RFC 4487
Mobile IPv6 and Firewalls: Problem Statement
RFC 4487: Mobile IPv6 and Firewalls: Problem Statement 🦋
okay bestie, this one is RFC 4487, titled Mobile IPv6 and Firewalls: Problem Statement ✨ It's an Informational doc, so it's not an Internet standard, just useful info for the community. It came out in May 2006. The authors are F. Le from CMU, S. Faccin, B. Patil from Nokia, and H. Tschofenig from Siemens 💖 The header doesn't list anything it obsoletes or updates, so it's a standalone vibe 🌸
Status of This Memo 📜
this memo gives info to the Internet community 🧚 it doesn't specify an Internet standard of any kind, and distribution is unlimited 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (2006) 💅
Abstract ✨
okay so this doc is all about the issues that can pop up when you deploy IPv6 networks that support Mobile IPv6 and firewalls 🔥 it's not just about enterprise networks either. the same problems show up in 3G mobile networks like GPRS/UMTS and CDMA2000 🌈
the goal is to highlight the firewall and Mobile IPv6 problems and basically start the convo 🗣️ every issue it names can be solved by building the right solutions 👑
Table of Contents 🎀
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Abbreviations ...................................................4
4. Overview of Firewalls ...........................................4
5. Analysis of Various Scenarios Involving MIP6 Nodes and
Firewalls .......................................................6
5.1. Scenario Where the Mobile Node Is in a Network
Protected by Firewall(s) ...................................7
5.2. Scenario Where the Correspondent Node Is in a
Network Protected by Firewall(s) ...........................9
5.3. Scenario Where the HA Is in a Network Protected by
Firewall(s) ...............................................12
5.4. Scenario Where the MN Moves to a Network Protected by
Firewall(s) ...............................................12
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Appendix A. Applicability to 3G Networks ..........................151. Introduction ✨
okay so firewalls are basically a must-have part of most IP networks today 🔥 with how things stand security-wise, and all the threats and vulnerabilities out there, it makes sense. most current IP networks run on IPv4, so firewalls were built for that world 🌸 IPv6 networks are rolling out too, just at a slower pace, and firewalls for IPv6 are still growing up and being developed 🧚
mobility support for IPv6 got standardized in RFC 3775 💖 since Mobile IPv6 is pretty new, most IPv6 firewalls don't support it yet 🙈
here's the tea: unless firewalls actually know the Mobile IPv6 protocol details, these security boxes will mess with how the protocol works and could slow down deployment 💀
Mobile IPv6 gives IP mobility to IPv6 nodes 🦋 a mobile IPv6 node can stay reachable through its home IPv6 address no matter what link it's attached to ✨ this works because of the extensions to IPv6 that are defined in the Mobile IPv6 spec [1] 👑
Mobile IPv6 also has a feature called Route Optimization 🌈 it's a set of extensions that's a core part of the protocol. it lets packets get routed in an optimized way between a mobile node and its correspondent node, which makes the communication perform better 🚀
but honestly, most current firewall tech doesn't support Mobile IPv6, or isn't even aware of its headers and extensions 😭 and since most business networks have firewalls, this could block big, large-scale Mobile IPv6 deployment 🥺
this doc goes into detail on some of the issues firewalls cause for Mobile IPv6 deployment, and the impact of each one 🔍💜
2. Terminology 📖
Return Routability Test (RRT): this is a procedure defined in RFC 3775 [1] 💅 it happens before Route Optimization (RO), where a mobile node (MN) tells a correspondent node (CN) to send the mobile node's data traffic to the care-of address (CoA) it claims. the Return Routability procedure gives some security assurance and stops people from misusing Mobile IPv6 signaling to redirect traffic maliciously or launch other attacks 🛡️
3. Abbreviations 🔤
this doc uses these abbreviations, fr fr:
- CN: Correspondent Node
- CoA: Care of Address
- CoTI: Care of Test Init
- HA: Home Agent
- HoA: Home Address
- HoTI: Home Test Init
- HoT: Home Test
- MN: Mobile Node
- RO: Route Optimization
- RRT: Return Routability Test
4. Overview of Firewalls 🔥
this section is a quick overview of firewalls 💖 it's background so the Mobile IPv6 issues make sense when the later sections dig into them 🧚
there are different types of firewalls, and state can get created in them in different ways 🌸 no matter which method is used, firewalls usually look at five parameters on the traffic that arrives at them 👀
- Source IP address
- Destination IP address
- Protocol type
- Source port number
- Destination port number
based on those parameters, firewalls usually decide whether to let the traffic through or drop the packets 🚫 some only filter incoming traffic, while others filter outgoing traffic too 🦋
according to Section 3.29 of RFC 2647 [2], stateful packet filtering is when traffic gets forwarded or rejected based on a state table the firewall keeps 💅 these firewalls are commonly deployed to protect networks from threats, like blocking unsolicited incoming traffic from external networks 🛡️ here's how they work, since they can cause extra problems for Mobile IPv6 in the sections ahead 👑
with TCP, an MN sends a TCP SYN message to connect to another host on the Internet 🌈
when that SYN packet arrives, the firewall records the source IP address, destination IP address, protocol type, source port number, and destination port number from the packet, and only then sends it on to the destination 📝
when an incoming message from an external network reaches the firewall, it checks the packet's source IP address, destination IP address, protocol type, source port number, and destination port number against its entries 🔍 if the packet matches a request that was sent earlier, the firewall lets it into the network ✨ if the packet wasn't solicited by an internal node, it gets blocked 🚫
when the TCP close session packets get exchanged, or after some configurable period of inactivity, the matching entry in the firewall gets deleted 🧹 this stops entries from hanging around when TCP connections are abruptly terminated 💀
UDP gets a similar entry 🌸 the difference is that UDP is connectionless and has no packets that signal a session starting or ending 🫠 so the lifetime of those entries depends only on timers ⏰
5. Analysis of Various Scenarios Involving MIP6 Nodes and Firewalls 🎀
this section walks through different scenarios with MIP6 nodes and firewalls, and the issues tied to each one 💖
the Mobile IPv6 specs define three main entities: the mobile node (MN), the correspondent node (CN), and the home agent (HA) 🧚 each of them could be in a network protected by one or many firewalls 👑
- Section 5.1 analyzes the issues when the MN is in a network protected by firewall(s)
- Section 5.2 analyzes the issues when the CN is in a network protected by firewall(s)
- Section 5.3 analyzes the issues when the HA is in a network protected by firewall(s)
the MN could also be moving from an external network into a network protected by firewall(s) 🦋 the issues for that case are covered in Section 5.4 ✨
some of the described issues (for example, Sections 5.1 and 5.2) may need changes to the protocols or the firewalls 🛠️ others (for example, Section 5.3) may only need the right rules and configuration in place 🫶
more of this next, stay tuned bestie 🧚💜
5.1. Scenario Where the Mobile Node Is in a Network Protected by Firewall(s) ✨
okay so let's picture MN A chilling inside a network that's guarded by firewall(s) 🛡️💅
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protectedFigure 1: Issues between MIP6 and firewalls when MN is in a network protected by firewalls
so there are a bunch of issues we need to think about 👀
Issue 1: when MN A plugs into the network, it's supposed to grab a local IP address (CoA) and send a Binding Update (BU) to its Home Agent so the HA knows where it currently is 📍 the Binding Updates and Acknowledgements should be protected by IPsec ESP, following the MIPv6 specs [1]. BUT, as a default, lots of firewalls just drop IPsec ESP packets because they can't tell whether inbound ESP packets are legit 😤 it's basically impossible (or really hard) to build useful state by watching the outbound ESP packets too. so the Binding Updates and Acknowledgements between the mobile node and its home agent might get dropped. not it 💀
Issue 2: now let's look at a node in the external network, B, trying to reach MN A 👀
- B sends a packet to the mobile node's home address.
- The packet gets intercepted by the MN's home agent, which tunnels it to the MN's CoA [1].
- When it reaches the firewall(s) protecting MN A, the packet may be dropped, since the incoming packet may not match any existing state. As described in Section 4, stateful inspection packet filters (for example) typically drop unsolicited incoming traffic.
- So B won't be able to contact MN A and set up a communication.
even though the HA knows where the MN is, the firewalls can stop correspondent nodes from starting a conversation when the MN is sitting behind firewall(s) 🙃
Issue 3: let's say there's a communication going on between MN A and an external node B. MN A might want to use Route Optimization (RO) so packets can go directly between the MN and the CN without taking the HA detour 🏃♀️💨 however, the firewalls protecting the MN might cause problems with the Return Routability procedure that has to happen before RO can be used.
according to the MIPv6 specs, the Home Test message of the RRT must be protected by IPsec in tunnel mode. but firewalls might drop any packet protected by ESP, since they can't analyze ESP-encrypted packets (e.g., port numbers) 😭 so the firewalls may drop the Home Test messages and stop the RRT procedure from finishing.
Issue 4: let's assume MN A successfully sends a Binding Update to its home agent (or to correspondent nodes) — which solves issue 1 (or issue 3) — and the traffic afterward is sent from the HA (or CN) to the MN's CoA. but there might not be any matching state in the firewalls. so the firewalls protecting A may drop the incoming packets 💔
the right state for traffic going to the MN's CoA needs to be created in the firewall(s) 🧚
Issue 5: when MN A moves, it might end up on a link served by a different firewall. MN A might be sending a BU to its CN, but incoming packets can get dropped at the firewall, because the firewall on the new link doesn't have any state associated with the MN 😩
all of these issues happen because the MN is behind the firewall 🧱 which means the MN's ability to talk to other nodes gets affected by the firewall rules. main character problems fr 💅
5.2. Scenario Where the Correspondent Node Is in a Network Protected by Firewall(s) 🦋
now let's flip it: an MN in one network is chatting with a Correspondent Node C that lives in a network protected by firewall(s) 🌸 there are no issues with the firewall when the MN sends packets to the CN through a reverse tunnel between the MN and HA. but firewalls can cause different problems for Route Optimization 🙈
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| | C | +----+
| +---+ | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewallFigure 2: Issues between MIP6 and firewalls when a CN is in a network protected by firewalls
here are the issues we need to keep in mind 🫶
Issue 1: the MN (MN B) should use its Home Address (HoA B) when setting up communication with the CN (CN C), if MN B wants to take advantage of the mobility support that Mobile IPv6 provides for that conversation ✨ so the state created by the firewall protecting CN C is based on the IP address of C (IP C) and the home address of Node B (IP HoA B). the states may be created in different ways, and the protocol type and port numbers depend on how the connection is set up 🎀
Uplink packet filters (1)
Source IP address: IP C
Destination IP address: HoA B
Protocol Type: TCP/UDP
Source Port Number: #1
Destination Port Number: #2Downlink packet filters (2)
Source IP address: HoA B
Destination IP address: IP C
Protocol Type: TCP/UDP
Source Port Number: #2
Destination Port Number: #1so nodes C and B might be topologically close to each other, but B's home agent might be far away. that creates a trombone effect 🎢 which can add delay and hurt performance 😭 MN B may decide to start the route optimization procedure with Node C. Route optimization needs MN B to send a Binding Update to Node C so that C creates an entry in its binding cache mapping the MN's home address to its current care-of-address 💜 but before sending that binding update, the mobile node must first run a Return Routability Test:
- Mobile Node B has to send a Home Test Init (HoTI) message via its home agent, and
- a Care of Test Init (COTI) message directly to its Correspondent Node C.
the Care of Test Init message uses the CoA of B as the source address. that packet doesn't match any entry in the protecting firewall (2), so the CoTi message gets dropped by the firewall 🚫
the HoTI is a Mobility Header packet, and since its protocol type is different from the state established in the firewall (see (2)), the HoTI packet gets dropped too 💀
so the RRT can't be completed, and route optimization can't be applied. every packet has to go through Node B's home agent and get tunneled between B's home agent and B 🐢
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B|
| +----X +----+
| +------+ | ^ CoTI & HoTI ^
| | CN C | | | dropped by FW |
| +------+ | | | HoTI
| | | |
| | | CoTI (CoA)+------+
| | +------------------| MN B |
+----------------+ +------+
Network protected External Mobile
by a firewall NodeFigure 3: Issues with Return Routability Test
Issue 2: let's say the Binding Update to the CN goes through successfully. the firewall(s) might still drop packets that are:
- coming from the CoA, since these incoming packets are sent from the CoA and don't match the Downlink Packet filter (2).
- sent from the CN to the CoA if uplink packet filters are implemented. the uplink packets are sent to the MN's CoA and don't match the uplink packet filter (1).
the packet filters for traffic sent to (or from) the CoA need to be created in the firewall(s) 🧚♀️
requiring the firewalls to update their connection state whenever they see Binding Update messages from a node outside the protected network doesn't seem feasible or desirable 🙅♀️ the reason is that firewalls currently have no way to verify the validity of Binding Update messages, and so they can't change the state information securely. changing firewall states without verifying the Binding Update messages could lead to denial of service attacks ⚠️ malicious nodes could send fake binding updates, forcing the firewall to change its state information, which would lead the firewall to drop packets from connections that use the legitimate addresses. an adversary could also use an address update to let its own traffic pass through the firewall and into the network 😱
Security note: letting outsiders change firewall state with unverified Binding Updates opens the door to denial of service and to attackers sneaking traffic into the network. that's a hard no from me 🚨
Issue 3: let's say the Binding Update to the CN is successful. the CN might be protected by different firewalls, and because the MN's IP address has changed, incoming and outgoing traffic may pass through a different firewall 🔀 the new firewall may not have any state associated with the CN, so incoming packets (and potentially outgoing traffic too) may be dropped at the firewall 🥲
firewall technology lets clusters of firewalls share state [3], and that's what allows routing asymmetry to be supported 🙌 however, if the previous and new firewalls (the ones the packets go through after the Binding Update has been sent) don't share state, packets might get dropped at the new firewall. since the new firewall has no state associated with the CN, incoming packets (and potentially outgoing traffic as well) may be dropped at the new firewall 💅
5.3. Scenario Where the HA Is in a Network Protected by Firewall(s) 🏰
okay so picture the home agent (HA) chilling inside a network that's guarded by firewall(s) 🛡️. In this scenario, the following issues may exist:
Issue 1: if the firewall(s) protecting the home agent block ESP traffic, a lot of the MIPv6 signaling (like Binding Update and HoT) may get dropped right at the firewall(s) 😭. That means the MN(s) can't update their binding cache or do Route Optimization, because Binding Update, HoT, and other MIPv6 signaling must be protected by IPsec ESP.
Issue 2: if the firewall(s) protecting the home agent block unsolicited incoming traffic (like stateful inspection packet filters do), the firewall(s) may drop connection setup requests from CNs, and packets from MNs 🙅♀️.
Issue 3: if the home agent sits behind several firewalls, an MN/CN changing its IP address may send traffic to and from the home agent through a different firewall. That firewall may not have the states for those flows, so packets may be dropped at the firewall. Literally so annoying 💀.
5.4. Scenario Where the MN Moves to a Network Protected by Firewall(s) 🧳
Let's consider an HA in a network protected by firewall(s). Here's what we need to look into 👀:
Issue 1: just like Issue 1 in Section 5.1, the MN will send a Binding Update to its home agent after getting a local IP address (CoA) ✨. The Binding Updates and Acknowledgements should be protected by IPsec ESP according to the MIPv6 specifications [1]. But as a default rule, lots of firewalls drop ESP packets. This may cause the Binding Updates and Acknowledgements between the mobile nodes and their home agent to get dropped. Not it 💅.
Issue 2: the MN may be in a communication with a CN, or a CN may be trying to set up a connection with the MN. Either way, packets sent from the CN will be forwarded by the MN's HA to the MN's CoA. But when those packets reach the firewall(s), the incoming traffic may not match any existing state, so the firewall(s) may therefore drop it 🥲.
Issue 3: if the MN is in a communication with a CN, the MN may attempt to execute an RRT for packets that should be route optimized 🦋. Just like Issue 3 in Section 5.1, the Home Test message that should be protected by ESP may be dropped by the firewall(s) protecting the MN. Firewall(s) may, as a default rule, drop any ESP traffic, and as a consequence the RRT cannot be completed.
Issue 4: if the MN is in a communication with a CN, and the MN successfully sent a Binding Update to its CN to use Route Optimization, packets will then be sent from the CN to the MN's CoA and from the MN's CoA to the CN 🌸.
Packets sent from the CN to the MN's CoA may, however, not match any existing entry in the firewall(s) protecting the MN, and therefore be dropped by the firewall(s) 😤.
If packet filtering is applied to uplink traffic (meaning traffic sent by the MN), packets sent from the MN's CoA to the CN may not match any entry in the firewall(s) either, and may be dropped as well 💔.
6. Conclusions 👑
Current firewalls may not only prevent route optimization but may also prevent regular TCP and UDP sessions from being established in some cases. This document describes some of the issues between the Mobile IPv6 protocol and current firewall technologies 🎀.
This document captures the various issues involved in deploying Mobile IPv6 in networks that would invariably include firewalls ✨. A number of different scenarios are described, including configurations where the mobile node, correspondent node, and home agent exist across various boundaries delimited by the firewalls. This gives us a better understanding of the issues when deploying Mobile IPv6, as well as the issues for firewall design and the policies to be installed in them 🧠.
7. Security Considerations 🚨
This document describes several issues that exist between the Mobile IPv6 protocol and firewalls. Lowkey a big deal 😳.
Firewalls may prevent Mobile IP6 signaling in addition to dropping incoming/outgoing traffic 🙈.
If the firewall configuration is modified to support the Mobile IPv6 protocol but not properly configured, many attacks may be possible, as outlined above. Malicious nodes may be able to launch different types of denial of service attacks. This is the part where we absolutely cannot be sloppy, bestie 🫶💀.
8. Acknowledgements 🫶
Huge thanks to James Kempf, Samita Chakrabarti, Giaretta Gerardo, Steve Bellovin, Henrik Levkowetz, and Spencer Dawkins for their valuable comments 💜. Their suggestions helped improve both the presentation and the content of the document ✨.
9. References 📚
9.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.9.2. Informative References
[2] Newman, D., "Benchmarking Terminology for Firewall Performance",
RFC 2647, August 1999.
[3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R.,
Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/
Firewall-1 Advanced Configuration and Troubleshooting", Syngress
Publishing Inc., 2003.
[4] Chen, X., Rinne, J., Wiljakka, J., and M. Watson, "Problem
Statement for MIPv6 Interactions with GPRS/UMTS Packet
Filtering", Work in Progress, January 2006.Appendix A. Applicability to 3G Networks 📱
In 3G networks, different packet filtering functionalities may be implemented to prevent malicious nodes from flooding or launching other attacks against 3G subscribers 🛰️. The packet filtering functionality of 3G networks is further described in [4]. Packet filters are set up and applied to both uplink and downlink traffic: outgoing and incoming data that doesn't match the packet filters is dropped. The issues described in this document also apply to 3G networks 💖.
Authors' Addresses 🌈
Franck Le
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213
USA
EMail: franckle@cmu.edu
Stefano Faccin
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
EMail: sfaccinstd@gmail.com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
EMail: Basavaraj.Patil@nokia.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006).
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 provided by the IETF
Administrative Support Activity (IASA).📦 where this page comes from
- ietf: rfc4487 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms