RFC 5909
Securing Neighbor Discovery Proxy: Problem Statement
Abstract ✨
Okay bestie, this one is RFC 5909, Securing Neighbor Discovery Proxy: Problem Statement 📜🎀. It was written by J-M. Combes (France Telecom Orange), S. Krishnan (Ericsson), and G. Daley (Netstar Logicalis) in July 2010. It's Informational, so it's not a standards-track spec. The ISSN is 2070-1721, and the header doesn't list anything it obsoletes or updates. 💅
Neighbor Discovery Proxies give an address presence on a link to nodes that aren't actually on that link anymore 🧚. Another device does the Neighbor Discovery operations for them, so packets aimed at that address still find their way. Proxies are used in Mobile IPv6 and related protocols so that nodes on the home network can still reach a Mobile Node that's away from home, with the Home Agent acting as the proxy 🏠. They also let a global prefix stretch across multiple links, where proxies relay Neighbor Discovery messages 🌈.
The tea ☕: ND Proxy can't currently be secured with Secure Neighbor Discovery (SEND) 😭. SEND assumes that whoever advertises an address is the actual owner and holds the right public and private keys for it. This document looks at how existing proxy ND practice lines up with SEND 🔍.
Status of This Memo 📋
Quick legal-ish bit 🫶: this doc is not an Internet Standards Track spec. It's just published for info.
It is still an IETF product, so it reflects IETF community consensus. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is eligible for any level of Internet Standard, though. Check Section 2 of RFC 5741 for that 🧐.
For the current status, errata, or feedback, head to http://www.rfc-editor.org/info/rfc5909 💌.
Copyright Notice 🔐
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This document falls under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 📖. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License 🧾.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . 4
2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 6
2.3. Bridge-Like ND Proxies . . . . . . . . . . . . . . . . . . 6
3. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 9
3.1. CGA Signatures and Proxy Neighbor Discovery . . . . . . . 9
3.2. Non-CGA Signatures and Proxy Neighbor Discovery . . . . . 10
3.3. Securing Proxy DAD . . . . . . . . . . . . . . . . . . . . 11
3.4. Securing Router Advertisements . . . . . . . . . . . . . . 11
4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 12
4.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 12
4.1.1. Mobile IPv6 and Router-Based Authorization . . . . . . 13
4.1.2. Mobile IPv6 and Per-Address Authorization . . . . . . 13
4.1.3. Cryptographic-Based Solutions . . . . . . . . . . . . 13
4.1.4. Solution Based on the 'Point-to-Point' Link Model . . 14
4.2. Secured Proxy ND and Bridge-Like Proxies . . . . . . . . . 14
4.2.1. Authorization Delegation . . . . . . . . . . . . . . . 14
4.2.2. Unauthorized Routers and Proxies . . . . . . . . . . . 14
4.2.3. Multiple Proxy Spans . . . . . . . . . . . . . . . . . 15
4.2.4. Routing Infrastructure Delegation . . . . . . . . . . 15
4.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 16
4.2.6. Host Delegation of Trust to Proxies . . . . . . . . . 17
4.3. Proxying Unsecured Addresses . . . . . . . . . . . . . . . 17
5. Two or More Nodes Defending the Same Address . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 19
6.2. Certificate Transport . . . . . . . . . . . . . . . . . . 19
6.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 211. Introduction 🌸
ND Proxy is defined in IPv6 Neighbor Discovery [RFC4861] 💖. It's used in networks where a prefix has to span multiple links [RFC4389], and it also shows up in Mobile IPv6 [RFC3775]. That includes the Mobile-IPv6-based crew like Network Mobility (NEMO) [RFC3963], Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568], and Hierarchical Mobile IPv6 (HMIPv6) [RFC5380]. It's also in the Internet Key Exchange Protocol (IKE) version 2 (IKEv2) [RFC4306] 🔑. The vibe is that a device that isn't physically on a link can have another device advertise its presence and forward packets to the off-link device 🦋.
ND Proxy relies on a device, the proxy, to watch for Neighbor Solicitations (NSs) and answer them with Neighbor Advertisements (NAs) 👀. These proxy Neighbor Advertisements steer data traffic through the proxy. Then the proxied traffic gets forwarded to the actual end destination 🚀.
2. Scenarios 🎬
This section walks through the different situations where SEND and ND Proxy interact and cause problems 🙈.
2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy 🧳
The whole point of IPv6 mobility is letting nodes stay reachable while they roam around the IPv6 Internet 🌍. This part focuses on Mobile IPv6, but the SEND and ND Proxy issue may be the same for Mobile IPv6-based protocols (e.g., NEMO, HMIPv6) 💜.
For Mobile IPv6 Mobile Nodes (MNs), it's necessary to keep existing sessions running, or to start new ones, even when a node leaves the home network 🏃♀️.
To keep existing sessions going while nodes are on the home link, the Proxy (i.e., the Home Agent in Mobile IPv6) sends an unsolicited NA to the all-nodes multicast address on the home link, as specified in [RFC3775] ✨.
For new sessions, the Proxy listens for the MN's address and responds with a Neighbor Advertisement. That NA comes from its own IPv6 address and carries the proxy's address as the Target Link-Layer Address. The Target Address field, though, contains the absent mobile 👻. SEND can't be applied here, because the address in the Target Address field isn't the same as the one in the Source Address field of the IP header 💀.
Check out Figure 1 😍. Solicitors send a multicast solicitation to the solicited nodes multicast address (based on the unicast address) of the absent node, which is a mobile node that's away from the home link 📡.
Absent Mobile Proxy Solicitor
NS:SL3=S,DL3=Sol(A),TA=A
+-----+ SL2=s,DL2=sol(a),SLL=s
| |<================
| |
| |================>
+-----+ NA:SL3=P,DL3=S,TA=A,
SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address RS: Router Solicitation
DL2: Destination Link-Layer Address RA: Router Advertisement
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 1When the MN is at home and has configured Cryptographically Generated Addresses (CGAs) [RFC3972], it can lock in establishment of Neighbor Cache Entries (NCEs) for its CGAs with its on-link neighbors, using SEND [RFC3971] 🔐. SEND security requires a node sending Neighbor Advertisements for a given address to hold the public/private key pair that generated that address 🗝️.
When an MN moves away from the home link, a proxy has to handle Neighbor Discovery signaling on the MN's behalf. In Mobile IPv6, the Home Agent is the one doing this proxy job 🏡. The Home Agent has a security association with the MN, but it doesn't have access to the public/private key pair used to generate the MN's CGA 🥲. So the Home Agent acting as an ND proxy can't use SEND for the address it's proxying [RFC3971] 🚫.
When an MN moves from the home network to a visited network, the proxy has to override the MN's existing Neighbor Cache Entries that are flagged as secure [RFC3971] 😬. That's needed so the Home Agent can intercept traffic sent on-link to the MN that would otherwise go to the MN's link-layer address 🛑.
With the current SEND spec, any solicitation or advertisement the proxy sends will be unsecured. So it can't update the MN's NCE for the home address, since that entry is flagged as secured 🙅♀️. These existing Neighbor Cache Entries will only time out after Neighbor Unreachability Detection [RFC4861] concludes the Home Address is unreachable at the link layer recorded in the NCE ⏳.
If secured proxy services can't be provided, a rogue proxy may override a proxy's advertisement, and the receiving host won't realize an attack happened 😱. This is identical to what happens in a network where SEND isn't deployed 🥀.
2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy 🏰
This scenario is a sub-case of the previous one 🧩. Here, the IPv6 node will never be on the link where the ND messages are proxied. For example, an IPv6 node gains remote access to a network protected by a security gateway that runs IKEv2 [RFC4306] 🔒. When a node needs an IP address inside the network behind that security gateway, the gateway assigns one dynamically using Configuration Payload during IKEv2 exchanges 🎁. The security gateway then has to receive packets sent to this address, and one way it could do that is by proxying ND messages 📬.
2.3. Bridge-Like ND Proxies
okay so the Neighbor Discovery (ND) Proxy spec [RFC4389] has a different way to do what classic bridging does 💅 Multiple link-layer segments still get bridged into one segment, but the magic happens with proxying at the IP layer instead of link-layer bridging ✨ The proxy forwards messages while changing their source and destination MAC addresses, and it rewrites their solicited and override flags and Link-Layer Address Options 🦋
this rewriting is NOT compatible with SEND signed messages, and it's not just one reason, bestie 😭
- rewriting stuff inside the message breaks the digital signature 💀
- the source IP address of each packet is the packet's origin, not the proxy's address. the proxy can't make another signature for that address because it doesn't have the CGA private key [RFC3971] 🙈
so proxy modification of SEND solicitations might need the proxied node and the proxying node to share credentials, or somebody has to make brand new options with proxying capabilities 🔐
bridge-like ND proxies want to interfere with ND as little as possible, but SEND was built to stop devices on the link from modifying or spoofing advertisements 🛡️ literally opposite vibes, periodt
here's the big one: ND Proxy does a different kind of proxy Neighbor Discovery than Mobile IPv6 does [RFC3775] [RFC4389] 👀 RFC 3775 (Mobile IPv6) says the Home Agent as proxy sends Neighbor Advertisements from its own address, with the Target Address set to the absent Mobile Node's address. the Home Agent's own link-layer address goes in the Target Link-Layer Address Option [RFC3775] 🏠 but ND Proxy resends messages with their original address, even after modification (so the IP source address stays the same) [RFC4389] 😳 Figure 2 shows the packet formats for proxy Neighbor solicitation and advertisement as RFC 4389 specifies them 📦
Advertiser Proxy Solicitor
NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A,
SL2=p,DL2=sol(a),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s
<==================| |<================
| |
==================>| |================>
NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A
SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 2to use the same security procedures for both ND Proxy and Mobile IPv6, the proxying procedures in [RFC4389] might need changes, and SEND might need changes too 🔧
there's also an extra (and undocumented!) requirement for bridge-like proxying: router discovery 🤫 router discovery packets can change Neighbor Cache state in a similar way, so they need protection from SEND as well 🛡️
in Figure 3, the router discovery messages go through to the router address without being modified, but the elements inside the message change. this matches the Neighbor Discovery description above 🎀
Advertiser Proxy Solicitor
RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR,
SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s
<==================| |<================
| |
==================>| |================>
RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S,
SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p
Legend:
SL3: Source IPv6 Address RS: Router Solicitation
DL3: Destination IPv6 Address RA: Router Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 3once again, the proxy can't sign these messages with a CGA signature, because it doesn't own the source address 🙃
also, Authorization Delegation Discovery messages need to be exchanged so bridge-like ND proxies can prove they're allowed to forward 🎟️ unless the proxy gets explicit authority to act as a router, or the router knows it's there, no authorization may be made 🚫 and honestly this explicit authorization requirement might clash with the zero configuration goal of ND proxying [RFC4389] 😤
there's an alternative (hinted at in an appendix of ND Proxy [RFC4389]) where the proxy sends Router Advertisements (RAs) from its own address 🌸 as ND Proxy describes it, that's not enough to give proxied Neighbor Advertisement service. but it can be matched with Neighbor solicitation and advertisement services using the proxy's source address, the same way Mobile IPv6 does [RFC4389] [RFC3775] 🦋 so all router and Neighbor advertisements would come from the proxied address, but they can carry a target address that lets proxied Neighbor presence get set up with peers on other segments ✨ and in this case the identity of the original (non-proxy) router is completely hidden in router discovery messages 🫥
the resulting proxy messages would have no identifying info showing where they came from. so proxying between multiple links would need state stored on outstanding solicitations, which is basically an ND-only NAT 😵💫 that level of state storage may be undesirable 🙅♀️
Mobile IPv6 doesn't have this problem when it supplies its own address, because ND messages never get forwarded on to the absent node (the Home Agent has enough info to respond itself) 🏠💜
authorization from a router may still be required for Router Advertisement, and Section 4.2 talks about that 📚
3. Proxy Neighbor Discovery and SEND
okay real talk, there are currently no existing secured Neighbor Discovery procedures for proxied addresses 😭 and all Neighbor Advertisements from SEND nodes have to have equal source and target addresses, AND be signed by the transmitter (Section 7.4 of [RFC3971]) 🔏
SEND signatures have to be applied to the CGA source address of the message, and there's no way to indicate that a message was proxied 🚫
even if the message can come from the original owner, differences in link-layer addressing and options mean a proxy has to modify it 🔄 and if a message has a CGA-based signature, the proxy can't regenerate the signature over the changed message because it doesn't have the keying material 🔑
so a router that wants to provide proxy Neighbor Advertisement service can't use existing SEND procedures on those messages 💔
a host might want to set up a session with a device that's not on-link but is proxied 👀 as a SEND host, it prefers to create Neighbor Cache Entries using secured procedures. but since SEND signatures can't be applied to an existing proxy Neighbor Advertisement, it must accept non-SEND advertisements in order to receive proxy Neighbor Advertisements 🥺
so Neighbor Cache spoofing of another node becomes super easy, because any address can be proxy-advertised to the SEND node 😈 it can only be overridden if the node is there to protect itself 🛡️ and when a node is present to defend itself, it can be hard for the solicitor to tell apart a proxy-spoofing attack from a situation where a proxied device comes back to a link and overrides other proxy advertisers [RFC4861] 🧐
3.1. CGA Signatures and Proxy Neighbor Discovery
SEND defines one public-key and signature format for use with Cryptographically Generated Addresses (CGAs) [RFC3972] 🔐 CGAs are meant to tie address ownership to a particular public/private key pair 💜
in SEND as it's defined today, Neighbor Discovery messages (including the IP Addresses from the IPv6 header) are signed with the same key used to generate the CGA 🖊️ so message recipients have proof that the signer owned the address 🎀
when a proxy replaces the message's source IPv6 address with its own CGA, the existing CGA option and RSA signature option would have to be replaced with ones that match the proxy's CGA 🔁 and to be valid under the SEND spec, the Target Address of the Neighbor Advertisement would also have to be replaced so it equals the Source Address [RFC3971] 😩
extra authorization info might be needed to prove the proxy is actually allowed to advertise for the target address, as described in Section 4 📜
3.2. Non-CGA Signatures and Proxy Neighbor Discovery
if a proxy keeps the original source address in a proxied message, the existing SEND security checks will fail, because fields inside the message have changed 💥 to get secured proxy Neighbor Discovery in this case, extended authorization mechanisms might be needed for SEND ✨
SEND does provide ways to extend it to non-CGA-based authorization 🙌 there are messages for Authorization Delegation Discovery, which can carry arbitrary PKIX/X.509 certificates [RFC5280] 📜
BUT there's no specification of keying information option formats that are analogous to the SEND CGA Option [RFC3971] 😤 the existing option lets a host verify message integrity by specifying a key and algorithm for the digital signature, without giving authorization through anything other than CGA ownership 🔑
the digital signature in SEND is carried in the RSA Signature Option 🖋️ as currently specified, the signature operation is done over a CGA Message type and allows CGA verification. updating the signature function to support non-CGA operations might be necessary 🛠️
inside SEND, more advanced functions like routing may be authorized by certificate path verification using Authorization Delegation Discovery 🗺️
with non-CGA signatures and authentication, the certificate contents used for authorization might need to be figured out, as outlined in Section 4 🧩
while SEND allows extensions to new non-CGA methods, existing SEND hosts may silently discard messages with unverifiable RSA signature options (Section 5.2.2 of [RFC3971]) if they're configured to accept only SEND messages 🙈 in cases where unsecured Neighbor Cache Entries are still accepted, messages from new algorithms will be treated as unsecured 🫣
3.3. Securing Proxy DAD 🔐
okay so proxy ND needs DAD checks on the address too [RFC4862] 🫶 those DAD checks get sent as Neighbor Solicitations from the unspecified source address, with the target being the proxied address 🎀
in existing SEND, the address used for the CGA tests on a DAD NS is the target address 👀 but if the proxied address owner is absent, the proxy literally can't make a CGA-based signature for it 😭 so it has to do DAD with an unsecured NS. the proxy might be able to make sure the NAs that come back are secured though 💅
for bridge-like ND proxy stuff, DAD NSs can be copied from the original source without changing them 🌸 (they have an unspecified source address and no link-layer address options, so there's nothing to fix) [RFC4389] ✨
if non-CGA signatures are available, the signature over the DAD NS doesn't have to have a CGA relationship to the Target Address 🦋 BUT authorization for address configuration still has to be shown using certificates. no shortcuts bestie 🙅♀️
and then there's the DAD collision case 💀 if two SEND nodes on different interfaces of the proxy collide, the proxy might not have the authority to change the NA that's defending the address. even so, the proxy still needs to modify the NA and pass it along to the other interfaces, even if the receiving node ends up failing SEND verification 😭🔥
3.4. Securing Router Advertisements 📮
Router Solicitations get protected the same way Neighbor Solicitations do ✨ but for Router Advertisements, the security is mainly based on certificates 🎀 so the mechanism is different, but the problem you get when L2 addresses are modified is exactly the same 💖 the proxy needs the right security material (e.g., a certificate) to sign the RA messages after modifying them 🔐
4. Potential Approaches to Securing Proxy ND 🌈
SEND nodes already have delegated authority built in 👑 routers need external authorization before they can do their routing and advertising jobs, and that authorization comes in the form of delegation certificates 📜
proxy Neighbor Discovery needs a delegation of authority (acting on behalf of the absent address owner) given to the proxier 🫶 without that authority, other devices on the link have no reason to trust the advertiser 🙈
for bridge-like proxies, it's assumed there's no preexisting trust between the host that owns the address and the proxy 💜 so the authority might have to be dynamic, or based on topological roles in the network [RFC4389] 🧚
there are two ways existing trust relationships can give authority for proxying 🦋
first, the SEND router authorization mechanisms from above give delegation from the organization in charge of routing in an address domain to the certified routers 👑 you could argue that certified routers can be trusted to serve nodes in a link's address range that happen to be absent 🌸 proxies could either be granted the right to proxy by the network's router, or be implicitly allowed to proxy just by being an authorized router ✨
second, if the proxied address is itself a CGA, the holder of the public and private keys is treated as the authority on how the address gets used 🔑 if this address owner signed the proxier's address and public key information, you could tell that the proxy is known and trusted by the CGA address owner for proxy service 🥹 this method needs the proxied address to know or learn the proxy's address and public key, and the certificate signed by the proxied node has to be passed to the proxy, either while they're on the same link or later on 📮
In both methods, the original address owner's advertisements need to override the proxy if it suddenly comes back 🚨 so timing and replay protection for those messages need to be thought through super carefully 🙏
4.1. Secured Proxy ND and Mobile IPv6 🏠
Mobile IPv6 has a security association between the Mobile Node and the Home Agent 🫶 the Mobile Node sends a Binding Update to the Home Agent to say it's not at home 🧳 that basically means the Mobile Node wants the Home Agent to start proxy Neighbor Discovery for its home address(es) 💅
4.1.1. Mobile IPv6 and Router-Based Authorization 🛣️
a secured Proxy Neighbor Advertisements idea based on existing router trust wouldn't need any explicit authorization signaling between the HA and MN to allow proxying 🙌 hosts on the home link will believe the proxied advertisements purely because they come from a trusted router 💖
but if the home agent is acting as a router without explicit trust to route from the advertising routing infrastructure (like a home with a router managed by an ISP), you may need more explicit proxying authorization, as described in Section 4.2 🫠
4.1.2. Mobile IPv6 and Per-Address Authorization 🔏
when proxy Neighbor Discovery is delegated by the MN to the home agent, the MN needs to learn the public key of the Home Agent 🔑 that way it can generate a certificate authorizing the public/private key pair to be used for proxying 📜 it might be able to do this using Certificate Path Solicitations, either over a home tunnel when it's away, or during router discovery while still at home [RFC3971] [RFC3775] 🏡
when the MN sends its Binding Update to the HA, it would need to provide a certificate containing the subject's (the proxy HA's) public key and address, the issuer's (the MN's) CGA and public key, and timestamps for when the authority begins and when it ends 🗓️ this certificate would need to be sent at binding time 💌 some messaging or exchange mechanism would have to be developed for that 🛠️
4.1.3. Cryptographic-Based Solutions 🧪
certain cryptographic algorithms might help allow trust between entities in the same group 🫶
ring signature algorithms are an example of this 💫 they create a signature using the private key of any member of the group, but verifying it requires the public keys of all the group members 🔐 applied to SEND, the addresses get cryptographically generated using multiple public keys, and the Neighbor Discovery messages are signed with an RSA ring signature [RING] 🌈
(ngl, the cryptographic algorithms underneath [RING] and similar solutions aren't widely accepted in the security community yet 🥺 more research is needed before a Standards Track protocol could be developed 🔬)
4.1.4. Solution Based on the 'Point-to-Point' Link Model 🪢
another approach is to use the 'Point-to-Point' link model 💜
in this model, there's one prefix per MN, and only an MN and the HA are on the same link 🫧 that means the HA no longer needs to act as an ND Proxy 🙌
one way to design this is with virtual interfaces on the MN and the HA, plus a virtual link between them 🦋 addresses generated on the virtual interfaces only get advertised on the virtual link 🎀 for Mobile IPv6, that results in a virtual Home Network where the MN never comes back 😭🏠
4.2. Secured Proxy ND and Bridge-Like Proxies 🌉
in link-extension environments, the role of a proxy is separated from the role of a router much more clearly 💅 in SEND, routers may be expected to be authorized by the routing infrastructure to advertise, and they may pass that authority on to hosts so the hosts can change forwarding state ✨
proxies aren't part of the traditional Internet infrastructure 🙈 hosts or routers might not have an explicit reason to trust them, except that proxies can forward packets to regions those hosts or routers couldn't otherwise reach 🧚
4.2.1. Authorization Delegation 🪪
if a proxy can convince a device that it should be trusted to do proxying, it may require that device to vouch for how it operates when dealing with other devices 🫶 it can do that by getting a certificate, signed by the originating device, saying the proxy is believed capable of proxying under certain circumstances 📜
this lets nodes that receive proxied Neighbor Discovery packets quickly check whether the proxy is authorized for the operation ⚡ there are several bases for that trust, and some requirements in proxied environments, which are covered below 👀
4.2.2. Unauthorized Routers and Proxies 🚫
routers can end up advertising on networks without any explicit authorization, and SEND hosts will register those routers if there are no other options [RFC3971] 😬 proxies can also try to advertise without authority, but that gives zero security for the routing infrastructure 💀 any device can be set up as a SEND proxy/router as long as it signs its own ND messages from its CGA 🙃
this might not help if a proxy tries to update Neighbor Cache Entries for a SEND node that moves between links 🏃♀️ the SEND node's authority to advertise its own CGA address wouldn't be overridden by a proxy with no credentials 🛡️
4.2.3. Multiple Proxy Spans 🕸️
proxies can have multiple levels of nesting, which lets the network connect non-adjacent segments 🧵
in this case, authority delegated at one point will have to be redelegated (possibly in a diluted form) to proxies further away from the origin of the trust 🫠
Trust Proxy A Proxy B Distant
Origin - T Node - D
+-----+ +-----+
| | | |
+-----+ +-----+ +-----+ +-----+
| | | | | |
------------| |------------| |----------
| | | |
+-----+ +-----+
==========> ==============> ==========>
Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B,
Deleg(A,T))
Figure 4as shown in Figure 4, Proxy A needs to redelegate authority to proxy for T over to Proxy B 🎀 that lets Proxy B proxy advertisements that target T back to D 🧚♀️
4.2.4. Routing Infrastructure Delegation 🏗️
if the proxy can pre-establish trust with the routing infrastructure, or at least with the local router, it may be possible to authorize proxying based on routing within the subnet 🗺️ the router or CA may then be able to certify proxying for only a subset of the prefixes it's certified for itself 💅
if a router or CA certifies a particular prefix, it may be able to indicate that only proxying is supported 🙅♀️ that way, Neighbor Cache Entries of routers connected to Internet infrastructure are never overridden by the proxy when the router is present on a segment 🛡️
hosts that understand such certificates may allow authorized proxies and routers to override the host when they take on proxy roles, if the host is absent 🫶
proxy certificate signing could be done dynamically (which requires exchanges of identity and authorization information) or statically when the network is set up ⚙️✨
4.2.5. Local Delegation 🏠✨
okay so, what if there's no trust tie between whoever runs the routing infrastructure and whoever is doing the bridging and proxying? 🥺 SEND hosts might still be able to trust the bridging provider to authorize proxying anyway. bestie, that's a whole vibe. 💅
SEND itself does require that routers can show they're authorized, but it doesn't make routers have one single trusted root. no cap, that flexibility is lowkey iconic. 👑
A local bridging/proxying authority trust delegation may be possible. This authority could hand out local-use certificates that allow proxying on a specific subnet or subnets, with a separate authorization chain to those subnets for the routers that have Internet access. 🦋
This would need only small changes to SEND, apart from adding router-based proxy authority (as in Section 4.2.4). Proxies would basically be treated as routers by SEND hosts [RFC3971]. The one thing that wouldn't be provided is distribution of keying and trust material for the initial bootstrap of proxies (and that part may be static). 🌸
Within small domains, key management and distribution may be a tractable problem, as long as these operations are simple enough to perform. 🧚
Since these domains may be small, it may be necessary to provide certificate chains for trust anchors that weren't requested in Certificate Path Solicitations, if the proxy doesn't have a trust chain to any requested trust anchor. 🫶
This is akin to 'suggesting' an appropriate trusted root. It may allow for user action in allowing trust extension when visiting domains without ties to a global keying infrastructure. In this case, the trust chain would have to start with a self-signed certificate from the original CA. 🔥
4.2.6. Host Delegation of Trust to Proxies 🤝
Unlike Mobile IPv6, bridge-like proxied networks don't have an existing security association to carry proxying authorization credentials. 😭
So proxies need to convince Neighbors to delegate proxy authority to them, so they can proxy-advertise to nodes on different segments. Without additional information, it's going to be hard to tell legitimate proxies apart from devices that have no need or right to proxy (and that might want to make two network segments look connected). 🙈
When proxy advertising, proxies must not only identify that proxying needs to occur, but also provide proof that they are allowed to do so, so that SEND Neighbor Cache Entries may be updated. Unless the authorization to update such entries is tied to address ownership proofs from the proxied host or the verifiable routing infrastructure, spoofing may occur. 💀
When a host receives a proxied Neighbor advertisement, it would be necessary to check authorization in the same way that authorization delegation discovery is performed in SEND. 🔍
Otherwise, certificate transport will be required to exchange authorization between proxied nodes and proxies. 🍓
Proxies would have to be able to delegate this authorization to downstream proxies, as described in Section 4.2.3. 🌈
4.3. Proxying Unsecured Addresses 🫥
Where the original Neighbor Discovery message is unsecured, there is an argument for not providing secured proxy service for that node. 🤷♀️
In both the Mobile IPv6 and extended networks cases, the node may come back to the network and need other hosts to map their existing Neighbor Cache Entry to the node's link-layer address. In this case, the re-arriving node's overriding of link-layer address mappings will happen without SEND. 🔄
It's notable that without SEND protection, any node may spoof the arrival and effectively steal service across an extended network. This is the same as in the non-proxy case, and it isn't made significantly worse by the proxy's presence (although the identity of the attacker may be masked if source addresses are being replaced). 🕵️♀️
If signatures over the proxied messages were to be used, re-arrival and override of the Neighbor Cache Entries would have to be allowed, so the signatures would show that at least the proxy wasn't spoofing (even if the original sender was). ✍️
For non-SEND routers, though, it may be possible for secured proxies to send signed router advertisement messages, in order to make sure routers aren't spoofed and then switched to different parts of the extended network. 🛡️
This has problems, because the origin is again unsecured, and any node on the network could spoof a router advertisement for an unsecured address. These spoofed messages may become almost indistinguishable (except for the non-CGA origin address) from unspoofed messages from SEND routers. 😵💫
Given all this complexity, the simplest method is to allow unsecured devices to be spoofed from any port on the network, as is the case today. 🫠
5. Two or More Nodes Defending the Same Address 🎀
All the previous sections of this document focused on the case where two nodes defend the same address (i.e., the node and the proxy). However, there are also cases where two or more nodes are defending the same address. This is at least the case for:
- Nodes having the same address, as the Mobile Access Gateway's (MAG's) ingress link-local address in Proxy Mobile IPv6 (PMIPv6) [RFC5213].
- Nodes having a common anycast address [RFC4291].
The problem statement, described previously in this document, applies to these cases, and the issues are the same from a signaling point of view. 📡
Multicast addresses are not mentioned here because Neighbor Discovery Protocol is not used for them. 🙅♀️
In the first case, [RFC5213] assumes that the security material used by SEND (i.e., public-private key pair) is shared between all the MAGs. For the second case, there is no solution today. But, in the same way, it should be possible to assume that the nodes having a common anycast address could also share the security material. 🔑
It is important to notice that when many nodes defending the same address are not in the same administrative domain (e.g., MAGs in different administrative domains but in the same PMIPv6 domain [RFC5213]), sharing the security material used by SEND may raise a security issue. 🚨
6. Security Considerations 🔐
6.1. Router Trust Assumption 👀
Router-based authorization for Secured Proxy ND may occur without the knowledge or consent of a device. It is susceptible to the 'Good Router Goes Bad' attack described in [RFC3756]. 😱
6.2. Certificate Transport 📜
Certificate delegation relies upon transfer of the new credentials to the proxying HA in order to undertake ND proxy on its behalf. Since the binding cannot come into effect until DAD has taken place, the delegation of the proxying authority necessarily predates the return of the Binding Ack, as described in [RFC3775]. In the case above described, the home tunnel that comes into creation as part of the binding process may be required for transport of Certificate Path Solicitations or Advertisements [RFC3971]. This constitutes a potential chicken-and-egg problem. Either modifications to initial home binding semantics or certificate transport are required. This may be trivial if certificates are sent in the clear between the MN's Care-of Address (CoA) and the HA without being tunneled. 🥚🐔
⚠️ bestie, read that chicken-and-egg bit twice. the tunnel you need to send the certs is the same tunnel that doesn't exist until the binding finishes. 💀
6.3. Timekeeping ⏰
All of the presented methods rely on accurate timekeeping on the receiver nodes of Neighbor Discovery Timestamp Options.
For router-authorized proxy ND, a Neighbor may not know that a particular ND message is replayed from the time when the proxied host was still on-link, since the message's timestamp falls within the valid timing window. Where the router advertises its secured proxy NA, a subsequent replay of the old message will override the NCE created by the proxy. 🫣
Creating the NCE in this way, without reference to accurate subsequent timing, may only be done once. Otherwise, the receiver will notice that the timestamp of the advertisement is old or doesn't match. ⌛
One way of creating a sequence of replayable messages that have timestamps likely to be accepted is to pretend to do an unsecured DAD on the address each second while the MN is at home. The attacker saves each DAD defense in a sequence. The granularity of SEND timestamp matching is around one second, so the attacker has a set of SEND NAs to advertise, starting at a particular timestamp, and valid for as many seconds as the original NA gathering occurred. 🎭
This sequence may then be played against any host that doesn't have a timestamp history for that MN, by tracking the number of seconds elapsed since the initial transmission of the replayed NA to that victim, and replaying the appropriate cached NA. 🫤
Where certificate-based authorization of ND proxy is in use, the origination/starting timestamp of the delegated authority may be used to override a replayed (non-proxy) SEND NA, while also ensuring that the Proxy NA's timestamp (provided by the proxy) is fresh. A returning MN would advertise a more recent timestamp than the delegated authority and thus override it. This method is therefore not subject to the above attack, since the proxy advertisement's certificate will have a timestamp greater than any replayed messages, preventing it from being overridden. 🛑✨
7. Acknowledgments 💖
James Kempf and Dave Thaler particularly contributed to work on this document. Contributions to discussion on this topic helped to develop this document. The authors would also like to thank Jari Arkko, Vijay Devarapalli, Mohan Parthasarathy, Marcelo Bagnulo, Julien Laganier, Tony Cheneau, Michaela Vanderveen, Sean Shen, and Sheng Jiang for their comments and suggestions. 🙌
Jean-Michel Combes is partly funded by MobiSEND, a research project supported by the French 'National Research Agency' (ANR). 🇫🇷
8. References 📚
8.1. Normative References
- [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
- [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
8.2. Informative References 📚
okay bestie, these are the "for further reading" receipts 🧾 the spec leans on. none of them are required to implement this, but they're the context. the trust models paper, mobile IP stuff, the X.509 profile, and one work-in-progress draft that's basically the same idea as this doc 🦋
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
July 2009.
[RING] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying
using Multi-Key Cryptographically Generated Addresses
(MCGAs)", Work in Progress, August 2005.Authors' Addresses ✨
the squad behind this doc, and how to reach them 💌
Jean-Michel Combes
France Telecom Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
EMail: jeanmichel.combes@orange-ftgroup.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal
QC Canada
EMail: Suresh.Krishnan@ericsson.com
Greg Daley
Netstar Logicalis
Level 6/616 St Kilda Road
Melbourne, Victoria 3004
Australia
Phone: +61 401 772 770
EMail: hoskuld@hotmail.com📦 where this page comes from
- ietf: rfc5909 2010-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms