MIP6 Working Group Gabor Bajko Internet Draft Document: <draft-bajko-mip6-rrtfw-01.txt> October, 2006 Firewall friendly RTT for MIPv6 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 1. Abstract Firewalls represent an integral part of today's IP networks, currently based on IPv4 technology. Deployment of IPv6 is under way, and firewall vendors will need to deploy firewalls which will be able to handle IPv6 packets, including its many extensions. Mobile IPv6, standardized in RFC3775, specifies a number of extensions and procedures to IPv6, which do not work when firewalls are on the data communication path [1]. This document defines a slightly modified Return Routability Test (RRT) for MIPv6 [2]. The new method is firewall friendly and allows a mobile node to send Binding Update message to its correspondent 1 Firewall friendly RTT for MIPv6 October 2006 node (so that Route Optimization can be applied) and ensures that the CN receives the Binding Update, even when either the mobile node, the CN, or both are located behind firewalls. 2. Conventions used in this document 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 RFC-2119 [1]. 3. Abbreviation used in this document This document uses the following abbreviations: o CN: Correspondent Node o CoA: Care of Address o CoT: Care-of Test o CoTI: Care-of Test Init o HA: Home Agent o HoA: Home Address o HoT Home Test o HoTI: Home Test Init o MN: Mobile Node o RO: Route Optimization o RRT: Return Routability Test 3. Table of Content 1. Abstract 1 2. Conventions used in this document 1 3. Table of Content 2 4. Introduction 3 5. Enabling basic mobile IPv6 operation through firewalls 4 6. Enabling route optimization through firewalls 4 5. New RRT proposal 8 5.1 RRT procedures at the MN 9 5.2 RRT procedures at the CN 9 5.3 HA processing of CoTI-FW 9 5.4 CoTI-FW message 9 5.5 New Mobility Options 10 6. Race conditions 10 7. Security considerations 10 8. Contributors 10 9. References 11 10. Author's Addresses 12 4. Introduction Current firewalls typically create state and filter data traffic based on the five tuple (sourceIP, destIP, Prot, sourcePort, MIP6 Working Group Expiration 08/25/06 2 Firewall friendly RTT for MIPv6 October 2006 destPort). Filtering may be applied either to only incoming traffic or both incoming and outgoing traffic. RFC3775 recommends the use of IPsec ESP to protect packets between the MN and its home agent, while today's firewalls, as a default rule, drop ESP packets, thus preventing the use of mobile IPv6. As mobile IPv6 could be regarded as a service offered to the mobile nodes, it is expected that firewalls placed between the access network, where the mobile node acquires its CoA, and the home network, where the mobile node's HA is residing, will relax the filtering rules based on some roaming agreements, thus allowing mobile nodes to register their CoA with the HA and use mobile IP. Even though mobile IPv6 signaling between the MN and its HA could be guaranteed using static configurations in the firewalls, there is no way to ensure the same for the signaling between the MN and the CN (for the return routability test purposes). Without applying route optimization the MN and the CN would be forced to communicate through their home agents, and that, based on their topological location, could result in a trombone effect introducing delays. Such additional delays might not be tolerated by interactive applications sensitive to delays. In order to ensure a successful deployment of IPv6 and mobile IPv6 in current IP networks, it is important to have mechanisms and guidelines in place which help the smooth operation of the protocol in a firewalled environment. There are a limited number of possibilities on how to enable mobile IPv6 through firewalls. One proposal, using the NSLP NATFW protocol can be found in [3]. The document proposes that the mobile node running mobile IPv6 uses the NSLP NATFW protocol to open the required pinholes in the firewalls on the path between the MN and the CN, before any and each mobile IPv6 signaling is initiated. The proposal also requires that all the firewalls on the path support the NSLP NATFW protocol. The proposal in this document describes an alternative solution for the problem by making some recommendations on firewall configuration and defining an extension to mobile IPv6. 5. Enabling basic mobile IPv6 operation through firewalls MIP6 Working Group Expiration 04/20/07 3 Firewall friendly RTT for MIPv6 October 2006 In order to enable the mobile node to use mobile IPv6, it is required to allow a communication path between the MN and its HA. More specifically, the Binding Update, Binding Acknowledgement, Binding error and Binding Refresh Request messages will need to pass through the firewalls on the path unaltered. RFC3775 mandates the use of IPsec and recommends the use of ESP for these messages. It is thus recommended that firewall administrators create a rule in the firewall to allow ESP protected packets between the MN and its HA to pass through. As these packets might not necessarily be ESP protected, the firewall would need to recognize mobility header packets and create a rule to allow these packets to pass through. One example of such a rule could be to filter on the sourceIP, destIP and next header value of 135. 6. Enabling route optimization through firewalls In order to enable route optimizations through firewalls, both HoTI and CoTI messages (and the corresponding HoT and CoT) need to successfully pass through. It is assumed that at the time when the MN initiates a route optimization procedure towards the CN, there is already some sort of data communication between the MN and the CN. If the CN is behind firewall and that firewall does have a rule to allow packets from the HoA of the MN to the address of the CN, then there is a good chance that HoTI would also make it through the firewall. The filtering rule would need to be relaxed to allow in addition MH packets through between the two destinations (HoA of the MN and the address of the CN). If such a rule does not exist in the firewall protecting the CN, then HoTI will be dropped and the return routability test will fail. In order to facilitate the communication between the mobile nodes, firewalls on the data path between an MN and a CN could also create the following pinholes automatically: - a pinhole from the address of the CN to the HoA of the MN present in the type 2 Routing Header - - a pinhole from the CoA of the MN to the HoA of the CN present in the Destination Options extension Header MIP6 Working Group Expiration 04/20/07 4 Firewall friendly RTT for MIPv6 October 2006 If it is only the MN protected by firewalls but the CN is not, then HoTI will successfully arrive to the CN. The firewall protecting the MN would need to allow the corresponding HoT to pass through and reach the MN. For this, the firewall may need to create a rule when forwarding the HoTI. An example of such a rule is to allow packets between the HoA of the MN and the address of the CN with the Next Header value of 135 to pass through. Once HoTI is sent out and a HoT response is received, the MN will send a CoTI message from its current CoA. If there is a firewall protecting the CN, that firewall will drop the CoTI message as it is coming from an untrusted source. In order to illustrate the problem, lets assume a communication between an inner node A (protected by the firewall), and an external mobile node B. It is assumed that the Firewall protecting the CN (node A) trusts the HoA of the mobile node B, therefore MH packets like HoTI are allowed to pass through the Firewall without problems. As specified in the Mobile IP [2], the transport and above layers of the ongoing communications should be based on the Home IP address and HoA of node B, and not the local IP address that node B might get while roaming in order to support mobility. The state created in the firewall protecting node A is therefore initially based on the IP address of node A, and the home address of the node B, HoA of node B. If the mobile node B is in its home network, the packets are directly exchanged between the nodes A and B. If the mobile node B is roaming, the session can be maintained thanks to the Home Agent of node B and the reverse tunneling mechanism [2]. Packets forwarded by the Home Agent to node A will have the source IP address indicating the Home IP address of node B and the destination IP address indicating the IP address of node A. Such packets can thus pass the packet filter inspection in the firewall protecting node A. However nodes A and B might be close while node Bs Home agent may be far, resulting in a 'trombone effect' that can create delay and degrade the performance. The Mobile IP specifications have defined the route optimization procedure [2] in order to solve this issue. The mobile node should first execute a Return Routability Test: the Mobile Node B should send a Home Test Init message (HoTI) via MIP6 Working Group Expiration 04/20/07 5 Firewall friendly RTT for MIPv6 October 2006 its Home Agent and a Care of Test Init (CoTI) message directly to its correspondent node A as illustrated in the figure below [1]: MIP6 Working Group Expiration 04/20/07 6 Firewall friendly RTT for MIPv6 October 2006 +----------------+ | +----+ HoTI (HoA) +----+ | | FW |<----------------|HA B| | +----X +----+ | +---+ | ^ CoTI dropped ^ | | A | | | by the FW | | +---+ | | | HoTI | | | | | | | CoTI (CoA)+---+ | | +------------------| B | +----------------+ +---+ Network protected External Mobile by a firewall Node The Care of Test Init message is more particularly sent from the new CoA, however such packet will not match any entry in the packet filter in the firewall and, the CoTI message will thus be dropped. As a consequence, the RRT cannot be completed and Route optimization cannot be applied due to the presence of a firewall. Support for route optimization is not a non-standard set of extensions, but a fundamental part of the protocol. Firewalls however prevent route optimisation to be applied by blocking the Return Routability Test messages. The above scenario is one from the problem statements described in [1]. One could argue that CoTI could be reverse tunneled in the same way as HoTI, and the problem would be solved. Even though sending CoTI through the HA provides solution for the case when the CN is behind Firewall, the problem would not be solved for the symmetric scenario, when the MN is behind Firewall: if a CoTI is not sent from the CoA of the MN, the Firewall protecting the MN would not open a pinhole for the <MN CoA, CN CoA> address pair, and thus CoT will be dropped, resulting in a failed RRT. If CoTI would follow the path of HoTI and CoT would follow the path of HoT, then the Return Routability Test would be successful, without actually testing the direct path between the MN and CN. If Firewalls are on the path of the data between MN and CN, the data MIP6 Working Group Expiration 04/20/07 7 Firewall friendly RTT for MIPv6 October 2006 packets would be dropped, as corresponding pinholes were not opened. Thus RRT would not reach its purpose. 7. New RTT proposal This document proposes an additional procedure for the Return Routability Test to be performed by mobile nodes who wish to communicate with CNs and either or both parties are behind Firewalls. A failure in RRT is usually detected in the CN by not receiving a CoTI after HOT was sent out. The MN detects the RRT failure by not receiving a CoT after sending out a CoTI. To solve this problem, this document proposes that when the MN detects the RRT failure, it will send out a new MH message, called CoTI-FW. The CoTI-FW will contain the CoA of the MN in the Mobility Options header field and it will need to be reverse tunneled through the HA. A CN receiving a CoTI-FW will know that a CoTI has been probably dropped by the Firewall. It will send a CoT message to the CoA of the MN in response to the CoTI-FW. Even if the MN is behind Firewall, the initial CoTI opened a pinhole which would allow the CoT response to CoTI-FW to pass through the Firewall and reach the MN. Figure 1 illustrates the new RRT procedure (the first three messages are part of the original RRT): Mobile node Home agent Correspondent node | | | Home Test Init (HoTI) | | |------------------------->|------------------------->| | | | | Care-of Test Init (CoTI) | |-----------|FW|---------------------->x|FW| dropped | | | | | Home Test (HoT) | |<-------------------------|<-------------------------| | | | | CoT not sent (as CoTI was not received by CN)<......| timeout waiting for CoT | | | CoTI-FW | | |------------------------->|------------------------->| | Care-of Test (CoT) | |<----------|FW|------------------------|FW|----------| | | Figure 1 The new RRT procedure MIP6 Working Group Expiration 04/20/07 8 Firewall friendly RTT for MIPv6 October 2006 A MN SHOULD always perform the herein described procedure when it experiences problems with the original RTT described in [2]. 7.1 RRT procedures at the MN A MN MUST NOT send a COTI-FW without sending first a COTI. The MN MUST NOT send a COTI-FW if a CoT response has been received for the CoTI. A MN SHOULD always send a CoTI-FW if it does not receive a CoT response to the previously sent CoTI. The CoTI-FW MUST contain the same care-of init cookie as the one sent out in CoTI. A CoTI-FW MUST contain the MN's CoA in the Mobility Options field. 7.2 RRT procedures at the CN Upon receiving a CoTI-FW request, the CN creates a care-of keygen token and uses the current nonce index as the Care-of Nonce Index. It then creates a Care-of Test message and sends it to the care-of address of the mobile node found in the Mobility Options field. 7.3 HA processing of CoTI-FW A CoTI-FW message MUST be processed by the HA as any other Mobility Header message, as described in [2]. 7.4 CoTI-FW message A mobile node uses the CoTI-FW message to finalize the return routability procedure and request a care-of keygen token from a correspondent node when a CoT response to CoTI has not been received. The CoTI-FW message uses the MH Type value 22 (to be registered with IANA). A CoTI-FW message MUST include a mobility options carrying the CoA of the MN sending it. MIP6 Working Group Expiration 04/20/07 9 Firewall friendly RTT for MIPv6 October 2006 7.5 New Mobility Options This specification defines a new Mobility Options called 'MN FW-RRT CoA' which has an alignment requirement of 8n+6. Its format is as follows: 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 = 16 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + MN FW-RRT Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MN FW-RRT CoA mobility options is defined to be carried in a CoTI-FW message. 8. Race conditions There are a few cases when the CN may receive both CoTI and CoTI-FW messages, e.g. when CoT got delayed and the MN sends a CoTI-FW after sending a CoTI. The CN can and SHOULD detect whether CoTI and CoTI-FW were sent from the same CoA or not. If they came from the same CoA, the CN SHOULD NOT respond to both with a CoT, but only to one of them. If CoTI and CoTI-FW came from different CoA, that might be the result of the MN changing CoA (e.g. from a CoA not belonging to the same FW protected network as the CN, to a CoA belonging there) and initiating RRT from both CoA. The CN SHOULD respond to both messages with a CoT. 9. Security considerations The proposal herein assumes that future Firewalls supporting MIPv6, will install states for MH packet initiated flows too, in the same way as it is currently done for UDP flows. It is the understanding of the authors, that this does not introduce any additional security threads to the system. 10. Contributors Acknowledgements to Franck Le for contributing to this draft. Thanks to Lassi Hippelainen for valuable comments. MIP6 Working Group Expiration 04/20/07 10 Firewall friendly RTT for MIPv6 October 2006 11. References [1] Franck Le, Stefano Faccin, Basavaraj Patil, Hannes Tschofenig, 'Mobile IPv6 and Firewalls, Problem statement' IETF Internet draft, May 2005. [2] D. Johnson, C. Perkins, J. Arkko Mobility support in IPv6, RFC3775, June 2004 [3] http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis- mip6-fw-04.txt, wprk in progress 12. Author's Addresses Gabor Bajko gabor.bajko@nokia.com Intellectual Property Statement 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. Disclaimer of Validity 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 MIP6 Working Group Expiration 04/20/07 11 Firewall friendly RTT for MIPv6 October 2006 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. MIP6 Working Group Expiration 04/20/07 12