draft-ietf-csi-proxy-send-02.txt   draft-ietf-csi-proxy-send-03.txt 
CGA & SEND maintenance Working S. Krishnan CGA & SEND maintenance Working S. Krishnan
Group Ericsson Group Ericsson
Internet-Draft J. Laganier Internet-Draft J. Laganier
Intended status: Standards Track QUALCOMM Inc. Intended status: Standards Track QUALCOMM Inc.
Expires: September 4, 2010 M. Bonola Expires: September 23, 2010 M. Bonola
Rome Tor Vergata University Rome Tor Vergata University
A. Garcia-Martinez A. Garcia-Martinez
UC3M UC3M
March 3, 2010 March 22, 2010
Secure Proxy ND Support for SEND Secure Proxy ND Support for SEND
draft-ietf-csi-proxy-send-02 draft-ietf-csi-proxy-send-03
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 a ND message is the
owner of the address from which the message is send, so that it is in 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 possession of the private key used to generate the digital signature
on the message. This means that the Proxy ND signaling performed by on the message. This means that the Proxy ND signaling performed by
nodes that do not possess knowledge of the address owner's private nodes that do not possess knowledge of the address owner's private
key cannot be secured using SEND. This document extends the current key cannot be secured using SEND. This document extends the current
SEND specification in order to support Proxy ND operation. SEND specification in order to secure Proxy ND operation.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2010. This Internet-Draft will expire on September 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6 4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6
5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8 5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8
5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8 5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8
5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10 5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10
5.2.1. Processing rules for senders . . . . . . . . . . . . . 10 5.2.1. Processing rules for senders . . . . . . . . . . . . . 10
5.2.2. Processing rules for receivers . . . . . . . . . . . . 11 5.2.2. Processing rules for receivers . . . . . . . . . . . . 11
5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 12 5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 12
6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 13 6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 13
6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 13 6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 13
6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 15 6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 14
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 17 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 16
7. Backward Compatibility with RFC3971 nodes and non-SEND 7. Backward Compatibility with RFC3971 nodes and non-SEND
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 20 7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 19
7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 20 7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for
skipping to change at page 6, line 22 skipping to change at page 6, line 22
public-private key pair that was used to generate a CGA, or that was public-private key pair that was used to generate a CGA, or that was
associated to a router certificate. 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 ownership 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 a X509v3 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, a KeyPurposeID value is [I-D.ietf-csi-send-cert]. Briefly, a KeyPurposeId value is
defined for authorizing proxies. The inclusion of the proxy defined for authorizing proxies. The inclusion of the proxy
authorization value allows the certificate owner to perform authorization value allows the certificate owner to perform
proxying of SEND messages for a range of addresses indicated in proxying of SEND messages for a range of addresses indicated in
the same certificate. This certificate can be exchanged as a the same certificate. This certificate can be exchanged through
result of the Authorization Delegation Discovery process defined the Authorization Delegation Discovery process defined in
in [RFC3971]. [RFC3971].
o A new Neighbor Discovery option called Proxy Signature option o A new Neighbor Discovery option called Proxy Signature option
(PSO). This option contains the hash value of the public key of (PSO). 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 PSO, it MUST Proxy ND's certificate. When a ND message contains a PSO, it MUST
NOT contain CGA and RSA Signature options. This option can be NOT contain CGA and RSA Signature options. This option can be
appended to any ND message: NA, NS, RS, RA and Redirect. appended to any ND message: NA, NS, RS, RA and Redirect.
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 is NA, NS, RS, RA, and Redirect. When any of these messages
received with a valid Proxy Signature option, it is considered as containing a valid Proxy Signature option is validated, it is
secure. considered as secure.
These extensions are applied in the following way: These extensions are applied in the following way:
o A Secure Proxy ND which proxies ND messages on behalf of a node o A Secure Proxy ND which proxies ND messages on behalf of a node
can use the PSO option to protect the proxied messages. This can use the PSO option to protect the proxied messages. This
Secure Proxy ND becomes part of the trusted infrastructure just Secure Proxy ND becomes part of the trusted infrastructure just
like a SEND router. like a SEND router.
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 know the Secure Proxy ND certificate (in messages, the nodes must be aware of the Secure Proxy ND
the format described in [I-D.ietf-csi-send-cert]) and must apply certificate (in the format described in [I-D.ietf-csi-send-cert])
the modified processing rules specified in this document. We call and must apply the modified processing rules specified in this
this nodes 'SPND nodes'. Note that the rules for generating ND document. We call these nodes 'SPND nodes'. Note that the rules
messages in SPND nodes do not change, so these nodes behave as for generating ND messages in SPND nodes do not change, so these
defined in [RFC3971] for sending ND messages. nodes behave as defined in [RFC3971] for sending ND messages.
o To allow SPND nodes to know the certificate path required to o To allow SPND nodes to know the certificate 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 Advertisements) as defined in Section 6 of SEND specification
[RFC3971] must handle the certificate format specified in [RFC3971] must handle the certificate format specified in
[I-D.ietf-csi-send-cert], and must be configured with the [I-D.ietf-csi-send-cert], and must be configured with the
appropriate certification path. appropriate certification path.
The proposed approach resolves the incompatibilities between the The proposed approach resolves the incompatibilities between the
current SEND specification and the application scenarios described in current SEND specification and the application scenarios described in
Section 6. Section 6.
5. Secure Proxy ND Specification 5. Secure Proxy ND Specification
A Secure Proxy ND performs all the operation described in the SEND A Secure Proxy ND 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 differentiate between an ensure that the receiving node can differentiate between an
authorized proxy generating or forwarding a SEND message for a authorized proxy generating or forwarding a SEND message for a
proxied address, and a malicious node doing the same. proxied address, and a malicious node doing the same.
This is accomplished by signing the message with the public key of This is accomplished by signing the message with the public key of
the authorized Secure Proxy ND. The signature of the ND Proxy is the authorized Secure Proxy ND. The signature of the ND Proxy is
included in a new option called Proxy Signature option (PSO). The included in a new option called Proxy Signature option (PSO). The
signature is performed over all the NDP options present in the signature is performed over all the NDP options present in the
message and the PSO is appended as the last option in the message. message and the PSO is appended as the last option in the message.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
TBA TBA
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 8
octets. octets.
Reserved Reserved
A 11-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) 128
bits of a SHA-1 [SHA1] hash of the public key used for 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's
skipping to change at page 10, line 42 skipping to change at page 10, line 42
A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST
contain a Proxy Signature option (PSO) and MUST NOT contain CGA and contain a Proxy Signature option (PSO) and MUST NOT contain CGA and
RSA Signature options. RSA Signature options.
A Secure Proxy ND sending a SEND message with the PSO Signature A Secure Proxy ND sending a SEND message with the PSO Signature
option MUST construct the message as follows: option MUST construct the message as follows:
1. The SEND message is constructed without the PSO as follows: 1. The SEND message is constructed without the PSO as follows:
A. If the Secure Proxy ND is locally generating the SEND message A. If the Secure Proxy ND is locally generating the SEND message
for a proxied address, the message is constructed as for a proxied address, the message MUST be constructed as
described in Neighbor Discovery for IP version 6 described in Neighbor Discovery for IP version 6
specification [RFC4861]. specification [RFC4861].
B. If the Secure Proxy ND is forwarding a SEND message, first B. If the Secure Proxy ND is forwarding a SEND message, first
the authenticity of the intercepted message is verified as the authenticity of the intercepted message MUST be verified
specified in SEND specification [RFC3971], Section 5. If the as specified in SEND specification [RFC3971], Section 5. If
SEND message is valid, any CGA or RSA option MUST be removed the SEND message is valid, any CGA or RSA option MUST be
from the message. The intercepted message is finally removed from the message. The intercepted message is finally
modified as described in Section 4 of the ND Proxy modified as described in Section 4 of the ND Proxy
specification [RFC4389]. specification [RFC4389].
C. If the Secure Proxy ND is forwarding a SEND message already C. If the Secure Proxy ND is forwarding a SEND message already
containing a PSO, first the authenticity of the intercepted containing a PSO, first the authenticity of the intercepted
message is verified as specified in Section 6.2.2 of this message is verified as specified in Section 5.2.2 of this
draft. If the SEND message is valid, the original PSO MUST specification. If the SEND message is valid, the original
be removed from the message. The intercepted message is PSO MUST be removed from the message. The intercepted
finally modified as described in Section 4 of the ND Proxy message is finally modified as described in Section 4 of the
specification[RFC4389]. ND Proxy specification [RFC4389].
2. Timestamp and Nonce options are included according to the rules 2. Timestamp and Nonce options MUST be included according to the
specified in SEND [RFC3971]. The value in the Timestamp option rules specified in SEND [RFC3971]. The value in the Timestamp
MUST be generated by the Proxy. If the proxy is forwarding a option MUST be generated by the Proxy. If the proxy is
message, the Nonce value in the proxied message MUST be the same forwarding a message, the Nonce value in the proxied message MUST
as in the forwarded message. be the same as in the forwarded message.
3. The Proxy Signature option is added as the last option in the 3. The Proxy Signature option MUST be added as the last option in
message. the message.
4. The data is signed as explained in Section 5.1. 4. 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
skipping to change at page 12, line 5 skipping to change at page 12, line 5
3. The Digital Signature field MUST have correct encoding. 3. The Digital Signature field MUST have correct encoding.
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. has been calculated as specified in Section 5.1.
5. Timestamp and Nonce options MUST be processed as specified in 5. Timestamp and Nonce options MUST be processed as specified in
[RFC3971] Section 5.3.4, except for replacing 'RSA Signature [RFC3971] Section 5.3.4, except for replacing 'RSA Signature
option' by 'PSO option'. option' by 'PSO option'.
6. Messages with the Override bit [RFC4861] set should override an 6. 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 if it was created as a result of
a RSA Signature option or a PSO option validation. When it is a RSA Signature option or a PSO option validation. When the
not set the advertisement will not update a cached link-layer Override bit is not set, the advertisement MUST NOT update a
address created securily by means of RSA Signature option or PSO cached link-layer address created securily by means of RSA
option validation. Signature option or PSO option validation.
Messages that do not pass all the above tests MUST be silently Messages that do not pass all the above tests MUST be silently
discarded if the host has been configured to accept only secured ND discarded if the host has been configured to accept only secured ND
messages. messages.
5.3. Proxying Link-Local Addresses 5.3. Proxying Link-Local Addresses
Secure Neighbor Discovery [RFC3971] relies on certificates to prove Secure Neighbor Discovery [RFC3971] relies on certificates to prove
that routers are authorized to announce a certain prefix. However, 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 router does not announce the
Link-Local prefix (fe80::/64). Hence, it is not required for a SEND Link-Local prefix (fe80::/64). Hence, it is not required for a SEND
certificate to hold a X.509 IP address extensions that authorizes the certificate to hold a X.509 extension for IP addresses that
fe80::/64 prefix. Some scenarios ([RFC4389], [RFC5213]) impose that authorizes the fe80::/64 prefix. However, some scenarios ([RFC4389],
the Secure ND proxy provides proxying function for the Link-Local [RFC5213]) impose that the Secure ND proxy provides proxying function
address of a node. When Secure ND proxy functionality on a Link- for the Link-Local address of a node. When Secure ND proxy
Local address is required, either a list of link-local addresses, or functionality for a Link-Local address is required, either a list of
the fe80::/64 prefix MUST be explicitly authorized to be proxied in link-local addresses, or the fe80::/64 prefix MUST be explicitly
the corresponding certificate. authorized to 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 for
which Secure Proxy ND Support for SEND can be applied. Note that the 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 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 directions, how the interaction with
non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on
the particular scenario considered. In the first two scenarios 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 generated in reaction to ND nodes. In the third one, ND message generation is trigged by the
messages being received by other interfaces of the proxied node. reception of ND messages 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
can be found in [I-D.ietf-csi-sndp-prob]. can be found in [I-D.ietf-csi-sndp-prob].
The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN) The Mobile IPv6 protocol (MIPv6) [RFC3775] 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 a 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).
The HA intercepts these packets acting as a ND proxy for this MN. The HA intercepts these packets acting as a ND proxy for this MN.
Lets assume that the nodes in the home link use SEND. When a secured When a NS is intercepted on the home link, the HA checks if the
NS is intercepted on the home link, the HA checks the validity of the Target address within the NS matches with any of the MN's Home
received message according to the rules stated in [RFC3971]. If the Address in the Binding Cache and if so, it replies with a Neighbor
message is valid, it checks if the Target address within the NS Advertisement (NA) constructed as described in [RFC4861], containing
matches with any of the MN's Home Address in the Binding Cache and if its own link layer address (HA_LL) as the Target Link Layer Address
so, it replies with a Neighbor Advertisement (NA) constructed as Option (TLLAO). Then a timestamp (generated by the proxy) and nonce
described in [RFC4861], so it contains its own link layer address (if appropriate, acccording to [RFC3971]), MUST be included.
(HA_LL) as the Target Link Layer Address Option (TLLAO), with a PSO Finally, a PSO option signing the message MUST be included as the
option signing the message, added as the last option of the message. 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] | |
skipping to change at page 14, line 37 skipping to change at page 14, line 37
|------------------------->| | |------------------------->| |
| | | | | |
| | tunnelled traffic | | | tunnelled 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 PSO (e.g.: the CN in the home A node receiving the NA containing the PSO (e.g.: the CN in the home
link, or a router) must have a certificate of the public key of the link, or a router) MUST apply the rules defined in Section 5.2.2.
HA acting as a Secure Proxy ND. To do so, a certificate for the HA Note that in this case the Override bit of the NA message is used to
could be made available through the Authorization Delegation control which messages should prevail each case: the message
Discovery process [RFC3971] performed at the home link, i.e. the generated by the proxy once the MN moves from the home network, or
devices responding to CPS messages should be configured to include in the MN if it comes back to the home link, as defined in the MIPv6
CPA messages information about the HA certificate. specification [RFC3775]
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 come back to the home
link, as defined in the MIPv6 specification [RFC3775]
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 an IP mobility management support for MNs protocol that provides an IP mobility management support for MNs
without requiring MNs being involved in the mobility related without requiring MNs being involved in the mobility related
signaling. The IP mobility management is totally hidden to the MN in signaling. The IP mobility management is totally hidden to the MN in
a Proxy Mobile IPv6 domain and is performed by two functional a Proxy Mobile IPv6 domain and is performed by two functional
entities: the Local Mobility Anchor (LMA) and the Mobile Access entities: the Local Mobility Anchor (LMA) and the Mobile Access
Gateway (MAG). Gateway (MAG).
When the MN connects to a new access link it will send a multicast 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, ICMPv6 Router Solicitation (RS). The MAG on the new access link,
upon detecting the MN's attachment, will signal the LMA for updating 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 the binding state of the MN (Proxy Binding Update - PBU) and once the
signaling is complete (it receives a Proxy Binding Ack - PBA), it signaling is completed (it receives a Proxy Binding Ack - PBA), it
will reply to the MN with a ICMPv6 Router Advertisement (RA) will reply to the MN with a ICMPv6 Router Advertisement (RA)
containing the home network prefix(es) that were assigned to that containing the home network prefix(es) that were assigned to that
mobility session, making the MN believe it is still on the same link mobility session, making the MN believe it is still on the same link
and not triggering the IPv6 address reconfiguration (figure and not triggering the IPv6 address reconfiguration (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 | |
skipping to change at page 16, line 49 skipping to change at page 16, line 15
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 configured on the specification requires the MAG's link-local address configured on the
link to which the MN is attached to, to be generated once by the LMA link to which the MN is attached to, to be generated once by the LMA
when the MN first attach to a PMIPv6 domain, and to be provided to 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 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 point of view, the MAG's link-local address remains constant for the
duration of that MN's session. duration of that MN's session.
Each MAG can be granted a certificate per each link-local address The approach described above and the current SEND specification are
expected by any MN that could attach to the link. However, the use incompatible since sharing the same link-local address on different
of Secure Proxy ND can greatly reduce the number of certificates MAGs would require all MAGs of a PMIPv6 domain to construct the CGA
needed. In this case, each MAG is configured to act as a proxy by and the RSA Signature option with the same public-private key pair,
means of a certification path from a trust anchor associated to the which is not acceptable from a security point of view.
PMIPv6 domain, authorizing each MAG to proxy securely ND messages.
When a secured RS message is issued by the MN, the MAG checks its Using different public-private key pairs on different MAGs would mean
validity according to the rules stated in [RFC3971]. If the message different MAGs use different CGAs as link-local address. Thus the
is valid, it replies with a RA with source address equal to the MAG serving MAG's link-local address changes after each handoff of the MN
link-local address associated to the MN in this PMIPv6 domain and its which is contradiction with the way MAG link-local address assignment
own link layer address as Source link-layer address, with the PSO occurs in a PMIPv6 domain.
option signing the message, added as the last option of the message.
When the MN receives this message, it may issue a CPS message in To provide SEND protection, each MAG is configured to act as a proxy
order to obtain the certification path associated to the public key by means of a certificate associated to the PMIPv6 domain,
of the PSO (or may have this certification path already available). authorizing each MAG to proxy securely ND messages. In addition, the
The MN node must be configured with a trust anchor related with the certificate must also authorize the MAG to advertise prefixes. Note
MAG's certificate. The MAG (or other device) could be configured to that the inclusion of multiple KeyPurposeId values is supported by
provide its certification path in a CPS message as a response to a [I-D.ietf-csi-send-cert].
CPA message issued by the MN. With this information, the MN can
validate the RS information, and use the same link-local address to
access to the MAG.
The MAG will intercept secured NS messages and reply with NA messages When a MAG replies to a RS with a RA, the source address MUST be
containing its own link layer address as the Target Link Layer equal to the MAG link-local address associated to the MN in this
Address Option (TLLAO), with a PSO option signing the message, added PMIPv6 domain and its own link layer address as Source link-layer
as the last option of the message. The same applies for Redirect address. Then a timestamp (generated by the proxy) and nonce (if
messages. appropriate, acccording to [RFC3971]), MUST be included. Finally, a
PSO 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.
A node receiving a message from the MAG containing the PSO MUST apply
the rules defined in 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 description of the problems for deploying SEND in this scenario
can be found in [I-D.ietf-csi-sndp-prob]. can be found in [I-D.ietf-csi-sndp-prob].
Link 1 Link 2 Link 1 Link 2
Host A ND Proxy (P) Host B Host A ND Proxy (P) Host B
| | | | | |
skipping to change at page 18, line 47 skipping to change at page 17, line 47
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 shall parse any IPv6 packet it receives on a proxy 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 interface to check whether it contains one of the following secured
ICMPv6 messages: NS, NA, RA, or Redirect. The Secure ND Proxy MUST ICMPv6 messages: NS, NA, 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 proxied the [RFC3971]. If the SEND message is valid, then it proxies the
original message with the following changes: original message with the following changes:
1. The message is processed according to [RFC4389]. This includes 1. The message MUST be processed according to [RFC4389]. This
changing the source link layer address will be the address of the includes changing the source link layer address to the address of
outgoing interface, maintaining the destination link layer the outgoing interface, maintaining the destination link layer
address as the address in the neighbor entry corresponding to the 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 within the payload (that is, in a Source Local Link
Address option - SLLAO, or a Target Local Link Address option - Address option - SLLAO, or a Target Local Link Address option -
TLLAO) is substituted with the link-layer address of the outgoing TLLAO) is substituted with the link-layer address of the outgoing
interface. interface.
2. Any CGA or RSA option is removed. 2. Any CGA or RSA option MUST be removed.
3. If a Nonce option existed in the original message, its value is 3. If a Nonce option existed in the original message, its value MUST
preserved in the proxied message. The Timestamp is generated by be preserved in the proxied message. The Timestamp MUST be
the proxy. generated by the proxy.
4. The PSO option is added as the last option in the message, 4. The PSO 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.
Moreover, when any other IPv6 unicast packet is received on a proxy When any other IPv6 unicast packet is received on a proxy interface,
interface, if it is not locally destined then it is forwarded if it is not locally destined then it is forwarded unchanged (other
unchanged (other than using a new link-layer header) to the proxy than using a new link-layer header) to the proxy interface for which
interface for which the next hop address appears in the neighbor the next hop address appears in the neighbor cache. If no neighbor
cache. If no neighbor cache entry is present, the ND proxy should cache entry is present, the ND proxy should queue the packet and
queue the packet and initiate a Neighbor Discovery signalling as if initiate a Neighbor Discovery signalling as if the ICMPv6 NS message
the ICMPv6 NS message were locally generated. were locally generated.
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 to configure at least one device per each proxied segment
(may be the proxy itself) to propagate the required certification (may be the proxy itself) 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.
While more robust mechanisms could be developed for securing the While more robust mechanisms could be developed for securing the
scenario described in [RFC4389], if hosts have been upgraded to apply scenario described in [RFC4389], if hosts have been upgraded to apply
the rules stated in Section 5.2.2, for example, to benefit from the rules stated in Section 5.2.2, for example to benefit from secure
secure support for other scenarios, the application of this mechanism support for other scenarios, the application of this mechanism is
is straighforward. straighforward.
7. Backward Compatibility with RFC3971 nodes and non-SEND nodes 7. Backward Compatibility with RFC3971 nodes and non-SEND nodes
In this section we discuss the interaction of Secure Proxy ND nodes In this section we discuss the interaction of Secure Proxy ND nodes
and SPND nodes with RFC3971 nodes and non-SEND nodes. and SPND nodes with RFC3971 nodes and non-SEND nodes.
7.1. Backward Compatibility with RFC3971 nodes 7.1. Backward Compatibility with RFC3971 nodes
RFC3971 nodes, i.e. SEND nodes not compliant with the modifications RFC3971 nodes, i.e. SEND nodes not compliant with the modifications
required in Section 5 cannot interpret correctly a PSO option required in Section 5 cannot interpret correctly a PSO option
skipping to change at page 20, line 30 skipping to change at page 19, line 30
intervention), in either direction, messages are generated according intervention), in either direction, messages are generated according
to the SEND specification [RFC3971], so these nodes interoperate to the SEND specification [RFC3971], so these nodes interoperate
seamlessly. 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 a RFC3971 node or
in an SPND node, without interoperability issues. in an SPND node, without interoperability issues.
7.2. Backward Compatibility with non-SEND nodes 7.2. Backward Compatibility with non-SEND nodes
Plain ND nodes receiving NDP packets silently discard PSO options, as Non-SEND nodes receiving NDP packets silently discard PSO options, as
specified in [RFC4861] for any unknown option. Therefore, these node specified in [RFC4861] for any unknown option. Therefore, these node
interpret messages proxied by a Secure Proxy ND as any other ND interpret messages proxied by a Secure Proxy ND 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 Proxy ND SHOULD support the use of secured and unsecured NDP A secure Proxy ND 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 proxing for unsecured NDP messages. A secure causes not to perform proxing for unsecured NDP messages. A secure
Proxy ND MAY also have a configuration option whereby it disables Proxy ND MAY also have a configuration option whereby it disables
secure ND proxying completely. This configuration SHOULD be switched secure ND proxying completely. This configuration SHOULD be switched
off by default, that is SEND is used. In the next paragraphs we off by default, that is SEND is used. In the next paragraphs we
discuss the recommended behavior of the Secure Proxy ND regarding to discuss the recommended behavior of the Secure Proxy ND regarding to
which protection level provide to proxied messages in a mixed the protection level to provide to proxied messages in a mixed
scenario involving SPND/RFC3971 nodes and non-SEND nodes. In scenario involving SPND/RFC3971 nodes and non-SEND nodes. In
particular, two different situations occur depending on if the particular, two different situations occur depending on if the
proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes. proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes.
As a rule of thumb, the Secure Proxy ND should only generate PSO As a rule of thumb, if the proxied nodes can return to the link in
options for nodes which have SEND capabilities (i.e. that they could which the proxy operates, the Secure Proxy ND MUST only generate PSO
use SEND to defend their messages if being in the same link than the options on behalf of nodes with SEND capabilities (i.e. that they
proxy, either RFC3971 nodes or SPND nodes). This is relevant to could use SEND to defend their messages if being in the same link
allow nodes preferring secured information over unsecured one, and than the proxy, either RFC3971 nodes or SPND nodes). This is
for executing the DAD procedure, as specified in [RFC3971]. relevant to allow nodes preferring secured information over unsecured
Therefore, the Secure Proxy ND SHOULD generate messages containing one, and for executing the DAD procedure, as specified in [RFC3971].
the PSO option for SPND and RFC3971 hosts, and SHOULD NOT generate Therefore, the Secure Proxy ND MUST generate messages containing the
messages containing the PSO option for non-SEND nodes. Note that ND PSO option for SPND and RFC3971 hosts, and MUST NOT generate messages
containing the PSO option for non-SEND nodes. Note that ND
advertisements in response to solicitations generated by a Secure advertisements in response to solicitations generated by a Secure
Proxy ND must be secured or not according to the previous Proxy ND must be secured or not according to the previous
considerations (i.e. to the nature of the proxied node), and not considerations (i.e. to the nature of the proxied node), and not
according to the secure or unsecure nature of the solicitation according to the secure or unsecure nature of the solicitation
message. message.
To apply this rule, we have to consider that depending on the To apply this rule, we have to consider that depending on the
application scenario the proxy may translate ND messages generated by application scenario the proxy may translate ND messages generated by
a node or synthetise ND messages on behalf of a node. a node or synthetise ND messages on behalf of a node that can return
to the link in which the Secure Proxy ND operates.
o For ND translated messages, the rule can be easily applied: only 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 Proxy ND according to the SEND messages validated in the Secure Proxy ND according to the SEND
specification [RFC3971] MUST be proxied securely by the inclusion specification [RFC3971] MUST be proxied securely by the inclusion
of a PSO option. Unsecured ND messages could be proxied if of a PSO option. Unsecured ND messages could be proxied if
unsecured operation is enabled in the proxy, but the message unsecured operation is enabled in the proxy, but the message
generated by the Secure Proxy ND for the received message MUST NOT generated by the Secure Proxy ND for the received message MUST NOT
include a PSO option. include a PSO option.
o For ND messages synthesised on behalf of remote nodes, different o For synthesizing ND messages on behalf of remote nodes, different
considerations should be made according to the particular considerations should be made according to the particular
application scenario. 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 for the proxy to know if the node could use SEND to
defend its address or not. A mismatch between the proxy and defend its address or not. A mismatch between the proxy and
proxied node behavior regarding to SEND operation would result proxied node behavior regarding to SEND operation would result
in unaproppriate operation. A HA including the PSO option for in unaproppriate operation. A HA including the PSO 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 ND message of the non-SEND MN if the to be more preferred than ND message of the non-SEND MN when
MN returns to the home link (even if the proxied messages have the MN returns to the home link (even if the proxied messages
the Override bit set to 1). Not using the PSO option for a have the Override bit set to 1). Not using the PSO option for
RFC3971 or SPND MN would make more vulnerable the address in 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 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 link (and would defeat the purpose of the Secure Proxy ND
mechanism). Therefore, in this case the HA must know the SEND mechanism). Therefore, in this case the HA MUST know the SEND
capabilities of the MN. capabilities of the MN, and MUST use PSO if the MN is a SPND or
RFC3971 host, and MUST NOT use PSO for non-SEND hosts.
* We can state the same for the Proxy Mobile IPv6 scenario as for * For the Proxy Mobile IPv6 scenario, we have to note that a node
the MIPv6 scenario. Note that a node moving from a link in moving from a link in which PSO has been used to protect a
which PSO has been used to protect a link-layer address to a link-layer address to a link in which ND messages are not
link in which ND messages are not SEND-enabled would prevent protected by SEND would prevent the MN from adquiring the new
the node from adquiring the new information until the information until the cached information expires. However, in
corresponding cache expires. However, in this case it is this case it is reasonable to consider that all MAGs provide
reasonable to consider that all MAGs provide the same security the same security for protecting ND messages, and that either
for protecting ND messages, and that either all MAGs will all MAGs will behave as Secure Proxy ND, or none, so
behave as Secure Proxy ND, or none, so configuration could be configuration could be easier.
easier.
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 Proxy
Signature Option (PSO) allowing a Secure Proxy ND to generate or Signature Option (PSO) allowing a Secure Proxy ND to generate or
modify a SEND message for a proxied address. An SPND node will only modify a SEND message for a proxied address. A SPND node will only
accept such a message if it includes a valid PSO generated by an accept such a message if it includes a valid PSO generated by an
authorized Secure Proxy ND. Such a message has equivalent protection authorized Secure Proxy ND. Such a message has equivalent protection
to the threats presented in section 9 of [RFC3971] as a message to the threats presented in section 9 of [RFC3971] as a message
signed with a RSA Signature option. signed with a RSA Signature option.
The security of proxied ND messages not including a PSO option is the The security of proxied ND messages not including a PSO option is the
same of an unsecured ND message. The security of a proxied ND 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 message received by a non-SEND host or RFC3971 host is the same of an
unsecured ND message. unsecured ND message.
skipping to change at page 23, line 31 skipping to change at page 22, line 31
proxy ND is authorized to issue ND signaling on behalf of nodes on proxy ND is authorized to issue ND signaling on behalf of nodes on
the subnet. Thus, a compromised proxy is able, like a compromised 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- router, to siphon off traffic from the host, or mount a man-in-the-
middle attack. However, when two on-link hosts communicate using middle attack. However, when two on-link hosts communicate using
their respective link-local addresses, the threats involved with a their respective link-local addresses, the threats involved with a
compromised router and a compromised proxy ND differs because the compromised router and a compromised proxy ND differs because the
router is not able to siphon off traffic exchanged between the hosts 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 or mount a man-in-the-middle attack, while the proxy ND can, even if
the hosts use SEND. the hosts use SEND.
The messages for which a Secure Proxy ND perform its function, and The messages for which a Secure Proxy ND 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 specially relevant if Secure Proxy ND is used for translating ND
messages from one link to another. messages from one link to another.
Proper configuration of when the PSO option must or must not be Proper configuration of when the PSO option must or must not be
included, depending on the proxied node being SEND or non-SEND may included, depending on the proxied nodes being SEND or non-SEND may
result in security considerations, as discussed in Section 7. result in security considerations which are discussed in Section 7.
Attacks to the timestamp of the secured ND message can be performed Attacks to the timestamp of the secured ND message can be performed
as describe in section 7.3 of [I-D.ietf-csi-sndp-prob]. as described in section 7.3 of [I-D.ietf-csi-sndp-prob].
9. IANA Considerations 9. IANA Considerations
IANA is requested to allocate: IANA is requested to allocate:
A new IPv6 Neighbor Discovery Option type for the PSO, as TBA. A new IPv6 Neighbor Discovery Option type for the PSO, as TBA.
The value need to be allocated from the namespace specified in the The value need to be allocated from the namespace specified in the
IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at
http://www.iana.org/assignments/icmpv6-parameters. http://www.iana.org/assignments/icmpv6-parameters.
A new 128-bit value under the CGA Message Type [RFC3972] A new 128-bit value under the CGA Message Type [RFC3972]
namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-csi-send-cert] [I-D.ietf-csi-send-cert]
Gagliano, R., Krishnan, S., and A. Kukec, "Certificate Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
profile and certificate management for SEND", profile and certificate management for SEND",
draft-ietf-csi-send-cert-02 (work in progress), draft-ietf-csi-send-cert-03 (work in progress),
February 2010. March 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 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
 End of changes. 55 change blocks. 
171 lines changed or deleted 169 lines changed or added

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