INTERNET DRAFT Franck Le File: draft-le-mip6-firewalls-00.txt Stefano Faccin Expires: August 2004 Basavaraj Patil Nokia Research Center Dallas February 2004 Mobile IPv6 and Firewalls Problem statement Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. 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 Abstract Firewalls are an integral part of most IP networks deployed today. Firewall technology available today is predominantly for IPv4 networks. Firewalls for IPv6 networks are slowly becoming available. In most cases, current firewall technologies do not support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 protocol details, these security devices will hamper large-scale deployment of the protocol. This document presents in detail some of the issues that firewalls present for Mobile IPv6 deployment. 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: August 2004 [Page 1]
draft-le-mip6-firewalls-00.txt February 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 by Mobile IPv6. Mobile IPv6 protocol design also incorporates a feature termed as Route Optimization. This is not a nonstandard set of extensions but a fundamental part of the protocol that allows to optimize the routing of the 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 aware 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, and the impact of each issue is also described. The goal of this Internet draft is to highlight the issues and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions in the MIP6 WG. 2. Background information One set of issues is related to the way IP addresses are used in Mobile IP, and the way state information is created and mintained 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. The following describes 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 synchronization, 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. Expires: August 2004 [Page 2]
draft-le-mip6-firewalls-00.txt February 2004 When the response comes back, the filter looks up the packets 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 dont 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. 3. Scenario where the external node is a Mobile Node Lets assume a communication between an internal node A, and an external Mobile Node B. +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of B | | A | | FW | | +---+ +----+ | | +---+ | | | B | | | +---+ +----------------+ External Mobile Network protected Node by a firewall 3.1 Issues with Return Routability Test As specified in Mobile IP [MIP6], the tranport and above layers of the ongoing communications should be based on the Home IP address of B, IP HoA B, and not the local IP address that B might get while roaming in order to support mobility. The state created in 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 the home network, packets are directly exchanged between the nodes A and B. If the Mobile Node B Expires: August 2004 [Page 3]
draft-le-mip6-firewalls-00.txt February 2004 is roaming to a vsited network, the session can be maintained thanks to the Home Agent of B and the reverse tunneling mechanism [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 stateful inspection packet filter protecting A. However nodes A and B might be close while B's 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 [MIP6] in order to solve this issue and, to send a Binding Update, the Mobile Node should first execute a Return Routability Test: the Mobile Node B should 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 source address, however such a packet does not match any entry in the stateful inspection packet filter 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 Bs Home Agent and tunneled between Bs Home Agent and B. 3.2 Issues with Firewall Status Update Assuming alternatives mechanisms are developed for authenticating the Binding Update, or other mechanisms are developed to let the RRT packets pass through the stateful inspection packet filter (e.g. rate limiting), the firewall may still drop the packets coming from the new CoA since these incoming packets do not match any existing entry. 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 mean to verify the validity of Binding Update messages and to therefore securely modify the sate information. .sp Changing the firewall states without verifying the validity of the Binding Update messages could lead to Denial of service attacks: malicious nodes may send fake Binding Update forcing the firewall to change the state information, and therefore leading the firewall to drop packets from the connections that use the legitimate addresses. Expires: August 2004 [Page 4]
draft-le-mip6-firewalls-00.txt February 2004 4. Scenario where the internal node is a Mobile Node Lets assume a communication between an internal Mobile Node A, and an external node B. B can also be a Mobile Node and issues raised in section 3 still apply. +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of A +---+ | | A | | FW | | B | | +---+ +----+ +---+ |Internal | External | MN | Node | | +----------------+ Network protected by a firewall 4.1 Issues with Triangular Routing One of the main advantages claimed by Mobile IP 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 Mobile Node which forwards it to the CoA of the MN. When considering stateful inspection packet filters, e.g. when the Mobile Node roams to a network protected by a firewall with such filters, 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. 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 as specified in section 1 a state in the firewall so that the response can pass the firewall and be delivered to the Mobile Node. The state created in the firewall is specific to the Mobility Header being used for the Mobile IPv6 signalling. Also some FW may leave this state open for a while (implementation dependent), whereas other firewalls may delete the state upon receiving the Binding Acknowledgement message. Lets assume a Correspondent node trying to initiate a communication with the Mobile Node. The Correspondent node sends a packet to the Mobile Nodes home address. The packet is intercepted by the MNs Home Agent which tunnels it to the MNs CoA. Expires: August 2004 [Page 5]
draft-le-mip6-firewalls-00.txt February 2004 As described in section 1, the lifetime corresponding to the state in the firewall may have 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 (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. 4.2 Issues with Return Routability Test Security of Mobile IPv6 Binding Update is based on the RRT mechanism [MIP6]. RRT robustness and security level relies on the application of IPsec ESP between the Home Agent and the MN. 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.' Also section 10.4.6 specifies that '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 MN Home Agent. This may however not be Expires: August 2004 [Page 6]
draft-le-mip6-firewalls-00.txt February 2004 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 e.g. overbilling attacks since the user has to pay for the air interface utilization. 4.3 Issues with Change of CoA The internal node A may change CoA within the network protected by the firewall. In such instances A updates its Home Agent with its current location by sending a Binding Update. This Binding Update message may present issues with the firewall if encrypted. Lets assume that the Mobile Node therefore only integrity protects the Binding Update message. When passing the firewall, this message creates a state in the firewall that will allow the response to pass the firewall and reach the Mobile Node. The state information includes the Mobile Node, the Home Agents IP addresses, and the Protocol Identifier indicating a a packet containing a Mobility Header The Home Agent updates its binding cache and replies with a Binding Acknowledgement message. The latter can pass the firewall and reach the Mobile Node thanks to the state previously created in the firewall. After this procedure the Home Agent forwards subsequent packets destined to the Mobile Node to the new CoA. The firewall however does not have any state for the new incoming data packets, since such packets are addressed to the new CoA of the Mobile Node, whereas the firewall state was created based on the old CoA. The incoming packets are therefore dropped at the firewall. If the Mobile Node were communicating with correspondent nodes, all the states in the firewall had been created for the previous MNs CoA. 4.4 Change of firewall When the MN A moves, it may roams to a subnet served by a different firewall. A might be sending BU to the CN (even assuming RRT problem section 4.2 - can be solved or other authentication mechanism is developed), incoming packets may however be dropped at the firewall since this latter does not have any state. 5. 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, but the issues are not Expires: August 2004 [Page 7]
draft-le-mip6-firewalls-00.txt February 2004 limited to the ones described in this document. There are other ones and the next version of this Internet draft will detail other issues. However the authors considered relevant to present these problems as soon as possible, so that network administrators who intend to deploy Mobile IPv6 can consider them, and so that solutions/tools can be developed to solve the identified problems. 6. Security Considerations This document describes the issues between current firewall technology and the Mobile IP protocol. No solution is being proposed, and therefore no security risks are being introduced. 7. References [MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in in IPv6", draft-ietf-mobileip-ipv6-24.txt, June 30, 2003 [GONC] Firewalls complete / Marcus Goncalves [STRE] Firewalls 24 seven / Matthew Strebe and Charles Perkins [CHES] Firewalls and Internet Security, Repelling the Wily Hacker / William R. Cheswick and Steve M. Bellovin Author's Address: Franck Le Stefano Faccin Nokia Research Center, Dallas Nokia Research Center, Dallas 6000 Connection Drive 6000 Connection Drive Irving, TX-75063, USA. Irving, TX-75063. USA. E-Mail: franck.le@nokia.com E-Mail: stefano.faccin@nokia.com Phone : +1 972 374 1256 Phone : +1 972 894 4994 Basavaraj Patil Nokia, Dallas 6000 Connection Drive Irving, TX-75063, USA. EMail: Basavaraj.Patil@nokia.com Phone: +1 972-894-6709 Expires: August 2004 [Page 8]