RFC 2401
Security Architecture for the Internet Protocol
Part 1 of 16 🎀
RFC 2401: Security Architecture for the Internet Protocol 🦋
Okay bestie, first the header stuff. This one came from the Network Working Group and was written by S. Kent (BBN Corp) and R. Atkinson (@Home Network). It's a Standards Track doc, dated November 1998, and it obsoletes RFC 1825. That's the whole vibe of the title block. ✨
Status of this Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. Check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 💌
Copyright Notice ©️
Copyright (C) The Internet Society (1998). All Rights Reserved. 🌸
Table of Contents 📚
1. Introduction........................................................3
1.1 Summary of Contents of Document..................................3
1.2 Audience.........................................................3
1.3 Related Documents................................................4
2. Design Objectives...................................................4
2.1 Goals/Objectives/Requirements/Problem Description................4
2.2 Caveats and Assumptions..........................................5
3. System Overview.....................................................5
3.1 What IPsec Does..................................................6
3.2 How IPsec Works..................................................6
3.3 Where IPsec May Be Implemented...................................7
4. Security Associations...............................................8
4.1 Definition and Scope.............................................8
4.2 Security Association Functionality..............................10
4.3 Combining Security Associations.................................11
4.4 Security Association Databases..................................13
4.4.1 The Security Policy Database (SPD).........................14
4.4.2 Selectors..................................................17
4.4.3 Security Association Database (SAD)........................21
4.5 Basic Combinations of Security Associations.....................24
4.6 SA and Key Management...........................................26
4.6.1 Manual Techniques..........................................27
4.6.2 Automated SA and Key Management............................27
4.6.3 Locating a Security Gateway................................28
4.7 Security Associations and Multicast.............................29
5. IP Traffic Processing..............................................30
5.1 Outbound IP Traffic Processing..................................30
5.1.1 Selecting and Using an SA or SA Bundle.....................30
5.1.2 Header Construction for Tunnel Mode........................31
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32
5.2 Processing Inbound IP Traffic...................................33
5.2.1 Selecting and Using an SA or SA Bundle.....................33
5.2.2 Handling of AH and ESP tunnels.............................34
6. ICMP Processing (relevant to IPsec)................................35
6.1 PMTU/DF Processing..............................................36
6.1.1 DF Bit.....................................................36
6.1.2 Path MTU Discovery (PMTU)..................................36
6.1.2.1 Propagation of PMTU...................................36
6.1.2.2 Calculation of PMTU...................................37
6.1.2.3 Granularity of PMTU Processing........................37
6.1.2.4 PMTU Aging............................................38
7. Auditing...........................................................39
8. Use in Systems Supporting Information Flow Security................39
8.1 Relationship Between Security Associations and Data Sensitivity.40
8.2 Sensitivity Consistency Checking................................40
8.3 Additional MLS Attributes for Security Association Databases....41
8.4 Additional Inbound Processing Steps for MLS Networking..........41
8.5 Additional Outbound Processing Steps for MLS Networking.........41
8.6 Additional MLS Processing for Security Gateways.................42
9. Performance Issues.................................................42
10. Conformance Requirements..........................................43
11. Security Considerations...........................................43
12. Differences from RFC 1825.........................................43
Acknowledgements......................................................44
Appendix A -- Glossary................................................45
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.....48
B.1 DF bit..........................................................48
B.2 Fragmentation...................................................48
B.3 Path MTU Discovery..............................................52
B.3.1 Identifying the Originating Host(s)........................53
B.3.2 Calculation of PMTU........................................55
B.3.3 Granularity of Maintaining PMTU Data.......................56
B.3.4 Per Socket Maintenance of PMTU Data........................57
B.3.5 Delivery of PMTU Data to the Transport Layer...............57
B.3.6 Aging of PMTU Data.........................................57
Appendix C -- Sequence Space Window Code Example......................58
Appendix D -- Categorization of ICMP messages.........................60
References............................................................63
Disclaimer............................................................64
Author Information....................................................65
Full Copyright Statement..............................................661. Introduction 🎀
1.1 Summary of Contents of Document 💖
This memo lays out the base architecture for IPsec compliant systems. The goal is to give you various security services for traffic at the IP layer, in both the IPv4 and IPv6 worlds. It covers the goals of these systems, their parts, how those parts fit together, and how they slot into the IP environment. It also explains the security services the IPsec protocols offer and how you can use them in the IP environment. 🧚
This doc does NOT cover every single corner of IPsec architecture. Later documents will dig into the more advanced stuff, like using IPsec in NAT environments and fuller support for IP multicast. The fundamental components are discussed in terms of their underlying, required functionality. Other RFCs (see Section 1.3 for pointers) define the protocols in (a), (c), and (d):
- (a) Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP)
- (b) Security Associations -- what they are and how they work, how they are managed, associated processing
- (c) Key Management -- manual and automatic (The Internet Key Exchange (IKE))
- (d) Algorithms for authentication and encryption
Also, this document is not an overall Security Architecture for the Internet. It only handles security at the IP layer, delivered through a mix of cryptographic and protocol security mechanisms. 🔐
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97]. 📝
1.2 Audience 🌈
The target audience is implementers of this IP security tech, plus anyone who wants a general background understanding of the system. Prospective users (end users or system administrators) are very much part of the audience too. There's a glossary in an appendix to help fill in gaps in background and vocabulary. This doc assumes you already know the Internet Protocol, related networking tech, and general security terms and concepts. 🤓
1.3 Related Documents 📚
As I said above, other documents give detailed definitions of some of the IPsec components and how they relate. They include RFCs on the following topics:
- (a) "IP Security Document Roadmap" [TDG97] -- a document giving guidelines for specifications describing encryption and authentication algorithms used in this system.
- (b) security protocols -- RFCs describing the Authentication Header (AH) [KA98a] and Encapsulating Security Payload (ESP) [KA98b] protocols.
- (c) algorithms for authentication and encryption -- a separate RFC for each algorithm.
- (d) automatic key management -- RFCs on "The Internet Key Exchange (IKE)" [HC98], "Internet Security Association and Key Management Protocol (ISAKMP)" [MSST97], "The OAKLEY Key Determination Protocol" [Orm97], and "The Internet IP Security Domain of Interpretation for ISAKMP" [Pip98]. 🦋
2. Design Objectives 💅
2.1 Goals/Objectives/Requirements/Problem Description 🎯
IPsec is built to give you interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The security services on the menu include access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services live at the IP layer, so they protect IP and/or upper layer protocols. 👑
All of this is achieved using two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), plus cryptographic key management procedures and protocols. Which IPsec protocols get used in any context, and how, is decided by the security and system requirements of users, applications, and/or sites/organizations. 🫶
When these mechanisms are correctly implemented and deployed, they ought not to adversely affect users, hosts, and other Internet components that don't use these security mechanisms to protect their traffic. The mechanisms are also designed to be algorithm-independent. That modularity lets you pick different sets of algorithms without messing with the rest of the implementation. For example, different user communities may pick different sets of algorithms (creating cliques) if they need to. 🌸
A standard set of default algorithms is specified so things interoperate across the global Internet. Using these algorithms, together with IPsec traffic protection and key management protocols, lets system and application developers ship high quality, Internet layer, cryptographic security tech. ✨
2.2 Caveats and Assumptions 🎀
okay so bestie, the IPsec protocol suite and its default algorithms are designed to give seriously high quality security for Internet traffic 💖 but here's the tea: how much security you actually get depends on the quality of the implementation, and that's outside the scope of this set of standards 😭. Also, the security of a computer system or network depends on loads of things, like personnel, physical stuff, procedures, compromising emanations, and general computer security practices 💅. So IPsec is literally only one part of the overall system security architecture 🧩.
Finally, the security IPsec gives you is super dependent on the operating environment it runs in 🌈. Like, defects in OS security, poor quality random number sources, sloppy system management protocols and practices, etc. can all degrade the security IPsec provides 💀. As above, none of these environmental attributes are within the scope of this or any other IPsec standard 🙈.
3. System Overview ✨
okay this section is the big picture, and it's giving "see how it all fits together" 🦋. It describes how IPsec works, what the components are, and how they team up to provide the security services we just mentioned 🫶. The goal is for you to "picture" the whole process/system, see how it fits into the IP environment, and get context for the later sections that break down each component in more detail 🧚.
An IPsec implementation operates in a host or a security gateway environment and protects IP traffic 🔥. The protection is based on requirements defined by a Security Policy Database (SPD) that a user or system administrator sets up and maintains, or that an application sets up within constraints established by either of those 💜. Generally, packets get sorted into one of three processing modes based on IP and transport layer header information (Selectors, Section 4.4.2) matched against entries in the database (SPD) 👑. Each packet either gets IPsec security services, gets discarded, or is allowed to bypass IPsec, depending on the applicable database policies identified by the Selectors 💅.
3.1 What IPsec Does
IPsec provides security services at the IP layer by letting a system select the required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services 🔐. IPsec can protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host 🌸. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway 🧱.)
The set of security services IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality ✨. Because these services live at the IP layer, any higher layer protocol can use them, e.g., TCP, UDP, ICMP, BGP, etc. 🙌
The IPsec DOI also supports negotiation of IP compression [SMPT98] 🗜️. This is motivated partly by the observation that when encryption is used within IPsec, it prevents effective compression by lower protocol layers 😭.
3.2 How IPsec Works
okay here's the core of it: IPsec uses two protocols to provide traffic security, the Authentication Header (AH) and the Encapsulating Security Payload (ESP) 💖. Both get described in more detail in their own RFCs [KA98a, KA98b] 📖.
- The IP Authentication Header (AH) [KA98a] provides connectionless integrity, data origin authentication, and an optional anti-replay service 🛡️.
- The Encapsulating Security Payload (ESP) protocol [KA98b] may provide confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. (One or the other set of these security services must be applied whenever ESP is invoked.) 🔒
- Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols 🚦.
These protocols may be applied alone or combined with each other to provide a desired set of security services in IPv4 and IPv6 🌈. Each protocol supports two modes of use: transport mode and tunnel mode 🦋. In transport mode the protocols mainly protect upper layer protocols, while in tunnel mode they get applied to tunneled IP packets 🎀. The differences between the two modes are discussed in Section 4 💅.
IPsec lets the user (or system administrator) control the granularity at which a security service is offered 🔍. For example, you can create a single encrypted tunnel to carry all the traffic between two security gateways, or you can create a separate encrypted tunnel for each TCP connection between each pair of hosts communicating across those gateways 🧁. IPsec management must incorporate facilities for specifying:
- which security services to use and in what combinations
- the granularity at which a given security protection should be applied
- the algorithms used to effect cryptographic-based security
Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting those keys in place 🗝️. (The keys are used for authentication/integrity and encryption services.) This document requires support for both manual and automatic distribution of keys 🫶. It specifies a particular public-key based approach (IKE -- [MSST97, Orm97, HC98]) for automatic key management, but other automated key distribution techniques MAY be used 💜. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed 🧚.
3.3 Where IPsec May Be Implemented
There are several ways IPsec may be implemented in a host, or alongside a router or firewall (to create a security gateway) 🏠. Here are some common examples:
a. Integration of IPsec into the native IP implementation. This requires access to the IP source code and is applicable to both hosts and security gateways 🧩.
b. "Bump-in-the-stack" (BITS) implementations, where IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Source code access for the IP stack is not required in this context, making this approach appropriate for legacy systems. When it is adopted, this approach is usually employed in hosts 🦕.
c. The use of an outboard crypto processor is a common design feature of network security systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "Bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway (or both). Usually the BITW device is IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but when supporting a router or firewall, it must operate like a security gateway 🔥.
4. Security Associations 👑
This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both 💖. The concept of a "Security Association" (SA) is fundamental to IPsec 🌟. Both AH and ESP make use of SAs, and a major function of IKE is establishing and maintaining Security Associations 🤝. All implementations of AH or ESP MUST support the concept of a Security Association as described below 🚨. The rest of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques 🎀.
4.1. Definition and Scope
okay so a Security Association (SA) is a simplex "connection" that gives security services to whatever traffic runs through it 🎀 Those services come from AH or ESP, but never both on the same SA. If you want AH and ESP protection on one traffic stream, you end up with two (or more) SAs covering that stream 🦋 For normal two-way chats between two hosts, or between two security gateways, you need two SAs, one for each direction 💖
An SA is uniquely identified by a triple: a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier ✨ In theory the Destination Address could be unicast, an IP broadcast address, or a multicast group address 🌈 BUT IPsec's SA management mechanisms are only defined for unicast SAs right now 😭 So for the rest of the doc, SAs get explained in a point-to-point setting, even though the idea works for point-to-multipoint too 💅
As we said earlier, there are two kinds of SAs: transport mode and tunnel mode 👑
A transport mode SA is a security association between two hosts 🧚 In IPv4, the transport mode security protocol header sits right after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP) 🌸 In IPv6, the security protocol header comes after the base IP header and extensions. It can show up before or after destination options, but it always lands before higher layer protocols 🫶 With ESP, a transport mode SA only protects those higher layer protocols. It does NOT cover the IP header or any extension headers in front of the ESP header 🙈 With AH, the protection stretches further, to selected parts of the IP header, selected parts of extension headers, and selected options (inside the IPv4 header, the IPv6 Hop-by-Hop extension header, or the IPv6 Destination extension headers) 🔥 For the full scoop on what AH covers, check the AH specification [KA98a] 💜
A tunnel mode SA is basically an SA applied to an IP tunnel 🦋 Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode 😤 So an SA between two security gateways is always tunnel mode, and so is an SA between a host and a security gateway 💅 Now, if traffic is headed to a security gateway (SNMP commands, for example), the gateway is acting like a host, so transport mode is allowed 🍓 But in that case the gateway isn't acting as a gateway, because it isn't passing transit traffic through 🙈 Two hosts MAY set up a tunnel mode SA between themselves ✨ The rule that any SA involving a security gateway for transit traffic has to be a tunnel SA exists because of fragmentation and reassembly problems with IPsec packets, and because multiple paths (for example, through different security gateways) can lead to the same destination behind those gateways 🌈
For a tunnel mode SA, you get an "outer" IP header that names the IPsec processing destination, plus an "inner" IP header that names the (apparently) ultimate destination for the packet 💖 The security protocol header goes after the outer IP header and before the inner IP header 🎀 If AH is used in tunnel mode, parts of the outer IP header get protected (same as before), and so does the entire tunneled IP packet. That means the whole inner IP header is covered, along with higher layer protocols 👑 If ESP is used, only the tunneled packet gets protection, and the outer header does not 🫶
So, in summary:
a) A host MUST support both transport and tunnel mode. 💅 b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management. 🧚
4.2. Security Association Functionality
the set of security services an SA offers depends on which security protocol is picked, the SA mode, the endpoints of the SA, and whether optional services inside the protocol get elected 🍓 For example, AH gives data origin authentication and connectionless integrity for IP datagrams (we'll just call this "authentication" from here on) ✨ How precise that authentication is depends on how granular the security association is that AH runs on, as covered in Section 4.4.2, "Selectors" 🌸
AH also has an anti-replay (partial sequence integrity) service, which the receiver can choose to use, and it helps defend against denial of service attacks 🔥 AH is the right pick when confidentiality isn't required (or isn't allowed, e.g , because of government restrictions on encryption) 😭 AH also authenticates selected parts of the IP header, which can be needed in some situations 💜 For example, if the integrity of an IPv4 option or an IPv6 extension header has to be protected on the way between sender and receiver, AH can handle that (except for the non-predictable but mutable parts of the IP header.) 🦋
ESP optionally gives confidentiality for traffic 🎀 (How strong that confidentiality is depends partly on the encryption algorithm used.) ESP can also optionally provide authentication, as defined above 💖 If authentication is negotiated for an ESP SA, the receiver can also choose to enforce an anti-replay service with the same features as the AH anti-replay service 👑 ESP's authentication covers less ground than AH's. The IP header(s) "outside" the ESP header is(are) NOT protected 🙈 If only the upper layer protocols need authenticating, ESP authentication is the right call, and it's more space efficient than wrapping ESP inside AH 🧚 Quick note: even though confidentiality and authentication are both optional, they can't both be left out. At least one of them MUST be selected 🔥
If you pick confidentiality, then an ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality 🌈 Tunnel mode lets the inner IP headers get encrypted, which hides who the (ultimate) traffic source and destination are 🫶 ESP payload padding can also be used to hide packet sizes, which hides even more about what the traffic looks like from the outside 💅 Similar traffic flow confidentiality can happen when a mobile user gets a dynamic IP address in a dialup setup and builds a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway) 🍓 And heads up: fine granularity SAs are generally more vulnerable to traffic analysis than coarse granularity ones that carry traffic from lots of subscribers 😭✨
4.3 Combining Security Associations ✨
okay so each SA only gets one security protocol, either AH or ESP, never both 💅 But sometimes a policy wants a combo of services for one traffic flow that a single SA just can't do 😭 In that case you need multiple SAs stacked together, and that stack is called an "SA bundle" (or "SA bundle" for short 🎀). The policy decides the order the traffic goes through them. Also, the SAs in a bundle don't have to end at the same place! One might run from a mobile host to a security gateway, and then a nested one keeps going to a host sitting behind that gateway 🦋
There are two ways to build these bundles: transport adjacency and iterated tunneling 💖
- Transport adjacency means putting more than one security protocol on the same IP datagram, with no tunneling involved 🌸 Combining AH and ESP this way only gets you one level of combination. Stacking more layers doesn't add anything (assuming the algorithms in each protocol are strong enough), because all the processing happens at one IPsec instance, the (ultimate) destination.
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -----Security Association 1 (ESP transport)------- |
| |
-------Security Association 2 (AH transport)----------- Iterated tunneling means layering several security protocols using IP tunneling 🧚 This one allows multiple levels of nesting, because each tunnel can start or end at a different IPsec site along the path. No special handling is expected for ISAKMP traffic at intermediate security gateways, beyond whatever you set up through the right SPD entries (see Case 3 in Section 4.5) 🔥
There are 3 basic cases of iterated tunneling, and only cases 2 and 3 are required 👑
- Both endpoints for the SAs are the same. The inner and outer tunnels can each be AH or ESP, though Host 1 probably wouldn't pick the same one twice, like AH inside of AH or ESP inside of ESP 🙈
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------- One endpoint of the SAs is the same. The inner and outer tunnels can each be AH or ESP 🌈
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------- Neither endpoint is the same. The inner and outer tunnels can each be AH or ESP ⭐
Host 1 --- Security ---- Internet -- Security --- Host 2
| Gwy 1 Gwy 2 |
| | | |
| --Security Assoc 1 (tunnel)- |
| |
-----------Security Association 2 (tunnel)-----------You can also mix the two approaches. For example, an SA bundle could be one tunnel mode SA plus one or two transport mode SAs, applied in sequence (see Section 4.5 "Basic Combinations of Security Associations.") 🦋 Nested tunnels can even happen where neither the source nor the destination endpoints of any of the tunnels match. In that case, no host or security gateway has a bundle that matches the nested tunnels 🫶
For transport mode SAs, only one ordering of security protocols seems appropriate 💅 AH covers both the upper layer protocols and (parts of) the IP header. So if AH is used in transport mode together with ESP, AH SHOULD appear as the first header after IP, before ESP. Then AH is applied to the ciphertext output of ESP 🔐 Tunnel mode SAs are different, though. There are lots of possible orderings of AH and ESP there 🌸 The required set of SA bundle types that a compliant IPsec implementation MUST support is described in Section 4.5 ✨
4.4 Security Association Databases 🎀
Lots of the details for handling IP traffic in an IPsec implementation are just local business and aren't standardized 💅 But some outside-facing parts do need standards, so that different implementations can work together and you get a minimum level of management that's essential for actually using IPsec productively 😭 This section describes a general model for handling IP traffic relative to security associations, to support those interoperability and functionality goals 💖 The model is nominal, so compliant implementations don't need to match its details exactly. What matters is that their external behavior can be mapped onto the externally observable characteristics of this model ✨
There are two nominal databases in this model: the Security Policy Database and the Security Association Database 🌈 The first one holds the policies that decide what happens to all IP traffic going in or out of a host, security gateway, or BITS or BITW IPsec implementation 👑 The second one holds parameters tied to each (active) security association 🦋 This section also defines a Selector, which is a set of IP and upper layer protocol field values. The Security Policy Database uses Selectors to map traffic to a policy, i.e., an SA (or SA bundle) 🧚
Each interface with IPsec enabled needs its own nominally separate inbound and outbound databases (SAD and SPD), because many of the fields used as selectors are directional 💜 Usually there's just one such interface, for a host or security gateway (SG). An SG always has at least 2 interfaces, but the "internal" one facing the corporate net usually doesn't have IPsec enabled, so only one pair of SADs and one pair of SPDs is needed 🔥 On the other hand, if a host has multiple interfaces, or an SG has multiple external interfaces, you might need separate SAD and SPD pairs for each interface 🍓
4.4.1. The Security Policy Database (SPD) 🎀
Okay so the big secret is that a security association is really just a management tool for enforcing a security policy 💅. That means all the SA stuff sits on top of a Security Policy Database (SPD) that decides which services get offered to IP datagrams and how. The exact shape of that database and how you talk to it is outside this spec 🙈. BUT this section does lay out the minimum management functionality a user or sysadmin needs, so they can control how IPsec gets applied to traffic a host sends or receives, or traffic passing through a security gateway ✨.
The SPD must be consulted while processing all traffic, both INBOUND and OUTBOUND, even the non-IPsec stuff 👀. That's why it needs distinct entries for inbound and outbound traffic. You can picture it as two SPDs, one inbound and one outbound. There's also a nominally separate SPD for each IPsec-enabled interface 🌸.
Every SPD situation comes down to three choices for any outbound or inbound datagram 💖:
- Discard: the traffic isn't allowed to leave the host, go through the security gateway, or reach an application at all 💀.
- Bypass IPsec: the traffic is allowed through without any extra IPsec protection 🦋.
- Apply IPsec: the traffic gets IPsec protection, and the SPD has to spell out the security services, protocols, algorithms, and so on 🧚.
This applies to the protection a sender applies and the protection a receiver must see present. Honestly it's giving a very clear "who gets what" energy 👑.
For every IPsec implementation, there MUST be an administrative interface that lets a user or system administrator manage the SPD 🫶. Every inbound or outbound packet gets processed by IPsec, and the SPD has to say what happens in each case. So the admin interface has to let the user (or sysadmin) choose the security processing for any packet entering or exiting the system, packet by packet 🔥. (Quick aside: in a host IPsec implementation that uses a socket interface, the SPD may not need to be checked on every single packet, but the end result is still the same ✨.) The management interface for the SPD MUST allow creating entries that match the selectors in Section 4.4.2, and it MUST support (total) ordering of those entries 📋. The vibe here is that wildcards in the selector fields, plus the fact that all packets on one UDP or TCP connection usually match a single SPD entry, mean this won't turn into an unreasonably detailed setup 💜. The selectors are basically the same kind you'd find in a stateless firewall or filtering router, which people already manage this way 🌈.
On hosts, applications MAY be allowed to pick what security processing gets applied to the traffic they generate and consume 🍓. (How they signal that request to the IPsec implementation is outside this standard, so don't come for me on that one 🙈.) However, the system administrator MUST be able to say whether or not a user or application can override the default system policies 👑. Also, application-specified policies may already satisfy the system's requirements, so the system might not need any extra IPsec processing beyond what the application already asked for ✨. This document doesn't specify the form of the management interface, and it may differ between hosts and security gateways. Inside hosts, it may also differ between socket-based and BITS implementations 💅. What this document DOES do is define a standard set of SPD elements that all IPsec implementations MUST support 🎀.
Here's the structure, bestie 🧚. The SPD holds an ordered list of policy entries. Each entry is keyed by one or more selectors that define which IP traffic it covers (the required selector types are in Section 4.4.2), and those selectors set the granularity of the policies or SAs 🦋. Each entry says whether matching traffic gets bypassed, discarded, or put through IPsec processing 💖. If IPsec applies, the entry includes an SA (or SA bundle) spec listing the IPsec protocols, modes, and algorithms to use, including any nesting requirements 🌸. For example, an entry might say all matching traffic gets protected by ESP in transport mode using 3DES-CBC with an explicit IV, nested inside AH in tunnel mode using HMAC/SHA-1 💜. For each selector, the policy entry also says how to derive the matching value for a new Security Association Database (SAD, see Section 4.4.3) entry, using the values from the SPD and the packet. Quick heads up, though: right now, ranges are only supported for IP addresses, but wildcarding can be expressed for all selectors ⭐.
- a. Use the value in the packet itself. This limits the SA to packets that have this packet's value for the selector, even if the policy entry's selector covers a range of allowed values or a wildcard 🔥.
- b. Use the value associated with the policy entry. If that's a single value, there's no difference between (a) and (b). But if the allowed values are a range (for IP addresses) or a wildcard, then with a range, (b) lets any packet with a selector value inside the range use the SA, not just the packet that triggered the SA's creation 🌈. With a wildcard, (b) lets packets with any value for that selector use the SA 🫶.
Let's do an example so it clicks 🍓. Say an SPD entry allows any host in the source address range 192.168.2.1 to 192.168.2.10, and you're sending a packet with source address 192.168.2.3. The value used for the SA depends on what the policy entry says the source of the selector value is:
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts)If the SPD entry had a wildcard as its allowed source address, the SAD selector value could be a wildcard too, meaning any host 🌸. Option (a) is how you prohibit sharing, even among packets that match the same SPD entry 🙅♀️.
Now, as Section 4.4.3 covers, selectors can include "wildcard" entries, so the selectors for two entries can overlap 🌀. (This is just like the overlap you get with ACLs or filter entries in routers or packet-filtering firewalls.) So to keep processing consistent and predictable, SPD entries MUST be ordered, and the SPD MUST always be searched in the same order, so the first matching entry is always the one picked 🔒. (This matters because the result of processing traffic against SPD entries has to be deterministic. There's just no way to canonicalize SPD entries when some selectors use wildcards 🤷♀️.) For more on how packets get matched against SPD entries, check out Section 5 📖.
Also, if ESP is specified, either authentication or encryption (but not both) can be left out 🦋. So it MUST be possible to configure the SPD value for the authentication or encryption algorithm as "NULL". However, at least one of those services MUST be selected. In other words, it MUST NOT be possible to configure both of them as "NULL" 🚫. Not both NULL, periodt 💀.
The SPD can map traffic to specific SAs or SA bundles, so it works as both the reference database for security policy and the map to existing SAs (or SA bundles) 🗺️. (To handle the bypass and discard policies mentioned above, the SPD also MUST provide a way to map traffic to those functions, even though they aren't IPsec processing per se 💅.) How the SPD operates is different for inbound vs. outbound traffic, and it can also differ between host, security gateway, BITS, and BITW implementations 🌈. Sections 5.1 and 5.2 cover how the SPD is used for outbound and inbound processing, respectively 🎀.
A security policy might need more than one SA applied to a set of traffic, in a specific order, so the SPD policy entry has to preserve those ordering requirements when they exist 🧚. That means an IPsec implementation has to be able to tell that an outbound or inbound packet must go through a sequence of SAs 👑. Conceptually, for outbound processing, you can imagine links (to the SAD) from SPD entries that have active SAs. Each entry would hold either a single SA or an ordered list of SAs forming an SA bundle 🦋. When a packet matches an SPD entry and there's an existing SA or SA bundle that can carry the traffic, the processing is controlled by the SA or SA bundle entry on that list ✨. For an inbound IPsec packet where multiple IPsec SAs need to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA 💜.
Last but not least, the SPD controls the flow of ALL traffic through an IPsec system, including security and key management traffic (like ISAKMP) to and from entities behind a security gateway 🔐. That means ISAKMP traffic must be explicitly accounted for in the SPD, or it will be discarded 💀. A security gateway could also block encrypted packets in various ways, like having a DISCARD entry in the SPD for ESP packets, or by providing proxy key exchange. In the proxy case, the traffic gets routed internally to the key management module in the security gateway 🌸.
4.4.2. Selectors ✨
okay bestie, so an SA (or SA bundle) can be super fine-grained or super coarse-grained 🦋, and it all depends on the selectors that decide which traffic belongs to it. Like, ALL the traffic between two hosts can ride on one SA and get the same security services, or the traffic can be split across several SAs based on the app (that's what the Next Protocol and Port fields are for), with different services on each one 💅. Same vibe for gateways: one SA for every bit of traffic between two security gateways, or one SA per communicating host pair. The selector parameters below are the ones that MUST be supported so you can actually control SA granularity 🎀.
Quick heads up: if a packet comes in with an ESP header (say, at an encapsulating security gateway or a BITW implementation), the transport layer protocol, the source/destination ports, and Name (if it's there) might be "OPAQUE", which just means you can't see them because of encryption or fragmentation 🙈. Also, both Source and Destination addresses should either be IPv4 or IPv6, not a mix 🌸.
- Destination IP Address (IPv4 or IPv6) 💖: this can be one single IP address (unicast, anycast, broadcast (IPv4 only), or a multicast group), a range of addresses (high and low values, inclusive), an address + mask, or a wildcard address. The last three are there so that more than one destination system can share the same SA (like hosts hiding behind a security gateway). Now, this selector is conceptually different from the "Destination IP Address" field in the
<Destination IP Address, IPsec Protocol, SPI>tuple that uniquely identifies an SA, so pay attention here 👀. When a tunneled packet shows up at the tunnel endpoint, its SPI/Destination address/Protocol are used to look up the SA for that packet in the SAD. That destination address comes from the encapsulating IP header. Once the packet has been processed by the tunnel SA and has come out the other end, its selectors get "looked up" in the Inbound SPD, and that SPD has a destination address selector too. This one is the IP destination address from the inner (encapsulated) IP header. For a transport'd packet, there's only one IP header, so this whole ambiguity just doesn't exist ✨ [REQUIRED for all implementations] - Source IP Address(es) (IPv4 or IPv6) 🧚: this can be a single IP address (unicast, anycast, broadcast (IPv4 only), or a multicast group), a range of addresses (high and low values inclusive), an address + mask, or a wildcard address. The last three support more than one source system sharing the same SA (like behind a security gateway or on a multihomed host) 🦋 [REQUIRED for all implementations]
- Name 👑: there are 2 cases here, and these name forms are supported in the IPsec DOI, so they're legit.
- 1. User ID
- a. a fully qualified user name string (DNS), e.g.,
mozart@foo.bar.com - b. X.500 distinguished name, e.g.,
C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent.
- a. a fully qualified user name string (DNS), e.g.,
- 2. System name (host, security gateway, etc.)
- a. a fully qualified DNS name, e.g.,
foo.bar.com - b. X.500 distinguished name
- c. X.500 general name
- a. a fully qualified DNS name, e.g.,
- 1. User ID
NOTE: One of the possible values of this selector is "OPAQUE". 🙈
[REQUIRED for the following cases. Note that support for name forms other than addresses is not required for manually keyed SAs.
- User ID
- native host implementations
- BITW and BITS implementations acting as HOSTS with only one user
- security gateway implementations for INBOUND processing.
- System names -- all implementations]
- Data sensitivity level 🔥: (IPSO/CIPSO labels) [REQUIRED for all systems providing information flow security as per Section 8, OPTIONAL for all other systems.]
- Transport Layer Protocol 💅: this gets pulled from the IPv4 "Protocol" or the IPv6 "Next Header" field, and it can be an individual protocol number. Those fields might not actually hold the transport protocol because of IP extension headers (a Routing Header, AH, ESP, a Fragmentation Header, Destination Options, Hop-by-hop options, etc.), which is so annoying 😭. Also, the transport protocol might not be visible when there's an ESP header, so a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations]
NOTE: To find the transport protocol, a system has to chain through the packet headers, checking the "Protocol" or "Next Header" field, until it hits one it recognizes as a transport protocol, or one that isn't on its list of extension headers, or an ESP header that makes the transport protocol opaque. It's like a treasure hunt 🗺️✨
- Source and Destination (e.g., TCP/UDP) Ports 🌈: these can be individual UDP or TCP port values or a wildcard port. (Using the Next Protocol field plus the Source and/or Destination Port fields, along with the Source and/or Destination Address fields, as an SA selector is sometimes called "session-oriented keying.") Again, with ESP the ports might not be visible, so a value of "OPAQUE" SHOULD be supported.
Here's the table summarizing how the "Next Header" value in the packet relates to the SPD and the derived Port Selector value for the SPD and SAD 🍓:
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragmentIf the packet has been fragmented, the port info might not be in the current fragment. If that happens, discard the fragment. An ICMP PMTU should be sent for the first fragment, since that's the one with the port information. [MAY be supported]
The IPsec implementation context decides how selectors get used 🧠. For example, a host implementation that's built into the stack might use a socket interface. When a new connection gets established, the SPD can be consulted and an SA (or SA bundle) bound to the socket, so traffic sent through that socket doesn't need extra SPD/SAD lookups. A BITS, BITW, or security gateway implementation, on the other hand, has to look at every single packet and do an SPD/SAD lookup based on the selectors 💖. The allowable values for the selector fields are different for the traffic flow, the security association, and the security policy, so keep that in mind ✨
Next up is the table of the kinds of entries you need to be able to express in the SPD and SAD. It shows how they match up with the fields in the data traffic that's getting IPsec screening 🎀. (Heads up: the "wild" or "wildcard" entry for src and dst addresses includes a mask, range, etc.)
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
* The SAD and SPD entries for these fields could be "OPAQUE"
because the traffic value is encrypted.NOTE: In principle, you could have selectors and/or selector values in the SPD that can't be negotiated for an SA or SA bundle 🙃. Examples might be selector values used to pick traffic to discard, or enumerated lists that create a separate SA for each item on the list. For now, this is left for future versions of this document, and the list of required selectors and selector values is the same for the SPD and the SAD. However, it's totally acceptable to have an administrative interface that supports selector values which can't be negotiated, as long as it doesn't mislead the user into thinking it's creating an SA with those selector values 🌸. For example, the interface might let the user specify an enumerated list of values, but that would actually result in a separate policy and SA for each item on the list. A vendor might support an interface like this to make it easier for customers to write clear and concise policy specifications 💜
4.4.3. Security Association Database (SAD) 🗄️
okay bestie, the SAD is where every Security Association lives 💅. each IPsec implementation has one nominal SAD, and every SA gets its own entry in it. for outbound traffic, SPD entries point at SAD entries. if an SPD entry isn't pointing at an SA that works for the packet, the implementation creates one (or an SA Bundle) and links the SPD entry to the new SAD entry, see Section 5.1.1 🦋. for inbound traffic, the SAD is indexed by destination IP address, IPsec protocol type, and SPI 🔍. the list below is the minimal stuff an SA needs to work, and it is explicitly NOT a MIB 🙈.
For inbound processing, these packet fields are used to look up the SA in the SAD:
Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations]IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. It specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations]SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations]
Selector check time 💖 For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values negotiated when the SA was created. Senders use these values to decide whether an SA is appropriate for an outbound packet, which is part of checking whether there's an existing SA they can reuse. Receivers use them to check that the selector values in an inbound packet match the SA's values (and therefore, indirectly, the matching policy's). That's part of verifying the SA was right for that packet. (See Section 6 for rules for ICMP messages.) These fields can take the form of specific values, ranges, wildcards, or "OPAQUE", as described in section 4.4.2, "Selectors". Also, for an ESP SA, the encryption algorithm or the authentication algorithm could be NULL. BUT they MUST not both be NULL 🚫.
Next up are the SAD fields used when doing actual IPsec processing ⚙️:
Sequence Number Counter: a 32-bit value used to generate theSequence Numberfield in AH or ESP headers. [REQUIRED for all implementations, but used only for outbound traffic.]Sequence Counter Overflow: a flag indicating whether overflow of theSequence Number Countershould generate an auditable event and prevent transmission of additional packets on the SA. [REQUIRED for all implementations, but used only for outbound traffic.]Anti-Replay Window: a 32-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. [REQUIRED for all implementations but used only for inbound traffic. NOTE: If anti-replay has been disabled by the receiver, e.g., in the case of a manually keyed SA, then theAnti-Replay Windowis not used.]AH Authentication algorithm, keys, etc.[REQUIRED for AH implementations]ESP Encryption algorithm, keys, IV mode, IV, etc.[REQUIRED for ESP implementations]ESP authentication algorithm, keys, etc.If the authentication service is not selected, this field will be null. [REQUIRED for ESP implementations]Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count, or a simultaneous use of both, the first lifetime to expire taking precedence. A compliant implementation MUST support both types of lifetimes, and must support a simultaneous use of both. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and theNextIssueDateof the CRLs used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. [REQUIRED for all implementations]
NOTE: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is:
- (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. For ESP, this is the encryption algorithm (including Null encryption) and for AH, this is the authentication algorithm. This includes pad bytes, etc. Note that implementations SHOULD be able to handle having the counters at the ends of an SA get out of synch, e.g., because of packet loss or because the implementations at each end of the SA aren't doing things the same way.
- (b) There SHOULD be two kinds of lifetime -- a soft lifetime which warns the implementation to initiate action such as setting up a replacement SA and a hard lifetime when the current SA ends.
- (c) If the entire packet does not get delivered during the SAs lifetime, the packet SHOULD be discarded.
IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. If this field iswildcardat the sending end of the SA, then the application has to specify the mode to the IPsec implementation. This use of wildcard allows the same SA to be used for either tunnel or transport mode traffic on a per packet basis, e.g., by different sockets. The receiver does not need to know the mode in order to properly process the packet's IPsec headers.
[REQUIRED as follows, unless implicitly defined by context:
- host implementations must support all modes
- gateway implementations must support tunnel mode]
NOTE: The use of wildcard for the protocol mode of an inbound SA may add complexity to the situation in the receiver (host only). Since the packets on such an SA could be delivered in either tunnel or transport mode, the security of an incoming packet could depend in part on which mode had been used to deliver it. If, as a result, an application cared about the SA mode of a given packet, then the application would need a mechanism to obtain this mode information.
Path MTU: any observed path MTU and aging variables. See Section 6.1.2.4 [REQUIRED for all implementations but used only for outbound traffic]
that's the whole SAD rundown, periodt ✨🎀
4.5. Basic Combinations of Security Associations 🦋
okay so this section lays out four basic combos of security associations (SAs) that compliant IPsec hosts or security gateways MUST support 💅 these are the must-haves. You can also do other combos of AH and/or ESP in tunnel and/or transport modes if you want, that's up to the implementor 🎀 but the four core ones are non-negotiable. Compliant implementations MUST be capable of generating these four and, when they arrive, processing them too. They SHOULD be able to receive and process any combination, which is very much a "go the extra mile" vibe 🌸 The diagrams and text below cover the basic cases, and this is the legend for the diagrams:
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsecNOTE: The security associations below can be either AH or ESP 🧚 The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel.
Case 1. End-to-end security between 2 hosts ✨
The case of providing end-to-end security between 2 hosts across the Internet (or an Intranet) 🌈
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*Note that either transport or tunnel mode can be selected by the hosts. So the headers in a packet between H1 and H2 could look like any of the following:
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet. ⭐ Order matters here, bestie!
Case 2. Simple virtual private networks support 🏰
This case illustrates simple virtual private networks support.
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundaryOnly tunnel mode is required here. So the headers in a packet between SG1 and SG2 could look like either of the following:
Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]Case 3. Cases 1 and 2 combined 💜
This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. Lowkey a power move, honestly 🙈
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundaryCase 4. Remote host reaching an organization's firewall 🔥
This covers the situation where a remote host (H1) uses the Internet to reach an organization's firewall (SG2) and to then gain access to some server or other machine (H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall (SG2), etc. The details of support for this case, (how H1 locates SG2, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.6.3, "Locating a Security Gateway". Main character energy from a remote host, no cap 📱
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA serverOnly tunnel mode is required between H1 and SG2. So the choices for the SA between H1 and SG2 would be one of the ones in case 2. The choices for the SA between H1 and H2 would be one of the ones in case 1.
Note that in this case, the sender MUST apply the transport header before the tunnel header. Therefore the management interface to the IPsec implementation MUST support configuration of the SPD and SAD to ensure this ordering of IPsec header application. 🧁 Ordering is everything, babe.
As noted above, support for additional combinations of AH and ESP is optional.
Use of other, optional combinations may adversely affect interoperability. Be careful out there, bestie 🚨
4.6. SA and Key Management 🔑
IPsec mandates support for both manual and automated SA and cryptographic key management. ✨ The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti-replay services available for AH and ESP require automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. (See also a discussion of this issue in Section 4.7.) In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the authentication algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources. So basically, who shares the secret matters a LOT 🫶
The following text describes the minimum requirements for both types of SA management.
4.6.1. Manual Techniques 🌸
The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist.
4.6.2. Automated SA and Key Management 🤖
Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) 💅
The default automated key management protocol selected for use with IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed.
When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because:
- the encryption algorithm uses multiple keys (e.g., triple DES)
- the authentication algorithm uses multiple keys
- both encryption and authentication algorithms are employed
The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption key(s) MUST be taken from the first (left-most, high-order) bits and the authentication key(s) MUST be taken from the remaining bits. 🧠 This bit-ordering stuff is so important, it's giving strict. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm.
4.6.3 Locating a Security Gateway 🗺️
okay so this section is all about how a host finds out that security gateways even exist 🔍, and then how it knows they're the correct ones 🧐. Where that info gets stored is totally a local decision, not our problem 💅.
picture this: a remote host (H1) is trying to reach a server or other machine (H2) over the Internet, and there's a security gateway (SG2), like a firewall, that H1's traffic has to go through 🚧. A good example is a mobile host (Road Warrior) crossing the Internet to the home org's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This raises a few issues, bestie 😭:
- How does H1 know/learn about the existence of the security gateway SG2?
- How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2?
- How does SG2 authenticate H1 and verify that H1 is authorized to contact H2?
- How does H1 know/learn about backup gateways which provide alternate paths to H2?
so to handle all that, a host or security gateway MUST have an administrative interface that lets the user/administrator set the address of a security gateway for any sets of destination addresses that need it 🎀. This includes being able to configure:
- the requisite information for locating and authenticating the security gateway and verifying its authorization to represent the destination host.
- the requisite information for locating and authenticating any backup gateways and verifying their authorization to represent the destination host.
it's assumed that the SPD is also configured with policy information that covers any other IPsec requirements for the path to the security gateway and the destination host 📋.
this document does not address how to automate the discovery/verification of security gateways 🙅.
4.7 Security Associations and Multicast 🌸
the receiver-orientation of the Security Association means that, for unicast traffic, the destination system will normally select the SPI value 🎯. Because the destination picks it, there's no chance that manually configured Security Associations clash with automatically configured ones (e.g., via a key management protocol), or that Security Associations from multiple sources step on each other 🙌. multicast is messier, since there are multiple destination systems per multicast group. So some system or person will need to coordinate across all multicast groups to select an SPI or SPIs on behalf of each multicast group, and then pass the group's IPsec information to all of the legitimate members of that group via mechanisms not defined here 🤝.
Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to that group when a symmetric key encryption or authentication algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic 🫣. Specifications for other, more general multicast cases are deferred to later IPsec documents 📚.
at the time this spec was published, automated protocols for multicast key distribution were not considered adequately mature for standardization 🛠️. For multicast groups with relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. An example of current work in this area is the Group Key Management Protocol (GKMP) [HM97] 🔑.
5. IP Traffic Processing 🚦
as mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded 🚫.
NOTE: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order 🔢.
5.1 Outbound IP Traffic Processing 📤
5.1.1 Selecting and Using an SA or SA Bundle
in a security gateway or BITW implementation (and in many BITS implementations), each outbound packet is compared against the SPD to determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event 👀. If the traffic is allowed to bypass IPsec processing, the packet continues through "normal" processing for the environment in which the IPsec processing is taking place. If IPsec processing is required, the packet is either mapped to an existing SA (or SA bundle), or a new SA (or SA bundle) is created for the packet. Since a packet's selectors might match multiple policies or multiple extant SAs, and since the SPD is ordered but the SAD is not, IPsec MUST:
- Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD.
- Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet.
- Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt.
in a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created, to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket 🧦.
NOTE: A compliant implementation MUST not allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event 🚨.
5.1.2 Header Construction for Tunnel Mode 🎁
this section describes how the inner and outer IP headers, extension headers, and options are handled for AH and ESP tunnels. It covers how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP" 💫:
- The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, (from the perspective of this tunnel), respectively. (see footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.)
- The inner IP header is not changed except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point.
- No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel.
- If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header and the inner IP header.
the tables in the following sub-sections show the handling for the different header/option fields (constructed = the value in the outer field is constructed independently of the value in the inner) 📊.
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
TOS copied from inner hdr (5) no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragmt offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP, routing hdr no change
checksum constructed constructed (2)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change- The IP version in the encapsulating header can be different from the value in the inner header.
- The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The checksum changes when the TTL changes.)
Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTL's decremented, as the sending node is originating the packet rather than forwarding it.
- src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet.
NOTE: In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses (e.g., if it's acting as a NAT box), so long as the address is reachable through the encapsulator from the environment into which the packet is sent. This does not cause a problem because IPsec does not currently have any INBOUND processing requirement that involves the Source Address of the encapsulating IP header. So while the receiving tunnel endpoint looks at the Destination Address in the encapsulating IP header, it only looks at the Source Address in the inner (encapsulated) IP header 🧠.
- configuration determines whether to copy from the inner header (IPv4 only), clear or set the DF.
- If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner Hdr is IPv6 (Protocol = 41), map the Class to TOS.
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode 💖
Okay bestie, this is the IPv6 version of the tunnel header stuff, and you still need the notes from 5.1.2 (notes 1-5, the ones marked with footnote numbers) 🧚
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
class copied or configured (6) no change
flow id copied or configured no change
len constructed no change
next header AH,ESP,routing hdr no change
hop limit constructed (2) decrement (2)
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied no change- If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class. 🎀
5.2 Processing Inbound IP Traffic 📬
Okay so before any AH or ESP processing happens, IP fragments get reassembled first 🧩 Every inbound datagram that needs IPsec processing gets spotted by the AH or ESP value showing up in the IP Next Protocol field (or AH or ESP as an extension header when it's IPv6) 👀
Note: Appendix C has sample code for a bitmask check for a 32 packet window that you can use for anti-replay service 🛡️
5.2.1 Selecting and Using an SA or SA Bundle 🦋
Mapping the datagram to the right SA is actually easy because the SPI sits right there in the AH or ESP header ✨ Heads up though: the selector checks look at the inner headers, not the outer (tunnel) ones 🙈 Here's the flow:
- Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error. 💅
- Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy decides how specific the SA selectors are (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA may have a source address other than the one bound to the SA, so such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA. Some or all of these selectors may be inaccessible because of limits on how many bits of the problem packet the ICMP packet can carry, or because of encryption. See Section 6. 🔍
Do (1) and (2) for every IPsec header until you hit a Transport Protocol Header or an IP header that is NOT for this system. Keep track of which SAs were used and the order they were applied in 📝
- Find an incoming policy in the SPD that matches the packet. You could do this with backpointers from the SAs to the SPD, or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD 🗂️
- Check whether the required IPsec processing has been applied, i.e., verify that the SAs found in (1) and (2) match the kind and order of SAs required by the policy found in (3). 🧐
NOTE: The correct "matching" policy won't necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) get repeated until all policy entries have been checked or until the check succeeds. 🔁
At the end of these steps, pass the resulting packet up to the Transport Layer or forward the packet. Any IPsec headers processed in these steps may have been removed, but that info (what SAs were used and the order they were applied) may still be needed for later IPsec or firewall processing 🫶
Also, if you're a security gateway and forwarding sends a packet out through an IPsec-enabled interface, then extra IPsec processing may be applied 🌸
5.2.2 Handling of AH and ESP tunnels 🌈
The inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be handled as described in the tables in Section 5.1. Literally just go back to those tables, no cap 💜
6. ICMP Processing (relevant to IPsec) 🛸
This section is all about how ICMP error messages get handled. Other ICMP traffic, like Echo/Reply, should be treated like everything else and can be protected end-to-end with SAs in the usual way 💖
An ICMP error message that's protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy decides whether it gets subjected to source address checks by the router at the far end of the tunnel. Heads up: if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail 😭 An ICMP message protected by AH or ESP and generated by a router MUST NOT be forwarded on a transport mode SA (unless the SA was set up to the router acting as a host, e.g., a Telnet connection used to manage a router). An ICMP message generated by a host SHOULD be checked against the source IP address selectors bound to the SA it arrives on. Even if the source of an ICMP error message is authenticated, the returned IP header could still be invalid, so the selector values in the IP header SHOULD also be checked to make sure they're consistent with the selectors for the SA the ICMP message came in on 🧐
The table in Appendix D characterizes ICMP messages as host generated, router generated, both, or unknown/unassigned. ICMP messages in the last two categories should be handled as determined by the receiver's policy 📋
An ICMP message that's not protected by AH or ESP is unauthenticated, and processing and/or forwarding it may result in denial of service. So in general, it would be desirable to ignore such messages 🙅♀️ But many routers (vs. security gateways) aren't expected to implement IPsec for transit traffic, so strictly following that rule would get a lot of ICMP messages thrown out. Then some critical IP functions would be lost, like redirection and PMTU processing 😩 So it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic according to local security policy ⭐
The rest of this section covers how PMTU processing MUST be performed at hosts and security gateways. It handles both authenticated and unauthenticated ICMP PMTU messages. But like we said above, unauthenticated ICMP messages MAY be discarded based on local policy 🌷
6.1 PMTU/DF Processing 🍓
6.1.1 DF Bit 🧁
When a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). That means it MUST be possible to configure how the system treats the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.) 🎀
6.1.2 Path MTU Discovery (PMTU) 🛣️
This section talks about IPsec handling for Path MTU Discovery messages. Here, "ICMP PMTU" means an ICMP message for:
- IPv4 (RFC 792):
Type = 3 (Destination Unreachable)Code = 4 (Fragmentation needed and DF set)Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled "unused" in RFC 792), with high-order 16 bits set to zero
- IPv6 (RFC 1885):
Type = 2 (Packet Too Big)Code = 0 (Fragmentation needed)Next-Hop MTU in the 32 bit MTU field of the ICMP6 message
6.1.2.1 Propagation of PMTU 📣
The amount of info returned with the ICMP PMTU message (IPv4 or IPv6) is limited, and that affects which selectors you can use to keep propagating the PMTU info. (See Appendix B for the deeper dive on this 🧠)
- PMTU message with 64 bits of IPsec header -- If the ICMP PMTU message only has 64 bits of the IPsec header (the minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis:
- a. If the originating host can be determined (or the possible sources narrowed down to a manageable number), send the PM information to all the possible originating hosts. 🎯
- b. If the originating host can't be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the originating host for the relevant security association. If the packet(s) are bigger than the PMTU, drop the packet(s), compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host. Keep the PMTU info for any message that might arrive later (see Section 6.1.2.4, "PMTU Aging") ⏳
- PMTU message with >64 bits of IPsec header -- If the ICMP message has more info from the original packet, there may be enough non-opaque info to immediately figure out which host to propagate the ICMP/PMTU message to, and to give that system the 5 fields (source address, destination address, source port, destination port, transport protocol) it needs to decide where to store/update the PMTU. In that situation, a security gateway MUST generate an ICMP PMTU message immediately upon receiving an ICMP PMTU from further down the path 🚀
- Distributing the PMTU to the Transport Layer -- The host mechanism for getting the updated PMTU up to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). 🌈
6.1.2.2 Calculation of PMTU 🧮
The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPsec header: AH transport, ESP transport, AH/ESP transport, ESP tunnel, or AH tunnel. (See Appendix B for discussion of implementation issues.) 💜
Note: In some situations, adding IPsec headers could make the effective PMTU (as seen by the host or application) unacceptably small. To avoid this, the implementation may set a threshold below which it won't report a reduced PMTU. In that case, the implementation would apply IPsec and then fragment the resulting packet according to the PMTU. That leads to more efficient use of the available bandwidth 🦋
6.1.2.3 Granularity of PMTU Processing ✨
okay bestie, so PMTU processing in hosts can be done at different granularities 🦋 depending on how the implementation is set up. There are 3 situations 💅 that matter here (see Appendix B for the extra details 🧚):
- a. Integration of IPsec into the native IP implementation
- b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers
- c. No IPsec implementation. This case is included because it matters when a security gateway is sending PMTU information back to a host 🌸
Only in case (a) can the PMTU data be kept at the same granularity as communication associations 👑. In (b) and (c), the IP layer can only track PMTU data by source and destination IP addresses (and optionally TOS), as described in RFC 1191 🎀. This is a big deal, because more than one communication association can map to the same source and destination IP addresses, and each one might have a different amount of IPsec header overhead (e.g., because of different transforms or different algorithms) 😭.
How PMTU gets calculated, and whether PMTUs work per individual communication association, is a local matter 🫶. Still, a socket-based implementation of IPsec in a host SHOULD keep that information per socket 🍓. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after subtracting any IPsec header overhead those systems added 🔥. The overhead SHOULD be worked out by looking at the SPI and any other selector information in a returned ICMP PMTU message 💜.
6.1.2.4 PMTU Aging 🌈
In all systems (host or gateway) that implement IPsec and keep PMTU information, the PMTU tied to a security association (transport or tunnel) MUST be "aged" 💖, and there has to be some mechanism for updating the PMTU in a timely way ⭐. That's especially important for finding out if the PMTU is smaller than it needs to be 👀. A given PMTU has to stick around long enough for a packet to travel from the source end of the security association to the system at the other end, and for an ICMP error message to make its way back if the current PMTU is too big 🙈. Note that with nested tunnels, it might take multiple packets and round trip times to get an ICMP message back to an encapsulator or originating host 🧚.
Systems SHOULD use the approach from the Path MTU Discovery document (RFC 1191, Section 6.3) 🦋, which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as needed ✨. The period SHOULD be configurable 🎀.
7. Auditing 📝
Not every system that implements IPsec will do auditing 🙃. For the most part, the granularity of auditing is a local matter 💅. But several auditable events are identified in the AH and ESP specifications, and for each of these events a minimum set of information SHOULD be included in an audit log 🔥. Additional information also MAY be included in the audit log for each of these events, and additional events that aren't explicitly called out in this specification also MAY result in audit log entries 🌸. There's no requirement for the receiver to send any message back to the purported transmitter when it detects an auditable event, because that could be used to cause denial of service 😭🚨.
8. Use in Systems Supporting Information Flow Security 🔐
Information at different sensitivity levels can travel over a single network 🌍. Information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, DoD87] are often used to tell it apart 🏷️. Labels make it easier to segregate information, which supports information flow security models, e.g., the Bell-LaPadula model [BL73] 👑. Those models, and the technology that supports them, are designed to stop sensitive information from flowing where it shouldn't, even when Trojan Horse attacks are involved 🐴💀. Conventional discretionary access control (DAC) mechanisms, e.g., ones based on access control lists, usually aren't enough for these policies 🙅♀️, so facilities like the SPD don't cut it in these environments 😤.
In the military context, technology that supports these models is often called multi-level security (MLS) 🎖️. Computers and networks are often called "multi-level secure" if they support keeping labelled data separated alongside information flow security policies 🛡️. MLS technology is useful well beyond the military, but this document uses the acronym "MLS" for the technology anyway, to match a lot of the existing literature 📚✨.
IPsec mechanisms can easily support MLS networking 🙌. MLS networking needs strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes can't control or violate 🔒. This section is only about using these IP security mechanisms in MLS (information flow security policy) environments 💜. Nothing in this section applies to systems that don't claim to provide MLS 🙈.
In this section, "sensitivity information" might include implementation-defined hierarchic levels, categories, and/or releasability information 🧾.
AH can be used to provide strong authentication to support mandatory access control decisions in MLS environments 🔑. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used, and confidentiality isn't considered necessary in that particular operational environment, AH can be used to authenticate the binding between the sensitivity labels in the IP header and the IP payload (including user data) 🫶. This is a huge upgrade over labeled IPv4 networks, where sensitivity information is trusted even though nothing authenticates it or cryptographically binds it to the IP header and user data 😭. IPv4 networks might or might not use explicit labelling 🤷♀️. IPv6 will normally use implicit sensitivity information that's part of the IPsec Security Association but isn't sent with each packet, instead of using explicit sensitivity information ✨. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both 🔥.
Encryption is useful, and can be desirable, even when all of the hosts are inside a protected environment, for example behind a firewall or disconnected from any external connectivity 🏰. ESP can be used, together with appropriate key management and encryption algorithms, to support both DAC and MAC 💖. (The choice of encryption and authentication algorithms, plus the assurance level of an IPsec implementation, will decide which environments an implementation can be considered sufficient for MLS requirements 🧐.) Key management can use sensitivity information to provide MAC 🗝️. IPsec implementations on systems that claim to provide MLS SHOULD be able to use IPsec to provide MAC for IP-based communications 🌸.
8.1 Relationship Between Security Associations and Data Sensitivity 🔗
Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide multi-level secure networking 🌈. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information 💅. For example, "PROPRIETARY - Internet Engineering" MUST be associated with a different SA (or SA bundle) than "PROPRIETARY - Finance" 🙅♀️.
8.2 Sensitivity Consistency Checking 🧐
An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information, with an interface, or with a configured IP address and its associated prefix (the latter is sometimes called a logical interface, or an interface alias) 🎀. If those properties exist, an implementation SHOULD compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix the packet arrived from, or will leave through 🦋. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix ✨.
The checking SHOULD be done on both inbound and outbound processing 🔄.
8.3 Additional MLS Attributes for Security Association Databases 🗂️
Section 4.4 talked about two Security Association databases (the Security Policy Database (SPD) and the Security Association Database (SAD)) and the policy selectors and SA attributes that go with them 📖. MLS networking adds one more selector/attribute 🧚:
- Sensitivity information.
Sensitivity information helps pick the right algorithms and key strength, so the traffic gets a level of protection that matches how important or sensitive it is, as described in section 8.1 💖. The exact syntax of sensitivity information is implementation defined 🤓.
8.4 Additional Inbound Processing Steps for MLS Networking 📥
After an inbound packet has gone through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) against the interface or address/prefix, as described in section 8.2 🔍. Only then should it deliver the datagram to an upper-layer protocol or forward it 🙌.
The MLS system MUST keep the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing 🔐. That way, appropriate policy decisions can be made when the datagram is delivered to an application or forwarding engine 💅. The means for maintaining this binding are implementation specific 🛠️.
8.5 Additional Outbound Processing Steps for MLS Networking 📤
An MLS implementation of IPsec MUST perform two additional checks on top of the normal steps detailed in section 5.1.1 💪. When it consults the SPD or the SAD to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an appropriate outbound SA or SA bundle 🎯. The second check happens before the packet is forwarded out to its destination, and it's the sensitivity consistency checking described in section 8.2 ✅.
8.6 Additional MLS Processing for Security Gateways 🏰
An MLS security gateway MUST follow the inbound and outbound processing rules mentioned earlier, and MUST also perform some additional processing for the intermediate protection of packets in an MLS environment 👑.
A security gateway MAY act as an outbound proxy, creating SAs for MLS systems that originate packets the gateway forwards 🎁. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it 🌐. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect the traffic it forwards 🔐.
Similarly, such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward them appropriately, using explicit packet labeling or relying on the sensitivity characteristics of the destination network 🫶✨
9. Performance Issues ⚡
okay so IPsec is not free, bestie 💅 running it costs the hosts and security gateways doing the work some computing power. there's the memory for IPsec's code and data structures, the math for integrity check values, encrypting and decrypting, and extra handling for every single packet. the per-packet costs show up as more latency and maybe lower throughput 🫠 then there's the SA/key management stuff, especially anything using public key crypto, which adds its own cost. those per-association costs show up as slower association setup. for a lot of hosts, software crypto isn't expected to noticeably hurt throughput, but security gateways (since they're the aggregation points) and some hosts might need hardware 🔥
IPsec also costs bandwidth across the rest of the Internet, the transmission, switching, and routing gear that doesn't run IPsec at all 🌐 the packets get bigger because of the AH and/or ESP headers, AH and ESP tunneling adds a whole second IP header, and key management traffic adds more packets on top. the good news is that in most cases this extra bandwidth demand won't noticeably affect the Internet infrastructure ✨ but sometimes it can matter a lot, like sending ESP encrypted traffic over a dialup link that would otherwise have been compressed. big yikes 😭
Note: The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet. 🙈
Note: As discussed earlier, compression can still be employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by IPsec protocols." so compression is still on the table above IP, periodt 🧚
10. Conformance Requirements 🎀
okay this part is serious, no cap. all IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. all IPv6 systems MUST comply with all requirements of the Security Architecture document. no skipping, no vibes-only compliance 💅
11. Security Considerations 🔒
this whole document is about security, so security considerations are literally everywhere in this spec 🫶 the whole thing is basically one giant security consideration 👑
12. Differences from RFC 1825 🦋
this architecture doc is pretty different from RFC 1825 in both the details and the organization, but the core ideas are the same ✨ it adds a lot more detail on compliance specs. it introduces the SPD and SAD, plus the idea of SA selectors. it lines up with the new versions of AH and ESP, which are also different from their predecessors. specific requirements for supported combinations of AH and ESP are new, and so are the details of PMTU management. main character glow-up 🌸
Acknowledgements 💜
so many of the concepts in this spec came from or were influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security 🌈
for over 3 years (although it sometimes seems much longer), this document went through multiple versions and iterations 😭 tons of people put in serious ideas and energy, both into the process and the documents themselves. the authors want to thank Karen Seo for doing a huge amount of review, editing, background research, and coordination for this version of the spec 🫶 they also want to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, Harry Varnis, and Nina Yuan. legends only 👑
Appendix A -- Glossary 📖
this section defines some key terms used in this document. other docs give more definitions and background, e.g., [VK83, HA94]. the glossary includes generic security service and security mechanism terms, plus IPsec-specific ones 🧚
Access Control
access control is a security service that prevents unauthorized use of a resource, including preventing use of a resource in an unauthorized manner. in the IPsec context, the resource being controlled is often:
- for a host, computing cycles or data
- for a security gateway, a network behind the gateway or bandwidth on that network.
Anti-replay
[See "Integrity" below] 🔁
Authentication
this term is used informally to refer to two nominally distinct security services combined: data origin authentication and connectionless integrity. see the definitions below for each of these services 🔐
Availability
availability, as a security service, deals with security concerns from attacks against networks that deny or degrade service ⏰ for example, in the IPsec context, the use of anti-replay mechanisms in AH and ESP supports availability.
Confidentiality
confidentiality is the security service that protects data from unauthorized disclosure 🤫 the main confidentiality concern in most cases is unauthorized disclosure of application level data, but disclosure of the external characteristics of communication can also be a concern in some situations. traffic flow confidentiality is the service that handles that second concern by hiding source and destination addresses, message length, or frequency of communication. in the IPsec context, using ESP in tunnel mode, especially at a security gateway, can give some level of traffic flow confidentiality. (see also traffic analysis, below.)
Encryption
encryption is a security mechanism that transforms data from an intelligible form (plaintext) into an unintelligible form (ciphertext) to provide confidentiality 🔐 the inverse process is called "decryption". oftimes the term "encryption" is used to generically refer to both processes.
Data Origin Authentication
data origin authentication is a security service that verifies the identity of the claimed source of data 🪪 this service is usually bundled with connectionless integrity service.
Integrity
integrity is a security service that makes sure modifications to data are detectable 🧩 integrity comes in different flavors to match application requirements. IPsec supports two forms of integrity: connectionless, and a form of partial sequence integrity. connectionless integrity detects modification of an individual IP datagram, without regard to its ordering in a stream of traffic. the form of partial sequence integrity offered in IPsec is called anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). this is different from connection-oriented integrity, which has stricter sequencing requirements on traffic, e.g., to be able to detect lost or re-ordered messages. although authentication and integrity services are often cited separately, in practice they're intimately connected and almost always offered together 💞
Security Association (SA)
a simplex (uni-directional) logical connection, created for security purposes. all traffic traversing an SA gets the same security processing 🔑 in IPsec, an SA is an internet layer abstraction implemented through the use of AH or ESP.
Security Gateway
a security gateway is an intermediate system that acts as the communications interface between two networks 🚪 the set of hosts (and networks) on the external side of the security gateway is viewed as untrusted (or less trusted), while the networks and hosts on the internal side are viewed as trusted (or more trusted). the internal subnets and hosts served by a security gateway are presumed trusted because they share a common, local, security administration. (see "Trusted Subnetwork" below.) in the IPsec context, a security gateway is a point where AH and/or ESP is implemented to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also using IPsec (either directly or via another security gateway).
SPI
SPI is short for "Security Parameters Index" 🏷️ the combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). the SPI is carried in AH and ESP so the receiving system can select the SA a received packet gets processed under. an SPI only has local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI), so an SPI is generally treated as an opaque bit string. however, the creator of an SA may choose to interpret the bits in an SPI to make local processing easier.
Traffic Analysis
traffic analysis is analyzing network traffic flow to deduce information useful to an adversary 🕵️ examples include frequency of transmission, the identities of the conversing parties, sizes of packets, flow identifiers, etc. [Sch94]
Trusted Subnetwork
a subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks 🤝 there's also an assumption that the underlying communications channel (e.g., a LAN or CAN) isn't being attacked by other means.
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues 🧵
B.1 DF bit 🎀
Okay bestie, the big question is this: when a system (host or gateway) wraps a packet in a new encapsulating header, like an ESP tunnel, should/must the DF bit from the original packet get copied onto that outer header? 🤔
Fragmenting makes sense in some situations. For example, it might be smart to fragment packets going over a network with a super tiny MTU, like a packet radio network or a cellular phone hop to a mobile node 📱. That's better than sending a really small PMTU back so the whole rest of the path has to use it 🙅♀️. In other situations, you might want to set the DF bit so you can get feedback from later routers about PMTU constraints that force fragmentation 📡.
Both of these situations are real, so a system needs to be able to decide whether to fragment over a particular network "link" 🔗. That means an implementation has to be able to copy the DF bit (and process ICMP PMTU messages), but copying should be an option picked on a per-interface basis 💅. In other words, an administrator should be able to configure how the router treats the DF bit for each interface: set, clear, or copy from the encapsulated header ⚙️.
Note: If a bump-in-the-stack implementation of IPsec tries to apply different IPsec algorithms based on source/destination ports, it's going to be really hard to apply Path MTU adjustments 😭.
B.2 Fragmentation 🧩
If fragmentation is needed, it happens after IPsec processing inside an IPsec implementation ✨. So transport mode AH or ESP only ever gets applied to whole IP datagrams, never to IP fragments 💖. An IP packet with AH or ESP applied can still get fragmented by routers along the way, and those fragments MUST be reassembled before IPsec processing happens at a receiver 🫶.
In tunnel mode, AH or ESP gets applied to an IP packet whose payload might itself be a fragmented IP packet 🎀. For example, a security gateway, a "bump-in-the-stack" (BITS) implementation, or a "bump-in-the-wire" (BITW) IPsec implementation might apply tunnel mode AH to fragments like these 🌈. BITS and BITW implementations are examples of where a host IPsec implementation might receive fragments that tunnel mode needs to be applied to 🧚. But if transport mode is the one being applied, these implementations MUST reassemble the fragments before applying IPsec 🔥.
NOTE: IPsec always has to figure out what the encapsulating IP header fields are 🤓. This is true no matter where you insert IPsec, and it's basically baked into what IPsec is. So any IPsec implementation that isn't integrated into an IP implementation has to include code that builds the necessary IP headers (for example, IP2) 🛠️:
o AH-tunnel --> IP2-AH-IP1-Transport-Data
o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer*********************************************************************Overall, the fragmentation/reassembly approach described above works for all of the cases examined 🎉.
AH Xport AH Tunnel ESP Xport ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor ** If the crypto processor system has its own IP address, then it's covered by the security gateway case 🏰. This box gets the packet from the host and does the IPsec processing. It has to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle 💪. If it doesn't have its own address, then it's similar to the bump-in-the-stack implementation between IP and the network drivers 🧸.
The following analysis assumes that:
- There is only one IPsec module in a given system's stack. There isn't an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPsec module B 🙅♀️.
- There are several places where IPsec could be implemented (as shown in the table above):
- a. Hosts with integration of IPsec into the native IP implementation. The implementer has access to the source for the stack 💻.
- b. Hosts with bump-in-the-stack implementations, where IPsec is implemented between IP and the local network drivers. Source access for the stack isn't available, but there are well-defined interfaces that allow the IPsec code to be incorporated into the system 🔌.
- c. Security gateways and outboard crypto processors with integration of IPsec into the stack 🚪.
- Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible 🥰.
For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes. That's a total of 24 cases (3 x 2 x 4) 🧮.
Some header fields and interface fields are listed here for ease of reference. They're not in header order. They're listed so you can compare them across the columns 👀. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.)
IP/Transport Interface
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt ? = AH covers Option-Type and Option-Length, but
might not cover Option-Data.The results for each of the 20 cases are shown below ("works" = will work if the system fragments after outbound IPsec processing and reassembles before inbound IPsec processing) 🦋. The notes point out implementation issues 📝.
a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- worksb. Hosts (bump-in-the-stack). Here IPsec sits between the IP layer and the network drivers. In this case, the IPsec module would have to do something like one of the following for fragmentation and reassembly 🧩:
- do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel end is at the ultimate destination, this is fine too. But in AH or ESP tunnel modes where the tunnel end is different from the ultimate destination and the source host is multi-homed, this approach could result in sub-optimal routing 🛣️. That's because the IPsec module may be unable to get the information it needs (LAN interface and next-hop gateway) to direct the packet to the right network interface. This isn't a problem if the interface and next-hop gateway are the same for the ultimate destination and the tunnel end. But if they're different, IPsec would need to know the LAN interface and the next-hop gateway for the tunnel end. (Note: The tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall 🔥.) OR
- pass the IPsec'd packet back to the IP layer, where an extra IP header would end up being pre-pended, and the IPsec module would have to check and let IPsec'd fragments go by. OR
- pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header 🎁.
At the network layer, the IPsec module will have access to the following selectors from the packet: SRC address, DST address, Next Protocol, and, if there's a transport layer header, SRC port and DST port 👑. You can't assume IPsec has access to the Name 🙈. It's assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s) 💜.
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- worksc. Security gateways, which integrate IPsec into the IP stack 🏢.
NOTE: The IPsec module will have access to the following selectors from the packet: SRC address, DST address, Next Protocol, and, if there's a transport layer header, SRC port and DST port. It won't have access to the User ID, since only hosts have User ID information 🙃. Unlike some bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name. That's handy in situations involving dynamically assigned IP addresses together with dynamically updated DNS entries 🌸. It also won't have access to the transport layer information if there's an ESP header, or if it's not the first fragment of a fragmented message 😬. It's assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s) ✨.
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works**********************************************************************B.3 Path MTU Discovery ✨
Okay bestie, quick refresher 🦋: "ICMP PMTU" is the ICMP message used for Path MTU Discovery, and it's the main character of this whole section 💅
The legend for the diagrams in B.3.1 and B.3.3 (but not B.3.2) is:
==== = security association (AH or ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for
IPv4:
- Type = 3 (Destination Unreachable)
- Code = 4 (Fragmentation needed and DF set)
- Next-Hop MTU in the low-order 16 bits of the second
word of the ICMP header (labelled unused in RFC 792),
with high-order 16 bits set to zero
IPv6 (RFC 1885):
- Type = 2 (Packet Too Big)
- Code = 0 (Fragmentation needed and DF set)
- Next-Hop MTU in the 32 bit MTU field of the ICMP6
Hx = host x
Rx = router x
SGx = security gateway x
X* = X supports IPsecB.3.1 Identifying the Originating Host(s)
Okay so the amount of info that comes back inside an ICMP message is pretty limited 🙈 and that totally affects which selectors you can use to figure out which security associations and originating hosts are involved, which you need for passing the PMTU info along to the right place 🧚
In brief... an ICMP message must contain the following information from the "offending" packet:
- IPv4 (RFC 792) -- IP header plus a minimum of 64 bitsSo in the IPv4 world, an ICMP PMTU might only identify the first (outermost) security association 😭 Only 64 bits of the "offending" packet past the IP header come back, and that's just enough to grab the first SPI from AH or ESP. In the IPv6 world, an ICMP PMTU will probably give you all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. And if ESP is in use, the transport ports and protocol selectors might be encrypted, so they're hidden too 🔒
Let's look at this security gateway tunnel diagram (as mentioned elsewhere, security gateways do not use transport mode) 🦋
H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4Say SG1's security policy is to use one single SA to SG2 for all the traffic between H0, H1, and H2 and H3, H4, and H5. Now H0 sends a data packet to H5, and that causes R1 to send an ICMP PMTU message back to SG1. If the PMTU message only has the SPI, SG1 can look up the SA and find the list of possible hosts (H0, H1, H2, wildcard), but it has no way to tell that H0 was the one who sent the traffic that set off the ICMP PMTU message 💀
original after IPsec ICMP
packet processing packet
-------- ----------- ------
IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header IP-2 header (S = SG1, D = SG2)
ESP header minimum of 64 bits of ESP hdr (*)
IP-1 header IP-1 header
TCP header TCP header
TCP data TCP data
ESP trailer (*) The 64 bits will include enough of the ESP (or AH) header to
include the SPI.
- ESP -- SPI (32 bits), Seq number (32 bits)
- AH -- Next header (8 bits), Payload Len (8 bits),
Reserved (16 bits), SPI (32 bits)This limit on what comes back in an ICMP message makes it tricky to figure out the originating hosts (so you know where to keep passing the ICMP PMTU info along) 🌸 If the ICMP message only has 64 bits of the IPsec header (the minimum for IPv4), the IPsec selectors (like Source and Destination addresses, Next Protocol, Source and Destination ports, and so on) are gone. But the ICMP error message will still give SG1 the SPI, the PMTU information, and the source and destination gateways for the relevant security association. Lowkey clutch ✨
The destination security gateway and the SPI together uniquely define a security association, and that SA in turn defines a set of possible originating hosts. So at this point, SG1 could:
- a. send the PMTU information to all the possible originating hosts. This wouldn't work well if the host list is a wildcard or if many or most of the hosts weren't sending to SG1. It might work if the SPI/destination/etc. maps to just one host or a small number of them 🙈
- b. store the PMTU with the SPI/etc. and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If those packet(s) are bigger than the PMTU, drop them, build new ICMP PMTU message(s) using the new packet(s) and the updated PMTU, and send those ICMP message(s) to the originating host(s) to flag the problem. Yes, this means a delay in telling the originating host(s), but it avoids the problems of (a) 🫶
Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, there might be enough info to immediately figure out which host to pass the ICMP/PMTU message to, and to give that system the 5 fields (source address, destination address, source port, destination port, and transport protocol) it needs to figure out where to store/update the PMTU. In those cases, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field may not be contained in the ICMP message, and the use of ESP encryption may hide the selector fields that have been encrypted 🔐
B.3.2 Calculation of PMTU
Calculating PMTU from an ICMP PMTU has to account for any IPsec header that H1 adds, whether that's AH and/or ESP transport, or ESP or AH tunnel 🎀 Within a single host, multiple applications may share an SPI, and nesting of security associations may happen too. (See Section 4.5 Basic Combinations of Security Associations for a description of the combinations that MUST be supported.) The diagram below shows an example of security associations between a pair of hosts, as seen from one of the hosts (ESPx or AHx = transport mode) 🦋
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- InternetTo figure out the PMTU for each socket that maps to SPI-B, you need backpointers from SPI-B to each of the 2 paths that lead to it: Socket 1 and Socket 2/SPI-A 🧚
B.3.3 Granularity of Maintaining PMTU Data
In hosts, how finely PMTU ICMP processing can be done depends on the implementation situation 🌈 From a host's point of view, there are three situations that matter for PMTU issues:
- a. Integration of IPsec into the native IP implementation
- b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing TCP/IP protocol stack, between the native IP and the local network drivers
- c. No IPsec implementation. This case is included because it's relevant when a security gateway is sending PMTU information back to a host 💜
Only in case (a) can PMTU data be kept at the same granularity as communication associations. In the other cases, the IP layer keeps PMTU data at the granularity of Source and Destination IP addresses (and optionally TOS/Class), as described in RFC 1191. This is a big deal 👑 because more than one communication association can map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (for example, because it uses different transforms or different algorithms). The examples below show this 🫶
In cases (a) and (b), let's say H1 is sending to H2, and the packet R1 has to send to R2 is bigger than the PMTU of the network hop between them.
==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|If R1 is configured to not fragment subscriber traffic, R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing depends on how it's implemented. In case (a), which is native IP, the security services are bound to sockets or the equivalent, so the IP/IPsec implementation in H1 can store/update the PMTU for the associated socket ✨ In case (b), the IP layer in H1 can store/update the PMTU, but only at the granularity of Source and Destination addresses and possibly TOS/Class, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination 🙈
In case (c), there has to be a security gateway for any IPsec processing to happen at all. So let's say H1 is sending to H2, and the packet SG1 has to send to R is bigger than the PMTU of the network hop between them.
================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|Same deal as case (b): the IP layer in H1 can store/update the PMTU, but only at the granularity of Source and Destination addresses, and possibly TOS/Class. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination 💀
B.3.4 Per Socket Maintenance of PMTU Data
Implementing the PMTU calculation (Section B.3.2) and supporting PMTUs at the granularity of individual "communication associations" (Section B.3.3) is a local matter 🏠 That said, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per-socket basis. Bump-in-the-stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead those systems added. The overhead SHOULD be determined by analyzing the SPI and any other selector information present in a returned ICMP PMTU message 👑
B.3.5 Delivery of PMTU Data to the Transport Layer
The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery) 🌸
B.3.6 Aging of PMTU Data
This topic is covered in Section 6.1.2.4 🧚
Appendix C -- Sequence Space Window Code Example ✨
okay so this appendix is a little C routine that does a bitmask check for a 32 packet window 🎀 It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com), and it's meant as an implementation example, not a rule book 💅
ngl this next bit is the important part 🫶 The code both checks for a replay AND updates the window in one go. So the algorithm, as shown, should only be called AFTER the packet has been authenticated 🔐 Otherwise you're updating state off a packet that might be fake 😭
Implementers might wish to consider splitting the code so the replay check happens before computing the ICV. If the packet is not a replay, the code would then compute the ICV, discard any bad packets, and only if the packet is OK, update the window. It's giving careful, it's giving secure 🌸
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
enum {
ReplayWindowSize = 32
};
u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */
/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);
int ChkReplayWindow(u_long seq) {
u_long diff;
if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}
char string_buffer[512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)
int main() {
int result;
u_long last, current, bits;
printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}Appendix D -- Categorization of ICMP messages 🦋
okay so these tables sort ICMP messages into four vibes: host generated, router generated, both router and host generated, and unassigned/unknown generator 🧚 The first set is IPv4 and the second set is IPv6 💜
IPv4
Type Name/Codes Reference
========================================================================
HOST GENERATED:
3 Destination Unreachable
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
8 Source Host Isolated [RFC792]
14 Host Precedence Violation [RFC1812]
10 Router Selection [RFC1256]
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
3 Destination Unreachable
0 Net Unreachable [RFC792]
4 Fragmentation Needed, Don't Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC792]
7 Destination Host Unknown [RFC792]
9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792]
11 Destination Network Unreachable for Type of Service[RFC792]
5 Redirect
0 Redirect Datagram for the Network (or subnet) [RFC792]
2 Redirect Datagram for the Type of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]
IPv4
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
0 Echo Reply [RFC792]
3 Destination Unreachable
1 Host Unreachable [RFC792]
10 Comm. w/Dest. Host is Administratively Prohibited [RFC792]
12 Destination Host Unreachable for Type of Service [RFC792]
13 Communication Administratively Prohibited [RFC1812]
15 Precedence cutoff in effect [RFC1812]
4 Source Quench [RFC792]
5 Redirect
1 Redirect Datagram for the Host [RFC792]
3 Redirect Datagram for the Type of Service and Host [RFC792]
6 Alternate Host Address [JBP]
8 Echo [RFC792]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792,RFC1108]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [Johnson]
39 SKIP [Markson]
40 Photuris [Simpson]
Type Name/Codes Reference
========================================================================
UNASSIGNED TYPE OR UNKNOWN GENERATOR:
1 Unassigned [JBP]
2 Unassigned [JBP]
7 Unassigned [JBP]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
33 IPv6 Where-Are-You [Simpson]
34 IPv6 I-Am-Here [Simpson]
35 Mobile Registration Request [Simpson]
36 Mobile Registration Reply [Simpson]
37 Domain Name Request [Simpson]
38 Domain Name Reply [Simpson]
41-255 Reserved [JBP]
IPv6
Type Name/Codes Reference
========================================================================
HOST GENERATED:
1 Destination Unreachable [RFC 1885]
4 Port Unreachable
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
1 Destination Unreachable [RFC1885]
0 No Route to Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a Neighbor
3 Address Unreachable
2 Packet Too Big [RFC1885]
0
3 Time Exceeded [RFC1885]
0 Hop Limit Exceeded in Transit
1 Fragment reassembly time exceeded
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
4 Parameter Problem [RFC1885]
0 Erroneous Header Field Encountered
1 Unrecognized Next Header Type Encountered
2 Unrecognized IPv6 Option EncounteredReferences ✨
okay bestie, this is the bibliography 📚🫶 every source the authors leaned on, and I'm keeping every single one exactly as written, because citations are the receipts 💅
- [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973.
- [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
- [DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985.
- [DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987.
- [HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
- [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [HM97] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
- [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
- [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993.
- [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio
- [KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, November 1991.
- [MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
- [Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
- [Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
- [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
- [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990.
- [SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.
- [TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
- [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
Disclaimer 🎀
the views and specs in here are the authors' own, not necessarily their employers' 💼 and the authors and their employers are totally not responsible for any problems that happen from implementing or using this design, whether that's done right or wrong 🙈
Author Information 🦋
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson
@Home Network
425 Broadway
Redwood City, CA 94063
USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.netCopyright 🌈
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💜
📦 where this page comes from
- ietf: rfc2401 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms