Network Working Group S. Krishnan
Internet-Draft Ericsson
Intended status: Standards Track November 02, 2007
Expires: May 5, 2008
Proxying Secure Neighbor Discovery Messages
draft-krishnan-cgaext-proxy-send-00
Status of this Memo
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 May 5, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Krishnan Expires May 5, 2008 [Page 1]
Internet-Draft Proxy SEND November 2007
Abstract
Neighbor discovery(ND) proxies provide a method for bridging multiple
links into a single subnet. They do this by modifying the neighbor
discovery signaling passing through them. SEND provides a way of
securing neighbor discovery signaling so that receiving nodes can
detect if the neighbor discovery packets have been tampered with.
This leads to SEND and ND proxies being unable to coexist with each
other. This document proposes a method for these to co-exist.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Changes to SEND concepts . . . . . . . . . . . . . . . . . . . 5
4. Proposed method . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Pre-requisites . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Operation of a SEND proxy . . . . . . . . . . . . . . . . 6
5. Proxy Signature Option(PSO) . . . . . . . . . . . . . . . . . 7
6. Original Link Layer Address Options . . . . . . . . . . . . . 9
7. Fallback procedure . . . . . . . . . . . . . . . . . . . . . . 10
8. Backward Compatibility with legacy SEND nodes . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Krishnan Expires May 5, 2008 [Page 2]
Internet-Draft Proxy SEND November 2007
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Krishnan Expires May 5, 2008 [Page 3]
Internet-Draft Proxy SEND November 2007
2. Introduction
Neighbor discovery proxies [RFC4389] describes a method by which
multiple link layer segments are bridged into a single segment. SEND
[RFC3971] specifies a method for securing neighbor discovery
signaling [RFC4861] 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
Neighbour Discovery signaling initiated by ND proxies cannot be
secured using SEND as they do not possess knowledge of the address
owner's private key.
Krishnan Expires May 5, 2008 [Page 4]
Internet-Draft Proxy SEND November 2007
3. Changes to SEND concepts
The original SEND specification [RFC3971] 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 that the advertiser possesses the public and
private keys related to the address. So this document recommends
that the roles of ownership and advertiser be explictly separated.
The certificates used by SEND do not specify the purpose for which
the certificate was granted. A companion document [SENDEKU]
describes the extensions required to SEND certificates in order to
explicitly specify the purpose of the certificate.
Krishnan Expires May 5, 2008 [Page 5]
Internet-Draft Proxy SEND November 2007
4. Proposed method
4.1. Pre-requisites
In the proposed method the proxy becomes part of the trusted
infrastructure just like a SEND router. The proxy is granted a
certificate that specifies the range of addresses that it is allowed
to proxy. 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 [RFC3971].
4.2. Operation of a SEND proxy
The SEND proxy performs all the operations that a standard ND proxy
defined in [RFC4389] performs. It performs a few additional steps in
order to ensure that the receiving node can differentiate between an
authorized proxy modifying a neighbor discovery message and a
malicious node doing the same. This is accomplished by signing the
modified message with the authorized proxy's key. An authorized
proxy will also include in the signed message, the original contents
of the neighbor discovery options it replaced. This can be used by
the receiving node for further verification if needed as specified in
Section 7. The signature of the neighbor discovery proxy is included
in a new option called the proxy signature option. The signature is
performed over all the NDP options present in the message including
the RSA signature option from the original message. The PSO is
appended as the last option in the message.
Krishnan Expires May 5, 2008 [Page 6]
Internet-Draft Proxy SEND November 2007
5. Proxy Signature Option(PSO)
The Proxy Signature option allows public key-based signatures to be
attached to NDP messages. The format of the Proxy Signature option
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA1
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
Krishnan Expires May 5, 2008 [Page 7]
Internet-Draft Proxy SEND November 2007
bits of a SHA-1 [14] hash of the public key used for constructing
the signature. The SHA-1 hash is taken over the presentation used
in the Public Key field of the CGA Parameters data structure
carried in the CGA option. Its purpose is to associate the
signature to a particular key known by the receiver. Such a key
can either be stored in the certificate cache of the receiver or
be received in the CGA option in the same message.
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:
1. The 128-bit CGA Message Type tag [11] value for SEND, 0x086F
CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
generated randomly by the editor of this specification.).
2. The 128-bit Source 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 the
ICMP header.
5. The NDP message header, starting from the octet after the ICMP
Checksum field and continuing up to but not including NDP
options.
6. All NDP options preceding the Proxy Signature option.
The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash, as defined in [13].
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.
Figure 1: PSO layout
Krishnan Expires May 5, 2008 [Page 8]
Internet-Draft Proxy SEND November 2007
6. Original Link Layer Address Options
These options contain the contents of the TLLAO and/or SLLAO options
in the original unmodified packet before the proxy modified the
packet to replace them with its own addresses.
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 | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type
TBA2 for Source Link-layer Address
TBA3 for Target Link-layer Address
Length The length of the option (including the type and
length fields) in units of 8 octets. For example,
the length for IEEE 802 addresses is 1
[IPv6-ETHER].
Link-Layer Address
The variable length link-layer address.
The content and format of this field (including
byte and bit ordering) is expected to be specified
in specific documents that describe how IPv6
operates over different link layers. For instance,
[IPv6-ETHER]. The contents of this field are to be
interpreted as described for the SLLAO and the
TLLAO options described in RFC4861.
Figure 2: OLLAO layout
Krishnan Expires May 5, 2008 [Page 9]
Internet-Draft Proxy SEND November 2007
7. Fallback procedure
If a receiving node does not trust a proxy it may elect to use the
original contents of the received neighbor discovery message instead
of the received contents. The original message can be derived as
follows
o Replace the contents of the TLLA option, if any, with the contents
of the OTLLA option while retaining the type field of the option
o Replace the contents of the SLLA option, if any, with the contents
of the OSLLA option while retaining the type field of the option
o Reset the value of the P bit if the received message is a Router
Advertisement
o Remove any proxy signature, OTLLA, and OSLLA options present in
the message
After obtaining the contents of the original message the receiving
node can perform SEND verification as described in [RFC3971]
Krishnan Expires May 5, 2008 [Page 10]
Internet-Draft Proxy SEND November 2007
8. Backward Compatibility with legacy SEND nodes
The options added by a SEND proxy, such as the PSO, will not be used
by nodes implementing the original SEND specification and hence will
not cause any interoperability problems. These legacy SEND nodes
will check the RSA signature option and will consider it invalid.
Based on the configuration of the host, the message MAY either be
treated as insecure or be dropped.
Krishnan Expires May 5, 2008 [Page 11]
Internet-Draft Proxy SEND November 2007
9. Security Considerations
The mechanism described in this document provides a method by which a
neighbor discovery proxy can replace the link layer address in any
neighbor discovery message with its own. The nodes receiving such
modified advertisements need to verify whether the proxy has been
authorized to perform the changes. For this the nodes depend on a
certificate issued to proxies, to authorize such changes.
Krishnan Expires May 5, 2008 [Page 12]
Internet-Draft Proxy SEND November 2007
10. IANA Considerations
This document uses three new neighbor discovery options and requests
the allocation of three different IPv6 Neighbor Discovery Option
types for each of these options. The values to be allocated are
denoted in the document as TBA1, TBA2 and TBA3. The values 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.
Krishnan Expires May 5, 2008 [Page 13]
Internet-Draft Proxy SEND November 2007
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[SENDEKU] Krishnan, S., "Authorization Certificates for Routers and
Proxies", Internet-Draft
draft-krishnan-cgaext-send-cert-eku-00, October 2007.
Krishnan Expires May 5, 2008 [Page 14]
Internet-Draft Proxy SEND November 2007
Author's Address
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Krishnan Expires May 5, 2008 [Page 15]
Internet-Draft Proxy SEND November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Krishnan Expires May 5, 2008 [Page 16]