Network Working Group Yang Shen Internet-Draft Zhang Hongke Expires: May, 2006 Zhang Sidong Beijing Jiaotong University Miao Fuyou Huawei Technologies November, 2005 Firewall Traversal for Mobile IPv6 draft-miao-mip6-ft-01 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 May, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Miao, et al. Expires: May 2006 [Page 1] draft-miao-mip6-ft-01.txt November 2005 As important security devices, firewalls are widely deployed in ISP and enterprise networks. However, currently firewalls, which are essentially designed for fixed networks, are difficult to support Mobile IPv6. Unless firewalls are aware of the detail of mobile IPv6 protocol, they impacts smooth operation of the protocol and can be harmful to mobile IPv6 deployment. This internet draft intends to show some ideas to solve the problems on mobile IPv6 firewall traversal. The solutions proposed are not an overall solution to fix all the traversal problems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4 3. Firewall between MN and CN . . . . . . . . . . . . . . . . . 5 3.1. Simple Analysis . . . . . . . . . . . . . . . . . . . 5 3.2. Process to Return Routability Procedure . . . . . . . 5 3.3. Home Address Matching . . . . . . . . . . . . . . . . 5 3.4. CoA Update. . . . . . . . . . . . . . . . . . . . . . 6 4. Firewall between HA and MN . . . . . . . . . . . . . . . . . 6 4.1. New Mobility Header Types . . . . . . . . . . . . . . 7 4.2. Detection Procedure . . . . . . . . . . . . . . . . . 9 5. Problem Unsolved . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations. . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Author's address . . . . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property Statement . . . . . . . . . . . . . . . . . 11 Expiration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Miao, et al. Expires: May 2006 [Page 2] draft-miao-mip6-ft-01.txt November 2005 1. Introduction Network environment must be considered during the mobile IPv6 deployment. In this case, firewalls which might block Mobile IPv6 traffic become one of the critical issues. In order to support each other's operation, some modifications must be made on both sides. The traffic between MN and HA is encapsulated with IPsec ESP for security, while most firewalls in use are configured to block IPsec data. UDP encapsulation is a possible solution to help IPsec data to pass through the firewall, but it can not be applied to all the traffic between MN and HA for efficiency consideration. So a dynamic firewall detection procedure is designed as a Mobile IPv6 extension in this draft. Two detection messages are sent to HA from MN before BU, one is UDP encapsulated while the other one is not, HA will reponse according to the request, the existence of firewall is determined based on the received replies. Such procedure could solve the efficiency problem which limits the usage of UDP encapsulation. In Mobile IPv6 specification, the cara-of address is transparent to the upper layer, only home address can be seen. If this feature could be introduced into firewall, most problems would get simplified. Miao, et al. Expires: May 2006 [Page 3] draft-miao-mip6-ft-01.txt November 2005 2. Problem Statements There are four scenarios in which firewalls may interfere in the smooth operation of the Mobile IPv6 Protocol. The first scenario is that the CN is protected by a firewall and the MN is an external node. The problem is that data sent by MN could not pass through the firewall. Details are described in [6] in section 3.1. The second scenario is that the MN is protected by a firewall and the CN is an external node. The problem is that data sent by CN could not pass through the firewall. Details are described in [6] in section 3.2. The third scenario actually is similiar to the second one, but it is more complicated. In this scenario, the CN is an external node and the MN protected by a firewall moves to another networks which is protected by another firewall. The problem is that the data sent by CN could not pass through the firewall because there is not any entry in the firewall for the cummunication. Details are described in [6] in section 3.2.5. The last scenario is about the IPsec data transmitted between MN and HA. Most firewalls are configured to refuse IPsec data for security consideration. If MN moves to a network protected by a firewall, the HoTI message in the Return Routability Test will be dropped. Details are described in [6] in section 3.2.3. Miao, et al. Expires: May 2006 [Page 4] draft-miao-mip6-ft-01.txt November 2005 3. Firewall between MN and CN 3.1. Simple Analysis There are two primary reasons that Mobile IPv6 message can not pass through firewall. One reason is that, once MN moved to a new link, the data traffic sent to/from MN is identified by a new care-of address, which will cause the traffic to be treated as a new connection. The other reason is that the firewall is unware of mobile IPv6 control messages, such as BU, BA, CoTI, HoTI and etc, each of such messages will be treated as a new connection by firewall. 3.2. Process to Return Routability Procedure When a firewall receives a packet from outside of the protected network, it checks the IPv6 header, extension headers and TCP/UDP header to get . Then, then firewall matches it to filtering entry. It is convenient for the firewall to obverse the mobility header. Each Mobile IPv6 control message is a part of mobility header. An administrator who wants to support Mobile IPv6 may configure a firewall to permit the packets that contain the mobility header to pass through. Although the process helps return routability procedure to survive firewall, it is noted that it may open loophole for potential attackers. 3.3. Home Address Matching The care-of address of mobile IPv6 is designed to be transparent to the application layer, this idea is presented by using the Type 2 Routing Header and Home Address Option. It can be utilized to implement firewall traversal. If firewall builds its state entry based on MN's home address, it will be very simple to traverse firewall in some cases. It is supposed that CN is protected by a stateful firewall which is configured to filter incoming packets based on home address, and MN is an external node. If CN initiates a connection to MN, the firewall creates entries based on the first packet. For normal firewall, the entries may be and , where xx, yy represent the source port number and destination port number respectively. Now mobile IPv6 firewall gets the home address from type 2 routing header and replace the destination address derived from IPv6 header with home address, so the enties is and . Any incoming packet sent by MN will be checked based on home address. Mobile IPv6 firewall gets the home address from home address destination option (which is carried by the Destination Option extension header) and replaces the source address derived from IPv6 Miao, et al. Expires: May 2006 [Page 5] draft-miao-mip6-ft-01.txt November 2005 header. The final filtering information should be . If it matches any entry, so the data traffic is allowed to pass through the firewall. When the MN is protected by stateful firewall and MN moves in the protected network, it also works. The home address is got from home address destination option and the address order in filtering entry is changed. When a MN moves from one network (protected by firewall or not) to another network protected by firewall, filtering based on home address does not work. 3.4. CoA Update If firewall stores both home address and CoA of a mobile node, it is possible to update the CoA in the filtering entry whenever MN moves. Then the same entry can be applied for all following packets without checking home address. The proposal reduces process for each packet and saves a lot of CPU cycles and memory expense. But in the same time it introduces new loophole resulting denial of service attack. 4. Firewall between HA and MN In mobile IPv6 specification it is specified that the data passed between home agent(HA) and MN should be encrypted and authenticated by IPsec. But nowadays most firewalls don't support IPsec well, or the administrator would like to configure the firewall to drop all ESP packets. When there is such a firewall between HA and MN, it is difficult to accomplish mobile IPv6 communication. An approach was mentioned in [draft-ietf-mip6-firewalls-00]: "A common approach, which is also used for NAT traversal, is to apply UDP encapsulation of IPsec packets. Unlike with NAT traversal it is not possible to detect the presence of a Firewall automatically in the same fashion as with a NAT. A NAT modifies the source IP address when an IP packet travels from the private to the public addressing space. For a Firewall this is not true. Hence, UDP encapsulation needs to be enabled proactively." Enable UDP encapsulation proactively is really not a good idea, since there will not be a firewall in every case. A mechanism is required to detect the firewall existence between HA and MN. A mechanism is introduced to perform this function. Miao, et al. Expires: May 2006 [Page 6] draft-miao-mip6-ft-01.txt November 2005 4.1. New Mobility Header Types Two new mobility header types are defined here, Firewall Detection and Firewall Detection Reply. (1)Firewall Detection message A MN uses Firewall Detection (FD) message to detect the existence of firewall between MN and HA. The Firewall Detection message uses the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Firewall Detection Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. This value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Firewall Detection Cookie 64-bit field which contains a random value, the firewall detection cookie. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Home Test Init message. If no option presents in the message, no padding is required and the Header Len field is set to 1. Miao, et al. Expires: May 2006 [Page 7] draft-miao-mip6-ft-01.txt November 2005 (2)Firewall Detection Reply message The Firewall Detection Reply (FDR) message is a response to the Firewall Detection message, and is sent from HA to MN. The Firewall Detection Reply message uses the MH Type value TBD. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Firewall Detection Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. This value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Firewall Detection Cookie 64-bit field which contains a random value, the firewall detection cookie. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Home Test Init message. If option presents in the message, no padding is required and the Header Len field is set to 1. Miao, et al. Expires: May 2006 [Page 8] draft-miao-mip6-ft-01.txt November 2005 4.2. Detection Procedure In mobile IPv6 specification, each time MN moves into a different link, it first updates its CoA/HoA binding in HA with BU message. But the BU message has the possibility to be dropped by firewalls along the path. To ensure the normal communication, the firewall detection procedure should be performed in the first time. when MN moves to a new link, it sends two Firewall Detection message to HA, one message is UDP encapsulated while the other one is not. These two messages contain the same value of Firewall Detection Cookie which is used to match the pair of messages. HA responds with the Firewall Detection Reply message, whether the reply is encapsulated depends on the received message, in other word, an encapsulated reply corresponds to an encapsulated request and an unencapsulaten reply corresponds to an unencapsulated request. The procedure works on the basis of fact that the encapsulated message could always pass through the firewall. The reply messages MN received will indicate the existence of firewall. If MN receives two reply messages, both the encapsulated one and the unencapsulated one, it means that there is no firewall between HA and MN or firewall allows ESP data to pass through at least. Neither case impacts the communication between MN and HA, so there is no need of encapsulation for following messages. If MN receives the encapsulated message only, it means there is firewall between MN and HA, so UDP encapsulation is required to enable ESP data to pass through the firewall. There may be network congestion or failure, either of the packets may be lost on the path. Because the two messages are sent "at the same time", so it is very possible that they are both lost, which will cause the retransmitting of the two requests. But it is still possible only one message is lost, especially when the two messages are sent along different path in the network. If only the encapsulated message is lost, it indicates that there is no firewall along the path. If the unencapsulated message is lost, MN may use encapsulation according to received packet while there is no firewall actually. It is the only case the firewall detection approach may fail,but such failure is more acceptable than UDP encapsulation proactively. 5. Problem Unsolved When MN moves to a network protected by firewalls, communication whit CN may also be blocked, as described in [6], so further research is required. Miao, et al. Expires: May 2006 [Page 9] draft-miao-mip6-ft-01.txt November 2005 6. Security Considerations When the firewall administrator wants to configure his device to support mobile IPv6, care must be taken. Because the mobile IPv6 works on the network layer, so the rules that allow moblile IPv6 packets to pass through must have the lowest priority. 7. Acknowledgments I would like to appreciate all the project members Chen Jian, Ren Yan, Su Wei, Yang He, Zheng Zuzhou. 8. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Montenegro, G. and Gupta V., "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998. [4] Thiruvengadam S., Tschofenig H. and F. Le, "Mobile IPv6 - NSIS Interaction for Firewall traversal", draft-thiruvengadam-nsis-mip6-fw-01 (work in progress), October 23, 2004. [5] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in progress), July 2004. [6] Le, F., "Mobile IPv6 and Firewalls Problem statement", draft-ietf-mip6-firewalls-03 (work in progress), August 2004. 9. Author's address Miao Fuyou Tel: +86 10 8288 2350 Huawei Technologies Fax: +86 10 8288 2537 No. 3, Xinxi Road, Shangdi, Haidian Beijing China,100085 Email: miaofy@huawei.com Yang Shen Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: belton.yang@hotmail.com Miao, et al. Expires: May 2006 [Page 10] draft-miao-mip6-ft-01.txt November 2005 Zhang Hongke Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: hkzhang@center.njtu.edu.cn Zhang Sidong Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: sdzhang@center.njtu.edu.cn Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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 Miao, et al. Expires: May 2006 [Page 11] draft-miao-mip6-ft-01.txt November 2005 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Expiration This Internet-Draft (draft-miao-mip6-ft-01.txt) expires in May 2006. Miao, et al. Expires: May 2006 [Page 12]