draft-ietf-csi-proxy-send-04.txt | draft-ietf-csi-proxy-send-05.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: Experimental QUALCOMM Inc. | Intended status: Experimental QUALCOMM Inc. | |||
Expires: December 2, 2010 M. Bonola | Expires: April 1, 2011 M. Bonola | |||
Rome Tor Vergata University | Rome Tor Vergata University | |||
A. Garcia-Martinez | A. Garcia-Martinez | |||
UC3M | UC3M | |||
May 31, 2010 | September 28, 2010 | |||
Secure Proxy ND Support for SEND | Secure Proxy ND Support for SEND | |||
draft-ietf-csi-proxy-send-04 | 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 a ND message is the | |||
owner of the address from which the message is sent, so that it is in | owner of the address from which the message is sent and/or posses a | |||
possession of the private key used to generate the digital signature | key which authorizes the node to act as a router, so that it is in | |||
on the message. This means that the Proxy ND signaling performed by | possession of the private key or keys used to generate the digital | |||
nodes that do not possess knowledge of the address owner's private | signature on each message. This means that the Proxy ND signaling | |||
key cannot be secured using SEND. This document extends the current | performed by nodes that do not possess knowledge of the address | |||
SEND specification in order to secure Proxy ND operation. | owner's private key and/or knowledge of a router's key cannot be | |||
secured using SEND. This document extends the current SEND | ||||
specification in order to secure Proxy ND operation. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted 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). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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." | |||
This Internet-Draft will expire on December 2, 2010. | This Internet-Draft will expire on April 1, 2011. | |||
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 26 | skipping to change at page 2, line 27 | |||
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
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 . . . . . . . . . . . . . . 13 | |||
6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 13 | 6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 14 | |||
6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 13 | 6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 14 | |||
6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 14 | 6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 15 | |||
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 17 | 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 18 | |||
7. Backward Compatibility with RFC3971 nodes and non-SEND | 7. Backward Compatibility with RFC3971 nodes and non-SEND | |||
nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 19 | 7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 20 | |||
7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 19 | 7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 20 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
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 | |||
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 a ND message is the owner of the address from which the | |||
message is sent, so that it is in possession of the private key used | message is sent and/or posses a key which authorizes the node to act | |||
to generate the digital signature on the message. This means that | as a router, so that it is in possession of the private key or keys | |||
the Proxy ND signaling performed by nodes that do not possess | used to generate the digital signature on each message. This means | |||
knowledge of the address owner's private key cannot be secured using | that the Proxy ND signaling performed by nodes that do not possess | |||
SEND. | knowledge of the address owner's private key and/or knowledge of a | |||
router's key cannot be secured using SEND. | ||||
This document extends the current SEND specification with support for | 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 extension as "Secure | |||
Proxy ND Support for SEND". | Proxy ND Support for SEND". | |||
3. Terminology | 3. Terminology | |||
Secure ND Proxy | Secure ND Proxy | |||
A node authorized to either modify or generate a SEND message | A node authorized to secure a Neighbor Discovery Protocol (NDP) | |||
without knowing the private key related to the source address of | message without knowing the private key related to the source | |||
the ICMPv6 ND message. | address of the node, or the key related to the router | |||
authorization, for which the node acts on behalf. | ||||
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 only the ND protocol defined in [RFC4861] | specification but uses the ND protocol defined in [RFC4861] and | |||
and [RFC4862], without security. | [RFC4862], without additional security. | |||
RFC3971 node | RFC3971 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 only 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 | 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 | ||||
A NDP message issued by a Secure ND Proxy as a result of a | ||||
received NDP message originated by the owner of the address or | ||||
originated by another node acting on behalf of the owner of the | ||||
address. | ||||
Synthetic NDP message | ||||
A NDP message issued by a Secure ND Proxy that is not the result | ||||
of a received NDP message. | ||||
4. Secure Proxy ND Overview | 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 a 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 turns 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 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, Secure Proxy ND certificates | |||
defined for authorizing proxies. The inclusion of the proxy | include one or more KeyPurposeId values which can be used for | |||
authorization value allows the certificate owner to perform | authorizing proxies to sign RA and Redirect messages, or to sign | |||
proxying of SEND messages for a range of addresses indicated in | NA, NS or RS messages on behalf or other nodes. The inclusion of | |||
the same certificate. This certificate can be exchanged through | this value allows the certificate owner to perform proxying of | |||
the Authorization Delegation Discovery process defined in | SEND messages for a range of addresses indicated in the same | |||
[RFC3971]. | 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 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's certificate. When a ND message contains a PS option, | |||
it MUST NOT contain CGA and RSA Signature options. This option | it MUST NOT contain CGA or RSA Signature options. This option | |||
can be appended to any ND message: NA, NS, RS, RA and Redirect. | MUST be appended to any NDP message (NA, NS, RS, RA and Redirect) | |||
to secure it. | ||||
o A modification of the SEND processing rules for all ND messages: | 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 valid Proxy Signature option is validated, it is | containing a Proxy Signature option is validated, it is considered | |||
considered as 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 which proxies ND messages on behalf of a node | |||
can use the PS option to protect the proxied messages. This | can use the PS option to protect the proxied messages. This | |||
Secure ND Proxy becomes part of the trusted infrastructure just | Secure ND Proxy 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 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 [I-D.ietf-csi-send-cert]) | |||
and must apply the modified processing rules specified in this | and MUST apply the modified processing rules specified in this | |||
document. We call these nodes 'SPND nodes'. Note that the rules | document. We call these nodes 'SPND nodes'. Note that the rules | |||
for generating ND messages in SPND nodes do not change, so these | for generating ND messages in SPND nodes do not change, so these | |||
nodes behave as defined in [RFC3971] for sending ND messages. | nodes behave as defined in [RFC3971] when they send ND messages. | |||
o To allow SPND nodes to know the certificate path required to | 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] are extended to support the certificate format specified | [RFC3971] are extended to support the certificate format specified | |||
in [I-D.ietf-csi-send-cert], and are configured with the | in [I-D.ietf-csi-send-cert], 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 differentiate between an | ensure that the receiving node can identify an authorized proxy | |||
authorized proxy generating or forwarding a SEND message for a | generating a translated or synthetic SEND message for a proxied | |||
proxied address, and a malicious node doing the same. | address. | |||
This is accomplished by signing the message with the public key of | This is accomplished by signing the message with a private key of the | |||
the authorized Secure ND Proxy. The signature of the ND Proxy is | authorized Secure ND Proxy. The signature of the ND Proxy is | |||
included in a new option called Proxy Signature (PS) option. The | included in a new option called Proxy Signature (PS) option. The | |||
signature is performed over all the NDP options present in the | signature is performed over all the Neighbor Discovery Protocol (NDP) | |||
message and the PS option is appended as the last option in the | options present in the message and the PS option is appended as the | |||
message. | last 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 public key-based signatures to be | |||
attached to NDP messages. The format of the PS option is described | attached to NDP messages. The format of the PS option is described | |||
in the following diagram: | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 10, line 22 | skipping to change at page 10, line 22 | |||
the PKCS#1 v1.5 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 | |||
The modifications described in the following section applies when a | ||||
SEND message contains the PS option, i.e. the message was sent by a | ||||
Secure ND Proxy. | ||||
This specification modifies the sender and receiver processing rules | 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 ICMPv6 message sent by a Secure ND Proxy for a proxied address MUST | A Secure ND Proxy MUST NOT use a key to sign NDP message types which | |||
contain a PS option and MUST NOT contain either CGA or RSA Signature | do not correspond to the authorization granted to the considered key. | |||
options. | NA, NS and RS messages MUST be signed with a key corresponding to a | |||
Secure Proxy ND certificate with a KeyPurposeId value | ||||
[I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source | ||||
addresses of the messages MUST be encompassed in the prefix | ||||
associated to the certificate. RA and Redirect messages MUST be | ||||
signed with a key corresponding to a Secure Proxy ND certificate with | ||||
a KeyPurposeId value of id-kp-sendProxiedRouter. The prefix included | ||||
in the RA message for on-link determination and/or stateless address | ||||
autoconfiguration, and the Target Address of the Redirect message, | ||||
MUST be encompassed in the prefix associated to that certificate. | ||||
A Secure ND Proxy sending a SEND message with the PS option MUST | A secured NDP message sent by a Secure ND Proxy for a proxied address | |||
construct the message as follows: | MUST contain a PS option and MUST NOT contain either CGA or RSA | |||
Signature options. Section 7 discusses in which cases a NDP message | ||||
has to be secured in an scenario including non-SEND nodes. | ||||
A Secure ND Proxy sending a secured message on behalf of other node | ||||
MUST construct the message as follows: | ||||
1. The SEND message is constructed without the PS option as follows: | 1. The SEND message is constructed without the PS option as follows: | |||
A. If the Secure ND Proxy is locally generating the SEND message | A. If the Secure ND Proxy is generating a synthetic SEND message | |||
for a proxied address, the message MUST be constructed as | 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 ND Proxy is forwarding a SEND message, first | B. If the Secure ND Proxy is generating a translated SEND | |||
the authenticity of the intercepted message MUST be verified | message, first the authenticity of the intercepted message | |||
as specified in SEND specification [RFC3971], Section 5. If | MUST be verified as specified in SEND specification | |||
the SEND message is valid, any CGA or RSA option MUST be | [RFC3971], Section 5. If the SEND message is valid, any CGA | |||
removed from the message. The intercepted message is finally | or RSA option MUST be removed from the message. The | |||
modified as described in Section 4 of the ND Proxy | intercepted message is finally modified as described in | |||
specification [RFC4389]. | Section 4 of the ND Proxy specification [RFC4389]. | |||
C. If the Secure ND Proxy is forwarding a SEND message already | C. If the Secure ND Proxy is translating a SEND message already | |||
containing a PS option, first the authenticity of the | containing a PS option, first the authenticity of the | |||
intercepted message is verified as specified in Section 5.2.2 | intercepted message is verified as specified in Section 5.2.2 | |||
of this specification. If the SEND message is valid, the | of this specification. If the SEND message is valid, the | |||
original PS option MUST be removed from the message. The | original PS option MUST be removed from the message. The | |||
intercepted message is finally modified as described in | intercepted message is finally modified as described in | |||
Section 4 of the ND Proxy specification [RFC4389]. | Section 4 of the ND Proxy specification [RFC4389]. | |||
2. Timestamp and Nonce options MUST be included according to the | 2. 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 | |||
forwarding a message, the Nonce value in the proxied message MUST | translating a message which includes a Nonce, the Nonce value in | |||
be the same as in the forwarded message, otherwise it is | the proxied message MUST be the same as in the intercepted | |||
generated by the proxy. | message. If the proxy is synthesizing a solicitation message, | |||
the Nonce value MUST be generated by the proxy. If the proxy is | ||||
synthesizing an advertisement message, the Nonce value MUST | ||||
correspond to the solicitation message to which the proxy is | ||||
responding. | ||||
3. The Proxy Signature option MUST be added as the last option in | 3. 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. | 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 | |||
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 [RFC3971] Section 6.3) between | A valid certification path (see [I-D.ietf-csi-send-cert] Section | |||
the receiver's trust anchor and the sender's public key MUST be | 9) between the receiver's trust anchor and the sender's public | |||
known. The Secure Proxy ND's X509v3 certificate MUST contain a | key MUST be known. The Secure Proxy ND's X509v3 certificate MUST | |||
extended key usage extension including the KeyPurposeId value for | contain an extended key usage extension including the appropriate | |||
the proxy authorization. | KeyPurposeId value and prefix for the message to validate: | |||
3. The Digital Signature field MUST have correct encoding. | * For RA messages, a KeyPurposeId value of id-kp- | |||
sendProxiedRouter MUST exist for the certificate, and the | ||||
prefix included in the RA message for on-link determination | ||||
and/or stateless address autoconfiguration MUST be encompassed | ||||
in the prefix associated to that certificate. | ||||
* For Redirect messages, a KeyPurposeId value of id-kp- | ||||
sendProxiedRouter MUST exist for the certificate, and the | ||||
prefix included in the Target Address of the Redirect message | ||||
MUST be encompassed in the prefix associated to that | ||||
certificate. | ||||
* For NA, NS and RS messages, a KeyPurposeId value of id-kp- | ||||
sendProxiedOwner MUST exist for the certificate, and the | ||||
source addresses of the messages MUST be encompassed in the | ||||
prefix associated to the certificate. | ||||
If any of these tests fails, the verification fails. | ||||
3. The Digital Signature field MUST have correct encoding, otherwise | ||||
the verification of the message including the PS option fails. | ||||
4. The Digital Signature verification MUST show that the signature | 4. The Digital Signature verification MUST show that the signature | |||
has been calculated as specified in Section 5.1. | has been calculated as specified in Section 5.1, otherwise the | |||
verification of the message including the PS option fails. | ||||
5. The Nonce option MUST be processed as specified in [RFC3971] | 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' by 'PS | |||
option'. | option'; if these tests fail, the verification of the message | |||
including the PS option fails. | ||||
6. The Timestamp option MUST be processed as specified in [RFC3971] | 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' by 'PS | |||
option'. The receiver SHOULD store the peer-related timing | option'. If these tests fail, the verification of the message | |||
information specified in [RFC3971] Section 5.3.4.1 and 5.3.4.2 | including the PS option fails. The receiver SHOULD store the | |||
(RDlast, TSlast) separately for each different proxy (which can | peer-related timing information specified in [RFC3971] Section | |||
be identified by the different Key Hash values of the proxied | 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each | |||
message) and separately from the timing information associated to | different proxy (which could be identified by the different Key | |||
the IP of node for which the message is proxied. In this way, a | Hash values of the proxied message) and separately from the | |||
message received for the first time from a proxy (i.e. for which | timing information associated to the IP address of a node for | |||
there is no information stored in the cache) for which the | which the message is proxied. In this way, a message received | |||
Timestamp option is checked, SHOULD be checked as messages | for the first time from a proxy (i.e. for which there is no | |||
received from new peers (as in [RFC3971] section 5.3.4.2). | information stored in the cache) for which the Timestamp option | |||
is checked, SHOULD be checked as a message received from a new | ||||
peer (as in [RFC3971] section 5.3.4.2). | ||||
7. Messages with the Override bit [RFC4861] set MUST override an | 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 if it was created as a result of | |||
a RSA Signature option or a PS option validation. When the | a RSA Signature option or a PS option validation. When the | |||
Override bit is not set, the advertisement MUST NOT update a | Override bit is not set, the advertisement MUST NOT update a | |||
cached link-layer address created securily by means of RSA | cached link-layer address created securely by means of RSA | |||
Signature option or PS option validation. | Signature option or PS option validation. | |||
Messages that do not pass all the above tests MUST be silently | Messages for which the verification fails MUST be silently discarded | |||
discarded if the host has been configured to accept only secured ND | if the node has been configured to accept only secured ND messages. | |||
messages. | The messages MAY be accepted if the host has been configured to | |||
accept both secured and unsecured messages but MUST be treated as an | ||||
unsecured message. | ||||
5.3. Proxying Link-Local Addresses | 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 routers do 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 extension for IP addresses that | certificate to hold a X.509 extension for IP addresses that | |||
authorizes the fe80::/64 prefix. However, some Secure Proxy ND | authorizes the fe80::/64 prefix. However, some Secure Proxy ND | |||
scenarios ([RFC4389], [RFC5213]) impose providing the proxying | scenarios ([RFC4389], [RFC5213]) impose providing the proxying | |||
function for the Link-Local address of a node. When Secure ND proxy | function for the Link-Local address of a node. When Secure ND proxy | |||
functionality for a Link-Local address is required, either a list of | functionality for a Link-Local address is required, either a list of | |||
link-local addresses, or the fe80::/64 prefix MUST be explicitly | link-local addresses, or the fe80::/64 prefix MUST be explicitly | |||
authorized to be proxied in 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 direction, 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 message generation is trigged by the | nodes. In the third one, ND messages are translated from the | |||
reception of ND messages 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 | |||
can be found in [I-D.ietf-csi-sndp-prob]. | is presented in [I-D.ietf-csi-sndp-prob]. | |||
The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN) | 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. | To deploy Secure Proxy ND in this scenario, i.e. to secure the HA | |||
When a NS is intercepted on the home link, the HA checks if the | operation, a Secure Proxy ND certificate with a KeyPurposeId value of | |||
Target address within the NS matches with any of the MN's Home | id-kp-sendProxiedOwner for the prefix of the home link is required. | |||
Address in the Binding Cache and if so, it replies with a Neighbor | The Secure ND Proxy is configured with the private key associated to | |||
Advertisement (NA) constructed as described in [RFC4861], containing | this certificate. When a NS is intercepted by the HA on the home | |||
its own link layer address (HA_LL) as the Target Link Layer Address | link, the HA checks if the Target address within the NS matches with | |||
Option (TLLAO). Then a timestamp (generated by the proxy) and nonce | any of the MN's Home Address in the Binding Cache and if so, it | |||
(if appropriate, according to [RFC3971]), MUST be included. Finally, | replies with a Neighbor Advertisement (NA) constructed as described | |||
a PS option signing the message MUST be included as the last option | in [RFC4861], containing its own link-layer address (HA_LL) as the | |||
of the message. | Target Link Layer Address Option (TLLAO). Then a timestamp | |||
(generated by the proxy) and nonce (if appropriate, according to | ||||
[RFC3971]), MUST be included. Finally, a PS option signing the | ||||
message MUST be included as the last option of the message. | ||||
Node (N) Home Agent (HA) Mobile Node (MN) | 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 29 | skipping to change at page 15, line 29 | |||
| 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 | | | |||
|------------------------->| | | |------------------------->| | | |||
| | | | | | | | |||
| | tunnelled 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 each case: | message is used to control which messages should prevail on each | |||
the message generated by the proxy once the MN moves from the home | case: the message generated by the proxy when the MN moves from the | |||
network, or the MN if it comes back to the home link, as defined in | home network, or the MN if it comes back to the home link, as defined | |||
the MIPv6 specification [RFC3775] | 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 IP mobility management support for MNs without | |||
without requiring MNs being involved in the mobility related | requiring MNs being involved in the mobility related signaling. The | |||
signaling. The IP mobility management is totally hidden to the MN in | IP mobility management is totally hidden to the MN in a Proxy Mobile | |||
a Proxy Mobile IPv6 domain and is performed by two functional | IPv6 domain and it is performed by two functional entities: the Local | |||
entities: the Local Mobility Anchor (LMA) and the Mobile Access | 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 sends a muliticast | |||
ICMPv6 Router Solicitation (RS). The MAG on the new access link, | Router Solicitation (RS). The MAG on the new access link, upon | |||
upon detecting the MN's attachment, will signal the LMA for updating | detecting the MN's attachment, signals the LMA requesting an update | |||
the binding state of the MN (Proxy Binding Update - PBU) and once the | of the binding state of the MN (by means of a Proxy Binding Update - | |||
signaling is completed (it receives a Proxy Binding Ack - PBA), it | PBU). Once the signaling is completed (it receives a Proxy Binding | |||
will reply to the MN with a ICMPv6 Router Advertisement (RA) | Ack - PBA), the MAG replies to the MN with a Router Advertisement | |||
containing the home network prefix(es) that were assigned to that | (RA) containing the home network prefix(es) that were assigned to | |||
mobility session, making the MN believe it is still on the same link | that mobility session, making the MN believe it is still on the same | |||
and not triggering the IPv6 address reconfiguration (Figure 3). | link, so the IPv6 address reconfiguration procedure is not triggered | |||
(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 8 | skipping to change at page 17, line 8 | |||
| 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 configured on the | specification requires the MAG's link-local address on the link to | |||
link to which the MN is attached to, to be generated by the LMA when | which the MN is attached to be generated by the LMA when the MN first | |||
the MN first attach to a PMIPv6 domain, and to be provided to the new | attaches to a PMIPv6 domain, and to be provided to the new MN's | |||
MN's serving MAG after each handoff. Thus, from the MN's point of | serving MAG after each handoff. Thus, from the MN's point of view, | |||
view, the MAG's link-local address remains constant for the duration | the MAG's link-local address remains constant for the duration of | |||
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 acceptable from a security point of view. | which is not an acceptable security policy. | |||
Using different public-private key pairs on different MAGs would mean | Using different public-private key pairs on different MAGs would mean | |||
different MAGs use different CGAs as link-local address. Thus the | different MAGs use different CGAs as link-local address. Thus the | |||
serving MAG's link-local address changes after each handoff of the MN | serving MAG's link-local address would change after each handoff of | |||
which is contradiction with the way MAG link-local address assignment | the MN, which is in contradiction with the way MAG link-local address | |||
occurs in a PMIPv6 domain. | assignment occurs in a PMIPv6 domain. | |||
To provide SEND protection, each MAG is configured to act as a proxy | To provide SEND protection, each MAG MUST be configured to act as a | |||
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 ND messages. In addition, the | authorizing each MAG to proxy securely NA and RS messages by means of | |||
certificate must also authorize the MAG to advertise prefixes. Note | a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the | |||
that the inclusion of multiple KeyPurposeId values is supported by | certificate MUST also authorize the MAG to advertise prefixes by | |||
[I-D.ietf-csi-send-cert]. | associating to the same certificate a KeyPurposeId value of id-kp- | |||
sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId | ||||
values is supported by [I-D.ietf-csi-send-cert]. | ||||
When a MAG replies to a RS with a RA, the source address MUST be | When a MAG replies to a RS with a RA, the source address MUST be | |||
equal to the MAG link-local address associated to the MN in this | equal to the MAG link-local address associated to the MN in this | |||
PMIPv6 domain and its own link layer address as Source link-layer | PMIPv6 domain, with its own link-layer address as Source link-layer | |||
address. Then a timestamp (generated by the proxy) and nonce (if | address. Then a timestamp (generated by the proxy) and nonce (if | |||
appropriate, according to [RFC3971]), MUST be included. Finally, a | appropriate, according to [RFC3971]), MUST be included. Finally, a | |||
PS option signing the message MUST be included as the last option of | PS option signing the message MUST be included as the last option of | |||
the message. This procedure is followed for any other ND message | the message. This procedure is followed for any other ND message | |||
that could be generated by the MAG to a MN. | that could be generated by the MAG to the MN. | |||
A node receiving a message from the MAG containing the PS option MUST | A node receiving a message from the MAG containing the PS option MUST | |||
apply the rules defined in Section 5.2.2. Note that unsolicited | apply the processing rules defined in Section 5.2.2. Note that | |||
messages sent by MAG are validated by the host according to timestamp | unsolicited messages sent by the MAG should be validated by the host | |||
values specific to the MAG serving the link, not to any other MAG to | according to timestamp values specific to the MAG serving the link, | |||
which the host has been connected before in other links. | not to any other MAG to which the host has been connected before in | |||
other links, according to processing step number 6 of Section 5.2.2. | ||||
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy | 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]. | is presented 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 | |||
| | | | | | | | |||
| 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 | | | |||
skipping to change at page 17, line 41 | skipping to change at page 18, line 41 | |||
| | 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: Proxy ND operations | 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 shall 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 secured | interface to check whether it contains one of the following NDP | |||
ICMPv6 messages: NS, NA, 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]. 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 MUST be processed according to [RFC4389]. This | 1. The message MUST be processed according to [RFC4389]. This | |||
includes changing the source link layer address to the address of | includes changing the source link-layer address to the address of | |||
the 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 MUST be removed. | 2. Any CGA or RSA option MUST be removed. | |||
3. If a Nonce option existed in the original message, its value MUST | 3. If a Nonce option existed in the original message, its value MUST | |||
be preserved in the proxied message. The Timestamp MUST be | be preserved in the proxied message. The Timestamp MUST be | |||
generated by the proxy. | generated by the proxy. | |||
4. The PS option MUST be added as the last option in the message, | 4. The PS option MUST be added as the last option in the message, | |||
signing all the information contained so far in the message. | signing all the information contained so far in the message. To | |||
be able to sign any NS, NA, RS, RA o Redirect message, the key | ||||
used must correspond to a certificate with KeyPurposeId values of | ||||
id-kp-sendProxiedOwner and id-kp-sendProxiedRouter. | ||||
When any other IPv6 unicast packet is received on a proxy interface, | 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 ND proxy should queue the packet and | cache entry is present, the Secure ND Proxy SHOULD queue the packet | |||
initiate a Neighbor Discovery signalling as if the ICMPv6 NS message | and initiate a Neighbor Discovery signaling as if the NS message were | |||
were locally generated. | 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. | |||
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 ND Proxies and | In this section we discuss the interaction of Secure ND Proxies and | |||
SPND nodes with RFC3971 nodes and non-SEND nodes. | SPND nodes with RFC3971 nodes and non-SEND nodes. As stated in | |||
[RFC3971], network operators may want to run a mixture of nodes | ||||
accepting secured and unsecured NDP messages at the same time. | ||||
Secure ND Proxies and SPND nodes SHOULD support the use of secured | ||||
and unsecured NDP messages at the same time. | ||||
7.1. Backward Compatibility with RFC3971 nodes | 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 PS option received | required in Section 5, cannot interpret correctly a PS option | |||
in a proxied ND message. These SEND nodes silently discard the PS | received in a proxied ND message. These SEND nodes silently discard | |||
option, as specified in [RFC4861] for any unknown option. As a | the PS option, as specified in [RFC4861] for any unknown option. As | |||
result, these messages will be treated as unsecured as described in | a result, these messages will be treated as unsecured as described in | |||
Section 8 "Transitions Issues" of the SEND specification [RFC3971]. | Section 8 "Transitions Issues" of the SEND specification [RFC3971]. | |||
When RFC3971 nodes and SPND nodes exchange ND messages (without proxy | When RFC3971 nodes and SPND nodes exchange ND messages (without proxy | |||
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 (note that the | |||
difference between RFC3971 nodes and SPND nodes only affect to the | ||||
ability to process received NDP messages containing a PS option, not | ||||
in the way they generate messages secured by SEND). | ||||
7.2. Backward Compatibility with non-SEND nodes | 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 proxing for unsecured NDP messages. A Secure | causes not to perform proxying for unsecured NDP messages. A Secure | |||
ND Proxy MAY also have a configuration option whereby it disables | ND Proxy 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 by default. In the next | off by default, that is security is provided by default. In the next | |||
paragraphs we discuss the recommended behavior of the Secure ND Proxy | paragraphs we discuss the recommended behavior of the Secure ND Proxy | |||
regarding to the protection level to provide to proxied messages in a | regarding to the protection level to provide to proxied messages in a | |||
mixed scenario involving SPND/RFC3971 nodes and non-SEND nodes. In | mixed 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, 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. that they | |||
could use SEND to defend their messages if being in the same link | could use SEND to defend their messages if present on the same link | |||
than the proxy, either RFC3971 nodes or SPND nodes). This is | as the proxy, i.e. being either RFC3971 nodes or SPND nodes). This | |||
relevant to allow nodes preferring secured information over unsecured | is relevant to allow nodes to prefer secured information over | |||
one, and for executing the DAD procedure, as specified in [RFC3971]. | unsecured one, and to properly execute the DAD procedure, as | |||
Therefore, the Secure ND Proxy MUST generate messages containing the | specified in [RFC3971]. Therefore, in this case the Secure ND Proxy | |||
PS option for SPND and RFC3971 hosts, and MUST NOT generate messages | MUST synthesize/translate messages containing the PS option for SPND | |||
and RFC3971 hosts, and MUST NOT synthesize/translate messages | ||||
containing the PS option for non-SEND nodes. Note that ND | containing the PS option for non-SEND nodes. Note that ND | |||
advertisements in response to solicitations generated by a Secure ND | advertisements in response to solicitations generated by a Secure ND | |||
Proxy must be secured or not according to the previous considerations | Proxy must be secured or not according to the previous considerations | |||
(i.e. to the nature of the proxied node), and not according to the | (i.e. to the nature of the proxied node), and not according to the | |||
secure or unsecure nature of the solicitation message. | secure or unsecure nature of the solicitation message. | |||
To apply this rule, we have to consider that depending on the | In order to apply this rule, the Secure ND Proxy needs to know the | |||
application scenario the proxy may translate ND messages generated by | security capabilities of the proxied node. The way this information | |||
a node or synthetise ND messages on behalf of a node that can return | is acquired depends on the application scenario, and it is discussed | |||
to the link in which the Secure ND Proxy operates. | next: | |||
o For translating ND messages for nodes that can arrive to the link | o For scenarios in which ND messages are translated for nodes that | |||
in which the proxy operates, the rule can be easily applied: only | can arrive to the link in which the proxy operates, the rule can | |||
messages validated in the Secure ND Proxy according to the SEND | be easily applied: only for messages validated in the Secure ND | |||
specification [RFC3971] MUST be proxied securely by the inclusion | Proxy according to the SEND specification [RFC3971], or according | |||
of a PS option. Unsecured ND messages could be proxied if | to Section 5.2.2 of this specification for messages containing a | |||
unsecured operation is enabled in the proxy, but the message | PS option (which means that another proxy previously checked that | |||
generated by the Secure ND Proxy for the received message MUST NOT | the original message was secured), the message MUST be proxied | |||
include a PS option. | securely by the inclusion of a PS option. Unsecured ND messages | |||
could be proxied if unsecured operation is enabled in the proxy, | ||||
but the message generated by the Secure ND Proxy for the received | ||||
message MUST NOT include a PS option. | ||||
o For synthesizing ND messages on behalf of remote nodes, different | o For scenarios in which ND messages are synthesized on behalf of | |||
considerations should be made according to the particular | remote nodes, different considerations should be made according to | |||
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 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 HA including the PS option for | |||
proxied node behavior regarding to SEND operation would result | ||||
in unaproppriate operation. 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 ND message of the non-SEND MN when | to be more preferred than a ND message of the non-SEND MN when | |||
the MN returns to the home link (even if the proxied messages | 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 a | |||
RFC3971 or SPND MN would make more vulnerable the address in | RFC3971 or SPND MN would make the address in the home link more | |||
the home link when the MN is away than when it is in the home | vulnerable when the MN is away than when it is in the home | |||
link (and would defeat the purpose of the Secure Proxy ND | link, defeating the purpose of the Secure Proxy ND mechanism. | |||
mechanism). Therefore, in this case the HA MUST know the SEND | Therefore, in this case the HA MUST know the SEND capabilities | |||
capabilities of the MN, and MUST use PS option if the MN is a | of the MN, MUST use the PS option if the MN is a SPND or | |||
SPND or RFC3971 host, and MUST NOT use PS option for non-SEND | RFC3971 host, and MUST NOT use PS option for non-SEND hosts. | |||
hosts. | ||||
* For the Proxy Mobile IPv6 scenario, we have to note that a node | * For the Proxy Mobile IPv6 scenario, a node moving from a link | |||
moving from a link in which PS option has been used to protect | in which PS option has been used to protect a link-layer | |||
a link-layer address to a link in which ND messages are not | address to a link in which ND messages are not protected by | |||
protected by SEND would prevent the MN from adquiring the new | SEND would prevent the MN from adquiring the new information | |||
information until the cached information expires. However, in | until the cached information expires. However, in this case it | |||
this case it is reasonable to consider that all MAGs provide | is reasonable to consider that all MAGs provide the same | |||
the same security for protecting ND messages, and that either | security for protecting ND messages, and that either all MAGs | |||
all MAGs will behave as Secure ND Proxy, or none, so | will behave as Secure ND Proxy, or none, so configuration is | |||
configuration could be easier. | expected to be 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 (PS) Option allowing a Secure ND Proxy to generate or | Signature (PS) option allowing a Secure ND Proxy to synthesize or | |||
modify a SEND message for a proxied address. A SPND node will only | translate a SEND message for a proxied address, to Redirect traffic | |||
accept such a message if it includes a valid PS option generated by | for given target addresses or to advertise prefix information by | |||
an authorized Secure ND Proxy. Such a message has equivalent | means of RA messages. A SPND node only accepts such a message if it | |||
protection to the threats presented in section 9 of [RFC3971] as a | includes a valid PS option generated by a properly authorized Secure | |||
message signed with a RSA Signature option. | ND Proxy (with a certificate containing a KeyPurposeId with value id- | |||
kp-sendProxiedOwner for protecting NA, NS and RS messages, or | ||||
containing a KeyPurposeId value of id-kp-sendProxiedRouter for | ||||
protecting RA and Redirect messages). Such a message has equivalent | ||||
protection against the threats presented in section 9 of [RFC3971] as | ||||
a message signed with a RSA Signature option. | ||||
The security of proxied ND messages not including a PS option is the | The security of proxied ND messages not including a PS option is the | |||
same of an unsecured ND message. The security of a proxied ND | 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 of an | message received by a non-SEND host or RFC3971 host is the same as an | |||
unsecured ND message. | unsecured ND message. | |||
Thanks to the authorization certificate it is provisioned with, a | When a message including a PS option is received by a SPND node, any | |||
proxy ND is authorized to issue ND signaling on behalf of nodes on | CGA or RSA options also included in the message are removed and the | |||
the subnet. Thus, a compromised proxy is able, like a compromised | remaining message further processed. Altough properly formed proxied | |||
router, to siphon off traffic from the host, or mount a man-in-the- | messages MUST NOT include at the same time PS and CGA/RSA options, | |||
middle attack. However, when two on-link hosts communicate using | discarding them if they appear does not affect to the security. If | |||
their respective link-local addresses, the threats involved with a | the PS option is validated, then the information included in the | |||
compromised router and a compromised proxy ND differs because the | message has been validly generated by a proxy, and should be honored | |||
router is not able to siphon off traffic exchanged between the hosts | (remember that anti-replay protection is provided by means of nonce | |||
or mount a man-in-the-middle attack, while the proxy ND can, even if | and timestamp options). If the PS option is not validated, then it | |||
the hosts use SEND. | is treated as an unsecured message. In any case, there is no gain | |||
for an attacker from appending false or old CGA/RSA information to a | ||||
message secured by a Secure ND Proxy. | ||||
The messages for which a Secure ND Proxy performs its function, and | A compromised Secure ND Proxy provisioned with an authorization | |||
certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is | ||||
able, like a compromised router to siphon off traffic from the host, | ||||
or mount a man-in-the-middle attack, for hosts communicating to off- | ||||
link hosts. A compromised Secure ND Proxy provisioned with an | ||||
authorization certificate with a KeyPurposeId value of id-kp- | ||||
sendProxiedOwner can siphon off traffic or mount a man-in-the-middle | ||||
attack for communication between on-link hosts, even if the hosts use | ||||
SEND. Note that different application scenarios may require one type | ||||
of authorization, the other, or both. To minimize security risks, | ||||
authorization capabilities SHOULD NOT exceed the ones strictly | ||||
required by the application scenario to be deployed. | ||||
The messages for which a Secure ND Proxy performs its function and | ||||
the link for which this function is performed MUST be configured | 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 PS option must or must not be | Section 7 discusses the security considerations resulting from the | |||
included, depending on the proxied nodes being SEND or non-SEND may | decision of appending or omitting the PS option depending on the | |||
result in security considerations which are discussed in Section 7. | SEND-awareness of the proxied nodes. | |||
Attacks to the timestamp of the secured ND message can be performed | Protection against replay attacks from unsolicited messages such as | |||
as described in section 7.3 of [I-D.ietf-csi-sndp-prob]. | NA, RA, and Redirects is provided by means of the Timestamp option. | |||
When Secure ND Proxy is used, each proxy and the host for which a | ||||
proxy acts on behalf are considered to be different peers in terms of | ||||
Timestamp verification. Since the information provided by the host | ||||
and a proxy maybe different, including different link-layer | ||||
addresses, a replay attack could affect the operation of a third | ||||
node: replaying messages issued by a host that is no longer in the | ||||
link can prevent the use of a proxy, and replaying messages of a | ||||
proxy when the host is back in the link can prevent communication | ||||
with the host. This kind of attacks can be performed until the | ||||
timestamp of the peer (either the host or a proxy) is no longer valid | ||||
for the receiver. The window of vulnerability is in general larger | ||||
for the first message received from a new peer than for subsequent | ||||
messages received from the same peer (see [RFC3971]). A more | ||||
detailed analysis of the possible attacks related with the Timestamp | ||||
option is described in section 7.3 of [I-D.ietf-csi-sndp-prob]. | ||||
9. IANA Considerations | 9. IANA Considerations | |||
IANA is requested to allocate: | IANA is requested to allocate: | |||
A new IPv6 Neighbor Discovery Option type for the PS option, as | A new IPv6 Neighbor Discovery Option type for the PS option, as | |||
TBA. The value need to be allocated from the namespace specified | TBA. The value need to be allocated from the namespace specified | |||
in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS | in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS | |||
located at http://www.iana.org/assignments/icmpv6-parameters. | located at 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. 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 and Marcelo Bagnulo. | Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey | |||
Melnikov and Sandra Murphy. | ||||
The work of Alberto Garcia-Martinez was supported in part by T2C2 | ||||
project (TIN2008-06739-C04-01, granted by the Spanish Science and | ||||
Innovation Ministry). | ||||
11. References | 11. References | |||
11.1. Normative References | 11.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-03 (work in progress), | draft-ietf-csi-send-cert-07 (work in progress), | |||
March 2010. | 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 | [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. 80 change blocks. | ||||
248 lines changed or deleted | 363 lines changed or added | |||
This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |