Lightweight Authentication Methods for IP Header
draft-dunbar-secdispatch-ligthtweight-authenticate-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Linda Dunbar , Kausik Majumdar , Scott Fluhrer | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dunbar-secdispatch-ligthtweight-authenticate-03
Network Working Group L. Dunbar
Internet Draft Futurewei
Intended status: Informational K. Majumdar
Expires: April 21, 2025
Oracle
S. Fluhrer
Cisco
October 21, 2024
Lightweight Authentication Methods for IP Header
draft-dunbar-secdispatch-ligthtweight-authenticate-03
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 7, 2020.
xxx, et al. Expires April 21, 2025 [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
4.4. Other Authentication Methods.........................7
5. Encoding of Header Authentication Value...................8
5.1. Analysis of HMAC Value...............................8
5.2. Consideration in Generating the Authentication Value.9
5.3. Authentication Value Encoding........................9
5.4. Selective Packet Header Authentication..............10
6. Authentication Key Distribution..........................11
6.1. Key Distribution Via Secure Control Plane Channel...11
6.2. Key Distribution Via Secure Data Plane Tunnel.......12
7. Control Plane Mechanism..................................12
8. Frames Loss Handling.....................................13
9. Mechanism to Handle Replay...............................14
10. Security Considerations.................................15
11. Manageability Considerations............................16
12. IANA Considerations.....................................16
13. References..............................................16
13.1. Normative References...............................16
Dunbar, et al. Expires Dec 21, 2025 [Page 2]
Internet-Draft Lightweight Header Authentication Methods
13.2. Informative References.............................17
14. Acknowledgments.........................................19
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:
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.
OnPrem: On Premises data centers and branch offices.
Dunbar, et al. Expires Dec 21, 2025 [Page 3]
Internet-Draft Lightweight Header Authentication Methods
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
[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 21, 2025 [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 App 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.
Dunbar, et al. Expires Dec 21, 2025 [Page 5]
Internet-Draft Lightweight Header Authentication Methods
Security in Overlay Networks:
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
HMAC uses hash functions like SHA-256 [RFC4868], which are
computationally efficient and can be processed quickly by
both software and hardware. This ensures minimal impact on
network performance, even at high data rates, making HMAC an
efficient choice for authenticating IP encapsulation packet
headers, such as GENEVE or UDP option headers. [RFC2104]
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.
Dunbar, et al. Expires Dec 21, 2025 [Page 6]
Internet-Draft Lightweight Header Authentication Methods
Additional Header Field:
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
Digital signatures, while effective for providing
authenticity and integrity of data, have several
limitations when it comes to authenticating IP
encapsulation headers or UDP option headers. Here are some
key reasons why digital signatures are not ideal for this
purpose:
Complexity: Digital signatures involve cryptographic
operations such as hashing and asymmetric encryption, which
require significant computational resources.
Frequent Changes: IP encapsulation headers and UDP option
headers often contain fields that change frequently as the
packet traverses the network. Digital signatures would need
to be recalculated for each change, which is impractical.
4.4. Other Authentication Methods
There are several alternatives to HMAC for message
authentication, including CMAC (Cipher-based Message
Authentication Code) [RFC4493], GMAC (Galois/Counter Mode
Message Authentication Code) [RFC4106], Poly1305 [RFC7539],
SIPHASH [RFC8968], BLAKE2 [RFC7693], and KMAC (Keccak
Message Authentication Code) [RFC8702]. CMAC is based on
AES .Advanced Encryption Standard. [RFC3826] and offers
strong security in hardware-accelerated environments, while
Dunbar, et al. Expires Dec 21, 2025 [Page 7]
Internet-Draft Lightweight Header Authentication Methods
GMAC provides high performance and is often used with AES-
GCM for authenticated encryption. Poly1305, known for its
speed, pairs well with ChaCha20, and SIPHASH is optimized
for short inputs, making it ideal for hash table lookups.
BLAKE2 is faster than traditional hash functions and offers
both hashing and keyed MAC capabilities. KMAC, based on the
SHA-3 sponge function, provides flexibility with variable-
length keys and tags. Despite these alternatives, HMAC
remains a preferred choice due to its widespread support,
robust security, and efficient performance across diverse
hardware and software environments, making it a reliable
and well-understood option for authenticating IP
encapsulation packet headers.
5. Encoding of Header Authentication Value
5.1. Analysis of HMAC Value
While the ideal HMAC 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) or 8 bytes (64 bits can be
considered to append the packet header (or UDP Option
Header). Shortening the HMAC reduces the packet size,
conserving bandwidth and reducing processing time, which is
crucial in high-speed networks and resource-constrained
environments. While a truncated HMAC offers less security
than a full-length HMAC, the shorter length still provides
sufficient protection against common threats in scenarios
where the primary goal is to ensure data integrity and
authenticity without imposing significant performance
penalties. Additionally, the use of a shorter HMAC is often a
pragmatic choice in environments where packets are frequently
modified, as it minimizes the need for recalculating the
authentication code.
As stated in the [RFC2104], the authentication tag may be
truncated (e.g., to 128 bits or less) as a means of reducing
the packet overhead and still provide adequate security,
depending on the application.
Dunbar, et al. Expires Dec 21, 2025 [Page 8]
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,
- Direct Truncation: Simply take the first 4 bytes of the
HMAC output.
- Hash function output: apply another hash function on the
32 bytes value from the HMAC-SHA-256 to derive 4 bytes
value.
[RFC2104] suggests using the Direct Truncation method.
5.3. Authentication Value Encoding
HMAC-Auth-VAL Sub-TLV specified in this section can be
appended to the IP header for the header authentication
purpose.
The HMAC-Auth-VAL 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 | K |Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| HMAC Authentication Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 HMAC Sub-TLV
HMAC-Auth-Val (8 bits): HMAC Authentication Value Type = 6
(assigned by [MULTI-SEG-SDWAN]).
Length (8 bits): total length of the value field, which is
the length of the HMAC Authentication Value in bytes 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.
Dunbar, et al. Expires Dec 21, 2025 [Page 9]
Internet-Draft Lightweight Header Authentication Methods
K Flag (2 bits): indicates the index of the key used for
computing the HMAC Authentication Value present in the TLV.
This flag allows the recipient to identify which key from a
predefined set is used to generate the HMAC, facilitating key
rotation and management. The key set is assumed to be shared
and agreed upon by both the sender and the receiver prior to
communication.
HMAC Authentication Value: is computed including the entire
encapsulation header, excluding the HMAC-auth-Val Sub-TLV,
based on a pre-configured algorithm.
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
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.
Dunbar, et al. Expires Dec 21, 2025 [Page 10]
Internet-Draft Lightweight Header Authentication Methods
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. Authentication Key Distribution
The lightweight authentication methods proposed in this
document are for environments where there are IPsec tunnels
between SD-WAN CPEs and the Cloud GW. For traffic originating
from SD-WAN CPEs and terminating within the Cloud Data Center
(DC), the Cloud GW decrypts the IPsec traffic. For traffic
that needs to be routed via the Cloud Backbone to remote
CPEs, the proposed lightweight authentication method is used.
6.1. Key Distribution Via Secure Control Plane Channel
The proposed deployment environment assumes the presence of a
secure channel between the two organizations for key
exchange. It also assumes a secure channel exists between the
network controller and the CPEs. Other scenarios are out of
the scope of this document.
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).
Dunbar, et al. Expires Dec 21, 2025 [Page 11]
Internet-Draft Lightweight Header Authentication Methods
To enhance security, it is imperative to periodically rotate
the authentication keys and incorporate key versioning
information. This ensures that both the Cloud Operator's
Controller and the enterprise's SD-WAN controller utilize the
correct and up-to-date keys.
6.2. Key Distribution Via Secure Data Plane Tunnel
For environments with IPsec tunnels between SD-WAN CPEs and
the Cloud GW, the IPsec tunnel provides a secure channel for
transmitting authentication keys, ensuring protection against
eavesdropping or tampering during distribution.
Additionally, the existing IPsec keys can be used as input to
a key derivation function (KDF). The KDF generates unique
authentication keys that are cryptographically linked to the
IPsec keys but not directly exposed.
7. 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,
- 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.
Dunbar, et al. Expires Dec 21, 2025 [Page 12]
Internet-Draft Lightweight Header Authentication Methods
- 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.
8. 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
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
Dunbar, et al. Expires Dec 21, 2025 [Page 13]
Internet-Draft Lightweight Header Authentication Methods
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.
9. 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:
- 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.
Dunbar, et al. Expires Dec 21, 2025 [Page 14]
Internet-Draft Lightweight Header Authentication Methods
- 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.
- 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.
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.
10. Security Considerations
The HMAC 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
Dunbar, et al. Expires Dec 21, 2025 [Page 15]
Internet-Draft Lightweight Header Authentication Methods
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.
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.
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.
Dunbar, et al. Expires Dec 21, 2025 [Page 16]
Internet-Draft Lightweight Header Authentication Methods
[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.
[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, <https://www.rfc-
editor.org/info/rfc8174>.
[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.
Dunbar, et al. Expires Dec 21, 2025 [Page 17]
Internet-Draft Lightweight Header Authentication Methods
[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.
[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-39, April, 2024.
[SD-WAN-Edge-Discovery] L. Dunbar, et al, "BGP UPDATE for SD-
WAN Edge Discovery", draft-ietf-idr-sdwan-edge-
discovery-13, June. 2024.
[UDP-OPTION-HDR] J Touch, "Transport Options for UDP", draft-
ietf-tsvwg-udp-options-28, Nov. 2023.
Dunbar, et al. Expires Dec 21, 2025 [Page 18]
Internet-Draft Lightweight Header Authentication Methods
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 21, 2025 [Page 19]
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 21, 2025 [Page 20]