RFC 3424

IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation

📅 published November 2002, from ietf

RFC 3424: IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation 💖

okay bestie, the paperwork first 📋✨ this is RFC 3424, edited by L. Daigle, Ed. and published by the Internet Architecture Board (IAB) 🧚 It's Informational, not a standard, and it's dated November 2002 🍓 Its header doesn't list anything it obsoletes or updates 🙅‍♀️

Status of This Memo 🎀

this memo gives info to the Internet community. it doesn't specify an Internet standard of any kind, and it can be shared freely 🌸

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

Abstract 🦋

okay so, NAT boxes (Network Address Translation middleboxes) cause a real mess 😭 endpoints sitting behind one or more NATs don't know how to refer to themselves with addresses that work in their peers' address realms, both now and later 🙈 people have come up with a bunch of ideas called "UNilateral Self-Address Fixing (UNSAF)" 🔧 in an UNSAF process, one originating endpoint tries to figure out or lock in the address (and port) another endpoint knows it by. the goal is to put that address in the protocol exchange, or to advertise a public address that connections can come in through 💜

this doc explains why these ideas are, at best, short-term fixes for specific problems 💀 it also lists the issues that need careful checking before anyone builds an UNSAF proposal 👑

1. Introduction 🌈

so, because of how NATs work (Network Address and port Translation), endpoints separated by one or more NATs can't properly refer to themselves in addresses valid in their peers' realms 😭 the translation is trapped inside the NAT box. some things need endpoints to know the addresses and/or ports their peers see them as 💖 there are two cases:

  1. when the client starts the conversation, that starts create an address binding in the NAT and allocates an address in the external realm 🦋
  2. a server accepts connections from outside, but because it doesn't start any communication, no NAT binding gets created 🙃

in both cases, a mechanism is needed to fix that binding before communication can happen ✨

so "UNilateral Self-Address Fixing (UNSAF)" is when some originating process tries to figure out or fix the address (and port) it's known by, for example to use address data in the protocol exchange, or to advertise a public address that connections will come in on 🎀

the honest truth is there are only heuristics and workarounds, and there's no 100% solution 😭 NATs can also reclaim or readjust translations on their own, so "keep-alive" and periodic re-polling may be needed 🔁 using these workarounds MUST be treated as transitional in IETF protocols, because a better architectural solution is being sought 🔥 the explicit plan is to deprecate these workarounds once sound technical approaches are available 🍓

2. Architectural issues affecting UNSAF Systems 💅

in general, these workarounds are for cases where a standard protocol communication is going to happen between two endpoints, but first there's a separate step where you figure out (or fix) the endpoint's perceived address in the other endpoint's addressing realm 🧚 so the proposals need an endpoint trying to "fix" its address to contact a participating service (in a different address realm) to find out (reflect) its address 🪞 that makes an "UNSAF client" partnering with some kind of "UNSAF service", which may or may not be connected to the target endpoint of the real session 💖 throughout this memo, "UNSAF server" and "UNSAF service" mean whatever process is helping the originating process (the UNSAF client) figure out its address 🫶

anyone using these workarounds should know about these specific technical issues that block a general solution 👇

  • there is no unique "outside" to a NAT 😭 it may be impossible to tell where the target endpoint is compared to the initiator. so how does an UNSAF client find an appropriate UNSAF server to reflect its address? (See Appendix C).
  • since you can't tell where address realms are bounded ("inside" or "outside", "private" or "public", or several "private" realms routing traffic), an address can only be determined relative to one specific point in the network 🌸 if the UNSAF service that reflected the client's address sits in a different NAT-masqueraded subnet from some other service X the client wants to use, there's no guarantee that the client's "perceived" address from the UNSAF partner will match the address seen from X's side 💀 (See Appendix C).
  • without "middlebox communication (midcom)", there's no usable way to let incoming communications get through a middlebox (NAT, firewall) under proper supervision 🚨 by going around the NAT, UNSAF mechanisms may also (accidentally) go around security mechanisms 😱 the big danger is that internal machines get unknowingly exposed to all the malicious traffic from outside that the firewall is supposed to block 🙈 this is especially not okay if one UNSAF process runs on a single machine acting for several machines 🚫
  • proposed workarounds include "ping"-like address discovery requests sent from the UNSAF client (initiator) to the UNSAF server (listener). the listener replies with the initiator's transport address, in the listener's realm 🪞 but with connection-less transports, like UDP, IPsec ESP, and so on, an UNSAF process has to be careful to react to changes in NAT bindings for a given application flow, since those can change unpredictably 🦋
  • if the UNSAF client uses periodic retries to refresh or re-evaluate the address translation state, then both the UNSAF client and the UNSAF server are required to keep info about the presumed state of the communication, so they can manage the address illusion 🎀
  • since the UNSAF server isn't part of the middlebox, it can only assume that past behavior predicts future behavior 🔮 it has no special knowledge of the address translation heuristic or the factors that affect it 🤷‍♀️
  • the communication gets more "brittle" when you add other servers (UNSAF servers) that have to be reachable for the communication to succeed 😩 that's more boxes "fate sharing" in the same communication 🧵

workarounds can ease some of these problems through tight scoping and specific fixes 💖 for example:

  • instead of finding the address from "the" outside of the NAT, the approach can be limited to finding the "self-address" from one specific service, to be used only with that service 🎀
  • limiting the scope to outbound requests for a service (or service initiation), to prevent unacceptable security exposures 🛡️

3. Practical Issues 🛠️

from watching deployed networks, it's clear that different NAT box implementations vary a lot in how they handle different traffic and addressing cases 👀

some of the specific behaviors that have been observed:

  • NATs may drop fragments in either direction 😭 without complete TCP/UDP headers, the NAT may not make the address translation mapping, so it just drops the packet 🗑️
  • shipping NATs often include Application Layer Gateways (ALGs) that try to be context-sensitive, depending on the source or destination port number 🧠 ALG behavior can be hard to predict, and it hasn't always been documented 📄
  • most NAT implementations with ALGs that try to translate TCP application protocols don't do their job correctly when the substrings they need to translate span multiple TCP segments 💀 some are also known to fail on flows that use TCP option headers, like timestamps ⏱️
  • NAT implementations differ a lot in how they handle packets 🙃 quite a few only work reliably with TCP, not UDP 🔥 of the ones that try to handle UDP, the timers that age out flows can vary widely, which makes behavior hard to predict 🔮
  • address and port assignments can change pretty often 😵 on NATs, port numbers always change, and they change unpredictably 🎲 there may also be multiple NATs in parallel for load-sharing, so IP address changes are quite likely too 🌪️

4. Architectural Considerations 🧩

by calling these approaches short-term fixes, the IAB believes the following considerations must be explicitly addressed in any proposal 👑

  1. a precise definition of a specific, limited-scope problem the UNSAF proposal is meant to solve 🎯 a short-term fix should not be generalized to solve other problems 🙅‍♀️ those generalizations lead to prolonged dependence on and use of the supposed short-term fix, and then it's no longer accurate to call it "short term" 😭
  2. a description of an exit strategy or transition plan 🚪 the better short-term fixes are the ones that naturally see less and less use as the right technology gets deployed 📉
  3. discussion of specific issues that may make systems more "brittle" 🧱 for example, approaches that use data at multiple network layers create more dependencies, make debugging harder, and make transitions harder too 🫠
  4. identification of requirements for longer-term, sound technical solutions, and contributions to finding the right longer-term solution 🔭
  5. discussion of how the practical issues above affect existing deployed NATs, plus experience reports 📝

5. Security Considerations 🔐

okay, this part is serious bestie 🚨 as a general class of workarounds, UNSAF proposals may introduce security holes 💀 without "middlebox communication (midcom)", there's no feasible way to let incoming communications get through a firewall under proper supervision 🧱 the point is to respect firewall policies, not to go around security mechanisms 🛡️

Appendix A. IAB Members at the time of this writing 👑

  • Harald Alvestrand
  • Ran Atkinson
  • Rob Austein
  • Fred Baker
  • Leslie Daigle
  • Steve Deering
  • Sally Floyd
  • Ted Hardie
  • Geoff Huston
  • Charlie Kaufman
  • James Kempf
  • Eric Rescorla
  • Mike St. Johns

Appendix B. Acknowledgements 🫶

this doc got a lot of help from detailed comments and suggestions from Thomas Narten, Bernard Aboba, Keith Moore, and James Woodyatt 💖

it was originally drafted when these people were on the IAB: Steve Bellovin, Brian Carpenter, Jon Crowcroft, John Klensin, and Henning Schulzrinne 🌷 the doc has benefited a lot from their contributions and review 🙌

Appendix C. Example NAT Configuration Scenario 🧚

nothing is in this section in the copy I was given 🥲

C.1 Generic NATed Network Configuration ✨

okay so here's a scenario that's lowkey confusing 🙈 it's hard to point to a single "outside" for a given address realm when NAPTs are bridging things together. 💅 picture an enterprise where different divisions each have their own subnets, all using the same private address space. the divisions can pass traffic to each other's networks, but to reach the global Internet, each one goes through a different NAPT/firewall 🔥

                                    +---------+
                                    | Box C   | (192.168.4.5)
                                    +---+-----+
                                        |
       ---------------------------------+-------
                                        |
                                        | 192.168.3.0/24
                                   +----+----+
                                   | NAT 2   |
                                   +----+----+
                                        | 10.1.0.0/32
                                        |
         -----+-------------------------+------------+----
              |                                      |
              |                                 +----+----+
              |                                 | Box B   | (10.1.1.100)
              |                                 +---------+
              |
         +----+----+
         | NAPT 1  | (10.1.2.27)
         +----+----+
              | 10.1.0.0/32
              |
          ----+-----+--
                    |
                    |
               +----+----+
               | Box A   | (10.1.1.100)
               +---------+

so from Box B's point of view, Box A is at (some port on) 10.1.2.27 ✨ but from Box C's point of view, Box A is somewhere in 192.168.3.0/24 🦋 same box, two totally different addresses, bestie. that's the whole mess 😭

C.2 Real World Home Network Example 🏠

James Woodyatt put together this scenario based on real home networking products that are out there right now 💖

  • the customer already has internet from some broadband provider, usually over a DSL line plugged into a box that combines a DSL modem with a NAT router/firewall (e.g. ✨).
  • these boxes often come with automatic provisioning firmware, so the customer might think of them as just part of what their ISP gives them 🎀
  • later, the customer wants to use a computer that only has a wireless LAN interface, so they install a wireless access point. it ships with NAT and a DHCP server turned on by default 🌸
  • and now the customer has a wired LAN in one private address realm and a wireless LAN in another one 🫶

ngl, most customers have no idea what "address realm" even means, and honestly they shouldn't have to learn it 🙈 all they usually know is that the printer server is unreachable from the wireless laptop 💀 (why? because the discovery protocol uses UDP multicast with TTL=1, and any reply just gets dropped by the NAT, since there's no ALG 😭 that's it, that's the tea)

Authors' Addresses 🖋️

Leslie Daigle Editor

Internet Architecture Board IAB EMail: iab@iab.org

Copyright (C) The Internet Society (2002). All Rights Reserved. 🌈

You can copy this document and share it with others, and you can make derivative works that comment on or explain it, or help with implementing it. You can also publish and distribute those copies and works, in whole or in part, with no restrictions of any kind. The only condition is that the copyright notice above and this paragraph stay on every copy and derivative work 💜

The document itself, though, can't be modified in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need to do it to develop Internet standards (in which case you have to follow the copyright procedures in the Internet Standards process), or when you need to translate it into a language other than English 🦋

The permissions above are perpetual, and the Internet Society and its successors or assigns won't revoke them ✨

This document and the information in it are provided "AS IS", 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 💅

Acknowledgement 🫶

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

📦 where this page comes from