INTERNET DRAFT Franck Le File: draft-ietf-mip6-firewalls-00.txt Stefano Faccin Expires: February 2005 Basavaraj Patil Nokia H. Tschofenig Siemens August 2004 Mobile IPv6 and Firewalls Problem statement Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Firewalls are an integral aspect of a majority of IP networks today given the state of security in the Internet, threats and vulnerabilities to data networks. IP networks today are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development. Mobility support for IPv6 has now been standardized as specified in RFC3775 [MIP6]. Given the fact that Mobile IPv6 is a recent Expires: February 2005 [Page 1]
draft-ietf-mip6-firewalls-00.txt August 2004 standard, most firewalls available for IPv6 networks today do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will interfere in the smooth operation of the protocol and can be a detriment to deployment. This document presents in detail some of the issues that people deploying IPv6 networks which include firewalls should consider when expanding the scope to support Mobile IPv6 as well. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as GPRS/UMTS and cdma2000 networks where packet filters are implemented in the GGSN in GPRS/UMTS networks and the PDSN in cdma2000 networks. The goal of this Internet draft is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG. Expires: February 2005 [Page 2]
draft-ietf-mip6-firewalls-00.txt August 2004 1. Introduction Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile IPv6 node to be reachable via its home IPv6 address irrespective of any link that the mobile attaches to. This is possible as a result of the extensions to IPv6 defined in the Mobile IPv6 specification [MIP6]. Mobile IPv6 protocol design also incorporates a feature termed as Route Optimization. This set of extensions is a fundamental part of the protocol that enables optimized routing of packets between a Mobile Node and its correspondent node and therefore the performance of the communication. In most cases, current firewall technologies however do not support Mobile IPv6 or are even unaware of Mobile IPv6 headers and extensions. Since most networks in the current business environment deploy firewalls, this may prevent future large-scale deployment of the Mobile IPv6 protocol. This document presents in detail some of the issues that firewalls present for Mobile IPv6 deployment, as well as the impact of each issue. 2. Background information 2.1 Overview of stateful inspection packet filters One set of issues is related to the way IP addresses are used in Mobile IP, and the way state information is created and maintained in stateful inspection packet filters. We refer to the internal node as the node connected to the network protected by the firewall, and to external node as the node outside the boundaries of the network protected by the firewall. Subsequently, we describe how stateful inspection packet filters work: When a MN connects to a TCP socket on another host in the Internet, it provides, at the connection setup, the socket (IP address and port) on which it expects to receive a response. When that SYN packet is routed through the firewall, the firewall makes an entry in its state table containing the destination socket and the response socket, and then forwards the packet to the destination. When the response comes back, the filter looks up the packets Expires: February 2005 [Page 3]
draft-ietf-mip6-firewalls-00.txt August 2004 source and destination sockets in its state table: If they match an expected response, the firewall lets the packet pass. If no table entry exists, the packet is dropped since it was not requested from inside the network. The filter removes the state table entries when the TCP close session negotiation packets are routed through, or after some period of delay, usually a few minutes. This ensures that dropped connections do not leave table holes open. For UDP, similar state is created but since UDP is connectionless and the protocol does not have indication of the beginning nor the end of a session, the state is based only on timers. 2.2 Mobile IP6 issues with packet filtering in 3G networks In 3G networks, packet filtering functionalities may be implemented to prevent malicious nodes from flooding or launching other attacks against the 3G subscribers. The packet filtering functionality of 3G networks are further described in [3GPP]. In such case, packet filters are set up and applied to both uplink and downlink traffic: outgoing and incoming data not matching the packet filters is dropped. The issues described in the following sections thus also apply to 3G networks. 3. Analysis of various scenarios involving MIP6 nodes and firewalls The following section describes various scenarios involving MIP6 nodes and firewalls and presents the issues related to each scenario. In the following section, the node in a network protected by a firewall will be refered to the inner node, and the node in the external network will be refered to the external node. Expires: February 2005 [Page 4]
draft-ietf-mip6-firewalls-00.txt August 2004 +----------------+ | | | | | | | +---+ +----+ | | A | | FW | | +---+ +----+ |Inner Node | +---+ | | | B | | | +---+ +----------------+ External Node Network protected by a firewall Figure 1. Illustration of inner and external nodes 3.1 Scenario when the external node is a Mobile Node Let's assume a communication between an internal node A, and an external Mobile Node B. The node A is in a network protected by a firewall, and node B may also be protected by a firewall but this section focuses on the issues related to the firewall protecting the node A. Issues related to the firewall protecting node B are further described in the following section. +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of B | | A | | FW | | +---+ +----+ | | +---+ | | | B | | | +---+ +----------------+ External Mobile Network protected Node by a firewall Figure 2. Issues between MIP6 and firewalls when a firewall is protecting the CN 3.1.1 Return Routability Test sp As specified in Mobile IPv6 [MIP6], a MN should base its communication on the Home IP address of B, IP HoA B, and not on the Expires: February 2005 [Page 5]
draft-ietf-mip6-firewalls-00.txt August 2004 care-of-address that B obtains while attached to a link other than its home link. The state created by the stateful inspection packet filter protecting A is therefore initially based on the IP address of A (IP A) and the home address of the node B (IP HoA B). If the Mobile Node B is connected to its home link, packets are directly exchanged between the nodes A and B. If the Mobile Node B is attached to any other link than its home link (in which case it has a care-of-address), the session can still be maintained by having the MN tunnel the traffic destined to the CN (Node A) via its home agent [MIP6]. Packets forwarded by the Home Agent to the node A will have the source IP address indicating the Home IP address of B and the destination IP address indicating the IP address of A. Such packets can thus pass the firewall functionality protecting A. However nodes A and B might be topologically close to each other while B's Home Agent may be far away, resulting in a trombone effect that can create delay and degrade the performance. Route Optimization is a feature that enables a MN to communicate directly with its CN, without involving the MN's Home Agent in the data path. So in the current scenario the MN B can initiate the route optimization procedure with Node A. Route optimization requires the MN B to send a Binding Update to Node A in order to create an entry in its binding cache that maps the MNs home address to its current care-of-address. However, prior to sending the binding update, the Mobile Node must first execute a Return Routability Test: - the Mobile Node B has to send a Home Test Init message via its Home Agent and - a Care of Test Init message directly to its Correspondent Node A. The Care of Test Init message is sent using the new CoA of B as the source address. Such a packet does not match any entry in the firewall protecting A and as described in Section 2, the CoTi message will thus be dropped by the firewall. As a consequence, the RRT cannot be completed and route optimization cannot be applied. Every packet has to go through the node B's Home Agent and tunneled between B's Home Agent and B. Expires: February 2005 [Page 6]
draft-ietf-mip6-firewalls-00.txt August 2004 +----------------+ | +----+ HoTI (HoA) +----+ | | FW |<----------------|HA B| | +----X +----+ | +---+ | ^ (CoTI is dropped ^ | | A | | | by FW) | | +---+ | | | HoTI | | | | | | | CoTI (CoA)+---+ | | +------------------| B | +----------------+ +---+ Network protected External Mobile by a firewall Node Figure 3. Issues with Return Routability Test 3.1.2 Issues with Firewall Status Update Even if firewalls are made MIPv6 aware (which might require a different Binding Update security solution) a firewall might still drop packets coming from the new CoA since these incoming packets do not match any existing entry. The packet filters in the firewall need to be updated with the COA of the MN in addition to its HoA. Requiring the stateful inspection filters to update the connection state upon detecting Binding Update messages from a node outside the network protected by the firewall does not appear feasible nor desirable, since currently the firewall does not have any means to verify the validity of Binding Update messages and to therefore securely modify the state information. Changing the firewall states without verifying the validity of the Binding Update messages could lead to denial of service attacks. Malicious nodes may send faked Binding Update forcing the firewall to change its state information, and therefore leading the firewall to drop packets from the connections that use the legitimate addresses. An adversary might also use an address update to enable its own traffic to enter the network. 3.2 Scenario when the inner node is a Mobile Node Let's assume a communication between an internal Mobile Node A, protected by a firewall, and an external node B. B can also be a Mobile Node protected by a firewall and issues raised in Section 3 apply in such case. Expires: February 2005 [Page 7]
draft-ietf-mip6-firewalls-00.txt August 2004 +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of A +---+ | | A | | FW | | B | | +---+ +----+ +---+ |Internal | External | MN | Node | | +----------------+ Network protected Figure 4. Issues between MIP6 and firewalls when a firewall is protecting the MN 3.2.1 Issues with Binding Updates and Acknowledgements between the Mobile Nodes and their Home Agent As required by [MIP6], the Mobile Node and the Home Agent MUST use IPsec to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Both the Mobile Nodes and the Home Agents SHOULD use the Encapsulating Security Payload (ESP). Many firewalls would however drop ESP packets (default behavior). This may cause the Binding Updates and Acknowledgements between the Mobile Nodes and their Home Agent to be dropped. 3.2.2 Issues with Reachability One of the main advantages of Mobile IPv6 is that it allows the Mobile Node to be always reachable thanks to the Home Agent. A node desiring to establish a communication will send a packet to the Home Address of the MN which causes the packet to be routed to the home link of the MN. The Home agent intercepts the packet destined for the MN and forwards it to the MNs current point of attachment which is indicated by its care-of-address. When considering firewalls, (e.g. when the Mobile Node roams to a network protected by a firewall), the packet forwarded from the Home Agent to the Mobile Node CoA may be dropped at the firewall since it does not match any existing entry. The following further describes the problem that might occur: When entering the visited network, the MN first acquires a Care of Address and then sends a Binding Update to its Home Agent. This message creates a state in the firewall: Expires: February 2005 [Page 8]
draft-ietf-mip6-firewalls-00.txt August 2004 - it may be a state for the IPsec packet (in the case, the Binding Update message is protected by IPsec) - or it may be a state for a mobility header in case IPsec is not used, but the security of the Binding Update is being provided by some other means such as an authentication option as specified in [AUTH] to solve the issue described in Section 4.1 The Binding Acknowledgement response can pass the firewall due to the created state, and be delivered to the Mobile Node. Some firewalls may leave the created state open for a while (implementation dependent), whereas other firewalls may delete the state upon receiving the Binding Acknowledgement message. Let's assume a Correspondent Node tries to initiate a communication with a Mobile Node. The Correspondent Node sends a packet to the Mobile Node's home address. The packet is intercepted by the MN's Home Agent which tunnels it to the MN's CoA. As described in Section 2, the lifetime corresponding to the state in the firewall may have been expired and the state may have been removed. In such case, the incoming packet sent from the CN does not match any existing entry and is therefore dropped at the firewall. Even if the state created above has not expired yet, the state created is for the Binding Update message (IPsec or Mobility Header) whereas the packet sent from the CN is received under the form of an IP in IP packet. The latter does not match any existing entry and is also dropped. 3.2.3 Return Routability Test Security of Mobile IPv6 Binding Update between the MN and the CN is based on the RRT mechanism, the routing infrastructure and secret sharing (see [MIP6]). Since some RRT messages are routed via the home network, the strong trust relationship between the mobile node and the home agent (and the usage of IPsec ESP) is important. As specified in Mobile IPv6 [MIP6] in Section 5.2.5: "For improved security, the data passed between the Home Agent and the Mobile Node is made immune to inspection and passive attacks. Such protection is gained by encrypting the home keygen token as it is tunneled from the Home Agent to the Mobile Node as specified in Section 10.4.6." Section 10.4.6 furthermore specifies: Expires: February 2005 [Page 9]
draft-ietf-mip6-firewalls-00.txt August 2004 "The return routability procedure described in Section 5.2.5 assumes that the confidentiality of the Home Test Init and Home Test messages is protected as they are tunneled between the Home Agent to the Mobile Node. Therefore, the Home Agent MUST support tunnel mode IPsec ESP for the protection of packets belonging to the return routability procedure.". This assumption is valid in some environments, however for networks protected by a firewall, the requirement can be an issue. Typically firewalls need to filter the packets based on the source/destination IP addresses and the TCP/UDP source/destination ports numbers. When a packet is encrypted using IPsec ESP, such information is not available (in particular the port numbers), therefore firewalls may drop the Home Test messages forwarded by the HA to the MNs CoA. The result is that the MN cannot complete the RRT procedure, and consequently cannot perform route optimization by sending any Binding Update messages. When ESP is applied, the firewall cannot differentiate packets containing the Mobility Header defined by MIPv6, i.e., packets for which Mobile IPv6 is used, from other packets. In order to support RRT, one possible idea could be to let the firewall pass all ESP packets coming from the MNs Home Agent. This may, however, not be desirable since it would allow several types of attacks (e.g. flooding) to be carried out against the MN. In cellular networks such flooding may result in attacks such as overbilling since the user is required to pay for all air-interface utilization. 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. The Mobile Node would have to send UDP packets to the Home Agent to create the corresponding necessary state in the firewall. The Home Agent should also encapsulate the HoT message in a UDP datagram. As other possible solutions, the home keygen token could be encrypted not using IPsec ESP but specific MIP6 fields within the HoT message so that the packet still appears as a Mobility Header one to the firewall as specified in [AUTH]. 3.2.4 Issues with Change of CoA Expires: February 2005 [Page 10]
draft-ietf-mip6-firewalls-00.txt August 2004 The internal node A may change its CoA within the network which is protected by a firewall. Node A updates its mobility binding at the Home Agent by sending a Binding Update. Node A may also send Binding Update to its correspondent nodes. However, even if firewalls are made MIPv6 aware to address the issues described in sections 4.1, 4.2 and 4.3, a firewall might still drop incoming packets sent to the new CoA since these incoming packets do not match any existing entry. The packet filters in the firewall needs to be updated with the new COA of the MN. 3.2.5 Change of firewall When the MN A moves, it may move to a link that is served by a different firewall. Node A might be sending BU to its CN, however incoming packets may be dropped at the firewall since the firewall on the new link that the MN attaches to does not have any state that is associated with the MN. 4. Conclusion Current firewalls may not only prevent route optimization but may also prevent communications to be established in some cases. This document describes some of the issues between the Mobile IP protocol and current firewall technologies. This document captures the various issues involved in the deployment of Mobile IPv6 in networks that would invariably include firewalls. A number of different scenarios are described which include configurations where the mobile node, correspondent node and home agent exist across various boundaries delimited by the firewalls. This enables a better understanding of the issues when deploying Mobile IPv6 as well as providing an understanding for firewall design and policies to be installed therein. 5. Security Considerations This document describes several issues that exist between the Mobile IPv6 protocol and firewalls. Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing traffic. If the firewall configuration is modified in order to support the Mobile IPv6 protocol but not properly configured, many attacks may be possible as outlined above: malicious nodes may be able to Expires: February 2005 [Page 11]
draft-ietf-mip6-firewalls-00.txt August 2004 launch different types of denial of service attacks. 6. References [3GPP] X. Chen, M. Watson, J. Wiljakka and J. Rinne Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering IETF internet draft <draft-chen- mip6-gprs-01.txt>, July 2004 [AUTH] A. Patel, K. Leung, M. Khalil, H. Akhtar and K. Chowdhury, Authentication Protocol for Mobile IPv6, IETF internet draft <draft-patel-mipv6-auth- protocol-01.txt>, May 24, 2004 [CHES] William R. Cheswick and Steve M. Bellovin Firewalls and Internet Security, Repelling the Wily Hacker [MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004 [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. 8. Author's Addresses: Franck Le Nokia Research Center, Dallas 6000 Connection Drive Irving, TX-75039, USA. E-Mail: franck.le@nokia.com Phone : +1 972 374 1256 Stefano Faccin Nokia Research Center, Dallas 6000 Connection Drive Irving, TX-75039. USA. E-Mail: stefano.faccin@nokia.com Phone : +1 972 894 4994 Expires: February 2005 [Page 12]
draft-ietf-mip6-firewalls-00.txt August 2004 Basavaraj Patil Nokia, Dallas 6000 Connection Drive Irving, TX-75039, USA. EMail: Basavaraj.Patil@nokia.com Phone: +1 972-894-6709 Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com 9. IPR Statement Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intel- lectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this docu- ment 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 stan- dard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Warranty 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 Expires: February 2005 [Page 13]
draft-ietf-mip6-firewalls-00.txt August 2004 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- TION 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 (2004). 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. Expires: February 2005 [Page 14]
