INTERNET DRAFT FranckMIP6 F. Le File: draft-ietf-mip6-firewalls-00.txt StefanoInternet-Draft S. Faccin Expires: FebruaryAugust 24, 2005 BasavarajB. Patil Nokia H. Tschofenig Siemens August 2004February 20, 2005 Mobile IPv6 and Firewalls Problem statement draft-ietf-mip6-firewalls-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, I certifyeach author represents that any applicable patent or other IPR claims of which I amhe or she is aware have been or will be disclosed, and any of which Ihe or she 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. 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 aas "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.htmlhttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.htmlhttp://www.ietf.org/shadow.html. This Internet-Draft will expire on August 24, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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. Current IP networks todayare 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].RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most firewalls available for IPv6 networks todaydo 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 somedeployment of the issues that people deployingIPv6 networks which include firewalls should considerwhen expanding the scope tothey support Mobile IPv6 as well.and firewalls. 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 networksCDMA2000 networks, where packet filters are implemented in the GGSN in GPRS/UMTS networks and the PDSN in cdma2000CDMA2000 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7 5. Analysis of various scenarios involving MIP6 nodes and firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Scenario where the Mobile Node is in a network protected by firewall(s) . . . . . . . . . . . . . . . . . 9 5.2 Scenario where the Correspondent Node is in a network protected by firewall(s) . . . . . . . . . . . . . . . . . 11 5.3 Scenario where the HA is in a network protected by firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14 5.4 Scenario where MN moves to a network protected by firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1 Normative References . . . . . . . . . . . . . . . . . . . 19 9.2 Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 A. Applicability to 3G Networks . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 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 howevertechnologies, 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 about 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 issuesTerminology Return Routability Test (RRT): The Return Routability Test is related to the way IP addresses are useda procedure defined in Mobile IP, and the way state informationRFC 3775 . It is created and maintained in stateful inspection packet filters. We referperformed prior to the internalRoute Optimization (RO), where a mobile node as the(MN) instructs a correspondent node connected(CN) to direct the network protected by the firewall, andmobile node's data traffic to external node as the node outsideits claimed care-of address (CoA). The Return Routability procedure provides some security assurance and prevents the boundariesmisuse of the network protected by the firewall. Subsequently, we describe how stateful inspection packet filters work: When a MN connectsMobile IPv6 signaling to a TCP socket on another host in the Internet, it provides, atmaliciously redirect the connection setup,traffic or to launch other attacks. 3. Abbreviations This document uses the socket (IP addressfollowing abbreviations: o CN Correspondent Node o CoA Care of Address o CoTI Care of Test Init o HA Home Agent o HoA Home Address o HoTI Home Test Init o MN Mobile Node o RO Route Optimization o RRT Return Routability Test 4. Overview of firewalls The following provides a brief overview of firewalls. This section is intended as a background information so that issues with the Mobile IPv6 protocol can then be presented in detail in the following sections. Readers familiar with firewall technology may skip this section. There are different types of firewalls and port)state can be created in these firewalls through different methods. Independent of the adopted method, firewalls typically look at five parameters of the traffic arriving at the firewalls: o Source IP address o Destination IP address o Protocol type o Source port number o Destination port number Based on which it expectsthese parameters, firewalls usually decide whether to allow the traffic or to drop the packets. Some firewalls may filter only incoming traffic while others may also filter outgoing traffic. Stateful packet filters are a specific type of firewalls. They are commonly deployed to protect networks from different threats. Stateful packet filters typically block unsolicited incoming traffic from the external networks. The following briefly describe how these firewalls work since they can create additional issues with the Mobile IPv6 protocol as described in the subsequent sections. When a MN connects using TCP to receiveanother host in the Internet, it sends a response.TCP SYN message to set up the connection. When that SYN packet is routed through the firewall, the firewall makescreates an entry in its state table containing the source IP address, the destination socketIP address, the Protocol type, the source port number and the response socket,destination port number indicated in that packet and then forwards the packet to the destination. When the response comes back, the filter looks up the packetspacket's source IP address, destination IP address, Protocol type, source port number and destination socketsport number in its state table: If they match an expected response, the firewall letslet the packet to 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.5. Analysis of various scenarios involving MIP6 nodes and firewalls The following section describes various scenarios involving MIP6 nodes and firewalls and also presents the issues related to each scenario. InThe Mobile IPv6 specifications define three main entities: the following section,Mobile Node (MN), the nodeCorrespondent Node (CN) and the Home Agent (HA). Each of these entities may be in a network protected by a firewall will be refered toone or many firewalls: o Section 5.1 analyzes the inner node, andissues when the nodeMN is in the externala network will be refered to the external node. +----------------+ | | | | | | | +---+ +----+ | | A | | FW | | +---+ +----+ |Inner Node | +---+ | | | B | | | +---+ +----------------+ External Node Networkprotected by a firewall Figure 1. Illustration of inner and external nodes 3.1 Scenariofirewall(s) o Section 5.2 analyzes the issues when the external nodeCN is in a Mobile Node Let's assume a communication between an internal node A, and an external Mobile Node B. The node Anetwork protected by firewall(s) o Section 5.3 analyzes the issues when the HA is in a network protected by a firewall, and node Bfirewall(s) The MN may also be moving from an external network, to a network protected by a firewall but this section focuses on thefirewall(s). The issues related to the firewall protecting the node A. Issues related to the firewall protecting node Bof this case are furtherdescribed in Section 5.3. 5.1 Scenario where the following section.Mobile Node is in a network protected by firewall(s) Let's consider a MN A, in a network protected by firewall(s). +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of BA +---+ | | A | | FW | | +---+ +----+B | | +---+ +----+ +---+ |Internal | External | MN | B |Node | | +---++----------------+ External MobileNetwork protected Node by a firewallFigure 2.1: Issues between MIP6 and firewalls when a firewallMN is protecting the CN 3.1.1 Return Routability Test sp As specifiedin Mobile IPv6 [MIP6],a MN should base its communication on the Home IP addressnetwork protected by firewalls A number of B, IP HoA B, and not on the care-of-address that B obtains while attachedissues need to a link other than its home link. The state created bybe considered: Issue 1: When the stateful inspection packet filter protectingMN A is therefore initially based onconnects to the network, it should acquire a local IP address of A (IP A)(CoA), and send a Binding Update to its Home Agent to update the home addressHA with its current point of the node B (IP HoA B). If the Mobile Node B is connectedattachment. The Binding Updates and Acknowledgements should be protected by IPsec ESP according to its home link, packets are directly exchanged betweenthe nodes AMIPv6 specifications . However, as a default rule, many firewalls drop ESP packets. This may cause the Binding Updates and B. IfAcknowledgements between the Mobile Node B is attachedNodes and their Home Agent to any other link than its home link (in which case it has a care-of-address), the session can stillbe maintained by havingdropped. Issue 2: Let's now consider a node in the external network, B, trying to establish a communication with MN tunnel the traffic destinedA. * B sends a packet to the CN (Node A) via itsMobile Node's home agent [MIP6]. Packets forwardedaddress. * The packet is intercepted by the MN's Home Agent which tunnels it to the node A will have the source IP address indicatingMN's CoA . * When arriving at the Home IP address of B andfirewall(s) protecting MN A, the destination IP address indicatingpacket may be dropped since the IP address of A. Such packets canincoming packet may not match any existing state. As described in Section 4, stateful inspection packet filters e.g. typically drop unsolicited incoming traffic. * B will thus passnot be able to contact the firewall functionality protecting A. However nodesMN A and B might be topologically close to each other while B's Home Agent may be far away, resulting inestablish a trombone effect that can create delay and degradecommunication. Even though the performance. Route OptimizationHA is updated with the location of a feature that enablesMN, firewalls may prevent Correspondent nodes from establishing communications when the MN is in a network protected by firewall(s). Issue 3: Let's assume a communication between MN A and an external node B. MN A may want to communicateuse Route Optimization (RO) so that packets can be directly with its CN, without involvingexchanged between the MN's Home Agent inMN and the data path. So inCN without passing through the current scenarioHA. However the MN B can initiatefirewalls protecting the route optimization procedureMN might present issues with Node A. Route optimization requiresthe MN B to send a Binding Update to Node A in order to create an entry in its binding cacheReturn Routability procedure that maps the MNs home addressneeds to its current care-of-address. However,be performed prior to sending the binding update,using RO. According to the Mobile Node must first execute a Return Routability Test: -MIPv6 specifications, the Mobile Node B has to send a Home Test Init message via itsHome Agent and - a Care of Test Init message directly to its Correspondent Node A. The Care ofTest Initmessage is sent using the new CoAof B asthe source address. Such a packet does not match any entryRRT must be protected by IPsec in the firewall protecting Atunnel mode. However, firewalls might drop any packet protected by ESP, since the firewalls cannot analyze the packets encrypted by ESP (e.g. port numbers). The firewalls may thus drop the Home Test messages and as describedprevent the completion of the RRT procedure. Issue 4: Let's assume that MN A successfully sends a Binding Update to its Home Agent (resp. Correspondent nodes) - issues 1 (resp. issue 3) solved - the subsequent traffic is sent from the HA (resp. CN) to the MN's CoA. However there may not be any corresponding state in Section 2,the CoTi message willfirewalls. The firewalls protecting A may thus drop the incoming packets. The appropriate states for the traffic to the MN's CoA need to be dropped bycreated in the firewall. As a consequence,firewall(s). Issue 5: When the RRT cannotMN A moves, it may move to a link that is served by a different firewall. MN A might be completed and route optimization cannotsending a BU to its CN, however incoming packets may be applied. Every packet hasdropped at the firewall, since the firewall on the new link that the MN attaches to go throughdoes not have any state that is associated with the node B's Home Agent and tunneled between B's Home Agent and B.MN. 5.2 Scenario where the Correspondent Node is in a network protected by firewall(s) Let's consider a MN in a network, communicating with a Correspondent Node A in a network protected by firewall(s). There is no issue with Reverse Tunneling. However firewalls may present different issues to Route Optimization. +----------------+ | +----+ HoTI (HoA)+----+ | | FW |<----------------|HA B|| +----X +----+HA | +---+| ^ (CoTI is dropped ^| +----+ | A| Home Agent | +---+ +----+ of B | by FW)|CN | | +---+ | | | HoTIFW | | +---+ +----+ | | +---+ | | | CoTI (CoA)+---+B | | +------------------| B| +----------------++---+ Network protected+----------------+ External Mobile Network protected Node by a firewall NodeFigure 3. Issues with Return Routability Test 3.1.22: Issues with Firewall Status Update Even ifbetween MIP6 and firewalls are made MIPv6 aware (which might requirewhen a different Binding Update security solution)CN is in a firewall might still drop packets coming from the new CoA since these incoming packets do not match any existing entry.network protected by firewalls The packet filters in the firewallfollowing issues need to be updatedconsidered: Issue 1: The MN, MN B, should use its Home Address, HoA B, when establishing the communication with the COA ofCN (CN A) if the MN in addition(MN B) wants to its HoA. Requiringtake advantage of the stateful inspection filters to updatemobility support provided by the connectionMobile IPv6 protocol, for its communication with CN A. The state upon detecting Binding Update messages from a node outside the network protectedcreated by the firewall does not appear feasible nor desirable, since currently the firewall does not have any means to verifyprotecting CN A is therefore created based on the validityIP address of Binding Update messagesA (IP A) and to therefore securely modify the state information. Changing the firewall states without verifyingthe validityhome address of the Binding Update messages could lead to denial of service attacks. Malicious nodesnode B (IP HoA B). The states may send faked Binding Update forcing the firewall to change its state information,be created via different means and therefore leading the firewall to drop packets fromthe connections that use the legitimate addresses. An adversary might also use an address update to enable its own traffic to enterprotocol type as well as the network. 3.2 Scenario whenport numbers depend on 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. +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +---+ +----+ of A +---+ | |connection set up. Uplink packet filters (1) Source IP address: IP A | | FW | |Destination IP address: HoA 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 MobileProtocol Type: TCP/UDP Source Port Number: #1 Destination Port Number: #2 Downlink packet filters (2) Source IP address: HoA B Destination IP address: IP A Protocol Type: TCP/UDP Source Port Number: #2 Destination Port Number: #1 Nodes A and their Home Agent As required by [MIP6], the Mobile Node and the Home Agent MUST use IPsecB might be topologically close to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Both the Mobile Nodes and theeach other while B's Home Agents SHOULD use the Encapsulating Security Payload (ESP). Many firewalls would however drop ESP packets (default behavior). ThisAgent may cause the Binding Updatesbe far away, resulting in a trombone effect that can create delay and Acknowledgements betweendegrade the Mobile Nodes and their Home Agentperformance. The MN B may decide to be dropped. 3.2.2 Issues with Reachability One of the main advantages of Mobile IPv6 is that it allowsinitiate the Mobileroute optimization procedure with Node to be always reachable thanks toA. Route optimization requires the Home Agent. A node desiringMN B to establish a communication willsend a packet to the Home Address of the MN which causes the packetBinding Update to be routedNode A in order to create an entry in its binding cache that maps the MNs home link of the MN. The Home agent intercepts the packet destined for the MN and forwards itaddress to the MNs current point of attachment which is indicated byits current care-of-address. When considering firewalls, (e.g. whenHowever, prior to sending the binding update, the Mobile Node must first execute a Return Routability Test: * the Mobile Node roamsB has to send a network protected by a firewall), the packet forwarded from theHome Test Init (HoTI) message via its Home Agent and * a Care of Test Init (COTI) message directly to the Mobileits Correspondent Node A. The Care of Test Init message is sent using the CoA may be dropped atof B as the firewall since itsource address. Such a packet 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 stateentry in the firewall: - it mayprotecting firewall (2). The CoTi message will thus be a state for the IPsec packet (in the case,dropped by the Binding Update messagefirewall. The HoTI is protected by IPsec) - or it may bea state for a mobility header in case IPsec is not used, but the security ofMobility Header packet, and the Binding Update is being provided by some other means such as an authentication option as specified in [AUTH] to solveprotocol type differing from the issue described in Section 4.1 The Binding Acknowledgement response can passexisting states (2), the firewall due toHoTI packet will also be dropped. As a consequence, the created state,RRT cannot be completed and route optimization cannot be deliveredapplied. Every packet has to go through the node B's Home Agent and tunneled between B's Home Agent and B. +----------------+ | +----+ HoTI (HoA) +----+ | | FW |X<---------------|HA B| | +----X +----+ | +---+ | ^ CoTI & HoTI ^ | | A | | | dropped by FW | | +---+ | | | HoTI | | | | | | | CoTI (CoA)+---+ | | +------------------| B | +----------------+ +---+ Network protected External 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 assumeby a Correspondentfirewall Node tries to initiate a communicationFigure 3: Issues 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,Return Routability Test Issue 2: Let's assume that the lifetime correspondingBinding Update to the state in the firewall may have been expired andCN is successful, the state may have been removed. In such case,firewall(s) might still drop packets 1. coming from the CoA, since these incoming packetpackets are sent from the CN does not match any existing entryCoA and is therefore dropped at the firewall. Even if the state created above hasdo not expired yet, the state created is for the Binding Update message (IPsec or Mobility Header) whereasmatch the packetDownlink Packet filter (2) 2. sent from the CN is received underto the form of an IP in IP packet.CoA if uplink packet filters are implemented. The latter does not match any existing entry and is also dropped. 3.2.3 Return Routability Test Security of Mobile IPv6 Binding Update betweenuplink packets are sent to the MNMN's CoA and do not match the CN is based onuplink packet filter (1). The packet filters for the RRT mechanism,traffic sent to (resp. from) the routing infrastructure and secret sharing (see [MIP6]). Since some RRT messages are routed viaCoA need to be created in the home network,firewall(s). Requiring the strong trust relationship betweenfirewalls to update the mobileconnection state upon detecting Binding Update messages from a node andoutside the home agent (andnetwork protected by the usage of IPsec ESP) is important. As specified in Mobile IPv6 [MIP6] in Section 5.2.5: "For improved security,firewall does not appear feasible nor desirable, since currently the data passed betweenfirewall does not have any means to verify the Home Agentvalidity of Binding Update messages and the Mobile Node is made immuneto inspection and passive attacks. Such protection is gained by encryptingtherefore securely modify the home keygen token as it is tunneled fromstate information. Changing the Home Agent tofirewall states without verifying the Mobile Node as specified in Section 10.4.6." Section 10.4.6 furthermore specifies: "The return routability procedure described in Section 5.2.5 assumes thatvalidity of the confidentialityBinding Update messages could lead to denial of service attacks. Malicious nodes may send faked Binding Update forcing the Home Test Initfirewall to change its state information, and Home Test messages is protected as they are tunneled betweentherefore leading the Home Agentfirewall to drop packets from the Mobile Node. Therefore,connections that use the Home Agent MUST support tunnel mode IPsec ESP forlegitimate addresses. An adversary might also use an address update to enable its own traffic to enter the protection of packets belongingnetwork. Issue 3: Let's assume that the Binding Update to the return routability procedure.". This assumptionCN is valid in some environments, however for networkssuccessful. The CN may be protected by a firewall, the requirement can be an issue. Typicallydifferent firewalls need to filter the packets based onand as a result of the source/destinationMN's change of IP addressesaddress, incoming and the TCP/UDP source/destination ports numbers. Whenoutgoing traffic may pass through a packet is encrypted using IPsec ESP, such information isdifferent firewall. The new firewall may not available (in particularhave any state associated with the port numbers), therefore firewallsCN and incoming (potentially outgoing traffic) may dropbe dropped at the Home Test messages forwarded byfirewall. 5.3 Scenario where the HA to the MNs CoA. The resultis that the MN cannot complete the RRT procedure, and consequently cannot perform route optimizationin a network protected by sending any Binding Update messages. Whenfirewall(s) Let's consider a MN moving into a network protected by firewall(s). The following issues may exist: Issue 1: If the firewall(s) block ESP is applied,traffic, many of the firewall cannot differentiate packets containingMIPv6 signaling (e.g. Binding Update, HoT) may be dropped at the Mobility Header defined by MIPv6, i.e., packets for which Mobile IPv6 is used,firewall(s) preventing MN(s) from updating their binding cache and performing Route Optimization, since Binding Update, HoT and other packets. In order to support RRT, one possible idea couldMIPv6 signaling must be to letprotected by IPsec ESP. Issue 2: If the firewall pass all ESP packets coming fromfirewall(s) protecting the MNsHome Agent. This may, however, not be desirable since it would allow several types of attacksAgent block unsolicited incoming traffic (e.g. flooding) to be carried out againstas stateful inspection packet filters do), the MN. In cellular networks such floodingfirewall(s) may result in attacks such as overbilling sincedrop connection set up requests from CN, and packets from MN. Issue 3: If 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 itHome Agent is not possible to detect the presence of a Firewall automaticallyin the same fashion as witha NAT. A NAT modifies the sourcenetwork protected by several firewalls, a MN/CN's change of IP address when an IP packet travels frommay result in the privatetraffic to and from the public addressing space. ForHome Agent passing through a Firewall this isdifferent firewall that may not true. Hence, UDP encapsulation needs to be enabled proactively. The Mobile Node wouldhave to send UDP packets to the Home Agent to createthe states corresponding necessary state in the firewall. The Home Agent should also encapsulateto the HoT message in a UDP datagram.flows. As other possible solutions, the home keygen token coulda consequence, packets may be encrypted not using IPsec ESP but specific MIP6 fields within the HoT message so thatdropped at the packet still appears asfirewall. 5.4 Scenario where MN moves to a Mobility Header onenetwork protected by firewall(s) Let's consider a HA in a network protected by firewall(s). The following issues need to be investigated: Issue 1: Similarly to the firewall as specifiedissue 1 described in [AUTH]. 3.2.4 Issues with Change of CoA The internal node A may change its CoA withinSection 5.1, the network which is protected byMN will send a firewall. Node A updatesBinding Update to its mobility binding at theHome Agent by sendingafter acquiring a local IP address (CoA). The Binding Update. Node A may also send Binding UpdateUpdates and Acknowledgements should be protected by IPsec ESP according to its correspondent nodes.the MIPv6 specifications . However, even ifas a default rule, many firewalls are made MIPv6 aware to addressdrop ESP packets. This may cause the issues described in sections 4.1, 4.2Binding Updates and Acknowledgements between the Mobile Nodes and 4.3,their Home Agent to be dropped. Issue 2: The MN may be in a firewall might still drop incomingcommunication with a CN, or a CN may be attempting to establish a connection with the MN. In both cases, packets sent from the CN will be forwarded by the MN's HA to the new CoA since these incomingMN's CoA. However when the packets doarrive at the firewall(s), the incoming traffic may not match any existing entry. The packet filtersstate, and the firewall(s) may therefore drop it. Issue 3: If the MN is in a communication with a CN, the firewall needsMN may attempt to execute a RRT for packets to be updated withroute optimized. Similarly to the new COA ofissue 3, Section 5.1, the Home Test message which should be protected by ESP may be dropped by firewall(s) protecting the MN. 3.2.5 Change of firewall WhenFirewall(s) may as a default rule drop any ESP traffic. As a consequence, the RRT cannot be completed. Issue 4: If the MN A moves, it may move tois in a linkcommunication with a CN, and assuming that is served bythe MN successfully sent a different firewall. Node A might be sending BUBinding Update to its CN, however incomingCN to use Route Optimization, packets maywill then be dropped atsent from the firewall sinceCN to the firewall onMN's CoA and from the new link thatMN's CoA to the MN attachesCN. Packets sent from the CN to doesthe MN's CoA may however not havematch any state thatexisting entry in the firewall(s) protecting the MN, and therefore be dropped by the firewall(s). If packet filtering is associated withapplied to uplink traffic (i.e. traffic sent by the MN. 4. ConclusionMN), packets sent from the MN's CoA to the the CN may not match any entry in the firewall(s) either and may be dropped as well. 6. Conclusions 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.7. 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 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. Akhtar8. Acknowledgments We would like to thank James Kempf, Samita Chakrabarti and K. Chowdhury, Authentication ProtocolGiaretta Gerardo for Mobile IPv6, IETF internet draft <draft-patel-mipv6-auth- protocol-01.txt>, May 24, 2004 [CHES] William R. Cheswick and Steve M. Bellovin Firewallstheir valuable comments. Their suggestions have helped to improve both the presentation and Internet Security, Repellingthe Wily Hacker [MIP6] D.content of the document. 9. References 9.1 Normative References  Johnson, C.D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004 [STUN] Rosenberg, J., Weinberger, J., Huitema, C.2004. 9.2 Informative References  Chen, X., Watson, M. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. 8. Author's Addresses:M. Harris, "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", Internet-Draft draft-chen-mip6-gprs-02, October 2004. Authors' Addresses Franck Le Nokia Research Center, DallasCenter 6000 Connection Drive Irving, TX-75039, USA. E-Mail:TX 75039 USA Email: firstname.lastname@example.org Phone : +1 972 374 1256Stefano Faccin Nokia Research Center, DallasCenter 6000 Connection Drive Irving, TX-75039. USA. E-Mail:TX 75039 USA Email: email@example.com Phone : +1 972 894 4994Basavaraj Patil Nokia, DallasNokia Research Center 6000 Connection Drive Irving, TX-75039, USA. EMail:TX 75039 USA Email: Basavaraj.Patil@nokia.com Phone: +1 972-894-6709Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, BayernBavaria 81739 Germany EMail:Email: Hannes.Tschofenig@siemens.com 9. IPR StatementAppendix A. Applicability to 3G Networks In 3G networks, different 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 . 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 this document also apply to 3G networks. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intel- lectualIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this docu- mentdocument 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.standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of WarrantyValidity 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 INFORMA- TIONINFORMATION 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).(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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.