MIP6 Working Group Gabor Bajko Internet Draft Franck Le Document: <draft-bajko-mip6-rrtfw-00.txt> February, 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 August 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 1. Abstract 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 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 MIP6 Working Group Expiration 08/25/06 1 Firewall friendly RTT for MIPv6 February 2006 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 2 5. New RRT proposal 5 5.1 RRT procedures at the MN 6 5.2 RRT procedures at the CN 6 5.3 HA processing of CoTI-FW 6 5.4 CoTI-FW message 6 5.5 New Mobility Options 7 6. Race conditions 7 7. Security considerations 7 8. Contributors 7 9. References 7 10. Author's Addresses 8 4. Introduction When a mobile node is behind a Firewall, and/or it is communicating with a node behind a firewall, the Return Routability Procedure might not succeed as the Firewalls usually block packets coming from untrusted sources (e.g. the CoTI or CoT message). 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 HA of the mobile node B, therefore MH MIP6 Working Group Expiration 08/25/06 2 Firewall friendly RTT for MIPv6 February 2006 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 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 08/25/06 3 Firewall friendly RTT for MIPv6 February 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 08/25/06 4 Firewall friendly RTT for MIPv6 February 2006 packets would be dropped, as corresponding pinholes were not opened. Thus RRT would not reach its purpose. 5. 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 08/25/06 5 Firewall friendly RTT for MIPv6 February 2006 A MN SHOULD always perform the herein described procedure when it experiences problems with the original RTT described in [2]. 5.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. 5.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. 5.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]. 5.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 08/25/06 6 Firewall friendly RTT for MIPv6 February 2006 5.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. 6. 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. 7. 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. 8. Contributors Thanks to Lassi Hippelainen for valuable comments. 9. References MIP6 Working Group Expiration 08/25/06 7 Firewall friendly RTT for MIPv6 February 2006 [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 10. Author's Addresses Gabor Bajko gaborbajko@yahoo.com Franck Le Carnegie Mellon University franckle@cmu.edu 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 08/25/06 8 Firewall friendly RTT for MIPv6 February 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 08/25/06 9