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