+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
11
Length
The length of the option (including the Type, Length, Pad Length,
Reserved, CGA Parameters, and Padding fields) in units of 8
octets.
Pad Length
The number of padding octets beyond the end of the CGA Parameters
field but within the length specified by the Length field.
Padding octets MUST be set to zero by senders and ignored by
receivers.
Reserved
An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.
CGA Parameters
A variable-length field containing the CGA Parameters data
structure described in Section 4 of [11].
This specification requires that if both the CGA option and the
RSA Signature option are present, then the public key found from
the CGA Parameters field in the CGA option MUST be that referred
by the Key Hash field in the RSA Signature option. Packets
received with two different keys MUST be silently discarded. Note
that a future extension may provide a mechanism allowing the owner
of an address and the signer to be different parties.
Padding
A variable-length field making the option length a multiple of 8,
containing as many octets as specified in the Pad Length field.
5.1.1. Processing Rules for Senders
If the node has been configured to use SEND, the CGA option MUST be
present in all Neighbor Solicitation and Advertisement messages and
MUST be present in Router Solicitation messages unless they are sent
with the unspecified source address. The CGA option MAY be present
in other messages.
A node sending a message using the CGA option MUST construct the
message as follows:
The CGA Parameter field in the CGA option is filled according to
the rules presented above and in [11]. The public key in the
field is taken from the configuration used to generate the CGA,
typically from a data structure associated with the source
address. The address MUST be constructed as specified in Section
4 of [11]. Depending on the type of the message, this address
appears in different places, as follows:
Redirect
The address MUST be the source address of the message.
Neighbor Solicitation
The address MUST be the Target Address for solicitations sent for
Duplicate Address Detection; otherwise it MUST be the source
address of the message.
Neighbor Advertisement
The address MUST be the source address of the message.
Router Solicitation
The address MUST be the source address of the message. Note that
the CGA option is not used when the source address is the
unspecified address.
Router Advertisement
The address MUST be the source address of the message.
5.1.2. Processing Rules for Receivers
Neighbor Solicitation and Advertisement messages without the CGA
option MUST be treated as unsecured (i.e., processed in the same way
as NDP messages sent by a non-SEND node). The processing of
unsecured messages is specified in Section 8. Note that SEND nodes
that do not attempt to interoperate with non-SEND nodes MAY simply
discard the unsecured messages.
Router Solicitation messages without the CGA option MUST also be
treated as unsecured, unless the source address of the message is the
unspecified address.
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing a CGA
option MUST be checked as follows:
If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet by using the
algorithm described in Section 5 of [11]. The inputs to the
algorithm are the claimed address, as defined in the previous
section, and the CGA Parameters field.
If the CGA verification is successful, the recipient proceeds with
a more time-consuming cryptographic check of the signature. Note
that even if the CGA verification succeeds, no claims about the
validity of the use can be made until the signature has been
checked.
A receiver that does not support CGA or has not specified its use for
a given interface can still verify packets by using trust anchors,
even if a CGA is used on a packet. In such a case, the CGA property
of the address is simply left unverified.
5.1.3. Configuration
All nodes that support the verification of the CGA option MUST record
the following configuration information:
minbits
The minimum acceptable key length for public keys used in the
generation of CGAs. The default SHOULD be 1024 bits.
Implementations MAY also set an upper limit for the amount of
computation needed when verifying packets that use these security
associations. The upper limit SHOULD be at least 2048 bits. Any
implementation should follow prudent cryptographic practice in
determining the appropriate key lengths.
All nodes that support the sending of the CGA option MUST record the
following configuration information:
CGA parameters
Any information required to construct CGAs, as described in [11].
5.2. RSA Signature Option
The RSA Signature option allows public key-based signatures to be
attached to NDP messages. The format of the RSA Signature option is
described in the following diagram:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
12
Length
The length of the option (including the Type, Length, Reserved,
Key Hash, Digital Signature, and Padding fields) in units of 8
octets.
Reserved
A 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Key Hash
A 128-bit field containing the most significant (leftmost) 128
bits of a SHA-1 [14] hash of the public key used for constructing
the signature. The SHA-1 hash is taken over the presentation used
in the Public Key field of the CGA Parameters data structure
carried in the CGA option. Its purpose is to associate the
signature to a particular key known by the receiver. Such a key
can either be stored in the certificate cache of the receiver or
be received in the CGA option in the same message.
Digital Signature
A variable-length field containing a PKCS#1 v1.5 signature,
constructed by using the sender’s private key over the following
sequence of octets:
1. The 128-bit CGA Message Type tag [11] value for SEND, 0x086F
CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
generated randomly by the editor of this specification.).
2. The 128-bit Source Address field from the IP header.
3. The 128-bit Destination Address field from the IP header.
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the
ICMP header.
5. The NDP message header, starting from the octet after the ICMP
Checksum field and continuing up to but not including NDP
options.
6. All NDP options preceding the RSA Signature option.
The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash, as defined in [13].
This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the RSA
Signature option minus the length of the other fields (including
the variable length Pad field).
Padding
This variable-length field contains padding, as many bytes long as
remain after the end of the signature.
5.2.1. Processing Rules for Senders
If the node has been configured to use SEND, Neighbor Solicitation,
Neighbor Advertisement, Router Advertisement, and Redirect messages
MUST contain the RSA Signature option. Router Solicitation messages
not sent with the unspecified source address MUST contain the RSA
Signature option.
A node sending a message with the RSA Signature option MUST construct
the message as follows:
o The message is constructed in its entirety, without the RSA
Signature option.
o The RSA Signature option is added as the last option in the
message.
o The data to be signed is constructed as explained in Section 5.2,
under the description of the Digital Signature field.
o The message, in the form defined above, is signed by using the
configured private key, and the resulting PKCS#1 v1.5 signature is
put in the Digital Signature field.
5.2.2. Processing Rules for Receivers
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages without the RSA Signature option MUST be
treated as unsecured (i.e., processed in the same way as NDP messages
sent by a non-SEND node). See Section 8.
Router Solicitation messages without the RSA Signature option MUST
also be treated as unsecured, unless the source address of the
message is the unspecified address.
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing an RSA
Signature option MUST be checked as follows:
o The receiver MUST ignore any options that come after the first RSA
Signature option. (The options are ignored for both signature
verification and NDP processing purposes.)
o The Key Hash field MUST indicate the use of a known public key,
either one learned from a preceding CGA option in the same
message, or one known by other means.
o The Digital Signature field MUST have correct encoding and MUST
not exceed the length of the RSA Signature option minus the
Padding.
o The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section.
o If the use of a trust anchor has been configured, a valid
certification path (see Section 6.3) between the receiver’s trust
anchor and the sender’s public key MUST be known.
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
anchor.
Messages that do not pass all the above tests MUST be silently
discarded if the host has been configured to accept only secured ND
messages. The messages MAY be accepted if the host has been
configured to accept both secured and unsecured messages but MUST be
treated as an unsecured message. The receiver MAY also otherwise
silently discard packets (e.g., as a response to an apparent CPU
exhausting DoS attack).
5.2.3. Configuration
All nodes that support the reception of the RSA Signature options
MUST allow the following information to be configured for each
separate NDP message type:
authorization method
This parameter determines the method through which the authority
of the sender is determined. It can have four values:
trust anchor
The authority of the sender is verified as described in
Section 6.3. The sender may claim additional authorization
through the use of CGAs, but this is neither required nor
verified.
CGA
The CGA property of the sender’s address is verified as
described in [11]. The sender may claim additional
authority through a trust anchor, but this is neither
required nor verified.
trust anchor and CGA
Both the trust anchor and the CGA verification is required.
trust anchor or CGA
Either the trust anchor or the CGA verification is required.
anchor
The allowed trust anchor(s), if the authorization method is not
set to CGA.
All nodes that support sending RSA Signature options MUST record the
following configuration information:
keypair
A public-private key pair. If authorization delegation is in
use, a certification path from a trust anchor to this key pair
must exist.
CGA flag
A flag that indicates whether CGA is used or not. This flag
may be per interface or per node. (Note that in future
extensions of the SEND protocol, this flag may also be per
subnet prefix.)
5.2.4. Performance Considerations
The construction and verification of the RSA Signature option is
computationally expensive. In the NDP context, however, hosts
typically only have to perform a few signature operations as they
enter a link, a few operations as they find a new on-link peer with
which to communicate, or Neighbor Unreachability Detection with
existing neighbors.
Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature
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
solicitations may cause a higher demand for performing asymmetric
operations, although the base NDP protocol limits the rate at which
multicast responses to solicitations can be sent.
Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements if the timing of the future advertisements
is known. Typically, solicited neighbor advertisements are sent to
the unicast address from which the solicitation was sent. Given that
the IPv6 header is covered by the signature, it is not possible to
precompute solicited advertisements.
5.3. Timestamp and Nonce Options
5.3.1. Timestamp Option
The purpose of the Timestamp option is to make sure that unsolicited
advertisements and redirects have not been replayed. The format of
this option is described in the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
13
Length
The length of the option (including the Type, Length, Reserved,
and Timestamp fields) in units of 8 octets; i.e., 2.
Reserved
A 48-bit field reserved for future use. The value MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.
Timestamp
A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1, 1970, 00:00 UTC,
by using a fixed point format. In this format, the integer number
of seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/64K fractions of a
second.
Implementation note: This format is compatible with the usual
representation of time under UNIX, although the number of bits
available for the integer and fraction parts may vary.
5.3.2. Nonce Option
The purpose of the Nonce option is to make sure that an advertisement
is a fresh response to a solicitation sent earlier by the node. The
format of this option is described in the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
14
Length
The length of the option (including the Type, Length, and Nonce