Skip to main content

Secure NEighbor Discovery (SEND) over OMNI Interfaces
draft-templin-omni-send-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Fred Templin
Last updated 2021-01-20
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-templin-omni-send-01
Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: RFC3971 (if approved)                          January 20, 2021
Intended status: Standards Track
Expires: July 24, 2021

         Secure NEighbor Discovery (SEND) over OMNI Interfaces
                       draft-templin-omni-send-01

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 24, 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 24, 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
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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:
   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

Templin                   Expires July 24, 2021                 [Page 2]
Internet-Draft                  OMNI SEND                   January 2021

   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 24, 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 24, 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 24, 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 24, 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 24, 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 24, 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

   [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>.

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 24, 2021                 [Page 9]