Secure NEighbor Discovery (SEND) over OMNI Interfaces

The Overlay Multilink Network Interface (OMNI) specification can be used by nodes on public Internetworks when a suitable security service is provided to authenticate IPv6 Neighbor Discovery (IPv6 ND) control messages . The basic OMNI security service for transmission of IPv6 ND messages over public Internetworks uses a Hashed Message Authentication Code (HMAC) based on a shared secret. This document specifies use of the Secure NEighbor Discovery (SEND) protocol over OMNI interfaces which can provide a more flexible and robust service. The HMAC-based security service may be adequate when all OMNI access routers can be provisioned with a shared secret for all potential clients. However, the service may not be scalable and/or agile enough for all environments, e.g., when the population of clients grows and/or changes dynamically. Moreover, it is client-server oriented, and may be too cumbersome for general-purpose use between opportunistic neighbor pairs. The Secure NEighbor Discovery (SEND) protocol and Cryptographically Generated Addresses (CGA) were designed to provide authentication services for IPv6 ND messaging over links of all varieties, including wireless. SEND requires that the CGA appear as the IPv6 ND message source or target address (see: Section 5.1.1 of ) where it will be covered by the RSA signature. Since OMNI interfaces use only non-CGA source and target addresses, however, this specification updates by allowing CGAs to appear elsewhere in the message. The use of SEND over OMNI interfaces offers the opportunity for a certificate-based security service for large and dynamically changing populations of mobile nodes within a bounded service domain. The service domain can be as large as a major public Internetwork, and can even span multiple disjoint Internetworks when appropriate peering arrangements are in place. The remainder of this document specifies the operation of SEND over OMNI interfaces.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The HMAC-based authentication option specified in is distinguished by the two-octet code 0x0001 immediately following the UDP/IP encapsulation headers. The first octet 0x00 indicates that a message preamble option follows, while the second octet 0x01 is a 'type' field that identifies the HMAC-based authentication option. Following the authentication option (and any other preamble options present), the IPv6 ND message itself begins and includes any necessary SEND options. This specification allows CGAs to appear in a location other than the source or target address of the IPv6 ND message. In particular, this specification defines a new "Cryptographically Generated Address (CGA)" sub-option for the OMNI option (see Section 10 of ) formatted as follows:

Sub-Type is set to "TBD". Sub-Length is set to 16 (i.e., the length of the CGA). Cryptographically-Generated Address (CGA) is a 128 bit IPv6 address generated as specified in . With this sub-option, OMNI nodes can place their CGAs inside the OMNI option instead of as the source or target address of the IPv6 ND message (note that this represents an update to Section 5.1.1 of ). The processing rules for senders and receivers are discussed in the following Sections.

Per the OMNI specification , a mobile node (MN) may be pre-provisioned with a Mobile Network Prefix (MNP) (e.g., 2001:db8:1:2::/64) which it uses to form an MNP-based OMNI Link Local Address (LLA) and MNP-based CGA. Otherwise, the MN obtains an MNP through an initial IPv6 ND message-based bootstrapping exchange with an Access Router (AR) while using a temporary LLA and LLA-based CGA using the prefix fe80::/64. The MN sends IPv6 ND messages with an OMNI option that includes its CGA in a CGA sub-option as shown in . The MN also includes any necessary SEND options (e.g., CGA parameters, RSA signature, Nonce, Timestamp, etc.) per while observing the updates discussed in . The RSA signature option MUST appear later in the IPv6 ND message options after the OMNI option so that the signature properly covers the CGA. The MN then sets the IPv6 source, destination and target (when present) to appropriate non-CGA addresses, and sends the message to the neighbor. When an initial bootstrapping exchange is required, the temporary LLA's statistical uniqueness properties allow for optimistic operation while the LLA-based CGA's uniqueness properties are irrelevant since it will never be used as an IPv6 packet header address. Following bootstrapping, the MN forms an MNP-based OMNI LLA and MNP-based CGA from its newly-obtained MNP and retains them for future IPv6 ND messaging. These addresses are assured to be unique within the domain, since the MNP is uniquely delegated to the MN. OMNI link ARs are assigned administrative OMNI LLAs that are guaranteed to be unique on the link, but they receive no MNPs of their own. Therefore, ARs will generate only LLA-based CGAs and use them for all SEND operations. While it is possible that two or more ARs may generate duplicate LLA-based CGAs, each AR will apply its own unique private key signature such that robust IPv6 ND message authentication is supported. For these reasons (and for the reasons explained for MNs above) no Duplicate Address Detection (DAD) testing of CGAs is necessary.

When an OMNI node receives an IPv6 ND message from a neighbor, if both the HMAC and SEND authentication services appear in the same message the node SHOULD process the SEND authentication credentials and ignore the HMAC credentials. If only one authentication service is present, the node SHOULD process the credentials according to the included service. If no authentication services are present (or, if the SEND service is present but the RSA signature option appears before the OMNI option) the node SHOULD regard the IPv6 ND message as unsecured. When the CGA sub-option is included in the OMNI option and the RSA signature option appears later in the IPv6 ND message options, the node verifies the signature per while observing the updates discussed in . In any case, if the IPv6 ND message includes an incorrect authentication code the node SHOULD discard the message.

Since their original publications, several important updates to the SEND and CGA specifications have been published and are observed as follows: defines a format for the CGA parameter data structure extension field. While no extensions are introduced in this document, any future updates to this document that introduce extensions MUST observe this format. introduces support for multiple hash algorithms in CGAs. The hash algorithm is identified by a value in the Sec bits of the CGA itself, which must be registered in the IANA "CGA SEC" registry. This document requests a new CGA SEC value "TBD2" for the SHA-256 hash algorithm (see: and ). defines a certificate profile that supersedes the profile for Router Authorization Certificates. Certificates used in SEND over OMNI interfaces MUST conform to this new certificate profile and MAY conform to the original profile. specifies Subject Key Identifier (SKI) Name Type Fields for SEND, which apply also to this document. analyzes the security implications of employing IPv6 fragmentation with IPv6 ND messages (especially with regards to SEND) and updates such that use of the IPv6 Fragmentation Header is forbidden in all ND messages. OMNI interfaces honor by employing the OMNI Adaptation Layer (OAL) to transport IPv6 ND messages no larger than the OMNI interface MTU without causing an IPv6 Fragmentation Header to appear within the IPv6 ND message itself.

IANA is instructed to allocate a new "OMNI option Sub-Type values" registry codepoint for the Cryptographically Generated Address (CGA) sub-option (value TBD). IANA is instructed to allocate a new "CGA SEC" registry codepoint for SHA-256 (value TBD2).

The OMNI specification provides an HMAC authentication service that can be used for basic client-server authentication based on shared secrets. The SEND service discussed in this document uses X.509 public keys which provide a more flexible and extensible security service, especially for use on large OMNI links that support a dynamically changing collection of many MNs. provides a hash threat analysis for SEND that concludes: "Current attacks on hash functions do not constitute any practical threat to the digital signatures used in SEND (both in the RSA signature option and in the X.509 certificates). Attacks on CGAs, as described in , will compromise the security of SEND and they need to be addressed by encoding the hash algorithm information into the CGA as specified in ." For this reason, implementations MUST use the SHA-256 hash algorithm for CGAs, as indicated by the value TBD2 appearing in the CGA Sec field (see: ). Future documents MAY specify additional hash algorithm values for the CGA Sec field. OMNI nodes assign CGAs to their OMNI interfaces but do not use them as IPv6 source, destination or target addresses, nor as node identifiers. Instead, OMNI nodes place the CGA in IPv6 ND message OMNI options, use non-CGA addresses for IPv6 packet addressing, and use purpose-built facilities such as Universally Unique IDentifiers (UUIDs) for node identification purposes.

This work is aligned with the NASA Safe Autonomous Systems Operation (SASO) program under NASA contract number NNA16BD84C. This work is aligned with the FAA as per the SE2025 contract number DTFAWA-15-D-00030. This work is aligned with the Boeing Commercial Airplanes (BCA) Internet of Things (IoT) and autonomy programs. This work is aligned with the Boeing Information Technology (BIT) MobileNet program.