HIPRG                                                      H. Tschofenig
Internet-Draft                                                   Siemens
Expires: April 27, 2006                                              M. Shanmugam
                                                                    TUHH
                                                        October 24, 2005
Expires: September 7, 2006                                    Siemens AG
                                                           March 6, 2006

     Traversing HIP-aware NATs and Firewalls: Problem Statement and
                              Requirements
           draft-tschofenig-hiprg-hip-natfw-traversal-03.txt
           draft-tschofenig-hiprg-hip-natfw-traversal-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 27, September 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

Abstract

   The Host Identity Protocol (HIP) is a signaling protocol protocol, which adds another
   supports mobility and multihoming by adding a new layer to the Internet model TCP/IP
   stack.  By carring relevant parameters in the signaling messages, HIP
   can be used to establish IPsec encapsulating security payload (ESP)
   security associations between two hosts.  Middleboxes (e.g. firewalls
   and (optionally) establishes network address translators) cannot inspect transport layer
   headers of data traffic if that traffic is sent over an IPsec ESP
   SAs to protect subsequent data traffic.
   tunnel.  However, HIP is designed to be a middlebox friendly protocol, friendly; it allows
   enables the middleboxes (such as NATs
   and Firewalls) to participate in inspect the base exchange signaling messages.  The
   information that they can derive from that messages in order enables the
   middleboxes to learn uniquely identify the flow identifier subsequent data flows, e.g. for
   the purposes of multiplexing and thereby, relying demultiplexing .  A middlebox that
   implements the data traffic.

   Adding relevant mechanisms is called "HIP-aware".  This
   document presents a problem statement and lists some requirements
   that are necessary for a HIP-aware middlebox traversal technique.
   These include authentication and authorization mechanisms can of signaling end-hosts
   by the middleboxes.  Such authorization will help the
   middlebox middleboxes to
   decide which whether or not an end hosts are host is allowed to traverse a firewall.
   This traverse, and can
   potentially prevent waste of network resources and limit unwanted traffic.  This document gives a problem statement and
   requirements for HIP-aware middlebox traversal techniques.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5  6
   4.  Overview of  HIP Base Exchange with Middleboxes . . . . . . . .  7
     4.1.  HIP Base Exchange with NAT . . . . . . . . . . . . . . . .  7
     4.2.  8
     4.1.  HIP Base Exchange with Firewall  . middleboxes . . . . . . . . . . . .  8
   5.  Scenarios  . . . . . . . . . . . . . . .
     4.2.  HIP Base Exchange with ESP Parameters and Middleboxes  . .  9
     4.3.  HIP Mobility/Multihoming Exchange with Middleboxes . . . . 10
   5.  Scenarios  . . . . . 10
     5.1.  Same Firewall at Initiator for both outgoing and
           incoming packets . . . . . . . . . . . . . . . . . . . . . 10
     5.2. 13
     5.1.  Different Firewalls at Initiator for outgoing and
           incoming packets . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Different Firewalls at Initiator and 13
     5.2.  Data Receiver behind a NAT . . . . . . 12
   6.  Requirements . . . . . . . . . . . . . . 15
   6.  Requirements for HIP Middlebox Solution  . . . . . . . . . . . 15 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16 18
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 19
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 20
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 21
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 21
     10.2. Informative References . . . . . . . . . . . . . . . . . . 19 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 22 24

1.  Introduction

   An

   In the current Internet architecture, an IP address serves the dual role of is used to locate
   and to identify a locator host, termed as "locator" and an identifier "identifier"
   respectively.  Hosts that move and change their IP addresses are said
   to be mobile and those that prefer to be addressed with multiple IPs
   at a given time are said to be multihomed.  Mobility and Multihoming
   are together expressed as Multiaddressing.  When hosts use IP
   addresses for
   every host on the Internet.  Since, the communication, all transport layer connections are bound to the IP address, end systems that use
   it.  Changes to IP addresses as
   identifiers cannot support dynamic changes in the mapping between mean breaking the
   identifier existing transport
   bindings and establishing a new transport connection.  Hence, the locator in case
   existing dual role of multi-homing and mobility. IP addresses are not able to cope with the
   requirements for multiaddressing.

   The Host Identity Protocol (HIP) [I-D.ietf-hip-base] proposes [I-D.ietf-hip-base], a
   multiaddressing proposal, presents a novel approach to separate the identifier
   "identifier" role from the locator "locator" role by adding an additional
   layer between the traditional transport layer and the network layer.
   The transport layer uses a new, mobility-unrelated identifier called
   as Host Identity Tags (HITs), in place of IP addresses, while the
   network layer uses conventional IP addresses for routing.  IPsec
   security associations  As the
   transport connections are bound to the HITs and HITs, they are not modified disturbed
   with the change in IP address changes. address.  In other words, a host despite being
   mobile or
   multi-homed can use a single transport layer connection associated to one
   HIT and multiple IP addresses.

   The Host Identity Protocol offers

   HIP uses a two-way handshake mechanism, termed as base exchange
   messages, to authenticate and to establish a connection with an end
   host.  HIP also offers the functionality to carry IPsec ESP relevant
   payloads together with the base exchange messages in order to
   establish IPsec ESP SAs security associations, which are subsequently
   used to encrypt the data traffic between the two end hosts.
   Consequently, if HIP is liable used to all known
   incompatibilities establish IPsec ESP SAs then it will
   also inherit some of the well-known incompatibilities similar to
   IPsec with middleboxes such ESP-NAT problems, as NATs [RFC3022] described in [RFC3715].  To overcome that,
   HIP allows the middleboxes to participate in the base exchange,
   inspect the relevant traffic identifiers and later the middleboxes
   will use those identifiers to distinguish and to allow a particular
   data traffic.

   This document presents a problem statement in the context of HIP and
   middlebox traversal, and firewalls. discusses the requirements that has to be
   addressed by a HIP-aware NAT/FW traversal technique.

   [Editor's Note: The problem statement for the HIP dealing with legacy
   NATs is described in [I-D.irtf-hiprg-nat]. [I-D.irtf-hiprg-nat].]

   The main goal of the draft document is to
   present a organized as follows: Section 3 presents the problem statement
   statement, Section 4 sketches the overview of the HIP base exchange
   together with the middleboxes, Section 5 discusses possible scenarios
   and Section 6 discusses the requirements in order to aim and properties for a
   NAT/FW traversal solution using the Host Identity Protocol. HIP-
   aware middlebox solution.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This draft used the terminology defined in [NATTerminology],
   [I-D.ietf-hip-base], [I-D.ietf-HIP-esp] [RFC2663], [I-D.ietf-hip-
   base], [I-D.ietf-hip-esp] and
   [draft-moskowitz-hip-arch] [I-D.ietf-hip-arch] and [RFC2401].

   The term SPI refers to the Security Parameter Index value used in
   IPsec packets.  The initiator selects one SPI(I) that can be found in
   the ESP_info parameter, which is then used by the responder to create
   an IPsec packet (ESP packet in this case) for traffic sent to the
   initiator.  The responder selects one SPI(R)(using ESP_info(R)
   parameter) which is used by the initiator to encrypt all data sent to
   the responder.

   Other relevant abbreviations can be found in [I-D.ietf-hip-base] and
   [I-D.ietf-HIP-esp].
   [I-D.ietf-hip-esp].

   The concept of a flow identifier is described in [RFC4080].

   We use the following notation throughout this document:

   o

   [x] indicates that x is optional.

   o

   {x} indicates that x is encrypted.

   o

   <x>y indicates that "x" is encrypted with the key "y".

   o

   --> signifies "Initiator to Responder" communication (requests).

   o

   <-- signifies "Responder to Initiator" communication (replies).

3.  Problem Statement

   This document assumes that the data traffic following the HIP base
   exchange is IPsec protected using the mechanism described in
   [I-D.ietf-HIP-esp] for exchanging the IPsec parameters.  A future
   version of this draft might also be extended to support other
   mechanisms for data traffic protection including no protection at
   all.

   Besides the communicating hosts in the Internet, the entities such as
   NATs and Firewalls play a major role in the event of delivering
   packets to an appropriate host, and each meant for specific
   functionality.  For instance, NATs are used to combat the IPv4
   address depletion problem, and Firewalls are erected to protect
   unsolicited information flowing in and out of a corporate network.

   Typically, NATs use <src IP ,dst IP, src port, dst port, protocol> as
   an flow identifier to identify a particular traffic or connection.
   Because of this, protocols like IPsec suffers from well-known NAT
   related
   problems. problems[RFC3715].  The NAT traversal approach approaches described in
   [RFC3947] and
   [I-D.ietf-ipsec-ikev2] [RFC4306] allows the end hosts to detect one or more
   NATs in between them and [RFC3948] proposes to use the UDP
   encapsulation of IPsec ESP packets to traverse NATs.

   Since

   If HIP uses IPsec protection for the data traffic, traffic then the flow
   identifier takes will take the shape of a <destination IP address, SPI and ESP>
   (in order
   ESP>.  Although HIP is described as a two-party protocol, middle
   boxes are supposed to support smooth traversal of intercept the middleboxes) base exchange messages to learn
   the flow identifier and to process them correctly.  In other words, a
   multi party protocol is created such that the
   middleboxes should learn this flow id in order identifier is
   available to relay middle boxes between the data
   packets. HIP hosts.  To achieve this,
   HIP aims to interact with middleboxes actively whereby these devices
   need to understand the HIP protocol and they need to be involved in
   the protocol exchange.

   This interaction, obviously, requires the middleboxes to verify the
   authenticity of the base exchange messages in order to learn the flow
   identifier and to create a state i.e., NAT binding or a pinhole.  In
   this context, to provide proper security, middleboxes should not be
   vulnerable to denial of service attacks and might want to
   authenticate or authorize entities before creating state information.
   Note that the IPsec SA is unidirectional and therefore two IPsec SAs
   (with two different SPIs, ESP_info contains the SPI value) have to be
   established.

   Finally, End hosts, behind middleboxes especially NATs, require the
   following steps to facilitate its reachability.

   1.  Connection, end host connects to the server, while doing that it
       may also identify the middleboxes.

   2.  Registration, end host registers with the middlebox in order to
       inform the middlebox to relay its traffic.

   3.  Keep-alive, end host maintains the NAT registration by sending
       heart-beat messages.

   4.  Messaging, end host receives the solicited traffic.

   HIP hosts can also make use of such procedures by binding their HITs
   (static identifier) with the middlebox to be connected, anywhere.
   Evidently, this requires the HIP hosts to perform a explicit
   registration mechanism with the middleboxes.

   HIP also provides a way to deal with legacy NATs, as described in
   [draft-nikander-hip-path-00.txt].
   [I-D.nikander-hip-path].  To support this functionality, it is
   necessary to provide UDP encapsulation for both HIP signaling and
   IPsec packets.  Legacy NAT traversal does not require NATs to be HIP
   aware or to understand the HIP message exchange.

   Even though

4.  HIP allows with Middleboxes

   This section describes the middleboxes to participate message exchange between the Initiator and
   the Responder, in which some of them situated behind a middlebox.
   Curently, this document explains the interaction of middlebox with
   plain HIP base
   exchange, but scenarios like routing asymmetry poses a serious
   challenge for exchange and the HIP base exchange carrying ESP
   payloads.  However, this draft can also be extended to traverse support other
   mechanisms for data traffic protection.

4.1.  HIP Base Exchange with middleboxes

   Assume that the initiator starts the HIP base exchange, Figure 1
   shows the HIP base exchange traversing a middlebox.  Section 5 explains  Note that if a
   host wants to be contacted by the other peers, it needs some possible scenarios which have routing asymmetry.  The inability
   of HIP other
   mechanisms to handle routing asymmetry motivates signal its public address to use an explicit
   signaling mechanism for the HIP hosts in order peers and, if
   necessary, should also inform the middlebox to support secure allow the peers.

                  I1         +-----+         I1
       +-------------------->|     |----------------------+
       |                     |     |                      |
       |                     |     |                      |
                   R1        |     |         R1           v
   +---------+ <-------------|     |<---------------- +---------+
   |Initiator|     I2        |     |         I2       |Responder|
   +---------+ ------------->|     |----------------> +---------+
       ^                     |     |                       |
       |                     |     |                       |
       |           R2        |     |         R2            |
       +---------------------|     |<----------------------+
                             +-----+
                             Middlebox

   Figure 1: HIP Base Exchange and
   smooth traversal of middleboxes

   Subsequently, the middleboxes.

   Although HIP base exchange is described as a two-party protocol, middle boxes are
   supposed to intercept these messages depicted in order to learn more detail.

    I -> R: I1: Trigger exchange

    I <- R: R1: (Puzzle, {D-H(R), HI(R), HIP Transform})SIG

    I -> R: I2: {Solution, LSI(I),D-H(I),
                 HIP Transform, {H(I)}SK }SIG

    I <- R: R2: {LSI(R), HMAC}SIG

   Here, the flow
   identifier and base exchange becomes vulnerable to process them correctly.  In other words, a multi
   party protocol is created such that DoS attack (for the flow identifier
   middleboxes) because the initiator's HI is available
   to middle boxes between encrypted in the HIP hosts.  To provide proper security,
   middleboxes should not be subject to denial of service attacks I2 packet
   and
   might want the middleboxes are unable to authenticate or authorize entities which create state.
   Note that verify the IPsec SA I2 message.  As a
   consequence, an attacker may send spoofed I2 messages before the
   authentic initiator does that.

   When HIP is unidirectional used with HIP-aware NAT devices, the checksum, computed
   over the source and therefore two IPsec SAs
   (with two different SPIs, ESP_info contains destination address, in the SPI value) have to IP header must be
   established.

4.  Overview of
   recomputed.  Additionally, it might be necessary to include support
   for storing the respective HITs and host identities.

4.2.  HIP Base Exchange with ESP Parameters and Middleboxes

   This section explains the HIP base exchange exchange, carrying ESP parameters,
   together with the middleboxes and describes how the middleboxes
   behave during the base exchange.

4.1.  HIP Base Exchange with NAT  Figure 1 3 shows the HIP base corresponding
   message exchange traversing a NAT. middlebox.

                   I1        +-----------+         I1
       +-------------------->|           |----------------------+
       |                     |           |                      |
       |                     |           |                      |
                   R1        | Intercept |         R1           v
   +---------+ <-------------| the flow  |<----------------  +---------+
   |Initiator|     I2        | identifer |         I2        |Responder|
   +---------+ ------------->| <Dest IP, |---------------->  +---------+
       ^                     |  SPI,ESP> |
       |                     |           |                       |
       |           R2        |           |         R2            |
       +---------------------|           |<----------------------+
                             +-----------+
                                  NAT
                              middlebox

   Figure 1: NAT and 3: ESP Transport Format with HIP Base Exchange and Middleboxes

   Subsequently, the HIP base with ESP exchange is described in more detail.

    I -> R: I1: Trigger exchange

    I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform,
                 HIP Transform }SIG

    I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I),
                 ESP_Transform, HIP Transform, {H(I)}SK }SIG

    I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG

   A potential responsibility of the NAT, middlebox, as shown in Figure 1, 3,
   can be the following

   o  Intercept the signaling messages

   o  Authenticate and authorize the HIP nodes by verifying the
      signatures.

   o  Process the flow identifier information

   o  Perform actions according to the state machine

   o  Create state based on the content of message I2 with ESP_info(I)
      and R2 with ESP_info(R).  Additionally, it might be necessary to
      include support for storing the respective HITs and host
      identities.

4.2.  HIP Base Exchange with Firewall

   In case of a firewall traversal,

   The middleboxes should participate in the routing asymmetry needs signaling messages and has
   to be
   considered i.e., learn the fact that flow identifier to pass the messages I1 and subsequent data traffic.

   Here, together with the spoofed I2 do not
   necessarily traverse message, an attacker may send a
   bogus SPI value, which will result in an inconsistent state at
   NAT/FW.

4.3.  HIP Mobility/Multihoming Exchange with Middleboxes

   This section explains the same devices as R1 HIP mobility and R2.  The same is true
   with more complex network topologies multihoming extensions for
   the HIP hosts [I-D.ietf-hip-mm] together with a mixture of NATs the middleboxes.
   Assume that the initiator moves after the base exchange and
   Firewalls.  This is an assumption made in wants to
   inform the NSIS working group (and
   therefore also with NAT/Firewall traversal).  Pure NAT traversal is
   therefore simpler responder.  During this procedure, the Initiator wants to handle
   start the rekeying proceudre in comparison order to middlebox traversal
   which also includes devices such as Firewalls. establish new keys.
   Figure 3 5 shows the mobility message exchange, traversing a middlebox.
   Note that this
   circumstance graphically:

                   I1         +----------+         I1
       +--------------------> draft explains only one possible exchange for
   mobility, [I-D.ietf-hip-mm] provides a detailed message exchange for
   other variants such as rekeying initiated by responder.

                 +-----+           UPDATE SEQ
    +----------> | Firewall     |--------------------------------------+
    | -----------------------+            |           I2     |    1         UPDATE ACK                   |
    |    +------ |     |---------------------------------+    |         I2
    |    |  +----------------->       |     | ------------------+                                 |    |
    |                   +----------+    v       |     |                                 |    v
   +---------+   |     |                                +---------+
   |Initiator|   |     |                                |Responder|
   +---------+                                            +---------+
       ^  ^        R1         +----------+         R1   |     |                                +---------+
        |  +------------------        | Firewall     | <-------------------+                                  ^
        |        |           R2     |    2            ACK                   |         R2
        +------  |
       +---------------------     |----------------------------------+
                 |     | <-----------------------+
                              +----------+

       ............... IPsec ESP protected traffic (SPI(R)).........>
       <.............. IPsec ESP protected traffic (SPI(I))..........

       Legend:
       --- = HIP signaling
       ... = IPsec protected data traffic
                 +-----+
                  middlebox

   Figure 3: Firewall and 5: HIP Base Mobility Exchange

   With one single NAT between with Middleboxee

   Subsequently, the HIP nodes, all messages of the base mobility exchange are forced through it.  With firewalls, it becomes obvious
   that the nice property of is depicted below.

   I -> R:UPDATE SEQ (ESP_INFO(I), LOCATOR, [DIFFIE_HELLMAN], SEQ)

   I <- R:UPDATE ACK (ESP_INFO(R), SEQ, ACK,
          [DIFFIE_HELLMAN], ECHO_REQUEST)

   I -> R:ACK (ACK, ECHO_RESPONSE)

   In such cases, a NAT with respect to middlebox should,

   o  Intercept the symmetric
   forwarding path is lost HIP mobility messages

   o  Authenticate and authorize the individual firewalls (Firewall 1 HIP nodes by verifying the
      signatures

   o  Process the flow identifier information and
   Firewall 2) are unable perform actions
      according to create the necessary firewall pinholes.
   SPI(I) is exchanged state machine

   o  Update the location of the initiator based on the "LOCATOR
      parameter" in I2 message (ESP_info(I)) through firewall 1,
   however firewall 2 only needs it.  Similarly firewall 2 needs SPI (R)
   which is sent the UPDATE messages, also in message R2 (ESP_info(I)) through firewall 1.

5.  Scenarios

   The following section describes some sample scenarios, case of rekeying, the
      middlebox should update the state based on the information in the context
   of involving middleboxes, to learn
      ESP_info parameter, together with the flow identifier:

5.1.  Same Firewall at Initiator for both outgoing respective HITs and incoming packets

   This scenario assumes that host
      identities

   The problem with the initiator I alone mobilty exchange, when the host is behind a firewall
   named FW(I).  This firewall NAT,
   is both for that the outgoing address in the LOCATOR parameter is a private address and incoming
   packets
   not globally routable.

   [Editor's Note: Some possible solutions, to overcome this problem,
   are to use RVS server as a contact point, initiator should find the
   public address and somehow has to inform it to the responder and the
   NAT has to bind the new private address and hence the public address.]

   In case of multihoming scenario, in which the hosts can look into all be reached by
   several addresses, the base exchange messages.  This
   scenario NAT handling becomes complicated.  For
   example, if a host is also applicable for NATs as well.  This multihomed, assume that the initial HIP and
   security associations are established with a public IP address of the
   host.  Later, if it decides to use the address which is illustrated in
   Figure 4

                  FW(I)
           I1    +-----+            I1
    +----------> |     |--------------------------------------+
    |      I2    |     |            I2                        |
    |    +-----> |     |---------------------------------+    |
    |    |       |     |                                 |    |
    |    |       |     |                                 v    v
   ---------+    |     |                                +--------+
   Initiator|    |     |                                |Receiver|
   ---------+    |     |                                +--------+ behind a NAT,
   then the "new" NAT has to create a binding between the hosts.

   +---------+        1. Base Exchange               +---------+
   |Initiator|<------------------------------------->|Responder|
   +---------+                                       +---------+
        ^                                                   ^
        |                     +------+                      |
        |    2. Update        |  R2    |     |            R2                    |    |
    |   +------  |     |< --------------------------------+    |
    |      R1    |     |            R1 NAT  |
    +----------     2. Update        |     |< -------------------------------------+
                 +-----+
        +-------------------->|      |----------------------+
                              +------+
                          Intercept the flow id

   Figure 4: One FW only at initiator end

   1.  I1 packet is sent from 7: Multihoming and Middleboxes

   Figure 7 depicts the initiator I to receiver R.

   2.  FW(I) forward one possible scenario in which the packet to initiator is
   multihomed.

   1.  If the Receiver.

   3.  R sends R1 message with puzzle,D-H key protected with Initiator notices the
       signature of R.

   4.  FW(I) forward change, it can update the packet to new
       address by using "Locator" parameter in the Initiator.

   5.  On receiving I2, FW(I) verifies UPDATE messages (or
       can inform the signature of I and learns NAT).  By this way, a NAT can create a new binding
       by intercepting the
       SPI value form UPDATE messages.

   2.  If the ESP_info parameter and forwards it Responder itself decides to send the
       Receiver

   6.  R sends the message R2 traffic to I.

   7.  On receiving R2, FW(I) verifies the signature of R. Accordingly,
       it earns
       previously exchanged address (informed as alternative address),
       then the SPI value form NAT will disrupt the ESP_info parameter and forwards connection, since it does not have
       necessary state information to handle the Initiator.

   8. traffic.  A more
       detailed analysis, about multihoming, will be done in the future
       version of this draft.

5.  Scenarios

   The base exchange continues until complete.  Since all messages
       I1,R1,I2 and R2 traverse through FW(I), it can look into these
       messages following section describes some sample scenarios, in the context
   of involving middleboxes, to learn the flow identifier information.

5.2. identifier:

5.1.  Different Firewalls at Initiator for outgoing and incoming packets

   This scenario assumes that both the initiator I and the receiver R responderR is
   situated behind firewalls named FW(I) and FW(R) respectively.  FW(I)
   is for the incoming packets to I and FW(R) is for the incoming
   packets to R. It is necessary that both the firewalls must learn the
   flow identifier information and should store the state <SPI,IP,HIT>
   to forward IPsec protected payload packets.  This scenario is
   illustrated in Figure 5

                                FW(R) 8

                   I1                 +-----+         +----------+         I1
     +------------------------>|     |--------+
       +--------------------> |      I2 Firewall | -----------------------+
       |           I2         |  FW(R)   |    +------------------->|     |---+         I2             |
       |  +-----------------> |                    +-----+          | ------------------+ |
       |  |                   +----------+                     v  v
   +---------+                        +--------+                                            +---------+
   |Initiator|                        |Receiver|                                            |Responder|
   +---------+                                            +---------+     FW(I)              +--------+
       ^  ^        +-----+               |    |        R1         +----------+         R1          |   |  R2
       |  +------------------ |      R2 Firewall | <-------------------+   |
       |   +--------|     |<--------------+           R2         |  FW(I)   |      R1         R2              |
       +--------------------- |     R1          |
     +------------|     |<-------------------+
                  +-----+ <-----------------------+
                              +----------+

       ............... IPsec ESP protected traffic (SPI(R)).........>
       <.............. IPsec ESP protected traffic (SPI(I))..........

       Legend:
       --- = HIP signaling
       ... = IPsec protected data traffic

   Figure 5: 8: End hosts behind FWs

   1.  I1 packet is sent from the initiator I to receiver responder R.

   2.  FW(R) forwards the packet to the Receiver. Responder.

   3.  Then, R sends R1 message with puzzle,D-H key protected with the
       signature of R.

   4.  FW(I) forward the packet to the Initiator.

   5.  Now, I sends the I2 packet, on receiving I2, FW(R) verifies the
       signature of I and learns the SPI value form the ESP_info
       parameter and forwards it to the Receiver Responder

   6.  To complete the base exchange, R sends the message R2 to I.

   7.  On receiving R2, FW(I) verifies the signature of R. Accordingly,
       it earns the SPI value from the ESP_info parameter and forwards
       it to the Initiator.

   Here, the problem with this asymmetric base exchange is that the SPI
   needed for the FW(I) is sent through the I2 message, which flows
   through the FW(R) and the SPI needed for for the FW(I) is sent to
   FW(R).

5.3.  Different Firewalls at Initiator and Receiver

   This scenario looks into

   The topology shown in Figure 8 shows a more complicated situation.  Initiator I
   is behind multiple firewalls FW1(I) for outgoing packets scenario where messages R1/R2
   are traversed by middlebox FW(I) and FW2(I) messages I1/I2 traverse
   middlebox FW(R).  These scenarios might be found in larger networks
   with routing asymmetry and FW3(I) are for incoming packets.  Similarly, receiver R multi-homed networks.  Today, in many
   cases a state synchronization protocol is behind
   FW1(R) and FW2(R) for incoming packets used between these two
   middleboxes to make them apear as a single device and FW3(R) therefore
   avoiding problems.

   A solution for outgoing
   packets.  The incoming firewalls dealing with NAT traversal is simpler compared to
   firewall traversal.  With one single NAT between the HIP nodes, all
   messages of the base exchange are chosen based on forced to pass through it.  With
   firewalls, it becomes obvious that the type nice property of a NAT with
   respect to the
   application symmetric forwarding path is lost and here the hosts
   individual firewalls are unaware from which unable to create the necessary firewall they
   receive packets.  Here,
   pinholes.  SPI(I) is exchanged in I2 message (ESP_info(I)) through
   firewall 1, however for our scenario we assume that
   FW2(R) firewall 2 only needs it.  Similarly firewall 2
   needs SPI (R) which is sent in message R2 (ESP_info(I)) through
   firewall 1.

   Hence, problems related with routing asymmetry and FW2(I) firewall traversal
   are chosen about :

   1.  When hosts are behind multiple incoming firewalls, they are
       unable to decide to which also firewall they have to signal the
       appropriate SPI values.

   2.  The second problem is to secure the SPI signalling message from
       the end host to the FW.  Since the end hosts are unaware
   of. authenticate and
       authorize to the FW that lets outgoing packets, they share keys
       only with them.  However, as mentioned earlier, they, somehow,
       need to signal the SPI value to the FW on the other end which
       forwards incoming packets.

5.2.  Data Receiver behind a NAT

   This scenario explains the full operation during the HIP base
   exchange between the Initiator and the Responder, where the Responder
   is illustrated in Figure 6
                                                +-----+ assumed to be situated behind a NAT and registered with the
   rendevous server (RVS) to facilitate its reachability.

                           -------
                        ///       \\\
      1. DNS Look Up   |             |
                                                |FW1-R|
      +-------------->     DNS
      |                |
                   +-----+                      +-----+
             I1             |
      |           I1         +-----+
      +------------|     +-----------\\\       ///
      | ------------------->     |     |---------+              -------       1'. Registration
      |      I2    |FW1-I|           I2         |FW2-R|     |                         +------------------------+
      |    +-------|     | ------------------->                         |     |----+                        |
      |     |                         |                        |                      +-----+
      |     |2. IP_RVS,HIT_R          |                        |
      |     |       +-----+                                 v                         v
    +---------+                                           +--------+
    |Initiator|                                           |Receiver|
    +---------+                                           +--------+
      ^   ^                        |
      |     |                     +-----+  +-----+             |
      |  R2     |                     |RVS  |  |     |             |
      |     v              +----->|     +->|     |             |
     ++--------+     3. I1 |            R2      +-----+  |     |   3.'I1   +---------+
     |   +------  |FW2-I| <--------------------|     |-----+         +-----------+               |     +---------->|         |      R1
     |Initiator|                           |     |            R1        |FW3-R|           |Responder|
     |
      +----------         |            4. Base Exchg  | <--------------------|     |----------+
                   +-----+ NAT |           |
                   +-----+         |
     +---------+ <-------------------------+-----+---------> +--+------+
                                           |     |                 |                      +-----+
                   |FW3-I|
                                           |     |1''.Registration |
                                           |     |<----------------+
                                           +-----+

   Figure 6: Multiple FWs at initiator's 9: HIP Responder with RVS and receiver's end

   1.  I1 packet is sent from NAT

   Figure 9 shows the initiator I to receiver R.

   2.  FW1(I) and FW2(R) forwards pictorial representaton of the packet operation.

   o  Initiator looks up the DNS in order to find the Receiver.

   3.  Then, R sends R1 message with puzzle,D-H key protected with connection
      parameters for the
       signature of R.

   4.  Now, FW3(R) and FW2(I) forward responder, This is typically done by querying
      the packet to DNS with the Initiator.

   5.  Now, corresponding FQDN.

   o  Since the I sends responder is registerd with the I2 packet, on receiving I2, FW1(I) and
       FW2(R) can verify RVS, the signature DNS record will
      contain the IP of I the RVS and can learn the SPI value
       from HIT of the ESP_info parameter and forward it to responder.

   o  The Initiator, now, contacts the Receiver.

   6.  To complete RVS by sending I1 message, the base exchange, R sends
      RVS relays the message R2 to I.

   7.  On receiving R2, FW3(R) and FW2(I) can verify the signature of R.
       Accordingly, they learn the SPI value form responder.  If the ESP_info parameter
       and forwards responder is
      situated behind a NAT, it to must inform the Initiator.

   Here, NAT, beforehand, to
      allow the problems are :

   1.  With this asymmetric HIP base exchange is that the SPI needed for packets to be traversed via the
       Firewall(s) on NAT.

      This typically requires a registration mechanism to siganl the receiver side is sent through
      NAT.

   o  The NAT forwards the I2 message,
       Which is actually sent through FW1(I) and FW2(R) HIP packets and actively participates in the SPI
       needed for for the Firewall(s) on the Initiator side is sent to
       FW3(R) and FW2(I).

   2.  When hosts are behind multiple incoming firewalls, there are
       unable to decide to which firewall they have to inform their SPI
       values to.

   3.  The second problem
      base exchange.  If ESP traffic information is to secure the SPI signalling message from exchanged, the end host to
      middlebox will also learn the FW.  Since flow identifier.

   Here, the end hosts authenticate NAT might require authentication and
       authorize to the FW that lets outgoing packets, they share keys
       only with them.  However, as mentioned earlier, they, somehow,
       need to signal authorization from the SPI value
   endhosts in order to enable a NAT binding for the FW on requesting hosts.
   This can be done achieved by performing middlebox signaling, the other end which
       forwards incoming packets.
   requirements for such solution is explained in Section 6.

6.  Requirements

   In the context of middlebox signaling, for HIP Middlebox Solution

   This section presents a few high-level requirements
   have that are derived
   from the given problem statement.  A novel middlebox signaling
   approach has to be accomplished: accomplish the following goals:

   o  Add some authentication and authorization capabilities to NAT the NAT/
      Firewall traversal.  Many NAT/Firewall traversal solutions do not
      allow the end host to interact with the middlebox.  As a
      consequence, some security vulnerabilities are introduced. introduced
      e.g.,denial of service.

   o  Add secure firewall traversal functionality as another type of
      middlebox signaling by using <destination IP address, SPI and
      protocol> triplet. as a substitute for the typical traditional < source
      IP, destination IP, source port, destination port, transport
      protocol> information.

   Such

   It is recommended that a solution for HIP-based HIP-aware middlebox signaling
   needs to have the following properties:

   o  A HIP-aware NAT/FW MUST be able to authenticate the entity
      requesting a NAT binding or a firewall pinhole.

   o  A HIP-aware NAT/FW MUST be able to intercept HIP messages in order
      to extract the flow identifier information and other related
      information.  A HIP-aware NAT/FW MUST be able to distinguish these
      messages.

   o  A HIP-aware NAT/FW MUST authorize the entity requesting a NAT
      binding or a firewall pinhole before storing state information.
      This requirement might be accomplished by identity based
      authorization or an identity independent authorization mechanism.

   o  A HIP-aware NAT/FW MUST be able to intercept HIP messages in order
      to extract the flow identifier information and other related
      information.  HIP messages are base exchange messages during
      context establishment and readdressing messages during IP address
      changes.  A NAT/FW MUST be able to distinguish these messages.

   o  A NAT/FW node MUST NOT introduce new denial of service attacks
      based on authentication or key management mechanisms. attacks.

   o  A potential solution MUST respect the property of some middleboxes
      which do not allow traffic (data and signaling traffic) to
      traverse this the middlebox without proper authorization.

   Some requirements are taken from [I-D.ietf-nsis-nslp-natfw].

7.  Security Considerations

   This document analyzes the traversal of HIP-aware middleboxes.  A

   In this document, a problem statement is given and scenarios are
   described that lead to a number of requirements.

   This document therefore lists requirements, which focusses on
   security at a number higher level of abstraction.  However, this document
   does not perform a detailed security aspects throughout
   the document.  Care analysis for a HIP-aware
   middlebox solution.

   The authors recommend that, atmost care should be taken when
   solutions are developed and the security solution must not introduce new
   security vulnerabilities to the middlebox.

8.  Contributors

   We would like to thank Aarthi Nagarajan, Vesa Torvinen, Jochen
   Grimminger and Jukka Ylitalo for their help with initial versions of
   this document.

9.  Acknowledgements

   The authors would like to thank Pekka Nikander, Dieter Gollmann and
   Thomas
   Tuomas Aura for their feedback to this document.

   This document is a byproduct of the Ambient Networks Project,
   partially funded by the European Commission under its Sixth Framework
   Programme.  It is provided "as is" and without any express or implied
   warranties, including, without limitation, the implied warranties of
   fitness for a particular purpose.  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   Project or the European Commission.

10.  References

10.1.  Normative References

   [I-D.ietf-HIP-esp]

   [I-D.ietf-hip-base]
              Moskowitz, R., Nikander, P., and P. "Host Identity Protocol",
              draft-ietf-hip-base-05 (work in progress), March 2006.

   [I-D.ietf-hip-esp]
              Jokela, P., "Using ESP transport format with HIP", draft-ietf-hip-esp-00
              draft-ietf-hip-esp-02 (work in progress), June 2005.

   [I-D.ietf-hip-base]
              Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", draft-ietf-hip-base-03 (work in
              progress), June 2005. March 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

10.2.  Informative References

   [I-D.ietf-ipsec-ikev2]
              Kaufman, C., "Internet Key Exchange (IKEv2)

   [I-D.ietf-hip-arch]
              Moskowitz, R. and P. Nikander, "Host Identity Protocol
              Architecture", draft-ietf-hip-arch-03 (work in progress),
              August 2005.

   [I-D.ietf-hip-mm]
              Nikander, P., "End-Host Mobility and Multihoming with the
              Host Identity Protocol",
              draft-ietf-ipsec-ikev2-17 draft-ietf-hip-mm-03 (work in
              progress),
              September 2004. March 2006.

   [I-D.ietf-nsis-nslp-natfw]
              Stiemerling, M., Tschofenig, H., and C. Aoun, "A NAT/
              Firewall "NAT/Firewall NSIS Signaling Layer
              Protocol (NSLP)",
              draft-ietf-nsis-nslp-natfw-07 draft-ietf-nsis-nslp-natfw-09 (work in
              progress),
              July 2005. February 2006.

   [I-D.irtf-hiprg-nat]
              Stiemerling, M., Quittek, J., and L. Eggert, "Middlebox Traversal Issues of Host
              Identity Protocol (HIP) Communication", draft-irtf-hiprg-nat-00.txt
              draft-irtf-hiprg-nat-01 (work in
              progress) progress), January 2006.

   [I-D.nikander-hip-path]
              Nikander, P., "Preferred Alternatives for Tunnelling HIP
              (PATH)", draft-nikander-hip-path-00 (work in progress), October
              February 2005.

   [NATTerminology]

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", Request
              For Comments
              RFC 2663, August 1999.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.

   [RFC3947]  Kivinen, T., A. Huttunen, A., Swander, B., and V. Volpe,
              "Negotiation of NAT-Traversal in the IKE", RFC 3947,
              January 2005.

   [RFC3948]  A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
              M. Stenberg, "UDP Encapsulation of IPsec Packets",
              RFC 3948, January 2005.

   [RFC4080]  Hancock, R., "Next Steps in Signaling: Framework",
              RFC 4080, November 2004.

   [draft-ietf-hip-mm]
              Henderson (Editor), T., "End-Host Mobility and Multi-
              Homing with Host Identity Protocol",
              draft-nikander-hip-mm-02.txt (work in progress) (work in
              progress), July 2005.

   [draft-ietf-ipsec-esp-v3-08]

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              draft-ietf-ipsec-esp-v3-10 (work in progress) (work in
              progress), March 2005.

   [draft-moskowitz-hip-arch]
              Moskowitz, R. and P. Nikander, "Host Identity Protocol
              Architecture", draft-ietf-hip-arch-03 (work in progress)
              (work in progress), August 2005.

   [draft-nikander-hip-path-00.txt]
              Nikander, P., Tschofenig, H., Henderson, T., Eggert, L.,
              and J. Laganier, "Preferred Alternatives for Tunnelling
              HIP (PATH)", draft-nikander-hip-path-00.txt (work in
              progress) (work in progress), February
              RFC RFC4303, December 2005.

   [rfc3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", Request For
              Comments

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 3022, January 2001. 3948, September 2004.

Authors' Addresses

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com

   Murugaraj Shanmugam
   Technical Univeristy Hamburg-Harburg
   Schwarzenbergstrasse 95
   Harburg, Hamburg  21073
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   Email: murugaraj.shanmugam@tuhh.de murugaraj.shanmugam@siemens.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this 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 standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of 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
   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 (2005). (2006).  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.