| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 8, 2008.
Secure Neighbor Discovery (SEND) specifies a method for securing 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.
1.
Requirements notation
2.
Introduction
3.
Terminology
4.
Application Scenarios
4.1.
Scenario 1: RFC 4389 Neighbor Discovery Proxy
4.2.
Scenario 2: Mobile IPv6
4.3.
Scenario 3: Proxy Mobile IPv6
5.
Secure Proxy ND Overview
6.
Secure Proxy ND Specification
6.1.
Proxy Signature Option
6.2.
Modified SEND processing rules
6.2.1.
Processing rules for senders
6.2.2.
Processing rules for receivers
7.
Backward Compatibility with legacy SEND nodes
8.
Security Considerations
9.
IANA Considerations
10.
Normative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
Secure Neighbor Discovery [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) specifies a method for
securing neighbor discovery signaling [RFC4861] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) 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.
From this point on we refer to such extension as "Secure Proxy ND Support for
SEND".
| TOC |
- Secure Proxy ND
A node authorized to either modify or generate a SEND message without knowing the private key related to the source address of the ICMPv6 ND message.- Proxied IPv6 address
An IPv6 address that doesn't belong to the Secure Proxy ND and for which the Secure Proxy ND is advertising.
| TOC |
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.
| TOC |
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 |
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.
| TOC |
The Mobile IPv6 protocol [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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 (Proxy ND role of the Home agent in MIPv6).
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 |
| TOC |
MN new MAG LMA
| | |
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 |
Sharing the same link-local address on different MAGs would require all MAGs of a PMIPv6 domain to construct the CGA and the RSA Signature option with the same public-private key pair, which is not acceptable from a security point of view.
Using different public-private key pairs on different MAGs would mean different MAGs use different CGAs as link-local address. Thus the serving MAG's link-local address changes after each handoff of the MN which is contradiction with the way MAG link-local address assignment occurs in a PMIPv6 domain.
| TOC |
The original SEND specification [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) has implicitly
assumed that the owner of the address was the one who was advertising the
prefix. This assumption does not allow proxying of a CGA based address as the
receiver requires the advertiser to generate a valid CGA and RSA Signature
option, which in turns requires possession of the public-private key pair that
was used to generate the CGA.
This specification explicitly separates the roles of ownership and advertiser
by extending the SEND protocol as follows:
The Secure Proxy ND becomes part of the trusted infrastructure just like a SEND
router. The Secure Proxy ND is granted a certificate that specifies the range
of addresses for which it is allowed to perform proxying of SEND messages.
Hosts can use the same process to discover the certification path between a
proxy and one of the host's trust anchors as the one defined for routers in
Section 6 of SEND specification (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971].
The proposed approach resolves the incompatibilities between the current SEND
specification and the application scenarios described in Section 4 (Application Scenarios). Since SEND messages containing a Proxy
Signature option 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.
| TOC |
A Secure ND Proxy performs all the operation described in the SEND
specification [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) with the addition of new processing
rules to ensure that the receiving node can differentiate between an authorized
proxy generating or forwarding a SEND message for a proxied address, and a
malicious node doing the same.
This is accomplished by signing the message with the public key of the
authorized Secure Proxy ND. The signature of the neighbor discovery proxy is
included in a new option called Proxy Signature option (PSO.) The signature is
performed over all the NDP options present in the message and the PSO is
appended as the last option in the message.
| TOC |
The Proxy Signature option allows public key-based signatures to be
attached to NDP messages. The format of the PSO is described in the following diagram:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 4: PSO layout |
- Type
TBA- Length
The length of the option (including the Type, Length, Reserved, Key Hash, Digital Signature, and Padding fields) in units of 8 octets.- Reserved
A 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.- Key Hash
A 128-bit field containing the most significant (leftmost) 128 bits of a SHA-1 [SHA1] (National Institute of Standards and Technology, “Secure Hash Standard,” April 1995.) hash of the public key used for constructing the signature. Its purpose is to associate the signature to a particular key known by the receiver. Such a key MUST be the same one within the Secure Proxy ND's certificate.- Digital Signature
A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets:The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash, as defined in [RSA] (RSA Laboratories, “RSA Encryption Standard, Version 2.1,” November 2002.).
- The 128-bit CGA Message Type tag [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) value for Secure Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag value has been generated randomly by the editor of this specification.)
- The 128-bit Source Address field from the IP header.
- The 128-bit Destination Address field from the IP header.
- The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header.
- The NDP message header, starting from the octet after the ICMP Checksum field and continuing up to but not including NDP options.
- All NDP options preceding the Proxy Signature option.
This field starts after the Key Hash field. The length of the Digital Signature field is determined by the length of the RSA Signature option minus the length of the other fields (including the variable length Pad field.)- Padding
This variable-length field contains padding, as many bytes long as remain after the end of the signature.
| TOC |
The modifications described in the following section applies when a SEND
message contains the Proxy Signature option (PSO), i.e. the message was sent by
a Secure Proxy ND.
This specification modifies the sender and receiver processing rules for the
following options defined in the SEND specification (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971]: CGA option, RSA option.
| TOC |
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 RSA Signature
options.
A Secure Proxy ND sending a SEND message with the PSO Signature option MUST
construct the message as follows:
- A.
- If the Secure Proxy ND is locally generating the SEND message for a proxied address, the message is constructed as described in Neighbor Discovery for IP version 6 specification [RFC4861] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.).
- B.
- If the Secure Proxy ND is forwarding a SEND message, first the authenticity of the intercepted message is verified as specified in SEND specification [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) Section 5. If the SEND message is valid, any CGA or RSA option MUST be removed from the message. The intercepted message is finally modified as described in Section 4 of the ND Proxy specification [RFC4389] (Thaler, D., Talwar, M., and C. Patel, “Neighbor Discovery Proxies (ND Proxy),” April 2006.).
| TOC |
Any SEND message without a Proxy Signature option MUST be treated as
specified in the SEND specification (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971].
A SEND message including a Proxy Signature option MUST be processed as specified below:
Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured ND messages.
| TOC |
The PSO added by a Secure Proxy ND will be ignored by nodes implementing the original SEND specification and hence will not cause any interoperability problems. Since the Secure Proxy ND also removes the original RSA option, these messages will be treated as "unsecured" message as described in Section 8 "Transitions Issues" of the SEND specification (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971]. Thus, this specification does not introduce any new transition issue compared to the original SEND specification.
| TOC |
The mechanism described in this document introduce a new Proxy Signature Option (PSO) allowing a Secure Proxy ND to generate or modify a SEND message for a proxied address. A node will only accept such a message if it includes a valid PSO generated by an authorized Secure Proxy ND.
If, on the other hand, a message does not include a PSO, then the Secure Proxy ND support doens't introduce any further security issues since this specification does not modify the SEND processing rules if an ICMPv6 ND message does not contain a PSO. Thus, the same security considerations than that of SEND applies (cf. Section 9 of the SEND specification (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971].)
| TOC |
IANA is requested to allocate:
A new IPv6 Neighbor Discovery Option types for the PSO, as TBA. The value need to be allocated from the namespace specified in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at http://www.iana.org/assignments/icmpv6-parameters.
A new 128-bit value under the CGA Message Type [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.
| TOC |
| [I-D.ietf-netlmm-proxymip6] | Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008 (TXT). |
| [I-D.krishnan-cgaext-send-cert-eku] | Krishnan, S., Kukec, A., and K. Ahmed, “Certificate profile and certificate management for SEND,” draft-krishnan-cgaext-send-cert-eku-03 (work in progress), March 2009 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3775] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
| [RFC3971] | Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” RFC 3971, March 2005 (TXT). |
| [RFC3972] | Aura, T., “Cryptographically Generated Addresses (CGA),” RFC 3972, March 2005 (TXT). |
| [RFC4389] | Thaler, D., Talwar, M., and C. Patel, “Neighbor Discovery Proxies (ND Proxy),” RFC 4389, April 2006 (TXT). |
| [RFC4861] | Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” RFC 4861, September 2007 (TXT). |
| [RSA] | RSA Laboratories, “RSA Encryption Standard, Version 2.1,” PKCS 1 , November 2002. |
| [SHA1] | National Institute of Standards and Technology, “Secure Hash Standard,” FIPS PUB 180-1 , April 1995. |
| TOC |
| Suresh Krishnan | |
| Ericsson | |
| 8400 Decarie Blvd. | |
| Town of Mount Royal, QC | |
| Canada | |
| Phone: | +1 514 345 7900 x42871 |
| Email: | suresh.krishnan@ericsson.com |
| Julien Laganier | |
| DoCoMo Communications Laboratories Europe GmbH | |
| Landsberger Strasse 312 | |
| Munich D-80687 | |
| Germany | |
| Phone: | +49 89 56824 231 |
| Email: | julien.ietf@laposte.net |
| URI: | http://www.docomolab-euro.com/ |
| Marco Bonola | |
| Rome Tor Vergata University | |
| Via del Politecnico, 1 | |
| Rome I-00133 | |
| Italy | |
| Phone: | |
| Email: | marco.bonola@gmail.com |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.