Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol
Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
9 rue Charles Fourier Evry91011Francetony.cheneau@it-sudparis.eu
Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
9 rue Charles Fourier Evry91011Francemaryline.laurent@it-sudparis.euHuawei4, South 4th Street, ZhongguancunBeijing100190P.R. Chinasean.s.shen@gmail.com
Qualcomm
mvandervn@gmail.com
Internet
CGA & SEND maintenanceCGARSAECDSAThis draft describes a mechanism to enable the Secure Neighbor Discovery (SEND) protocol to select
between different signature algorithms to use with Cryptographically Generated Addresses (CGA). The usage scenarios associated with neighbor discovery have recently been
extended to include environments with mobile or nomadic nodes.
Many of these nodes have limited battery power and computing resources. Therefore, heavy public key signing
algorithms like RSA are not feasible to support on such constrained nodes. Fortunately, more lightweight
yet secure signing algorithms do exist and have been standardized, e.g. Elliptic Curve based algorithms.It is then a worthwhile goal to extend secure neighbor discovery to support signing and corresponding hashing
algorithm agility. Besides
accommodating power-constrained nodes, signing and hashing algorithm agility is also desired as a safety measure
over time, to offer alternatives when cryptanalysis of one type of algorithm makes significant progress.
The aim of this memo is to outline options for allowing public key signing algorithm and hashing algorithm
agility for nodes configured to perform secure neighbor discovery operations.
The extent to which these options impact existing specifications and
is also addressed. The current SEND protocol specification, , mandates the use of the RSA signature algorithm.
Since the time of its writing, different signature algorithms have been shown to be secure and have been
adopted by other protocols in an effort to reduce key length, signature generation and verification time, and
increase security level.
This shift in signature algorithm adoption particularly benefits lightweight devices, which are
power and memory-limited but in need of secure signing algorithms support. For these reasons, we feel that
the restriction on the signature algorithm for SEND is no longer warranted.At the time of this writing, there are no known large-scale or even small-scale deployment of -compatible devices.
However, in the interest of caution, we assume that there exist nodes that support only the RSA algorithm and that are configured
to perform secure neighbor discovery. Such nodes may not be updated in the near term or for the foreseeable future.
On the other hand, it appears that there will be deployments of nodes that support only Elliptic Curve Cryptography as their
public key algorithm, i.e. ECDSA as a signature algorithm, rather than traditional RSA. To ensure that all possible network/link configurations are considered when designing a signature agility solution,
we categorize nodes (hosts and routers) according to their support for different signature algorithms, as follows:
A host that only supports one type of signature algorithm and has a CGA generated
with the public key of this algorithm. Examples of this type of hosts: an old host that does not support signature agility,
i.e. only supports RSA signature algorithm; or, a host that only supports ECDSA signature. A host that supports multiple signature algorithms and has a CGA generated with
only one key selected from among its supported algorithms.Examples of this type of hosts: (1) a host that supports RSA and ECDSA signature algorithms,
but only has a CGA derived with an RSA public key; (2) a host that supports RSA and ECDSA signature algorithms,
but only has a CGA derived with an ECC public key. A host that supports multiple signature algorithms and has a CGA generated with
multiple keys of different supported algorithms.Such CGA addresses have been studied during the writing of this document and have been proved to be hard to secure. A host that supports multiple signature algorithms and has multiple CGAs, each of which is
associated with a single key of one supported algorithm.
A node MUST select and settle on one CGA when building a trust relationship with another device via SeND (more
below). In such cases, a destination node may be reached at a CGA associated with a signature algorithm
that the originating node cannot verify. The destination node will need to securely redirect the originating node
to one of its other CGA(s) (presumably with a common signature algorithm). The need for a method to secure
the binding between the two CGAs of the destination node is still an open problem, that is considered out of scope.Based on this reasoning, consideration of H4 type nodes is left for future work. Routers are more likely to possess
the resources necessary to support multiple signature and hashing algorithms. It is also more feasible
that routers employ certificates. However, for a basic signature agility solution, we do not mandate that
routers support multiple signature and hashing algorithms. Possible router devices with different signature algorithm support ability are:
A router that only supports one type of signature algorithm and has a CGA and Certificate with
a public key of this algorithm. Such routers are expected to be commonplace, as compliance with suffices for them. A router that supports multiple types of signature algorithms and has one CGA and Certificate with
a public key of one of the algorithm types. This type of router can sign and verify signatures of the type of certificate it owns, and additionally,
it can verify signatures of other algorithm types. A router that supports multiple types of signature algorithms
and has one CGA composed of multiple Publics Keys and multiple certificates containing each a Public Key. Similar considerations as for H3 host type apply here: CGA addresses based on multiple Public Keys are hard to secure and should not be used.A router that supports multiple types of signature algorithms and has multiple CGAs
and Certificates with public key of several different algorithm types. This type of router can sign and verify signatures of multiple types. Such routers may not be attractive to
build and deploy due to increased requirements on its resources. Moreover using multiple CGAs (with no bindings)
may make that routers appear as having multiple identities.Note that all types of router presented above can be configured to use SEND over multiple interfaces or to have multiple addresses on the same interface. In this case, the router will use separate CGAs. Such configuration is treated in this draft as if the different addresses refer to separate entities.Based on the discussion above, a SEND agility solution should at least properly deal with the communication between devices of type H1, H2, R1, R2 and R4.An H1 or R1 node interacting with an H2 or R2 node: i.e., a node supporting only RSA (for example,
an old non-agility node which only supports RFC3971) and a node supporting
both RSA and ECDSA (or other new algorithms). These two nodes may be able to perform secure neighbor discovery.An H1 or R1 node interacting with another H1 or R1 node, but their algorithms differ: e.g., a node supporting only
RSA (for example, an old non-agility node which only supports RFC3971) and a node supporting only
ECDSA (or other new algorithms). In this case, implementations supporting SEND signature agility solution
may likely realize the incompatibility, while older implementations may not. An H2, or R2 node interacting with another H2 or R2 node: when the two nodes support at least verification of the signature algorithm used by its correspondent for signature generation (tightly bound to the Public Key type used to generate the CGA address), they can perform secure neighbor discovery.We hold the following to be requirements on a signing algorithm agility solution for SEND: A Signature-Algorithm-Agility-Node should be able to communicate with a Non-Signature-Algorithm-Agility-Node,
but not necessarily employ SEND. Traditional ND should suffice, to accommodate nodes that only support
one type of Signature Algorithm, which may not be RSA. Local policy MAY disable this behavior, namely
the use of unsecured ND messages when communicating with a node that does not share any common signature
algorithm.Two Signature-Algorithm-Agility nodes that support signing with a common Signature Algorithm and hashing algorithm
should be able to communicate
using SEND and sign messages using the common Signature Algorithm and hash algorithm.The current SEND/CGA specifications should incur as few changes as possible.This document proposes an update to to allow two SEND nodes to choose an appropriate signature algorithm.
This solution encompasses the following:
A "Supported Signature Algorithm" Neighbor Discovery Protocol option which contains a list of
signing and hashing algorithms that the sender node supports for SEND purposes and its interaction with the Neighbor Cache; A modification of the "RSA Signature" option defined in the SEND specification; We define the aforementioned options format and provide processing rules for both senders
and receivers of SEND messages employing the new options, as well as example negotiation message flows.
Note that the ECC support for SEND is described in document .
The Supported Signature Algorithm (SSA) NDP option contains a list of signing and hashing algorithm pairs
that the sender node supports. The format of this option is described in
: NDP option type, TBA. See . The length of the option
(including the Type, Length fields), in octets. 8-bit unsigned integer, the values lower than 2 are invalid. Reserved for future use. This 16-bit field MUST be set
to zero by the sender, and MUST be ignored by the receiver.
A one-octet long field indicating a signature algorithm and the corresponding hash algorithm that
this node supports; this support implies at least ability to verify signatures of this Signature Algorithm algorithm.
If the first leftmost bit, bit 0, is set to 0, it indicates that the emitter is able to perform signature checks only (i.e. no signature
generation with this type of signature algorithm).
If this bit is set to 1, it indicates that the emitter has a public key of this type and can generate signatures.
Bit 1 and 2 are reserved.
Bit 3 to 7 are named Signature Type Identifier subfield and encode an identifier for the signature algorithm and corresponding hash algorithm.
Default values for the Signature Type Identifier subfield defined in this document are taken in part from the IANA-defined numbers
for the IKEv2 protocol, i.e. IANA registry named "IKEv2 Authentication Method":
Value 0 is RSA/SHA-1 (compatible with )Value 1 is RSA/SHA-256Section 5 of document provides values for ECDSA signature algorithm
The Signature/hash Algorithm combinations SHOULD be included in order of preference.
A SSA option MAY be built to respect a Local Policy.
However, the SSA option MUST not indicate Signature Algorithm(s) that the emitting node's CGA does not support
and MUST contain at least one Signature Algorithm with the first bit on (i.e. this Signature Algorithm is available for signature generation).
Neighbor Cache MUST have the ability to store Supported Signature Algorithm information for each entry (i.e. IPv6 address).
Supported Signature Algorithm information for an entry MAY be empty (e.g. entry created by a RFC 3971 node or an unverifiable message).
If a node has been configured to use SEND, then all Neighbor Solicitation,
Neighbor Advertisement, Router Solicitation, Router Advertisement, and Redirect messages
it sends MUST contain the Supported Signature Algorithm option.
This option MUST contain in the Signature Algorithm field(s) all the
signature algorithms it is willing to use in signature generation and verification.
Upon receiving a SEND packet with a Supported Signature Algorithm Option, a receiver performs the following operations:
When a message is a Neighbor Solicitation or a Router Solicitation, the receiving node
computes the intersection between the set of Supported Signature Algorithm indicated
by the option and its own. If the set is empty, this means the node will not be able to use a
Signature Algorithm that the initiating node can check. Given the local policy,
a receiver node MAY still respond to the received message using its "preferred" Signature
Algorithm (even if the node knows the receiver will not be able to verify the Signature Algorithm).
If the set is not empty, the receiving node will choose one of the algorithms among the set
in order to generate a Universal Signature Option.
If a message passes the SEND verifications (CGA verification, Timestamp, Nonce, Universal Signature Option verification) and contains a Supported Signature Algorithm Option,
the information of the Supported Signature Algorithm in the Neighbor Cache is updated by the information contained in the
Supported Signature Option attached to the message.
If a message does not pass the SEND verifications because of a unverifiable RSA Signature Option or Universal Signature Option, if it contains a Supported Signature Algorithm Option,
and the Neighbor Cache entry associated to that node does not contain any information about the Supported Signature Algorithm, the Neighbor Cache
entry SHOULD be updated with the information contained in the Supported Signature Algorithm Option.
We propose replacing the RSA Signature Option by a new algorithm-independent signature option.
The "Universal Signature Option" is an updated version of the RSA Signature Option, that allows a node to
specify which Signature Algorithm it is using.
To achieve this, we use the 16-bit reserved field of the RSA Signature Option, and define a new 5-bit Signature
Type Identifier field that details the type of algorithms used to generate the Digital Signature.
Same value as in : 12.
The length of the option (including the Type, Length, Reserved, Signature Type Identifier,
Key Hash, Digital Signature, and Padding fields) in units of 8
octets.
A 11-bit field reserved for future use. The value MUST be
set to zero by the sender and MUST be ignored by the
receiver.
Signature Type Identifier is a 5-bit field. It corresponds to the Signature Type Identifier subfield (bits 3 to 7 of the Signature Algorithm field)
in the Supported Signature Algorithm option . It indicates the type of signature contained in the Digital Signature field.
A 128-bit field containing the most significant (leftmost) 128 bits of a hash of the public key used for constructing the signature.
It is computed using the same hash function as used in generating digital signature
(indicated in Signature Type Identifier).
The hash value is computed 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 with 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.
A variable-length field containing a signature constructed by using the sender's private key associated to
the public key. The signature type is determined from the value of the Signature Type Identifier field.
If the value of the Signature Type Identifier field is 0, the Digital
Signature field is computed the same way as the Digital Signature field of the RSA Signature Option described in . This value is compatible with .
If the value of the Signature Type Identifier field is 1, then this Digital Signature field is computed the same way
as the Digital Signature field of the RSA Signature Option described in except that the
signature is computed with the RSASSA-PKCS1-v1_5 algorithm (as defined in ) and the SHA-256 hash function.
Values for ECDSA signature algorithm are defined in Section 5 of .
This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the Universal
Signature option minus the length of the other fields (including
the variable length Pad field).
This variable-length field contains padding, as many bytes long as
remain after the end of the signature.
A Neighbor Solicitation/Advertisement, Router Solicitation/Advertisement and Redirect message
MAY contain more than one Universal Signature Option, as long as it does not exceed the MTU.
This is particularly useful for routers operating in heterogeneous networks,
where hosts have a disjoint set of supported signature algorithms. For information on how to compute the message size, see .
When sending a SEND message spontaneously, an emitter node CAN choose a signature algorithm of its
preference (defined by its local policy) among the corresponding Signature Algorithm available for the Public Key carried in the CGA option. Using this signature
algorithm, the node computes the Digital Signature and fills the Signature Type Identifier field with appropriate value.If the node has been configured to use SEND, then all Neighbor Solicitation,
Neighbor Advertisement, Router Advertisement, and Redirect messages
MUST contain at least one Universal Signature option. Router Solicitation messages
not sent with the unspecified source address MUST contain the Universal
Signature option.A node sending a message with one or more Universal Signature option(s) MUST construct
the message as follows:
If the node has previously received hints (e.g. a NDP message with a Supported Signature Algorithm
option or an entry in the Neighbor Cache) on the type of Signature Algorithm it should use, it MUST restrict
its choice on those Signature Algorithms.
The message is then constructed in its entirety, without any of the Universal
Signature options.The Universal Signature option(s) is (are) added as the last option in the
message.The data to be signed is constructed as explained in ,
under the description of the Digital Signature field.The message, in the form defined above, is signed by using the
configured private key associated to the selected Signature Algorithm, and the result
signature
is encapsulated into the Digital Signature field.
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages without any Universal Signature option or
with an unverifiable Universal 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 of .Router Solicitation messages without any Universal 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 one or more Universal
Signature option MUST be checked as follows:
The receiver MUST ignore any options that come after the first Universal
Signature option. (The options are ignored for both signature
verification and NDP processing purposes.)The Key Hash field MUST correspond to a known public key,
either one learned from the CGA option in the same message or one known by other means.The Digital Signature field MUST have correct encoding and MUST
not exceed the length of the Universal Signature option minus the
Padding.The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section.If the use of a trust anchor has been configured, a valid
certification path (see Section 6.3 of ) between the receiver's trust
anchor and the sender's public key MUST be known.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 unsecured messages. The receiver MAY also otherwise
silently discard packets (e.g., as a response to an apparent CPU
exhausting DoS attack).This section describes different configurations of SEND-enabled nodes with varying signing capabilities and their interaction during the negotiation phase.Case 1: when both nodes support the same two Signature Algorithms, they can pick the Signature Algorithm they prefer for signing and are able to verify each others signature. is an example of such a message flow.
Case 2: two nodes sharing at least one common Signing Algorithm must be able to securely communicate.
is an example of such a message flow.
Case 3: when two nodes have a disjoint set of Signature Algorithm support for signing, but the two nodes are able to verify each others, a full negotiation is possible.
is an example of such a message flow.
Case 4: when two nodes have a disjoint set of Signature Algorithm support for signing, but one node is able to verify, a partial negotiation is possible.
is an example of such a message flow.
Upon receiving the Neighbor Solicitation message, node B determines, through the Supported Signature Algorithm option, that node A
will not be able to verify any of its signature algorithm. However, based on their local policy, node B may answer and node A might decide
to trust the unsecure Neighbor Discovery (thus being vulnerable), see .
When sending unsolicited message, a node MAY have to rely on the entries of its Neighbor Cache.
The Neighbor Cache will provide hints concerning the Signature Algorithm supported by the neighbors.
Neighbor Cache can assist the node in the Signature Algorithm selection process when:
A router advertises unsolicited Router Advertisement message to the All-Nodes multicast address
(e.g. to indicate a prefix lifetime is going down to 0).
The router needs to know which signature algorithm(s) to use in order to send verifiable messages to hosts.
To do so, the router MAY rely on the Neighbor Cache and compute an intersection of the set of all Supported Signature Algorithms.
The router will then be able to advertise a Router Advertisement signed multiple times
with the resulting subset of Supported Signature Algorithms or
advertise multiple Router Advertisements, each signed with a single Signature Algorithm part of the intersection.
A node sends unsolicited Neighbor Advertisement (e.g. when changing its Link-Layer address). This is similar to the previous
problem and can also be solved using the Neighbor Cache the same way.
A router sends a Redirect message to a host. Choosing a supported signature algorithm
without probing the node can be difficult. However, Neighbor Cache will most likely contain
an entry for the host, prior to the decision to send a Redirect message, because of the Address
Resolution process.
This entry should contain information on the Supported Signature Algorithm(s)
and thus provide hints concerning the Signature Algorithm to choose to sign the Redirect messages.
Note that the information on the neighbors with which a communication has occurred recently or is ongoing are in the Neighbor Cache and are maintained up to date through the Neighbor Unreachability Detection procedure.
This document advises that the Certificate Path MAY only contain certificates signed with a same signature algorithm. That is, if a node support this specific signature type, he will be able to verify all the certificates composing the Certificate Path. However, when only one Certificate Path composed of certificate signed by different signature algorithm is available, a node is expected to be able to process certificates signed with Signature Algorithm advertised by its Supported Signature Algorith option. Thus, a router can verify when responding to a Certificate Path Solicitation message if the Certificate Path is verifiable by the requester.
TBD
presents a new Universal Signature Option. A recommended use of this option is to allow signatures of equivalent security level (i.e. Public Keys with equivalent key lengths) for a same node.
Usage of SHA-1 for signature is strongly NOT RECOMMENDED, and when available should be preferred by the usage of SHA-256. SHA-1 security has
been proved to be flawed in the light of recent attacks .
The Universal Signature Option is vulnerable to downgrade attacks. That is, given that a node can employ multiple signature types (by varying the hash function), an attacker may choose to use a flawed one. To mitigate this issue, nodes are allowed, on a local policy, to refuse to check certain types of signature (i.e. those which are know to be flawed) and will treat the associated messages as unsecured. When trying to completely mitigate downgrade attacks, an administrator MAY deploy SEND-secured nodes only authorizing a single signature algorithm scheme. This comes at a price of a reduced interoperability.
defines a Signature Type Identifier subfield containing new values corresponding to different Signature Algorithm. This document requests creation of a new registry to the IANA. The authors gratefully acknowledge the contributions of Marcelo Bagnulo, Gabriel Montenegro,
Greg Daley, Dave Thaler, Stephen Kent, Jari Arko, and Francis Dupont for their helpful feedback.Cryptographically Generated Addresses (CGA)This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS TRACK]SEcure Neighbor Discovery (SEND)IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS TRACK]Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS TRACK]ECCÂ public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND)This draft describes a mechanism to deploy Elliptic Curve Cryptography (ECC) alongside with Cryptographically Generated Addresses (CGA) and the Secure Neighbor Discovery.
This document provides basic skeleton for other Signature Algorithms to be integrated in CGA and SEND. Internet Protocol, Version 6 (IPv6) SpecificationCisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706USA+1 408 527 8213+1 408 527 8254deering@cisco.comNokia232 Java DriveSunnyvaleCA94089USA+1 408 990 2004+1 408 743 5677hinden@iprg.nokia.com
Internet
internet protocol version 6IPv6
This document specifies version 6 of the Internet Protocol (IPv6),
also sometimes referred to as IP Next Generation or IPng.
IPv6 Neighbor Discovery (ND) Trust Models and ThreatsThe existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS TRACK]NIST Comments on Cryptanalytic Attacks on SHA-1National Institute of Standards and TechnologyRSA Encryption Standard, Version 2.1RSA LaboratoriesSecure Hash StandardNational Institute of Standards and Technology
SEC 1: Elliptic Curve Cryptography
Standards for Efficient Cryptography Group
SHA-1 collisions now 2^52Authors announced that a new path to find SHA-1 collision has complexity 2^52. Practical collisions
are within resources of a well funded organisation and paper will appear on Eprint soon.RSA key length (bits)Public exponentSize of the DER-encoded Public Key (bytes)3843 or 177638465537785123 or 1792512655379410243 or 1716010246553716220483 or 1729220486553729430723 or 1742030726553742276803 or 17996768065537998153603 or 17195615360655371958RSA Key Length (in bits)Size of the Digital Signature field without padding38448512641024128204825630723847680960153601920
When using multiple Universal Signature Options, one may reach before each Neighbor
the Maximum Transfer Unit (which must be at least 1280 octets according to
). This section aims to approximate this limit.
Numerous factors (presence and number of option, size of public key, etc) influence the size of the Neighbor
Discovery message. For example, when sending a SEND-secured Router Advertisement message:
The IPv6 header is 40 bytes long. Described in .The bare Router Advertisement message (without any option) is 16 bytes long. Described in .A Prefix Information Option (can appear more than once) is 32 bytes long. Described in .A Source Link-Layer Option, when a IEEE 802 address is used, is 8 bytes long. Described in .A MTU Option is 8 bytes long. Described in .The CGA Option is the size of the CGA Parameters data structure plus 4 bytes rounded up to the closest multiple of 8 value. This option is defined in .
The CGA Parameters data structure (defined in size depends on the following fields:
Modifier: 16 bytes long.Subnet Prefix: 8 bytes long.Collision Count: 1 byte long.Public Key: variable size. provides size of the commonly used DER-encoded RSA Public Keys.
Extension(s): variable size.The Timestamp Option is 16 bytes long. Defined in .The Nonce Option minimum size is 8 bytes long. Defined in .The Universal Signature Option depends on the size of the Digital Signature. The fixed part of the option is 20 bytes long.
This option is updated in this document. presents common sizes for usual Digital Signature field when using RSA.
This option size must be a multiple of 8 bytes.
A Router Advertisement message, carrying a Prefix Information Option and a Source Link-Layer Option, without Nonce, with one 1024-bits long RSA Public Key and a
Public Exponent of 3 in the CGA Option is 456 bytes long.