draft-ietf-send-ndopt-04.txt   draft-ietf-send-ndopt-05.txt 
Secure Neighbor Discovery Working J. Arkko (Editor)
Secure Neighbor Discovery Working J. Arkko, Editor
Group Ericsson Group Ericsson
Internet-Draft J. Kempf Internet-Draft J. Kempf
Expires: August 16, 2004 DoCoMo Communications Labs USA Expires: October 12, 2004 DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
P. Nikander P. Nikander
Ericsson Ericsson
February 16, 2004 April 13, 2004
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-04 draft-ietf-send-ndopt-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 August 16, 2004. This Internet-Draft will expire on October 12, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine the link-layer addresses of other nodes on the link, to determine the link-layer addresses of
other nodes on the link, to find routers, and to maintain other nodes on the link, to find routers, and to maintain
skipping to change at page 2, line 17 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . . 4 1.1 Specification of Requirements . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11
5.1.1 Processing Rules for Senders . . . . . . . . . 12 5.1.1 Processing Rules for Senders . . . . . . . . . . 12
5.1.2 Processing Rules for Receivers . . . . . . . . 13 5.1.2 Processing Rules for Receivers . . . . . . . . . 13
5.1.3 Configuration . . . . . . . . . . . . . . . . 14 5.1.3 Configuration . . . . . . . . . . . . . . . . . 14
5.2 Signature Option . . . . . . . . . . . . . . . . . . .15 5.2 Signature Option . . . . . . . . . . . . . . . . . . . 14
5.2.1 Processing Rules for Senders . . . . . . . . . 17 5.2.1 Processing Rules for Senders . . . . . . . . . . 16
5.2.2 Processing Rules for Receivers . . . . . . . . 17 5.2.2 Processing Rules for Receivers . . . . . . . . . 17
5.2.3 Configuration . . . . . . . . . . . . . . . . 18 5.2.3 Configuration . . . . . . . . . . . . . . . . . 18
5.2.4 Performance Considerations . . . . . . . . . . 19 5.2.4 Performance Considerations . . . . . . . . . . . 19
5.3 Timestamp and Nonce options . . . . . . . . . . . . .20 5.3 Timestamp and Nonce options . . . . . . . . . . . . . 19
5.3.1 Timestamp Option . . . . . . . . . . . . . . . 20 5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 19
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 21 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 20
5.3.3 Processing rules for senders . . . . . . . . . 21 5.3.3 Processing rules for senders . . . . . . . . . . 21
5.3.4 Processing rules for receivers . . . . . . . . 22 5.3.4 Processing rules for receivers . . . . . . . . . 22
6. Authorization Delegation Discovery . . . . . . . . . . . . . 25 6. Authorization Delegation Discovery . . . . . . . . . . . . . 25
6.1 Certificate Format . . . . . . . . . . . . . . . . . .25 6.1 Certificate Format . . . . . . . . . . . . . . . . . .25
6.1.1 Router Authorization Certificate Profile . . . 25 6.1.1 Router Authorization Certificate Profile . . . . 25
6.2 Certificate Transport . . . . . . . . . . . . . . . .28 6.2 Certificate Transport . . . . . . . . . . . . . . . .28
6.2.1 Delegation Chain Solicitation Message Format . 28 6.2.1 Delegation Chain Solicitation Message Format . . 28
6.2.2 Delegation Chain Advertisement Message Format 30 6.2.2 Delegation Chain Advertisement Message Format . 30
6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32 6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 32
6.2.4 Certificate Option . . . . . . . . . . . . . . 34 6.2.4 Certificate Option . . . . . . . . . . . . . . . 34
6.2.5 Processing Rules for Routers . . . . . . . . . 35 6.2.5 Processing Rules for Routers . . . . . . . . . . 35
6.2.6 Processing Rules for Hosts . . . . . . . . . . 36 6.2.6 Processing Rules for Hosts . . . . . . . . . . . 36
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . .38 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . .38
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38
7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . 43 9. Security Considerations . . . . . . . . . . . . . . . . . . 42
9.1 Threats to the Local Link Not Covered by SEND . . . .43 9.1 Threats to the Local Link Not Covered by SEND . . . . 42
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .43 9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 42
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 44 9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 43
9.2.2 Neighbor Unreachability Detection Failure . . 44 9.2.2 Neighbor Unreachability Detection Failure . . . 43
9.2.3 Duplicate Address Detection DoS Attack . . . . 44 9.2.3 Duplicate Address Detection DoS Attack . . . . . 43
9.2.4 Router Solicitation and Advertisement Attacks 45 9.2.4 Router Solicitation and Advertisement Attacks . 44
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 45 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 44
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 46 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 45
9.3 Attacks against SEND Itself . . . . . . . . . . . . .46 9.3 Attacks against SEND Itself . . . . . . . . . . . . . 45
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 47
11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 49 11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 48
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
Normative References . . . . . . . . . . . . . . . . . . . . 51 Normative References . . . . . . . . . . . . . . . . . . . . 50
Informative References . . . . . . . . . . . . . . . . . . . 53 Informative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 56 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 57 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 58 Intellectual Property and Copyright Statements . . . . . . . 57
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7] IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
and 2462 [8]. Nodes on the same link use NDP to discover each and 2462 [8]. Nodes on the same link use NDP to discover each
other's presence, to determine each other's link-layer addresses, to other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the find routers, and to maintain reachability information about the
paths to active neighbors. NDP is used both by hosts and routers. paths to active neighbors. NDP is used both by hosts and routers.
Its functions include Neighbor Discovery (ND), Router Discovery (RD), Its functions include Neighbor Discovery (ND), Router Discovery (RD),
Address Autoconfiguration, Address Resolution, Neighbor Address Autoconfiguration, Address Resolution, Neighbor
skipping to change at page 4, line 26 skipping to change at page 4, line 26
The original NDP specifications called for the use of IPsec to The original NDP specifications called for the use of IPsec to
protect NDP messages. However, the RFCs do not give detailed protect NDP messages. However, the RFCs do not give detailed
instructions for using IPsec for this. In this particular instructions for using IPsec for this. In this particular
application, IPsec can only be used with a manual configuration of application, IPsec can only be used with a manual configuration of
security associations, due to bootstrapping problems in using IKE security associations, due to bootstrapping problems in using IKE
[21, 16]. Furthermore, the number of such manually configured [21, 16]. Furthermore, the number of such manually configured
security associations needed for protecting NDP can be very large security associations needed for protecting NDP can be very large
[22], making that approach impractical for most purposes. [22], making that approach impractical for most purposes.
This document is organized as follows. Section 2 and Section 3 This document is organized as follows. Section 2 and Section 3 define
define some terminology and present a brief review of NDP, some terminology and present a brief review of NDP, respectively.
respectively. Section 4 describes the overall approach to securing Section 4 describes the overall approach to securing NDP. This
NDP. This approach involves the use of new NDP options to carry approach involves the use of new NDP options to carry public-key
public-key based signatures. A zero-configuration mechanism is used based signatures. A zero-configuration mechanism is used for showing
for showing address ownership on individual nodes; routers are address ownership on individual nodes; routers are certified by a
certified by a trust anchor [10]. The formats, procedures, and trust anchor [10]. The formats, procedures, and cryptographic
cryptographic mechanisms for the zero-configuration mechanism are mechanisms for the zero-configuration mechanism are described in a
described in a related specification [13]. related specification [13].
The required new NDP options are discussed in Section 5. Section 6 The required new NDP options are discussed in Section 5. Section 6
describes the mechanism for distributing certificate chains to describes the mechanism for distributing certificate chains to
establish an authorization delegation chain to a common trust anchor. establish an authorization delegation chain to a common trust anchor.
Finally, Section 8 discusses the co-existence of secure and Finally, Section 8 discusses the co-existence of secure and
non-secure NDP on the same link and Section 9 discusses security non-secure NDP on the same link and Section 9 discusses security
considerations for Secure Neighbor Discovery (SEND). considerations for Secure Neighbor Discovery (SEND).
1.1 Specification of Requirements 1.1 Specification of Requirements
skipping to change at page 7, line 37 skipping to change at page 7, line 37
to a better first-hop router, or to inform hosts that a to a better first-hop router, or to inform hosts that a
destination is in fact a neighbor (i.e., on-link). Redirect is destination is in fact a neighbor (i.e., on-link). Redirect is
specified in Section 8 of RFC 2461 [7]. specified in Section 8 of RFC 2461 [7].
o Address Autoconfiguration is used for automatically assigning o Address Autoconfiguration is used for automatically assigning
addresses to a host [8]. This allows hosts to operate without addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The default explicit configuration related to IP connectivity. The default
autoconfiguration mechanism is stateless. To create IP addresses, autoconfiguration mechanism is stateless. To create IP addresses,
hosts use any prefix information delivered to them during Router hosts use any prefix information delivered to them during Router
Discovery, and then test the newly formed addresses for Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [20], provides uniqueness. A stateful mechanism, DHCPv6 [20], provides additional
additional autoconfiguration features. autoconfiguration features.
o Duplicate Address Detection (DAD) is used for preventing address o Duplicate Address Detection (DAD) is used for preventing address
collisions [8], for instance during Address Autoconfiguration. A collisions [8], for instance during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that there is no other node first runs the DAD procedure to verify that there is no other node
using the same address. Since the rules forbid the use of an using the same address. Since the rules forbid the use of an
address until it has been found unique, no higher layer traffic is address until it has been found unique, no higher layer traffic is
possible until this procedure has been completed. Thus, possible until this procedure has been completed. Thus,
preventing attacks against DAD can help ensure the availability of preventing attacks against DAD can help ensure the availability of
communications for the node in question. communications for the node in question.
o The Address Resolution function allows a node on the link to o The Address Resolution function allows a node on the link to
resolve another node's IPv6 address to the corresponding resolve another node's IPv6 address to the corresponding
link-layer address. Address Resolution is defined in Section 7.2 link-layer address. Address Resolution is defined in Section 7.2
of RFC 2461 [7], and it is used for hosts and routers alike. of RFC 2461 [7], and it is used for hosts and routers alike.
Again, no higher level traffic can proceed until the sender knows Again, no higher level traffic can proceed until the sender knows
the link layer address of the destination node or the next hop the link layer address of the destination node or the next hop
router. Note the source link layer address on link layer frames router. Note the source link layer address on link layer frames is
is not checked against the information learned through Address not checked against the information learned through Address
Resolution. This allows for an easier addition of network Resolution. This allows for an easier addition of network
elements such as bridges and proxies, and eases the stack elements such as bridges and proxies, and eases the stack
implementation requirements as less information needs to be passed implementation requirements as less information needs to be passed
from layer to layer. from layer to layer.
o Neighbor Unreachability Detection (NUD) is used for tracking the o Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighboring nodes, both hosts and routers. NUD is reachability of neighboring nodes, both hosts and routers. NUD is
defined in Section 7.3 of RFC 2461 [7]. NUD is defined in Section 7.3 of RFC 2461 [7]. NUD is
security-sensitive, because an attacker could falsely claim that security-sensitive, because an attacker could falsely claim that
reachability exists when it in fact does not. reachability exists when it in fact does not.
skipping to change at page 11, line 18 skipping to change at page 11, line 18
nodes. nodes.
5.1 CGA Option 5.1 CGA Option
The CGA option allows the verification of the sender's CGA. The The CGA option allows the verification of the sender's CGA. The
format of the CGA option is described as follows. format of the CGA option is described as follows.
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 | Collision Cnt | Reserved | | Type | Length | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Modifier |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Key Information . . CGA Parameters .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD <To be assigned by IANA for CGA>. TBD <To be assigned by IANA for CGA>.
Length Length
The length of the option (including the Type, Length, Collision The length of the option (including the Type, Length, Pad Length,
Cnt, Reserved, Modifier, Key Information, and Padding fields) in Reserved, CGA Parameters, and Padding fields) in units of 8
units of 8 octets. octets.
Collision Cnt Pad Length
An 8-bit collision count, which can be 0, 1 or 2. Its semantics The number of padding octets beyond the end of the CGA Parameters
are defined in [13]. field but within the length specified by the Length field. Padding
octets MUST be set to zero by senders and ignored by receivers.
Reserved Reserved
An 8-bit field reserved for future use. The value MUST be An 8-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.
Modifier CGA Parameters
A random 128-bit number used in CGA generation. Its semantics are
defined in [13].
Key Information
A variable length field containing the public key of the sender, A variable length field containing the CGA Parameters data
represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as structure described in Section 4 of [13].
described in Section 4 of [13].
This specification requires that if both the CGA option and the This specification requires that if both the CGA option and the
Signature option are present, then the publicKey field in the CGA Signature option are present, then the public key found from the
option MUST be the public key referred by the Key Hash field in CGA Parameters field in the CGA option MUST be the public key
the Signature option. Packets received with two different keys referred by the Key Hash field in the Signature option. Packets
MUST be silently discarded. Note that a future extension may received with two different keys MUST be silently discarded. Note
provide a mechanism which allows the owner of an address and the that a future extension may provide a mechanism which allows the
signer to be different parties. owner of an address and the signer to be different parties.
The length of the Key Information field is determined by the ASN.1
encoding.
Padding Padding
A variable length field making the option length a multiple of 8, A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field ends, and containing as many octets as specified in the Pad Length field.
continuing to the end of the option, as specified by the Length
field.
5.1.1 Processing Rules for Senders 5.1.1 Processing Rules for Senders
The CGA option MUST be present in all Neighbor Solicitation and The CGA option MUST be present in all Neighbor Solicitation and
Advertisement messages, and MUST be present in Router Solicitation Advertisement messages, and MUST be present in Router Solicitation
messages unless they are sent with the unspecified source address. messages unless they are sent with the unspecified source address.
The CGA option MAY be present in other messages. The CGA option MAY be present in other messages.
A node sending a message using the CGA option MUST construct the A node sending a message using the CGA option MUST construct the
message as follows. message as follows.
The Modifier, Collision Cnt, and Key Information fields in the CGA The CGA Parameter field in the CGA option is filled in according to
option are filled in according to the rules presented above and in the rules presented above and in [13]. The public key in the field is
[13]. The public key in the Key Information field is taken from the taken from the node's configuration used to generate the CGA;
node's configuration used to generate the CGA; typically from a data typically from a data structure associated with the source address.
structure associated with the source address. The address MUST be The address MUST be constructed as specified in Section 4 of [13].
constructed as specified in Section 4 of [13]. Depending on the type Depending on the type of the message, this address appears in
of the message, this address appears in different places: different places:
Redirect Redirect
The address MUST be the source address of the message. The address MUST be the source address of the message.
Neighbor Solicitation Neighbor Solicitation
The address MUST be the Target Address for solicitations sent for The address MUST be the Target Address for solicitations sent for
Duplicate Address Detection, and the source address of the message Duplicate Address Detection, and the source address of the message
otherwise. otherwise.
skipping to change at page 14, line 6 skipping to change at page 13, line 38
Router Solicitation messages without the CGA option MUST be also Router Solicitation messages without the CGA option MUST be also
treated as insecure, unless the source address of the message is the treated as insecure, unless the source address of the message is the
unspecified address. unspecified address.
A message containing a CGA option MUST be checked as follows: A message containing a CGA option MUST be checked as follows:
If the interface has been configured to use CGA, the receiving If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet using the node MUST verify the source address of the packet using the
algorithm described in Section 5 of [13]. The inputs to the algorithm described in Section 5 of [13]. The inputs to the
algorithm are the claimed address, as defined in the previous algorithm are the claimed address, as defined in the previous
section, and the concatenation from left to right of the following section, and the CGA Parameters field.
data: the contents of the 8-octet Modifier field, the 8-octet
subnet-prefix part of the claimed address, the content of the
1-octet Collision Cnt field, and contents of the variable-length
Key Information Field.
If the CGA verification is successful, the recipient proceeds with If the CGA verification is successful, the recipient proceeds with
the cryptographically more time consuming check of the signature. the cryptographically more time consuming check of the signature.
However, even if the CGA verification succeeds, no claims about However, even if the CGA verification succeeds, no claims about
the validity of the use can be made, until the signature has been the validity of the use can be made, until the signature has been
checked. checked.
Note that a receiver that does not support CGA or has not specified Note that a receiver that does not support CGA or has not specified
its use for a given interface can still verify packets using trust its use for a given interface can still verify packets using trust
anchors, even if a CGA is used on a packet. In such a case, the CGA anchors, even if a CGA is used on a packet. In such a case, the CGA
skipping to change at page 14, line 34 skipping to change at page 14, line 16
All nodes that support the verification of the CGA option MUST record All nodes that support the verification of the CGA option MUST record
the following configuration information: the following configuration information:
minbits minbits
The minimum acceptable key length for public keys used in the The minimum acceptable key length for public keys used in the
generation of CGAs. The default SHOULD be 1024 bits. generation of CGAs. The default SHOULD be 1024 bits.
Implementations MAY also set an upper limit in order to limit the Implementations MAY also set an upper limit in order to limit the
amount of computation they need to perform when verifying packets amount of computation they need to perform when verifying packets
that use these security associations. The upper limit SHOULD be that use these security associations. The upper limit SHOULD be at
at least 2048 bits. Any implementation should follow prudent least 2048 bits. Any implementation should follow prudent
cryptographic practice in determining the appropriate key lengths. cryptographic practice in determining the appropriate key lengths.
minSec minSec
The minimum acceptable Sec value, if CGA verification is required. The minimum acceptable Sec value, if CGA verification is required.
This parameter is intended to facilitate future extensions and This parameter is intended to facilitate future extensions and
experimental work. Currently, the minSec value SHOULD always be experimental work. Currently, the minSec value SHOULD always be
set to zero. set to zero.
See Section 2 in [13]. See Section 2 in [13].
skipping to change at page 15, line 13 skipping to change at page 14, line 40
following configuration information: following configuration information:
CGA parameters CGA parameters
Any information required to construct CGAs, including the used Sec Any information required to construct CGAs, including the used Sec
and Modifier values, and the CGA address itself. and Modifier values, and the CGA address itself.
5.2 Signature Option 5.2 Signature Option
The Signature option allows public-key based signatures to be The Signature option allows public-key based signatures to be
attached to NDP messages. Configured trust anchors, CGAs, or both attached to NDP messages. Configured trust anchors, CGAs, or both are
are supported as the trusted root. The format of the Signature supported as the trusted root. The format of the Signature option is
option is described in the following diagram: described in the following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key Hash | | Key Hash |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Digital Signature . . Digital Signature .
. . . .
skipping to change at page 15, line 46 skipping to change at page 15, line 34
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD <To be assigned by IANA for Signature>. TBD <To be assigned by IANA for Signature>.
Length Length
The length of the option (including the Type, Length, Pad Length, The length of the option (including the Type, Length, Reserved,
Reserved, Key Hash, Digital Signature, and Padding fields) in Key Hash, Digital Signature, and Padding fields) in units of 8
units of 8 octets. octets.
Pad Length
An 8-bit integer field, giving the length of the Pad field in
units of an octet.
Reserved Reserved
An 8-bit field reserved for future use. The value MUST be A 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
Key Hash Key Hash
A 128-bit field containing the most significant (leftmost) A 128-bit field containing the most significant (leftmost)
128-bits of a SHA-1 hash of the public key used for constructing 128-bits of a SHA-1 hash of the public key used for constructing
the signature. The SHA-1 hash is taken over the presentation used the signature. The SHA-1 hash is taken over the presentation used
in the Key Information field of the CGA option. Its purpose is to in the Public Key field of the CGA Parameters data structure that
associate the signature to a particular key known by the receiver. is carried in the CGA option. Its purpose is to associate the
Such a key can be either stored in the certificate cache of the signature to a particular key known by the receiver. Such a key
receiver, or be received in the CGA option in the same message. can be either stored in the certificate cache of the receiver, or
be received in the CGA option in the same message.
Digital Signature Digital Signature
A variable length field containing a PKCS#1 signature, constructed A variable length field containing a PKCS#1 signature, constructed
using the sender's private key, over the the following sequence of using the sender's private key, over the the following sequence of
octets: octets:
1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F 1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F
CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
generated randomly by the editor of this specification.). generated randomly by the editor of this specification.).
skipping to change at page 17, line 7 skipping to change at page 16, line 36
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 [14]. algorithm and SHA-1 hash as defined in [14].
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 Digital Signature field is determined by the length of the
Signature option minus the length of the other fields (including Signature option minus the length of the other fields (including
the variable length Pad field). the variable length Pad field).
Padding Padding
This variable length field contains padding, as many bytes as is This variable length field contains padding, as many bytes as
given by the Pad Length field. remains after end of the signature.
5.2.1 Processing Rules for Senders 5.2.1 Processing Rules for Senders
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages MUST contain the Signature option. Router and Redirect messages MUST contain the Signature option. Router
Solicitation messages not sent with the unspecified source address Solicitation messages not sent with the unspecified source address
MUST contain the Signature option. MUST contain the Signature option.
A node sending a message using the Signature option MUST construct A node sending a message using the Signature option MUST construct
the message as follows: the message as follows:
skipping to change at page 19, line 31 skipping to change at page 19, line 13
the following configuration information: the following configuration information:
keypair keypair
A public-private key pair. If authorization delegation is in use, A public-private key pair. If authorization delegation is in use,
there must exist a delegation chain from a trust anchor to this there must exist a delegation chain from a trust anchor to this
key pair. key pair.
CGA flag CGA flag
A flag that indicates whether CGA is used or not. This flag may A flag that indicates whether CGA is used or not. This flag may be
be per interface or per node. (Note that in future extensions of per interface or per node. (Note that in future extensions of the
the SEND protocol, this flag may be per subnet-prefix.) SEND protocol, this flag may be per subnet-prefix.)
5.2.4 Performance Considerations 5.2.4 Performance Considerations
The construction and verification of this option is computationally The construction and verification of this option is computationally
expensive. In the NDP context, however, the hosts typically have the expensive. In the NDP context, however, the hosts typically have the
need to perform only a few signature operations as they enter a link, need to perform only a few signature operations as they enter a link,
and a few operations as they find a new on-link peer with which to and a few operations as they find a new on-link peer with which to
communicate. communicate.
Routers are required to perform a larger number of operations, Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature to mobility requirements. Still, the number of required signature
operations is on the order of a few dozen per second, some of which operations is on the order of a few dozen per second, some of which
can be precomputed as explained below. A large number of router can be precomputed as explained below. A large number of router
solicitations may cause higher demand for performing asymmetric solicitations may cause higher demand for performing asymmetric
operations, although RFC 2461 limits the rate at which responses to operations, although RFC 2461 limits the rate at which responses to
solicitations can be sent. solicitations can be sent.
Signatures can be precomputed for unsolicited (multicast) Neighbor Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements if the timing of such future advertisements and Router Advertisements if the timing of such future advertisements
is known. Typically, solicited advertisements are sent to the is known. Typically, solicited advertisements are sent to the unicast
unicast address from which the solicitation was sent. Given that the address from which the solicitation was sent. Given that the IPv6
IPv6 header is covered by the signature, it is not possible to header is covered by the signature, it is not possible to precompute
precompute solicited advertisements. solicited advertisements.
5.3 Timestamp and Nonce options 5.3 Timestamp and Nonce options
5.3.1 Timestamp Option 5.3.1 Timestamp Option
The purpose of the Timestamp option is to assure that unsolicited The purpose of the Timestamp option is to assure that unsolicited
advertisements and redirects have not been replayed. The format of advertisements and redirects have not been replayed. The format of
this option is described in the following: this option is described in the following:
0 1 2 3 0 1 2 3
skipping to change at page 21, line 37 skipping to change at page 21, line 29
Length Length
The length of the option (including the Type, Length, and Nonce The length of the option (including the Type, Length, and Nonce
fields) in units of 8 octets. fields) in units of 8 octets.
Nonce Nonce
A field containing a random number selected by the sender of the A field containing a random number selected by the sender of the
solicitation message. The length of the random number MUST be at solicitation message. The length of the random number MUST be at
least 6 bytes. The length of the random number MUST be selected least 6 bytes. The length of the random number MUST be selected so
so that the length of the nonce option is a multiple of 8 octets. that the length of the nonce option is a multiple of 8 octets.
5.3.3 Processing rules for senders 5.3.3 Processing rules for senders
All solicitation messages MUST include a Nonce. When sending a All solicitation messages MUST include a Nonce. When sending a
solicitation, the sender MUST store the nonce internally so that it solicitation, the sender MUST store the nonce internally so that it
can recognize any replies containing that particular nonce. can recognize any replies containing that particular nonce.
All solicited advertisements MUST include a Nonce, copied from the All solicited advertisements MUST include a Nonce, copied from the
received solicitation. Note that routers may decide to send a received solicitation. Note that routers may decide to send a
multicast advertisement to all nodes instead of a response to a multicast advertisement to all nodes instead of a response to a
specific host. In such case the router MAY still include the nonce specific host. In such case the router MAY still include the nonce
value for the host that triggered the multicast advertisement. value for the host that triggered the multicast advertisement.
Omitting the nonce value may, however, cause the host to ignore the
router's advertisement, unless the clocks in these nodes are
sufficiently synchronized so that timestamps can be relied on.
All solicitation, advertisement, and redirect messages MUST include a All solicitation, advertisement, and redirect messages MUST include a
Timestamp. Senders SHOULD set the Timestamp field to the current Timestamp. Senders SHOULD set the Timestamp field to the current
time, according to their real time clock. time, according to their real time clock.
If a message has both Nonce and Timestamp options, the Nonce option If a message has both Nonce and Timestamp options, the Nonce option
SHOULD precede the Timestamp option in the message. SHOULD precede the Timestamp option in the message.
5.3.4 Processing rules for receivers 5.3.4 Processing rules for receivers
skipping to change at page 25, line 50 skipping to change at page 25, line 50
single trust anchor. single trust anchor.
6.1.1 Router Authorization Certificate Profile 6.1.1 Router Authorization Certificate Profile
Router Authorization Certificates are X.509v3 certificates, as Router Authorization Certificates are X.509v3 certificates, as
defined in RFC 3280 [10], and MUST contain at least one instance of defined in RFC 3280 [10], and MUST contain at least one instance of
the X.509 extension for IP addresses, as defined in [12]. The parent the X.509 extension for IP addresses, as defined in [12]. The parent
certificates in the certificate chain MUST contain one or more X.509 certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to a trusted party (such as the user's IP address extensions, back up to a trusted party (such as the user's
ISP) that configured the original IP address space block for the ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so. The router in question, or delegated the right to do so. The certificates
certificates for the intermediate delegating authorities MUST contain for the intermediate delegating authorities MUST contain X.509 IP
X.509 IP address extension(s) for subdelegations. The router's address extension(s) for subdelegations. The router's certificate is
certificate is signed by the delegating authority for the prefixes signed by the delegating authority for the prefixes the router is
the router is authorized to to advertise. authorized to to advertise.
The X.509 IP address extension MUST contain at least one The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an addressesOrRanges element. This element MUST contain an addressPrefix
addressPrefix element containing an IPv6 address prefix for a prefix element containing an IPv6 address prefix for a prefix the router or
the router or the intermediate entity is authorized to route. If the the intermediate entity is authorized to route. If the entity is
entity is allowed to route any prefix, the used IPv6 address prefix allowed to route any prefix, the used IPv6 address prefix is the null
is the null prefix, ::/0. The addressFamily element of the prefix, ::/0. The addressFamily element of the containing
containing IPAddrBlocks sequence element MUST contain the IPv6 IPAddrBlocks sequence element MUST contain the IPv6 Address Family
Address Family Identifier (0002), as specified in [12] for IPv6 Identifier (0002), as specified in [12] for IPv6 prefixes. Instead
prefixes. Instead of an addressPrefix element, the addressesOrRange of an addressPrefix element, the addressesOrRange element MAY contain
element MAY contain an addressRange element for a range of prefixes, an addressRange element for a range of prefixes, if more than one
if more than one prefix is authorized. The X.509 IP address prefix is authorized. The X.509 IP address extension MAY contain
extension MAY contain additional IPv6 prefixes, expressed either as additional IPv6 prefixes, expressed either as an addressPrefix or an
an addressPrefix or an addressRange. addressRange.
A SEND node receiving a Router Authorization Certificate MUST first A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If addressPrefix entries in the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within the an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attempt to delegating authority's prefixes or ranges, the client MAY attempt to
skipping to change at page 28, line 9 skipping to change at page 28, line 9
... other certificate parameters ... ... other certificate parameters ...
When processing the three certificates, the usual RFC 3280 [10] When processing the three certificates, the usual RFC 3280 [10]
certificate path validation is performed. Note, however, that at the certificate path validation is performed. Note, however, that at the
time a node is checking certificates received in a DCA from a router, time a node is checking certificates received in a DCA from a router,
it typically does not have a connection to the Internet yet, and so it typically does not have a connection to the Internet yet, and so
it is not possible to perform an on-line Certificate Revocation List it is not possible to perform an on-line Certificate Revocation List
(CRL) check if such a check is necessary. Until such a check is (CRL) check if such a check is necessary. Until such a check is
performed, acceptance of the certificate MUST be considered performed, acceptance of the certificate MUST be considered
provisional, and the node MUST perform a check as soon as it has provisional, and the node MUST perform a check as soon as it has
established a connection with the Internet through the router. If established a connection with the Internet through the router. If the
the router has been compromised, it could interfere with the CRL router has been compromised, it could interfere with the CRL check.
check. Should performance of the CRL check be disrupted or should Should performance of the CRL check be disrupted or should the check
the check fail, the node SHOULD immediately stop using the router as fail, the node SHOULD immediately stop using the router as a default
a default and use another router on the link instead. and use another router on the link instead.
In addition, the IP addresses in the delegation extension must be a In addition, the IP addresses in the delegation extension must be a
subset of the IP addresses in the delegation extension of the subset of the IP addresses in the delegation extension of the
issuer's certificate. So in this example, R1, ..., Rs must be a issuer's certificate. So in this example, R1, ..., Rs must be a
subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If
the certificate chain is valid, then router_foo.isp_foo_example.com the certificate chain is valid, then router_foo.isp_foo_example.com
is authorized to route the prefixes R1,...,Rs. is authorized to route the prefixes R1,...,Rs.
6.2 Certificate Transport 6.2 Certificate Transport
skipping to change at page 33, line 10 skipping to change at page 33, line 10
6.2.3 Trust Anchor Option 6.2.3 Trust Anchor Option
The format of the Trust Anchor option is described in the following: The format of the Trust Anchor option is described in the following:
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 | Name Type | Pad Length | | Type | Length | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... | Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD <To be assigned by IANA for Trust Anchor>. TBD <To be assigned by IANA for Trust Anchor>.
Length Length
The length of the option, (including the Type, Length, Name Type, The length of the option, (including the Type, Length, Name Type,
Pad Length, and Name fields) in units of 8 octets. Pad Length, and Name fields) in units of 8 octets.
skipping to change at page 34, line 9 skipping to change at page 34, line 11
In the FQDN case the Name field is an "IDN-unaware domain name In the FQDN case the Name field is an "IDN-unaware domain name
slot" as defined in [11]. That is, it can contain only ASCII slot" as defined in [11]. That is, it can contain only ASCII
characters. An implementation MAY support internationalized characters. An implementation MAY support internationalized
domain names (IDNs) using the ToASCII operation; see [11] for more domain names (IDNs) using the ToASCII operation; see [11] for more
information. information.
All systems MUST support the DER Encoded X.501 Name. All systems MUST support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type. Implementations MAY support the FQDN name type.
Padding
A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field ends, and
continuing to the end of the option, as specified by the Length
field.
6.2.4 Certificate Option 6.2.4 Certificate Option
The format of the certificate option is described in the following: The format of the certificate option is described in the following:
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 | Cert Type | Pad Length | | Type | Length | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ... | Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD <To be assigned by IANA for Certificate>. TBD <To be assigned by IANA for Certificate>.
Length Length
The length of the option, (including the Type, Length, Cert Type, The length of the option, (including the Type, Length, Cert Type,
Pad Length, and Certificate fields) in units of 8 octets. Pad Length, and Certificate fields) in units of 8 octets.
Cert Type Cert Type
The type of the certificate included in the Certificate field. The type of the certificate included in the Certificate field.
This specification defines only one legal value for this field: This specification defines only one legal value for this field:
1 X.509v3 Certificate, as specified below 1 X.509v3 Certificate, as specified below
Reserved
Pad Length An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
The number of padding octets beyond the end of the Certificate receiver.
field but within the length specified by the Length field.
Padding octets MUST be set to zero by senders and ignored by
receivers.
Certificate Certificate
When the Cert Type field is set to 1, the Certificate field When the Cert Type field is set to 1, the Certificate field
contains an X.509v3 certificate [10], as described in Section contains an X.509v3 certificate [10], as described in Section
6.1.1. 6.1.1.
Padding
A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field ends, and
continuing to the end of the option, as specified by the Length
field.
6.2.5 Processing Rules for Routers 6.2.5 Processing Rules for Routers
Routers should be configured with a key pair and a certificate from Routers should be configured with a key pair and a certificate from
at least one certificate authority. at least one certificate authority.
A router MUST silently discard any received Delegation Chain A router MUST silently discard any received Delegation Chain
Solicitation messages that do not conform to the message format Solicitation messages that do not conform to the message format
defined in Section 6.2.1. The contents of the Reserved field, and of defined in Section 6.2.1. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future, any unrecognized options, MUST be ignored. Future,
backward-compatible changes to the protocol may specify the contents backward-compatible changes to the protocol may specify the contents
skipping to change at page 36, line 28 skipping to change at page 36, line 46
options that are not specified to be used with Delegation Chain options that are not specified to be used with Delegation Chain
Advertisement messages MUST be ignored and the packet processed in Advertisement messages MUST be ignored and the packet processed in
the normal manner. The only defined options that may appear are the the normal manner. The only defined options that may appear are the
Certificate and Trust Anchor options. An advertisement that passes Certificate and Trust Anchor options. An advertisement that passes
the validity checks is called a "valid advertisement". the validity checks is called a "valid advertisement".
Hosts SHOULD store certificate chains retrieved in Delegation Chain Hosts SHOULD store certificate chains retrieved in Delegation Chain
Discovery messages if they start from an anchor trusted by the host. Discovery messages if they start from an anchor trusted by the host.
The certificate chains MUST be verified, as defined in Section 6.1, The certificate chains MUST be verified, as defined in Section 6.1,
before storing them. Routers MUST send the certificates one by one, before storing them. Routers MUST send the certificates one by one,
starting from the trust anchor end of the chain. Except for starting from the trust anchor end of the chain. Except for temporary
temporary purposes to allow for message loss and reordering, hosts purposes to allow for message loss and reordering, hosts SHOULD NOT
SHOULD NOT store certificates received in a Delegation Chain store certificates received in a Delegation Chain Advertisement
Advertisement unless they contain a certificate which can be unless they contain a certificate which can be immediately verified
immediately verified either to the trust anchor or to a certificate either to the trust anchor or to a certificate that has been verified
that has been verified earlier. earlier.
Note that caching this information and the implied verification Note that caching this information and the implied verification
results between network attachments for use over multiple attachments results between network attachments for use over multiple attachments
to the network can help improve performance. But periodic to the network can help improve performance. But periodic certificate
certificate revocation checks are still needed even with cached revocation checks are still needed even with cached results, to make
results, to make sure that the certificates are still valid. sure that the certificates are still valid.
The host has a need to retrieve a delegation chain when a Router The host has a need to retrieve a delegation chain when a Router
Advertisement has been received with a public key that is not stored Advertisement has been received with a public key that is not stored
in the hosts' cache of certificates, or there is no authorization in the hosts' cache of certificates, or there is no authorization
delegation chain to the host's trust anchor. In these situations, delegation chain to the host's trust anchor. In these situations, the
the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain
Solicitation messages, each separated by at least DCS_INTERVAL Solicitation messages, each separated by at least DCS_INTERVAL
seconds. seconds.
Delegation Chain Solicitations SHOULD NOT be sent if the host has a Delegation Chain Solicitations SHOULD NOT be sent if the host has a
currently valid certificate chain from a reachable router to a trust currently valid certificate chain from a reachable router to a trust
anchor. anchor.
When soliciting certificates for a router, a host MUST send When soliciting certificates for a router, a host MUST send
Delegation Chain Solicitations either to the All-Routers multicast Delegation Chain Solicitations either to the All-Routers multicast
address, if it has not selected a default router yet, or to the address, if it has not selected a default router yet, or to the
skipping to change at page 38, line 10 skipping to change at page 38, line 10
solicitation, the host MAY prefer to process first those solicitation, the host MAY prefer to process first those
advertisements with the same Identifier field value as in the advertisements with the same Identifier field value as in the
solicitation. This makes Denial-of-Service attacks against the solicitation. This makes Denial-of-Service attacks against the
mechanism harder (see Section 9.3). mechanism harder (see Section 9.3).
7. Addressing 7. Addressing
7.1 CGAs 7.1 CGAs
Nodes that use stateless address autoconfiguration SHOULD generate a Nodes that use stateless address autoconfiguration SHOULD generate a
new CGA as specified in Section 4 of [13] each time they run the new CGA and a CGA Parameters data structure as specified in Section 4
autoconfiguration procedure. The nodes MAY continue to use the same of [13] each time they run the autoconfiguration procedure.
public key and modifier, and start the process from Step 4 of the
generation algorithm.
By default, a SEND-enabled node SHOULD use only CGAs for its own By default, a SEND-enabled node SHOULD use only CGAs for its own
addresses. Other types of addresses MAY be used in testing, addresses. Other types of addresses MAY be used in testing,
diagnostics or for other purposes. However, this document does not diagnostics or for other purposes. However, this document does not
describe how to choose between different types of addresses for describe how to choose between different types of addresses for
different communications. A dynamic selection can be provided by an different communications. A dynamic selection can be provided by an
API, such as the one defined in [23]. API, such as the one defined in [23].
7.2 Redirect Addresses 7.2 Redirect Addresses
skipping to change at page 39, line 21 skipping to change at page 39, line 19
should configure routers with certificates containing either the should configure routers with certificates containing either the
null prefix or no prefix extension at all. null prefix or no prefix extension at all.
Upon processing a Prefix Information option within a Router Upon processing a Prefix Information option within a Router
Advertisement, nodes SHOULD verify that the prefix specified in this Advertisement, nodes SHOULD verify that the prefix specified in this
option falls within the range defined by the certificate, if the option falls within the range defined by the certificate, if the
certificate contains a prefix extension. Options failing this check certificate contains a prefix extension. Options failing this check
are treated as containing uncertified prefixes. are treated as containing uncertified prefixes.
Nodes SHOULD use one of the certified prefixes for stateless Nodes SHOULD use one of the certified prefixes for stateless
autoconfiguration. If none of the advertised prefixes match, the autoconfiguration. If none of the advertised prefixes match, the host
host SHOULD use a different advertising router as its default router, SHOULD use a different advertising router as its default router, if
if available. If the node is performing stateful autoconfiguration, available. If the node is performing stateful autoconfiguration, it
it SHOULD check the address provided by the DHCP server against the SHOULD check the address provided by the DHCP server against the
certified prefixes and SHOULD NOT use the address if the prefix is certified prefixes and SHOULD NOT use the address if the prefix is
not certified. not certified.
7.4 Limitations 7.4 Limitations
This specification does not address the protection of NDP packets for This specification does not address the protection of NDP packets for
nodes that are configured with a static address (e.g., PREFIX::1). nodes that are configured with a static address (e.g., PREFIX::1).
Future certificate chain-based authorization specifications are Future certificate chain-based authorization specifications are
needed for such nodes. needed for such nodes.
skipping to change at page 40, line 4 skipping to change at page 39, line 50
particular interface identifier. This specification does not specify particular interface identifier. This specification does not specify
the format of such certificates, since there are currently a few the format of such certificates, since there are currently a few
cases where such certificates are required by the link layer and it cases where such certificates are required by the link layer and it
is up to the link layer to provide certification for the interface is up to the link layer to provide certification for the interface
identifier. This may be the subject of a future specification. It identifier. This may be the subject of a future specification. It
is also outside the scope of this specification to describe how is also outside the scope of this specification to describe how
stateful address autoconfiguration works with the CGA method. stateful address autoconfiguration works with the CGA method.
The Target Address in Neighbor Advertisement is required to be equal The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in the case of proxy to the source address of the packet, except in the case of proxy
Neighbor Discovery. Proxy Neighbor Discovery is not supported by Neighbor Discovery. Proxy Neighbor Discovery is not supported by this
this specification. specification.
8. Transition Issues 8. Transition Issues
During the transition to secure links or as a policy consideration, During the transition to secure links or as a policy consideration,
network operators may want to run a particular link with a mixture of network operators may want to run a particular link with a mixture of
secure and insecure nodes. Nodes that support SEND SHOULD support secure and insecure nodes. Nodes that support SEND SHOULD support
the use of SEND and plain NDP at the same time. the use of SEND and plain NDP at the same time.
In a mixed environment, SEND nodes receive both secure and insecure In a mixed environment, SEND nodes receive both secure and insecure
messages but give priority to "secured" ones. Here, the "secured" messages but give priority to "secured" ones. Here, the "secured"
skipping to change at page 42, line 15 skipping to change at page 41, line 15
Detection for the first tentative address. This configuration Detection for the first tentative address. This configuration
option SHOULD be disabled by default. This is a recovery option SHOULD be disabled by default. This is a recovery
mechanism, in case attacks against the first address become mechanism, in case attacks against the first address become
common. common.
o The Neighbor Cache, Prefix List and Default Router list entries o The Neighbor Cache, Prefix List and Default Router list entries
MUST have a secured/insecure flag that indicates whether the MUST have a secured/insecure flag that indicates whether the
message that caused the creation or last update of the entry was message that caused the creation or last update of the entry was
secured or insecure. Received insecure messages MUST NOT cause secured or insecure. Received insecure messages MUST NOT cause
changes to existing secured entries in the Neighbor Cache, Prefix changes to existing secured entries in the Neighbor Cache, Prefix
List or Default Router List. The Neighbor Cache SHOULD implement List or Default Router List. The Neighbor Cache SHOULD implement a
a flag on entries indicating whether the entry issecured. flag on entries indicating whether the entry issecured. Received
Received secured messages MUST cause an update of the matching secured messages MUST cause an update of the matching entries and
entries and flagging of them as secured. flagging of them as secured.
o The conceptual sending algorithm is modified so that an insecure o The conceptual sending algorithm is modified so that an insecure
router is selected only if there is no reachable SEND router for router is selected only if there is no reachable SEND router for
the prefix. That is, the algorithm for selecting a default router the prefix. That is, the algorithm for selecting a default router
favors reachable SEND routers over reachable non-SEND ones. favors reachable SEND routers over reachable non-SEND ones.
o A node MAY adopt an insecure router, including a SEND router for
which full security checks have not yet been completed, while
security checking for the SEND router is underway. Security checks
in this case include delegation chain solicitation, certificate
verification, CRL checks, and RA signature checks. A node MAY also
adopt an insecure router if a SEND router becomes unreachable, but
SHOULD attempt to find a SEND router as soon as possible, since
the unreachability may be the result of an attack. Note that while
this can speed up attachment to a new network, accepting an
insecure router opens the node to possible attacks, and nodes that
choose to accept insecure routers do so at their own risk. The
node SHOULD in any case prefer the SEND router as soon as one is
available with completed security checks.
o A SEND node SHOULD have a configuration option that causes it to o A SEND node SHOULD have a configuration option that causes it to
ignore all insecure Neighbor Solicitation and Advertisement, ignore all insecure Neighbor Solicitation and Advertisement,
Router Solicitation and Advertisement, and Redirect messages. Router Solicitation and Advertisement, and Redirect messages. This
This can be used to enforce SEND-only networks. can be used to enforce SEND-only networks.
9. Security Considerations 9. Security Considerations
9.1 Threats to the Local Link Not Covered by SEND 9.1 Threats to the Local Link Not Covered by SEND
SEND does not provide confidentiality for NDP communications. SEND does not provide confidentiality for NDP communications.
SEND does not compensate for an insecure link layer. For instance, SEND does not compensate for an insecure link layer. For instance,
there is no assurance that payload packets actually come from the there is no assurance that payload packets actually come from the
same peer that the NDP was run against. same peer that the NDP was run against.
skipping to change at page 43, line 28 skipping to change at page 42, line 28
attacker could disrupt IP service by sending out a Neighbor attacker could disrupt IP service by sending out a Neighbor
Advertisement having the source address on the link layer frame of a Advertisement having the source address on the link layer frame of a
victim, a valid CGA address and a valid signature corresponding to victim, a valid CGA address and a valid signature corresponding to
itself, and a Target Link-layer Address extension corresponding to itself, and a Target Link-layer Address extension corresponding to
the victim. The attacker could then proceed to cause a traffic the victim. The attacker could then proceed to cause a traffic
stream to bombard the victim in a DoS attack. This attack cannot be stream to bombard the victim in a DoS attack. This attack cannot be
prevented just by securing the link layer. prevented just by securing the link layer.
Even on a secure link layer, SEND does not require that the addresses Even on a secure link layer, SEND does not require that the addresses
on the link layer and Neighbor Advertisements correspond to each on the link layer and Neighbor Advertisements correspond to each
other. However, it is RECOMMENDED that such checks be performed other. However, it is RECOMMENDED that such checks be performed where
where this is possible on the given link layer technology. this is possible on the given link layer technology.
Prior to participating in Neighbor Discovery and Duplicate Address Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the link-scoped All-Nodes Detection, nodes must subscribe to the link-scoped All-Nodes
Multicast Group and the Solicited-Node Multicast Group for the Multicast Group and the Solicited-Node Multicast Group for the
address that they are claiming for their addresses; RFC 2461 [7]. address that they are claiming for their addresses; RFC 2461 [7].
Subscribing to a multicast group requires that the nodes use MLD Subscribing to a multicast group requires that the nodes use MLD
[17]. MLD contains no provision for security. An attacker could [17]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the send an MLD Done message to unsubscribe a victim from the
Solicited-Node Multicast address. However, the victim should be able Solicited-Node Multicast address. However, the victim should be able
to detect such an attack because the router sends a to detect such an attack because the router sends a
skipping to change at page 44, line 15 skipping to change at page 43, line 15
9.2.1 Neighbor Solicitation/Advertisement Spoofing 9.2.1 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [24]. The threat is that This threat is defined in Section 4.1.1 of [24]. The threat is that
a spoofed message may cause a false entry in a node's Neighbor Cache. a spoofed message may cause a false entry in a node's Neighbor Cache.
There are two cases: There are two cases:
1. Entries made as a side effect of a Neighbor Solicitation or 1. Entries made as a side effect of a Neighbor Solicitation or
Router Solicitation. A router receiving a Router Solicitation Router Solicitation. A router receiving a Router Solicitation
with a Target Link-Layer Address extension and the IPv6 source with a Target Link-Layer Address extension and the IPv6 source
address not equal to the unspecified address inserts an entry for address not equal to the unspecified address inserts an entry for
the IPv6 address into its Neighbor Cache. Also, a node the IPv6 address into its Neighbor Cache. Also, a node performing
performing Duplicate Address Detection (DAD) that receives a Duplicate Address Detection (DAD) that receives a Neighbor
Neighbor Solicitation for the same address regards the situation Solicitation for the same address regards the situation as a
as a collision and ceases to solicit for the address. collision and ceases to solicit for the address.
In either case, SEND counters these treats by requiring the In either case, SEND counters these treats by requiring the
Signature and CGA options to be present in such solicitations. Signature and CGA options to be present in such solicitations.
SEND nodes can send Router Solicitation messages with a CGA SEND nodes can send Router Solicitation messages with a CGA
source address and a CGA option, which the router can verify, so source address and a CGA option, which the router can verify, so
the Neighbor Cache binding is correct. If a SEND node must send the Neighbor Cache binding is correct. If a SEND node must send
a Router Solicitation with the unspecified address, the router a Router Solicitation with the unspecified address, the router
will not update its Neighbor Cache, as per RFC 2461. will not update its Neighbor Cache, as per RFC 2461.
skipping to change at page 46, line 29 skipping to change at page 45, line 29
The CGAs have a 59-bit hash value. The security of the CGA mechanism The CGAs have a 59-bit hash value. The security of the CGA mechanism
has been discussed in [13]. has been discussed in [13].
Some Denial-of-Service attacks against NDP and SEND itself remain. Some Denial-of-Service attacks against NDP and SEND itself remain.
For instance, an attacker may try to produce a very high number of For instance, an attacker may try to produce a very high number of
packets that a victim host or router has to verify using asymmetric packets that a victim host or router has to verify using asymmetric
methods. While safeguards are required to prevent an excessive use methods. While safeguards are required to prevent an excessive use
of resources, this can still render SEND non-operational. of resources, this can still render SEND non-operational.
When CGA protection is used, SEND deals with the DoS attacks using When CGA protection is used, SEND deals with the DoS attacks using
the verification process described in Section 5.2.2. In this the verification process described in Section 5.2.2. In this process,
process, a simple hash verification of the CGA property of the a simple hash verification of the CGA property of the address is
address is performed before performing the more expensive signature performed before performing the more expensive signature
verification. However, even if the CGA verification succeeds, no verification. However, even if the CGA verification succeeds, no
claims about the validity of the message can be made, until the claims about the validity of the message can be made, until the
signature has been checked. signature has been checked.
When trust anchors and certificates are used for address validation When trust anchors and certificates are used for address validation
in SEND, the defenses are not quite as effective. Implementations in SEND, the defenses are not quite as effective. Implementations
SHOULD track the resources devoted to the processing of packets SHOULD track the resources devoted to the processing of packets
received with the Signature option, and start selectively discarding received with the Signature option, and start selectively discarding
packets if too many resources are spent. Implementations MAY also packets if too many resources are spent. Implementations MAY also
first discard packets that are not protected with CGA. first discard packets that are not protected with CGA.
skipping to change at page 55, line 8 skipping to change at page 54, line 8
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Pekka.Nikander@nomadiclab.com EMail: Pekka.Nikander@nomadiclab.com
Appendix A. Contributors Appendix A. Contributors
Tuomas Aura contributed the transition mechanism specification in Tuomas Aura contributed the transition mechanism specification in
Section 8. Jonathan Trostle contributed the certificate chain Section 8. Jonathan Trostle contributed the certificate chain example
example in Section 6.1.1. in Section 6.1.1.
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel
Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier,
Francis Dupont, and Pekka Savola for interesting discussions in this Francis Dupont, and Pekka Savola for interesting discussions in this
problem space and feedback regarding the SEND protocol. problem space and feedback regarding the SEND protocol.
Appendix C. Cache Management Appendix C. Cache Management
skipping to change at page 59, line 12 skipping to change at page 58, line 12
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/