diff options
Diffstat (limited to 'doc/rfc/rfc5909.txt')
| -rw-r--r-- | doc/rfc/rfc5909.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc5909.txt b/doc/rfc/rfc5909.txt new file mode 100644 index 0000000..dbb5789 --- /dev/null +++ b/doc/rfc/rfc5909.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) J-M. Combes +Request for Comments: 5909 France Telecom Orange +Category: Informational S. Krishnan +ISSN: 2070-1721 Ericsson + G. Daley + Netstar Logicalis + July 2010 + + + Securing Neighbor Discovery Proxy: Problem Statement + +Abstract + + Neighbor Discovery Proxies are used to provide an address presence on + a link for nodes that are no longer present on the link. They allow + a node to receive packets directed at its address by allowing another + device to perform Neighbor Discovery operations on its behalf. + + Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols + to provide reachability from nodes on the home network when a Mobile + Node is not at home, by allowing the Home Agent to act as proxy. It + is also used as a mechanism to allow a global prefix to span multiple + links, where proxies act as relays for Neighbor Discovery messages. + + Neighbor Discovery Proxy currently cannot be secured using Secure + Neighbor Discovery (SEND). Today, SEND assumes that a node + advertising an address is the address owner and in possession of + appropriate public and private keys for that node. This document + describes how existing practice for proxy Neighbor Discovery relates + to SEND. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5909. + + + + + +Combes, et al. Informational [Page 1] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Combes, et al. Informational [Page 2] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + +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 . . . . . . . . . . . . . . . . . . 21 + +1. Introduction + + Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery + [RFC4861]. It is used in networks where a prefix has to span + multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in + Mobile-IPv6-based protocols like Network Mobility (NEMO) [RFC3963], + Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568], or Hierarchical + Mobile IPv6 (HMIPv6) [RFC5380]) and in the Internet Key Exchange + Protocol (IKE) version 2 (IKEv2) [RFC4306]. It allows a device that + is not physically present on a link to have another advertise its + presence, and forward packets to the off-link device. + + + + +Combes, et al. Informational [Page 3] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + Neighbor Discovery Proxy relies upon another device, the proxy, to + monitor for Neighbor Solicitations (NSs), and answer with Neighbor + Advertisements (NAs). These proxy Neighbor Advertisements direct + data traffic through the proxy. Proxied traffic is then forwarded to + the end destination. + +2. Scenarios + + This section describes the different scenarios where the interaction + between Secure Neighbor Discovery (SEND) and ND Proxy raises issues. + +2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy + + The goal of IPv6 mobility is to allow nodes to remain reachable while + moving around in the IPv6 Internet. The following text is focused on + Mobile IPv6 but the issue raised by the interaction between SEND and + ND Proxy may be the same with Mobile IPv6 based protocols (e.g., + NEMO, HMIPv6). + + For Mobile IPv6 Mobile Nodes (MNs), it is necessary to keep existing + sessions going or to allow new sessions even when one leaves the home + network. + + In order to continue existing sessions, when nodes are present 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 [RFC3775]. + + For new sessions, the Proxy, which listens to the MN's address + responds with a Neighbor Advertisement that originates at its own + IPv6 address and has the proxy's address as the Target Link-Layer + Address, but contains the absent mobile in the Target Address field + of the Neighbor Advertisement. In this case, SEND cannot be applied + because the address in the Target Address field is not the same as + the one in the Source Address field of the IP header. + + As seen in Figure 1, solicitors send a multicast solicitation to the + solicited nodes multicast address (based on the unicast address) of + the absent node (a mobile node that is away from the home link). + + + + + + + + + + + + +Combes, et al. Informational [Page 4] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + 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 1 + + While at home, if the MN has configured Cryptographically Generated + Addresses (CGAs) [RFC3972], it can secure establishment by its on- + link neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using + SEND [RFC3971]. SEND security requires a node sending Neighbor + Advertisements for a given address to be in possession of the public/ + private key pair that generated the address. + + When an MN moves away from the home link, a proxy has to undertake + Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6, + the role of the proxy is undertaken by the Home Agent. While the + Home Agent has a security association with the MN, it does not have + access to the public/private key pair used to generate the MN's CGA. + Thus, the Home Agent acting as an ND proxy cannot use SEND for the + address it is proxying [RFC3971]. + + When an MN moves from the home network to a visited network, the + proxy will have to override the MN's existing Neighbor Cache Entries + that are flagged as secure [RFC3971]. This is needed for the Home + Agent to intercept traffic sent on-link to the MN that would + otherwise be sent to the MN's link-layer address. + + With the current SEND specification, any solicitation or + advertisement sent by the proxy will be unsecure and thus will not be + able to update the MN's NCE for the home address because it 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. + + + +Combes, et al. Informational [Page 5] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + Where secured proxy services are not able to be provided, a proxy's + advertisement may be overridden by a rogue proxy without the + receiving host realizing that an attack has occurred. This is + identical to what happens in a network where SEND is not deployed. + +2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy + + This scenario is a sub-case of the previous one. In this scenario, + 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 in the network protected by a security + gateway, the security gateway assigns an address dynamically using + Configuration Payload during IKEv2 exchanges. The security gateway + then needs to receive packets sent to this address; one way to do so + would be to proxy ND messages. + +2.3. Bridge-Like ND Proxies + + The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an + alternative method to classic bridging. Just as with classic + bridging, multiple link-layer segments are bridged into a single + segment, but with the help of proxying at the IP layer rather than + link-layer bridging. In this case, the proxy forwards messages while + modifying their source and destination MAC addresses, and it rewrites + their solicited and override flags and Link-Layer Address Options. + + This rewriting is incompatible with SEND signed messages for a number + of reasons: + + o Rewriting elements within the message will break the digital + signature. + + o The source IP address of each packet is the packet's origin, not + the proxy's address. The proxy is unable to generate another + signature for this address, as it doesn't have the CGA private key + [RFC3971]. + + Thus, proxy modification of SEND solicitations may require sharing of + credentials between the proxied node and the proxying node or + creation of new options with proxying capabilities. + + While bridge-like ND proxies aim to provide as little interference + with ND mechanisms as possible, SEND has been designed to prevent + modification or spoofing of advertisements by devices on the link. + + + + + + +Combes, et al. Informational [Page 6] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + Of particular note is the fact that ND Proxy performs a different + kind of proxy Neighbor Discovery to Mobile IPv6 [RFC3775] [RFC4389]. + RFC 3775 (Mobile IPv6) specifies that 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 is placed in the Target Link-Layer Address Option + [RFC3775]. On the other hand, ND Proxy resends messages containing + their original address, even after modification (i.e., the IP source + address remains the same) [RFC4389]. Figure 2 describes packet + formats for proxy Neighbor solicitation and advertisement as + specified by RFC 4389. + + 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 2 + + In order to use the same security procedures for both ND Proxy and + Mobile IPv6, changes may be needed to the proxying procedures in + [RFC4389], as well as changes to SEND. + + An additional (and undocumented) requirement for bridge-like proxying + is the operation of router discovery. Router discovery packets may + similarly modify Neighbor Cache state, and require protection from + SEND. + + In Figure 3, the router discovery messages propagate without + modification to the router address, but elements within the message + change. This is consistent with the description of Neighbor + Discovery above. + + + + + + +Combes, et al. Informational [Page 7] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + 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 3 + + Once again, these messages may not be signed with a CGA signature by + the proxy, because it does not own the source address. + + Additionally, Authorization Delegation Discovery messages need to be + exchanged for bridge-like ND proxies to prove their authority to + forward. Unless the proxy receives explicit authority to act as a + router, or the router knows of its presence, no authorization may be + made. This explicit authorization requirement may be at odds with + the zero configuration goal of ND proxying [RFC4389]. + + An alternative (alluded to in an appendix of ND Proxy [RFC4389]) + suggests that the proxy send Router Advertisements (RAs) from its own + address. As described by ND Proxy, this is insufficient for + providing proxied Neighbor Advertisement service, but may be matched + with Neighbor solicitation and advertisement services using the + proxy's source address in the same way as Mobile IPv6 [RFC4389] + [RFC3775]. This means that all router and Neighbor advertisements + would come from the proxied address, but may contain a target address + that allows proxied Neighbor presence to be established with peers on + other segments. Router discovery in this case has the identity of + the original (non-proxy) router completely obscured in router + discovery messages. + + The resultant proxy messages would have no identifying information + indicating their origin, which means that proxying between multiple + links would require state to be stored on outstanding solicitations + (effectively a ND only NAT). This level of state storage may be + undesirable. + + + +Combes, et al. Informational [Page 8] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + Mobile IPv6 does not experience this issue when supplying its own + address, since ND messages are never forwarded on to the absent node + (the Home Agent having sufficient information to respond itself). + + Authorization from a router may still be required for Router + Advertisement, and will be discussed in Section 4.2. + +3. Proxy Neighbor Discovery and SEND + + There are currently no existing secured Neighbor Discovery procedures + for proxied addresses, and all Neighbor Advertisements from SEND + nodes are required to have equal source and target addresses, and be + signed by the transmitter (Section 7.4 of [RFC3971]). + + Signatures over SEND messages are required to be applied on the CGA + source address of the message, and there is no way of indicating that + a message is proxied. + + Even if the message is able to be transmitted from the original + owner, differences in link-layer addressing and options require + modification by a proxy. If a message is signed with a CGA-based + signature, the proxy is unable to regenerate a signature over the + changed message as it lacks the keying material. + + Therefore, a router wishing to provide proxy Neighbor Advertisement + service cannot use existing SEND procedures on those messages. + + A host may wish to establish a session with a device that is not on- + link but is proxied. As a SEND host, it prefers to create Neighbor + Cache Entries using secured procedures. Since SEND signatures cannot + be applied to an existing proxy Neighbor Advertisement, it must + accept non-SEND advertisements in order to receive proxy Neighbor + Advertisements. + + Neighbor Cache spoofing of another node therefore becomes trivial, as + any address may be proxy-advertised to the SEND node, and overridden + only if the node is there to protect itself. When a node is present + to defend itself, it may also be difficult for the solicitor + determine the difference between a proxy-spoofing attack, and a + situation where a proxied device returns 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 + intended to tie address ownership to a particular public/private key + pair. + + + +Combes, et al. Informational [Page 9] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + In SEND as defined today, Neighbor Discovery messages (including the + IP Addresses from the IPv6 header) are signed with the same key used + to generate the CGA. This means that message recipients have proof + that the signer of the message 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 need to + be replaced with ones that correspond to the CGA of the proxy. To be + valid according to the SEND specification, the Target Address of the + Neighbor Advertisement message would need to be replaced also to be + equal to the Source Address [RFC3971]. + + Additional authorization information may be needed to prove that the + proxy is indeed allowed to advertise for the target address, as is + described in Section 4. + +3.2. Non-CGA Signatures and Proxy Neighbor Discovery + + Where a proxy retains the original source address in a proxied + message, existing security checks for SEND will fail, since fields + within the message will be changed. In order to achieve secured + proxy Neighbor Discovery in this case, extended authorization + mechanisms may be needed for SEND. + + SEND provides mechanisms for extension of SEND to non-CGA-based + authorization. Messages are available for Authorization Delegation + Discovery, which is able to carry arbitrary PKIX/X.509 certificates + [RFC5280]. + + There is, however, no specification of keying information option + formats analogous to the SEND CGA Option [RFC3971]. The existing + option allows a host to verify message integrity by specifying a key + and algorithm for digital signature, without providing authorization + via mechanisms other than CGA ownership. + + The digital signature in SEND is transported in the RSA Signature + Option. As currently specified, the signature operation is performed + over a CGA Message type, and allows for CGA verification. Updating + the signature function to support non-CGA operations may be + necessary. + + Within SEND, more advanced functions such as routing may be + authorized by certificate path verification using Authorization + Delegation Discovery. + + With non-CGA signatures and authentication, certificate contents for + authorization may need to be determined, as outlined in Section 4. + + + + +Combes, et al. Informational [Page 10] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + While SEND provides for 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 configured only to + accept 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 + + Initiation of proxy Neighbor Discovery also requires Duplicate + Address Detection (DAD) checks of the address [RFC4862]. These DAD + checks need to be performed by sending Neighbor Solicitations, from + the unspecified source address, with the target being the proxied + address. + + In existing SEND procedures, the address that is used for CGA tests + on DAD NS is the target address. A Proxy that originates this + message while the proxied address owner is absent is unable to + generate a CGA-based signature for this address and must undertake + DAD with an unsecured NS. It may be possible that the proxy can + ensure that responding NAs are secured though. + + Where bridge-like ND proxy operations are being performed, DAD NSs + may be copied from the original source, without modification + (considering they have an unspecified source address and contain no + link-layer address options) [RFC4389]. + + If non-CGA-based signatures are available, then the signature over + the DAD NS doesn't need to have a CGA relationship to the Target + Address, but authorization for address configuration needs to be + shown using certificates. + + In case there is a DAD collision between two SEND nodes on different + interfaces of the proxy, it is possible that the proxy may not have + the authority to modify the NA defending the address. In this case, + the proxy still needs to modify the NA and pass it onto the other + interfaces even if it will fail SEND verification on the receiving + node. + +3.4. Securing Router Advertisements + + While Router Solicitations are protected in the same manner as + Neighbor Solicitations, the security for Router Advertisements is + mainly based on the use of certificates. Even though the mechanism + for securing RAs is different, the problems that arise due to the + modification of the L2 addresses are exactly the same: the proxy + needs to have the right security material (e.g., certificate) to sign + the RA messages after modification. + + + +Combes, et al. Informational [Page 11] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + +4. Potential Approaches to Securing Proxy ND + + SEND nodes already have the concept of delegated authority through + requiring external authorization of routers to perform their routing + and advertisement roles. The authorization of these routers takes + the form of delegation certificates. + + Proxy Neighbor Discovery requires a delegation of authority (on + behalf of the absent address owner) to the proxier. Without this + authority, other devices on the link have no reason to trust an + advertiser. + + For bridge-like proxies, it is assumed that there is no preexisting + trust between the host owning the address and the proxy. Therefore, + authority may necessarily be dynamic or based on topological roles + within the network [RFC4389]. + + Existing trust relationships lend themselves to providing authority + for proxying in two alternative ways. + + First, the SEND router authorization mechanisms described above + provide delegation from the organization responsible for routing in + an address domain to the certified routers. It may be argued that + routers so certified may be trusted to provide service for nodes that + form part of a link's address range, but are themselves absent. + Devices which are proxies could either be granted the right to proxy + by the network's router, or be implicitly allowed to proxy by virtue + of being an authorized router. + + Second, where the proxied address is itself a CGA, the holder of the + public and private keys is seen to be authoritative about the + address's use. If this address owner was able to sign the proxier's + address and public key information, it would be possible to identify + that the proxy is known and trusted by the CGA address owner for + proxy service. This method requires that the proxied address know or + learn the proxy's address and public key, and that the certificate + signed by the proxied node's is passed to the proxy, either while + they share the same link, or at a later stage. + + In both methods, the original address owner's advertisements need to + override the proxy if it suddenly returns, and therefore timing and + replay protection from such messages need to be carefully considered. + +4.1. Secured Proxy ND and Mobile IPv6 + + Mobile IPv6 has a security association between the Mobile Node and + Home Agent. The Mobile Node sends a Binding Update to the Home + Agent, to indicate that it is not at home. This implies that the + + + +Combes, et al. Informational [Page 12] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery + operations for its home address(es). + +4.1.1. Mobile IPv6 and Router-Based Authorization + + A secured Proxy Neighbor Advertisements proposal based on existing + router trust would require no explicit authorization signaling + between HA and MN to allow proxying. Hosts on the home link will + believe proxied advertisements solely because they come from a + trusted router. + + Where the home agent operates as a router without explicit trust to + route from the advertising routing infrastructure (such as in a home, + with a router managed by an ISP), more explicit proxying + authorization may be required, as described in Section 4.2. + +4.1.2. Mobile IPv6 and Per-Address Authorization + + Where proxy Neighbor Discovery is delegated by the MN to the home + agent, the MN needs to learn the public key for the Home Agent, so + that it can generate a certificate authorizing the public/private key + pair to be used in proxying. It may conceivably do this using + Certificate Path Solicitations either over a home tunnel, when it is + away from home, or during router discovery while still at home + [RFC3971] [RFC3775]. + + When sending its Binding Update to the HA, the MN would need to + provide a certificate containing the subject's (i.e., proxy HA's) + public key and address, the issuer's (i.e., MN's) CGA and public key, + and timestamps indicating when the authority began and when it ends. + This certificate would need to be transmitted at binding time. + Messaging or such an exchange mechanism would have to be developed. + +4.1.3. Cryptographic-Based Solutions + + Specific cryptographic algorithms may help to allow trust between + entities of a same group. + + This is the case, for example, with ring signature algorithms. These + algorithms generate a signature using the private key of any member + from the same group, but to verify the signature the public keys of + all group members are required. Applied to SEND, the addresses are + cryptographically generated using multiple public keys, and the + Neighbor Discovery messages are signed with an RSA ring signature + [RING]. (Note that the cryptographic algorithms that are the + foundation for [RING] and other similar solutions are not widely + accepted in the security community; additional research is needed + before a Standards Track protocol could be developed.) + + + +Combes, et al. Informational [Page 13] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + +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, one prefix is provided per MN, and only an MN and the + HA are on a same link. The consequence is the HA no longer needs to + act as ND Proxy. + + One way to design such a solution is to use virtual interfaces, on + the MN and the HA, and a virtual link between them. Addresses + generated on the virtual interfaces will only be advertised on the + virtual link. For Mobile IPv6, this results in a virtual Home + Network where the MN will never come back. + +4.2. Secured Proxy ND and Bridge-Like Proxies + + In link-extension environments, the role of a proxy is more + explicitly separated from that of a router. In SEND, routers may + expect to be authorized by the routing infrastructure to advertise + and may provide this authority to hosts in order to allow them to + change forwarding state. + + Proxies are not part of the traditional infrastructure of the + Internet, and hosts or routers may not have an explicit reason to + trust them, except that they can forward packets to regions where + otherwise those hosts or routers could not reach. + +4.2.1. Authorization Delegation + + If a proxy can convince a device that it should be trusted to perform + proxying function, it may require that device to vouch for its + operation in dealing with other devices. It may do this by receiving + a certificate, signed by the originating device that the proxy is + believed capable of proxying under certain circumstances. + + This allows nodes receiving proxied Neighbor Discovery packets to + quickly check if the proxy is authorized for the operation. There + are several bases for such trust, and requirements in proxied + environments, which are discussed below. + +4.2.2. Unauthorized Routers and Proxies + + Routers may be advertising on networks without any explicit + authorization, and SEND hosts will register these routers if there + are no other options [RFC3971]. While proxies may similarly attempt + to advertise without authority, this provides no security for the + routing infrastructure. Any device can be setup as a SEND proxy/ + router so long as it signs its own ND messages from its CGA. + + + +Combes, et al. Informational [Page 14] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + This may not help in the case that a proxy attempts to update + Neighbor Cache Entries for a SEND node that moves between links, + since the SEND node's authority to advertise its own CGA address + would not be superseded by a proxy with no credentials. + +4.2.3. Multiple Proxy Spans + + Proxies may have multiple levels of nesting, which allow the network + to connect between 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 4 + + As shown in Figure 4, the Proxy A needs to redelegate authority to + proxy for T to Proxy B; this allows it to proxy advertisements that + target T back to D. + +4.2.4. Routing Infrastructure Delegation + + Where it is possible for the proxy to pre-establish trust with the + routing infrastructure, or at least to the local router, it may be + possible to authorize proxying as a function of routing within the + subnet. The router or CA may then be able to certify proxying for + only a subset of the prefixes for which it is itself certified. + + If a router or CA provides certification for a particular prefix, it + may be able to indicate that only proxying is supported, so that + Neighbor Cache Entries of routers connected to Internet + infrastructure are never overridden by the proxy, if the router is + present on a segment. + + + + +Combes, et al. Informational [Page 15] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + Hosts understanding such certificates may allow authorized proxies + and routers to override the host when assuming proxy roles, if the + host is absent. + + Proxy certificate signing could be done either dynamically (requiring + exchanges of identity and authorization information) or statically + when the network is set up. + +4.2.5. Local Delegation + + Where no trust tie exists between the authority that provides the + routing infrastructure and the provider of bridging and proxying + services, it may still be possible for SEND hosts to trust the + bridging provider to authorize proxying operations. + + SEND itself requires that routers be able to show authorization, but + doesn't require routers to have a single trusted root. + + A local bridging/proxying authority trust delegation may be possible. + It would be possible for this authority to pass out local-use + certificates, allowing proxying on a specific subnet or subnets, with + a separate authorization chain to those subnets for the routers with + Internet access. + + This would require little modification to SEND, other than the + addition of router-based proxy authority (as in Section 4.2.4), and + proxies would in effect be treated as routers by SEND hosts + [RFC3971]. Distribution of keying and trust material for the initial + bootstrap of proxies would not be provided though (and may be + static). + + Within small domains, key management and distribution may be a + tractable problem, so 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. + + + + + + +Combes, et al. Informational [Page 16] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + +4.2.6. Host Delegation of Trust to Proxies + + Unlike Mobile IPv6, for bridge-like proxied networks, there is no + existing security association upon which to transport proxying + authorization credentials. + + Thus, proxies need to convince Neighbors to delegate proxy authority + to them, in order to proxy-advertise to nodes on different segments. + It will be difficult without additional information to distinguish + between legitimate proxies and devices that have no need or right to + proxy (and may want to make two network segments appear connected). + + When proxy advertising, proxies must not only identify that proxying + needs to occur, but 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 received 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 + arrive back at the network and require other hosts to map their + existing Neighbor Cache Entry to the node's link-layer address. The + re-arriving node's overriding of link-layer address mappings will + occur without SEND in this case. + + It is 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 is not made + significantly worse by the proxy's presence (although the identity of + the attacker may be masked if source addresses are being replaced). + + + + + + +Combes, et al. Informational [Page 17] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + 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 indicate 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 ensure that + routers aren't spoofed, and subsequently switched to different parts + of the extended network. + + This has problems in that the origin is again unsecured, and any node + on the network could spoof 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 these complexities, 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: + + o Nodes having the same address, as the Mobile Access Gateway's + (MAG's) ingress link-local address in Proxy Mobile IPv6 (PMIPv6) + [RFC5213]. + + o Nodes having a common anycast address [RFC4291]. + + The problem statement, described previously in this document, applies + for 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. + + + + + + +Combes, et al. Informational [Page 18] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + 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. + +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. + + + + + + +Combes, et al. Informational [Page 19] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + 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. + + + + +Combes, et al. Informational [Page 20] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + + [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 + + [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. + + + + + + + +Combes, et al. Informational [Page 21] + +RFC 5909 SEND ND Proxy: Problem Statement July 2010 + + +Authors' Addresses + + 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 + + + + + + + + + + + + + + + + + + + + + + + +Combes, et al. Informational [Page 22] + |