base.txt   issue75.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: January 6, 2005 DoCoMo Communications Labs USA Expires: January 8, 2005 DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
P. Nikander P. Nikander
Ericsson Ericsson
July 8, 2004 July 10, 2004
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-pre06 draft-ietf-send-ndopt-pre06
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 6, 2005. This Internet-Draft will expire on January 8, 2005.
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 29 skipping to change at page 2, line 29
5.2.1 Processing Rules for Senders . . . . . . . . . . 17 5.2.1 Processing Rules for Senders . . . . . . . . . . 17
5.2.2 Processing Rules for Receivers . . . . . . . . . 18 5.2.2 Processing Rules for Receivers . . . . . . . . . 18
5.2.3 Configuration . . . . . . . . . . . . . . . . . 19 5.2.3 Configuration . . . . . . . . . . . . . . . . . 19
5.2.4 Performance Considerations . . . . . . . . . . . 20 5.2.4 Performance Considerations . . . . . . . . . . . 20
5.3 Timestamp and Nonce options . . . . . . . . . . . . . 20 5.3 Timestamp and Nonce options . . . . . . . . . . . . . 20
5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 20 5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 20
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 21 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 21
5.3.3 Processing rules for senders . . . . . . . . . . 22 5.3.3 Processing rules for senders . . . . . . . . . . 22
5.3.4 Processing rules for receivers . . . . . . . . . 23 5.3.4 Processing rules for receivers . . . . . . . . . 23
6. Authorization Delegation Discovery . . . . . . . . . . . . . 26 6. Authorization Delegation Discovery . . . . . . . . . . . . . 26
6.1 Certificate Format . . . . . . . . . . . . . . . . . . 26 6.1 Authorization Model . . . . . . . . . . . . . . . . . 26
6.1.1 Router Authorization Certificate Profile . . . . 26 6.2 Deployment Model . . . . . . . . . . . . . . . . . . . 27
6.2 Certificate Transport . . . . . . . . . . . . . . . . 29 6.3 Certificate Format . . . . . . . . . . . . . . . . . . 28
6.2.1 Certification Path Solicitation Message Format . 29 6.3.1 Router Authorization Certificate Profile . . . . 28
6.2.2 Certification Path Advertisement Message Format 31 6.3.2 Suitability of Standard Identity Certificates . 30
6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 34 6.4 Certificate Transport . . . . . . . . . . . . . . . . 31
6.2.4 Certificate Option . . . . . . . . . . . . . . . 35 6.4.1 Certification Path Solicitation Message Format . 31
6.2.5 Processing Rules for Routers . . . . . . . . . . 36 6.4.2 Certification Path Advertisement Message Format 33
6.2.6 Processing Rules for Hosts . . . . . . . . . . . 37 6.4.3 Trust Anchor Option . . . . . . . . . . . . . . 35
6.3 Configuration . . . . . . . . . . . . . . . . . . . . 39 6.4.4 Certificate Option . . . . . . . . . . . . . . . 37
6.4 Deployment Model . . . . . . . . . . . . . . . . . . . 39 6.4.5 Processing Rules for Routers . . . . . . . . . . 38
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.4.6 Processing Rules for Hosts . . . . . . . . . . . 39
7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.5 Configuration . . . . . . . . . . . . . . . . . . . . 40
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 41 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 41 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 42 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 42
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 44 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . 46 7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 43
9.1 Threats to the Local Link Not Covered by SEND . . . . 46 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 45
9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . 47
9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 47 9.1 Threats to the Local Link Not Covered by SEND . . . . 47
9.2.2 Neighbor Unreachability Detection Failure . . . 47 9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 47
9.2.3 Duplicate Address Detection DoS Attack . . . . . 47 9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 48
9.2.4 Router Solicitation and Advertisement Attacks . 48 9.2.2 Neighbor Unreachability Detection Failure . . . 48
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 48 9.2.3 Duplicate Address Detection DoS Attack . . . . . 48
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 49 9.2.4 Router Solicitation and Advertisement Attacks . 49
9.3 Attacks against SEND Itself . . . . . . . . . . . . . 49 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 49
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 51 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 50
10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 51 9.3 Attacks against SEND Itself . . . . . . . . . . . . . 50
10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 51 10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 52
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 52 10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 52
Normative References . . . . . . . . . . . . . . . . . . . . 53 10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . . 55 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 Normative References . . . . . . . . . . . . . . . . . . . . 54
A. Contributors and Acknowledgments . . . . . . . . . . . . . . 57 Informative References . . . . . . . . . . . . . . . . . . . 56
B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56
C. Message Size When Carrying Certificates . . . . . . . . . . 59 A. Contributors and Acknowledgments . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . 60 B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 59
C. Message Size When Carrying Certificates . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . 61
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 37 skipping to change at page 4, line 37
Section 4 describes the overall approach to securing NDP. This Section 4 describes the overall approach to securing NDP. This
approach involves the use of new NDP options to carry public-key approach involves the use of new NDP options to carry public-key
based signatures. A zero-configuration mechanism is used for showing based signatures. A zero-configuration mechanism is used for showing
address ownership on individual nodes; routers are certified by a address ownership on individual nodes; routers are certified by a
trust anchor [10]. The formats, procedures, and cryptographic trust anchor [10]. The formats, procedures, and cryptographic
mechanisms for the zero-configuration mechanism are described in a mechanisms for the zero-configuration mechanism are described in a
related specification [14]. related specification [14].
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 certification paths to describes the mechanism for distributing certification paths to
establish an authorization delegation chain to a common trust anchor. establish an authorization delegation chain to a 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).
Out of scope for this document is the use of identity certificates Out of scope for this document is the use of identity certificates
provisioned on end hosts for authorizing address use, and security of provisioned on end hosts for authorizing address use, and security of
NDP when the entity defending an address is not the same as the NDP when the entity defending an address is not the same as the
entity claiming that adddress (also known as "proxy ND"). These are entity claiming that adddress (also known as "proxy ND"). These are
extensions of SEND that may be treated in separate documents should extensions of SEND that may be treated in separate documents should
skipping to change at page 7, line 34 skipping to change at page 7, line 34
Nonce Nonce
An unpredictable random or pseudorandom number generated by a node An unpredictable random or pseudorandom number generated by a node
and used exactly once. In SEND, nonces are used to assure that a and used exactly once. In SEND, nonces are used to assure that a
particular advertisement is linked to the solicitation that particular advertisement is linked to the solicitation that
triggered it. triggered it.
Router Authorization Certificate Router Authorization Certificate
An X.509v3 [10] public key certificate using the profile specified An X.509v3 [10] public key certificate using the profile specified
in Section 6.1.1. in Section 6.3.1.
SEND node SEND node
An IPv6 node that implements this specification. An IPv6 node that implements this specification.
Router Discovery (RD) Router Discovery (RD)
Router Discovery allows the hosts to discover what routers exist Router Discovery allows the hosts to discover what routers exist
on the link, and what prefixes are available. Router Discovery is on the link, and what prefixes are available. Router Discovery is
a part of the Neighbor Discovery Protocol. a part of the Neighbor Discovery Protocol.
Trust Anchor
Hosts are configured with a set of trust anchors for the purposes
of protecting Router Discovery. A trust anchor is an entity that
the host trusts to authorize routers to act as routers.
3. Neighbor and Router Discovery Overview 3. Neighbor and Router Discovery Overview
The Neighbor Discovery Protocol has several functions. Many of these The Neighbor Discovery Protocol has several functions. Many of these
functions are overloaded on a few central message types, such as the functions are overloaded on a few central message types, such as the
ICMPv6 Neighbor Advertisement message. In this section we review ICMPv6 Neighbor Advertisement message. In this section we review
some of these tasks and their effects in order to understand better some of these tasks and their effects in order to understand better
how the messages should be treated. This section is not normative, how the messages should be treated. This section is not normative,
and if this section and the original Neighbor Discovery RFCs are in and if this section and the original Neighbor Discovery RFCs are in
conflict, the original RFCs take precedence. conflict, the original RFCs take precedence.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
Discovery options is introduced. They are used to protect NDP Discovery options is introduced. They are used to protect NDP
messages. This specification introduces these options, an messages. This specification introduces these options, an
authorization delegation discovery process, an address ownership authorization delegation discovery process, an address ownership
proof mechanism, and requirements for the use of these components in proof mechanism, and requirements for the use of these components in
NDP. NDP.
The components of the solution specified in this document are as The components of the solution specified in this document are as
follows: follows:
o Certification paths, anchored on trusted parties, are expected to o Certification paths, anchored on trusted parties, are expected to
certify the authority of routers. A host and a router must have certify the authority of routers. A host must be configured with
at least one common trust anchor before the host can adopt the a trust anchor to which the router has a certification path before
router as its default router. Certification Path Solicitation and the host can adopt the router as its default router.
Advertisement messages are used to discover a certification path Certification Path Solicitation and Advertisement messages are
to the trust anchor without requiring the actual Router Discovery used to discover a certification path to the trust anchor without
messages to carry lengthy certification paths. The receipt of a requiring the actual Router Discovery messages to carry lengthy
protected Router Advertisement message for which no certification certification paths. The receipt of a protected Router
path is available triggers the authorization delegation discovery Advertisement message for which no certification path is available
process. triggers the authorization delegation discovery process.
o Cryptographically Generated Addresses are used to assure that the o Cryptographically Generated Addresses are used to assure that the
sender of a Neighbor Discovery message is the "owner" of the sender of a Neighbor Discovery message is the "owner" of the
claimed address. A public-private key pair is generated by all claimed address. A public-private key pair is generated by all
nodes before they can claim an address. A new NDP option, the CGA nodes before they can claim an address. A new NDP option, the CGA
option, is used to carry the public key and associated parameters. option, is used to carry the public key and associated parameters.
This specification also allows a node to use non-CGAs with This specification also allows a node to use non-CGAs with
certificates to authorize their use. However, the details of such certificates to authorize their use. However, the details of such
use are beyond the scope of this specification and are left for use are beyond the scope of this specification and are left for
skipping to change at page 15, line 29 skipping to change at page 15, line 29
All nodes that support the sending of the CGA option MUST record the All nodes that support the sending of the CGA option MUST record the
following configuration information: following configuration information:
CGA parameters CGA parameters
Any information required to construct CGAs, as described in [14]. Any information required to construct CGAs, as described in [14].
5.2 RSA Signature Option 5.2 RSA Signature Option
The RSA Signature option allows public-key based signatures to be The RSA Signature option allows public-key based signatures to be
attached to NDP messages. Configured trust anchors, CGAs, or both are attached to NDP messages. The format of the RSA Signature option is
supported as the trusted root. The format of the RSA Signature described in the following diagram:
option is 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 | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key Hash | | Key Hash |
| | | |
| | | |
skipping to change at page 18, line 48 skipping to change at page 18, line 48
either one learned from a preceding CGA option in the same either one learned from a preceding CGA option in the same
message, or one known by other means. message, or one known by other means.
o The Digital Signature field MUST have correct encoding, and not o The Digital Signature field MUST have correct encoding, and not
exceed the length of the RSA Signature option minus the Padding. exceed the length of the RSA Signature option minus the Padding.
o The Digital Signature verification MUST show that the signature o The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section. has been calculated as specified in the previous section.
o If the use of a trust anchor has been configured, a valid o If the use of a trust anchor has been configured, a valid
certification path (see Section 6.1) MUST be known between the certification path (see Section 6.3) MUST be known between the
receiver's trust anchor and the sender's public key. receiver's trust anchor and the sender's public key.
Note that the receiver may verify just the CGA property of a Note that the receiver may verify just the CGA property of a
packet, even if, in addition to CGA, the sender has used a trust packet, even if, in addition to CGA, the sender has used a trust
anchor. anchor.
Messages that do not pass all the above tests MUST be silently Messages that do not pass all the above tests MUST be silently
discarded if the host has been configured to only accept secure ND discarded if the host has been configured to only accept secure ND
messages. The messages MAY be accepted it the host has been messages. The messages MAY be accepted it the host has been
configured to accept both secure and insecure messages, but MUST be configured to accept both secure and insecure messages, but MUST be
skipping to change at page 19, line 30 skipping to change at page 19, line 30
separate NDP message type: separate NDP message type:
authorization method authorization method
This parameter determines the method through which the authority This parameter determines the method through which the authority
of the sender is determined. It can have four values: of the sender is determined. It can have four values:
trust anchor trust anchor
The authority of the sender is verified as described in Section The authority of the sender is verified as described in Section
6.1. The sender may claim additional authorization through the 6.3. The sender may claim additional authorization through the
use of CGAs, but that is neither required nor verified. use of CGAs, but that is neither required nor verified.
CGA CGA
The CGA property of the sender's address is verified as The CGA property of the sender's address is verified as
described in [14]. The sender may claim additional authority described in [14]. The sender may claim additional authority
through a trust anchor, but that is neither required nor through a trust anchor, but that is neither required nor
verified. verified.
trust anchor and CGA trust anchor and CGA
Both the trust anchor and the CGA verification is required. Both the trust anchor and the CGA verification is required.
trust anchor or CGA trust anchor or CGA
Either the trust anchor or the CGA verification is required. Either the trust anchor or the CGA verification is required.
anchor anchor
The public keys and names of the allowed trust anchor(s), if the The allowed trust anchor(s), if the authorization method is not
authorization method is not set to CGA. set to CGA.
All nodes that support the sending of RSA Signature options MUST All nodes that support the sending of RSA Signature options MUST
record the following configuration information: record 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 certification path from a trust anchor to this there must exist a certification path from a trust anchor to this
key pair. key pair.
skipping to change at page 26, line 27 skipping to change at page 26, line 27
someone else's search results and conclude that a particular message someone else's search results and conclude that a particular message
comes from an authorized source. In the typical case, a router comes from an authorized source. In the typical case, a router
already connected beyond the link, can (if necessary) communicate already connected beyond the link, can (if necessary) communicate
with off-link nodes and construct such a certification path. with off-link nodes and construct such a certification path.
The Secure Neighbor Discovery Protocol mandates a certificate format The Secure Neighbor Discovery Protocol mandates a certificate format
and introduces two new ICMPv6 messages that are used between hosts and introduces two new ICMPv6 messages that are used between hosts
and routers to allow the host to learn a certification path with the and routers to allow the host to learn a certification path with the
assistance of the router. assistance of the router.
6.1 Certificate Format 6.1 Authorization Model
To protect Router Discovery, SEND requires routers to be authorized
to act as routers. This authorization is provisioned in both routers
and hosts: routers are given certificates from a trust anchor and the
hosts are configured with the trust anchor(s) that they trust to
authorize routers. This provisioning is specific to SEND, and does
not assume that certificates already deployed for some other purpose
can be used.
The authorization for routers in SEND is twofold:
o Routers are authorized to act as routers. The router belongs to
the set of routers trusted by the trust anchor. All routers in
this set have the same authorization.
o Optionally, routers may also be authorized to advertise a certain
set of prefixes. A specific router is given a specific set of
prefixes to advertise; other routers have an authorization to
advertise other prefixes. Trust anchors may also delegate a
certain set of prefixes to someone (such as an ISP), who in turn
delegates parts of this set to individual routers.
Note that while communicating with hosts, routers typically present
also a number of other parameters beyond the above. For instance,
routers have their own IP addresses, prefixes have lifetimes, routers
control the use of stateless and stateful address autoconfiguration,
and so on. However, the ability to be a router and the prefixes are
the most fundamental parameters to authorize. This is because the
host needs to choose a router that it uses as its defaulr router, and
because the advertised prefixes have an impact on the addresses the
host uses. In addition, the prefixes also represent a claim about the
topological location in the network.
Care should be taken if the certificates used in SEND are re-used to
provide authorization in other circumstances, for example with
routing protocols. It is necessary to ensure that the authorization
information is appropriate for all applications. SEND certificates
may authorize a larger set of prefixes than the router is really
authorized to advertise on a given interface. For instance, SEND
allows the use of the null prefix. This prefix might cause
verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND.
Note that end hosts need not be provisioned with their own certified
public keys, just as Web clients today do not require end host
provisioning with certified keys. Public keys for CGA generation do
not need to be certified, since such keys derive their ability to
authorize operations on the CGA by the tie to the address.
6.2 Deployment Model
The deployment model for trust anchors can be either a globally
rooted public key infrastructure, or a more local, decentralized
deployment model similar to the current model used for TLS in Web
servers. The centralized model assumes a global root capable of
authorizing routers and, optionally, the address space they
advertise. The end hosts are configured with the public keys of the
global root. The global root could operate, for instance, under the
Internet Assigned Numbers Authority (IANA) or as a co-operation among
Regional Internet Registries (RIRs). However, no such global root
currently exists or is even being planned.
In the decentralized model, end hosts are configured with a
collection of trusted public keys that form the trust anchors. The
public keys could be issued from a variety of places, for example: a)
a public key for the end host's own organization, b) a public key for
the end host's home ISP and for ISPs with which the home ISP has a
roaming agreement, or c) public keys for roaming brokers that act as
intermediaries for ISPs that don't want to run their own
certification authority.
This decentralized model works even when a SEND node is used both in
networks that have certified routers and in networks that do not. As
discussed in Section 8, a SEND node can fallback to the use of a
non-SEND router. This makes it possible to start with a local trust
anchor even if there is no trust anchor for all possible networks.
6.3 Certificate Format
The certification path of a router terminates in a Router The certification path of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization paths are not a common practice as a router. Because authorization paths are not a common practice
in the Internet at the time this specification was written, the path in the Internet at the time this specification was written, the path
MUST consist of standard Public Key Certificates (PKC, in the sense MUST consist of standard Public Key Certificates (PKC, in the sense
of [11]). The certification path MUST start from the identity of a of [11]). The certification path MUST start from the identity of a
trust anchor that is shared by the host and the router. This allows trust anchor that is shared by the host and the router. This allows
the host to anchor trust for the router's public key in the trust the host to anchor trust for the router's public key in the trust
anchor. Note that there MAY be multiple certificates issued by a anchor. Note that there MAY be multiple certificates issued by a
single trust anchor. single trust anchor.
6.1.1 Router Authorization Certificate Profile 6.3.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 SHOULD contain at least one instance of
the X.509 extension for IP addresses, as defined in [13]. The parent the X.509 extension for IP addresses, as defined in [13]. The parent
certificates in the certification path MUST contain one or more X.509 certificates in the certification path SHOULD contain one or more
IP address extensions, back up to a trusted party (such as the user's X.509 IP address extensions, back up to a trusted party (such as the
ISP) that configured the original IP address space block for the user's ISP) that configured the original IP address space block for
router in question, or delegated the right to do so. The certificates the router in question, or delegated the right to do so. The
for the intermediate delegating authorities MUST contain X.509 IP certificates for the intermediate delegating authorities SHOULD
address extension(s) for subdelegations. The router's certificate is contain X.509 IP address extension(s) for subdelegations. The
signed by the delegating authority for the prefixes the router is router's certificate is signed by the delegating authority for the
authorized to advertise. prefixes the router is authorized 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 addressPrefix addressesOrRanges element. This element MUST contain an addressPrefix
element containing an IPv6 address prefix for a prefix the router or element containing an IPv6 address prefix for a prefix the router or
the intermediate entity is authorized to route. If the entity is the intermediate entity is authorized to route. If the entity is
allowed to route any prefix, the used IPv6 address prefix is the null allowed to route any prefix, the used IPv6 address prefix is the null
prefix, ::/0. The addressFamily element of the containing prefix, ::/0. The addressFamily element of the containing
IPAddrBlocks sequence element MUST contain the IPv6 Address Family IPAddrBlocks sequence element MUST contain the IPv6 Address Family
Identifier (0002), as specified in [13] for IPv6 prefixes. Instead Identifier (0002), as specified in [13] for IPv6 prefixes. Instead
of an addressPrefix element, the addressesOrRange element MAY contain of an addressPrefix element, the addressesOrRange element MAY contain
an addressRange element for a range of prefixes, if more than one an addressRange element for a range of prefixes, if more than one
prefix is authorized. The X.509 IP address extension MAY contain prefix is authorized. The X.509 IP address extension MAY contain
additional IPv6 prefixes, expressed either as an addressPrefix or an additional IPv6 prefixes, expressed either as an addressPrefix or an
addressRange. addressRange.
A node receiving a Router Authorization Certificate MUST first check A node receiving a Router Authorization Certificate MUST first check
whether the certificate's signature was generated by the delegating whether the certificate's signature was generated by the delegating
authority. Then the client MUST check whether all the addressPrefix authority. Then the client SHOULD check whether all the
or addressRange entries in the router's certificate are contained addressPrefix or addressRange entries in the router's certificate are
within the address ranges in the delegating authority's certificate, contained within the address ranges in the delegating authority's
and whether the addressPrefix entries match any addressPrefix entries certificate, and whether the addressPrefix entries match any
in the delegating authority's certificate. If an addressPrefix or addressPrefix entries in the delegating authority's certificate. If
addressRange is not contained within the delegating authority's an addressPrefix or addressRange is not contained within the
prefixes or ranges, the client MAY attempt to take an intersection of delegating authority's prefixes or ranges, the client MAY attempt to
the ranges/prefixes, and use that intersection. If the addressPrefix take an intersection of the ranges/prefixes, and use that
in the certificate is the null prefix, ::/0, such an intersection intersection. If the resulting intersection is empty, the client MUST
SHOULD be used. (In that case the intersection is the parent prefix NOT accept the certificate. If the addressPrefix in the certificate
or range.) If the resulting intersection is empty, the client MUST is missing or is the null prefix, ::/0, the parent prefix or range
NOT accept the certificate. SHOULD be used. If there is no parent prefix or range, the prefixes
that the router advertises are said to be unconstrained (see Section
7.3). That is, the router is allowed to advertise any prefix.
The above check SHOULD be done for all certificates in the path. If The above check SHOULD be done for all certificates in the path. If
any of the checks fail, the client MUST NOT accept the certificate. any of the checks fail, the client MUST NOT accept the certificate.
The client also needs to perform validation of advertised prefixes as The client also needs to perform validation of advertised prefixes as
discussed in Section 7.3. discussed in Section 7.3.
Hosts MUST check the subjectPublicKeyInfo field within the last Hosts MUST check the subjectPublicKeyInfo field within the last
certificate in the certificate path to ensure that only RSA public certificate in the certificate path to ensure that only RSA public
keys are used to attempt validation of router signatures, and MUST keys are used to attempt validation of router signatures, and MUST
disregard the certificate for SEND if it does not contain an RSA key. disregard the certificate for SEND if it does not contain an RSA key.
Care should be taken if the certificates used in SEND are re-used to
provide authorization in other circumstances, for example with
routing protocols. It is necessary to ensure that the authorization
information is appropriate for all applications. SEND certificates
may authorize a larger set of prefixes than the router is really
authorized to advertise on a given interface. For instance, SEND
allows the use of the null prefix. This prefix might cause
verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND.
Since it is possible that some public key certificates used with SEND Since it is possible that some public key certificates used with SEND
do not immediately contain the X.509 IP address extension element, an do not immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default be off by default. That is, the system SHOULD have a default
configuration that requires rigorous prefix and range checks. configuration that requires rigorous prefix and range checks.
The following is an example of a certification path. Suppose that The following is an example of a certification path. Suppose that
isp_group_example.net is the trust anchor. The host has this isp_group_example.net is the trust anchor. The host has this
certificate: certificate:
skipping to change at page 29, line 25 skipping to change at page 30, line 47
fail, the node SHOULD immediately stop using the router as a default fail, the node SHOULD immediately stop using the router as 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 certification path is valid, then router_foo.isp_foo_example.com the certification path 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.3.2 Suitability of Standard Identity Certificates
Since deployment of the IP address extension is, itself, not common,
a network service provider MAY choose to deploy standard identity
certificates on the router to supply the router's public key for
signed Router Advertisements.
If there is no prefix information further up in the certification
chain, a host interprets a standard identity certificate as allowing
unconstrained prefix advertisements.
If the other certificates do contain prefix information, a standard
identity certificate is interpreted as allowing those prefixes.
6.4 Certificate Transport
The Certification Path Solicitation (CPS) message is sent by a host The Certification Path Solicitation (CPS) message is sent by a host
when it wishes to request a certification path between a router and when it wishes to request a certification path between a router and
one of the host's trust anchors. The Certification Path one of the host's trust anchors. The Certification Path
Advertisement (CPA) message is sent in reply to the CPS message. Advertisement (CPA) message is sent in reply to the CPS message.
These messages are separate from the rest of Neighbor and Router These messages are separate from the rest of Neighbor and Router
Discovery, in order to reduce the effect of the potentially Discovery, in order to reduce the effect of the potentially
voluminous certification path information on other messages. voluminous certification path information on other messages.
The Authorization Delegation Discovery (ADD) process does not exclude The Authorization Delegation Discovery (ADD) process does not exclude
skipping to change at page 29, line 47 skipping to change at page 31, line 35
fast movements mobile nodes may learn information - including the fast movements mobile nodes may learn information - including the
certification paths - of the next router from a previous router, or certification paths - of the next router from a previous router, or
nodes may be preconfigured with certification paths from roaming nodes may be preconfigured with certification paths from roaming
partners. partners.
Where hosts themselves are certified by a trust anchor, these Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the messages MAY also optionally be used between hosts to acquire the
peer's certification path. However, the details of such usage are peer's certification path. However, the details of such usage are
beyond the scope of this specification. beyond the scope of this specification.
6.2.1 Certification Path Solicitation Message Format 6.4.1 Certification Path Solicitation Message Format
Hosts send Certification Path Solicitations in order to prompt Hosts send Certification Path Solicitations in order to prompt
routers to generate Certification Path Advertisements. routers to generate Certification Path Advertisements.
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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component | | Identifier | Component |
skipping to change at page 31, line 12 skipping to change at page 32, line 50
generated. This randomness does not need to be generated. This randomness does not need to be
cryptographically hard, since its purpose is only to avoid cryptographically hard, since its purpose is only to avoid
collisions. collisions.
Component Component
This 16-bit unsigned integer field is set to 65,535 if the This 16-bit unsigned integer field is set to 65,535 if the
sender desires to retrieve all certificates. Otherwise, it is sender desires to retrieve all certificates. Otherwise, it is
set to the component identifier corresponding to the set to the component identifier corresponding to the
certificate that the receiver wants to retrieve (see Section certificate that the receiver wants to retrieve (see Section
6.2.2 and Section 6.2.6). 6.4.2 and Section 6.4.6).
Valid Options: Valid Options:
Trust Anchor Trust Anchor
One or more trust anchors that the client is willing to accept. One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.2.3. If there is more than Encoded X.501 Name; see Section 6.4.3. If there is more than
one Trust Anchor option, the options past the first one may one Trust Anchor option, the options past the first one may
contain any type of trust anchor. contain any type of trust anchor.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST and continue processing the message. All included options MUST
have a length that is greater than zero. have a length that is greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets. ICMP length (derived from the IP length) MUST be 8 or more octets.
6.2.2 Certification Path Advertisement Message Format 6.4.2 Certification Path Advertisement Message Format
Routers send out Certification Path Advertisement messages in Routers send out Certification Path Advertisement messages in
response to a Certification Path Solicitation. response to a Certification Path Solicitation.
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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | All Components | | Identifier | All Components |
skipping to change at page 34, line 11 skipping to change at page 35, line 43
present, these options MUST appear in the first component of a present, these options MUST appear in the first component of a
multi-component advertisement. multi-component advertisement.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST and continue processing the message. All included options MUST
have a length that is greater than zero. have a length that is greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets. ICMP length (derived from the IP length) MUST be 8 or more octets.
6.2.3 Trust Anchor Option 6.4.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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 27 skipping to change at page 37, line 15
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 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 previous field ends, and continuing to the end beginning after the previous field ends, and continuing to the end
of the option, as specified by the Length field. of the option, as specified by the Length field.
6.2.4 Certificate Option 6.4.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 | Reserved | | Type | Length | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ... | Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 21 skipping to change at page 38, line 8
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.
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.3.1.
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 [10, 15] beginning after the ASN.1 encoding of the previous field [10, 15]
ends, and continuing to the end of the option, as specified by the ends, and continuing to the end of the option, as specified by the
Length field. Length field.
6.2.5 Processing Rules for Routers 6.4.5 Processing Rules for Routers
A router MUST silently discard any received Certification Path A router MUST silently discard any received Certification Path
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.4.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
of the Reserved field or add new options; backward-incompatible of the Reserved field or add new options; backward-incompatible
changes may use different Code values. The contents of any defined changes may use different Code values. The contents of any defined
options that are not specified to be used with Router Solicitation options that are not specified to be used with Router Solicitation
messages MUST be ignored and the packet processed in the normal messages MUST be ignored and the packet processed in the normal
manner. The only defined option that may appear is the Trust Anchor manner. The only defined option that may appear is the Trust Anchor
option. A solicitation that passes the validity checks is called a option. A solicitation that passes the validity checks is called a
"valid solicitation". "valid solicitation".
skipping to change at page 37, line 15 skipping to change at page 38, line 50
MAX_CPA_RATE times within a second. When there are more MAX_CPA_RATE times within a second. When there are more
solicitations, the router SHOULD send the response to the All-Nodes solicitations, the router SHOULD send the response to the All-Nodes
multicast address regardless of the source address that appeared in multicast address regardless of the source address that appeared in
the solicitation. the solicitation.
In an advertisement, the router SHOULD include suitable Certificate In an advertisement, the router SHOULD include suitable Certificate
options so that a certification path to the solicited trust anchor options so that a certification path to the solicited trust anchor
can be established (or a part of it, if the Component field in the can be established (or a part of it, if the Component field in the
solicitation is not equal to 65,535). Note also that a single solicitation is not equal to 65,535). Note also that a single
advertisement is broken into separately sent components and ordered advertisement is broken into separately sent components and ordered
in a particular way (see Section 6.2.2) when there is more than one in a particular way (see Section 6.4.2) when there is more than one
Certificate option. Certificate option.
The anchor is identified by the Trust Anchor option. If the Trust The anchor is identified by the Trust Anchor option. If the Trust
Anchor option is represented as a DER Encoded X.501 Name, then the Anchor option is represented as a DER Encoded X.501 Name, then the
Name must be equal to the Subject field in the anchor's certificate. Name must be equal to the Subject field in the anchor's certificate.
If the Trust Anchor option is represented as an FQDN, the FQDN must If the Trust Anchor option is represented as an FQDN, the FQDN must
be equal to an FQDN in the subjectAltName field of the anchor's be equal to an FQDN in the subjectAltName field of the anchor's
certificate. The router SHOULD include the Trust Anchor option(s) in certificate. The router SHOULD include the Trust Anchor option(s) in
the advertisement for which the certification path was found. the advertisement for which the certification path was found.
If the router is unable to find a path to the requested anchor, it If the router is unable to find a path to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case SHOULD send an advertisement without any certificates. In this case
the router SHOULD include the Trust Anchor options which were the router SHOULD include the Trust Anchor options which were
solicited. solicited.
6.2.6 Processing Rules for Hosts 6.4.6 Processing Rules for Hosts
A host MUST silently discard any received Certification Path A host MUST silently discard any received Certification Path
Advertisement messages that do not conform to the message format Advertisement messages that do not conform to the message format
defined in Section 6.2.2. The contents of the Reserved field, and of defined in Section 6.4.2. 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
of the Reserved field or add new options; backward-incompatible of the Reserved field or add new options; backward-incompatible
changes MUST use different Code values. The contents of any defined changes MUST use different Code values. The contents of any defined
options that are not specified to be used with Certification Path options that are not specified to be used with Certification Path
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 certification paths retrieved in Certification Hosts SHOULD store certification paths retrieved in Certification
Path Discovery messages if they start from an anchor trusted by the Path Discovery messages if they start from an anchor trusted by the
host. The certification paths MUST be verified, as defined in Section host. The certification paths MUST be verified, as defined in Section
6.1, before storing them. Routers send the certificates one by one, 6.3, before storing them. Routers send the certificates one by one,
starting from the trust anchor end of the path. starting from the trust anchor end of the path.
Note: except for temporary purposes to allow for message loss and Note: except for temporary purposes to allow for message loss and
reordering, hosts might not store certificates received in a reordering, hosts might not store certificates received in a
Certification Path Advertisement unless they contain a certificate Certification Path Advertisement unless they contain a certificate
which can be immediately verified either to the trust anchor or to a which can be immediately verified either to the trust anchor or to a
certificate that has been verified earlier. This measure is to certificate that has been verified earlier. This measure is to
prevent Denial-of-Service attacks, whereby an attacker floods a host prevent Denial-of-Service attacks, whereby an attacker floods a host
with certificates that the host cannot validate and overwhelms memory with certificates that the host cannot validate and overwhelms memory
for certificate storage. for certificate storage.
skipping to change at page 39, line 4 skipping to change at page 40, line 39
address of the receiver. The advertisements SHOULD be sent as address of the receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are outside specified above for routers. However, the exact details are outside
the scope of this specification. the scope of this specification.
When processing possible advertisements sent as responses to a When processing possible advertisements sent as responses to a
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).
6.3 Configuration 6.5 Configuration
End hosts are configured with a set of trust anchors for the purposes End hosts are configured with a set of trust anchors for the purposes
of protecting Router Discovery. A trust anchor configuration consists of protecting Router Discovery. A trust anchor configuration consists
of the following items: of the following items:
o A public key signature algorithm and associated public key, which o A public key signature algorithm and associated public key, which
may optionally include parameters. may optionally include parameters.
o A name as described in Section 6.2.3. o A name as described in Section 6.4.3.
o An optional public key identifier. o An optional public key identifier.
o An optional list of address ranges the trust anchor is authorized o An optional list of address ranges the trust anchor is authorized
for. for.
If the host has been configured to use SEND, it SHOULD possess the If the host has been configured to use SEND, it SHOULD possess the
above information for at least one trust anchor. above information for at least one trust anchor.
Routers are configured with a collection of certification paths and a Routers are configured with a collection of certification paths and a
collection of certified keys and the certificates containing them, collection of certified keys and the certificates containing them,
down to the key and certificate for the router itself. Certified keys down to the key and certificate for the router itself. Certified keys
are required for routers in order that a certification path can be are required for routers in order that a certification path can be
established between the router's certificate and the public key of a established between the router's certificate and the public key of a
trust anchor. trust anchor.
If the router has been configured to use SEND, it should be If the router has been configured to use SEND, it should be
configured with its own key pair and certificate, and at least one configured with its own key pair and certificate, and at least one
certification path. certification path.
6.4 Deployment Model
The deployment model for trust anchors can be either a globally
rooted public key infrastructure, or a more local, decentralized
deployment model similar to the current model used for TLS in Web
servers. The centralized model assumes a global root capable of
authorizing routers and, optionally, the address space they
advertise. The end hosts are configured with the public keys of the
global root. The global root could operate, for instance, under the
Internet Assigned Numbers Authority (IANA) or as a co-operation among
Regional Internet Registries (RIRs). However, no such global root
currently exists or is even being planned.
In the decentralized model, end hosts are configured with a
collection of trusted public keys that form the trusted roots. The
public keys could be issued from a variety of places, for example: a)
a public key for the end host's own organization, b) a public key for
the end host's home ISP and for ISPs with which the home ISP has a
roaming agreement, or c) public keys for roaming brokers that act as
intermediaries for ISPs that don't want to run their own
certification authority.
This decentralized model works even when a SEND node is used both in
networks that have certified routers and in networks that do not. As
discussed in Section 8, a SEND node can fallback to the use of a
non-SEND router. This makes it possible to start with a local trust
anchor even if there is no trust anchor for all possible networks.
Note that end hosts need not be provisioned with their own certified
public keys, just as Web clients today do not require end host
provisioning with certified keys. Public keys for CGA generation do
not need to be certified, since such keys derive their ability to
authorize operations on the CGA by the tie to the address.
7. Addressing 7. Addressing
7.1 CGAs 7.1 CGAs
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 [24]. API, such as the one defined in [24].
skipping to change at page 52, line 11 skipping to change at page 53, line 11
TIMESTAMP_FUZZ 1 second TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01) TIMESTAMP_DRIFT 1 % (0.01)
11. IANA Considerations 11. IANA Considerations
This document defines two new ICMP message types, used in This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range: ICMPv6 type numbers from the informational message range:
o The Certification Path Solicitation message, described in Section o The Certification Path Solicitation message, described in Section
6.2.1. 6.4.1.
o The Certification Path Advertisement message, described in Section o The Certification Path Advertisement message, described in Section
6.2.2. 6.4.2.
This document defines six new Neighbor Discovery Protocol [7] This document defines six new Neighbor Discovery Protocol [7]
options, which must be assigned Option Type values within the option options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages: numbering space for Neighbor Discovery Protocol messages:
o The CGA option, described in Section 5.1. o The CGA option, described in Section 5.1.
o The RSA Signature option, described in Section 5.2. o The RSA Signature option, described in Section 5.2.
o The Timestamp option, described in Section 5.3.1. o The Timestamp option, described in Section 5.3.1.
o The Nonce option, described in Section 5.3.2. o The Nonce option, described in Section 5.3.2.
o The Trust Anchor option, described in Section 6.2.3. o The Trust Anchor option, described in Section 6.4.3.
o The Certificate option, described in Section 6.2.4. o The Certificate option, described in Section 6.4.4.
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
[14] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. [14] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
This document defines a new name space for the Name Type field in the This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated Trust Anchor option. Future values of this field can be allocated
using Standards Action [6]. The current values for this field are: using Standards Action [6]. The current values for this field are:
1 DER Encoded X.501 Name 1 DER Encoded X.501 Name
skipping to change at page 57, line 8 skipping to change at page 58, line 8
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Pekka.Nikander@nomadiclab.com EMail: Pekka.Nikander@nomadiclab.com
Appendix A. Contributors and Acknowledgments Appendix A. Contributors and Acknowledgments
Tuomas Aura contributed the transition mechanism specification in Tuomas Aura contributed the transition mechanism specification in
Section 8. Jonathan Trostle contributed the certification path Section 8. Jonathan Trostle contributed the certification path
example in Section 6.1.1. example in Section 6.3.1.
The authors would also like to thank Tuomas Aura, Erik Nordmark, The authors would also like to thank Tuomas Aura, Erik Nordmark,
Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien
Laganier, Francis Dupont, Pekka Savola, Valtteri Niemi, Mike Roe, Laganier, Francis Dupont, Pekka Savola, Valtteri Niemi, Mike Roe,
Russ Housley, Thomas Narten, and Steven Bellovin for interesting Russ Housley, Thomas Narten, and Steven Bellovin for interesting
discussions in this problem space and feedback regarding the SEND discussions in this problem space and feedback regarding the SEND
protocol. protocol.
Appendix B. Cache Management Appendix B. Cache Management
skipping to change at page 59, line 6 skipping to change at page 60, line 6
victim into promoting its cache entry to the old cache. Hence, the victim into promoting its cache entry to the old cache. Hence, the
node may be more intelligent in keeping its cache entries, and not node may be more intelligent in keeping its cache entries, and not
just have a black/white old/new boundary. just have a black/white old/new boundary.
It also looks like a good idea to consider the Sec parameter when It also looks like a good idea to consider the Sec parameter when
forcing cache entries out, and let those entries with a larger Sec a forcing cache entries out, and let those entries with a larger Sec a
higher chance of staying in. higher chance of staying in.
Appendix C. Message Size When Carrying Certificates Appendix C. Message Size When Carrying Certificates
TBD. In one example scenario using SEND, an Authorization Delegation
Discovery test run was made using a certification chain length four.
This results in having to send three certificates using the
Certification Chain Advertisement messages as the trust anchor's
certificate is already known by both parties. Using a key length of
XXX bits, the implementation used in the test run used certificates
ranging from 864 to 888 bytes long; the variation is due to the
differences in the certificate issuer names and prefix extensions in
the certificates. The different certificates had one to four prefix
extensions.
The three Certification Chain Advertisement messages ranged from 1050
to 1066 bytes on an Ethernet link layer. The certificate itself
accounts for the bulk of the packet. The rest is the trust anchor
option, ICMP header, IPv6 header, and link layer header.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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