Network Working Group L. Dunbar Internet Draft Futurewei Intended status: Informational Expires: December 26, 2024 June 26, 2024 Lightweight Methods for Authenticating IP Header draft-dunbar-secdispatch-ligthtweight-authenticate-00 Abstract This document describes lightweight authentication methods to prevent malicious actors tampering with the IP encapsulation headers or metadata carried by the UPD Option Header. 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 25, 2024. xxx, et al. Expires December 26, 2024 [Page 1] Internet-Draft Lightweight Header Authentication Methods Copyright Notice Copyright (c) 2024 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 4.1. Justification for Header Authentication..............5 4.2. HMAC-Based Authentication Method.....................6 4.3. Digital Signatures...................................7 5. Encoding of HMAC and Digital Signature Value..............8 5.1. Analysis of HMAC and Digital Signature Value.........8 5.2. Consideration in Generating the Authentication Value .........................................................10 5.3. Authentication Value Encoding.......................10 5.4. Selective Packet Header Authentication..............11 6. Control Plane Mechanism..................................12 7. Frames Loss Handling.....................................13 8. Mechanism to Handle Replay...............................14 9. Key Distribution.........................................16 10. Security Considerations.................................17 11. Manageability Considerations............................17 12. IANA Considerations.....................................18 13. References..............................................18 13.1. Normative References...............................18 13.2. Informative References.............................19 14. Acknowledgments.........................................20 Dunbar, et al. Expires Dec 26, 2024 [Page 2] Internet-Draft Lightweight Header Authentication Methods 1. Introduction [MULTI-SEG-SDWAN] describes scenarios and methods where an additional header (GENEVE Encapsulation [RFC8926]) is added to the encrypted payload to steer packets through underlay networks. In these scenarios, the underlay network edge nodes do not decrypt and re-encrypt the payloads. The header information is used for optimizing packet forwarding in underlay networks and, therefore, resides outside the IPsec ESP header. Authenticating these additional headers is important in certain environments to prevent malicious actors from tampering with header information. This document outlines lightweight methods to authenticate encapsulation headers, aiming to reduce the computational resources needed for this process while ensuring security. These methods can be applied to authenticate GENEVE and SRH headers used by [Multi-SEG-SDWAN], [SECURE-SRV6], UDP option headers [MEDIA-HDR-WIRELESS], [UDP-OPTION-HDR], and other encapsulation headers. 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: 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. OnPrem: On Premises data centers and branch offices. RR Route Reflector. Dunbar, et al. Expires Dec 26, 2024 [Page 3] Internet-Draft Lightweight Header Authentication Methods 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 [MULTI-SEG-SDWAN] describes the method of using GENEVE Header to encapsulate the IPsec encrypted packets for Cloud GW to steer the packets through the Cloud backbone without the Cloud GWs to decrypt and re-encrypt the payload, as shown in the figure below. It is necessary to authenticate the GENEVE Header to prevent anyone from tampering with the information in the GENEVE header. (^^^^^^^^^^^^^^^) ( Cloud ) ( +----+ +----+ ) +-----+ + ---(-|Edge|==| GW1|================= GW2 | Direct | ( +----+ +/--\+ ) +--|--+ Connect | (^^^^^^^/^^^^\^) | {-+---} / \ | { VPN } / \ +-----+ {-+---} / IPsec Tunnel |CPE10| +-------+--/--------+ \ +-----+ | / | \ 10.2.1.x ++/--+ | +\---+ 20.2.1.x |CPE1| +----+CPE2| 30.2.1.x +----+ +----+ Client Route: 11.1.1.x 10.1.1.x 21.1.1.x 20.1.1.x 30.1.1.x Figure 1 Multi-Segment SD-WAN via Cloud Backbone Dunbar, et al. Expires Dec 26, 2024 [Page 4] Internet-Draft Lightweight Header Authentication Methods 3.2. Metadata in UDP Authentication [MEDIA-HDR-WIRELESS] describes the scenario and method of carrying metadata in a packet's UDP Option Header [UDP- OPTION-HDR] between wireless network nodes and the application servers. The IP packet payload is already encrypted. It is necessary to authenticate the metadata to prevent anyone from tampering with it. UDP payload + metadata UDP payload + metadata +-------------------+ +----------------------+ / \ / _____ \ / _____ \ / ( ) \ / ( ) +---V----+ ( ) \ +---V----+ (Wireless) |Wireless| ( IP ) +----o-----+ | Client +---( Network )--+ Node +--( Network )---+ Server | +--------+ ( ) +--------+ ( ) +----------+ (UDP dest) (_____) ( ) (UDP source) (_____) Wireless Provider Application Provider |------------------------| |-------------| Figure 2: Media Payload and Metadata in UDP Packet The described header authentication focuses solely on authenticating the appended metadata in the UDP Option Header. This approach differs from Section 11.9 (Authentication) of [UDP-OPTION-HDR], which authenticates the entire payload. It's important to note that the authentication method outlined in this document is designed to be lightweight. 4. Header Authentication Methods Analysis 4.1. Justification for Header Authentication Authenticating IP packet encapsulation headers is essential for safeguarding against a variety of malicious activities, in particular: Integrity Assurance: Tamper Detection: Any unauthorized modification or tampering of the headers can be detected, indicating potential malicious activity. Security in Overlay Networks: Dunbar, et al. Expires Dec 26, 2024 [Page 5] Internet-Draft Lightweight Header Authentication Methods Overlay Network Protection: GENEVE or VXLAN are commonly used in overlay networks, where security is paramount. Authenticating encapsulation headers helps secure the overlay network by preventing attackers from manipulating routing information or injecting malicious packets into the network. Preventing Spoofing and Injection Attacks: Source Address Verification: Authentication ensures that the source address in the encapsulation header is genuine. This helps prevent address spoofing, ensuring that the sender's identity is verified and not manipulated by malicious actors attempting to inject unauthorized traffic. Protection Against Man-in-the-Middle Attacks: Routing Manipulation Prevention: In the case of SRv6, which involves source routing, authenticating headers prevents unauthorized changes to the routing information. This guards against man-in-the-middle attacks where an attacker could alter the routing path of the packet. Preventing Denial-of-Service (DoS) Attacks: Header Flooding Protection: Authentication adds a layer of protection against DoS attacks that flood the network with manipulated or maliciously crafted encapsulation headers. By verifying the authenticity of headers, the network can reject unauthorized or suspicious traffic. 4.2. HMAC-Based Authentication Method A lightweight method to authenticate and ensure the integrity of IP encapsulation packet headers, like GENEVE or UDP Option Header, can be achieved using HMAC (Hash-based Message Authentication Code) and a shared secret key. HMAC using the SHA-256 hash function defined in [RFC 4868]. [RFC 2104] describes the general construction of HMAC and guides its use. Here's are the steps: Key Establishment: Need a secure channel for network edges to share a secret key. This could be done manual configuration or through a secure key exchange protocol. Additional Header Field: Dunbar, et al. Expires Dec 26, 2024 [Page 6] Internet-Draft Lightweight Header Authentication Methods Need to add a new field in the packet header, e.g., "HMAC- Auth-Val" field, to store the HMAC value. Before sending the packet, the edge node computes the HMAC of the entire header (excluding the HMAC-Auth-Val field) using the shared secret key. Authentication Process: When a packet is received, the recipient recalculates the HMAC of the received header using the shared key. Compare the computed HMAC with the value in the received "HMAC-Auth-Val" field. If the values match, the header is considered authentic and has not been tampered with. This method provides a lightweight approach for ensuring the authenticity and integrity of IP encapsulation packet headers without adding significant overhead. 4.3. Digital Signatures Using digital signatures to authenticate encapsulation headers for IP packets involves asymmetric cryptography and public-private key pairs. Below are the detailed procedures: Key Generation: Generate a key pair for digital signatures: - Private Key: Kept secret by the entity generating the signature. - Public Key: Shared with entities that need to verify the signature. Digital Signature Generation: When a sender wants to send an IP packet with an authenticated header, it performs the following steps: - Hash the IP packet header using a cryptographic hash function (e.g., SHA-256) to create a message digest. - Encrypt the message digest using the sender's private key to create the digital signature. - Append the digital signature to the IP packet header. Need a new type to indicate additional field that hold the digital signature value. Digital Signature Verification: When the receiver receives the IP packet, it performs the following steps to verify the digital signature: Dunbar, et al. Expires Dec 26, 2024 [Page 7] Internet-Draft Lightweight Header Authentication Methods - Extract the digital signature from the received IP packet. - Decrypt the digital signature using the sender's public key to obtain the original message digest. - Recalculate the hash of the received IP packet header using the same cryptographic hash function. - Compare the recalculated hash with the decrypted message digest. If they match, the signature is valid. Trust in Public Key: The receiver must have a trusted copy of the sender's public key. This could be obtained through a public key infrastructure (PKI) or a secure out-of-band communication channel. 5. Encoding of HMAC and Digital Signature Value 5.1. Analysis of HMAC and Digital Signature Value While the ideal HMAC or Digital Signature value size might be 32 bytes for robust security [NIST-SP-800-107], adding an extra 32 bytes to each IP packet can significantly impact the overall packet size, potentially leading to exceeding the underlay network' MTU (Maximum Transmission Unit), fragmentation, and increased transmission overhead. To address this challenge, a judicious compromise can be made by employing a smaller, yet still secure, shorter HMAC size, such as 4 bytes (32 bits), 8 bytes (64 bits), or 12 bytes (96 bits) can be considered to append the packet header (or UDP Option Header). Although a shorter HMAC value offers a reduced cryptographic strength compared to larger alternatives, it can still provide a reasonable level of security for the use cases in consideration. The trade-off between security and efficiency becomes particularly relevant in scenarios where network resources are constrained, and the need to minimize packet size and transmission latency is imperative. The choice of 4 bytes (8 bytes, or 12 bytes) HMAC authentication value is pragmatic, striking a balance between ensuring data integrity and authenticity while mitigating the impact on network performance. This approach enables the implementation of effective security measures within the confines of the underlay network limitations. Dunbar, et al. Expires Dec 26, 2024 [Page 8] Internet-Draft Lightweight Header Authentication Methods Appendix C of the [NIST-AES-GCM] offers some considerations when using a shorter authentication tag. In particular, here are some pros and cons of choosing a shorter HMAC or Digital Value size: Advantages: Reduced Overhead: reduces the overhead of the data packet size, conserving bandwidth and storage space. Efficiency in Processing: Smaller signature values require less computation time for both generation and verification. This can be advantageous in resource-constrained environments or scenarios where rapid processing and low latency are crucial. Less Computational Load: Verifying smaller signatures generally requires less computational load, making it suitable for devices with limited processing capabilities. Disadvantages: Security Concerns: The primary drawback of using a shorter authentication value is the reduced cryptographic strength and security compared to larger signatures. Smaller signature sizes are more susceptible to brute-force attacks, increasing the risk of successful forgery. Collision Risk: A shorter authentication tag increases the probability of collision (two different inputs producing the same signature). This compromises the uniqueness and integrity assurances provided by the signature. Conclusion: While a shorter signature offers efficiency advantages, especially in resource-constrained environments, it comes with security trade-offs. It is essential to carefully consider the specific security requirements of the deployment to assess whether the reduced security strength is acceptable. Dunbar, et al. Expires Dec 26, 2024 [Page 9] Internet-Draft Lightweight Header Authentication Methods 5.2. Consideration in Generating the Authentication Value HMAC-SHA-256 [RFC4868] [RFC6234] produces a 32-byte (256-bit) output by default. Here are some methods to generate a 4-byte (32-bit) or 8-byte (64-bits) HMAC value, - Apply another hash function on the 32 bytes value from the HMAC-SHA-256. 5.3. Authentication Value Encoding Two Sub-TLVs are specified in this section: HMAC-Auth-VAL Sub-TLV and Digital-Sig Sub-TLV. Only one of them needs to be appended to the IP header for the header authentication purpose. The HMAC Sub-TLV is to carry the HMAC authentication value. The HMAC Sub-TLV must be appended as the last Sub-TLV in the encapsulation header. The entire encapsulation header, excluding the HMAC Sub-TLV, is included in computing the HMAC authentication value based on the pre-configured algorithm. The detailed Sub-TLV is specified below: 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | HMAC Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 HMAC Sub-TLV HMAC-Auth-Val: HMAC Authentication Value Type, to be assigned by IANA. Length: total length of the value field, which is the length of the HMAC Authentication Value plus 2 Reserved bytes. It is 6 bytes by default. However, in some deployments where security requirements are high, a longer authentication value can be considered. HMAC Authentication Value: The entire encapsulation header, excluding the HMAC Sub-TLV, are included in computing the HMAC authentication value based on the pre-configured algorithm. See Section 5.2 for the consideration in computing the HMAC Authentication Value. Dunbar, et al. Expires Dec 26, 2024 [Page 10] Internet-Draft Lightweight Header Authentication Methods The Digital-Sig Sub-TLV is to carry the Digital Signature value. The Digital-Sig Sub-TLV must be appended as the last Sub-TLV in the encapsulation header. The entire encapsulation header, excluding the Digital-Sig Sub-TLV, is included in computing the Digital Signature value based on the pre- configured algorithm. The detailed Sub-TLV is specified below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Digital-Sig | length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Digital Signature Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Digital-Sig Sub-TLV Digital-Sig: Digital Signature Value Type, to be assigned by IANA. Length: the total length of the Digital Signature Value plus 2. It is 6 bytes by default. However, in some deployments where security requirements are high, a longer authentication value can be considered. Digital Signature Value: Digital Signature value is computed using the entire encapsulation header, excluding the Digital- Sig Sub-TLV, based on the pre-configured algorithm. See Section 5.2 for the consideration in computing the 4-Byte (or 8-Byte) Digital Signature Value. 5.4. Selective Packet Header Authentication Selective Packet Header Authentication (SPHA) employs a strategic method, where receiving nodes selectively authenticate a subset of packets, guided by control messages from their controller or management systems. Each packet features an Authentication Type-Length-Value (TLV), but only specific packets or flows undergo full authentication. Authenticated packets contain a genuine authentication value in the TLV Value field of the encapsulation header, while others hold dummy authentication values. However, it should be noted that the metadata itself in each GENEVE or other encapsulation is actual/new information. The control plane determines the frequency of authentication or selective flows Dunbar, et al. Expires Dec 26, 2024 [Page 11] Internet-Draft Lightweight Header Authentication Methods for authentication, and the presence of an Authentication TLV on every packet conceals which packets are authentically validated. This obfuscation enhances security by preventing intermediaries from tampering with or identifying the authentic authentication values. On the receiving end, nodes verify the authentication of headers based on a pre-configured policy, choosing only specific packets or flows for authentication. This method of selectively applying authentication effectively balances security with operational efficiency. It optimizes resource usage while maintaining robust protection against header manipulation, making it an economical choice for securing network traffic against man-in-the-middle attacks. Furthermore, for packets that are not authenticated, the receiver can still monitor for integrity by comparing their headers, such as the flow identifier, with those of authenticated packets. This comparison helps detect unauthorized modifications, even if the packet itself was not authenticated. This selective authentication method is particularly beneficial in environments where the computational cost of authenticating every packet header is prohibitively high, such as on small IoT devices. Moreover, in contexts where packet payloads are already encrypted, the main concern shifts to ensuring the integrity of the packet headers. The use of HMAC or Digital-Sig Sub-TLVs in SPHA provides a robust measure against header tampering by potential malicious intermediaries, thereby maintaining the integrity of packet headers. Overall, SPHA offers a sophisticated and dynamic approach to packet authentication, effectively balancing security with efficiency and scalability. 6. Control Plane Mechanism The configuration for the frequency and selection of packets or flows that undergo real authentication is managed through a secure management channel between edge nodes and the network controller. Options include: - Specific flows, Dunbar, et al. Expires Dec 26, 2024 [Page 12] Internet-Draft Lightweight Header Authentication Methods - the first packet of specific flows or every 'N' packets. When a network segment is detected to have a higher than usual probability of security risks, such as man-in-the- middle (MITM) attacks, several actions can be taken to mitigate these risks. For example: - Increase the frequency of packets or flows to be fully authenticated, - Move towards comprehensive authentication where all packet headers are authenticated, rather than just selective flows. - Adding another layer of encryption for the header between CPEs and Cloud GWs, - Use Stronger Encryption Algorithms: Ensure that the encryption algorithms used for securing data are strong (e.g., AES-256) The secure management channel facilitates dynamic adjustments to the authentication process, accommodating varying network conditions and security needs efficiently. This approach also enhances security by enabling the detection of malicious actors injecting traffic into the flow. This capability not only ensures the integrity and security of data flow but also acts as a deterrent against man-in-the-middle attacks, providing a robust defense mechanism against unauthorized data manipulation. 7. Frames Loss Handling Here are some methods that can be effectively integrated with SPHA to mitigate the impact of packet loss: - Retransmission Requests: Implement a mechanism where receiving nodes can request the retransmission of lost packets. This is particularly useful for packets that were supposed to carry valid authentication but were lost in transit. Ensuring that these packets can be retransmitted securely is crucial. - Forward Error Correction (FEC): Use FEC techniques to send additional error-correcting code with the packets. This allows the receiver to reconstruct lost packets without Dunbar, et al. Expires Dec 26, 2024 [Page 13] Internet-Draft Lightweight Header Authentication Methods needing a retransmission, which is especially useful in high- latency or unreliable network environments. - Sequence Numbering: Assign sequence numbers to each packet as they are sent. This allows receiving nodes to detect missing packets (gaps in the sequence numbers) and can be used to trigger alerts or retransmission requests. - Heartbeat Messages: Regularly send heartbeat or status messages that can help in identifying packet loss quickly. These messages can carry summary information about the sequence of authenticated packets, allowing for faster detection and recovery from packet loss. - Multi-Path Transmission: Use multiple network paths to send duplicates of critical packets. This redundancy increases the likelihood that at least one copy of the packet reaches its destination, which is useful in networks where packet loss is frequent. - Adaptive Authentication Thresholds: Dynamically adjust the frequency of authentication based on network conditions. If packet loss is detected, the system could increase the authentication frequency to ensure that enough authenticated packets are received to maintain security. - Time-based Reconciliation: Implement a system where packets are periodically reconciled based on their timestamps. This can help in identifying missing packets over a specific interval and ensure that data integrity is maintained over time. 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. 8. Mechanism to Handle Replay Handling replay attacks, where a man-in-the-middle resends previously captured packet frames to disrupt or mislead the network, is crucial in maintaining the security of a network using Selective Packet Header Authentication (SPHA). Here are several strategies that can be employed to mitigate the risk of replay attacks: Dunbar, et al. Expires Dec 26, 2024 [Page 14] Internet-Draft Lightweight Header Authentication Methods - Timestamps: Include precise timestamps in each packet's header. Receiving nodes can then check these timestamps against a permissible time window to ensure that packets are not being replayed outside of this window. This approach requires synchronized clocks between the sender and the receiver. - Sequence Numbers: Use unique sequence numbers for each packet. This allows the receiving nodes to detect out-of- order or repeated sequences, which are indicative of replay attacks. Sequence numbers should be sufficiently large to prevent rollover during a session. - Nonce Values: Incorporate a random or pseudo-random number (nonce) in each packet that cannot be predicted by attackers. This nonce can be verified by the receiver to ensure that each packet is fresh and not a replay. - Challenge-Response Mechanisms: Implement a challenge- response system where the receiver sends a challenge to the sender, and the sender must include a response in subsequent packets. If a packet lacks the correct response, it can be assumed to be a replay. - Session Keys: Use session-specific keys that change periodically or each time a new connection is established. Even if a packet is captured, it will become useless once the session key changes. - Digital Signatures with Context Information: Incorporate digital signatures that include context-specific information, such as session IDs, sequence numbers, and timestamps. The combination of this data in the signature makes it difficult for an attacker to reuse the packet in a different context or session. - Packet Expiry Information: Embed expiry information within packets to define how long they are valid. This can prevent older packets from being accepted by the receiver long after their intended lifespan. - Stateful Inspection: Utilize stateful inspection at the receiving end to track the state of network connections and validate that incoming packets conform to the expected state. This can help detect and block packets that are anomalies or replays based on previous communications. Dunbar, et al. Expires Dec 26, 2024 [Page 15] Internet-Draft Lightweight Header Authentication Methods Each of these methods can be used alone or in combination to provide robust defense mechanisms against replay attacks, enhancing the security of communications in networks using SPHA. 9. Key Distribution The distribution of authentication keys (HMAC keys or Digital Signature Keys) in the context described in [MULTI-SEG-SDWAN] & [MEDIA-HDR-WIRELESS] necessitates coordination between two organizations. This document assumes a secure channel exists between those two organizations' controllers or management systems for exchanging keys. It also assumes a secure channel exists among the network controller and the edge routers. Other scenarios are out of the scope of this document. [MULTI-SEG-SDWAN] involves the key exchange between the Cloud Operator's controller (or management system) and the enterprise's SD-WAN controller. [MEDIA-HDR-WIRELESS] involves the Wireless provider controller and the application provider controller. Pre-shared keys are preferred over dynamic key exchange for simplicity and efficiency when possible. In scenarios demanding a higher security posture, authentication keys can be generated using a cryptographically secure random number generator to mitigate predictability and opt for shorter key lifetimes. In the case of [MULTI-SEG-SDWAN], the Cloud Controller can own the authentication key and securely distribute it to the enterprise's SD-WAN controller through a secure channel, such as TLS. In the case of [MEDIA-HDR-WIRELESS], the application controller can own the authentication key and securely distribute it to the wireless provider's controller (or management system). Upon receiving the authentication key, the enterprise SD-WAN controller can distribute the authentication key to the SD- WAN edges that need to authenticate the GENEVE header when steering traffic via the Cloud backbone described in the [MULTI-SEG-SDWAN] via the enterprise's secure management channel. To bolster security, it is imperative to periodically rotate the authentication keys and incorporate key versioning information to ensure that both the Cloud Operator's Dunbar, et al. Expires Dec 26, 2024 [Page 16] Internet-Draft Lightweight Header Authentication Methods Controller and the enterprise's SD-WAN controller utilize the correct and up-to-date keys. Adhering to these considerations establishes a robust authentication key among the enterprise CPE and Cloud Gateways (GWs). 10. Security Considerations The HMAC and Digital Signature provided security relies on the strength of the shared key and the effectiveness of the algorithms. Each deployment must adjust the hash algorithm and key management based on specific security requirements and considerations. While a 32-bit signature offers efficiency advantages, especially in resource-constrained environments, it comes with security trade-offs. It is essential to carefully consider the specific security requirements of the deployment to assess whether the reduced security strength is acceptable. 10.1. AH based Integrity and Authentication For enterprises or Cloud providers worrying about secret HMAC keys being compromised, they can add another layer of AH encryption [RFC4301] or ESP-NULL [RFC2410] [RFC6071] on top of the IPsec encryption between the two CPEs. Both AH and ESP-NULL IPsec encryption require pairwise IPsec key management between Cloud GWs and the CPEs, therefore requiring more processing on Cloud GWs and CPEs. In addition, the AH encrypted packets can't traverse NAT because of outer IP address changes. 11. Manageability Considerations A robust management system is essential for handling HMAC key configurations between SD-WAN edges and Cloud GW to ensure consistency and streamline the management of authentication settings. It is imperative to guarantee the secure generation, distribution, and periodic updating of HMAC keys. Additionally, implementing a well-defined process for promptly revoking and replacing HMAC keys in response to compromises or other security incidents is necessary. Dunbar, et al. Expires Dec 26, 2024 [Page 17] Internet-Draft Lightweight Header Authentication Methods 12. IANA Considerations IANA is requested to assign the values for the following Sub- TLV types that can append to IP Header for Authentication Purpose: - HMAC-Auth-Val Sub-TLV Type: The HMAC Sub-TLV is to carry the HMAC authentication value. - Digital-Sig Sub-TLV Type: The Digital-Sig Sub-TLV is to carry the Digital Signature value. 13. References 13.1. Normative References [RFC2104] H. Krawczyk, et al, "HMAC: Keyed-Hashing for Message Authentication", RFC2104, Feb. 1997. [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. [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. Dunbar, et al. Expires Dec 26, 2024 [Page 18] Internet-Draft Lightweight Header Authentication Methods [RFC6234] D. Eastlake and T. Hansen, "US Secure Hash Algorithms", RFC6234, May 2011. [RFC7011] B. Claise, B. Trammell, and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", RFC7011, Sept 2013. [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 [MULTI-SEG-SDWAN] K. Majumdar, et al, "Multi-segment SD-WAN via Cloud DCs", draft-ietf-rtgwg-multisegment- sdwan-00, May, 2024. [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. [RFC6071] S. Frankel and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Feb. 2011. Dunbar, et al. Expires Dec 26, 2024 [Page 19] Internet-Draft Lightweight Header Authentication Methods [RFC8192] S. Hares, et al, "Interface to Network Security Functions (I2NSF) Problem Statement and Use Cases", July 2017. [MEDIA-HDR-WIRELESS] J. Kaippallimalil, et al, "Media Header Extensions for Wireless Networks", draft- kaippallimalil-tsvwg-media-hdr-wireless-03, Oct 2023. [MEF-70.1] MEF 70.1 SD-WAN Service Attributes and Service Framework. Nov. 2021. [Net2Cloud] L. Dunbar and A. Malis, "Dynamic Networks to Hybrid Cloud DCs Problem Statement", draft-ietf- rtgwg-net2cloud-problem-statement-34, Feb, 2024. [SD-WAN-Edge-Discovery] L. Dunbar, et al, "BGP UPDATE for SD- WAN Edge Discovery", draft-ietf-idr-sdwan-edge- discovery-12, Oct. 2023. [UDP-OPTION-HDR] J Touch, "Transport Options for UDP", draft- ietf-tsvwg-udp-options-28, Nov. 2023. 14. Acknowledgments Acknowledgements to Russ Housley for his review, questions, and suggestions. This document was prepared using 2-Word-v2.0.template.dot. Dunbar, et al. Expires Dec 26, 2024 [Page 20] Internet-Draft Lightweight Header Authentication Methods Authors' Addresses Linda Dunbar Futurewei Email: ldunbar@futurewei.com Kausik Majumdar Microsoft Email: kmajumdar@microsoft.com Contributors' Addresses Dunbar, et al. Expires Dec 26, 2024 [Page 21]