[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
INTERNET DRAFT                                                 Franck Le
File: draft-le-mip6-firewalls-00.txt                      Stefano Faccin
Expires: August 2004                                     Basavaraj Patil
                                                   Nokia Research Center
                                                           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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


     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

          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

          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

     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

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

     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

     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

          D. Johnson, C. Perkins, J. Arkko, "Mobility Support in in
          IPv6", draft-ietf-mobileip-ipv6-24.txt, June 30, 2003

          Firewalls complete / Marcus Goncalves

          Firewalls 24 seven / Matthew Strebe and Charles Perkins

          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]