draft-ietf-csi-proxy-send-05.txt   rfc6496.txt 
CGA & SEND maintenance Working S. Krishnan Internet Engineering Task Force (IETF) S. Krishnan
Group Ericsson Request for Comments: 6496 Ericsson
Internet-Draft J. Laganier Category: Experimental J. Laganier
Intended status: Experimental QUALCOMM Inc. ISSN: 2070-1721 Juniper Networks
Expires: April 1, 2011 M. Bonola M. Bonola
Rome Tor Vergata University Rome Tor Vergata University
A. Garcia-Martinez A. Garcia-Martinez
UC3M UC3M
September 28, 2010 February 2012
Secure Proxy ND Support for SEND Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
draft-ietf-csi-proxy-send-05
Abstract Abstract
Secure Neighbor Discovery (SEND) specifies a method for securing SEcure Neighbor Discovery (SEND) specifies a method for securing
Neighbor Discovery (ND) signaling against specific threats. As Neighbor Discovery (ND) signaling against specific threats. As
defined today, SEND assumes that the node sending a ND message is the defined today, SEND assumes that the node sending an ND message is
owner of the address from which the message is sent and/or posses a the owner of the address from which the message is sent and/or
key which authorizes the node to act as a router, so that it is in possesses a key that authorizes the node to act as a router, so that
possession of the private key or keys used to generate the digital it is in possession of the private key or keys used to generate the
signature on each message. This means that the Proxy ND signaling digital signature on each message. This means that the Proxy ND
performed by nodes that do not possess knowledge of the address signaling performed by nodes that do not possess knowledge of the
owner's private key and/or knowledge of a router's key cannot be address owner's private key and/or knowledge of a router's key cannot
secured using SEND. This document extends the current SEND be secured using SEND. This document extends the current SEND
specification in order to secure Proxy ND operation. specification in order to secure Proxy ND operation.
Status of this Memo 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 This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on April 1, 2011. 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/rfc6496.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation ...........................................3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology .....................................................3
4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6 4. Secure Proxy ND Overview ........................................4
5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8 5. Secure Proxy ND Specification ...................................5
5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8 5.1. Proxy Signature Option .....................................6
5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10 5.2. Modified SEND Processing Rules .............................8
5.2.1. Processing rules for senders . . . . . . . . . . . . . 10 5.2.1. Processing Rules for Senders ........................8
5.2.2. Processing rules for receivers . . . . . . . . . . . . 11 5.2.2. Processing Rules for Receivers ......................9
5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 13 5.3. Proxying Link-Local Addresses .............................11
6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 14 6. Application Scenarios ..........................................11
6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 14 6.1. Scenario 1: Mobile IPv6 ...................................11
6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 15 6.2. Scenario 2: Proxy Mobile IPv6 .............................13
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 18 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy .............16
7. Backward Compatibility with RFC3971 nodes and non-SEND 7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes ..17
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Backward Compatibility with RFC 3971 Nodes ................17
7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 20 7.2. Backward Compatibility with Non-SEND Nodes ................18
7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 20 8. Security Considerations ........................................20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations ............................................22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements ..............................................22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 11. References ....................................................22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References .....................................22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References ...................................23
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 1. Introduction
Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for SEcure Neighbor Discovery (SEND) [RFC3971] specifies a method for
securing Neighbor Discovery (ND) signaling [RFC4861] against specific securing Neighbor Discovery (ND) signaling [RFC4861] against specific
threats [RFC3756]. As defined today, SEND assumes that the node threats [RFC3756]. As defined today, SEND assumes that the node
sending a ND message is the owner of the address from which the sending an ND message is the owner of the address from which the
message is sent and/or posses a key which authorizes the node to act message is sent and/or possesses a key that authorizes the node to
as a router, so that it is in possession of the private key or keys act as a router, so that it is in possession of the private key or
used to generate the digital signature on each message. This means keys used to generate the digital signature on each message. This
that the Proxy ND signaling performed by nodes that do not possess means that the Proxy ND signaling performed by nodes that do not
knowledge of the address owner's private key and/or knowledge of a possess knowledge of the address owner's private key and/or knowledge
router's key cannot be secured using SEND. of a router's key cannot be secured using SEND.
This document extends the current SEND specification with support for 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. From this point on, we refer to such an extension as
Proxy ND Support for SEND". "Secure Proxy ND Support for SEND".
2. 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].
3. Terminology 3. Terminology
Secure ND Proxy Secure ND Proxy
A node authorized to secure a Neighbor Discovery Protocol (NDP) A node acting on behalf of another node and authorized to secure a
message without knowing the private key related to the source Neighbor Discovery Protocol (NDP) message without knowing the
address of the node, or the key related to the router private key related to the source address of the other node or the
authorization, for which the node acts on behalf. key related to the router authorization.
Proxied IPv6 address Proxied IPv6 address
An IPv6 address that does not belong to the Secure ND Proxy and An IPv6 address that does not belong to the Secure ND Proxy and
for which the Secure ND Proxy is performing advertisements. for which the Secure ND Proxy is performing advertisements.
Non-SEND node Non-SEND node
An IPv6 node that does not implement the SEND [RFC3971] An IPv6 node that does not implement the SEND [RFC3971]
specification but uses the ND protocol defined in [RFC4861] and specification but uses the ND protocol defined in [RFC4861] and
[RFC4862], without additional security. [RFC4862], without additional security.
RFC3971 node RFC 3971 node
An IPv6 node that does not implement the specification defined in An IPv6 node that does not implement the specification defined in
this document for Secure Proxy ND support, but uses the SEND this document for Secure Proxy ND support but uses the SEND
specification as defined in [RFC3971]. specification as defined in [RFC3971].
SPND node Secure Proxy ND (SPND) node
An IPv6 node that receives and validates messages according to the An IPv6 node that receives and validates messages according to the
specification defined in this document for Secure Proxy ND specification defined in this document for Secure Proxy ND
support. support.
Translated NDP message Translated NDP message
A NDP message issued by a Secure ND Proxy as a result of a An NDP message issued by a Secure ND Proxy as a result of a
received NDP message originated by the owner of the address or received NDP message originated by the owner of the address or
originated by another node acting on behalf of the owner of the originated by another node acting on behalf of the owner of the
address. address.
Synthetic NDP message Synthetic NDP message
A NDP message issued by a Secure ND Proxy that is not the result An NDP message issued by a Secure ND Proxy that is not the result
of a received NDP message. of a received NDP message.
4. Secure Proxy ND Overview 4. Secure Proxy ND Overview
The original SEND specification [RFC3971] has implicitly assumed that The original SEND specification [RFC3971] has implicitly assumed that
only the node sending a ND message is the owner of the address from only the node sending an ND message is the owner of the address from
which the message is sent. This assumption does not allow proxying which the message is sent. This assumption does not allow proxying
of ND messages since the advertiser is required to generate a valid of ND messages, since the advertiser is required to generate a valid
RSA Signature option, which in turns requires possession of the RSA Signature option, which in turn requires possession of the
public-private key pair that was used to generate a CGA, or that was public-private key pair that was used to generate a Cryptographically
associated to a router certificate. Generated Address (CGA), or that was associated to a router
certificate.
To be able to separate the roles of ownership and advertiser the To be able to separate the roles of owner and advertiser, the
following extensions to the SEND protocol are defined: following extensions to the SEND protocol are defined:
o A Secure Proxy ND certificate, which is a certificate authorizing 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 an entity to act as an ND proxy. It is an X.509v3 certificate in
which the purpose for which the certificate is issued has been which the purpose for which the certificate is issued has been
specified explicitly as described in a companion document specified explicitly, as described in a companion document
[I-D.ietf-csi-send-cert]. Briefly, Secure Proxy ND certificates [RFC6494]. Briefly, Secure Proxy ND certificates include one or
include one or more KeyPurposeId values which can be used for more KeyPurposeId values that can be used for authorizing proxies
authorizing proxies to sign RA and Redirect messages, or to sign to sign Router Advertisement (RA) and Redirect messages, or to
NA, NS or RS messages on behalf or other nodes. The inclusion of sign Neighbor Advertisement (NA), Neighbor Solicitation (NS), or
this value allows the certificate owner to perform proxying of Router Solicitation (RS) messages on behalf of other nodes. The
SEND messages for a range of addresses indicated in the same inclusion of this value allows the certificate owner to perform
certificate. This certificate can be exchanged through the proxying of SEND messages for a range of addresses indicated in
Authorization Delegation Discovery process defined in [RFC3971]. 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) o A new Neighbor Discovery option called the Proxy Signature (PS)
option. This option contains the hash value of the public key of option. This option contains the hash value of the public key of
the proxy, and the digital signature of the SEND message computed 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 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 the proxy is computed over the public key contained in the Secure
Proxy ND's certificate. When a ND message contains a PS option, Proxy ND certificate. When an ND message contains a PS option, it
it MUST NOT contain CGA or RSA Signature options. This option MUST NOT contain CGA or RSA Signature options. The PS option MUST
MUST be appended to any NDP message (NA, NS, RS, RA and Redirect) be appended to any NDP message (NA, NS, RS, RA, and Redirect) to
to secure it. secure it.
o A modification of the SEND processing rules for all ND messages: o A modification of the SEND processing rules for all ND messages:
NA, NS, RS, RA, and Redirect. When any of these messages NA, NS, RS, RA, and Redirect. When any of these messages
containing a Proxy Signature option is validated, it is considered containing a PS option is validated, it is considered secure.
as secure.
These extensions are applied in the following way: These extensions are applied in the following way:
o A Secure ND Proxy which proxies ND messages on behalf of a node o A Secure ND Proxy that proxies ND messages on behalf of a node can
can use the PS option to protect the proxied messages. This use the PS option to protect the proxied messages. This Secure ND
Secure ND Proxy becomes part of the trusted infrastructure just Proxy becomes part of the trusted infrastructure just like a SEND
like a SEND router. router.
o The messages to be secured with the PS option are built according
to [RFC4861] if they are synthesized by the Secure ND Proxy, or
they result from the processing rules defined in [RFC4389] if they
are translated ND messages.
o In order to allow nodes to successfully validate secured proxied 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]) certificate (in the format described in [RFC6494]) and MUST apply
and MUST apply the modified processing rules specified in this the modified processing rules specified in this document. We call
document. We call these nodes 'SPND nodes'. Note that the rules these nodes 'SPND nodes'. Note that the rules for generating ND
for generating ND messages in SPND nodes do not change, so these messages in SPND nodes do not change, so these nodes behave as
nodes behave as defined in [RFC3971] when they send ND messages. defined in [RFC3971] when they send ND messages.
o To allow SPND nodes to know the certificate path required to o To allow SPND nodes to know the certification path required to
validate the public key of the proxy, devices responding to CPS validate the public key of the proxy, devices responding to CPS
(Certification Path Solicitation) messages with CPA (Certification (Certification Path Solicitation) messages with CPA (Certification
Path Advertisements) as defined in Section 6 of SEND specification Path Advertisement) messages as defined in Section 6 of the SEND
[RFC3971] are extended to support the certificate format specified specification [RFC3971] are extended to support the certificate
in [I-D.ietf-csi-send-cert], and are configured with the format specified in [RFC6494], and are configured with the
appropriate certification path. appropriate certification path.
5. Secure Proxy ND Specification 5. Secure Proxy ND Specification
A Secure ND Proxy performs all the operations described in the SEND A Secure ND Proxy performs all the operations described in the SEND
specification [RFC3971] with the addition of new processing rules to specification [RFC3971] with the addition of new processing rules to
ensure that the receiving node can identify an authorized proxy ensure that the receiving node can identify an authorized proxy
generating a translated or synthetic SEND message for a proxied generating a translated or synthetic SEND message for a proxied
address. address.
This is accomplished by signing the message with a private key of the This is accomplished by signing the message with a private key of the
authorized Secure ND Proxy. The signature of the ND Proxy is authorized Secure ND Proxy. The signature of the Secure ND Proxy is
included in a new option called Proxy Signature (PS) option. The included in a new option called the PS option. The signature is
signature is performed over all the Neighbor Discovery Protocol (NDP) performed over all the Neighbor Discovery Protocol (NDP) options
options present in the message and the PS option is appended as the present in the message, and the PS option is appended as the last
last option in the message. option in the message.
5.1. Proxy Signature Option 5.1. Proxy Signature Option
The Proxy Signature option allows public key-based signatures to be The Proxy Signature option allows signatures based on public keys to
attached to NDP messages. The format of the PS option is described be attached to NDP messages. The format of the PS option is
in the following diagram: described in the following diagram:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key Hash | | Key Hash |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Digital Signature . . Digital Signature .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PS option layout Figure 1: PS Option Layout
Type Type
TBA 32
Length Length
The length of the option (including the Type, Length, Reserved, The length of the option (including the Type, Length, Reserved,
Key Hash, Digital Signature, and Padding fields) in units of 8 Key Hash, Digital Signature, and Padding fields) in units of
octets. 8 octets.
Reserved Reserved
A 16-bit field reserved for future use. The value MUST be A 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
Key Hash Key Hash
A 128-bit field containing the most significant (leftmost) 128 A 128-bit field containing the most significant (leftmost)
bits of a SHA-1 [SHA1] hash of the public key used for 128 bits of a SHA-1 [SHA1] hash of the public key used for
constructing the signature. Its purpose is to associate the constructing the signature. Its purpose is to associate the
signature to a particular key known by the receiver. Such a key signature to a particular key known by the receiver. Such a key
MUST be the same one within the corresponding Secure Proxy ND's MUST be the same one within the corresponding Secure Proxy ND
certificate. certificate.
Digital Signature Digital Signature
A variable-length field containing a PKCS#1 v1.5 signature, A variable-length field containing a PKCS#1 v1.5 signature,
constructed by using the sender's private key over the following constructed by using the sender's private key over the following
sequence of octets: sequence of octets:
1. The 128-bit CGA Message Type tag [RFC3972] value for Secure 1. The 128-bit CGA Message Type tag [RFC3972] value for Secure
Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. (The tag
value has been generated randomly by the editor of this value has been generated randomly by the editor of this
specification). specification.)
2. The 128-bit Source Address field from the IP header. 2. The 128-bit Source Address field from the IP header.
3. The 128-bit Destination Address field from the IP header. 3. The 128-bit Destination Address field from the IP header.
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from
the ICMP header. the ICMP header.
5. The NDP message header, starting from the octet after the ICMP 5. The NDP message header, starting from the octet after the ICMP
Checksum field and continuing up to but not including NDP Checksum field and continuing up to, but not including, NDP
options. options.
6. All NDP options preceding the Proxy Signature option. 6. All NDP options preceding the Proxy Signature option.
The signature value is computed with the RSASSA-PKCS1-v1_5 The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash, as defined in [RSA]. algorithm and SHA-1 hash, as defined in [RSA]. This field starts
after the Key Hash field. The length of the Digital Signature
This field starts after the Key Hash field. The length of the field is determined by the ASN.1 BER coding of the PKCS#1 v1.5
Digital Signature field is determined by the ASN.1 BER coding of signature.
the PKCS#1 v1.5 signature.
Padding Padding
This variable-length field contains padding. The length of the This variable-length field contains padding. The length of the
padding field is determined by the length of the Proxy Signature padding field is determined by the length of the Proxy Signature
Option minus the length of the other fields. option minus the length of the other fields.
5.2. Modified SEND processing rules 5.2. Modified SEND Processing Rules
This specification modifies the sender and receiver processing rules This specification modifies the sender and receiver processing rules
defined in the SEND specification [RFC3971]. defined in the SEND specification [RFC3971].
5.2.1. Processing rules for senders 5.2.1. Processing Rules for Senders
A Secure ND Proxy MUST NOT use a key to sign NDP message types which A Secure ND Proxy MUST NOT use a key to sign NDP message types that
do not correspond to the authorization granted to the considered key. 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 NA, NS, and RS messages MUST be signed with a key corresponding to a
Secure Proxy ND certificate with a KeyPurposeId value Secure Proxy ND certificate with a KeyPurposeId value [RFC6494] of
[I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source id-kp-sendProxiedOwner, and the source addresses of the messages MUST
addresses of the messages MUST be encompassed in the prefix be encompassed in the prefix associated to the certificate. RA and
associated to the certificate. RA and Redirect messages MUST be Redirect messages MUST be signed with a key corresponding to a Secure
signed with a key corresponding to a Secure Proxy ND certificate with Proxy ND certificate with a KeyPurposeId value of
a KeyPurposeId value of id-kp-sendProxiedRouter. The prefix included id-kp-sendProxiedRouter. The prefix included in the RA message for
in the RA message for on-link determination and/or stateless address on-link determination and/or stateless address autoconfiguration, and
autoconfiguration, and the Target Address of the Redirect message, the Target Address of the Redirect message, MUST be encompassed in
MUST be encompassed in the prefix associated to that certificate. the prefix associated to that certificate.
A secured NDP message sent by a Secure ND Proxy for a proxied address 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 MUST contain a PS option and MUST NOT contain either CGA or RSA
Signature options. Section 7 discusses in which cases a NDP message Signature options. Section 7 discusses in which cases an NDP message
has to be secured in an scenario including non-SEND nodes. has to be secured in a 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: The input of this process is a message obtained in either of the
following ways:
A. If the Secure ND Proxy is generating a synthetic SEND message a. If the Secure ND Proxy generates synthetic SEND messages for a
for a proxied address, the message MUST be constructed as proxied address, the message MUST be constructed as described in
described in Neighbor Discovery for IP version 6 the Neighbor Discovery for IP version 6 specification [RFC4861].
specification [RFC4861].
B. If the Secure ND Proxy is generating a translated SEND b. If the Secure ND Proxy translates secured messages, first the
message, first the authenticity of the intercepted message authenticity of the intercepted message MUST be verified. If the
MUST be verified as specified in SEND specification intercepted message is a SEND message, it MUST be validated as
[RFC3971], Section 5. If the SEND message is valid, any CGA specified in Section 5 of the SEND specification [RFC3971]. If
or RSA option MUST be removed from the message. The the intercepted message contains a PS option, the authenticity of
intercepted message is finally modified as described in the message MUST be verified as detailed in Section 5.2.2 of this
Section 4 of the ND Proxy specification [RFC4389]. specification. After validation, the CGA, RSA, or PS options of
the original message MUST be removed. Then, the message to be
translated MUST be processed according to the ND Proxy
specification [RFC4389]. In this way, it is determined whether
the message received should be proxied or not; the proxy
interface status is updated if needed, the outgoing interface is
determined, the link-layer header and the link-layer address
within the payload are modified if required, etc.
C. If the Secure ND Proxy is translating a SEND message already A Secure ND Proxy then modifies the input message as follows:
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 1. Timestamp and Nonce options MUST be included according to the
rules specified in SEND [RFC3971]. The value in the Timestamp rules specified in SEND [RFC3971]. The value in the Timestamp
option MUST be generated by the proxy. If the proxy is option MUST be generated by the proxy. If the proxy is
translating a message which includes a Nonce, the Nonce value in translating a message that includes a nonce, the Nonce value in
the proxied message MUST be the same as in the intercepted the proxied message MUST be the same as in the intercepted
message. If the proxy is synthesizing a solicitation message, message. If the proxy is synthesizing a solicitation message,
the Nonce value MUST be generated by the proxy. If the proxy is the Nonce value MUST be generated by the proxy. If the proxy is
synthesizing an advertisement message, the Nonce value MUST synthesizing an advertisement message, the Nonce value MUST
correspond to the solicitation message to which the proxy is correspond to the solicitation message to which the proxy is
responding. responding.
3. The Proxy Signature option MUST be added as the last option in 2. The Proxy Signature option MUST be added as the last option in
the message. the message.
4. The data MUST be signed as explained in Section 5.1. 3. The data MUST be signed as explained in Section 5.1.
5.2.2. Processing rules for receivers 5.2.2. Processing Rules for Receivers
Any SEND message without a Proxy Signature option MUST be treated as Any SEND message without a Proxy Signature option MUST be treated as
specified in the SEND specification [RFC3971]. specified in the SEND specification [RFC3971].
A SEND message including a Proxy Signature option MUST be processed A SEND message including a Proxy Signature option MUST be processed
as specified below: as specified below:
1. The receiver MUST ignore any RSA and CGA options, as well as any 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 options that might come after the first PS option. The options
are ignored for both signature verification and NDP processing are ignored for both signature verification and NDP processing
purposes. purposes.
2. The Key Hash field MUST indicate the use of a known public key. 2. The Key Hash field MUST indicate the use of a known public key.
A valid certification path (see [I-D.ietf-csi-send-cert] Section A valid certification path (see [RFC6494] Section 9) between the
9) between the receiver's trust anchor and the sender's public receiver's trust anchor and the sender's public key MUST be
key MUST be known. The Secure Proxy ND's X509v3 certificate MUST known. The Secure Proxy ND X.509v3 certificate MUST contain an
contain an extended key usage extension including the appropriate extended key usage extension including the appropriate
KeyPurposeId value and prefix for the message to validate: KeyPurposeId value and prefix for the message to validate:
* For RA messages, a KeyPurposeId value of id-kp- * For RA messages, a KeyPurposeId value of
sendProxiedRouter MUST exist for the certificate, and the id-kp-sendProxiedRouter MUST exist for the certificate, and
prefix included in the RA message for on-link determination the prefix included in the RA message for on-link
and/or stateless address autoconfiguration MUST be encompassed determination and/or stateless address autoconfiguration MUST
in the prefix associated to that certificate. be encompassed in the prefix associated to that certificate.
* For Redirect messages, a KeyPurposeId value of id-kp- * For Redirect messages, a KeyPurposeId value of
sendProxiedRouter MUST exist for the certificate, and the id-kp-sendProxiedRouter MUST exist for the certificate, and
prefix included in the Target Address of the Redirect message the prefix included in the Target Address of the Redirect
MUST be encompassed in the prefix associated to that message MUST be encompassed in the prefix associated to that
certificate. certificate.
* For NA, NS and RS messages, a KeyPurposeId value of id-kp- * For NA, NS, and RS messages, a KeyPurposeId value of
sendProxiedOwner MUST exist for the certificate, and the id-kp-sendProxiedOwner MUST exist for the certificate, and the
source addresses of the messages MUST be encompassed in the source addresses of the messages MUST be encompassed in the
prefix associated to the certificate. prefix associated to the certificate.
If any of these tests fails, the verification fails. If any of these tests fail, the verification fails.
3. The Digital Signature field MUST have correct encoding, otherwise 3. The Digital Signature field MUST have correct encoding;
the verification of the message including the PS option fails. otherwise, the verification of the message including the PS
option fails.
4. The Digital Signature verification MUST show that the signature 4. The Digital Signature verification MUST show that the signature
has been calculated as specified in Section 5.1, otherwise the has been calculated as specified in Section 5.1; otherwise, the
verification of the message including the PS option fails. verification of the message including the PS option fails.
5. The Nonce option MUST be processed as specified in [RFC3971] 5. The Nonce option MUST be processed as specified in [RFC3971]
Section 5.3.4, except for replacing 'RSA Signature option' by 'PS Section 5.3.4, except for replacing 'RSA Signature option' with
option'; if these tests fail, the verification of the message 'PS option'; if these tests fail, the verification of the message
including the PS option fails. including the PS option fails.
6. The Timestamp option MUST be processed as specified in [RFC3971] 6. The Timestamp option MUST be processed as specified in [RFC3971]
Section 5.3.4, except for replacing 'RSA Signature option' by 'PS Section 5.3.4, except for replacing 'RSA Signature option' with
option'. If these tests fail, the verification of the message 'PS option'. If these tests fail, the verification of the
including the PS option fails. The receiver SHOULD store the message including the PS option fails. The receiver SHOULD store
peer-related timing information specified in [RFC3971] Section the peer-related timing information specified in [RFC3971]
5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each Sections 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each
different proxy (which could be identified by the different Key different proxy (which could be identified by the different Key
Hash values of the proxied message) and separately from the Hash values of the proxied message) and separately from the
timing information associated to the IP address of a node for timing information associated to the IP address of a node for
which the message is proxied. In this way, a message received 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 for the first time from a proxy (i.e., for which there is no
information stored in the cache) for which the Timestamp option information stored in the cache) for which the Timestamp option
is checked, SHOULD be checked as a message received from a new is checked SHOULD be checked as a message received from a new
peer (as in [RFC3971] section 5.3.4.2). peer (as in [RFC3971] Section 5.3.4.2).
7. Messages with the Override bit [RFC4861] set MUST override an 7. Messages with the Override bit [RFC4861] set MUST override an
existing cache entry regardless if it was created as a result of existing cache entry regardless of whether it was created as a
a RSA Signature option or a PS option validation. When the result of an RSA Signature option or a PS option validation.
Override bit is not set, the advertisement MUST NOT update a When the Override bit is not set, the advertisement MUST NOT
cached link-layer address created securely by means of RSA update a cached link-layer address created securely by means of
Signature option or PS option validation. RSA Signature option or PS option validation.
Messages for which the verification fails MUST be silently discarded Messages for which the verification fails MUST be silently discarded
if the node has been configured to accept only secured ND messages. if the node has been configured to accept only secured ND messages.
The messages MAY be accepted if the host has been configured to The messages MAY be accepted if the host has been configured to
accept both secured and unsecured messages but MUST be treated as an accept both secured and unsecured messages but MUST be treated as an
unsecured message. unsecured message.
5.3. Proxying Link-Local Addresses 5.3. Proxying Link-Local Addresses
Secure Neighbor Discovery [RFC3971] relies on certificates to prove SEND [RFC3971] relies on certificates to prove that routers are
that routers are authorized to announce a certain prefix. However, authorized to announce a certain prefix. However, Neighbor Discovery
Neighbor Discovery [RFC4861] states that routers do not announce the [RFC4861] states that routers do not announce the link-local prefix
Link-Local prefix (fe80::/64). Hence, it is not required for a SEND (fe80::/64). Hence, it is not required for a SEND certificate to
certificate to hold a X.509 extension for IP addresses that hold an X.509 extension for IP addresses that authorizes the
authorizes the fe80::/64 prefix. However, some Secure Proxy ND fe80::/64 prefix. However, some Secure Proxy ND scenarios
scenarios ([RFC4389], [RFC5213]) impose providing the proxying ([RFC4389], [RFC5213]) impose providing the proxying function for the
function for the Link-Local address of a node. When Secure ND proxy link-local address of a node. When Secure ND Proxy functionality for
functionality for a Link-Local address is required, either a list of a link-local address is required, either a list of link-local
link-local addresses, or the fe80::/64 prefix MUST be explicitly addresses, or the fe80::/64 prefix MUST be explicitly authorized to
authorized to be proxied in the corresponding certificate. be proxied in the corresponding certificate.
6. Application Scenarios 6. Application Scenarios
In this section we describe three different application scenarios for In this section, we describe three different application scenarios
which Secure Proxy ND support for SEND can be applied. Note that the for which Secure Proxy ND support for SEND can be applied. Note that
particular way in which Secure Proxy ND support is applied (which ND the particular way in which Secure Proxy ND support is applied (which
messages are proxied, in which direction, how the interaction with ND messages are proxied, in which direction, how the interaction with
non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on non-SEND hosts and RFC 3971 hosts is handled, etc.) largely depends
the particular scenario considered. In the first two scenarios on the particular scenario considered. In the first two scenarios
presented below, ND messages are synthesized on behalf of off-link presented below, ND messages are synthesized on behalf of off-link
nodes. In the third one, ND messages are translated from the nodes. In the third one, ND messages are translated from the
messages received in other interfaces of the proxy. messages received in other interfaces of the proxy.
6.1. Scenario 1: Mobile IPv6 6.1. Scenario 1: Mobile IPv6
The description of the problems for deploying SEND in this scenario The description of the problems for deploying SEND in this scenario
is presented in [I-D.ietf-csi-sndp-prob]. is presented in [RFC5909].
The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN) The Mobile IPv6 (MIPv6) protocol [RFC6275] allows a Mobile Node (MN)
to move from one link to another while maintaining reachability at a 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 stable address, the so-called MN's Home Address (HoA). When an MN
attaches to a foreign network, all the packets sent to the MN's HoA 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 by a Correspondent Node (CN) on the home link or a router are
intercepted by the Home Agent (HA) on that home link, encapsulated intercepted by the Home Agent (HA) on that home link, encapsulated,
and tunneled to the MN's registered Care-of Address (CoA). and tunneled to the MN's registered Care-of Address (CoA).
To deploy Secure Proxy ND in this scenario, i.e. to secure the HA 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 operation, a Secure Proxy ND certificate with a KeyPurposeId value of
id-kp-sendProxiedOwner for the prefix of the home link is required. id-kp-sendProxiedOwner for the prefix of the home link is required.
The Secure ND Proxy is configured with the private key associated to 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 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 link, the HA checks whether the Target Address within the NS matches
any of the MN's Home Address in the Binding Cache and if so, it with any of the MN's Home Addresses in the binding cache, and if so,
replies with a Neighbor Advertisement (NA) constructed as described it replies with a Neighbor Advertisement (NA) constructed as
in [RFC4861], containing its own link-layer address (HA_LL) as the described in [RFC4861], containing its own link-layer address (HA_LL)
Target Link Layer Address Option (TLLAO). Then a timestamp as the Target Link-Layer Address Option (TLLAO). Then, a timestamp
(generated by the proxy) and nonce (if appropriate, according to (generated by the proxy) and nonce (if appropriate, according to
[RFC3971]), MUST be included. Finally, a PS option signing the [RFC3971]) MUST be included. Finally, a PS option signing the
message MUST be included as the last option of the message. message MUST be included as the last option of the message.
Node (N) Home Agent (HA) Mobile Node (MN) Node (N) Home Agent (HA) Mobile Node (MN)
on Home Link on Home Link on Foreign Link on Home Link on Home Link on Foreign Link
| | | | | |
| SRC = N | | | SRC = N | |
| DST = solicited_node(MN) | | | DST = solicited_node (MN) | |
| ICMPv6 NS | | | ICMPv6 NS | |
| TARGET = MN | | | TARGET = MN | |
| SLLAO = N_LL | | | SLLAO = N_LL | |
| [CGA] | | | [CGA] | |
| RSA signature | | | RSA signature | |
|------------------------->| | |-------------------------->| |
| | | | | |
| SRC = HA | | | SRC = HA | |
| DST = N | | | DST = N | |
| ICMPv6 NA | | | ICMPv6 NA | |
| TARGET = MN | | | TARGET = MN | |
| TLLAO = HA_LL | | | TLLAO = HA_LL | |
| PS signature | | | PS signature | |
|<-------------------------| | |<--------------------------| |
| | | | | |
| traffic | | | traffic | |
| dest= MN HoA | | | dest = MN HoA | |
|------------------------->| | |-------------------------->| |
| | | | | |
| | tunneled traffic | | | tunneled traffic |
| | dest= MN CoA | | | dest = MN CoA |
| |------------------------->| | |------------------------->|
| | | | | |
Figure 2: Proxy ND role of the Home agent in MIPv6 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 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 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 Section 5.2.2. Note that in this case the Override bit of the NA
message is used to control which messages should prevail on each message is used to control which messages should prevail on each
case: the message generated by the proxy when the MN moves from the 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 home network, or the MN if it comes back to the home link, as defined
in the MIPv6 specification [RFC3775]. in the MIPv6 specification [RFC6275].
6.2. Scenario 2: Proxy Mobile IPv6 6.2. Scenario 2: Proxy Mobile IPv6
Proxy Mobile IPv6 [RFC5213] is a network-based mobility management Proxy Mobile IPv6 [RFC5213] is a network-based mobility management
protocol that provides IP mobility management support for MNs without protocol that provides IP mobility management support for MNs without
requiring MNs being involved in the mobility related signaling. The requiring that MNs be involved in the mobility-related signaling.
IP mobility management is totally hidden to the MN in a Proxy Mobile The IP mobility management is totally hidden to the MN in a Proxy
IPv6 domain and it is performed by two functional entities: the Local Mobile IPv6 domain, and it is performed by two functional entities:
Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG).
When the MN connects to a new access link, it sends a muliticast When the MN connects to a new access link, it sends a multicast
Router Solicitation (RS). The MAG on the new access link, upon Router Solicitation (RS). The MAG on the new access link, upon
detecting the MN's attachment, signals the LMA requesting an update 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 - 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 (PBU)). Once the signaling is completed (it receives a Proxy Binding
Ack - PBA), the MAG replies to the MN with a Router Advertisement Ack (PBA)), the MAG replies to the MN with a Router Advertisement
(RA) containing the home network prefix(es) that were assigned to (RA) containing the home network prefix(es) that were assigned to
that mobility session, making the MN believe it is still on the same that mobility session, making the MN believe it is still on the same
link, so the IPv6 address reconfiguration procedure is not triggered link, so the IPv6 address reconfiguration procedure is not triggered
(Figure 3). (Figure 3).
MN new MAG LMA MN new MAG LMA
| | | | | |
MN Attached | | MN Attached | |
| | | | | |
| MN Attached Event from MN/Network | | MN Attached Event from MN/Network |
| | | | | |
| SRC = MN | | | SRC = MN | |
| DST = all-routers | | | DST = all routers | |
| ICMPv6 RS | | | ICMPv6 RS | |
| [CGA] | | | [CGA] | |
| RSA signature | | | RSA signature | |
|--------------------->| | |--------------------->| |
| | | | | |
| |--- PBU ------------->| | |--- PBU ------------->|
| | | | | |
| | Accept PBU | | Accept PBU
| | | | | |
| |<------------- PBA ---| | |<------------- PBA ---|
skipping to change at page 17, line 4 skipping to change at page 14, line 37
| | | | | |
| SRC = MAG4MN | | | SRC = MAG4MN | |
| DST = MN | | | DST = MN | |
| ICMPv6 RA | | | ICMPv6 RA | |
| SLL = MAG_LL | | | SLL = MAG_LL | |
| PS | | | PS | |
|<---------------------| | |<---------------------| |
| | | | | |
| | | | | |
| | | | | |
Figure 3: Mobile node's handover in PMIPv6
Figure 3: Mobile Node's Handover in PMIPv6
To avoid potential link-local address collisions between the MAG and To avoid potential link-local address collisions between the MAG and
the MN after a handoff to a new link, the Proxy Mobile IPv6 the MN after a handoff to a new link, the Proxy Mobile IPv6
specification requires the MAG's link-local address on the link to specification [RFC5213] requires that the MAG's link-local address on
which the MN is attached to be generated by the LMA when the MN first the link to which the MN is attached be generated by the LMA when the
attaches to a PMIPv6 domain, and to be provided to the new MN's MN first attaches to a PMIPv6 domain, and be provided to the new MN's
serving MAG after each handoff. Thus, from the MN's point of view, 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 the MAG's link-local address remains constant for the duration of
that MN's session. that MN's session.
The approach described above and the current SEND specification are The approach described above and the current SEND specification are
incompatible since sharing the same link-local address on different incompatible, since sharing the same link-local address on different
MAGs would require all MAGs of a PMIPv6 domain to construct the CGA 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, and the RSA Signature option with the same public-private key pair,
which is not an acceptable security policy. which is not an acceptable security policy.
Using different public-private key pairs on different MAGs would mean Using different public-private key pairs on different MAGs would mean
different MAGs use different CGAs as link-local address. Thus the that different MAGs use different CGAs as link-local addresses.
serving MAG's link-local address would change after each handoff of Thus, the serving MAG's link-local address would change after each
the MN, which is in contradiction with the way MAG link-local address handoff of the MN, which is in contradiction with the way MAG link-
assignment occurs in a PMIPv6 domain. local address assignment occurs in a PMIPv6 domain.
To provide SEND protection, each MAG MUST be configured to act as a To provide SEND protection, each MAG MUST be configured to act as a
proxy by means of a certificate associated to the PMIPv6 domain, proxy by means of a certificate associated to the PMIPv6 domain,
authorizing each MAG to proxy securely NA and RS messages by means of authorizing each MAG to securely proxy NA and RS messages by means of
a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the
certificate MUST also authorize the MAG to advertise prefixes by certificate MUST also authorize the MAG to advertise prefixes by
associating to the same certificate a KeyPurposeId value of id-kp- associating to the same certificate a KeyPurposeId value of
sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId id-kp-sendProxiedRouter. Note that the inclusion of multiple
values is supported by [I-D.ietf-csi-send-cert]. KeyPurposeId values is supported by [RFC6494].
When a MAG replies to a RS with a RA, the source address MUST be When a MAG replies to an RS with an RA, the source address MUST be
equal to the MAG link-local address associated to the MN in this equal to the MAG link-local address associated to the MN in this
PMIPv6 domain, with its own link-layer address as Source link-layer PMIPv6 domain, with its own link-layer address as the source link-
address. Then a timestamp (generated by the proxy) and nonce (if layer address. Then, a timestamp (generated by the proxy) and nonce
appropriate, according to [RFC3971]), MUST be included. Finally, a (if appropriate, according to [RFC3971]) MUST be included. Finally,
PS option signing the message MUST be included as the last option of a PS option signing the message MUST be included as the last option
the message. This procedure is followed for any other ND message of the message. This procedure is followed for any other ND message
that could be generated by the MAG to the MN. that could be generated by the MAG to the MN.
A node receiving a message from the MAG containing the PS option MUST A node receiving a message from the MAG containing the PS option MUST
apply the processing rules defined in Section 5.2.2. Note that apply the processing rules defined in Section 5.2.2. Note that
unsolicited messages sent by the MAG should be validated by the host unsolicited messages sent by the MAG should be validated by the host
according to timestamp values specific to the MAG serving the link, 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 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. other links, according to processing step number 6 of Section 5.2.2.
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy
The description of the problems for deploying SEND in this scenario The problems for deploying SEND in this scenario are presented in
is presented in [I-D.ietf-csi-sndp-prob]. [RFC5909].
Link 1 Link 2 Link 1 Link 2
Host A ND Proxy (P) Host B Host A ND Proxy (P) Host B
| | | | | |
| SRC = A | | | SRC = A | |
| DST = solicited_node(B) | | | DST = solicited_node (B) | |
| ICMPv6 NS | | | ICMPv6 NS | |
| TARGET = B | | | TARGET = B | |
| SLLAO = A_LL | | | SLLAO = A_LL | |
|------------------------->| | |------------------------->| |
| | SRC = A | | | SRC = A |
| | DST = solicited_node(B) | | | DST = solicited_node (B) |
| | ICMPv6 NS | | | ICMPv6 NS |
| | TARGET = B | | | TARGET = B |
| | SLLAO = P_LL | | | SLLAO = P_LL |
| |------------------------->| | |------------------------->|
| | | | | |
| | SRC = B | | | SRC = B |
| | DST = A | | | DST = A |
| | ICMPv6 NA | | | ICMPv6 NA |
| | TARGET = B | | | TARGET = B |
| | TLLAO = B_LL | | | TLLAO = B_LL |
| |<-------------------------| | |<-------------------------|
| SRC = B | | | SRC = B | |
| DST = A | | | DST = A | |
| ICMPv6 NA | | | ICMPv6 NA | |
| TARGET = B | | | TARGET = B | |
| TLLAO = P_LL | | | TLLAO = P_LL | |
|<-------------------------| | |<-------------------------| |
| | | | | |
Figure 4: RFC 4389 Neighbor Discovery Proxy operation Figure 4: RFC 4389 Neighbor Discovery Proxy Operation
The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a 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 single segment and specifies the IP-layer support that enables
bridging under these circumstances. bridging under these circumstances.
A Secure ND Proxy MUST parse any IPv6 packet it receives on a proxy 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 interface to check whether it contains one of the following NDP
messages: NS, NA, RS, RA, or Redirect. The Secure ND Proxy MUST messages: NS, NA, RS, RA, or Redirect. The Secure ND Proxy MUST
verify the authenticity of the received ND message, according to verify the authenticity of the received ND message, according to
[RFC3971]. If the SEND message is valid, then it proxies the [RFC3971], or according to Section 5.2.2 if it contains a PS option.
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
address as the address in the neighbor entry corresponding to the
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, Then, after removing the CGA, RSA, or PS options, the message to be
signing all the information contained so far in the message. To translated MUST be processed according to the ND Proxy specification
be able to sign any NS, NA, RS, RA o Redirect message, the key [RFC4389]. This includes performing loop prevention checks,
used must correspond to a certificate with KeyPurposeId values of determining the outgoing interface for the proxied message, changing
id-kp-sendProxiedOwner and id-kp-sendProxiedRouter. the source link-layer address to the address of the outgoing
interface, changing source link-layer addresses contained in the
payload (that is, in a Source Link-Layer Address Option (SLLAO) or a
Target Link-Layer Address Option (TLLAO)), maintaining the
destination link-layer address as the address in the neighbor entry
corresponding to the destination IPv6 address, setting the P bit for
proxied RA messages, etc. Note that besides link-layer addresses and
the P bit of a RA, no other field of the received message is changed
when proxied by an [RFC4389] proxy.
When any other IPv6 unicast packet is received on a proxy interface, When any other IPv6 unicast packet is received on a proxy interface,
if it is not locally destined then it is forwarded unchanged (other 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 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 the next-hop address appears in the neighbor cache. If no neighbor
cache entry is present, the Secure ND Proxy SHOULD queue the packet cache entry is present, the Secure ND Proxy SHOULD queue the packet
and initiate a Neighbor Discovery signaling as if the NS message were and initiate a Neighbor Discovery signaling as if the NS message were
locally generated. locally generated.
Note that to be able to sign any NS, NA, RS, RA, or Redirect message,
the key used MUST correspond to a certificate with KeyPurposeId
values of id-kp-sendProxiedOwner and id-kp-sendProxiedRouter.
In order to deploy this scenario, nodes in proxied segments MUST know In order to deploy this scenario, nodes in proxied segments MUST know
the certificate authorizing proxy operation. To do so it could be the certificate-authorizing proxy operation. To do so, it could be
required to configure at least one device per each proxied segment required that at least one device per proxied segment (maybe the
(may be the proxy itself) to propagate the required certification proxy itself) be configured to propagate the required certification
path to authorize proxy operation by means of a CPS/CPA exchange. path to authorize proxy operation by means of a CPS/CPA exchange.
7. Backward Compatibility with RFC3971 nodes and non-SEND nodes 7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes
In this section we discuss the interaction of Secure ND Proxies and In this section, we discuss the interaction of Secure ND Proxies and
SPND nodes with RFC3971 nodes and non-SEND nodes. As stated in SPND nodes with RFC 3971 nodes and non-SEND nodes. As stated in
[RFC3971], network operators may want to run a mixture of nodes [RFC3971], network operators may want to run a mixture of nodes
accepting secured and unsecured NDP messages at the same time. accepting secured and unsecured NDP messages at the same time.
Secure ND Proxies and SPND nodes SHOULD support the use of secured Secure ND Proxies and SPND nodes SHOULD support the use of secured
and unsecured NDP messages at the same time. and unsecured NDP messages at the same time.
7.1. Backward Compatibility with RFC3971 nodes 7.1. Backward Compatibility with RFC 3971 Nodes
RFC3971 nodes, i.e. SEND nodes not compliant with the modifications RFC 3971 nodes, i.e., SEND nodes not compliant with the modifications
required in Section 5, cannot interpret correctly a PS option required in Section 5, cannot correctly interpret a PS option
received in a proxied ND message. These SEND nodes silently discard received in a proxied ND message. These SEND nodes silently discard
the PS option, as specified in [RFC4861] for any unknown option. As the PS option, as specified in [RFC4861] for any unknown option. As
a result, these messages will be treated as unsecured as described in a result, these messages will be treated as unsecured, as described
Section 8 "Transitions Issues" of the SEND specification [RFC3971]. in Section 8 ("Transitions Issues") of the SEND specification
[RFC3971].
When RFC3971 nodes and SPND nodes exchange ND messages (without proxy When RFC 3971 nodes and SPND nodes exchange ND messages (without
intervention), in either direction, messages are generated according proxy intervention), in either direction, messages are generated
to the SEND specification [RFC3971], so these nodes interoperate according to the SEND specification [RFC3971], so these nodes
seamlessly. interoperate seamlessly.
In the scenarios in which the proxy translates ND messages, the In the scenarios in which the proxy translates ND messages, the
messages to translate can either be originated in a RFC3971 node or messages to translate can either be originated in an RFC 3971 node or
in an SPND node, without interoperability issues (note that the in an SPND node, without interoperability issues (note that the
difference between RFC3971 nodes and SPND nodes only affect to the difference between RFC 3971 nodes and SPND nodes only affects the
ability to process received NDP messages containing a PS option, not ability to process received NDP messages containing a PS option, not
in the way they generate messages secured by SEND). the way they generate messages secured by SEND).
7.2. Backward Compatibility with non-SEND nodes A configuration option MAY exist in a Secure ND Proxy to specify the
RFC 3971 nodes to which it is connected, so that the proxied messages
sent to these nodes are not processed according to the Secure Proxy
ND specification, for performance reasons.
7.2. Backward Compatibility with Non-SEND Nodes
Non-SEND nodes receiving NDP packets silently discard PS options, as Non-SEND nodes receiving NDP packets silently discard PS options, as
specified in [RFC4861] for any unknown option. Therefore, these specified in [RFC4861] for any unknown option. Therefore, these
nodes interpret messages proxied by a Secure ND Proxy as any other ND nodes interpret messages proxied by a Secure ND Proxy as any other ND
message. message.
When non-SEND nodes and SPND nodes exchange ND messages (without When non-SEND nodes and SPND nodes exchange ND messages (without
proxy intervention), in either direction, the rules specified in proxy intervention), in either direction, the rules specified in
section 8 of [RFC3971] apply. Section 8 of [RFC3971] apply.
A Secure ND Proxy SHOULD support the use of secured and unsecured NDP 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 messages at the same time, although it MAY have a configuration that
causes not to perform proxying for unsecured NDP messages. A Secure causes proxying to not be performed for unsecured NDP messages. A
ND Proxy MAY also have a configuration option whereby it disables Secure ND Proxy MAY also have a configuration option whereby it
secure ND proxying completely. This configuration SHOULD be switched disables secure ND proxying completely. This configuration SHOULD be
off by default, that is security is provided by default. In the next switched off by default; that is, security is provided by default.
paragraphs we discuss the recommended behavior of the Secure ND Proxy In the following paragraphs, we discuss the recommended behavior of
regarding to the protection level to provide to proxied messages in a the Secure ND Proxy regarding the protection level to provide to
mixed scenario involving SPND/RFC3971 nodes and non-SEND nodes. In proxied messages in a mixed scenario involving SPND/RFC 3971 nodes
particular, two different situations occur depending on if the and non-SEND nodes. In particular, two different situations occur,
proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes. depending on whether the proxied nodes are RFC 3971 or SPND nodes, or
non-SEND nodes.
As a rule of thumb, if the proxied nodes can return to the link in 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 which the proxy operates, the Secure ND Proxy MUST only generate PS
options on behalf of nodes with SEND capabilities (i.e. that they options on behalf of nodes with SEND capabilities (i.e., those nodes
could use SEND to defend their messages if present on the same link that could use SEND to defend their messages if present on the same
as the proxy, i.e. being either RFC3971 nodes or SPND nodes). This link as the proxy -- in other words, either RFC 3971 nodes or SPND
is relevant to allow nodes to prefer secured information over nodes). This is relevant to allow nodes to prefer secured
unsecured one, and to properly execute the DAD procedure, as information over an unsecured one, and to properly execute the
specified in [RFC3971]. Therefore, in this case the Secure ND Proxy Duplicate Address Detection (DAD) procedure, as specified in
MUST synthesize/translate messages containing the PS option for SPND [RFC3971]. Therefore, in this case, the Secure ND Proxy MUST
and RFC3971 hosts, and MUST NOT synthesize/translate messages synthesize/translate messages containing the PS option for SPND and
containing the PS option for non-SEND nodes. Note that ND RFC 3971 hosts, and MUST NOT synthesize/translate messages containing
advertisements in response to solicitations generated by a Secure ND the PS option for non-SEND nodes. Note that ND advertisements in
Proxy must be secured or not according to the previous considerations response to solicitations generated by a Secure ND Proxy must either
(i.e. to the nature of the proxied node), and not according to the be secured or not secured, according to the previous considerations
secure or unsecure nature of the solicitation message. (i.e., according to the nature of the proxied node), and not
according to the secure or unsecure nature of the solicitation
message.
In order to apply this rule, the Secure ND Proxy needs to know the In order to apply this rule, the Secure ND Proxy needs to know the
security capabilities of the proxied node. The way this information security capabilities of the proxied node. The way this information
is acquired depends on the application scenario, and it is discussed is acquired depends on the application scenario, and it is discussed
next: next:
o For scenarios in which ND messages are translated for nodes that 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 can arrive to the link in which the proxy operates, the rule can
be easily applied: only for messages validated in the Secure ND be easily applied: only for messages validated in the Secure ND
Proxy according to the SEND specification [RFC3971], or according Proxy according to the SEND specification [RFC3971], or according
skipping to change at page 21, line 47 skipping to change at page 19, line 41
securely by the inclusion of a PS option. Unsecured ND messages securely by the inclusion of a PS option. Unsecured ND messages
could be proxied if unsecured operation is enabled in the proxy, could be proxied if unsecured operation is enabled in the proxy,
but the message generated by the Secure ND Proxy for the received but the message generated by the Secure ND Proxy for the received
message MUST NOT include a PS option. message MUST NOT include a PS option.
o For scenarios in which ND messages are synthesized on behalf of o For scenarios in which ND messages are synthesized on behalf of
remote nodes, different considerations should be made according to remote nodes, different considerations should be made according to
the particular application scenario. the particular application scenario.
* For MIPv6, if the MN can return to the home link, it is * 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 required that the proxy know whether the node could use SEND to
defend its address or not. 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 proxying a non-SEND MN would make ND messages sent by the proxy
to be more preferred than a ND message of the non-SEND MN when be more preferred than an ND message of the non-SEND MN when
the MN returns to the home link (even if the proxied messages 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 have the Override bit set to 1). Not using the PS option for
RFC3971 or SPND MN would make the address in the home link more an RFC 3971 or SPND MN would make the address in the home link
vulnerable when the MN is away than when it is in the home more vulnerable when the MN is away than when it is in the home
link, defeating the purpose of the Secure Proxy ND mechanism. link, defeating the purpose of the Secure Proxy ND mechanism.
Therefore, in this case the HA MUST know the SEND capabilities 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 of the MN, MUST use the PS option if the MN is an SPND or
RFC3971 host, and MUST NOT use PS option for non-SEND hosts. RFC 3971 host, and MUST NOT use the PS option for non-SEND
hosts.
* For the Proxy Mobile IPv6 scenario, a node moving from a link * For the Proxy Mobile IPv6 scenario, a node moving from a link
in which PS option has been used to protect a link-layer in which the PS option has been used to protect a link-layer
address to a link in which ND messages are not protected by address to a link in which ND messages are not protected by
SEND would prevent the MN from adquiring the new information SEND would prevent the MN from acquiring the new information
until the cached information expires. However, in this case it until the cached information expires. However, in this case,
is reasonable to consider that all MAGs provide the same it is reasonable to consider that all MAGs provide the same
security for protecting ND messages, and that either all MAGs security for protecting ND messages, and that either all MAGs
will behave as Secure ND Proxy, or none, so configuration is or no MAGs will behave as a Secure ND Proxy, so configuration
expected to be easier. is expected to be easier.
A configuration option MAY exist in a Secure ND Proxy to specify the
non-SEND nodes to which it is connected, so that the proxied messages
sent to these nodes are not processed according to the Secure Proxy
ND specification, for performance reasons.
8. Security Considerations 8. Security Considerations
The mechanism described in this document introduces a new Proxy The mechanism described in this document introduces a new PS option
Signature (PS) option allowing a Secure ND Proxy to synthesize or allowing a Secure ND Proxy to synthesize or translate a SEND message
translate a SEND message for a proxied address, to Redirect traffic for a proxied address, to redirect traffic for given target
for given target addresses or to advertise prefix information by addresses, or to advertise prefix information by means of RA
means of RA messages. A SPND node only accepts such a message if it messages. An SPND node only accepts such a message if it includes a
includes a valid PS option generated by a properly authorized Secure valid PS option generated by a properly authorized Secure ND Proxy
ND Proxy (with a certificate containing a KeyPurposeId with value id- (with a certificate containing a KeyPurposeId with value
kp-sendProxiedOwner for protecting NA, NS and RS messages, or id-kp-sendProxiedOwner for protecting NA, NS, and RS messages, or
containing a KeyPurposeId value of id-kp-sendProxiedRouter for containing a KeyPurposeId value of id-kp-sendProxiedRouter for
protecting RA and Redirect messages). Such a message has equivalent protecting RA and Redirect messages). Such a message has protection
protection against the threats presented in section 9 of [RFC3971] as against the threats presented in Section 9 of [RFC3971] equivalent to
a message signed with a RSA Signature option. a message signed with an RSA Signature option.
The security of proxied ND messages not including a PS option is the The security of proxied ND messages not including a PS option is the
same as an unsecured ND message. The security of a proxied ND 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 message received by a non-SEND host or RFC 3971 host is the same as
unsecured ND message. an unsecured ND message.
When a message including a PS option is received by a SPND node, any When a message including a PS option is received by an SPND node, any
CGA or RSA options also included in the message are removed and the CGA or RSA options also included in the message are removed and the
remaining message further processed. Altough properly formed proxied remaining message further processed. Although properly formed
messages MUST NOT include at the same time PS and CGA/RSA options, proxied messages MUST NOT include PS and CGA/RSA options at the same
discarding them if they appear does not affect to the security. If time, discarding them if they appear does not affect security. If
the PS option is validated, then the information included in the the PS option is validated, then the information included in the
message has been validly generated by a proxy, and should be honored message has been validly generated by a proxy, and should be honored
(remember that anti-replay protection is provided by means of nonce (remember that anti-replay protection is provided by means of Nonce
and timestamp options). If the PS option is not validated, then it 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 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 for an attacker from appending false or old CGA/RSA information to a
message secured by a Secure ND Proxy. message secured by a Secure ND Proxy.
A compromised Secure ND Proxy provisioned with an authorization A compromised Secure ND Proxy provisioned with an authorization
certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is
able, like a compromised router to siphon off traffic from the host, 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- or mount a man-in-the-middle attack, for hosts communicating to off-
link hosts. A compromised Secure ND Proxy provisioned with an link hosts. A compromised Secure ND Proxy provisioned with an
authorization certificate with a KeyPurposeId value of id-kp- authorization certificate with a KeyPurposeId value of
sendProxiedOwner can siphon off traffic or mount a man-in-the-middle id-kp-sendProxiedOwner can siphon off traffic or mount a man-in-the-
attack for communication between on-link hosts, even if the hosts use middle attack for communication between on-link hosts, even if the
SEND. Note that different application scenarios may require one type hosts use SEND. Note that different application scenarios may
of authorization, the other, or both. To minimize security risks, require one type of authorization, the other, or both. To minimize
authorization capabilities SHOULD NOT exceed the ones strictly security risks, authorization capabilities MUST NOT exceed the ones
required by the application scenario to be deployed. strictly required by the application scenario to be deployed.
The messages for which a Secure ND Proxy performs its function and The messages for which a Secure ND Proxy performs its function and
the link for which this function is performed MUST be configured the link for which this function is performed MUST be configured
appropriately for each proxy and scenario. This configuration is appropriately for each proxy and scenario. This configuration is
specially relevant if Secure Proxy ND is used for translating ND especially relevant if Secure Proxy ND is used for translating ND
messages from one link to another. messages from one link to another.
Section 7 discusses the security considerations resulting from the Section 7 discusses the security considerations resulting from the
decision of appending or omitting the PS option depending on the decision to append or omit the PS option, depending on the SEND-
SEND-awareness of the proxied nodes. awareness of the proxied nodes.
Protection against replay attacks from unsolicited messages such as Protection against replay attacks from unsolicited messages such as
NA, RA, and Redirects is provided by means of the Timestamp option. 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 When Secure ND Proxy is used, each host, and each proxy acting on
proxy acts on behalf are considered to be different peers in terms of behalf of that host, are considered to be different peers in terms of
Timestamp verification. Since the information provided by the host timestamp verification. Since the information provided by the host
and a proxy maybe different, including different link-layer and a proxy, including different link-layer addresses, may be
addresses, a replay attack could affect the operation of a third different, a replay attack could affect the operation of a third
node: replaying messages issued by a host that is no longer in the 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 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 proxy when the host is back in the link can prevent communication
with the host. This kind of attacks can be performed until the with the host. This kind of attack can be performed until the
timestamp of the peer (either the host or a proxy) is no longer valid 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 receiver. The window of vulnerability is in general larger
for the first message received from a new peer than for subsequent for the first message received from a new peer than for subsequent
messages received from the same peer (see [RFC3971]). A more messages received from the same peer (see [RFC3971]). A more
detailed analysis of the possible attacks related with the Timestamp detailed analysis of the possible attacks related to the Timestamp
option is described in section 7.3 of [I-D.ietf-csi-sndp-prob]. option is described in Section 6.3 of [RFC5909].
9. IANA Considerations 9. IANA Considerations
IANA is requested to allocate: IANA has allocated the following a new IPv6 Neighbor Discovery Option
type for the PS option, as 32. The value has been allocated from the
namespace specified in the IANA "IPv6 Neighbor Discovery Option
Formats" registry located at
http://www.iana.org/assignments/icmpv6-parameters.
A new IPv6 Neighbor Discovery Option type for the PS option, as IANA has also allocated the following new 128-bit value under the
TBA. The value need to be allocated from the namespace specified "Cryptographically Generated Addresses (CGA) Message Type Name Space"
in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS registry [RFC3972]:
located at http://www.iana.org/assignments/icmpv6-parameters.
A new 128-bit value under the CGA Message Type [RFC3972] 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.
namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.
10. Acknowledgements 10. Acknowledgements
The text has benefited from feedback provided by Jari Arkko, Jean- The text has benefited from feedback provided by Jari Arkko, Jean-
Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey
Melnikov and Sandra Murphy. Melnikov, Sandra Murphy, and Sean Turner.
The work of Alberto Garcia-Martinez was supported in part by T2C2 The work of Alberto Garcia-Martinez was supported in part by the T2C2
project (TIN2008-06739-C04-01, granted by the Spanish Science and project (TIN2008-06739-C04-01, granted by the Spanish Science and
Innovation Ministry). Innovation Ministry).
11. References 11. References
11.1. Normative 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-07 (work in progress),
September 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
in IPv6", RFC 3775, June 2004. "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[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)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, August 2008.
[RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
PKCS 1 , November 2002. Support in IPv6", RFC 6275, July 2011.
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
Profile and Certificate Management for SEcure Neighbor
Discovery (SEND)", RFC 6494, February 2012.
[RSA] RSA Laboratories, "PKCS #1 v2.1: RSA Cryptography
Standard", June 2002.
[SHA1] National Institute of Standards and Technology, "Secure [SHA1] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1 , April 1995. Hash Standard", FIPS PUB 180-1 , April 1995.
11.2. Informative References 11.2. Informative References
[I-D.ietf-csi-sndp-prob] [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Combes, J., Krishnan, S., and G. Daley, "Securing Neighbor Neighbor Discovery (ND) Trust Models and Threats",
Discovery Proxy: Problem Statement", RFC 3756, May 2004.
draft-ietf-csi-sndp-prob-04 (work in progress),
January 2010.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing
Discovery (ND) Trust Models and Threats", RFC 3756, Neighbor Discovery Proxy: Problem Statement", RFC 5909,
May 2004. July 2010.
Authors' Addresses Authors' Addresses
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com EMail: suresh.krishnan@ericsson.com
Julien Laganier Julien Laganier
QUALCOMM Incorporated Juniper Networks
5775 Morehouse Dr 1094 North Mathilda Avenue
San Diego, CA 92121 Sunnyvale, CA 94089
USA USA
Phone: +1 858 658 3538 Phone: +1 408 936 0385
Email: julienl@qualcomm.com EMail: julien.ietf@gmail.com
Marco Bonola Marco Bonola
Rome Tor Vergata University Rome Tor Vergata University
Via del Politecnico, 1 Via del Politecnico, 1
Rome I-00133 Rome I-00133
Italy Italy
Phone: Phone:
Email: marco.bonola@gmail.com EMail: marco.bonola@gmail.com
Alberto Garcia-Martinez Alberto Garcia-Martinez
U. Carlos III de Madrid U. Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
Spain Spain
Phone: +34 91 6248782 Phone: +34 91 6248782
Email: alberto@it.uc3m.es EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/ URI: http://www.it.uc3m.es/
 End of changes. 156 change blocks. 
518 lines changed or deleted 532 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/