Network Working Group                                  L. Dunbar
Internet Draft                                          Futurewei
Intended status: Standards Track                     K. Majumdar
Expires: February 14, 2026                               Oracle
                                                      S. Fluhrer
                                                           Cisco

                                                  August 15, 2025


          Lightweight Authentication Methods for IP Header
          draft-dunbar-ipsecme-lightweight-authenticate-01

Abstract
   This document specifies a lightweight method for
   authenticating encapsulation headers, such as GENEVE, SRH,
   and UDP options, used to steer encrypted IPsec traffic across
   a Cloud Backbone, ensuring forwarding integrity without Cloud
   GWs decrypting the payloads.

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), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed
   at http://www.ietf.org/shadow.html

   This Internet-Draft will expire on Dec 14, 2020.



xxx, et al.           Expires February 14, 2026         [Page 1]

Internet-Draft Lightweight Header Authentication Methods


Copyright Notice

   Copyright (c) 2025 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
   (http://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 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..............................................3
   2. Conventions used in this document.........................3
   3. Use Cases.................................................4
      3.1. Multi-segment SD-WAN connected by Cloud Backbone.....4
      3.2. Metadata in UDP Authentication.......................5
   4. Header Authentication Methods Analysis....................5
   5. Encoding of Header Authentication Value...................6
      5.1. Analysis of HMAC Value...............................6
      5.2. Consideration in Generating the Authentication Value.7
      5.3. Authentication Value Encoding........................7
      5.4. Selective Packet Header Authentication...............8
   6. Authentication Key Distribution...........................8
      6.1. Key Distribution Via Secure Control Plane............9
      6.2. Key Distribution Via Secure Data Plane Tunnel........9
   7. Dynamic Authentication Policy Control.....................9
   8. Packet Loss Handling.....................................10
   9. Mechanism to Handle Replay...............................11
   10. Security Considerations.................................12
   11. Manageability Considerations............................13
   12. IANA Considerations.....................................13
   13. References..............................................13
      13.1. Normative References...............................13
      13.2. Informative References.............................14
   14. Acknowledgments.........................................15




Dunbar, et al.           Expires Dec 14, 2026            [Page 2]

Internet-Draft Lightweight Header Authentication Methods


1. Introduction
   The Multi-Segment SD-WAN architecture [MULTI-SEG-SDWAN]
   specifies an additional encapsulation header, such as GENEVE
   [RFC8926], outside the IPsec ESP header for Cloud Gateway
   (GW) to steer encrypted traffic through Cloud Backbone. Cloud
   GW forward packets based on these header fields without
   decrypting or re-encrypting the payload.
   Because the encapsulation header is not protected by ESP, it
   is susceptible to modification. Unauthorized changes can
   misroute traffic, bypass policy, or degrade service.
   Authenticating the encapsulation header ensures forwarding
   integrity and protects against such attacks.
   This document specifies a lightweight authentication method
   for encapsulation headers, minimizing computational cost
   while preserving security. The approach applies to GENEVE and
   Segment Routing Headers (SRH) [RFC8754] used in [MULTI-SEG-
   SDWAN], as well as UDP option headers [MEDIA-HDR-WIRELESS],
   [UDP-OPTION-HDR], and other encapsulation formats.
   By authenticating only the relevant outer-header fields,
   without decrypting the payload, these methods enable high-
   performance, secure packet steering between SD-WAN segments
   via the Cloud Backbone.

2. Conventions used in this document
   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 BCP14 [RFC2119] [RFC8174]
   when, and only when, they appear in all capitals, as shown
   here.

   The following acronyms and terms are used in this document:

   AES         Advanced Encryption Standard

   Cloud DC:   Off-Premises Data Center, managed by the third
               party, that hosts applications, services, and
               workload for different organizations or tenants.

   CPE:        Customer (Edge) Premises Equipment.


Dunbar, et al.           Expires Dec 14, 2026            [Page 3]

Internet-Draft Lightweight Header Authentication Methods


   OnPrem:     On Premises data centers and branch offices.

   RR          Route Reflector.

   SD-WAN      An overlay connectivity service that optimizes
               transport of IP Packets over one or more Underlay
               Connectivity Services by recognizing applications
               (Application Flows) and determining forwarding
               behavior by applying Policies to them. [MEF-70.1]

   VPN         Virtual Private Network.


3. Use Cases

3.1. Multi-segment SD-WAN connected by Cloud Backbone

   In [MULTI-SEG-SDWAN], GENEVE encapsulation is used to carry
   IPsec-encrypted packets between CPEs via Cloud GWs, enabling
   the Cloud Backbone to steer traffic without decrypting and
   re-encrypting payloads. To protect against malicious
   alteration of routing metadata, the GENEVE header in this
   encapsulation SHOULD be authenticated so that only authorized
   entities can modify or insert header information.
                    (^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^)
                    (             Cloud Backbone            )
                   (+-----+  +----+                  +-----+)
              + ---(|CEdge|==| GW1==================== GW2 |)
      Direct  |    (+-----+  +/--\+                  +--|--+)
     Connect  |    (^^^^^^^^/^^^^\^^^^^^^^^^^^^^^^^^^^^|^^^^)
            {-+---}        /      \                    |
            { VPN }       /        \                 +-----+
            {-+---}      /          IPsec Tunnel     |CPE10|
              +-------+-/--------+   \               +-----+
                      |/         |    \       192.0.2.128/25
                     ++---+      |  +--\-+ 198.51.100.128/25
                     |CPE1|      +--+CPE2|
                     +----+         +----+
       Client Route: 192.0.2.0/26      192.0.2.64/26
                     198.51.100.0/26   198.51.100.64/26
          Figure 1 Multi-Segment SD-WAN via Cloud Backbone




Dunbar, et al.           Expires Dec 14, 2026            [Page 4]

Internet-Draft Lightweight Header Authentication Methods


3.2. Metadata in UDP Authentication

   [MEDIA-HDR-WIRELESS] describes how metadata can be carried in
   a packet's UDP Option Header [UDP-OPTION-HDR] between
   wireless network nodes and application servers. While the IP
   packet payload is encrypted, the metadata in the UDP Option
   Header remains exposed in transit. Authenticating this
   metadata is essential to ensure its integrity and prevent
   unauthorized modification that could mislead application
   logic or disrupt service behavior.

          UDP payload + metadata      UDP payload + metadata
           +-------------------+     +---------------------+
          /                     \   /         _____         \
         /         _____         \ /         (     )         \
        /         (     )     +---V----+    (        )        \
   +---V----+    (Wireless)   |Wireless|   (    IP    )   +----o-----+
   | Client +---( Network  )--+  Node  +--(   Network  )--+  Server  |
   +--------+    (        )   +--------+   (          )   +----------+
   (UDP dest)     (_____)                   (       )     (UDP source)
                                             (_____)
            Wireless Provider                             App Provider
       |------------------------|                       |-------------|

        Figure 2: Media Payload and Metadata in UDP Packet

   The authentication described here focuses specifically on the
   metadata carried in the UDP Option Header, rather than the
   entire packet payload. This differs from Section 11.9
   (Authentication) of [UDP-OPTION-HDR], which applies
   authentication to the full payload. Since the user payload is
   already encrypted, authenticating it again is unnecessary;
   protecting the appended metadata alone is sufficient to
   ensure integrity. The method proposed in this document is
   intentionally lightweight, targeting only the appended
   metadata to reduce processing overhead while still ensuring
   its integrity.

4. Header Authentication Methods Analysis

   Several methods can be used to authenticate encapsulation
   headers without processing the entire packet payload. The
   choice depends on balancing security strength, processing
   overhead, and deployment complexity.





Dunbar, et al.           Expires Dec 14, 2026            [Page 5]

Internet-Draft Lightweight Header Authentication Methods


     - HMAC-based authentication provides strong integrity
       protection and is widely supported. It requires a shared
       key between endpoints and introduces additional bytes in
       each packet but offers a good security-performance trade-
       off.

     - Lightweight checksums (e.g., CRC or Fletcher) offer
       minimal overhead but do not protect against intentional
       tampering and are only suitable for environments with low
       security risk.

     - Digital signatures ensure strong, non-repudiable
       integrity but add significant computational cost and
       packet size, making them impractical for high-throughput
       scenarios.

     - Reuse of existing security associations-for example,
       using keys already established for IPsec tunnels-reduces
       key distribution complexity and avoids additional
       negotiation steps.

   The methods described here are intended for authenticating
   only the encapsulation header (e.g., GENEVE, SRH, UDP Option)
   while leaving the already-encrypted payload untouched. This
   targeted authentication reduces processing overhead compared
   to full-packet authentication, while still preventing
   tampering with critical steering or metadata information.

5. Encoding of Header Authentication Value

5.1. Analysis of HMAC Value

   While a 32-byte HMAC value is recommended for strong security
   [NIST-SP-800-107], appending this to every packet can
   increase the packet size enough to cause MTU exceedance,
   fragmentation, and higher transmission overhead.

   A practical compromise is to use a shorter HMAC, such as 4
   bytes (32 bits) or 8 bytes (64 bits), when the primary goal
   is integrity and authenticity verification without heavy
   performance impact. Truncating the HMAC conserves bandwidth,
   reduces processing time, and is especially beneficial in
   high-speed or resource-constrained environments.



Dunbar, et al.           Expires Dec 14, 2026            [Page 6]

Internet-Draft Lightweight Header Authentication Methods


   As noted in [RFC2104], authentication tags may be truncated
   (e.g., to 128 bits or less) to balance security with
   efficiency. While shorter tags reduce the cryptographic
   strength compared to full-length values, they can still
   provide adequate protection against common threats in the
   intended use cases.

5.2. Consideration in Generating the Authentication Value

   HMAC-SHA-256 [RFC4868] [RFC6234] produces a 32-byte (256-bit)
   output by default. For scenarios requiring shorter
   authentication values, such as 4 bytes (32 bits) or 8 bytes
   (64 bits), the following methods can be used:

     - Direct Truncation: Select the first n bytes from the HMAC
       output. This is simple, efficient, and the approach
       recommended by [RFC2104].
     - Secondary Hash: Apply a separate hash function to the
       full 32-byte HMAC output to derive the desired shorter
       value.

   Direct truncation is generally preferred for its simplicity
   and minimal processing overhead, especially in high-speed or
   resource-constrained environments.

5.3. Authentication Value Encoding

   The HMAC-Auth-VAL Sub-TLV carries the HMAC authentication
   value used to validate the encapsulation header. It MUST be
   the last Sub-TLV in the encapsulation header. The HMAC is
   computed over the entire encapsulation header excluding the
   HMAC-Auth-VAL Sub-TLV itself, using a pre-configured
   algorithm:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | HMAC-Auth-Val | length        | K |Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                  HMAC Authentication Value                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Figure 3 HMAC Sub-TLV

     - HMAC-Auth-Val (8 bits): Type value = 6 (assigned by
       [MULTI-SEG-SDWAN]).



Dunbar, et al.           Expires Dec 14, 2026            [Page 7]

Internet-Draft Lightweight Header Authentication Methods


     - Length (8 bits): Total length of the Value field,
       excluding the Type and Length fields. This is equal to
       the HMAC length plus 2 reserved bytes. Default is 6
       bytes, but longer values may be used in deployments with
       higher security requirements.
     - K Flag (2 bits): Index of the key used for HMAC
       calculation, enabling key rotation and management. The
       key set is pre-shared and agreed upon between sender and
       receiver.
     - HMAC Authentication Value: The computed HMAC output,
       based on the encapsulation header (excluding this Sub-
       TLV).

5.4. Selective Packet Header Authentication

   Selective Packet Header Authentication (SPHA) enables
   receiving nodes to authenticate only a subset of flows, as
   determined by control-plane instructions from a controller or
   management system. Every packet includes an Authentication
   TLV in its encapsulation header, but only packets of
   selective flows carry a genuine authentication value; others
   contain dummy values. This design ensures that an observer
   cannot distinguish which packets are actually authenticated,
   reducing the risk of targeted tampering.

   The metadata in each GENEVE or other encapsulation header is
   always valid and current. The control plane determines the
   authentication frequency, or which flows to be authenticated.
   On receipt, nodes verify only the packets of designated flows
   according to pre-configured policy, thereby reducing
   processing load while maintaining protection against header
   manipulation.

   SPHA is particularly valuable in environments where
   authenticating every packet header is computationally
   expensive, such as on resource-constrained devices. It
   optimizes the balance between security and performance,
   ensuring that the integrity of critical flows is protected
   without imposing unnecessary overhead on all traffic.

6. Authentication Key Distribution

   The lightweight authentication methods in this document apply
   to environments where IPsec tunnels connect SD-WAN CPEs to
   Cloud GWs. When traffic from a CPE is destined for services


Dunbar, et al.           Expires Dec 14, 2026            [Page 8]

Internet-Draft Lightweight Header Authentication Methods


   in the Cloud Data Center, the Cloud GW decrypts the IPsec
   traffic. When traffic is routed through the Cloud Backbone to
   reach remote CPEs, the lightweight authentication method is
   applied without decryption at the Cloud GWs.

6.1. Key Distribution Via Secure Control Plane

   When a secure control channel exists-such as between two
   organizations for interconnection, or between a network
   controller and its CPEs-authentication keys can be exchanged
   over this channel.

   Pre-shared keys are preferred for their simplicity and
   efficiency. For deployments requiring stronger security, keys
   should be generated using a cryptographically secure random
   number generator to avoid predictability, and key lifetimes
   should be kept short.

   In a [MULTI-SEG-SDWAN] environment, the Cloud Controller can
   own the authentication keys and securely distribute them,
   such as via TLS, to the enterprise's SD-WAN controller. In a
   [MEDIA-HDR-WIRELESS] environment, the application controller
   can similarly distribute keys securely to the wireless
   provider's controller or management system.

   To maintain ongoing security, keys should be rotated
   periodically, and versioning information should be included
   so both ends always use the correct and current keys.

6.2. Key Distribution Via Secure Data Plane Tunnel

   In environments where IPsec tunnels connect SD-WAN CPEs to
   Cloud GWs, the IPsec tunnel itself provides a secure channel
   for transmitting authentication keys, protecting them from
   eavesdropping or tampering during distribution.

   The existing IPsec session keys can also serve as input to a
   key derivation function (KDF), producing dedicated
   authentication keys that are cryptographically linked to the
   IPsec keys but never directly exposed. This approach ensures
   both strong security and operational efficiency by leveraging
   already-established secure channels.

7. Dynamic Authentication Policy Control

   The selection and frequency of flows to be fully
   authenticated are determined by the network controller


Dunbar, et al.           Expires Dec 14, 2026            [Page 9]

Internet-Draft Lightweight Header Authentication Methods


   through a secure management channel with the edge nodes. This
   policy can target specific flows or, for example, only the
   first packet of those flows.

   When a network segment is deemed at higher risk of security
   threats, such as man-in-the-middle (MITM) attacks, the
   controller can dynamically adjust the policy to:

   -  Increase the proportion of flows subject to full
   authentication.

   -  Apply additional header encryption between CPEs and Cloud
   GWs.

   -  Use stronger encryption algorithms (e.g., AES-256).

   The secure management channel enables real-time adaptation to
   changing network conditions and threat levels, ensuring that
   authentication remains both efficient and effective. By
   adjusting authentication scope and strength as needed, the
   system can detect and deter malicious attempts to inject or
   manipulate traffic, maintaining the integrity of the data
   flow.

8. Packet Loss Handling

   In environments using Selective Packet Header Authentication
   (SPHA), packet loss can reduce the number of authenticated
   packets available for integrity verification, which may
   temporarily weaken header-tampering detection. In non-SPHA
   deployments where every packet is authenticated, loss
   directly impacts both integrity verification and delivery
   reliability.

   Therefore, mechanisms to mitigate the effects of packet loss
   are important in both SPHA and non-SPHA environments, but are
   especially critical in SPHA when authentication frequency is
   already reduced.

   Mitigation Techniques

   Several complementary methods can be applied to minimize the
   security and operational impact of lost packets:

   -  Retransmission Requests: Allow receivers to securely
   request retransmission of lost packets that were expected to
   carry valid authentication data.


Dunbar, et al.           Expires Dec 14, 2026           [Page 10]

Internet-Draft Lightweight Header Authentication Methods


   -  Forward Error Correction (FEC): Send additional error-
   correcting codes to enable reconstruction of lost packets
   without retransmission, which is useful in high-latency or
   unreliable networks.

   -  Sequence Numbering: Assign sequence numbers to all packets
   so that missing packets can be detected quickly and trigger
   alerts or retransmissions.

   -  Heartbeat Messages: Periodically send control or status
   packets summarizing authenticated packet sequences to speed
   loss detection.

   -  Multi-Path Transmission: Transmit duplicates of critical
   packets over multiple network paths to increase delivery
   success probability.

   -  Adaptive Authentication Thresholds: Dynamically increase
   authentication frequency when packet loss is detected,
   ensuring enough authenticated packets reach the receiver to
   maintain integrity guarantees.

   -  Time-based Reconciliation: Periodically compare packet
   headers received over a given interval to identify gaps and
   detect possible tampering.

   Each of these methods can be tailored to fit the specific
   needs and constraints of the network, allowing for an
   effective balance between security, performance, and
   reliability in the face of packet loss challenges.

9. Mechanism to Handle Replay

   Replay attacks-where an attacker resends previously captured
   packets to disrupt or mislead the network-must be addressed
   in both SPHA and non-SPHA environments, but the mitigation
   approach differs.

   In non-SPHA environments, where every packet is
   authenticated, replay protection is typically implemented
   using per-packet identifiers such as sequence numbers,
   nonces, or timestamps. This makes detecting and rejecting
   replays straightforward, provided the anti-replay window and
   state tracking are properly managed.

   In SPHA environments, where authentication is applied to
   selected flows rather than every packet, replay protection


Dunbar, et al.           Expires Dec 14, 2026           [Page 11]

Internet-Draft Lightweight Header Authentication Methods


   must still ensure that packets within authenticated flows are
   uniquely identifiable and time-bound. Without this, attackers
   could replay unauthenticated packets from an existing flow or
   reuse authenticated packets within the replay window. Flow-
   level authentication therefore requires supplemental
   measures, such as per-packet sequence numbers or timestamps,
   to maintain protection against replays.

   Common techniques for mitigating replay attacks include:

   -  Sequence Numbers: Ensure each packet has a monotonically
   increasing identifier to detect duplicates or out-of-order
   arrivals.

   -  Nonce Values: Add unpredictable values to each packet to
   guarantee freshness.

   -  Session Keys with Rotation: Change keys periodically so
   captured packets cannot be reused after a key update.

   -  Packet Expiry Information: Set validity windows so old
   packets are automatically rejected.

   -  Stateful Inspection: Maintain connection state to identify
   packets that fall outside expected patterns.

   These measures, used individually or in combination, ensure
   that replay attempts are detected and blocked, preserving the
   integrity of both SPHA and non-SPHA deployments.

10. Security Considerations

   The effectiveness of HMAC-based authentication depends on the
   strength of the shared key, the robustness of the hash
   algorithm, and sound key management practices. Deployments
   should select algorithms and key lifetimes that match their
   specific security requirements.

   While a 32-bit signature can reduce processing and bandwidth
   overhead, especially valuable in resource-constrained
   environments, it provides lower cryptographic strength.
   Operators must evaluate whether this trade-off meets their
   risk tolerance.

   For environments concerned about possible HMAC key
   compromise, an additional integrity layer such as IPsec AH


Dunbar, et al.           Expires Dec 14, 2026           [Page 12]

Internet-Draft Lightweight Header Authentication Methods


   [RFC4301] or ESP-NULL [RFC2410][RFC6071] may be applied on
   top of existing IPsec encryption between CPEs. These methods
   require pairwise IPsec key management between Cloud GWs and
   CPEs and introduce additional processing load. AH also has
   the limitation of being incompatible with NAT traversal due
   to changes in outer IP headers.

11. Manageability Considerations

   Effective management of HMAC key configurations between SD-
   WAN edges and Cloud GWs is critical for maintaining
   authentication consistency. The management system must
   support secure key generation, protected distribution, and
   periodic key rotation. It should also include clear
   procedures for rapid key revocation and replacement in the
   event of compromise or other security incidents, ensuring
   minimal disruption to operations.

12. IANA Considerations

   This document makes no IANA requests. It reuses the HMAC-
   Auth-Val Sub-TLV Type defined in [MULTI.SEG.SDWAN].




13. References


13.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2403] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within
             ESP and AH", RFC2403, Nov. 1998.

   [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96
             within ESP and AH", RFC2404, Nov. 1998.

   [RFC4301] S. Kent and K. Seo, "Security Architecture for the
             Internet Protocol", RFC4301, Dec. 2005.




Dunbar, et al.           Expires Dec 14, 2026           [Page 13]

Internet-Draft Lightweight Header Authentication Methods


   [RFC4303] S. Kent, "IP Encapsulating Security Payload (ESP)".
             RFC4303, Dec. 2005.

   [RFC4868] S. Kelly , S. Frankel, "Using HMAC-SHA-256, HMAC-
             SHA-384, and HMAC-SHA-512 with IPsec", RFC4868, May
             2007.

   [RFC5424] R. Gerhards, "The Syslog Protocol", RFC5424, March
             2009.

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

   [RFC8926] J. Gross, et al, "Geneve: Generic Network
             Virtualization Encapsulation", RFC8926, Nov 2020.


13.2. Informative References

   [RFC2104] H. Krawczyk, et al, "HMAC: Keyed-Hashing for
             Message Authentication", RFC2104, Feb. 1997.

   [MULTI-SEG-SDWAN] K. Majumdar, et al, "Multi-segment SD-WAN
             via Cloud DCs", draft-ietf-rtgwg-multisegment-
             sdwan-02, Feb, 2025.

   [NIST-SP-800-107] National Institute of Standards and
             Technology (NIST) Special Publication 800-107
             Revision 1, "Recommendation for Applications Using
             Approved Hash Algorithms".

   [NIST-AES-GCM] National Institute of Standards and Technology
             (NIST) Special Publication 800-38D, "Recommendation
             for Block Cipher Modes of Operation: Galois/Counter
             Mode (GCM) and GMAC", Nov. 2007.

   [RFC2410] R. Glenn and S. Kent, "The NULL encryption
             Algorithm and Its Use with IPsec", RFC2310, Nov.
             1998.


Dunbar, et al.           Expires Dec 14, 2026           [Page 14]

Internet-Draft Lightweight Header Authentication Methods


   [RFC4493] T, Iwata, et al, "The AES-CMAC Algorithm", RFC4493,
             June 2006.

   [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec)
             and Internet Key Exchange (IKE) Document Roadmap",
             Feb. 2011.

   [RFC6234] D. Eastlake and T. Hansen, "US Secure Hash
             Algorithms", RFC6234, May 2011.

   [MEDIA-HDR-WIRELESS] J. Kaippallimalil, et al, "Media Header
             Extensions for Wireless Networks", draft-
             kaippallimalil-tsvwg-media-hdr-wireless-05, Aug
             2024.

   [MEF-70.1] MEF 70.1 SD-WAN Service Attributes and Service
             Framework. Nov. 2021.

   [UDP-OPTION-HDR] J Touch, "Transport Options for UDP", draft-
             ietf-tsvwg-udp-options-28, Nov. 2023.

14. Acknowledgments

   Acknowledgements to Russ Housley, Paul Wouters, and Scott
   Fluhrer for their review, questions, and suggestions.

   This document was prepared using 2-Word-v2.0.template.dot.

















Dunbar, et al.           Expires Dec 14, 2026           [Page 15]

Internet-Draft Lightweight Header Authentication Methods


Authors' Addresses


   Linda Dunbar
   Futurewei
   Email: ldunbar@futurewei.com

   Kausik Majumdar
   Oracle
   Email: kausik.majumdar@oracle.com

   Scott Fluhrer
   Cisco
   Email: sfluhrer@cisco.com

Contributors' Addresses































Dunbar, et al.           Expires Dec 14, 2026           [Page 16]

