INTERNET DRAFT                                                 Franck
MIP6                                                               F. Le
File: draft-ietf-mip6-firewalls-00.txt                    Stefano
Internet-Draft                                                 S. Faccin
Expires: February August 24, 2005                                   Basavaraj                                        B. Patil
                                                                   Nokia
                                                           H. Tschofenig
                                                                 Siemens
                                                             August 2004
                                                       February 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 certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I he 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 a as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html
   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
   http://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 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].
   RFC 3775.  Given the fact that Mobile IPv6 is a recent 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 deployment of the issues that people deploying IPv6 networks which include firewalls should consider when expanding the
     scope to they 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 networks CDMA2000 networks, where packet filters are implemented
   in the GGSN in GPRS/UMTS networks and the PDSN in
     cdma2000 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.

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].
   [1].

   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 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 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 issues  Terminology

   Return Routability Test (RRT): The Return Routability Test is related to the way IP addresses are used a
      procedure defined in
     Mobile IP, and the way state information RFC 3775 [1].  It is created and maintained
     in stateful inspection packet filters. We refer performed prior to the internal
      Route Optimization (RO), where a mobile node as the (MN) instructs a
      correspondent node connected (CN) to direct the network protected by the
     firewall, and mobile node's data traffic
      to external node as the node outside its claimed care-of address (CoA).  The Return Routability
      procedure provides some security assurance and prevents the boundaries misuse
      of the network protected by the firewall.

     Subsequently, we describe how stateful inspection packet filters
     work:

     When a MN connects Mobile IPv6 signaling to a TCP socket on another host in the Internet,
     it provides, at maliciously redirect the connection setup, traffic or to
      launch other attacks.

3.  Abbreviations

   This document uses the socket (IP address following 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 expects these 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 receive another 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
     makes creates an entry
   in its state table containing the source IP address, the destination socket
   IP 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 packets packet's source IP address, destination IP
   address, Protocol type, source port number and destination sockets port
   number in its state table: If they match an expected response, the
   firewall lets let 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.

     In

   The Mobile IPv6 specifications define three main entities: the following section, Mobile
   Node (MN), the node Correspondent Node (CN) and the Home Agent (HA).  Each
   of these entities may be in a network protected by a
     firewall will be refered to one or many
   firewalls:

   o  Section 5.1 analyzes the inner node, and issues when the node MN is in the
     external a network will be refered to the external node.

          +----------------+
          |                |
          |                |
          |                |
          |  +---+      +----+
          |  | A |      | FW |
          |  +---+      +----+
          |Inner Node      |                +---+
          |                |                | B |
          |                |                +---+
          +----------------+           External Node
          Network
      protected by a firewall

          Figure 1. Illustration of inner and external nodes

3.1 Scenario firewall(s)
   o  Section 5.2 analyzes the issues when the external node CN is in a Mobile Node

     Let's assume a communication between an internal node A, and an
     external Mobile Node B. The node A network
      protected by firewall(s)
   o  Section 5.3 analyzes the issues when the HA is in a network
      protected by a
     firewall, and node B firewall(s)

   The MN may also be moving from an external network, to a network
   protected by a firewall but this
     section focuses on the firewall(s).  The issues related to the firewall protecting
     the node A. Issues related to the firewall protecting node B of this case are
     further described 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 B A               +---+
     |  | A |      | FW |                         |  +---+      +----+ B |
     |  +---+      +----+                         +---+
     |Internal        |                         External
     |   MN           | B |                           Node
     |                |                +---+
     +----------------+           External Mobile
     Network protected                  Node
            by a firewall

  Figure 2. 1: Issues between MIP6 and firewalls when a firewall MN 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 network
                        protected by firewalls

   A number of B, IP HoA B, and not on the
     care-of-address that B obtains while attached issues need to a link other than
     its home link.

     The state created by be considered:

   Issue 1: When the stateful inspection packet filter
     protecting MN A is therefore initially based on connects 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 address HA with its current point of the node B (IP HoA B).

     If the Mobile Node B is connected attachment.  The
      Binding Updates and Acknowledgements should be protected by IPsec
      ESP according to its home link, packets are
     directly exchanged between the nodes A MIPv6 specifications [1].  However, as a
      default rule, many firewalls drop ESP packets.  This may cause the
      Binding Updates and B. If Acknowledgements between the Mobile Node B
     is attached Nodes and
      their Home Agent 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 dropped.

   Issue 2: Let's now consider a node in the external network, B, trying
      to establish a communication with MN tunnel the traffic destined A.

      *  B sends a packet to the CN (Node A) via
     its Mobile Node's home agent [MIP6]. Packets forwarded address.
      *  The packet is intercepted by the MN's Home Agent which tunnels
         it to the
     node A will have the source IP address indicating MN's CoA [1].
      *  When arriving at the Home IP
     address of B and firewall(s) protecting MN A, the destination IP address indicating packet
         may be dropped since the IP
     address of A. Such packets can incoming 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 pass not be able to contact the firewall functionality
     protecting A.

     However nodes MN A and B might be topologically close to each other
     while B's Home Agent may be far away, resulting in establish a trombone
     effect that can create delay and degrade
         communication.

      Even though the performance.

     Route Optimization HA is updated with the location of a feature that enables MN, 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 communicate use Route Optimization (RO) so that
      packets can be directly with its CN, without involving exchanged between the MN's Home Agent in MN and the
     data path. So in CN
      without passing through the current scenario HA.  However the MN B can initiate firewalls protecting
      the
     route optimization procedure MN might present issues 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 Return Routability procedure
      that maps the MNs home address needs 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 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 RRT must be protected by IPsec in the
     firewall protecting A tunnel 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 described
      prevent 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 will firewalls.  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 by
      created in the firewall. As a consequence, firewall(s).

   Issue 5: When the
     RRT cannot MN A moves, it may move to a link that is served by
      a different firewall.  MN A might be completed and route optimization cannot sending a BU to its CN,
      however incoming packets may be applied.
     Every packet has dropped at the firewall, since the
      firewall on the new link that the MN attaches to go through does 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 |      |  +---+         | |                    | HoTI FW |
      |  +---+      +----+
      |                |                +---+
      |                |                |        CoTI (CoA)+---+ B |
      | +------------------| B                |
          +----------------+                +---+
          Network protected
      +----------------+           External Mobile
      Network protected                  Node
        by a firewall                        Node

 Figure 3. Issues with Return Routability Test

3.1.2 2: Issues with Firewall Status Update

     Even if between MIP6 and firewalls are made MIPv6 aware (which might require when 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 firewall following issues need to be updated considered:

   Issue 1: The MN, MN B, should use its Home Address, HoA B, when
      establishing the communication with the COA
     of CN (CN A) if the MN in addition (MN B)
      wants to its HoA.

     Requiring take advantage of the stateful inspection filters to update mobility support provided by the connection
      Mobile IPv6 protocol, for its communication with CN A.  The state upon detecting Binding Update messages from a node outside
     the network protected
      created by the firewall does not appear feasible nor
     desirable, since currently the firewall does not have any means to
     verify protecting CN A is therefore created based
      on the validity IP address of Binding Update messages A (IP A) and to therefore
     securely modify the state information.  Changing the firewall
     states without verifying the validity home address of the Binding Update
     messages could lead to denial of service  attacks. Malicious nodes node 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 from the connections that use the legitimate addresses. An
     adversary might also use an address update to enable its own
     traffic to enter
      protocol type as well as the network.

3.2 Scenario when port 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
Mobile
            Protocol 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
     IPsec B might be topologically close to protect the integrity and authenticity of the Binding
     Updates and Acknowledgements. Both the Mobile Nodes and the each other while B's
      Home
     Agents SHOULD use the Encapsulating Security Payload (ESP).

     Many firewalls would however drop ESP packets (default behavior).
     This Agent may cause the Binding Updates be far away, resulting in a trombone effect that
      can create delay and Acknowledgements between degrade the
     Mobile Nodes and their Home Agent performance.  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 allows initiate the
     Mobile route optimization procedure with Node to be always reachable thanks to A.  Route
      optimization requires the Home Agent. A node
     desiring MN B to establish a communication will send a packet to the
     Home Address of the MN which causes the packet Binding Update to be routed Node 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 it address to the MNs current point of attachment
     which is indicated by its current care-of-address.

     When considering firewalls, (e.g. when  However, prior to
      sending the binding update, the Mobile Node must first execute a
      Return Routability Test:

      *  the Mobile Node roams B has to send a
     network protected by a firewall), the packet forwarded from the Home Test Init (HoTI) message
         via its Home Agent and
      *  a Care of Test Init (COTI) message directly to the Mobile its
         Correspondent Node A.

      The Care of Test Init message is sent using the CoA may be dropped at of B as the firewall
     since it
      source 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 state entry in the firewall:

     - it may
      protecting firewall (2).  The CoTi message will thus be a state for the IPsec packet (in the case, dropped by
      the Binding
       Update message firewall.

      The HoTI is protected by IPsec)

     - or it may be a state for a mobility header in case IPsec is not
       used, but the security of Mobility Header packet, and the Binding Update is being provided by
       some other means such as an authentication option as specified in
       [AUTH] to solve protocol type
      differing from the issue described in Section 4.1

     The Binding Acknowledgement response can pass existing states (2), the firewall due to HoTI packet will also
      be dropped.

      As a consequence, the created state, RRT cannot be completed and route
      optimization cannot be delivered applied.  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 assume
               by a Correspondent firewall                        Node tries to initiate a communication

             Figure 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 corresponding Binding Update to the state
     in the firewall may have been expired and CN 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 packet packets are sent
          from the CN does
     not match any existing entry CoA and is therefore dropped at the
     firewall.

     Even if the state created above has do not expired yet, the state
     created is for the Binding Update message (IPsec or Mobility
     Header) whereas match the packet Downlink Packet filter (2)
      2.  sent from the CN is received under to 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 between uplink packets are sent to the MN MN's CoA and
          do not match the CN is
     based on uplink 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 via CoA
      need to be created in the
     home network, firewall(s).

      Requiring the strong trust relationship between firewalls to update the mobile connection state upon
      detecting Binding Update messages from a node
     and outside the home agent (and network
      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 between firewall does not have any means to verify the Home Agent
      validity of Binding Update messages and
     the Mobile Node is made immune to inspection and passive attacks.
     Such protection is gained by encrypting therefore securely
      modify the home keygen token as it
     is tunneled from state information.  Changing the Home Agent to firewall 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 that validity of the confidentiality Binding Update messages
      could lead to denial of service attacks.  Malicious nodes may send
      faked Binding Update forcing the Home Test Init firewall to change its state
      information, and Home
     Test messages is protected as they are tunneled between therefore leading the Home
     Agent firewall to drop packets
      from the Mobile Node.  Therefore, connections that use the Home Agent MUST support
     tunnel mode IPsec ESP for legitimate addresses.  An
      adversary might also use an address update to enable its own
      traffic to enter the protection of packets belonging network.

   Issue 3: Let's assume that the Binding Update to the return routability procedure.".

     This assumption CN is valid in some environments, however for networks
      successful.  The CN may be protected by a firewall, the requirement can be an issue.

     Typically different firewalls need to filter the packets based on and as
      a result of the
     source/destination MN's change of IP addresses address, incoming and the TCP/UDP source/destination
     ports numbers. When outgoing
      traffic may pass through a packet is encrypted using IPsec ESP, such
     information is different firewall.  The new firewall
      may not available (in particular have any state associated with the port numbers),
     therefore firewalls CN and incoming
      (potentially outgoing traffic) may drop be dropped at the Home Test messages forwarded by firewall.

5.3  Scenario where the HA to the MNs CoA. The result is that the MN cannot complete
     the RRT procedure, and consequently cannot perform route
     optimization in a network protected by sending any Binding Update messages.

     When firewall(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
     containing MIPv6
      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 could
      MIPv6 signaling must be to let protected by IPsec ESP.

   Issue 2: If the firewall pass all ESP
     packets coming from firewall(s) protecting the MNs Home Agent. This may, however, not be
     desirable since it would allow several types of attacks Agent block
      unsolicited incoming traffic (e.g.
     flooding) to be carried out against  as stateful inspection packet
      filters do), the MN. In cellular networks
     such flooding firewall(s) may result in attacks such as overbilling since drop 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
     it Home Agent is not possible to detect the presence of a Firewall
     automatically in the same fashion as with a NAT. A NAT modifies the
     source network protected by several
      firewalls, a MN/CN's change of IP address when an IP packet travels from may result in the private
      traffic to and from the
     public addressing space. For Home Agent passing through a Firewall this is different
      firewall that may 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 states corresponding necessary state in the firewall. The Home
     Agent should also encapsulate to the HoT message in a UDP datagram. flows.
      As other possible solutions, the home keygen token could a consequence, packets may be
     encrypted not using IPsec ESP but specific MIP6 fields within the
     HoT message so that dropped at the packet still appears as firewall.

5.4  Scenario where MN moves to a Mobility Header
     one network 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 specified issue 1 described in [AUTH].

3.2.4 Issues with Change of CoA
     The internal node A may change its CoA within Section 5.1, the network which is
     protected by MN
      will send a firewall. Node A updates Binding Update to its mobility binding at the Home Agent by sending after acquiring a
      local IP address (CoA).  The Binding Update. Node A may also send
     Binding Update Updates and Acknowledgements
      should be protected by IPsec ESP according to its correspondent nodes. the MIPv6
      specifications [1].  However, even if as a default rule, many firewalls are made MIPv6 aware to address
      drop ESP packets.  This may cause the
     issues described in sections 4.1, 4.2 Binding 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 incoming communication 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
     incoming
      MN's CoA.  However when the packets do arrive at the firewall(s), the
      incoming traffic may not match any existing entry.

     The packet filters state, and the
      firewall(s) may therefore drop it.

   Issue 3: If the MN is in a communication with a CN, the firewall needs MN may
      attempt to execute a RRT for packets to be updated with route optimized.
      Similarly to the new
     COA of issue 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

     When  Firewall(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 to is in a link communication with a CN, and assuming that is served by
      the MN successfully sent a
     different firewall. Node A might be sending BU Binding Update to its CN, however
     incoming CN to use Route
      Optimization, packets may will then be dropped at sent from the firewall since CN to the firewall
     on MN's
      CoA and from the new link that MN's CoA to the MN attaches CN.
      Packets sent from the CN to does the MN's CoA may however not have match any state
     that
      existing entry in the firewall(s) protecting the MN, and therefore
      be dropped by the firewall(s).

      If packet filtering is associated with applied to uplink traffic (i.e.  traffic
      sent by the MN.

4. Conclusion MN), 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. Akhtar

8.  Acknowledgments

   We would like to thank James Kempf, Samita Chakrabarti and
                K. Chowdhury, Authentication Protocol Giaretta
   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
                Firewalls their valuable comments.  Their suggestions have helped
   to improve both the presentation and Internet Security, Repelling the Wily
                Hacker

     [MIP6]     D. content of the document.

9.  References

9.1  Normative References

   [1]  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

   [2]  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, Dallas Center
   6000 Connection Drive
   Irving, TX-75039, USA.

      E-Mail: TX  75039
   USA

   Email: franck.le@nokia.com
      Phone : +1 972 374 1256

   Stefano Faccin
   Nokia Research Center, Dallas Center
   6000 Connection Drive
   Irving, TX-75039. USA.

      E-Mail: TX  75039
   USA

   Email: stefano.faccin@nokia.com
      Phone : +1 972 894 4994

   Basavaraj Patil
      Nokia, Dallas
   Nokia Research Center
   6000 Connection Drive
   Irving, TX-75039, USA.

      EMail: TX  75039
   USA

   Email: Basavaraj.Patil@nokia.com
      Phone: +1 972-894-6709
   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern Bavaria  81739
   Germany

      EMail:

   Email: Hannes.Tschofenig@siemens.com

9. IPR Statement

Appendix 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 [2].  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- lectual
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this docu- ment document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this stan- dard. standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Warranty Validity

   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- TION
   INFORMATION 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.