RFC 3519
Mobile IP Traversal of Network Address Translation (NAT) Devices
RFC 3519: Mobile IP Traversal of Network Address Translation (NAT) Devices 💖
okay bestie, this is RFC 3519 and it's giving Standards Track energy 🎀 H. Levkowetz (ipUnplugged) and S. Vaarala (Netseal) wrote it, and it's dated April 2003. The title block doesn't list anything it obsoletes or updates, so no drama there ✨
Status of This Memo 📣
so this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 if you want the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Copyright Notice 🔒
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🦋
Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT) 💅 This document brings in extensions to the Mobile IP protocol plus a tunnelling method that lets mobile nodes using Mobile IP work inside private address networks, the kind that get separated from the public internet by NAT devices. The NAT traversal is built on using the Mobile IP Home Agent UDP port for encapsulated data traffic 🧚
Table of Contents 📜
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem description . . . . . . . . . . . . . . . . . . 3
1.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . 4
2. NAT Traversal Overview. . . . . . . . . . . . . . . . . . . . 5
2.1 Basic Message Sequence. . . . . . . . . . . . . . . . . 5
3. New Message Formats . . . . . . . . . . . . . . . . . . . . . 6
3.1 UDP Tunnel Request Extension. . . . . . . . . . . . . . 6
3.1.1 F (Force) Flag. . . . . . . . . . . . . . . . . . 7
3.1.2 R (Registration through FA Required) flag . . . . 8
3.1.3 Reserved Fields . . . . . . . . . . . . . . . . . 8
3.1.4 Encapsulation . . . . . . . . . . . . . . . . . . 8
3.1.5 Mobile IP Registration Bits . . . . . . . . . . . 9
3.2 UDP Tunnel Reply Extension. . . . . . . . . . . . . . . 9
3.2.1 Reply Code. . . . . . . . . . . . . . . . . . . . 10
3.3 MIP Tunnel Data Message . . . . . . . . . . . . . . . . 10
3.4 UDP Tunnelling Flag in Agent Advertisements . . . . . . 11
3.5 New Registration Reply Codes. . . . . . . . . . . . . . 12
4. Protocol Behaviour. . . . . . . . . . . . . . . . . . . . . . 12
4.1 Relation to standard MIP tunnelling . . . . . . . . . . 12
4.2 Encapsulating IP Headers in UDP . . . . . . . . . . . . 13
4.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . 15
4.4 Mobile Node Considerations. . . . . . . . . . . . . . . 15
4.5 Foreign Agent Considerations. . . . . . . . . . . . . . 16
4.6 Home Agent Considerations . . . . . . . . . . . . . . . 18
4.6.1 Error Handling. . . . . . . . . . . . . . . . . . 19
4.7 MIP signalling versus tunnelling. . . . . . . . . . . . 20
4.8 Packet fragmentation. . . . . . . . . . . . . . . . . . 21
4.9 Tunnel Keepalive. . . . . . . . . . . . . . . . . . . . 21
4.10 Detecting and compensating for loss of NAT mapping. . . 22
4.11 Co-located registration through FA. . . . . . . . . . . 24
5. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
5.1 Movement Detection and Private Address Aliasing . . . . 24
5.2 Mobility Binding Lifetime . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6.1 Traffic Redirection Vulnerabilities . . . . . . . . . . 27
6.1.1 Manipulation of the Registration
Request Message . . . . . . . . . . . . . . . . . 27
6.1.2 Sending a Bogus Keepalive Message . . . . . . . . 27
6.2 Use of IPsec. . . . . . . . . . . . . . . . . . . . . . 28
6.3 Firewall Considerations . . . . . . . . . . . . . . . . 28
7. UNSAF Considerations. . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Intellectual Property Rights. . . . . . . . . . . . . . . . . 30
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 31
11. Normative References. . . . . . . . . . . . . . . . . . . . . 31
12. Informative References. . . . . . . . . . . . . . . . . . . . 32
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 33
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 341. Introduction 🌸
1.1. Terminology
the Mobile IP terms from RFC 3344 [10] are what we're using here 🤓 plus a few extra ones:
- Forward Tunnel: a tunnel that forwards packets towards the mobile node. It starts at the home agent and ends at the mobile node's care-of address.
- Reverse Tunnel: a tunnel that starts at the mobile node's care-of address and terminates at the home agent.
- NAT: Network Address Translation. "Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network." -- RFC 2663 [11]. Basic NAT and NAPT are two varieties of NAT.
- Basic NAT: "With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated." -- RFC 2663 [11].
- NAPT: Network Address Port Translation. "NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation." -- RFC 2663 [11].
in this doc, the more general term NAT covers both NATs and NAPTs 💖 and most deployments today, we believe, use the NAPT variety 🫶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [6]. 🔑
1.2. Problem description
ok so a basic assumption Mobile IP [10] makes is that mobile nodes and foreign agents are uniquely identifiable by a globally routable IP address. That assumption breaks down when a mobile node tries to communicate from behind a NAT 😭
Mobile IP sends traffic from the home network to the mobile node or foreign agent through IP-in-IP tunnelling. IP nodes that communicate from behind a NAT are reachable only through the NAT's public address(es). IP-in-IP tunnelling doesn't generally carry enough information to allow unique translation from the common public address(es) to the particular care-of address of a mobile node or foreign agent behind the NAT. Most importantly, there are no TCP/UDP port numbers available for a NAT to work with. So IP-in-IP tunnels cannot in general pass through a NAT, and Mobile IP will not work across a NAT 💀
the Registration Request and Reply are the plot twist 🙈 they CAN pass through NATs and NAPTs on the mobile node or foreign agent side, because they're UDP datagrams originating from inside the NAT or NAPT.
When they go out, they make the NAT set up an address/port mapping, so the Registration Reply can get back in to the correct recipient. The current Mobile IP protocol does however not permit a registration where the mobile node's IP source address is not either the CoA, the Home Address, or 0.0.0.0 🙅♀️
what's needed is an alternative data tunnelling mechanism for Mobile IP that gives NAT devices what they need to make unique mappings so address translation works. We also need a registration mechanism that lets that alternative tunnel get set up when it's appropriate 🦋
This mechanism will address 3 different scenarios:
- A mobile node with co-located address behind a NAT; no FA
- A mobile node registered with an FA where both the mobile node and the FA are behind the same NAT
- A mobile node with co-located address using an FA which demands that registrations pass through the FA (sets the "R" bit) where both the mobile node and the FA are behind the same NAT
1.3. Assumptions
the big assumption in this doc is that the network allows communication between a UDP port chosen by the mobile node and the home agent UDP port 434 🧚 if that doesn't hold, neither Mobile IP registration nor data tunnelling will work 😬
This document does not assume that mobility is limited to a common IP address space 🌈 the routing fabric between the mobile node and the home agent may be split into a "private" and a "public" network, and the assumption is that some mechanism is needed on top of vanilla Mobile IP according to RFC 3344 [10] to achieve mobility across disparate IP address spaces.
For a deeper dive on the problems with disparate address spaces and how they might be solved, see RFC 3024 [9] 📚
The reverse tunnels considered here are symmetric. That means they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel ✨
2. NAT Traversal Overview ✨
This section gives a quick overview of the MIP UDP tunnelling mechanism that may be used to achieve NAT traversal for Mobile IP 💅
In MIP UDP tunnelling, the mobile node may use an extension (described below) in its Registration Request to say it can use Mobile IP UDP tunnelling instead of standard Mobile IP tunnelling, if the home agent sees that the Registration Request seems to have passed through a NAT 👑 The home agent may then send a registration reply with an extension that indicates acceptance (or denial). After assent from the home agent, MIP UDP tunnelling is available for both forward and reverse tunnelling 🔥
UDP tunnelled packets sent by the mobile node use the same ports as the registration request message. The source port may vary between new registrations, but stays the same for all tunnelled data and re-registrations. The destination port is always 434. UDP tunnelled packets sent by the home agent use the same ports, but in reverse 🦋
2.1 Basic Message Sequence 🎀
okay so this diagram is literally the whole vibe 🦋 It shows how you set up and actually use a Mobile IP UDP tunnel, the way this document describes it. The tunnel gets built using special extensions tucked into the very first Mobile IP Registration Request and Reply exchange 🧚 After that, any traffic going from the home agent to the mobile node goes through the UDP tunnel, no detours ✨ The mobile node gets to decide for itself whether it uses the UDP tunnel for reverse tunnelling or not. But ngl, in most cases where MIP UDP tunnelling is needed, reverse tunnelling is needed too 💀
mobile node NAT home agent
| | |
| | |
| Registration | |
| Request with | |
|-----------------///--------------->>|
|UDP Tunnel Request| |
| | +
| | || IP Source and
| | || CCoA address
| | || discrepancy
| | || seen
| | Registration +
| | Reply with |
|<<---------------///-----------------|
| | UDP Tunnel Reply.|
| | |
| UDP tunnelled pkg| |
|=================///===============>>|
| | UDP tunnelled pkg|
|<<===============///=================|
| | ||absence of
| | ||traffic for
| | ||UDP keepalive
| UDP keepalive | ||period
|-----------------///--------------->>+
. . +
. . .
. . .3. New Message Formats 🧚
3.1 UDP Tunnel Request Extension 💖
okay this one is a skippable extension, bestie 🫶 It tells the other side that the sender can handle MIP UDP tunnelling, and it can optionally ask for a specific encapsulation format to be used in the MIP UDP tunnel ✨ It follows the short extension format described in [10]. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|R| Reserved 2| Encapsulation | Reserved 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now the field breakdown, which is the good stuff 👑
Type 144
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type 0
Reserved 1 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
F F (Force) flag. Indicates that the mobile
node wants to force MIP UDP tunnelling to be
established.
R R (Registration through FA Required) flag.
Indicates that the R bit was set in the FA's
Agent Advertisement. Registration is being
made using a co-located care-of address, but
through the FA.
Reserved 2 Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.
Encapsulation Indicates the type of tunnelled data, using
the same numbering as the IP Header Protocol
Field.
Reserved 3 Reserved for future use. MUST be set to 0 on
sending, MUST be verified as 0 on receipt;
otherwise the extension must be handled as not
understood and silently skipped.3.1.1 F (Force) Flag ✨
so the F flag basically says the mobile node wants to use traversal no matter what the home agent's NAT detection says 💅 It's super handy when the route between the mobile node and the home agent works for Mobile IP signalling packets but not for generic data packets (like if firewall filtering rules are being extra) 🙈 If the home agent supports this protocol, it SHOULD either accept the traversal and reply with a UDP Tunnel Reply Extension, or reject the Registration Request. And if the registration fails, the Home Agent SHOULD send a Registration Reply with the Code field set to 129 ("administratively prohibited") 🚫
Heads up: if the HA doesn't understand the UDP Tunnel Request Extension, it'll silently discard it. If everything else is fine, it'll reply with a registration reply with reply code 0 (registration accepted), but without any UDP Tunnel Reply Extension. In that case, the mobile node MUST NOT use MIP UDP tunnelling. 🙅♀️
3.1.2 R (Registration through FA Required) flag 🌸
this flag MUST be set by the mobile node when it's using a co-located address but registering through an FA, because it got an Agent Advertisement with the 'R' bit set 🦋
3.1.3 Reserved Fields 🧸
the 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt, while the 'Reserved 3' field must be 0 on receipt. otherwise this extension MUST be handled as not understood and silently skipped 🫶 This is the trick that lets future additions to the extension either co-exist with old implementations, or force old implementations to reject it. genius, honestly 👑
3.1.4 Encapsulation 🎁
the 'Encapsulation' field defines the mode of encapsulation requested if MIP UDP tunnelling is accepted by the home agent. It uses the exact same values as the IP header Protocol field:
4 IP header (IP-in-UDP tunnelling) RFC 2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
55 Minimal IP encapsulation header RFC 2004 [5]okay so if the home agent finds that UDP tunnelling isn't needed, the encapsulation gets decided by the 'M' and 'G' flags of the registration request 🤷♀️ But if the home agent decides MIP UDP tunnelling should happen, then the encapsulation comes from the Encapsulation field. If that value is zero, it defaults to whatever the 'M' and 'G' fields say in the Registration Request message. If it's non-zero, it means a particular encapsulation is desired 💜
3.1.5 Mobile IP Registration Bits 🌈
the Mobile IP registration bits S, B, D, M, G and T keep their meaning from RFC 3344 [10] and RFC 3024 [9]. The one twist is that the significance of the M and G bits can be modified by the Encapsulation field when MIP UDP tunnelling is in use, as described above. The use of the M and G bits together with MIP UDP tunnelling is also touched on in Section 4.1 ✨
When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation by the mobile node) MUST be set, otherwise UDP tunnelling wouldn't be meaningful 🙈
Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP tunnelling, even if not all traffic will be reverse tunnelled. This makes sure that a HA which isn't prepared to accept reverse tunnelling won't accept a registration that might later turn out to be unusable 🔥 Also see the discussion of the 'T' bit in Foreign Agent Considerations (Section 4.5) 💅
3.2 UDP Tunnel Reply Extension 🦋
this one is a non-skippable extension, so no sneaking past it 😭 It gets sent in reply to a UDP Tunnel Request extension, and it says whether or not the HA will use MIP UDP tunnelling for the current mobility binding. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reply Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | Keepalive Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And the fields 🍓
Type 44
Length 6. Length in bytes of this extension, not
including the Type and Length bytes.
Sub-Type 0
Reply Code Indicates whether the HA assents or declines
to use UDP tunnelling for the current mobility
binding. See Section 3.2.1 below.
F F (Forced) flag. Indicates that tunnelling is
being forced because the F flag was set in the
tunnelling request, irrespective of the
detection of a NAT or not.
Keepalive Interval Specifies the NAT keepalive interval that the
mobile node SHOULD use. A keepalive packet
SHOULD be sent if Keepalive Interval seconds
have elapsed without any signalling or data
traffic being sent. If this field is set to
0, the mobile node MUST use its default
configured keepalive interval.
Reserved Reserved for future use. MUST be set to 0 on
sending, MUST be ignored on reception.3.2.1 Reply Code 💜
the Reply Code field tells you if UDP tunnelling was accepted and will be used by the HA ✨ Values from 0 .. 63 mean "yes, assent, tunnelling will be done" 🎉 Values from 64 .. 255 mean tunnelling should NOT be done 🙅♀️ The actual response code can give you more info about why.
The response codes defined for the code field of the UDP Tunnel Reply Extension are:
0 Will do tunnelling
64 Tunnelling declined, reason unspecified3.3 MIP Tunnel Data Message ✨
okay so this header is basically the bouncer at port 434 💅 Its whole job is to tell tunnelled traffic apart from other Mobile IP messages, like Registration Requests and Registration Replies 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Next Header | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Typeis always 4 🦋Next Headertells you what kind of data is being tunnelled, using the same numbering as the IP Header Protocol Field 🍓Reservedis reserved for future use. It MUST be set to 0 on sending, and it MUST be ignored on reception 🫶
The Next Header field uses the same values as the IP header Protocol field. The ones that matter most for Mobile IP are these:
4 IP header (IP-in-UDP tunnelling) RFC 2003 [4]
47 GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]
55 Minimal IP encapsulation header RFC 2004 [5]Here's the important bit 🔥 The receiver of a tunnelled packet MUST check that the Next Header value matches the tunnelling mode established for the mobility binding that the packet was sent with. If there's a mismatch, the packet MUST be dropped. A log entry MAY be written, but in that case the receiver SHOULD make sure it doesn't write an excessive number of log entries 💀
Also, MIP UDP tunnelling can potentially support other encapsulations too. You do this with the Next Header field in the MIP Tunnel Data Header, plus the Encapsulation Header field of the UDP Tunnel Request Extension (Section 3.1) 🌈
3.4 UDP Tunnelling Flag in Agent Advertisements ✨
the only change to the Mobility Agent Advertisement Extension from RFC 3344 [10] is a flag that says the foreign agent sending the advertisement supports MIP UDP Tunnelling 🧚 The flag goes in right after the flags already defined in [10].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|U| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |The flag works like this:
Uis UDP Tunnelling support 💖 It means this Agent supports MIP UDP Tunnelling as specified in this document. This flag SHOULD be set in advertisements from a foreign agent that supports MIP UDP tunnelling and sits behind a NAT. It MUST NOT be set in advertisements from foreign agents that are not behind a NAT, since they have no reason to advertise the capability 👑
3.5 New Registration Reply Codes ✨
one new registration reply code is defined, and it's giving main character energy 🎀
ERROR_HA_UDP_ENCAP_UNAVAIL Requested UDP tunnel encapsulation
unavailableThe HA uses this to tell apart a registration denial caused by an unavailable UDP tunnel encapsulation mode from a denial caused by an unavailable standard tunnel encapsulation. That second kind is requested with the T bit together with either the M or G bit 🔥
4. Protocol Behaviour 🦋
4.1 Relation to standard MIP tunnelling
the default encapsulation mode for MIP UDP tunnelling is IP-in-UDP encapsulation 💅 The mobile node MAY request other forms of encapsulation for UDP tunnelling. It can do that by setting the M bit and/or the G bit in a Mobile IP registration request, or by explicitly asking for a particular encapsulation for the MIP UDP tunnel with the Encapsulation field. The M and G bits keep the meaning they have in RFC 3344 [10] within the context of MIP UDP tunnelling. Here's how the UDP tunnelling versions of the classic MIP encapsulation methods work 🌸
IP in UDP. When Mobile IP UDP tunnelling is used, this is the default encapsulation type. Any home agent and mobile node that implements Mobile IP UDP tunnelling MUST implement this encapsulation type 🫶
GRE in UDP. If the G bit is set in a registration request and the Encapsulation field is zero, the mobile node is asking its home agent to use GRE encapsulation [3] for datagrams tunnelled to the mobile node. If MIP UDP tunnelling is also requested and accepted, GRE-in-UDP encapsulation SHALL be used in the same cases where GRE in IP encapsulation would have been used if MIP UDP tunnelling hadn't been requested ✨
Minimal encapsulation in UDP. If the M bit is set and the Encapsulation field is zero, the mobile node is asking its home agent to use minimal encapsulation [5] for datagrams tunnelled to the mobile node. If MIP UDP tunnelling is also used, minimal encapsulation in UDP SHALL be used in the same cases where minimal encapsulation according to RFC 2004 [5] would have been used if MIP UDP tunnelling hadn't been requested 🧚
when the Encapsulation field is non-zero, a particular encapsulation format is requested for the MIP UDP tunnel. If tunnelling is indicated, the request MUST either be accepted using the requested encapsulation, or rejected with the error code ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable", which is defined in Section 3.5 😭 After getting that error, the mobile node MAY choose to send a new Registration Request with different requirements for MIP UDP tunnelling encapsulation 🍓
4.2 Encapsulating IP Headers in UDP
MIP IP-in-UDP tunnelling (or UDP tunnelling for short) works in a way that's basically the same as the IP-in-IP tunnelling in RFC 2003 [4], except it adds a UDP header [1] and a MIP Message header [10] between the outer and inner IP headers 🌈
Mobile IP Registration Requests and Registration Replies are already UDP messages, so they SHALL NOT be tunnelled, even when MIP IP-in-UDP tunnelling is in force 🙈
To encapsulate an IP datagram with MIP IP-in-UDP encapsulation, you insert an outer IP header [2], a UDP header [1] and a MIP Message header [10] in front of the datagram's existing IP header, like this 💜
+---------------------------+
| |
| Outer IP Header |
+---------------------------+
| |
| UDP Header |
+---------------------------+
| MIP Tunnel Data |
| Message Header |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+The outer IP header Source Address and Destination Address, together with the UDP header Source Port and Destination Port, identify the "endpoints" of the tunnel 🦋 The inner IP header Source Address and Destination Address identify the original sender and the recipient of the datagram. The inner IP header isn't changed by the encapsulator, except to decrement the TTL by one when the tunnelling is part of forwarding the datagram, as noted in RFC 2003 [4]. It stays unchanged while it's delivered to the tunnel exit point. No changes are made to the IP options in the inner header while the encapsulated datagram goes through the tunnel. Note that the security options of the inner IP header MAY affect the choice of security options for the encapsulating (outer) IP header 🔒
Minimal Encapsulation and GRE encapsulation work in an analogous way. They follow RFC 2004 [5] for Minimal Encapsulation and RFC 2784 [8] for GRE Encapsulation, but they use the outer IP, UDP and MIP headers in place of the outer IP header 🌸
All other provisions and requirements of RFC 2003 [4] and RFC 3024 [9] are in force, with one exception, which is covered in Packet Fragmentation (Section 4.8) 💖
4.3 Decapsulation
Before decapsulation actually happens, the decapsulating node MUST verify that the outer IP addresses and UDP port numbers exactly match the values used for the tunnel. The exception is tunnels that are "half bound" (as described in Section 4.11), where the source UDP port can change 🧚
IP-in-UDP encapsulated traffic is decapsulated simply by stripping off the outer IP, UDP and MIP headers. What's left is the original IP packet, which is forwarded as is ✨
Minimal IP encapsulation is processed by the receiver conceptually like this. First, the UDP and Mobile IP headers are removed from the packet, and the Protocol field of the IP header is replaced with the Next Header field from the MIP Tunnel Data header. Second, the remaining IP header total length and checksum are adjusted to match the stripped packet. Third, ordinary minimal IP encapsulation processing is done 🍓
GRE encapsulated traffic is processed according to RFC 2784 [8] and RFC 1701 [3], with the delivery header made up of the outer IP, UDP and MIP headers 🌈
4.4. Mobile Node Considerations 💖
okay bestie, so the UDP Tunnel Request Extension MAY be used in a Mobile IP Registration Request from the mobile node to the home agent when the mobile node uses a co-located care-of address 💅. It SHALL NOT be used by the mobile node when it is registering with a foreign agent care-of address. no exceptions, periodt 🙅♀️
the whole point of this extension is to tell the home agent that the mobile node can handle MIP UDP tunnelling IF the home agent has a hint that the mobile node is hiding behind a NAT or NAPT 🧚. so it's a conditional solicitation, basically saying "hey, I'm down to tunnel if you need it" 🦋.
As per Section 3.2 and 3.6.1.3 of RFC 3344 [10], the mobile node MUST place this Extension before the Mobile-Home Authentication Extension in registration messages, so that it is covered by the Mobile-Home Authentication Extension. the main character placement, iykyk 👑
now, if the mobile node includes the UDP Tunnel Request extension in a registration request but gets a registration reply with no UDP Tunnel Reply extension, it MUST assume that the HA does not understand this extension, and it MUST NOT use UDP tunnelling. if the mobile node is actually behind a NAT, the registration might still succeed, but the traffic won't be able to get through the NAT 😭. not ideal, bestie.
when the mobile node sends MIP UDP tunnelled data, it MUST use the same UDP source port as was used for the most recent registration request 🎀.
when the mobile node re-registers without having moved, it SHOULD take care to use the same source port as was used for the original registration of the current mobility binding. otherwise, while the home agent would change the destination port when it accepts the new registration, and the mobile node would presumably start listening on the new port, the packets in flight from the home agent at the time of the change will get dropped when they arrive at the mobile node's old port 🥺. (this does not mean that the home agent should refuse a registration request using MIP UDP tunnelling where a new port has been used, since this might be the result of the NAT dropping state, the mobile node rebooting, changing interface, etc. ✨)
if a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent had the 'U' bit set, the mobile node MUST set the 'R' flag in its UDP Tunnel Request Extension, in order to make the HA use MIP UDP tunnelling. in this case, the mobile node also MUST send a keepalive as soon as its registration has been accepted 🔥.
and if a mobile node is registering through a foreign agent with a co-located care-of address, but the agent advertisement from that foreign agent does NOT have the 'U' bit set, the mobile node MUST NOT include a UDP Tunnel Request Extension in the registration request 🙈.
4.5. Foreign Agent Considerations 🌸
the UDP Tunnel Request Extension MAY be used by a foreign agent when it is forwarding a Mobile IP Registration Request to a home agent, when the foreign agent is sitting behind a NAT or has some other compelling reason to need MIP UDP tunnelling 🧚♀️.
the purpose here is the same vibe as before: to tell the home agent that the foreign agent can accept MIP UDP tunnelling IF the home agent has a hint that the foreign agent is behind a NAT or NAPT. it's a conditional solicitation for MIP UDP tunnelling, so it's giving "I'm open to it, but only if you need it" 💅.
a foreign agent that makes the mobile node register through it by setting the 'R' bit in the agent advertisement MUST NOT add the UDP Tunnel Request Extension when forwarding a registration request that uses a co-located care-of address 🙅♀️. why? because it would lead to a UDP tunnel being set up from the home agent to the foreign agent instead of to the mobile node. wild, right? 😳
As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent using this extension MUST place it after the Mobile-Home Authentication Extension in registration messages. if the foreign agent shares a mobility security association with the home agent and therefore appends a Foreign-Home Authentication Extension, the UDP Tunnel Request Extension MUST be placed before the Foreign-Home Authentication Extension 🎀.
the home agent spots a NAT in the path between the sender and itself by seeing a mismatch between the IP source address and the care-of address in the registration request. so it is REQUIRED that the foreign agent, when using this extension, sends the registration request with an IP source address that matches the care-of address. this one is non-negotiable, bestie 👑.
a foreign agent using MIP UDP tunnelling to a home agent because it's behind a NAT may be configured to encourage reverse tunnelling, or stay neutral about it, depending on the characteristics of the NAT 🦋. if the NAT translates ALL source addresses of outgoing packets to its own public address, sessions won't be maintained when moving away from that network IF the mobile node has used triangular routing instead of reverse tunnelling 😬. on the other hand, if it's known that the NAT is smart enough not to translate publicly routable source addresses, AND it doesn't do ingress filtering, then triangular routing may succeed ✨. the leg from the home agent to the foreign agent will still use MIP UDP tunnelling to get through the NAT.
so, if you know when configuring a foreign agent behind a NAT that the NAT will translate public as well as private addresses, OR you know ingress filtering is happening between the private and public networks, the foreign agent SHOULD reply to registration requests that don't have the 'T' bit set with reply code 75, reverse tunnel is mandatory and 'T' bit not set 🔥.
the flip side: if it's known that the NAT is smart about not translating public addresses, and there's no ingress filtering, so it's reasonable to believe a mobile node with a publicly routable address can keep sessions up when moving to or from this network, the foreign agent MAY be configured to forward registration requests even if they don't have the 'T' bit set 🌈.
and if the NAT's behaviour here is unknown, it SHOULD be assumed that it will translate all addresses. so the foreign agent SHOULD be configured to reply to registration requests without the 'T' bit set with reply code 75, reverse tunnel is mandatory and 'T' bit not set 💜.
4.6. Home Agent Considerations ✨
the whole purpose of the MIP UDP Tunnel Reply Extension is to say whether or not the home agent accepts MIP UDP tunnelling for this mobility binding, and to tell the mobile node or foreign agent the suggested tunnel keepalive interval to use 🧚.
the UDP Tunnel Reply Extension MUST be used in a Mobile IP Registration Reply from the home agent to the mobile node when it has received and accepted a UDP Tunnel Request (Section 3.1) from a mobile node 💖.
the home agent MUST use a mismatch between the source IP address and the care-of address in the Mobile IP Registration Request message as the sign that a mobile node may be behind a NAT 👀. if the Registration Request also contains the UDP Tunnel Request extension without the 'R' flag set, and the home agent is capable of, and permits, MIP UDP tunnelling, the home agent SHALL respond with a registration reply containing an assenting UDP Tunnel Reply Extension, as described in Section 3.2 🦋. if the 'R' flag IS set, there are special considerations, which we'll get into below 🫶.
if the home agent receives a Registration Request with a matching source IP address and co-located care-of address that contains a MIP UDP Tunnel Request Extension, the home agent SHOULD respond with a Registration Reply containing a declining UDP Tunnel Reply, unless tunnelling has been explicitly requested by the mobile node using the 'F' flag, as described in Section 3.1 🌸.
if the home agent assents to UDP tunnelling, it MUST use the source address of the registration request as the effective care-of address, rather than the care-of address given in the registration request. the one exception is when the 'R' flag is set in the UDP Tunnel Request Extension 🎀.
if the home agent gets a Registration Request with the 'R' flag set in the UDP Tunnel Request Extension, it SHOULD reply with an assenting UDP Tunnel Reply Extension if it is capable of, and permits, MIP UDP tunnelling 🔥. in this case, though, the source address and port of the registration request might be a NAT'ed version of the foreign agent's source address and port. so, to direct tunnelled traffic correctly to the mobile node, the home agent MUST wait for the first keepalive packet from the mobile node to arrive before it can send traffic back to the correct NAT port (the one mapped to the MN) 🥹. in this case, the home agent MUST check that the outer source address (but NOT the port) of this keepalive packet is identical to the source address of the corresponding registration request. the inner source address (the one from the encapsulated ICMP echo request) MUST be the home address of the mobile node, and the inner destination address MUST be that of the home agent. if all of this holds, the outer source address and port of this keepalive packet SHALL be used by the HA as the outer destination address and port of the MIP UDP tunnel when forwarding traffic to the mobile node 💅.
the home agent SHOULD be consistent about acknowledging support for UDP tunnelling, or not ✨. a home agent that understands the UDP Tunnel Request Extension and is prepared to respond positively to such a request SHOULD also respond with a UDP Tunnel Reply Extension containing a declining reply code if MIP UDP tunnelling is not indicated for a session. and the mobile node MUST NOT assume that kind of behaviour from the home agent, since the home agent may undergo a software change with a reboot, a policy change, or a replacement, and so a change of behaviour 🙈. expect the unexpected, bestie 💜.
4.6.1 Error Handling 🚨
okay so here's what happens when things go sideways 😭
The HA does not support the UDP Tunnel Request extension:
The home agent ignores the extension and carries on as normal, which would be to refuse the registration if the IP source address doesn't match the care-of address, the home address or 0.0.0.0. Even if the HA mistakenly does accept the registration, the mobile node won't be able to receive forward tunnelled data if it's behind a NAT. 💔
(It would be lowkey helpful for the mobile node to de-register in this case 🥺. The thing is, the MN normally has no way of knowing it's behind a NAT if it doesn't get a UDP Tunnelling Reply.)
NAT detected by home agent, but traversal not allowed:
In some cases the home agent may disable NAT traversal even though it supports the UDP Tunnel Request extension and a NAT is detected. In this case, the HA SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited". 🙅♀️
NAT not detected, 'F' flag set, but home agent does not allow forced use of MIP UDP tunnelling:
The HA SHOULD send a Registration Reply with the Code field set to 129, "administratively prohibited". 🙅♀️
UDP Tunnel Request extension sent by the mobile node (placed before the MN-HA authentication extension), but 'D' bit in registration request header not set:
The HA SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". 💀
UDP Tunnel Request extension sent by the foreign agent (placed after the MN-HA authentication extension), but 'D' bit is set:
The HA SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". 💀
Reserved 3 field of UDP Tunnel Request extension is nonzero:
The HA SHOULD send a Registration Reply with the Code field set to 134, "poorly formed Request". 💀
Encapsulation type requested in UDP Tunnel Request extension is unsupported:
The HA SHOULD send a Registration Reply with the Code field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation unavailable" defined in Section 3.5. 🧚
4.7 MIP signalling versus tunnelling ✨
okay this one is so important 👑. UDP tunnelling SHALL be used only for data packets, and only when the mobility binding used for sending was established using the UDP Tunnel Request, and accepted by an UDP Tunnel Reply from the home agent. Once MIP UDP tunnelling has been set up for a mobility binding, data packets that are forward or reverse tunnelled using this mobility binding MUST be tunnelled using MIP UDP tunnelling, not IP-in-IP tunnelling or some other tunnelling method. no cap, no mixing it up 🫶
As a consequence:
- Mobile IP signalling is never tunnelled. 🙅♀️
- When using simultaneous bindings, each binding may have a different type (i.e., UDP tunnelling bindings may be mixed with non-UDP tunnelling bindings). 🦋
- Tunnelling is only allowed for the duration of the binding lifetime. ⏳
4.8 Packet fragmentation 🧩
From RFC 3022 [12]:
"Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT set-up are doomed to fail. The reason is as follows. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted."
Yikes 😭. Because of this, if the mobile node or foreign agent for any reason needs to send fragmented packets, the fragmentation MUST be done prior to the encapsulation. This differs from the case for IP-in-IP tunnelling, where fragmentation may be done before or after encapsulation, although RFC 2003 [4] recommends doing it before encapsulation.
A similar issue exists with some firewalls 🔥, which may have rules that only permit traffic on certain TCP and UDP ports, and not arbitrary outbound (or inbound) IP traffic. If this is the case and the firewall is not set to do packet reassembly, a home agent behind a firewall will also have to do packet fragmentation before MIP UDP encapsulation. Otherwise, only the first fragment (which contains the UDP header) will be allowed to pass from the home agent out through the firewall.
For this reason, the home agent SHOULD do packet fragmentation before it does MIP UDP encapsulation. 💅
4.9 Tunnel Keepalive 💓
So the UDP tunnel through the NAT only works if the NAT keeps state for the session, as described in RFC 2663 [11]. The NAT might decide the session has ended after a certain time, so keepalive messages may be needed to keep the tunnel open. The keepalives should be sent more often than the timeout value used by the NAT. ⏰
This timeout may be assumed to be a couple of minutes, according to RFC 2663 [11], but it is conceivable that shorter timeouts may exist in some NATs. 🤷♀️
For this reason, the extension used to set up the UDP tunnel has the option of setting the keepalive message interval to another value than the default value, see Section 3.2. ✨
The keepalive message sent MUST consist of a properly UDP encapsulated ICMP echo request directed to the home agent. 🏓
For each mobility binding which has UDP tunnelling established, the non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive packet if no other packet to the HA has been sent in K seconds. Here K is a parameter with a default value of 110 seconds. K may be set to another value by the HA as described in the UDP tunnelling reply extension (Section 3.2). 🕰️
Except for the case where the mobile node registers with a co-located address through an FA (see Section 4.11), MIP UDP tunnelling is done using the same ports that have already been used for the registration request / reply exchange. The MN or FA will send its first keepalive message at the earliest K seconds after the registration request was sent. The same UDP source port MUST be used for the keepalive messages as was used for the original Registration Messages and for data messages. 🎀
The remote UDP tunnel endpoint MUST use two-way keepalives consisting of UDP encapsulated ICMP Echo Request/Reply messages. The rationale for using two-way keepalives is two-fold:
- Two-way keepalives allow the mobile node to detect loss of a NAT mapping. Detection of NAT mapping loss in turn allows the MN to compensate by re-registering and using a shorter keepalive to avoid loss of NAT mappings in the future. 🕵️♀️
- One-way keepalives (keepalives sent by MN or FA, but without any reply from the home agent) actually cause more keepalive traffic overhead; the keepalive messages have to be sent more frequently to compensate for occasional loss of keepalive messages. In contrast, two-way keepalives are acknowledged, and retransmissions occur only when a response is not received for a keepalive request within a reasonable time. 📉
4.10 Detecting and compensating for loss of NAT mapping 🕵️♀️
When a mobile node is using UDP encapsulated ICMP Echo Request/Reply messages as keepalives, it will have to deal with the possibility that a NAT mapping is lost by a NAT device. The crucial thing here is of course not the loss of the NAT mapping in itself; but rather that the home agent, in the absence of a Registration Request through the new mapping, will continue to send traffic to the NAT port associated with the old mapping. 😱
If the mobile node does not get a reply to its UDP encapsulated ICMP Echo Request even after a number of retransmissions, and is still connected to the same router that was used to establish the current mobility binding, the mobile node SHOULD re-register with the home agent by sending a Registration Request. This lets the HA know about the new NAT mapping and restores connectivity between mobile node and home agent. 🔄
Having established a new mobility binding, the mobile node MAY use a shorter keepalive interval than before the NAT mapping was lost; in particular, the mobile node MAY deviate from the keepalive interval assigned by the home agent. If the binding loss continues to occur, the mobile node may shorten the keepalive interval each time it re-registers, in order to end up with a keepalive interval that is sufficient to keep the NAT mapping alive. The strategy used to arrive at a keepalive interval when a NAT mapping is lost is implementation dependent. However, the mobile node MUST NOT use a keepalive less than 10 seconds. 🙅♀️
Note that the above discussion only applies when the mobile node is re-registering through the same router, and thus presumably through the same NAT device that lost a NAT mapping earlier. If the MN moves and still finds itself behind a NAT, it SHOULD return to its original keepalive interval (the default value, or as assigned by the home agent) and it SHOULD NOT do any keepalive interval compensation unless it discovers a loss of NAT mapping in the new environment. 🧭
The home agent MUST NOT attempt to detect or compensate for NAT binding loss by dynamically changing the keepalive interval assigned in the Registration Reply; the home agent does not have enough information to do this reliably and should thus not do it at all. The mobile node is in a much better position to determine when a NAT mapping has actually been lost. Note also that a MN is allowed to let a NAT mapping expire if the MN no longer needs connectivity. 🫠
The discussion above does only in a limited sense apply to a foreign agent which is situated behind a NAT and using MIP UDP tunnelling. In this case, it is a matter of permanently configuring the FA to use a keepalive interval which is lower than the NAT mapping lifetime, rather than trying to dynamically adapt to the binding lifetimes of different NATs. 🌸
4.11. Co-located registration through FA ✨
okay so this section is basically a recap 💅 of the stuff we needed to make things work when a mobile node registers a co-located address through a foreign agent, which happens when the FA advertisements have the 'R' bit set 🎀. it's background info only, so there are no new requirements here, bestie 🫶
when a mobile node registers a co-located care-of address through an FA, the registration request that reaches the HA has a care-of address that's different from the source address in that request's IP header 😭. if the request also has a UDP Tunnel Request Extension, the HA will wrongly set up a UDP tunnel that goes to the FA instead of the MN 💀. so, like we said in Section 4.4, the mobile node must not include a UDP Tunnel Request Extension in the registration if it's registering a co-located address through an FA that doesn't have the 'U' bit set in its advertisements 🙈
still, we want MIP UDP tunnelling to work in this situation 🦋. so foreign agents that sit behind a NAT are encouraged to send advertisements with the 'U' bit set, as described in Section 3.4 ✨
if the FA advertisement has the 'U' bit set (meaning it's behind a NAT) and also has the 'R' bit set, and the mobile node wants to use a co-located care-of address, then it MUST set the 'R' flag in the UDP Tunnel Request Extension 🔥. this tells the HA what's going on so it can act appropriately, as described in Section 4.4 👑
here's the tricky part 🌀. the UDP tunnel is now taking a different path than the registration requests, so the home agent has to wait for the first keepalive packet to arrive before it sets up the tunnel to the correct address and port. to make it harder for someone to hijack the tunnel by sending a keepalive with a fake source address, only the port of the keepalive packet is allowed to differ from the registration request, and the source address has to be the same 🔐. this also means that if the FA and MN talk to the HA through different NATs, the connection will fail 💔
5. Implementation Issues 🌸
5.1. Movement Detection and Private Address Aliasing
okay this part is about a case that doesn't happen super often but still gets mentioned for completeness 🧚
in giving a mobile node a way to traverse NATs for Mobile IP traffic, we expand the address space where a mobile node can work and get care-of addresses 🌈. that brings a new problem with movement detection and address aliasing 😵💫
private networks use overlapping address spaces, so they can get mistaken for one another in some situations. this document calls that private address aliasing 🙈. because of that, it may be necessary for mobile nodes implementing this specification to keep an eye on the link layer address(es) of the gateway(s) they use for sending packets 👀. a change in the link layer address points to probable movement to a new network, even if the IP address is still reachable through the new link layer address ✨
for example, a mobile node might get the co-located care-of address 10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP from network #1 🍓. then it moves to network #2, which uses an identical addressing scheme 😳. the only difference the mobile node sees is the gateway's link layer address. the mobile node should store the link layer address it first gets for the gateway (using ARP, for instance) 💜. then it can notice link layer address changes in successive ARP exchanges as part of its normal movement detection 🔍
in rare cases, mobile nodes might not be able to monitor the link layer address of the gateway(s) they use, and so they can mix up one point of attachment with another 😬. this specification doesn't explicitly deal with that issue 🤷♀️. the potential traffic blackout from this can be limited by keeping the mobility binding lifetime short enough, since the re-registration caused by the binding expiring fixes the problem (see Section 5.2) 💖
5.2. Mobility Binding Lifetime
when the home agent responds to a registration request with a registration reply, it's allowed to decrease the lifetime that was in the registration request, as covered in RFC 3344 [10] 🎀. when UDP tunnelling is being used, there are some cases where a short lifetime is actually helpful 🌷
first up, if the NAT mapping kept by the NAT device gets dropped, you get a connection blackout 🥲. new packets from the mobile node (or the foreign agent) will create a new NAT mapping, but the home agent won't recognize it until a new mobility binding is set up by a new registration request 😩
a second case where a short lifetime helps is the private network address aliasing thing from Section 5.1 🧩. if the mobile node can't detect that it's moved and ends up behind a new NAT device, a short lifetime keeps the traffic blackout from getting super long, since a re-registration ends it 🙌
what counts as a "short lifetime" here depends on what the usage scenario needs 🤔. the suggested maximum lifetime the home agent returns is 60 seconds, but if the scenarios above aren't a problem for you, longer lifetimes are totally fine to use 🌼
6. Security Considerations 🔐
okay this section is serious, so no cap, please read it all 😭🚨
the usual Mobile IP security mechanisms also work with the NAT traversal mechanism in this document 🫶. but there's one big change: the NAT traversal mechanism needs the HA to trust unauthenticated address (and port) fields that NATs might modify 😱
relying on unauthenticated address information when creating or updating a mobility binding leads to several redirection attack vulnerabilities 💀. basically, an attacker can do what NATs do, meaning modify addresses and ports, and redirect traffic to an address they pick 🦹♀️. the same vulnerabilities apply to both MN-HA and FA-HA NAT traversal 🔁
here's the deeper version 🧠. without a NAT, the HA uses the care-of address in the registration request directly to send traffic back to the MN (or the FA), and that care-of address is protected by the MN-HA (or FA-HA) authentication extension 🛡️. but when you're across a NAT, the effective care-of address from the HA's point of view is the NAT's address, which no authentication extension protects. the HA infers it from the apparent IP source address of received packets 👀. so using the Mobile IP registration extensions in this document to traverse NATs means someone could maliciously change the care-of address of an MN (or an FA) 😈
some of these attacks can be eased a bit by a simple routability check ✅. but this document doesn't specify that mechanism, partly for simplicity, and because it wouldn't protect against every redirection attack 🙅♀️. to limit how long these redirection attacks can last, it is RECOMMENDED to use a conservative (that is, short) mobility binding lifetime when using the NAT traversal mechanism specified here 🌟
the known security issues are in the sections that follow 📚
6.1. Traffic Redirection Vulnerabilities
6.1.1. Manipulation of the Registration Request Message
an attacker on the route between the mobile node (or foreign agent) and the home agent can redirect mobility bindings to an address they want, just by changing the IP and UDP headers of the Registration Request message 😤. once they've changed the binding, they don't need to keep listening to (or messing with) the traffic 🙃. the redirection stays in force until the mobility binding expires or the mobile node re-registers ⏳
this vulnerability can let an attacker read traffic meant for a mobile node, and send traffic pretending to be the mobile node 🥷. it can also redirect traffic to a victim host to cause denial-of-service on that victim 💥
the only defense here is a short time between re-registrations, which limits how long the redirection attack lasts after the attacker stops modifying registration messages ⏱️
6.1.2. Sending a Bogus Keepalive Message
when registering through an FA with a co-located care-of address, another redirection vulnerability pops up 🚩. after exchanging Registration Request/Reply messages with the HA through the FA, the MN is expected to send the first keepalive message to the HA, which finalizes the mobility binding (the binding stays in a "half bound" state until the keepalive arrives) 🫠
an attacker who has watched a Registration Request/Reply exchange can send a bogus keepalive, assuming the mobility binding is in the "half bound" state 😈. that sets up a similar redirection attack to the one in Section 6.1.1. but here's the kicker: the attacker doesn't need to be able to modify packets in flight. just being able to observe the Registration Request/Reply exchange is enough to pull it off 👀
with that in mind, the home agent MUST NOT accept a keepalive message from a different source IP address than the one the Registration Request came from, as specified in Section 4.6 🔒. this limits the attack to redirecting traffic to a bogus UDP port, since the IP address has to stay the same as in the initial Registration Request 🧱
the only defenses against this vulnerability are: (1) a short time between re-registrations, which limits how long the redirection attack lasts after the attacker stops sending bogus keepalive messages, and (2) minimizing the time the binding spends in a "half bound" state, by having the mobile node send the first keepalive message right after getting an affirmative registration reply 🏃♀️💨
6.2. Use of IPsec
if the intermediate network is considered insecure, it is recommended that IPsec be used to protect user data traffic 🔏. but IPsec doesn't protect against the redirection attacks we just covered, other than keeping hijacked user data traffic confidential 🤐
the NAT traversal mechanism in this document lets all IPsec-related traffic go through NATs without any changes to IPsec 🎉. also, the IPsec security associations don't need to be re-established when the mobile node moves 🦋
6.3. Firewall Considerations
this document doesn't specify a general firewall traversal mechanism 🙅♀️. however, the mechanism makes it possible to use only a single address and a port for all MN-HA (or FA-HA) communication ✨. and using the same port for the MIP UDP tunnelled traffic as for control messages makes it pretty likely that if a MIP registration can reach the home agent, MIP tunnelling and reverse tunnelling using the described mechanism will also work 🌈💅
7. UNSAF Considerations 💅
okay so this mechanism is NOT an "UNilateral Self-Address Fixing" (UNSAF) mechanism 🙈 The mobile node never tries to figure out or use the NAT translated address. BUT during registration it does keep the NAT mapping alive by sending refresh messages, so we have to talk about it. This section goes through those issues using the UNSAF considerations IAB document [13]. ✨
1. Precise definition.
This proposal extends the Mobile IP v4 registration process so it can work across NATs in between. The Home Agent (HA) spots a NAT by looking at the source address in the packet header and comparing it with the address in the registration message. 👀
The NAT address and port the home agent detects are not exported or communicated to any other node anywhere. 🤐
2. Exit strategy.
This mechanism will go out of use once IPv6 and Mobile IP v6 are deployed, so we won't need MIPv4 NAT traversal anymore. 🦋
It's also worth noting that this mechanism makes no changes to the base MIPv4 protocol. That means it depends on NATs being there, or on the current extensions. So if NATs ever went away, no extra protocol changes would be needed. 🌈
3. Issues making systems more brittle.
The specific issue here is that the effective care-of address (the source address in the IP header the HA receives) is not protected by the Mobile IP authentication extension, so it can be spoofed. 😭 Section 6, Security Considerations goes into this in a lot more detail. 💀
4. Requirements for longer term solutions.
The trivial long term solution is moving to an environment where NATs aren't required. The most obvious version of that is an IPv6 based internet. 🧚
In the presence of NATs, a better solution would need:
- the ability to discover the translations done by each NAT along the route
- the ability to validate the authority of each NAT to do those translations
- communicating, as part of the signed registration request, the address of the NAT closest to the HA, for use as the effective care-of address from the viewpoint of the HA
- configuration of all intermediate NATs to accept only packets from the neighbour NATs
5. Impact on existing, deployed NATs.
One precursor of the mechanism described here has been used successfully across deployed NATs in Sweden, Germany, England, Japan and the USA. 🌍 It didn't need any adjustments to those NATs, and it didn't need any protocol parameters changed either. At the time of writing, there's little experience with the exact implementation proposed in this document, but effort went into making this mechanism even more robust and adaptive than its precursors. 💪
With respect to the base Mobile IP specification, the impact of this document is that an increased frequency of registration requests is recommended from a security perspective when the NAT traversal mechanism is used. ⏰
8. IANA Considerations 🎀
The numbers for the extensions defined in this document come from the numbering space defined for Mobile IP messages, registration extensions and error codes in RFC 3344 [10]. 📋 This document proposes one new message, two new extensions and a new error code. Those need type numbers and an error code value that IANA has to assign. The two new extensions also introduce two new sub-type numbering spaces that IANA will manage. 🫶
Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request Extension. Its type number is 144. This extension introduces a new sub-type numbering space where the value 0 has been assigned to this extension. Approval of new Tunnel Request Extension sub-type numbers is subject to Expert Review, and a specification is required [7]. 📝
Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply Extension. Its type value is 44. This extension introduces a new sub-type numbering space where the value 0 has been assigned to this extension. Approval of new Tunnel Reply Extension sub-type numbers is subject to Expert Review, and a specification is required [7]. 🦋
Section 3.3 defines a new Mobile IP message, the Tunnel Data message. Its type value is 4. 🌸
Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL: "Requested UDP tunnel encapsulation unavailable", from the numbering space for values used with the Code field of Mobile IP Registration Reply Messages. Code number 142 has been assigned from the subset "Error Codes from the Home Agent". 🙈
The values for the Next Header field in the MIP Tunnel Data Message (Section 3.3) shall be the same as those used for the Protocol field of the IP header [2], and it requires no new number assignment. ✨
9. Intellectual Property Rights 🌈
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights (www.ietf.org/ipr.html). 🔗
10. Acknowledgements 🫶
Much of the text in Section 4.2 has been taken almost verbatim from RFC 2003, IP Encapsulation within IP [4]. 📚
Adding support for the FA case was suggested by George Tsirtsis and Frode B. Nilsen. Roy Jose pointed out a problem with binding updates, and Frode, Roy and George pointed out that there are cases where triangular routes may work, and suggested that reverse tunnelling need not be mandatory. Roy and Qiang Zhang drew attention to a number of sections that needed to be corrected or stated more clearly. 👏
Phil Roberts helped remove a number of rough edges. Farid Adrangi pointed out the DoS issue now covered in Security Considerations (Section 6). Francis Dupont's helpful comments made the authors extend the Security Considerations section to make it more comprehensive and clear. Milind Kulkarni and Madhavi Chandra pointed out the required match between the FA source and care-of addresses when the mechanism is used by an FA, and also contributed a number of clarifications to the text. 💖
Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and Timo Aalto at Netseal, and Hans Sjostrand, Fredrik Johansson and Erik Liden at ipUnplugged. They read and re-read the text, and contributed many valuable corrections and insights. 🥹
11. Normative References 📖
[1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[4] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[5] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[9] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
12. Informative References 🧠
[11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[12] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
13. Authors' Addresses 💌
Henrik Levkowetz
ipUnplugged AB
Arenavagen 23
Stockholm S-121 28
SWEDEN
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Sami Vaarala
Netseal
Niittykatu 6
Espoo 02201
FINLAND
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi14. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2003). 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. 🫶
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🎉
📦 where this page comes from
- ietf: rfc3519 2003-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms