Internet DRAFT - draft-templin-omni-send
draft-templin-omni-send
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: RFC3971 (if approved) January 22, 2021
Intended status: Standards Track
Expires: July 26, 2021
Secure NEighbor Discovery (SEND) over OMNI Interfaces
draft-templin-omni-send-03
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Templin Expires July 26, 2021 [Page 1]
Internet-Draft OMNI SEND January 2021
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SEND Over OMNI Interfaces . . . . . . . . . . . . . . . . . . 3
3.1. Processing Rules for Senders . . . . . . . . . . . . . . 4
3.2. Processing Rules for Receivers . . . . . . . . . . . . . 5
4. SEND/CGA Updates . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Using Host Identity Tags (HITs) with OMNI/SEND . . . 9
Appendix B. Using HIP-based Authentication Instead of SEND/CGA . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Overlay Multilink Network Interface (OMNI) specification
[I-D.templin-6man-omni-interface] can be used by nodes on public
Internetworks when a suitable security service is provided to
authenticate IPv6 Neighbor Discovery (IPv6 ND) control messages
[RFC4861][RFC8200]. 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 [RFC3971] and
Cryptographically Generated Addresses (CGA) [RFC3972] 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:
Templin Expires July 26, 2021 [Page 2]
Internet-Draft OMNI SEND January 2021
Section 5.1.1 of [RFC3971]) where it will be covered by the RSA
signature. Since OMNI interfaces use only non-CGA source and target
addresses, however, this specification updates [RFC3971] 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.
2. Terminology
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 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. SEND Over OMNI Interfaces
The HMAC-based authentication option specified in
[I-D.templin-6man-omni-interface] 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
[I-D.templin-6man-omni-interface]) formatted as follows:
Templin Expires July 26, 2021 [Page 3]
Internet-Draft OMNI SEND January 2021
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type=TBD | Sub-length=16 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Cryptographically-Generated Address (CGA) (128 bits) .
. .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Cryptographically-Generated Address (CGA) Sub-option
o Sub-Type is set to "TBD".
o Sub-Length is set to 16 (i.e., the length of the CGA).
o Cryptographically-Generated Address (CGA) is a 128 bit IPv6
address generated as specified in [RFC3972].
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
[RFC3971]). The processing rules for senders and receivers are
discussed in the following Sections.
3.1. Processing Rules for Senders
Per the OMNI specification [I-D.templin-6man-omni-interface], 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 Figure 1. The MN also includes
any necessary SEND options (e.g., CGA parameters, RSA signature,
Nonce, Timestamp, etc.) per [RFC3971] while observing the updates
discussed in Section 4. 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.
Templin Expires July 26, 2021 [Page 4]
Internet-Draft OMNI SEND January 2021
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.
3.2. Processing Rules for Receivers
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 [RFC3971] while observing the updates
discussed in Section 4. In any case, if the IPv6 ND message includes
an incorrect authentication code the node SHOULD discard the message.
4. SEND/CGA Updates
Since their original publications, several important updates to the
SEND [RFC3971] and CGA [RFC3972] specifications have been published
and are observed as follows:
o [RFC4581] 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.
Templin Expires July 26, 2021 [Page 5]
Internet-Draft OMNI SEND January 2021
o [RFC4982] 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: Section 5 and Section 6).
o [RFC6494] 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.
o [RFC6495] specifies Subject Key Identifier (SKI) Name Type Fields
for SEND, which apply also to this document.
o [RFC6980] analyzes the security implications of employing IPv6
fragmentation with IPv6 ND messages (especially with regards to
SEND) and updates [RFC4861] such that use of the IPv6
Fragmentation Header is forbidden in all ND messages. OMNI
interfaces honor [RFC6980] by employing the OMNI Adaptation Layer
(OAL) [I-D.templin-6man-omni-interface] 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.
5. IANA Considerations
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).
6. Security Considerations
The OMNI specification [I-D.templin-6man-omni-interface] 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.
[RFC6273] 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 [RFC4982], will compromise the security of SEND
Templin Expires July 26, 2021 [Page 6]
Internet-Draft OMNI SEND January 2021
and they need to be addressed by encoding the hash algorithm
information into the CGA as specified in [RFC4982]."
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: Section 5). 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 Universally Unique IDentifiers (UUIDs) [RFC4122][RFC6487] for
node identification purposes.
The series of consecutively-numbered RFCs beginning with [RFC6480]
and extending to [RFC6495] establishes standards and operational
practices for secure Internet routing. The series includes updates
cited in Section 4 that establish SEND as an integral component of
the architecture. OMNI interfaces that use SEND over public
Internetworks therefore observe these same principles.
7. Acknowledgements
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.
8. References
8.1. Normative References
[I-D.templin-6man-omni-interface]
Templin, F. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", draft-
templin-6man-omni-interface-68 (work in progress), January
2021.
Templin Expires July 26, 2021 [Page 7]
Internet-Draft OMNI SEND January 2021
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4581] Bagnulo, M. and J. Arkko, "Cryptographically Generated
Addresses (CGA) Extension Field Format", RFC 4581,
DOI 10.17487/RFC4581, October 2006,
<https://www.rfc-editor.org/info/rfc4581>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007,
<https://www.rfc-editor.org/info/rfc4982>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
Profile and Certificate Management for SEcure Neighbor
Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494,
February 2012, <https://www.rfc-editor.org/info/rfc6494>.
[RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key
Identifier (SKI) SEcure Neighbor Discovery (SEND) Name
Type Fields", RFC 6495, DOI 10.17487/RFC6495, February
2012, <https://www.rfc-editor.org/info/rfc6495>.
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation
with IPv6 Neighbor Discovery", RFC 6980,
DOI 10.17487/RFC6980, August 2013,
<https://www.rfc-editor.org/info/rfc6980>.
Templin Expires July 26, 2021 [Page 8]
Internet-Draft OMNI SEND January 2021
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
8.2. Informative References
[I-D.ietf-drip-rid]
Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"UAS Remote ID", draft-ietf-drip-rid-06 (work in
progress), December 2020.
[I-D.templin-duid-ipv6]
Templin, F., "The IPv6 Address-based DHCPv6 Unique
Identifier (DUID-V6ADDR)", draft-templin-duid-ipv6-01
(work in progress), January 2021.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>.
[RFC6273] Kukec, A., Krishnan, S., and S. Jiang, "The Secure
Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273,
DOI 10.17487/RFC6273, June 2011,
<https://www.rfc-editor.org/info/rfc6273>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
Appendix A. Using Host Identity Tags (HITs) with OMNI/SEND
Section 4 of [RFC3971] states:
"This specification also allows a node to use non-CGAs with
certificates that authorize their use. However, the details of
such use are beyond the scope of this specification and are left
for future work."
Templin Expires July 26, 2021 [Page 9]
Internet-Draft OMNI SEND January 2021
The Host Identity Tag (HIT) [RFC7401] is an example of a non-CGA that
is also obtained through a cryptographic hash of the node's public
key. HITs (and their derivatives known as "Hierarchical HITs"
[I-D.ietf-drip-rid]) have several important properties:
"The HIT is 128 bits long and has the following three key
properties: i) it is the same length as an IPv6 address and can be
used in fixed address-sized fields in APIs and protocols; ii) it
is self-certifying (i.e., given a HIT, it is computationally hard
to find a Host Identity key that matches the HIT); and iii) the
probability of a HIT collision between two hosts is very low;
hence, it is infeasible for an attacker to find a collision with a
HIT that is in use. [RFC7401]"
Should IETF consensus determine that (H)HITs represent a preferred
solution, the same mechanisms described for CGAs in this document can
be used to enable OMNI interface SEND security operations while using
(H)HITs. Namely, a new OMNI sub-option will be defined for the
purpose of carrying a 128-bit (H)HIT as the sub-option of an OMNI
option. The processing rules for senders and receivers specified in
Section 3 will be applied in the same fashion as for CGAs, with the
exception that the IPv6 ND CGA option which includes the node's
public key (and other information) will be associated with the (H)HIT
instead of with a CGA. Most importantly, the (H)HIT would be covered
under the RSA signature applied to the IPv6 ND message thereby
allowing receivers to verify proof of ownership.
Use of the (H)HIT as a node identifier can also be considered per
future IETF consensus determinations. If the IETF determines that an
(H)HIT can be used as a node identifier (i.e., instead of a UUID) the
specification of a new Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Device Unique IDentifier (DUID) type may be indicated (see:
[I-D.templin-duid-ipv6]).
Appendix B. Using HIP-based Authentication Instead of SEND/CGA
[RFC7401] specifies the Host Identity Protocol, version 2 (HIPv2) and
is intended as a comprehensive protocol suite which in many ways
overlaps with the intended use cases for OMNI. However, IPv6 ND
control messages over OMNI interfaces could be secured using selected
elements of [RFC7401] without incorporating all aspects of the
specification.
In particular, the HOST_ID and HIP_SIGNATURE parameters specified in
Sections 5.2.9 and 5.2.14 of [RFC7401] could be incorporated as new
sub-options of the OMNI option, and the SIGNATURE calculation and
verification procedures specified in Section 6.4 could be adapted for
Templin Expires July 26, 2021 [Page 10]
Internet-Draft OMNI SEND January 2021
signing IPv6 ND messages in the manner similar to that currently
prescribed by [RFC3971].
The [RFC7401] message authentication methods could therefore be used
with OMNI interfaces instead of employing SEND/CGA. Furthermore, the
(H)HIT could be used as an OMNI node identifier instead of a UUID as
discussed in the previous section.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires July 26, 2021 [Page 11]
