--- 1/draft-ietf-csi-proxy-send-04.txt 2010-09-28 18:12:20.000000000 +0200 +++ 2/draft-ietf-csi-proxy-send-05.txt 2010-09-28 18:12:20.000000000 +0200 @@ -1,52 +1,54 @@ CGA & SEND maintenance Working S. Krishnan Group Ericsson Internet-Draft J. Laganier Intended status: Experimental QUALCOMM Inc. -Expires: December 2, 2010 M. Bonola +Expires: April 1, 2011 M. Bonola Rome Tor Vergata University A. Garcia-Martinez UC3M - May 31, 2010 + September 28, 2010 Secure Proxy ND Support for SEND - draft-ietf-csi-proxy-send-04 + draft-ietf-csi-proxy-send-05 Abstract Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending a ND message is the - owner of the address from which the message is sent, so that it is in - possession of the private key used to generate the digital signature - on the message. This means that the Proxy ND signaling performed by - nodes that do not possess knowledge of the address owner's private - key cannot be secured using SEND. This document extends the current - SEND specification in order to secure Proxy ND operation. + owner of the address from which the message is sent and/or posses a + key which authorizes the node to act as a router, so that it is in + possession of the private key or keys used to generate the digital + signature on each message. This means that the Proxy ND signaling + performed by nodes that do not possess knowledge of the address + owner's private key and/or knowledge of a router's key cannot be + secured using SEND. This document extends the current SEND + specification in order to secure Proxy ND operation. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 2, 2010. + This Internet-Draft will expire on April 1, 2011. 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 @@ -60,166 +62,182 @@ 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6 5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8 5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8 5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10 5.2.1. Processing rules for senders . . . . . . . . . . . . . 10 5.2.2. Processing rules for receivers . . . . . . . . . . . . 11 - 5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 12 - 6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 13 - 6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 14 - 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 17 + 5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 13 + 6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 14 + 6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 14 + 6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 15 + 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 18 7. Backward Compatibility with RFC3971 nodes and non-SEND - nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 19 - 7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 19 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 + nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 20 + 7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 20 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for securing Neighbor Discovery (ND) signaling [RFC4861] against specific threats [RFC3756]. As defined today, SEND assumes that the node sending a ND message is the owner of the address from which the - message is sent, so that it is in possession of the private key used - to generate the digital signature on the message. This means that - the Proxy ND signaling performed by nodes that do not possess - knowledge of the address owner's private key cannot be secured using - SEND. + message is sent and/or posses a key which authorizes the node to act + as a router, so that it is in possession of the private key or keys + used to generate the digital signature on each message. This means + that the Proxy ND signaling performed by nodes that do not possess + knowledge of the address owner's private key and/or knowledge of a + router's key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND. From this point on we refer to such extension as "Secure Proxy ND Support for SEND". 3. Terminology Secure ND Proxy - A node authorized to either modify or generate a SEND message - without knowing the private key related to the source address of - the ICMPv6 ND message. + A node authorized to secure a Neighbor Discovery Protocol (NDP) + message without knowing the private key related to the source + address of the node, or the key related to the router + authorization, for which the node acts on behalf. Proxied IPv6 address An IPv6 address that does not belong to the Secure ND Proxy and for which the Secure ND Proxy is performing advertisements. Non-SEND node An IPv6 node that does not implement the SEND [RFC3971] - specification but uses only the ND protocol defined in [RFC4861] - and [RFC4862], without security. + specification but uses the ND protocol defined in [RFC4861] and + [RFC4862], without additional security. RFC3971 node An IPv6 node that does not implement the specification defined in - this document for Secure Proxy ND support, but uses only the SEND + this document for Secure Proxy ND support, but uses the SEND specification as defined in [RFC3971]. SPND node An IPv6 node that receives and validates messages according to the specification defined in this document for Secure Proxy ND support. + Translated NDP message + + A NDP message issued by a Secure ND Proxy as a result of a + received NDP message originated by the owner of the address or + originated by another node acting on behalf of the owner of the + address. + + Synthetic NDP message + + A NDP message issued by a Secure ND Proxy that is not the result + of a received NDP message. + 4. Secure Proxy ND Overview The original SEND specification [RFC3971] has implicitly assumed that only the node sending a ND message is the owner of the address from which the message is sent. This assumption does not allow proxying of ND messages since the advertiser is required to generate a valid RSA Signature option, which in turns requires possession of the public-private key pair that was used to generate a CGA, or that was associated to a router certificate. To be able to separate the roles of ownership and advertiser the following extensions to the SEND protocol are defined: o A Secure Proxy ND certificate, which is a certificate authorizing an entity to act as an ND proxy. It is a X509v3 certificate in which the purpose for which the certificate is issued has been specified explicitly as described in a companion document - [I-D.ietf-csi-send-cert]. Briefly, a KeyPurposeId value is - defined for authorizing proxies. The inclusion of the proxy - authorization value allows the certificate owner to perform - proxying of SEND messages for a range of addresses indicated in - the same certificate. This certificate can be exchanged through - the Authorization Delegation Discovery process defined in - [RFC3971]. + [I-D.ietf-csi-send-cert]. Briefly, Secure Proxy ND certificates + include one or more KeyPurposeId values which can be used for + authorizing proxies to sign RA and Redirect messages, or to sign + NA, NS or RS messages on behalf or other nodes. The inclusion of + this value allows the certificate owner to perform proxying of + SEND messages for a range of addresses indicated in the same + certificate. This certificate can be exchanged through the + Authorization Delegation Discovery process defined in [RFC3971]. o A new Neighbor Discovery option called Proxy Signature (PS) option. This option contains the hash value of the public key of the proxy, and the digital signature of the SEND message computed with the private key of the proxy. The hash of the public key of the proxy is computed over the public key contained in the Secure Proxy ND's certificate. When a ND message contains a PS option, - it MUST NOT contain CGA and RSA Signature options. This option - can be appended to any ND message: NA, NS, RS, RA and Redirect. + it MUST NOT contain CGA or RSA Signature options. This option + MUST be appended to any NDP message (NA, NS, RS, RA and Redirect) + to secure it. o A modification of the SEND processing rules for all ND messages: NA, NS, RS, RA, and Redirect. When any of these messages - containing a valid Proxy Signature option is validated, it is - considered as secure. + containing a Proxy Signature option is validated, it is considered + as secure. These extensions are applied in the following way: o A Secure ND Proxy which proxies ND messages on behalf of a node can use the PS option to protect the proxied messages. This Secure ND Proxy becomes part of the trusted infrastructure just like a SEND router. o In order to allow nodes to successfully validate secured proxied - messages, the nodes must be aware of the Secure Proxy ND + messages, the nodes MUST be aware of the Secure Proxy ND certificate (in the format described in [I-D.ietf-csi-send-cert]) - and must apply the modified processing rules specified in this + and MUST apply the modified processing rules specified in this document. We call these nodes 'SPND nodes'. Note that the rules for generating ND messages in SPND nodes do not change, so these - nodes behave as defined in [RFC3971] for sending ND messages. + nodes behave as defined in [RFC3971] when they send ND messages. o To allow SPND nodes to know the certificate path required to validate the public key of the proxy, devices responding to CPS (Certification Path Solicitation) messages with CPA (Certification Path Advertisements) as defined in Section 6 of SEND specification [RFC3971] are extended to support the certificate format specified in [I-D.ietf-csi-send-cert], and are configured with the appropriate certification path. 5. Secure Proxy ND Specification A Secure ND Proxy performs all the operations described in the SEND specification [RFC3971] with the addition of new processing rules to - ensure that the receiving node can differentiate between an - authorized proxy generating or forwarding a SEND message for a - proxied address, and a malicious node doing the same. + ensure that the receiving node can identify an authorized proxy + generating a translated or synthetic SEND message for a proxied + address. - This is accomplished by signing the message with the public key of - the authorized Secure ND Proxy. The signature of the ND Proxy is + This is accomplished by signing the message with a private key of the + authorized Secure ND Proxy. The signature of the ND Proxy is included in a new option called Proxy Signature (PS) option. The - signature is performed over all the NDP options present in the - message and the PS option is appended as the last option in the - message. + signature is performed over all the Neighbor Discovery Protocol (NDP) + options present in the message and the PS option is appended as the + last option in the message. 5.1. Proxy Signature Option The Proxy Signature option allows public key-based signatures to be attached to NDP messages. The format of the PS option is described in the following diagram: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -302,173 +320,216 @@ the PKCS#1 v1.5 signature. Padding This variable-length field contains padding. The length of the padding field is determined by the length of the Proxy Signature Option minus the length of the other fields. 5.2. Modified SEND processing rules - The modifications described in the following section applies when a - SEND message contains the PS option, i.e. the message was sent by a - Secure ND Proxy. - This specification modifies the sender and receiver processing rules defined in the SEND specification [RFC3971]. 5.2.1. Processing rules for senders - A ICMPv6 message sent by a Secure ND Proxy for a proxied address MUST - contain a PS option and MUST NOT contain either CGA or RSA Signature - options. + A Secure ND Proxy MUST NOT use a key to sign NDP message types which + do not correspond to the authorization granted to the considered key. + NA, NS and RS messages MUST be signed with a key corresponding to a + Secure Proxy ND certificate with a KeyPurposeId value + [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source + addresses of the messages MUST be encompassed in the prefix + associated to the certificate. RA and Redirect messages MUST be + signed with a key corresponding to a Secure Proxy ND certificate with + a KeyPurposeId value of id-kp-sendProxiedRouter. The prefix included + in the RA message for on-link determination and/or stateless address + autoconfiguration, and the Target Address of the Redirect message, + MUST be encompassed in the prefix associated to that certificate. - A Secure ND Proxy sending a SEND message with the PS option MUST - construct the message as follows: + A secured NDP message sent by a Secure ND Proxy for a proxied address + MUST contain a PS option and MUST NOT contain either CGA or RSA + Signature options. Section 7 discusses in which cases a NDP message + has to be secured in an scenario including non-SEND nodes. + + A Secure ND Proxy sending a secured message on behalf of other node + MUST construct the message as follows: 1. The SEND message is constructed without the PS option as follows: - A. If the Secure ND Proxy is locally generating the SEND message + A. If the Secure ND Proxy is generating a synthetic SEND message for a proxied address, the message MUST be constructed as described in Neighbor Discovery for IP version 6 specification [RFC4861]. - B. If the Secure ND Proxy is forwarding a SEND message, first - the authenticity of the intercepted message MUST be verified - as specified in SEND specification [RFC3971], Section 5. If - the SEND message is valid, any CGA or RSA option MUST be - removed from the message. The intercepted message is finally - modified as described in Section 4 of the ND Proxy - specification [RFC4389]. + B. If the Secure ND Proxy is generating a translated SEND + message, first the authenticity of the intercepted message + MUST be verified as specified in SEND specification + [RFC3971], Section 5. If the SEND message is valid, any CGA + or RSA option MUST be removed from the message. The + intercepted message is finally modified as described in + Section 4 of the ND Proxy specification [RFC4389]. - C. If the Secure ND Proxy is forwarding a SEND message already + C. If the Secure ND Proxy is translating a SEND message already containing a PS option, first the authenticity of the intercepted message is verified as specified in Section 5.2.2 of this specification. If the SEND message is valid, the original PS option MUST be removed from the message. The intercepted message is finally modified as described in Section 4 of the ND Proxy specification [RFC4389]. 2. Timestamp and Nonce options MUST be included according to the rules specified in SEND [RFC3971]. The value in the Timestamp option MUST be generated by the proxy. If the proxy is - forwarding a message, the Nonce value in the proxied message MUST - be the same as in the forwarded message, otherwise it is - generated by the proxy. + translating a message which includes a Nonce, the Nonce value in + the proxied message MUST be the same as in the intercepted + message. If the proxy is synthesizing a solicitation message, + the Nonce value MUST be generated by the proxy. If the proxy is + synthesizing an advertisement message, the Nonce value MUST + correspond to the solicitation message to which the proxy is + responding. 3. The Proxy Signature option MUST be added as the last option in the message. 4. The data MUST be signed as explained in Section 5.1. 5.2.2. Processing rules for receivers Any SEND message without a Proxy Signature option MUST be treated as specified in the SEND specification [RFC3971]. A SEND message including a Proxy Signature option MUST be processed as specified below: 1. The receiver MUST ignore any RSA and CGA options, as well as any options that might come after the first PS option. The options are ignored for both signature verification and NDP processing purposes. 2. The Key Hash field MUST indicate the use of a known public key. - A valid certification path (see [RFC3971] Section 6.3) between - the receiver's trust anchor and the sender's public key MUST be - known. The Secure Proxy ND's X509v3 certificate MUST contain a - extended key usage extension including the KeyPurposeId value for - the proxy authorization. + A valid certification path (see [I-D.ietf-csi-send-cert] Section + 9) between the receiver's trust anchor and the sender's public + key MUST be known. The Secure Proxy ND's X509v3 certificate MUST + contain an extended key usage extension including the appropriate + KeyPurposeId value and prefix for the message to validate: - 3. The Digital Signature field MUST have correct encoding. + * For RA messages, a KeyPurposeId value of id-kp- + sendProxiedRouter MUST exist for the certificate, and the + prefix included in the RA message for on-link determination + and/or stateless address autoconfiguration MUST be encompassed + in the prefix associated to that certificate. + + * For Redirect messages, a KeyPurposeId value of id-kp- + sendProxiedRouter MUST exist for the certificate, and the + prefix included in the Target Address of the Redirect message + MUST be encompassed in the prefix associated to that + certificate. + + * For NA, NS and RS messages, a KeyPurposeId value of id-kp- + sendProxiedOwner MUST exist for the certificate, and the + source addresses of the messages MUST be encompassed in the + prefix associated to the certificate. + + If any of these tests fails, the verification fails. + + 3. The Digital Signature field MUST have correct encoding, otherwise + the verification of the message including the PS option fails. 4. The Digital Signature verification MUST show that the signature - has been calculated as specified in Section 5.1. + has been calculated as specified in Section 5.1, otherwise the + verification of the message including the PS option fails. 5. The Nonce option MUST be processed as specified in [RFC3971] Section 5.3.4, except for replacing 'RSA Signature option' by 'PS - option'. + option'; if these tests fail, the verification of the message + including the PS option fails. 6. The Timestamp option MUST be processed as specified in [RFC3971] Section 5.3.4, except for replacing 'RSA Signature option' by 'PS - option'. The receiver SHOULD store the peer-related timing - information specified in [RFC3971] Section 5.3.4.1 and 5.3.4.2 - (RDlast, TSlast) separately for each different proxy (which can - be identified by the different Key Hash values of the proxied - message) and separately from the timing information associated to - the IP of node for which the message is proxied. In this way, a - message received for the first time from a proxy (i.e. for which - there is no information stored in the cache) for which the - Timestamp option is checked, SHOULD be checked as messages - received from new peers (as in [RFC3971] section 5.3.4.2). + option'. If these tests fail, the verification of the message + including the PS option fails. The receiver SHOULD store the + peer-related timing information specified in [RFC3971] Section + 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each + different proxy (which could be identified by the different Key + Hash values of the proxied message) and separately from the + timing information associated to the IP address of a node for + which the message is proxied. In this way, a message received + for the first time from a proxy (i.e. for which there is no + information stored in the cache) for which the Timestamp option + is checked, SHOULD be checked as a message received from a new + peer (as in [RFC3971] section 5.3.4.2). 7. Messages with the Override bit [RFC4861] set MUST override an existing cache entry regardless if it was created as a result of a RSA Signature option or a PS option validation. When the Override bit is not set, the advertisement MUST NOT update a - cached link-layer address created securily by means of RSA + cached link-layer address created securely by means of RSA Signature option or PS option validation. - Messages that do not pass all the above tests MUST be silently - discarded if the host has been configured to accept only secured ND - messages. + Messages for which the verification fails MUST be silently discarded + if the node has been configured to accept only secured ND messages. + The messages MAY be accepted if the host has been configured to + accept both secured and unsecured messages but MUST be treated as an + unsecured message. 5.3. Proxying Link-Local Addresses Secure Neighbor Discovery [RFC3971] relies on certificates to prove that routers are authorized to announce a certain prefix. However, - Neighbor Discovery [RFC4861] states that router does not announce the + Neighbor Discovery [RFC4861] states that routers do not announce the Link-Local prefix (fe80::/64). Hence, it is not required for a SEND certificate to hold a X.509 extension for IP addresses that authorizes the fe80::/64 prefix. However, some Secure Proxy ND scenarios ([RFC4389], [RFC5213]) impose providing the proxying function for the Link-Local address of a node. When Secure ND proxy functionality for a Link-Local address is required, either a list of link-local addresses, or the fe80::/64 prefix MUST be explicitly authorized to be proxied in the corresponding certificate. 6. Application Scenarios In this section we describe three different application scenarios for which Secure Proxy ND support for SEND can be applied. Note that the particular way in which Secure Proxy ND support is applied (which ND - messages are proxied, in which directions, how the interaction with + messages are proxied, in which direction, how the interaction with non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on the particular scenario considered. In the first two scenarios presented below, ND messages are synthesized on behalf of off-link - nodes. In the third one, ND message generation is trigged by the - reception of ND messages in other interfaces of the proxy. + nodes. In the third one, ND messages are translated from the + messages received in other interfaces of the proxy. 6.1. Scenario 1: Mobile IPv6 The description of the problems for deploying SEND in this scenario - can be found in [I-D.ietf-csi-sndp-prob]. + is presented in [I-D.ietf-csi-sndp-prob]. The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN) to move from one link to another while maintaining reachability at a stable address, the so-called MN's Home Address (HoA). When a MN attaches to a foreign network, all the packets sent to the MN's HoA by a Correspondent Node (CN) on the home link or a router, are intercepted by the Home Agent (HA) on that home link, encapsulated and tunneled to the MN's registered Care-of Address (CoA). - The HA intercepts these packets acting as a ND proxy for this MN. - When a NS is intercepted on the home link, the HA checks if the - Target address within the NS matches with any of the MN's Home - Address in the Binding Cache and if so, it replies with a Neighbor - Advertisement (NA) constructed as described in [RFC4861], containing - its own link layer address (HA_LL) as the Target Link Layer Address - Option (TLLAO). Then a timestamp (generated by the proxy) and nonce - (if appropriate, according to [RFC3971]), MUST be included. Finally, - a PS option signing the message MUST be included as the last option - of the message. + To deploy Secure Proxy ND in this scenario, i.e. to secure the HA + operation, a Secure Proxy ND certificate with a KeyPurposeId value of + id-kp-sendProxiedOwner for the prefix of the home link is required. + The Secure ND Proxy is configured with the private key associated to + this certificate. When a NS is intercepted by the HA on the home + link, the HA checks if the Target address within the NS matches with + any of the MN's Home Address in the Binding Cache and if so, it + replies with a Neighbor Advertisement (NA) constructed as described + in [RFC4861], containing its own link-layer address (HA_LL) as the + Target Link Layer Address Option (TLLAO). Then a timestamp + (generated by the proxy) and nonce (if appropriate, according to + [RFC3971]), MUST be included. Finally, a PS option signing the + message MUST be included as the last option of the message. Node (N) Home Agent (HA) Mobile Node (MN) on Home Link on Home Link on Foreign Link | | | | SRC = N | | | DST = solicited_node(MN) | | | ICMPv6 NS | | | TARGET = MN | | | SLLAO = N_LL | | | [CGA] | | @@ -480,54 +541,54 @@ | ICMPv6 NA | | | TARGET = MN | | | TLLAO = HA_LL | | | PS signature | | |<-------------------------| | | | | | traffic | | | dest= MN HoA | | |------------------------->| | | | | - | | tunnelled traffic | + | | tunneled traffic | | | dest= MN CoA | | |------------------------->| | | | Figure 2: Proxy ND role of the Home agent in MIPv6 A node receiving the NA containing the PS option (e.g.: the CN in the home link, or a router) MUST apply the rules defined in Section 5.2.2. Note that in this case the Override bit of the NA - message is used to control which messages should prevail each case: - the message generated by the proxy once the MN moves from the home - network, or the MN if it comes back to the home link, as defined in - the MIPv6 specification [RFC3775] + message is used to control which messages should prevail on each + case: the message generated by the proxy when the MN moves from the + home network, or the MN if it comes back to the home link, as defined + in the MIPv6 specification [RFC3775]. 6.2. Scenario 2: Proxy Mobile IPv6 Proxy Mobile IPv6 [RFC5213] is a network-based mobility management - protocol that provides an IP mobility management support for MNs - without requiring MNs being involved in the mobility related - signaling. The IP mobility management is totally hidden to the MN in - a Proxy Mobile IPv6 domain and is performed by two functional - entities: the Local Mobility Anchor (LMA) and the Mobile Access - Gateway (MAG). + protocol that provides IP mobility management support for MNs without + requiring MNs being involved in the mobility related signaling. The + IP mobility management is totally hidden to the MN in a Proxy Mobile + IPv6 domain and it is performed by two functional entities: the Local + Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). - When the MN connects to a new access link, it will send a multicast - ICMPv6 Router Solicitation (RS). The MAG on the new access link, - upon detecting the MN's attachment, will signal the LMA for updating - the binding state of the MN (Proxy Binding Update - PBU) and once the - signaling is completed (it receives a Proxy Binding Ack - PBA), it - will reply to the MN with a ICMPv6 Router Advertisement (RA) - containing the home network prefix(es) that were assigned to that - mobility session, making the MN believe it is still on the same link - and not triggering the IPv6 address reconfiguration (Figure 3). + When the MN connects to a new access link, it sends a muliticast + Router Solicitation (RS). The MAG on the new access link, upon + detecting the MN's attachment, signals the LMA requesting an update + of the binding state of the MN (by means of a Proxy Binding Update - + PBU). Once the signaling is completed (it receives a Proxy Binding + Ack - PBA), the MAG replies to the MN with a Router Advertisement + (RA) containing the home network prefix(es) that were assigned to + that mobility session, making the MN believe it is still on the same + link, so the IPv6 address reconfiguration procedure is not triggered + (Figure 3). MN new MAG LMA | | | MN Attached | | | | | | MN Attached Event from MN/Network | | | | | SRC = MN | | | DST = all-routers | | | ICMPv6 RS | | @@ -551,65 +612,68 @@ | SLL = MAG_LL | | | PS | | |<---------------------| | | | | | | | | | | Figure 3: Mobile node's handover in PMIPv6 To avoid potential link-local address collisions between the MAG and the MN after a handoff to a new link, the Proxy Mobile IPv6 - specification requires the MAG's link-local address configured on the - link to which the MN is attached to, to be generated by the LMA when - the MN first attach to a PMIPv6 domain, and to be provided to the new - MN's serving MAG after each handoff. Thus, from the MN's point of - view, the MAG's link-local address remains constant for the duration - of that MN's session. + specification requires the MAG's link-local address on the link to + which the MN is attached to be generated by the LMA when the MN first + attaches to a PMIPv6 domain, and to be provided to the new MN's + serving MAG after each handoff. Thus, from the MN's point of view, + the MAG's link-local address remains constant for the duration of + that MN's session. The approach described above and the current SEND specification are incompatible since sharing the same link-local address on different MAGs would require all MAGs of a PMIPv6 domain to construct the CGA and the RSA Signature option with the same public-private key pair, - which is not acceptable from a security point of view. + which is not an acceptable security policy. Using different public-private key pairs on different MAGs would mean different MAGs use different CGAs as link-local address. Thus the - serving MAG's link-local address changes after each handoff of the MN - which is contradiction with the way MAG link-local address assignment - occurs in a PMIPv6 domain. + serving MAG's link-local address would change after each handoff of + the MN, which is in contradiction with the way MAG link-local address + assignment occurs in a PMIPv6 domain. - To provide SEND protection, each MAG is configured to act as a proxy - by means of a certificate associated to the PMIPv6 domain, - authorizing each MAG to proxy securely ND messages. In addition, the - certificate must also authorize the MAG to advertise prefixes. Note - that the inclusion of multiple KeyPurposeId values is supported by - [I-D.ietf-csi-send-cert]. + To provide SEND protection, each MAG MUST be configured to act as a + proxy by means of a certificate associated to the PMIPv6 domain, + authorizing each MAG to proxy securely NA and RS messages by means of + a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the + certificate MUST also authorize the MAG to advertise prefixes by + associating to the same certificate a KeyPurposeId value of id-kp- + sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId + values is supported by [I-D.ietf-csi-send-cert]. When a MAG replies to a RS with a RA, the source address MUST be equal to the MAG link-local address associated to the MN in this - PMIPv6 domain and its own link layer address as Source link-layer + PMIPv6 domain, with its own link-layer address as Source link-layer address. Then a timestamp (generated by the proxy) and nonce (if appropriate, according to [RFC3971]), MUST be included. Finally, a PS option signing the message MUST be included as the last option of the message. This procedure is followed for any other ND message - that could be generated by the MAG to a MN. + that could be generated by the MAG to the MN. A node receiving a message from the MAG containing the PS option MUST - apply the rules defined in Section 5.2.2. Note that unsolicited - messages sent by MAG are validated by the host according to timestamp - values specific to the MAG serving the link, not to any other MAG to - which the host has been connected before in other links. + apply the processing rules defined in Section 5.2.2. Note that + unsolicited messages sent by the MAG should be validated by the host + according to timestamp values specific to the MAG serving the link, + not to any other MAG to which the host has been connected before in + other links, according to processing step number 6 of Section 5.2.2. 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy The description of the problems for deploying SEND in this scenario - can be found in [I-D.ietf-csi-sndp-prob]. + is presented in [I-D.ietf-csi-sndp-prob]. Link 1 Link 2 Host A ND Proxy (P) Host B | | | | SRC = A | | | DST = solicited_node(B) | | | ICMPv6 NS | | | TARGET = B | | | SLLAO = A_LL | | @@ -628,238 +692,289 @@ | | TLLAO = B_LL | | |<-------------------------| | SRC = B | | | DST = A | | | ICMPv6 NA | | | TARGET = B | | | TLLAO = P_LL | | |<-------------------------| | | | | - Figure 4: Proxy ND operations + Figure 4: RFC 4389 Neighbor Discovery Proxy operation The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a - method by which multiple link layer segments are bridged into a + method by which multiple link-layer segments are bridged into a single segment and specifies the IP-layer support that enables bridging under these circumstances. - A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy - interface to check whether it contains one of the following secured - ICMPv6 messages: NS, NA, RA, or Redirect. The Secure ND Proxy MUST + A Secure ND Proxy MUST parse any IPv6 packet it receives on a proxy + interface to check whether it contains one of the following NDP + messages: NS, NA, RS, RA, or Redirect. The Secure ND Proxy MUST verify the authenticity of the received ND message, according to [RFC3971]. If the SEND message is valid, then it proxies the original message with the following changes: 1. The message MUST be processed according to [RFC4389]. This - includes changing the source link layer address to the address of - the outgoing interface, maintaining the destination link layer + includes changing the source link-layer address to the address of + the outgoing interface, maintaining the destination link-layer address as the address in the neighbor entry corresponding to the - destination IPv6 address, etc. In particular any link layer + destination IPv6 address, etc. In particular any link-layer address within the payload (that is, in a Source Local Link Address option - SLLAO, or a Target Local Link Address option - TLLAO) is substituted with the link-layer address of the outgoing interface. 2. Any CGA or RSA option MUST be removed. 3. If a Nonce option existed in the original message, its value MUST be preserved in the proxied message. The Timestamp MUST be generated by the proxy. 4. The PS option MUST be added as the last option in the message, - signing all the information contained so far in the message. + signing all the information contained so far in the message. To + be able to sign any NS, NA, RS, RA o Redirect message, the key + used must correspond to a certificate with KeyPurposeId values of + id-kp-sendProxiedOwner and id-kp-sendProxiedRouter. When any other IPv6 unicast packet is received on a proxy interface, if it is not locally destined then it is forwarded unchanged (other than using a new link-layer header) to the proxy interface for which - the next hop address appears in the neighbor cache. If no neighbor - cache entry is present, the ND proxy should queue the packet and - initiate a Neighbor Discovery signalling as if the ICMPv6 NS message - were locally generated. + the next-hop address appears in the neighbor cache. If no neighbor + cache entry is present, the Secure ND Proxy SHOULD queue the packet + and initiate a Neighbor Discovery signaling as if the NS message were + locally generated. In order to deploy this scenario, nodes in proxied segments MUST know the certificate authorizing proxy operation. To do so it could be required to configure at least one device per each proxied segment (may be the proxy itself) to propagate the required certification path to authorize proxy operation by means of a CPS/CPA exchange. 7. Backward Compatibility with RFC3971 nodes and non-SEND nodes In this section we discuss the interaction of Secure ND Proxies and - SPND nodes with RFC3971 nodes and non-SEND nodes. + SPND nodes with RFC3971 nodes and non-SEND nodes. As stated in + [RFC3971], network operators may want to run a mixture of nodes + accepting secured and unsecured NDP messages at the same time. + Secure ND Proxies and SPND nodes SHOULD support the use of secured + and unsecured NDP messages at the same time. 7.1. Backward Compatibility with RFC3971 nodes RFC3971 nodes, i.e. SEND nodes not compliant with the modifications - required in Section 5 cannot interpret correctly a PS option received - in a proxied ND message. These SEND nodes silently discard the PS - option, as specified in [RFC4861] for any unknown option. As a - result, these messages will be treated as unsecured as described in + required in Section 5, cannot interpret correctly a PS option + received in a proxied ND message. These SEND nodes silently discard + the PS option, as specified in [RFC4861] for any unknown option. As + a result, these messages will be treated as unsecured as described in Section 8 "Transitions Issues" of the SEND specification [RFC3971]. When RFC3971 nodes and SPND nodes exchange ND messages (without proxy intervention), in either direction, messages are generated according to the SEND specification [RFC3971], so these nodes interoperate seamlessly. In the scenarios in which the proxy translates ND messages, the messages to translate can either be originated in a RFC3971 node or - in an SPND node, without interoperability issues. + in an SPND node, without interoperability issues (note that the + difference between RFC3971 nodes and SPND nodes only affect to the + ability to process received NDP messages containing a PS option, not + in the way they generate messages secured by SEND). 7.2. Backward Compatibility with non-SEND nodes Non-SEND nodes receiving NDP packets silently discard PS options, as specified in [RFC4861] for any unknown option. Therefore, these nodes interpret messages proxied by a Secure ND Proxy as any other ND message. When non-SEND nodes and SPND nodes exchange ND messages (without proxy intervention), in either direction, the rules specified in section 8 of [RFC3971] apply. A Secure ND Proxy SHOULD support the use of secured and unsecured NDP messages at the same time, although it MAY have a configuration that - causes not to perform proxing for unsecured NDP messages. A Secure + causes not to perform proxying for unsecured NDP messages. A Secure ND Proxy MAY also have a configuration option whereby it disables secure ND proxying completely. This configuration SHOULD be switched - off by default, that is SEND is used by default. In the next + off by default, that is security is provided by default. In the next paragraphs we discuss the recommended behavior of the Secure ND Proxy regarding to the protection level to provide to proxied messages in a mixed scenario involving SPND/RFC3971 nodes and non-SEND nodes. In particular, two different situations occur depending on if the proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes. As a rule of thumb, if the proxied nodes can return to the link in which the proxy operates, the Secure ND Proxy MUST only generate PS options on behalf of nodes with SEND capabilities (i.e. that they - could use SEND to defend their messages if being in the same link - than the proxy, either RFC3971 nodes or SPND nodes). This is - relevant to allow nodes preferring secured information over unsecured - one, and for executing the DAD procedure, as specified in [RFC3971]. - Therefore, the Secure ND Proxy MUST generate messages containing the - PS option for SPND and RFC3971 hosts, and MUST NOT generate messages + could use SEND to defend their messages if present on the same link + as the proxy, i.e. being either RFC3971 nodes or SPND nodes). This + is relevant to allow nodes to prefer secured information over + unsecured one, and to properly execute the DAD procedure, as + specified in [RFC3971]. Therefore, in this case the Secure ND Proxy + MUST synthesize/translate messages containing the PS option for SPND + and RFC3971 hosts, and MUST NOT synthesize/translate messages containing the PS option for non-SEND nodes. Note that ND advertisements in response to solicitations generated by a Secure ND Proxy must be secured or not according to the previous considerations (i.e. to the nature of the proxied node), and not according to the secure or unsecure nature of the solicitation message. - To apply this rule, we have to consider that depending on the - application scenario the proxy may translate ND messages generated by - a node or synthetise ND messages on behalf of a node that can return - to the link in which the Secure ND Proxy operates. + In order to apply this rule, the Secure ND Proxy needs to know the + security capabilities of the proxied node. The way this information + is acquired depends on the application scenario, and it is discussed + next: - o For translating ND messages for nodes that can arrive to the link - in which the proxy operates, the rule can be easily applied: only - messages validated in the Secure ND Proxy according to the SEND - specification [RFC3971] MUST be proxied securely by the inclusion - of a PS option. Unsecured ND messages could be proxied if - unsecured operation is enabled in the proxy, but the message - generated by the Secure ND Proxy for the received message MUST NOT - include a PS option. + o For scenarios in which ND messages are translated for nodes that + can arrive to the link in which the proxy operates, the rule can + be easily applied: only for messages validated in the Secure ND + Proxy according to the SEND specification [RFC3971], or according + to Section 5.2.2 of this specification for messages containing a + PS option (which means that another proxy previously checked that + the original message was secured), the message MUST be proxied + securely by the inclusion of a PS option. Unsecured ND messages + could be proxied if unsecured operation is enabled in the proxy, + but the message generated by the Secure ND Proxy for the received + message MUST NOT include a PS option. - o For synthesizing ND messages on behalf of remote nodes, different - considerations should be made according to the particular - application scenario. + o For scenarios in which ND messages are synthesized on behalf of + remote nodes, different considerations should be made according to + the particular application scenario. * For MIPv6, if the MN can return to the home link, it is required for the proxy to know if the node could use SEND to - defend its address or not. A mismatch between the proxy and - proxied node behavior regarding to SEND operation would result - in unaproppriate operation. A HA including the PS option for + defend its address or not. A HA including the PS option for proxying a non-SEND MN would make ND messages sent by the proxy - to be more preferred than ND message of the non-SEND MN when + to be more preferred than a ND message of the non-SEND MN when the MN returns to the home link (even if the proxied messages have the Override bit set to 1). Not using the PS option for a - RFC3971 or SPND MN would make more vulnerable the address in - the home link when the MN is away than when it is in the home - link (and would defeat the purpose of the Secure Proxy ND - mechanism). Therefore, in this case the HA MUST know the SEND - capabilities of the MN, and MUST use PS option if the MN is a - SPND or RFC3971 host, and MUST NOT use PS option for non-SEND - hosts. + RFC3971 or SPND MN would make the address in the home link more + vulnerable when the MN is away than when it is in the home + link, defeating the purpose of the Secure Proxy ND mechanism. + Therefore, in this case the HA MUST know the SEND capabilities + of the MN, MUST use the PS option if the MN is a SPND or + RFC3971 host, and MUST NOT use PS option for non-SEND hosts. - * For the Proxy Mobile IPv6 scenario, we have to note that a node - moving from a link in which PS option has been used to protect - a link-layer address to a link in which ND messages are not - protected by SEND would prevent the MN from adquiring the new - information until the cached information expires. However, in - this case it is reasonable to consider that all MAGs provide - the same security for protecting ND messages, and that either - all MAGs will behave as Secure ND Proxy, or none, so - configuration could be easier. + * For the Proxy Mobile IPv6 scenario, a node moving from a link + in which PS option has been used to protect a link-layer + address to a link in which ND messages are not protected by + SEND would prevent the MN from adquiring the new information + until the cached information expires. However, in this case it + is reasonable to consider that all MAGs provide the same + security for protecting ND messages, and that either all MAGs + will behave as Secure ND Proxy, or none, so configuration is + expected to be easier. 8. Security Considerations The mechanism described in this document introduces a new Proxy - Signature (PS) Option allowing a Secure ND Proxy to generate or - modify a SEND message for a proxied address. A SPND node will only - accept such a message if it includes a valid PS option generated by - an authorized Secure ND Proxy. Such a message has equivalent - protection to the threats presented in section 9 of [RFC3971] as a - message signed with a RSA Signature option. + Signature (PS) option allowing a Secure ND Proxy to synthesize or + translate a SEND message for a proxied address, to Redirect traffic + for given target addresses or to advertise prefix information by + means of RA messages. A SPND node only accepts such a message if it + includes a valid PS option generated by a properly authorized Secure + ND Proxy (with a certificate containing a KeyPurposeId with value id- + kp-sendProxiedOwner for protecting NA, NS and RS messages, or + containing a KeyPurposeId value of id-kp-sendProxiedRouter for + protecting RA and Redirect messages). Such a message has equivalent + protection against the threats presented in section 9 of [RFC3971] as + a message signed with a RSA Signature option. The security of proxied ND messages not including a PS option is the - same of an unsecured ND message. The security of a proxied ND - message received by a non-SEND host or RFC3971 host is the same of an + same as an unsecured ND message. The security of a proxied ND + message received by a non-SEND host or RFC3971 host is the same as an unsecured ND message. - Thanks to the authorization certificate it is provisioned with, a - proxy ND is authorized to issue ND signaling on behalf of nodes on - the subnet. Thus, a compromised proxy is able, like a compromised - router, to siphon off traffic from the host, or mount a man-in-the- - middle attack. However, when two on-link hosts communicate using - their respective link-local addresses, the threats involved with a - compromised router and a compromised proxy ND differs because the - router is not able to siphon off traffic exchanged between the hosts - or mount a man-in-the-middle attack, while the proxy ND can, even if - the hosts use SEND. + When a message including a PS option is received by a SPND node, any + CGA or RSA options also included in the message are removed and the + remaining message further processed. Altough properly formed proxied + messages MUST NOT include at the same time PS and CGA/RSA options, + discarding them if they appear does not affect to the security. If + the PS option is validated, then the information included in the + message has been validly generated by a proxy, and should be honored + (remember that anti-replay protection is provided by means of nonce + and timestamp options). If the PS option is not validated, then it + is treated as an unsecured message. In any case, there is no gain + for an attacker from appending false or old CGA/RSA information to a + message secured by a Secure ND Proxy. - The messages for which a Secure ND Proxy performs its function, and + A compromised Secure ND Proxy provisioned with an authorization + certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is + able, like a compromised router to siphon off traffic from the host, + or mount a man-in-the-middle attack, for hosts communicating to off- + link hosts. A compromised Secure ND Proxy provisioned with an + authorization certificate with a KeyPurposeId value of id-kp- + sendProxiedOwner can siphon off traffic or mount a man-in-the-middle + attack for communication between on-link hosts, even if the hosts use + SEND. Note that different application scenarios may require one type + of authorization, the other, or both. To minimize security risks, + authorization capabilities SHOULD NOT exceed the ones strictly + required by the application scenario to be deployed. + + The messages for which a Secure ND Proxy performs its function and the link for which this function is performed MUST be configured appropriately for each proxy and scenario. This configuration is specially relevant if Secure Proxy ND is used for translating ND messages from one link to another. - Proper configuration of when the PS option must or must not be - included, depending on the proxied nodes being SEND or non-SEND may - result in security considerations which are discussed in Section 7. + Section 7 discusses the security considerations resulting from the + decision of appending or omitting the PS option depending on the + SEND-awareness of the proxied nodes. - Attacks to the timestamp of the secured ND message can be performed - as described in section 7.3 of [I-D.ietf-csi-sndp-prob]. + Protection against replay attacks from unsolicited messages such as + NA, RA, and Redirects is provided by means of the Timestamp option. + When Secure ND Proxy is used, each proxy and the host for which a + proxy acts on behalf are considered to be different peers in terms of + Timestamp verification. Since the information provided by the host + and a proxy maybe different, including different link-layer + addresses, a replay attack could affect the operation of a third + node: replaying messages issued by a host that is no longer in the + link can prevent the use of a proxy, and replaying messages of a + proxy when the host is back in the link can prevent communication + with the host. This kind of attacks can be performed until the + timestamp of the peer (either the host or a proxy) is no longer valid + for the receiver. The window of vulnerability is in general larger + for the first message received from a new peer than for subsequent + messages received from the same peer (see [RFC3971]). A more + detailed analysis of the possible attacks related with the Timestamp + option is described in section 7.3 of [I-D.ietf-csi-sndp-prob]. 9. IANA Considerations IANA is requested to allocate: A new IPv6 Neighbor Discovery Option type for the PS option, as TBA. The value need to be allocated from the namespace specified in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at http://www.iana.org/assignments/icmpv6-parameters. A new 128-bit value under the CGA Message Type [RFC3972] namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. 10. Acknowledgements The text has benefited from feedback provided by Jari Arkko, Jean- - Michel Combes, Roque Gagliano, Tony Cheneau and Marcelo Bagnulo. + Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey + Melnikov and Sandra Murphy. + + The work of Alberto Garcia-Martinez was supported in part by T2C2 + project (TIN2008-06739-C04-01, granted by the Spanish Science and + Innovation Ministry). 11. References 11.1. Normative References [I-D.ietf-csi-send-cert] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate profile and certificate management for SEND", - draft-ietf-csi-send-cert-03 (work in progress), - March 2010. + draft-ietf-csi-send-cert-07 (work in progress), + September 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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.