RFC 3715

RFC 3715 📜 IPsec-Network Address Translation (NAT) Compatibility Requirements 🎀

Okay bestie, this is RFC 3715, titled IPsec-Network Address Translation (NAT) Compatibility Requirements. It was written by B. Aboba and W. Dixon from Microsoft in March 2004. Its category is Informational, so it's giving "here's some useful info," not "here's a rule you must follow." 💅 The header doesn't list anything it obsoletes or updates, so it's a standalone doc. 🦋

Status of this Memo ✨

This memo is here to provide info for the Internet community. It is not a standard of any kind, and distribution is unlimited. 🌸

Copyright Notice 🌈

Copyright (C) The Internet Society (2004). All Rights Reserved. 🫶

Abstract 💖

Okay, so the abstract is basically the whole tea ☕. IPsec and NAT don't get along, and it's a real problem. 😭 The doc describes the known incompatibilities between Network Address Translation (NAT) and IPsec, and lays out what's needed to fix them. 🔥

Here's the main drama: IPsec is hugely popular for virtual private networking, especially for telecommuters who want to get into the corporate Intranet from home. NATs are everywhere now, in home gateways and in places telecommuters are likely to be, like hotels 🧳. So the IPsec-NAT clash has become a major barrier to deploying IPsec in one of its biggest use cases. Not a vibe. 💀

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1.  Requirements Language. . . . . . . . . . . . . . . . . .  2
   2.  Known Incompatibilities between NA(P)T and IPsec . . . . . . .  3
       2.1.  Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . .  3
       2.2.  NA(P)T Implementation Weaknesses . . . . . . . . . . . .  7
       2.3.  Helper Incompatibilities . . . . . . . . . . . . . . . .  8
   3.  Requirements for IPsec-NAT Compatibility . . . . . . . . . . .  8
   4.  Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12
       4.1.  IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12
       4.2.  RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       4.3.  6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
       6.1.  Normative References . . . . . . . . . . . . . . . . . . 15
       6.2.  Informative References . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18

---

1. Introduction 🧚

Okay so IPsec [RFC2401] is the go-to for virtual private networking (VPN) 🔐, and one of the most popular things people do with VPNs is get telecommuter access to the corporate Intranet. Network Address Translations (NATs), as described in [RFC3022] and [RFC2663], are now widely deployed in home gateways and in other spots telecommuters tend to be, like hotels 🏨. The result is that IPsec-NAT incompatibilities have turned into a major barrier to deploying IPsec for one of its principal uses. Iconic, not in a good way 😭. This document describes those known NAT/IPsec incompatibilities and explains what's required to address them ✨.

1.1. Requirements Language 📝

Here's how the key words work in this doc 🎀. The terms "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are interpreted as described in [RFC2119]. Only the capitalized ones are the official key words, so keep an eye on those 👀.

Also, the requirements in this document are meant for evaluating protocol submissions 🧐. The requirements language is about the capabilities of those protocols. The protocol documents themselves decide whether a feature is required, recommended, or optional. For example, requiring that a protocol support confidentiality is not the same thing as requiring that all protocol traffic be encrypted 🔒. Totally different vibes!

Now the compliance tea ☕. A protocol submission is not compliant if it fails one or more of the MUST or MUST NOT requirements for the capabilities it implements. If a submission satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT requirements for its capabilities, it's called "unconditionally compliant" 👑. If it satisfies all the MUST and MUST NOT requirements, but not all the SHOULD or SHOULD NOT requirements for its protocols, it's called "conditionally compliant." Still valid, just a little less perfect 💅.

2. Known Incompatibilities between NA(P)T and IPsec 🍓

Okay, the NA(P)T and IPsec incompatibilities fall into three categories, and honestly each one is its own kind of messy 😩:

1. Intrinsic NA(P)T issues. These come straight from the NA(P)T functionality described in [RFC3022]. That means they show up in any NA(P)T device, no exceptions 🙅‍♀️.
2. NA(P)T implementation weaknesses. These aren't intrinsic to NA(P)T, but they're present in lots of NA(P)T implementations. This category includes problems handling inbound or outbound fragments 🧩. Since they aren't intrinsic, they could, in principle, be addressed in future NA(P)T implementations 🌟. BUT the implementation problems seem really widespread, so they need to be taken into account in a NA(P)T traversal solution anyway. Not optional, bestie 🫠.
3. Helper issues. These show up in NA(P)T devices that try to provide IPsec NA(P)T traversal. The irony is so real 💀: this "helper" functionality creates more incompatibilities, which makes an already hard problem even harder to solve 🙃. IPsec traversal "helper" functionality isn't in every NA(P)T, but these features are getting popular enough that they also need to be taken into account in a NA(P)T traversal solution 📈.

Part 2 is coming up next, so stay tuned, bestie 🦋💜

2.1. Intrinsic NA(P)T Issues ✨

okay so these are the problems that are baked right into NA(P)T itself, no cap 💅 Here's the list:

a) Incompatibility between IPsec AH [RFC2402] and NAT 😭 AH bakes the IP source and destination addresses into its keyed message integrity check. So when a NAT or reverse NAT box changes those address fields, the integrity check breaks. ESP [RFC2406] doesn't include the IP source and destination addresses in its keyed integrity check, so this issue doesn't happen for ESP. 🫶

b) Incompatibility between checksums and NAT 🧮 TCP and UDP checksums depend on the IP source and destination addresses, because the "pseudo-header" gets included in the calculation. So wherever checksums get calculated and checked on receipt, they'll be invalidated once a NAT or reverse NAT box touches the packet. 💔

This is why IPsec Encapsulating Security Payload (ESP) only gets through a NAT smoothly if TCP/UDP isn't involved (like in IPsec tunnel mode or IPsec protected GRE), or if checksums aren't calculated (which is possible with IPv4 UDP). As described in [RFC793], TCP checksum calculation and verification is required in IPv4. UDP/TCP checksum calculation and verification is required in IPv6. 🎀

Stream Control Transmission Protocol (SCTP), defined in [RFC2960] and [RFC3309], uses a CRC32C algorithm that's calculated only over the SCTP packet (common header + chunks). The IP header isn't covered, so NATs don't invalidate the SCTP CRC and the problem just doesn't show up. ✨

Also, transport mode IPsec traffic is integrity protected and authenticated with strong cryptography, so modifications to the packet can be detected before UDP/TCP checksums get checked. Which means checksum verification only really gives you assurance against errors made in internal processing. 🙈

c) Incompatibility between IKE address identifiers and NAT 🪪 When IP addresses are used as identifiers in Internet Key Exchange Protocol (IKE) Phase 1 [RFC2409] or Phase 2, a NAT or reverse NAT changing the IP source or destination addresses creates a mismatch between the identifiers and the addresses in the IP header. As described in [RFC2409], IKE implementations are required to discard such packets. 💀

To dodge using IP addresses as IKE Phase 1 and Phase 2 identifiers, you can use userIDs and FQDNs instead. If user authentication is what you want, you can use an ID type of ID_USER_FQDN, as described in [RFC2407]. If machine authentication is what you want, you can use an ID type of ID_FQDN. Either way, you need to verify that the proposed identifier gets authenticated as a result of processing an end-entity certificate, if certificates are exchanged in Phase 1. USER_FQDN or FQDN identity types are possible within IKE, but there are usage scenarios (e.g. Security Policy Database (SPD) entries describing subnets) that can't be accommodated this way. 😤

Since the source address in the Phase 2 identifier is often used to build a full 5-tuple inbound SA selector, the destination address, protocol, source port and destination port can be used in the selector so inbound SA processing doesn't get weakened. 🔐

d) Incompatibility between fixed IKE source ports and NAPT 🚪 When multiple hosts behind the NAPT start IKE SAs with the same responder, the NAPT needs a way to demultiplex the incoming IKE packets coming back from the responder. This is usually done by translating the IKE UDP source port on outbound packets from the initiator. So responders have to be able to accept IKE traffic from a UDP source port other than 500, and they have to reply to that port. Be careful, because unpredictable behavior can happen during re-keys. If the floated source port isn't used as the destination port for the re-key, the NAT may not be able to send the re-key packets to the correct destination. 🥺

e) Incompatibilities between overlapping SPD entries and NAT 👯 When initiating hosts behind a NAT use their source IP addresses in Phase 2 identifiers, they can negotiate overlapping SPD entries with the same responder IP address. The responder could then send packets down the wrong IPsec SA. That happens because, to the responder, the IPsec SAs look equivalent: they exist between the same endpoints and can pass the same traffic. 🌀

f) Incompatibilities between IPsec SPI selection and NAT 🔢 ESP traffic is encrypted and therefore opaque to the NAT, so the NAT has to use elements of the IP and IPsec headers to demultiplex incoming IPsec traffic. Usually the combination of destination IP address, security protocol (AH/ESP) and IPsec SPI is used for this. 🧠

The catch is that outgoing and incoming SPIs are chosen independently. There's no way for the NAT to figure out which incoming SPI goes with which destination host just by inspecting outgoing traffic. So if two hosts behind the NAT try to create IPsec SAs to the same destination at the same time, the NAT could deliver the incoming IPsec packets to the wrong destination. 😱

This isn't really an incompatibility with IPsec itself, it's an incompatibility with the way IPsec is typically implemented. With both AH and ESP, the receiving host specifies the SPI to use for a given SA, and that choice only matters to the receiver. Right now, the combination of Destination IP, SPI and Security Protocol (AH, ESP) uniquely identifies a Security Association. Also, SPI values in the range 1-255 are reserved to IANA and may be used in the future. So when negotiating with the same external host or gateway, internal hosts behind the same NAPT can pick the same SPI value. Like this, where one host's inbound SA is:

(SPI=470, Internal Dest IP=192.168.0.4)

and a different host's inbound SA is:

(SPI=470, Internal Dest IP=192.168.0.5)

The receiving NAPT won't be able to tell which internal host an inbound IPsec packet with SPI=470 should be forwarded to. 🫠

⚠️ bestie, there's a workaround! The receiving host can give every unicast Security Association its own unique SPI. Then the Destination IP Address only needs to be checked to see if it's "any valid unicast IP for this host", rather than checked against the specific Destination IP address the sending host used. With this technique, the NA(P)T can be assured of a low but non-zero chance of forwarding packets to the wrong internal host, even when two or more hosts establish SAs with the same external host. 🦋

This approach is completely backwards compatible, and it only requires the particular receiving host to change its SPI allocation and its IPsec_esp_input() code. The catch is that NA(P)T devices may not be able to detect this behavior without the problems that come with parsing IKE payloads. And a host may still be required to use a SPI in the IANA reserved range for the assigned purpose. 🧩

g) Incompatibilities between embedded IP addresses and NAT 📦 Since the payload is integrity protected, any IP addresses enclosed within IPsec packets can't be translated by a NAT. That makes Application Layer Gateways (ALGs) implemented within NATs ineffective. Protocols that use embedded IP addresses include FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (optionally), and many games. 🎮 To deal with this, you need to install ALGs on the host or security gateway, where they can operate on application traffic before IPsec encapsulation and after IPsec decapsulation. 🛠️

h) Implicit directionality of NA(P)T ➡️ NA(P)Ts often need an initial outbound packet to flow through them so they can create an inbound mapping state. Directionality means you can't establish IPsec SAs to hosts behind the NA(P)T without them being solicited first. 🚫

i) Inbound SA selector verification 🕵️ Assuming IKE negotiates phase 2 selectors, inbound SA processing will drop the decapsulated packet. That's because [RFC2401] requires a packet's source address to match the SA selector value, and NA(P)T processing of an ESP packet would change that source address. 💅

2.2. NA(P)T Implementation Weaknesses 🫧

Implementation problems that show up in lots of NA(P)Ts include:

j) Inability to handle non-UDP/TCP traffic 🙅‍♀️ Some NA(P)Ts throw away non-UDP/TCP traffic, or only do address-only translation when just one host is behind the NAT. Those NAPTs can't enable SCTP, ESP (protocol 50), or AH (protocol 51) traffic. 😩

k) NAT mapping timeouts ⏳ NA(P)Ts vary in how long they keep a UDP mapping when there's no traffic. So even where IKE packets can be translated correctly, the translation state might get removed too early. 🥀

l) Inability to handle outgoing fragments 🧩 Most NA(P)Ts can fragment outgoing IP packets properly when the packet size is bigger than the MTU on the outgoing interface. But properly translating outgoing packets that are already fragmented is hard, and most NAPTs don't handle it correctly. As noted in Section 6.3 of [RFC3022], when two hosts send fragmented packets to the same destination, their fragment identifiers can overlap. The destination host relies on the fragmentation identifier and fragment offset to reassemble, so the result is data corruption. 💥 Few NA(P)Ts protect against identifier collisions by supporting identifier translation. Identifier collisions aren't an issue when NATs do the fragmentation themselves, since the fragment identifier only needs to be unique within a source/destination IP address pair. 🌸

A fragment can be as small as 68 octets [RFC791], so there's no guarantee the first fragment contains a complete TCP header. That means a NA(P)T trying to recalculate the TCP checksum may need to modify a subsequent fragment. Fragments can be reordered, and IP addresses can be embedded and even split between fragments, so the NA(P)T will need to do reassembly before finishing the translation. Few NA(P)Ts support this. 🙃

m) Inability to handle incoming fragments 📥 Only the first fragment will typically contain a complete IP/UDP/SCTP/TCP header. So NAPTs need to be able to do the translation based on the source/dest IP address and fragment identifier alone. Fragments can be reordered, so the headers for a given fragment identifier may not be known if a later fragment arrives before the first one, and the headers may be split between fragments. As a result, the NAPT may need to do reassembly before finishing the translation. Few NAPTs support this. 🥹 With NAT, the source/dest IP address is enough to determine the translation, so this doesn't come up. But it's possible for the IPsec or IKE headers to be split between fragments, so reassembly may still be required. 🧵

2.3. Helper Incompatibilities ✨

okay so the "helper" stuff is where IPsec and NAT start getting into messy drama 💅 the incompatibilities here include:

n) ISAKMP header inspection. some NAT implementations try to use IKE cookies to sort incoming IKE traffic. it's the same problem as source-port sorting: re-keying gets messed up, because Phase 1 re-keys typically won't use the same cookies as the earlier traffic 😭

o) Special treatment of port 500. some IKE implementations can't handle non-500 UDP source ports, so some NATs just don't translate packets with a UDP source port of 500 🙈 that means these NATs are limited to one IPsec client per destination gateway, unless they inspect the ISAKMP header to check cookies, and that brings back the problem from n) 🔁

p) ISAKMP payload inspection. NA(P)T implementations that try to parse ISAKMP payloads may not handle every payload ordering combination, or support vendor_id payloads for IKE option negotiation 🧚

---

3. Requirements for IPsec-NAT Compatibility 🎀

the goal of an IPsec-NAT compatibility solution is to expand the range of usable IPsec functionality beyond what the NAT-compatible IPsec tunnel mode solution from Section 2.3 gives you ✨

when you're judging a solution to IPsec-NAT incompatibility, keep these criteria in mind (this is my lowkey checklist 📝):

Deployment

okay so IPv6 is going to fix the address scarcity stuff that keeps pushing people toward NA(P)Ts with IPv4 🌈 which means IPsec-NAT compatibility is a transitional problem that has to get solved before IPv6 is widely deployed. so to be useful, an IPsec-NAT compatibility solution MUST be deployable on a shorter time scale than IPv6 ⏰

IPv6 deployment needs changes to routers and hosts. a potential IPsec-NAT solution that needs changes to both routers and hosts would be deployable on roughly the same time scale as IPv6, which is not the vibe we want 🙃 so an IPsec-NAT compatibility solution SHOULD require changes only to hosts, and not to routers 💻

part of that also means the host and the NA(P)T SHOULD NOT need to talk to each other for the solution to work. otherwise you'd be changing the NA(P)Ts and doing interoperability testing between host and NA(P)T implementations, and that's a whole saga 😩 to get anything working in the short term, the solution has to work with the existing router and NA(P)T products already in the deployed infrastructure 🫶

Protocol Compatibility

an IPsec NAT traversal solution isn't expected to fix protocols that can't get through NA(P)T when they're unsecured by IPsec 🙅‍♀️ so ALGs may still be needed for some protocols, even when an IPsec NAT traversal solution exists. (not every problem gets a fairy godmother 🧚)

Security

NA(P)T directionality is doing a security job, so IPsec NA(P)T traversal solutions should not let arbitrary incoming IPsec or IKE traffic from any IP address reach a host behind the NA(P)T 🛡️ mapping state should be maintained once bidirectional IKE and IPsec communication is established though, so the door stays open for the right people 🔑

Telecommuter Scenario

one of the main uses of IPsec is remote access to corporate Intranets, so a NA(P)T traversal solution MUST support NA(P)T traversal, via either IPsec tunnel mode or L2TP over IPsec transport mode [RFC3193] 💼 this includes support for traversal of more than one NA(P)T between the remote client and the VPN gateway, because one NAT is never enough 😤

the client may have a routable address while the VPN gateway sits behind at least one NA(P)T. or both the client and the VPN gateway may be behind one or more NA(P)Ts 🌀 telecommuters might all use the same private IP address, each behind their own NA(P)T. or many telecommuters might live on a private network behind the same NA(P)T, each with their own unique private address, all connecting to the same VPN gateway 🏠 since IKE uses UDP port 500 as the destination, you don't need to enable multiple VPN gateways behind the same external IP address 🎯

Gateway-to-Gateway Scenario

in a gateway-to-gateway scenario, a privately addressed network (DMZ) can be placed between the corporate network and the Internet 🏰 the IPsec security gateways connecting portions of the corporate network may live in the DMZ and have private addresses on their external (DMZ) interfaces. a NA(P)T connects the DMZ network to the Internet 🌐

End-to-End Scenario

a NAT-IPsec solution MUST enable secure host-to-host TCP/IP communication via IPsec, as well as host-to-gateway communications 🔐 a host on a private network MUST be able to bring up one or multiple IPsec-protected TCP connections or UDP sessions to another host with one or more NA(P)Ts between them 💫 for example, NA(P)Ts may be deployed within branch offices connecting to the corporate network, with an extra NA(P)T connecting the corporate network to the Internet 🏢 likewise, NA(P)Ts may be deployed within a corporate network LAN or WAN to connect wireless or remote location clients to the corporate network 📶 this may require special processing of TCP and UDP traffic on the host 🧐

bringing up SCTP connections to another host with one or more NA(P)Ts between them may present special challenges 😬 SCTP supports multi-homing. if more than one IP address is used, those addresses get transported as part of the SCTP packet during association setup (in the INIT and INIT-ACK chunks). if only single homed SCTP endpoints are used, [RFC2960] section 3.3.2.1 says:

Note that not using any IP address parameters in the INIT and
INIT-ACK is an alternative to make an association more likely
to work across a NAT box.

so basically, IP addresses shouldn't go into the SCTP packet unless it's necessary 🙏 if NATs are present and IP addresses are included, association setup will fail 💀 recently [AddIP] was proposed, which lets you modify the IP address once an association is established. but the modification messages also carry IP addresses in the SCTP packet, so NATs will mess with those too 😭

Firewall Compatibility

firewalls are everywhere, so a NAT-IPsec compatibility solution MUST let a firewall administrator create simple, static access rule(s) to permit or deny IKE and IPsec NA(P)T traversal traffic 🧱 this means, for example, that dynamic allocation of IKE or IPsec destination ports is something to avoid 🚫

Scaling

an IPsec-NAT compatibility solution should be able to run in an installation with thousands of telecommuters 📈 in that situation, you can't assume only one host is talking to a given destination at a time 🙅‍♀️ so an IPsec-NAT compatibility solution MUST address the issue of overlapping SPD entries and de-multiplexing of incoming packets 🌸

Mode Support

at a minimum, an IPsec-NAT compatibility solution MUST support traversal of the IKE and IPsec modes required for support within [RFC2409] and [RFC2401] 🎀 for example, an IPsec gateway MUST support ESP tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec transport mode NA(P)T traversal 💜

AH is a different story. its job is to protect immutable fields in the IP header (addresses included), and NA(P)T translates addresses, which breaks the AH integrity check 💔 so NA(P)T and AH are fundamentally incompatible, and there is no requirement that an IPsec-NAT compatibility solution support AH transport or tunnel mode 🙅‍♀️

Backward Compatibility and Interoperability

an IPsec-NAT compatibility solution MUST be interoperable with existing IKE/IPsec implementations, so they can still talk where no NA(P)T is present 🤝 that means an IPsec-NAT compatibility solution MUST be backwards-compatible with IPsec as defined in [RFC2401] and IKE as defined in [RFC2409] 🔙 it also SHOULD be able to detect whether a NA(P)T is present, so NA(P)T traversal support only gets used when it's needed 🔍 this means it MUST be possible to determine that an existing IKE implementation doesn't support NA(P)T traversal, so a standard IKE conversation can happen, as described in [RFC2407], [RFC2408], and [RFC2409] 📞 note that while this implies initiating IKE to port 500, there's no requirement for a specific source port, so UDP source port 500 may or may not be used 🫧

Security

okay this one is serious bestie 🚨 an IPsec-NAT compatibility solution MUST NOT introduce additional IKE or IPsec security vulnerabilities. for example, an acceptable solution must show that it introduces no new denial of service or spoofing vulnerabilities 🛑 and IKE MUST be allowed to re-key in a bi-directional manner as described in [RFC2408] 🔐

---

4. Existing Solutions 🦋

4.1. IPsec Tunnel Mode

in a limited set of circumstances, an IPsec tunnel mode implementation, like the one described in [DHCP], can traverse NA(P)T successfully ✨ but the requirements for successful traversal are so limited that a more general solution is needed 🙈

1. IPsec ESP. IPsec ESP tunnels don't cover the outer IP header within the message integrity check, so they won't suffer Authentication Data invalidation from address translation 🎉 IPsec tunnels also don't need to worry about checksum invalidation 🙌
2. No address validation. most current IPsec tunnel mode implementations don't do source address validation, so incompatibilities between IKE identifiers and source addresses won't get detected 🫠 this introduces security vulnerabilities, as described in Section 5 🚩
3. "Any to Any" SPD entries. IPsec tunnel mode clients can negotiate "any to any" SPDs, which address translation doesn't invalidate 🌍 this effectively rules out using SPDs to filter allowed tunnel traffic 🚫
4. Single client operation. with only one client behind a NAT, there's no risk of overlapping SPDs 👯 and since the NAT doesn't need to arbitrate between competing clients, there's also no risk of re-key mis-translation or improper incoming SPI or cookie de-multiplexing 💖
5. No fragmentation. when certificate authentication is used, IKE fragmentation can come up. this can happen when certificate chains are used, or even when exchanging a single certificate if the key size, or the size of other certificate fields (like the distinguished name and other extensions), is big enough 📜 but when pre-shared keys are used for authentication, fragmentation is less likely 🔑
6. Active sessions. most VPN sessions keep traffic flowing for their whole lifetime, so UDP port mappings are less likely to be removed due to inactivity ⏳ (ongoing traffic is kinda the whole point, periodt 💅)

4.2. RSIP ✨

okay so RSIP (described in [RSIP] and [RSIPFrame]) has mechanisms for IPsec traversal too, as covered in [RSIPsec] 💅. By letting hosts and NA(P)Ts talk to each other, RSIP takes care of IPsec SPI de-multiplexing AND SPD overlap, which is honestly iconic 😭🔥. That makes it a good fit for enterprises and home networks alike 🏠. Hosts behind a NAT can share the NA(P)T's external IP address (the RSIP gateway), so it plays nicely with protocols that carry embedded IP addresses 🦋.

RSIP tunnels IKE and IPsec packets, so it doesn't change the IKE and IPsec protocols themselves 🎀. The catch is that host IKE and IPsec implementations need major changes to become RSIP-compatible, so it's a lot of work 💀. Once that's done, it works with all the existing protocols (AH/ESP) and modes (transport and tunnel) 👑.

To handle de-multiplexing of IKE re-keys, RSIP needs the IKE source port to float, and re-keying has to happen to the floated port 🌸. This means interoperability with existing IPsec implementations is not assured 😬.

RSIP does NOT meet the deployment requirements for an IPsec-NAT compatibility solution, because an RSIP-enabled host needs a matching RSIP-enabled gateway before it can set up an IPsec SA with another host 🙈. Okay but the vibe check: RSIP only changes clients and routers, not servers, so it's less hard to deploy than IPv6 ✨. However, for vendors, implementing RSIP eats up a substantial chunk of the resources IPv6 support needs 😩. So RSIP solves a "transitional" problem on a long-term time scale, and that's just not useful 🥀.

4.3. 6to4

6to4, as described in [RFC3056], can be the foundation for an IPsec-NAT traversal solution 🧚. The NAT gives IPv6 hosts an IPv6 prefix derived from its external IPv4 address, and it wraps IPv6 packets in IPv4 so they can reach other 6to4 hosts or 6to4 relays 🌈. This lets an IPv6 host running IPsec talk freely to other hosts in the IPv6 or 6to4 clouds ☁️.

6to4 is an elegant, robust solution when a single NA(P)T sits between a client and its VPN gateway 💖. It's NOT universally applicable though. It needs a routable IPv4 address assigned to the NA(P)T so an IPv6 prefix can be formed, which means it can't be used when multiple NA(P)Ts sit between the client and VPN gateway 🙃. For example, an NA(P)T with a private address on its external interface can't let the clients behind it get an IPv6 prefix via 6to4 💀.

6to4 needs little extra help from hosts that already support IPv6 🫶. The downside is that NATs have to be upgraded to support it 📦. So 6to4 may not be suitable for deployment in the short term ⏳.

5. Security Considerations 🔐

Okay this section is SERIOUS bestie 😤. By definition, IPsec-NAT compatibility means hosts and routers running IPsec have to be able to securely process packets whose IP headers are NOT cryptographically protected. That opens up a bunch of issues worth talking about 👀.

Since IPsec AH can't get through a NAT, one side effect of an IPsec-NAT compatibility solution could be that IPsec ESP with null encryption gets used instead of AH wherever a NAT sits between source and destination 🔄. BUT, ESP with null encryption does NOT give you the same security properties as AH 🚨. For example, there are IPv6 source routing security risks that AH blocks but ESP with null encryption doesn't 😱.

Also, since ESP with any transform doesn't protect against source address spoofing, some kind of source IP address sanity checking has to happen 🕵️‍♀️. People don't really get how important this anti-spoofing check is 🙈. Normally there's an anti-spoofing check on the Source IP Address as part of IPsec_{esp,ah}_input(). It makes sure the packet came from the same address that was claimed in the original IKE Phase 1 and Phase 2 security associations 🔍. When a receiving host is behind a NAT, this check might not really mean much for unicast sessions. But on the Global Internet, this check matters a LOT for tunnel-mode unicast sessions, to stop the spoofing attack described in [AuthSource]. That attack can happen when access controls on the receiver depend on the source IP address of verified ESP packets after decapsulation 🚫. IPsec-NAT compatibility schemes should provide anti-spoofing protection if they use source addresses for access controls 🛡️.

Let's picture two hosts, A and C, both behind (different) NATs, who negotiate IPsec tunnel mode SAs to router B 🧩. A and C might have very different privileges. Like, host A could belong to an employee who's trusted to access most of the corporate Intranet, while C is a contractor who's only allowed to access one specific web site 💼.

If host C sends a tunnel mode packet pretending to be A (spoofing A's IP address as the source), this packet must NOT get A's privileges 😤. If authentication and integrity checking happen but there's NO anti-spoofing check (verifying that the originating IP address matches the SPI), then host C could get into parts of the network that are totally off limits 💀. So an IPsec-NAT compatibility scheme MUST provide some degree of anti-spoofing protection 🔒. Non-negotiable, periodt 💅.

6. References 📚

6.1. Normative References

[RFC791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
             September 1981.

[RFC793]     Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

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

[RFC2401]    Atkinson, R. and S. Kent, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

[RFC2402]    Kent, S. and R. Atkinson, "IP Authentication Header",
             RFC 2402, November 1998.

[RFC2406]    Kent,S. and R. Atkinson, "IP Encapsulating Security
             Payload (ESP)", RFC 2406, November 1998.

[RFC2407]    Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMP", RFC 2407, November 1998.

[RFC2409]    Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

[RFC2663]    Srisuresh, P. and M. Holdredge, "IP Network Address
             Translator (NAT) Terminology and Considerations", RFC
             2663, August 1999.

[RFC3022]    Srisuresh, P. and K. Egevang, "Traditional IP Network
             Address Translator (Traditional NAT)", RFC 3022, January
             2001.

6.2. Informative References

[RFC2408]    Maughan, D., Schertler, M., Schneider, M. and J. Turner,
             "Internet Security Association and Key Management
             Protocol (ISAKMP)", RFC 2408, November 1998.

[RFC2960]    Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
             Zhang, M. and V. Paxson, "Stream Control Transmission
             Protocol", RFC 2960, October 2000.

[RFC3056]    Carpenter, B. and K. Moore, "Connection of IPv6 Domains
             via IPv4 Clouds", RFC 3056, February 2001.

[RFC3193]    Patel, B., Aboba, B., Dixon, W., Zorn, G. and S. Booth,
             "Securing L2TP using IPsec", RFC 3193, November 2001.

[RFC3309]    Stone, J., Stewart, R. and D. Otis, "Stream Control
             Transmission Protocol (SCTP) Checksum Change", RFC 3309,
             September 2002.

[RSIPFrame]  Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
             "Realm Specific IP: Framework", RFC 3102, October 2001.

[RSIP]       Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi,
             "Realm Specific IP: Protocol Specification", RFC 3103,
             October 2001.

[RSIPsec]    Montenegro, G. and M. Borella, "RSIP Support for End-
             to-End IPsec", RFC 3104, October 2001.

[DHCP]       Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic
             Host Configuration Protocol (DHCPv4) Configuration of
             IPsec Tunnel Mode", RFC 3456, January 2003.

[AuthSource] Kent, S., "Authenticated Source Addresses", IPsec WG
             Archive (ftp://ftp.ans.net/pub/archive/IPsec), Message-
             Id:  <v02130517ad121773c8ed@[128.89.0.110]>, January 5,
             1996.

[AddIP]      Stewart, R., et al., "Stream Control Transmission
             Protocol (SCTP) Dynamic Address Reconfiguration", Work
             in Progress.

7. Acknowledgments 🫶

Huge thanks to Steve Bellovin of AT&T Research, Michael Tuexen of Siemens, Peter Ford of Microsoft, Ran Atkinson of Extreme Networks, and Daniel Senie for useful discussions of this problem space 💜.

8. Authors' Addresses ✉️

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 706 6605
Fax:   +1 425 936 7329
EMail: bernarda@microsoft.com


William Dixon
V6 Security, Inc.
601 Union Square, Suite #4200-300
Seattle, WA 98101

EMail: ietf-wd@v6security.com

9. Full Copyright Statement ©️

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

---

Intellectual Property 🔏

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸✨