draft-ietf-csi-proxy-send-01.txt   draft-ietf-csi-proxy-send-02.txt 
Network Working Group S. Krishnan CGA & SEND maintenance Working S. Krishnan
Internet-Draft Ericsson Group Ericsson
Intended status: Standards Track J. Laganier Internet-Draft J. Laganier
Expires: January 14, 2010 DoCoMo Euro-Labs Intended status: Standards Track QUALCOMM Inc.
M. Bonola Expires: September 4, 2010 M. Bonola
Rome Tor Vergata University Rome Tor Vergata University
July 13, 2009 A. Garcia-Martinez
UC3M
March 3, 2010
Secure Proxy ND Support for SEND Secure Proxy ND Support for SEND
draft-ietf-csi-proxy-send-01 draft-ietf-csi-proxy-send-02
Abstract
Secure Neighbor Discovery (SEND) specifies a method for securing
Neighbor Discovery (ND) signaling against specific threats. As
defined today, SEND assumes that the node sending a ND message is the
owner of the address from which the message is send, so that it is in
possession of the private key used to generate the digital signature
on the message. This means that the Proxy ND signaling performed by
nodes that do not possess knowledge of the address owner's private
key cannot be secured using SEND. This document extends the current
SEND specification in order to support 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. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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.
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."
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 January 14, 2010. This Internet-Draft will expire on September 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Secure Neighbor Discovery (SEND) specifies a method for securing described in the BSD License.
Neighbor Discovery (ND) signaling against specific threats. As
specified today, SEND assumes that the node advertising an address is
the owner of the address and is in possession of the private key used
to generate the digital signature on the message. This means that
the Proxy ND signaling initiated by nodes that do not possess
knowledge of the address owner's private key cannot be secured using
SEND. This document extends the current SEND specification with
support for Proxy ND, the Secure Proxy ND Support for SEND.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 7 4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6
4.1. Scenario 1: RFC 4389 Neighbor Discovery Proxy . . . . . . 7 5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8
4.2. Scenario 2: Mobile IPv6 . . . . . . . . . . . . . . . . . 8 5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8
4.3. Scenario 3: Proxy Mobile IPv6 . . . . . . . . . . . . . . 10 5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10
5. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 12 5.2.1. Processing rules for senders . . . . . . . . . . . . . 10
6. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 14 5.2.2. Processing rules for receivers . . . . . . . . . . . . 11
6.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 14 5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 12
6.2. Modified SEND processing rules . . . . . . . . . . . . . . 16 6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Processing rules for senders . . . . . . . . . . . . . 16 6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 13
6.2.2. Processing rules for receivers . . . . . . . . . . . . 17 6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 15
7. Backward Compatibility with legacy SEND nodes . . . . . . . . 18 6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Backward Compatibility with RFC3971 nodes and non-SEND
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Normative References . . . . . . . . . . . . . . . . . . . . . 21 7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 [RFC3971] specifies a method for securing Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for
neighbor discovery signaling [RFC4861] against specific threats. As securing Neighbor Discovery (ND) signaling [RFC4861] against specific
specified today, SEND assumes that the node advertising an address is threats. As defined today, SEND assumes that the node sending a ND
the owner of the address and is in possession of the private key used message is the owner of the address from which the message is sent,
to generate the digital signature on the message. This means that so that it is in possession of the private key used to generate the
the Proxy ND signaling initiated by nodes that do not possess digital signature on the message. This means that the Proxy ND
knowledge of the address owner's private key cannot be secured using signaling performed by nodes that do not possess knowledge of the
SEND. address owner's private 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 Proxy ND Secure Proxy ND
A node authorized to either modify or generate a SEND message A node authorized to either modify or generate a SEND message
without knowing the private key related to the source address of without knowing the private key related to the source address of
the ICMPv6 ND message. the ICMPv6 ND message.
Proxied IPv6 address Proxied IPv6 address
An IPv6 address that doesn't belong to the Secure Proxy ND and for An IPv6 address that does not belong to the Secure Proxy ND and
which the Secure Proxy ND is advertising. for which the Secure Proxy ND is performing advertisements.
4. Application Scenarios
In this section we provide three different application scenarios for
which the ICMPv6 Neighbor Discovery signaling cannot be secured by
using the current SEND specification.
Either of the entities described in the following three scenarios,
(i.e.: ND Proxy, MIPv6 Home Agent, PMIPv6 Mobile Access Gateway) can
be consider as a Secure Proxy ND.
4.1. Scenario 1: RFC 4389 Neighbor Discovery Proxy
Link 1 Link 2
Host A ND Proxy (P) Host B
| | |
| SRC = A | |
| DST = solicited_node(B) | |
| ICMPv6 NS | |
| TARGET = B | |
| SLLAO = B_LL | |
|------------------------->| |
| | SRC = A |
| | DST = solicited_node(B) |
| | ICMPv6 NS |
| | TARGET = B |
| | SLLAO = P_LL |
| |------------------------->|
| | |
| | SRC = B |
| | DST = A |
| | ICMPv6 NA |
| | TARGET = B |
| | TLLAO = B_LL |
| |<-------------------------|
| SRC = B | |
| DST = A | |
| ICMPv6 NA | |
| TARGET = B | |
| TLLAO = B_LL | |
|<-------------------------| |
| | |
Figure 1: Proxy ND operations
The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
method by which multiple link layer segments are bridged into a
single segment and specifies the IP-layer support that enables
bridging under these circumstances.
A ND Proxy shall parse any IPv6 packet it receives on a proxy
interface to check whether it contains one of the following ICMPv6
messages: Neighbor Solicitation (NS), Neighbor Advertisement (NA),
Router Advertisement, or Redirect. Since each of these messages
contains a link-layer address which might not be valid on another
segment, the ND Proxy proxies these packets as follows, and as
illustrated in Figure 1:
1. The source link layer address will be the address of the outgoing
interface.
2. The destination link layer address will be the address in the
neighbor entry corresponding to the destination IPv6 address.
3. A link layer address within the payload (that is, in a Source
Local Link Address option - SLLAO, or a Target Local Link Address
option - TLLAO) is substituted with the link-layer address of the
outgoing interface.
Moreover, when any other IPv6 unicast packet is received on a proxy
interface, if it is not locally destined then it is forwarded
unchanged (other than using a new link-layer header) to the proxy
interface for which the next hop address appears in the neighbor
cache. If no neighbor cache entry is present, the ND proxy should
queue the packet and initiate a Neighbor Discovery signalling as if
the ICMPv6 NS message were locally generated.
A ND proxy cannot protect proxied ND messages since protection of an
ND message as per the current SEND specification requires knowledge
of the private key of each node for which it is generating or
forwarding a ND message on the bridged link layer segments.
4.2. Scenario 2: Mobile IPv6
The Mobile IPv6 protocol [RFC3775] allows a mobile node (MN) to move
from one link to another while maintaining reachability at a stable
address, the so-called MN's home address (HoA.) When a mobile node
attaches to a foreign network, all the packets sent to the MN's HoA
and forwarded on the home link by a correspondent node (CN) or a
router are intercepted by the home agent (HA) on that home link,
encapsulated and tunneled to the mobile node's registered care-of
address (CoA.)
The HA intercepts these packets by being a Neighbor Discovery proxy
for this MN. When a Neighbor Solicitation (NS) is intercepted on the
home link, the home agent checks if the Target address within the NS
matches with any of the MN's Home Address in the Binding Cache and if
so, it replies with a Neighbor Advertisement (NA) containing its own
link layer address (HA_LL) as the Target Link Layer Address Option
(TLLAO), as illustrated in Figure 2.
Node (N) Home Agent (HA) Mobile Node (MN)
on Home Link on Home Link on Foreign Link
| | |
| SRC = N | |
| DST = solicited_node(MN) | |
| ICMPv6 NS | |
| TARGET = MN | |
| SLLAO = N_LL | |
|------------------------->| |
| | |
| SRC = MN | |
| DST = N | |
| ICMPv6 NA | |
| TARGET = MN | |
| TLLAO = HA_LL | |
|<-------------------------| |
| | |
| traffic | |
| dest= MN HoA | |
|------------------------->| |
| | |
| | tunnelled traffic |
| | dest= MN CoA |
| |------------------------->|
| | |
Figure 2: Proxy ND role of the Home agent in MIPv6
It is not possible to apply the current SEND specification to protect Non-SEND node
the NA message issued by the HA. To generate an ICMPv6 NA with a
valid CGA option and the corresponding RSA Signature option, the HA
needs knowledge of the private key related to the MN's
Cryptographically Generated Address (CGA.) Any ICMPv6 NA without a
valid CGA and RSA signature option is to be treated as insecure by a
SEND receiver.
4.3. Scenario 3: Proxy Mobile IPv6 An IPv6 node that does not implement the SEND [RFC3971]
specification but uses only the ND protocol defined in [RFC4861]
and [RFC4862], without security.
MN new MAG LMA RFC3971 node
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| | |
|--- ICMPv6 RS ------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
|<------ ICMPv6 RA ----| |
| | |
| | |
| | |
Figure 3: Mobile node's handover in PMIPv6 An IPv6 node that does not implement the specification defined in
this document for Secure Proxy ND support, but uses only the SEND
specification as defined in [RFC3971].
Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based SPND node
mobility management protocol that provides an IP mobility management
support for MNs without requiring MNs being involved in the mobility
related signaling. The IP mobility management is totally hidden to
the MN in a Proxy Mobile IPv6 domain and is performed by two
functional entities: the Local Mobility Anchor (LMA) and the Mobile
Access Gateway (MAG.)
When the MN connects to a new access link it will send a multicast An IPv6 node that implements the specification defined in this
ICMPv6 Router Solicitation (RS.) The MAG on the new access link, document for Secure Proxy ND support.
upon detecting the MN's attachment, will signal the LMA for updating
the binding state of the MN (Proxy Binding Update - PBU) and once the
signaling is complete (Proxy Binding Ack - PBA - received), it will
reply to the MN with a ICMPv6 Router Advertisement (RA) containing
its home network prefix(es) that were assigned to that mobility
session, making the MN believe it is still on the same link and not
triggering the IPv6 address reconfiguration (figure Figure 3.)
To avoid potential link-local address collisions between the MAG and
the MN after a handoff to a new link, the Proxy Mobile IPv6
specification requires the MAG's link-local address configured on the
link to which the MN is attached to be generated once by the LMA when
the MN first attach to a PMIPv6 domain, and to be provided to the new
MN's serving MAG after each handoff. Thus, from the MN's point of
view, the MAG's link-local address remains constant for the duration
of that MN's session.
The approach described above and the current SEND specification are 4. Secure Proxy ND Overview
incompatible since:
Sharing the same link-local address on different MAGs would The original SEND specification [RFC3971] has implicitly assumed that
require all MAGs of a PMIPv6 domain to construct the CGA and the only the node sending a ND message is the owner of the address from
RSA Signature option with the same public-private key pair, which which the message is sent. This assumption does not allow proxying
is not acceptable from a security point of view. of ND messages since the advertiser is required to generate a valid
RSA Signature option, which in turns requires possession of the
public-private key pair that was used to generate a CGA, or that was
associated to a router certificate.
Using different public-private key pairs on different MAGs would To be able to separate the roles of ownership and advertiser the
mean different MAGs use different CGAs as link-local address. following extensions to the SEND protocol are defined:
Thus the serving MAG's link-local address changes after each
handoff of the MN which is contradiction with the way MAG link-
local address assignment occurs in a PMIPv6 domain.
5. Secure Proxy ND Overview o A Secure Proxy ND certificate, which is a certificate authorizing
an entity to act as an ND proxy. It is a X509v3 certificate in
which the purpose for which the certificate is issued has been
specified explicitly as described in a companion document
[I-D.ietf-csi-send-cert]. Briefly, a KeyPurposeID value is
defined for authorizing proxies. The inclusion of the proxy
authorization value allows the certificate owner to perform
proxying of SEND messages for a range of addresses indicated in
the same certificate. This certificate can be exchanged as a
result of the Authorization Delegation Discovery process defined
in [RFC3971].
The original SEND specification [RFC3971] has implicitly assumed that o A new Neighbor Discovery option called Proxy Signature option
the owner of the address was the one who was advertising the prefix. (PSO). This option contains the hash value of the public key of
This assumption does not allow proxying of a CGA based address as the the proxy, and the digital signature of the SEND message computed
receiver requires the advertiser to generate a valid CGA and RSA with the private key of the proxy. The hash of the public key of
Signature option, which in turns requires possession of the public- the proxy is computed over the public key contained in the Secure
private key pair that was used to generate the CGA. Proxy ND's certificate. When a ND message contains a PSO, it MUST
NOT contain CGA and RSA Signature options. This option can be
appended to any ND message: NA, NS, RS, RA and Redirect.
This specification explicitly separates the roles of ownership and o A modification of the SEND processing rules for all ND messages:
advertiser by extending the SEND protocol as follows: NA, NS, RS, RA, and Redirect. When any of these messages is
received with a valid Proxy Signature option, it is considered as
secure.
o A certificate authorizing an entity to act as an ND proxy is These extensions are applied in the following way:
introduced. This is achieved via specifying explicitly in the
X509v3 certificate the purpose for which the certificate is
issued, as described in a companion document
[I-D.krishnan-cgaext-send-cert-eku]. Briefly, two KeyPurposeID
values are defined: one for authorizing routers, and one for
authorizing proxies. The inclusion of the proxy authorization
value allows the certificate owner to perform proxying of SEND
messages for a set of prefixes indicated in the same certificate.
o A new option called Proxy Signature option (PSO) is defined. This o A Secure Proxy ND which proxies ND messages on behalf of a node
option contains the key hash value of the Secure Proxy ND's public can use the PSO option to protect the proxied messages. This
key and the digital signature computed over the SEND message. The Secure Proxy ND becomes part of the trusted infrastructure just
key has value is computed over the public key within the Secure like a SEND router.
Proxy ND's certificate.
o The SEND processing rules are modified for all Neighbor Discovery o In order to allow nodes to successfully validate secured proxied
messages: NA, NS, RS, RA, and Redirect. When any of these messages, the nodes must know the Secure Proxy ND certificate (in
messages is received with a valid Proxy Signature option, it is the format described in [I-D.ietf-csi-send-cert]) and must apply
considered as secure even if it doesn't contain a CGA option. the modified processing rules specified in this document. We call
this nodes 'SPND nodes'. Note that the rules for generating ND
messages in SPND nodes do not change, so these nodes behave as
defined in [RFC3971] for sending ND messages.
The Secure Proxy ND becomes part of the trusted infrastructure just o To allow SPND nodes to know the certificate path required to
like a SEND router. The Secure Proxy ND is granted a certificate validate the public key of the proxy, devices responding to CPS
that specifies the range of addresses for which it is allowed to (Certification Path Solicitation) messages with CPA (Certification
perform proxying of SEND messages. Hosts can use the same process to Path Advertisements) as defined in Section 6 of SEND specification
discover the certification path between a proxy and one of the host's [RFC3971] must handle the certificate format specified in
trust anchors as the one defined for routers in Section 6 of SEND [I-D.ietf-csi-send-cert], and must be configured with the
specification [RFC3971]. 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 4. Since SEND messages containing a Proxy Signature option Section 6.
are not required to carry a CGA option, the IPv6 source address is no
longer cryptographically bound to the signature, and the sender of a
Neighbor Discovery message is not required to be the owner of the
claimed address. Thus, the Secure Proxy ND is able to either forward
and generate SEND messages for a proxied address within the set of
prefixes for which it is authorized.
6. Secure Proxy ND Specification 5. Secure Proxy ND Specification
A Secure ND Proxy performs all the operation described in the SEND A Secure Proxy ND performs all the operation 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 neighbor the authorized Secure Proxy ND. The signature of the ND Proxy is
discovery proxy is included in a new option called Proxy Signature included in a new option called Proxy Signature option (PSO). The
option (PSO.) The signature is performed over all the NDP options signature is performed over all the NDP options present in the
present in the message and the PSO is appended as the last option in message and the PSO is appended as the last option in the message.
the message.
6.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 PSO is described in the attached to NDP messages. The format of the PSO is described in the
following diagram: following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key Hash | | Key Hash |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Digital Signature . . Digital Signature .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PSO layout Figure 1: PSO layout
Type Type
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 16-bit field reserved for future use. The value MUST be A 11-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 Secure Proxy ND's certificate. MUST be the same one within the corresponding Secure Proxy ND's
certificate.
Digital Signature Digital Signature
A variable-length field containing a PKCS#1 v1.5 signature, A variable-length field containing a PKCS#1 v1.5 signature,
constructed by using the sender's private key over the following constructed by using the sender's private key over the following
sequence of octets: sequence of octets:
1. The 128-bit CGA Message Type tag [RFC3972] value for Secure 1. The 128-bit CGA Message Type tag [RFC3972] value for Secure
Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag
value has been generated randomly by the editor of this value has been generated randomly by the editor of this
specification.) specification).
2. The 128-bit Source Address field from the IP header. 2. The 128-bit Source Address field from the IP header.
3. The 128-bit Destination Address field from the IP header. 3. The 128-bit Destination Address field from the IP header.
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from
the ICMP header. the ICMP header.
5. The NDP message header, starting from the octet after the ICMP 5. The NDP message header, starting from the octet after the ICMP
Checksum field and continuing up to but not including NDP Checksum field and continuing up to but not including NDP
options. options.
6. All NDP options preceding the Proxy Signature option. 6. All NDP options preceding the Proxy Signature option.
The signature value is computed with the RSASSA-PKCS1-v1_5 The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash, as defined in [RSA]. algorithm and SHA-1 hash, as defined in [RSA].
This field starts after the Key Hash field. The length of the This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the RSA Digital Signature field is determined by the ASN.1 BER coding of
Signature option minus the length of the other fields (including the PKCS#1 v1.5 signature.
the variable length Pad field.)
Padding Padding
This variable-length field contains padding, as many bytes long as This variable-length field contains padding. The length of the
remain after the end of the signature. padding field is determined by the length of the Proxy Signature
Option minus the length of the other fields.
6.2. Modified SEND processing rules 5.2. Modified SEND processing rules
The modifications described in the following section applies when a The modifications described in the following section applies when a
SEND message contains the Proxy Signature option (PSO), i.e. the SEND message contains the Proxy Signature option (PSO), i.e. the
message was sent by a Secure Proxy ND. message was sent by a Secure Proxy ND.
This specification modifies the sender and receiver processing rules This specification modifies the sender and receiver processing rules
for the following options defined in the SEND specification for the CGA and RSA options defined in the SEND specification
[RFC3971]: CGA option, RSA option. [RFC3971].
6.2.1. Processing rules for senders 5.2.1. Processing rules for senders
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 follow: 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 is 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 is verified as
specified in SEND specification [RFC3971] Section 5. If the specified in SEND specification [RFC3971], Section 5. If the
SEND message is valid, any CGA or RSA option MUST be removed SEND message is valid, any CGA or RSA option MUST be removed
from the message. The intercepted message is finally 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].
2. The Proxy Signature option is added as the last option in the C. If the Secure Proxy ND is forwarding a SEND message already
containing a PSO, first the authenticity of the intercepted
message is verified as specified in Section 6.2.2 of this
draft. If the SEND message is valid, the original PSO MUST
be removed from the message. The intercepted message is
finally modified as described in Section 4 of the ND Proxy
specification[RFC4389].
2. Timestamp and Nonce options are included according to the rules
specified in SEND [RFC3971]. The value in the Timestamp option
MUST be generated by the Proxy. If the proxy is forwarding a
message, the Nonce value in the proxied message MUST be the same
as in the forwarded message.
3. The Proxy Signature option is added as the last option in the
message. message.
3. The data is signed as explained in Section 6.1. 4. The data is signed as explained in Section 5.1.
6.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 PSO. The options are options that might come after the first PSO. The options are
ignored for both signature verification and NDP processing 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 [RFC3971] Section 6.3) between
the receiver's trust anchor and the sender's public key MUST be the receiver's trust anchor and the sender's public key MUST be
known. The Secure Proxy ND's X509v3 certificate MUST contain a known. The Secure Proxy ND's X509v3 certificate MUST contain a
extended key usage extension including the KeyPurposeId value for extended key usage extension including the KeyPurposeId value for
the proxy authorization. the proxy authorization.
3. The Digital Signature field MUST have correct encoding and MUST 3. The Digital Signature field MUST have correct encoding.
NOT exceed the length of the Proxy Signature option minus the
Padding.
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 6.1. has been calculated as specified in Section 5.1.
5. Timestamp and Nonce options MUST be processed as specified in
[RFC3971] Section 5.3.4, except for replacing 'RSA Signature
option' by 'PSO option'.
6. Messages with the Override bit [RFC4861] set should override an
existing cache entry regardless if it was created as a result of
a RSA Signature option or a PSO option validation. When it is
not set the advertisement will not update a cached link-layer
address created securily by means of RSA 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.
7. Backward Compatibility with legacy SEND nodes 5.3. Proxying Link-Local Addresses
The PSO added by a Secure Proxy ND will be ignored by nodes Secure Neighbor Discovery [RFC3971] relies on certificates to prove
implementing the original SEND specification and hence will not cause that routers are authorized to announce a certain prefix. However,
any interoperability problems. Since the Secure Proxy ND also Neighbor Discovery [RFC4861] states that router does not announce the
removes the original RSA option, these messages will be treated as Link-Local prefix (fe80::/64). Hence, it is not required for a SEND
"unsecured" message as described in Section 8 "Transitions Issues" of certificate to hold a X.509 IP address extensions that authorizes the
the SEND specification [RFC3971]. Thus, this specification does not fe80::/64 prefix. Some scenarios ([RFC4389], [RFC5213]) impose that
introduce any new transition issue compared to the original SEND the Secure ND proxy provides proxying function for the Link-Local
specification. address of a node. When Secure ND proxy functionality on a Link-
Local address is required, either a list of link-local addresses, or
the fe80::/64 prefix MUST be explicitly authorized to be proxied in
the corresponding certificate.
6. Application Scenarios
In this section we describe three different application scenarios for
which Secure Proxy ND Support for SEND can be applied. Note that the
particular way in which Secure Proxy ND support is applied (which ND
messages are proxied, in which directions, how the interaction with
non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on
the particular scenario considered. In the first two scenarios
presented below, ND messages are synthesized on behalf of off-link
nodes. In the third one, ND messages are generated in reaction to ND
messages being received by other interfaces of the proxied node.
6.1. Scenario 1: Mobile IPv6
The description of the problems for deploying SEND in this scenario
can be found in [I-D.ietf-csi-sndp-prob].
The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN)
to move from one link to another while maintaining reachability at a
stable address, the so-called MN's Home Address (HoA). When a MN
attaches to a foreign network, all the packets sent to the MN's HoA
by a Correspondent Node (CN) on the home link, or a router, are
intercepted by the Home Agent (HA) on that home link, encapsulated
and tunneled to the MN's registered Care-of Address (CoA).
The HA intercepts these packets acting as a ND proxy for this MN.
Lets assume that the nodes in the home link use SEND. When a secured
NS is intercepted on the home link, the HA checks the validity of the
received message according to the rules stated in [RFC3971]. If the
message is valid, it checks if the Target address within the NS
matches with any of the MN's Home Address in the Binding Cache and if
so, it replies with a Neighbor Advertisement (NA) constructed as
described in [RFC4861], so it contains its own link layer address
(HA_LL) as the Target Link Layer Address Option (TLLAO), with a PSO
option signing the message, added as the last option of the message.
Node (N) Home Agent (HA) Mobile Node (MN)
on Home Link on Home Link on Foreign Link
| | |
| SRC = N | |
| DST = solicited_node(MN) | |
| ICMPv6 NS | |
| TARGET = MN | |
| SLLAO = N_LL | |
| [CGA] | |
| RSA signature | |
|------------------------->| |
| | |
| SRC = HA | |
| DST = N | |
| ICMPv6 NA | |
| TARGET = MN | |
| TLLAO = HA_LL | |
| PSO signature | |
|<-------------------------| |
| | |
| traffic | |
| dest= MN HoA | |
|------------------------->| |
| | |
| | tunnelled traffic |
| | dest= MN CoA |
| |------------------------->|
| | |
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
link, or a router) must have a certificate of the public key of the
HA acting as a Secure Proxy ND. To do so, a certificate for the HA
could be made available through the Authorization Delegation
Discovery process [RFC3971] performed at the home link, i.e. the
devices responding to CPS messages should be configured to include in
CPA messages information about the HA certificate.
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
Proxy Mobile IPv6 [RFC5213] is a network-based mobility management
protocol that provides an IP mobility management support for MNs
without requiring MNs being involved in the mobility related
signaling. The IP mobility management is totally hidden to the MN in
a Proxy Mobile IPv6 domain and is performed by two functional
entities: the Local Mobility Anchor (LMA) and the Mobile Access
Gateway (MAG).
When the MN connects to a new access link it will send a multicast
ICMPv6 Router Solicitation (RS). The MAG on the new access link,
upon detecting the MN's attachment, will signal the LMA for updating
the binding state of the MN (Proxy Binding Update - PBU) and once the
signaling is complete (it receives a Proxy Binding Ack - PBA), it
will reply to the MN with a ICMPv6 Router Advertisement (RA)
containing the home network prefix(es) that were assigned to that
mobility session, making the MN believe it is still on the same link
and not triggering the IPv6 address reconfiguration (figure
Figure 3).
MN new MAG LMA
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| | |
| SRC = MN | |
| DST = all-routers | |
| ICMPv6 RS | |
| [CGA] | |
| RSA signature | |
|--------------------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
| SRC = MAG4MN | |
| DST = MN | |
| ICMPv6 RA | |
| SLL = MAG_LL | |
| PSO | |
|<---------------------| |
| | |
| | |
| | |
Figure 3: Mobile node's handover in PMIPv6
To avoid potential link-local address collisions between the MAG and
the MN after a handoff to a new link, the Proxy Mobile IPv6
specification requires the MAG's link-local address configured on the
link to which the MN is attached to, to be generated once by the LMA
when the MN first attach to a PMIPv6 domain, and to be provided to
the new MN's serving MAG after each handoff. Thus, from the MN's
point of view, the MAG's link-local address remains constant for the
duration of that MN's session.
Each MAG can be granted a certificate per each link-local address
expected by any MN that could attach to the link. However, the use
of Secure Proxy ND can greatly reduce the number of certificates
needed. In this case, each MAG is configured to act as a proxy by
means of a certification path from a trust anchor associated to the
PMIPv6 domain, authorizing each MAG to proxy securely ND messages.
When a secured RS message is issued by the MN, the MAG checks its
validity according to the rules stated in [RFC3971]. If the message
is valid, it replies with a RA with source address 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 address, with the PSO
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
order to obtain the certification path associated to the public key
of the PSO (or may have this certification path already available).
The MN node must be configured with a trust anchor related with the
MAG's certificate. The MAG (or other device) could be configured to
provide its certification path in a CPS message as a response to a
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
containing its own link layer address as the Target Link Layer
Address Option (TLLAO), with a PSO option signing the message, added
as the last option of the message. The same applies for Redirect
messages.
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy
The description of the problems for deploying SEND in this scenario
can be found in [I-D.ietf-csi-sndp-prob].
Link 1 Link 2
Host A ND Proxy (P) Host B
| | |
| SRC = A | |
| DST = solicited_node(B) | |
| ICMPv6 NS | |
| TARGET = B | |
| SLLAO = A_LL | |
|------------------------->| |
| | SRC = A |
| | DST = solicited_node(B) |
| | ICMPv6 NS |
| | TARGET = B |
| | SLLAO = P_LL |
| |------------------------->|
| | |
| | SRC = B |
| | DST = A |
| | ICMPv6 NA |
| | TARGET = B |
| | TLLAO = B_LL |
| |<-------------------------|
| SRC = B | |
| DST = A | |
| ICMPv6 NA | |
| TARGET = B | |
| TLLAO = P_LL | |
|<-------------------------| |
| | |
Figure 4: Proxy ND operations
The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
method by which multiple link layer segments are bridged into a
single segment and specifies the IP-layer support that enables
bridging under these circumstances.
A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy
interface to check whether it contains one of the following secured
ICMPv6 messages: NS, NA, RA, or Redirect. The Secure ND Proxy MUST
verify the authenticity of the received ND message, according to
[RFC3971]. If the SEND message is valid, then it proxied the
original message with the following changes:
1. The message is processed according to [RFC4389]. This includes
changing the source link layer address will be the address of the
outgoing interface, maintaining the destination link layer
address as the address in the neighbor entry corresponding to the
destination IPv6 address, etc. In particular any link layer
address within the payload (that is, in a Source Local Link
Address option - SLLAO, or a Target Local Link Address option -
TLLAO) is substituted with the link-layer address of the outgoing
interface.
2. Any CGA or RSA option is removed.
3. If a Nonce option existed in the original message, its value is
preserved in the proxied message. The Timestamp is generated by
the proxy.
4. The PSO option is added as the last option 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
interface, if it is not locally destined then it is forwarded
unchanged (other than using a new link-layer header) to the proxy
interface for which the next hop address appears in the neighbor
cache. If no neighbor cache entry is present, the ND proxy should
queue the packet and initiate a Neighbor Discovery signalling as if
the ICMPv6 NS message were locally generated.
In order to deploy this scenario, nodes in proxied segments MUST know
the certificate authorizing proxy operation. To do so it could be
required to configure at least one device per each proxied segment
(may be the proxy itself) to propagate the required certification
path to authorize proxy operation by means of a CPS/CPA exchange.
While more robust mechanisms could be developed for securing the
scenario described in [RFC4389], if hosts have been upgraded to apply
the rules stated in Section 5.2.2, for example, to benefit from
secure support for other scenarios, the application of this mechanism
is straighforward.
7. Backward Compatibility with RFC3971 nodes and non-SEND nodes
In this section we discuss the interaction of Secure Proxy ND nodes
and SPND nodes with RFC3971 nodes and non-SEND nodes.
7.1. Backward Compatibility with RFC3971 nodes
RFC3971 nodes, i.e. SEND nodes not compliant with the modifications
required in Section 5 cannot interpret correctly a PSO option
received in a proxied ND message. These SEND nodes silently discard
the PSO option, as specified in [RFC4861] for any unknown option. As
a result, these messages will be treated as unsecured as described in
Section 8 "Transitions Issues" of the SEND specification [RFC3971].
When RFC3971 nodes and SPND nodes exchange ND messages (without proxy
intervention), in either direction, messages are generated according
to the SEND specification [RFC3971], so these nodes interoperate
seamlessly.
In the scenarios in which the proxy translates ND messages, the
messages to translate can either be originated in a RFC3971 node or
in an SPND node, without interoperability issues.
7.2. Backward Compatibility with non-SEND nodes
Plain ND nodes receiving NDP packets silently discard PSO options, as
specified in [RFC4861] for any unknown option. Therefore, these node
interpret messages proxied by a Secure Proxy ND as any other ND
message.
When non-SEND nodes and SPND nodes exchange ND messages (without
proxy intervention), in either direction, the rules specified in
section 8 of [RFC3971] apply.
A secure Proxy ND SHOULD support the use of secured and unsecured NDP
messages at the same time, although it MAY have a configuration that
causes not to perform proxing for unsecured NDP messages. A secure
Proxy ND MAY also have a configuration option whereby it disables
secure ND proxying completely. This configuration SHOULD be switched
off by default, that is SEND is used. In the next paragraphs we
discuss the recommended behavior of the Secure Proxy ND regarding to
which protection level provide to proxied messages in a mixed
scenario involving SPND/RFC3971 nodes and non-SEND nodes. In
particular, two different situations occur depending on if the
proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes.
As a rule of thumb, the Secure Proxy ND should only generate PSO
options for nodes which have SEND capabilities (i.e. that they could
use SEND to defend their messages if being in the same link than the
proxy, either RFC3971 nodes or SPND nodes). This is relevant to
allow nodes preferring secured information over unsecured one, and
for executing the DAD procedure, as specified in [RFC3971].
Therefore, the Secure Proxy ND SHOULD generate messages containing
the PSO option for SPND and RFC3971 hosts, and SHOULD NOT generate
messages containing the PSO option for non-SEND nodes. Note that ND
advertisements in response to solicitations generated by a Secure
Proxy ND must be secured or not according to the previous
considerations (i.e. to the nature of the proxied node), and not
according to the secure or unsecure nature of the solicitation
message.
To apply this rule, we have to consider that depending on the
application scenario the proxy may translate ND messages generated by
a node or synthetise ND messages on behalf of a node.
o For ND translated messages, the rule can be easily applied: only
messages validated in the Secure Proxy ND according to the SEND
specification [RFC3971] MUST be proxied securely by the inclusion
of a PSO option. Unsecured ND messages could be proxied if
unsecured operation is enabled in the proxy, but the message
generated by the Secure Proxy ND for the received message MUST NOT
include a PSO option.
o For ND messages synthesised on behalf of remote nodes, different
considerations should be made according to the particular
application scenario.
* For MIPv6, if the MN can return to the home link, it is
required for the proxy to know if the node could use SEND to
defend its address or not. A mismatch between the proxy and
proxied node behavior regarding to SEND operation would result
in unaproppriate operation. A HA including the PSO option for
proxying a non-SEND MN would make ND messages sent by the proxy
to be more preferred than ND message of the non-SEND MN if the
MN returns to the home link (even if the proxied messages have
the Override bit set to 1). Not using the PSO option for a
RFC3971 or SPND MN would make more vulnerable the address in
the home link when the MN is away than when it is in the home
link (and would defeat the purpose of the Secure Proxy ND
mechanism). Therefore, in this case the HA must know the SEND
capabilities of the MN.
* We can state the same for the Proxy Mobile IPv6 scenario as for
the MIPv6 scenario. Note that a node moving from a link in
which PSO has been used to protect a link-layer address to a
link in which ND messages are not SEND-enabled would prevent
the node from adquiring the new information until the
corresponding cache expires. However, in this case it is
reasonable to consider that all MAGs provide the same security
for protecting ND messages, and that either all MAGs will
behave as Secure Proxy ND, or none, so configuration could be
easier.
8. Security Considerations 8. Security Considerations
The mechanism described in this document introduce 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. A node will only accept modify a SEND message for a proxied address. An SPND node will only
such a message if it includes a valid PSO generated by an authorized accept such a message if it includes a valid PSO generated by an
Secure Proxy ND. authorized Secure Proxy ND. Such a message has equivalent protection
to the threats presented in section 9 of [RFC3971] as a message
signed with a RSA Signature option.
If, on the other hand, a message does not include a PSO, then the The security of proxied ND messages not including a PSO option is the
Secure Proxy ND support doens't introduce any further security issues same of an unsecured ND message. The security of a proxied ND
since this specification does not modify the SEND processing rules if message received by a non-SEND host or RFC3971 host is the same of an
an ICMPv6 ND message does not contain a PSO. Thus, the same security unsecured ND message.
considerations than that of SEND applies (cf. Section 9 of the SEND
specification [RFC3971].) Thanks to the authorization certificate it is provisioned with, a
proxy ND is authorized to issue ND signaling on behalf of nodes on
the subnet. Thus, a compromised proxy is able, like a compromised
router, to siphon off traffic from the host, or mount a man-in-the-
middle attack. However, when two on-link hosts communicate using
their respective link-local addresses, the threats involved with a
compromised router and a compromised proxy ND differs because the
router is not able to siphon off traffic exchanged between the hosts
or mount a man-in-the-middle attack, while the proxy ND can, even if
the hosts use SEND.
The messages for which a Secure Proxy ND perform its function, and
the link for which this function is performed MUST be configured
appropriately for each proxy and scenario. This configuration is
specially relevant if Secure Proxy ND is used for translating ND
messages from one link to another.
Proper configuration of when the PSO option must or must not be
included, depending on the proxied node being SEND or non-SEND may
result in security considerations, as discussed in Section 7.
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].
9. IANA Considerations 9. IANA Considerations
IANA is requested to allocate: IANA is requested to allocate:
A new IPv6 Neighbor Discovery Option types 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. Normative References 10. References
[I-D.ietf-netlmm-proxymip6] 10.1. Normative References
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-18 (work in progress),
May 2008.
[I-D.krishnan-cgaext-send-cert-eku] [I-D.ietf-csi-send-cert]
Krishnan, S., Kukec, A., and K. Ahmed, "Certificate Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
profile and certificate management for SEND", profile and certificate management for SEND",
draft-krishnan-cgaext-send-cert-eku-03 (work in progress), draft-ietf-csi-send-cert-02 (work in progress),
March 2009. February 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.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1", [RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1",
PKCS 1 , November 2002. PKCS 1 , November 2002.
[SHA1] National Institute of Standards and Technology, "Secure [SHA1] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1 , April 1995. Hash Standard", FIPS PUB 180-1 , April 1995.
10.2. Informative References
[I-D.ietf-csi-sndp-prob]
Combes, J., Krishnan, S., and G. Daley, "Securing Neighbor
Discovery Proxy: Problem Statement",
draft-ietf-csi-sndp-prob-04 (work in progress),
January 2010.
Authors' Addresses Authors' Addresses
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Julien Laganier Julien Laganier
DoCoMo Communications Laboratories Europe GmbH QUALCOMM Incorporated
Landsberger Strasse 312 5775 Morehouse Dr
Munich D-80687 San Diego, CA 92121
Germany USA
Phone: +49 89 56824 231 Phone: +1 858 658 3538
Email: julien.ietf@laposte.net Email: julienl@qualcomm.com
URI: http://www.docomolab-euro.com/
Marco Bonola Marco Bonola
Rome Tor Vergata University Rome Tor Vergata University
Via del Politecnico, 1 Via del Politecnico, 1
Rome I-00133 Rome I-00133
Italy Italy
Phone: Phone:
Email: marco.bonola@gmail.com Email: marco.bonola@gmail.com
Alberto Garcia-Martinez
U. Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34 91 6248782
Email: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/
 End of changes. 63 change blocks. 
367 lines changed or deleted 624 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/