fields) in units of 8 octets.
Nonce
A field containing a random number selected by the sender of the
solicitation message. The length of the random number MUST be at
least 6 bytes. The length of the random number MUST be selected
so that the length of the nonce option is a multiple of 8 octets.
5.3.3. Processing Rules for Senders
If the node has been configured to use SEND, all solicitation
messages MUST include a Nonce. When sending a solicitation, the
sender MUST store the nonce internally so that it can recognize any
replies containing that particular nonce.
If the node has been configured to use SEND, all advertisements sent
in reply to a solicitation MUST include a Nonce, copied from the
received solicitation. Note that routers may decide to send a
multicast advertisement to all nodes instead of a response to a
specific host. In such a case, the router MAY still include the
nonce value for the host that triggered the multicast advertisement.
(Omitting the nonce value may cause the host to ignore the router’s
advertisement, unless the clocks in these nodes are sufficiently
synchronized so that timestamps function properly.)
If the node has been configured to use SEND, all solicitation,
advertisement, and redirect messages MUST include a Timestamp.
Senders SHOULD set the Timestamp field to the current time, according
to their real time clocks.
5.3.4. Processing Rules for Receivers
The processing of the Nonce and Timestamp options depends on whether
a packet is a solicited advertisement. A system may implement the
distinction in various ways. Section 5.3.4.1 defines the processing
rules for solicited advertisements. Section 5.3.4.2 defines the
processing rules for all other messages.
In addition, the following rules apply in all cases:
o Messages received without at least one of the Timestamp and Nonce
options MUST be treated as unsecured (i.e., processed in the same
way as NDP messages sent by a non-SEND node).
o Messages received with the RSA Signature option but without the
Timestamp option MUST be silently discarded.
o Solicitation messages received with the RSA Signature option but
without the Nonce option MUST be silently discarded.
o Advertisements sent to a unicast destination address with the RSA
Signature option but without a Nonce option SHOULD be processed as
unsolicited advertisements.
o An implementation MAY use some mechanism such as a timestamp cache
to strengthen resistance to replay attacks. When there is a very
large number of nodes on the same link, or when a cache filling
attack is in progress, it is possible that the cache holding the
most recent timestamp per sender will become full. In this case,
the node MUST remove some entries from the cache or refuse some
new requested entries. The specific policy as to which entries
are preferred over others is left as an implementation decision.
However, typical policies may prefer existing entries to new ones,
CGAs with a large Sec value to smaller Sec values, and so on. The
issue is briefly discussed in Appendix B.
o The receiver MUST be prepared to receive the Timestamp and Nonce
options in any order, as per RFC 2461 [4], Section 9.
5.3.4.1. Processing Solicited Advertisements
The receiver MUST verify that it has recently sent a matching
solicitation, and that the received advertisement contains a copy of
the Nonce sent in the solicitation.
If the message contains a Nonce option but the Nonce value is not
recognized, the message MUST be silently discarded.
Otherwise, if the message does not contain a Nonce option, it MAY be
considered an unsolicited advertisement and processed according to
Section 5.3.4.2.
If the message is accepted, the receiver SHOULD store the receive
time of the message and the timestamp time in the message, as
specified in Section 5.3.4.2.
5.3.4.2. Processing All Other Messages
Receivers SHOULD be configured with an allowed timestamp Delta value,
a "fuzz factor" for comparisons, and an allowed clock drift
parameter. The recommended default value for the allowed Delta is
TIMESTAMP_DELTA; for fuzz factor TIMESTAMP_FUZZ; and for clock drift,
TIMESTAMP_DRIFT (see Section 10.2).
To facilitate timestamp checking, each node SHOULD store the
following information for each peer:
o The receive time of the last received and accepted SEND message.
This is called RDlast.
o The time stamp in the last received and accepted SEND message.
This is called TSlast.
An accepted SEND message is any successfully verified Neighbor
Solicitation, Neighbor Advertisement, Router Solicitation, Router
Advertisement, or Redirect message from the given peer. The RSA
Signature option MUST be used in such a message before it can update
the above variables.
Receivers SHOULD then check the Timestamp field as follows:
o When a message is received from a new peer (i.e., one that is not
stored in the cache), the received timestamp, TSnew, is checked,
and the packet is accepted if the timestamp is recent enough to
the reception time of the packet, RDnew:
-Delta < (RDnew - TSnew) < +Delta
The RDnew and TSnew values SHOULD be stored in the cache as RDlast
and TSlast.
o If the timestamp is NOT within the boundaries but the message is a
Neighbor Solicitation message that the receiver should answer, the
receiver SHOULD respond to the message. However, even if it does
respond to the message, it MUST NOT create a Neighbor Cache entry.
This allows nodes that have large differences in their clocks to
continue communicating with each other by exchanging NS/NA pairs.
o When a message is received from a known peer (i.e., one that
already has an entry in the cache), the timestamp is checked
against the previously received SEND message:
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
If this inequality does not hold, the receiver SHOULD silently
discard the message. If, on the other hand, the inequality holds,
the receiver SHOULD process the message.
Moreover, if the above inequality holds and TSnew > TSlast, the
receiver SHOULD update RDlast and TSlast. Otherwise, the receiver
MUST NOT update RDlast or TSlast.
As unsolicited messages may be used in a Denial-of-Service attack to
make the receiver verify computationally expensive signatures, all
nodes SHOULD apply a mechanism to prevent excessive use of resources
for processing such messages.
6. Authorization Delegation Discovery
NDP allows a node to configure itself automatically based on
information learned shortly after connecting to a new link. It is
particularly easy to configure "rogue" routers on an unsecured link,
and it is particularly difficult for a node to distinguish between
valid and invalid sources of router information, because the node
needs this information before communicating with nodes outside of the
link.
As the newly-connected node cannot communicate off-link, it cannot be
responsible for searching information to help validate the router(s).
However, given a certification path, the node can check someone
else’s search results and conclude that a particular message comes
from an authorized source. In the typical case, a router already
connected beyond the link can communicate if necessary with off-link
nodes and construct a certification path.
The Secure Neighbor Discovery Protocol mandates a certificate format
and introduces two new ICMPv6 messages used between hosts and routers
to allow the host to learn a certification path with the assistance
of the router.
6.1. Authorization Model
To protect Router Discovery, SEND requires that routers 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) 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 subnet prefixes. A specific router is given a specific set
of subnet prefixes to advertise; other routers have an
authorization to advertise other subnet prefixes. Trust anchors
may also delegate a certain set of subnet 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 also
present a number of other parameters beyond the above. For instance,
routers have their own IP addresses, subnet prefixes have lifetimes,
and routers control the use of stateless and stateful address
autoconfiguration. However, the ability to be a router and the
subnet prefixes are the most fundamental parameters to authorize.
This is because the host needs to choose a router that it uses as its
default router, and because the advertised subnet prefixes have an
impact on the addresses the host uses. The subnet prefixes also
represent a claim about the topological location of the router in the
network.
Care should be taken if the certificates used in SEND are also 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 subnet prefixes than the router is
authorized to advertise on a given interface. For instance, SEND
allows the use of the null prefix, which 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, as these 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 that currently 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-operative among
Regional Internet Registries (RIRs). However, no such global root
currently exists.
In the decentralized model, end hosts are configured with a
collection of trusted public keys. The public keys could be issued
from various 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 acting 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 fall back 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
Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization paths are not a common practice
in the Internet at the time of this writing, the path MUST consist of
standard Public Key Certificates (PKC, in the sense of [8]). The
certification path MUST start from the identity of a trust anchor
shared by the host and the router. This allows 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 single trust anchor.
6.3.1. Router Authorization Certificate Profile
Router Authorization Certificates are X.509v3 certificates, as
defined in RFC 3280 [7], and SHOULD contain at least one instance of
the X.509 extension for IP addresses, as defined in [10]. The parent
certificates in the certification path SHOULD contain one or more
X.509 IP address extensions, back up to a trusted party (such as the
user’s ISP) that configured the original IP address block for the
router in question, or that delegated the right to do so. The
certificates for the intermediate delegating authorities SHOULD
contain X.509 IP address extension(s) for subdelegations. The
router’s certificate is signed by the delegating authority for the
subnet prefixes the router is authorized to advertise.
The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an
addressPrefix element containing an IPv6 address prefix for a prefix
that the router or the intermediate entity is authorized to route.
If the entity is allowed to route any prefix, the IPv6 address prefix
used is the null prefix, ::/0. The addressFamily element of the
IPAddrBlocks sequence element MUST contain the IPv6 Address Family
Identifier (0002), as specified in [10], for IPv6 subnet prefixes.
Instead of an addressPrefix element, the addressesOrRange element MAY
contain an addressRange element for a range of subnet prefixes, if
more than one prefix is authorized. The X.509 IP address extension
MAY contain additional IPv6 subnet prefixes, expressed as either an
addressPrefix or an addressRange.
A node receiving a Router Authorization Certificate MUST first check
whether the certificate’s signature was generated by the delegating
authority. Then the client SHOULD check whether all the
addressPrefix or addressRange entries in the router’s certificate are
contained within the address ranges in the delegating authority’s
certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority’s certificate. If
an addressPrefix or addressRange is not contained within the
delegating authority’s subnet prefixes or ranges, the client MAY
attempt to take an intersection of the ranges/subnet prefixes and to
use that intersection. If the resulting intersection is empty, the
client MUST NOT accept the certificate. If the addressPrefix in the
certificate is missing or is the null prefix, ::/0, the parent prefix
or range SHOULD be used. If there is no parent prefix or range, the
subnet 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 checks SHOULD be done for all certificates in the path. If
any of the checks fail, the client MUST NOT accept the certificate.
The client also has to perform validation of advertised subnet
prefixes as discussed in Section 7.3.
Hosts MUST check the subjectPublicKeyInfo field within the last
certificate in the certificate path to ensure that only RSA public
keys are used to attempt validation of router signatures. Hosts MUST
disregard the certificate for SEND if it does not contain an RSA key.
As it is possible that some public key certificates used with SEND do
not immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD
be switched off by default. The system SHOULD have a default
configuration that requires rigorous prefix and range checks.
The following is an example of a certification path. Suppose that
isp_group_example.net is the trust anchor. The host has this
certificate:
Certificate 1:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group_example.net
Extensions:
IP address delegation extension:
Prefixes: P1, ..., Pk
... possibly other extensions ...
... other certificate parameters ...
When the host attaches to a link served by
router_x.isp_foo_example.net, it receives the following certification
path:
Certificate 2:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes: Q1, ..., Qk
... possibly other extensions ...
... other certificate parameters ...
Certificate 3:
Issuer: isp_foo_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: router_x.isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes R1, ..., Rk
... possibly other extensions ...
... other certificate parameters ...
When the three certificates are processed, the usual RFC 3280 [7]
certificate path validation is performed. Note, however, that when a
node checks certificates received from a router, 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 (CRL) check, if
necessary. Until this check is performed, acceptance of the
certificate MUST be considered provisional, and the node MUST perform
a check as soon as it has established a connection with the Internet
through the router. If the router has been compromised, it could
interfere with the CRL check. Should performance of the CRL check be
disrupted or should the check fail, the node SHOULD immediately stop
using the router as a default and use another router on the link
instead.
In addition, the IP addresses in the delegation extension MUST be a
subset of the IP addresses in the delegation extension of the
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
the certification path is valid, then router_foo.isp_foo_example.com
is authorized to route the prefixes R1,...,Rs.
6.3.2. Suitability of Standard Identity Certificates
As 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
path, a host interprets a standard identity certificate as allowing
unconstrained prefix advertisements.
If the other certificates contain prefix information, a standard
identity certificate is interpreted as allowing those subnet
prefixes.
6.4. Certificate Transport
The Certification Path Solicitation (CPS) message is sent by a host
when it wishes to request a certification path between a router and
one of the host’s trust anchors. The Certification Path
Advertisement (CPA) message is sent in reply to the CPS message.
These messages are kept separate from the rest of Neighbor and Router
Discovery to reduce the effect of the potentially voluminous
certification path information on other messages.
The Authorization Delegation Discovery (ADD) process does not exclude
other forms of discovering certification paths. For instance, during
fast movements, mobile nodes may learn information (including the
certification paths) about the next router from a previous router, or
nodes may be preconfigured with certification paths from roaming
partners.
Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the
peer’s certification path. However, the details of such usage are
beyond the scope of this specification.
6.4.1. Certification Path Solicitation Message Format
Hosts send Certification Path Solicitations in order to prompt
routers to generate Certification Path Advertisements.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
A link-local unicast address assigned to the sending interface,
or to the unspecified address if no address is assigned to the
sending interface.
Destination Address
Typically the All-Routers multicast address, the Solicited-Node
multicast address, or the address of the host’s default router.
Hop Limit
255
ICMP Fields:
Type
148
Code
0
Checksum
The ICMP checksum [6].
Identifier
A 16-bit unsigned integer field, acting as an identifier to
help match advertisements to solicitations. The Identifier
field MUST NOT be zero, and its value SHOULD be randomly
generated. This randomness does not have to be
cryptographically hard, as its purpose is only to avoid
collisions.
Component
This 16-bit unsigned integer field is set to 65,535 if the
sender seeks to retrieve all certificates. Otherwise, it is
set to the component identifier corresponding to the
certificate that the receiver wants to retrieve (see Sections
6.4.2 and 6.4.6).
Valid Options:
Trust Anchor
One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.4.3. If there is more than
one Trust Anchor option, the options beyond the first may
contain any type of trust anchor.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST
have a length greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets.
6.4.2. Certification Path Advertisement Message Format
Routers send out Certification Path Advertisement messages in
response to a Certification Path Solicitation.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+