Internet DRAFT - draft-xia-mip6-fw-policy

draft-xia-mip6-fw-policy






Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Expires: November 2, 2007                                     Huawei USA
                                                                May 2007


            Policy-based Firewall Traversal for Mobile IPv6
                      draft-xia-mip6-fw-policy-00

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 November 2, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Xia & Sarikaya          Expires November 2, 2007                [Page 1]

Internet-Draft       Policy-based Firewall Traversal            May 2007


Abstract

   Most of firewalls deployed today are Mobile IPv6 unaware.  Widespread
   Mobile IPv6 deployment is not possible unless Mobile IPv6 messages
   can pass through these firewalls.  In this memo, policy servers are
   used to communicate with firewalls and instruct them to bypass Mobile
   IPv6 messages.  To achieve the goal, Network Access Identifier (NAI)
   and authentication information are included in Mobile IPv6 control
   signalling or data packets.  Firewalls extract these information and
   send them to a policy server, and the policy server then installs
   corresponding states in firewalls based on authentication result and
   user's predefined policy.  The new defined IPv6 extension header and
   the policy-based frame can also facilitate dynamic configuration in
   any application firewall traversal.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Policy Control Framework . . . . . . . . . . . . . . . . . . .  3
   4.  Middlebox Communication architecture . . . . . . . . . . . . .  4
   5.  Mobile node behind a firewall  . . . . . . . . . . . . . . . .  4
     5.1.  Binding Updates and Binding Acknowledgement  . . . . . . .  5
     5.2.  Route optimization . . . . . . . . . . . . . . . . . . . .  6
     5.3.  Change of Firewalls  . . . . . . . . . . . . . . . . . . .  6
   6.  Correspondent Node behind a firewall . . . . . . . . . . . . .  6
     6.1.  Route Optimization . . . . . . . . . . . . . . . . . . . .  7
   7.  Home Agent behind a firewall . . . . . . . . . . . . . . . . .  7
   8.  New IPv6 Extension Header  . . . . . . . . . . . . . . . . . .  8
     8.1.  Middlebox Hop Header Description . . . . . . . . . . . . .  8
     8.2.  Extension Header Order . . . . . . . . . . . . . . . . . .  9
     8.3.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Consideration of Mobile IPv6 Authentication Protocol . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     13.2. Informative references . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14









Xia & Sarikaya          Expires November 2, 2007                [Page 2]

Internet-Draft       Policy-based Firewall Traversal            May 2007


1.  Introduction

   In [RFC3775], route optimization, bi-directional tunneling, and ESP
   encapsulated binding update are integral parts of Mobile IPv6
   specification.  Most corporate firewalls (among others) are typically
   configured to disallow IP in IP tunneling and ESP, by default.  Such
   configuration would prevent MIPv6 control messages and normal data to
   pass through those firewalls.

   [I-D.thiruvengadam-nsis-mip6-fw] applies NSIS signaling for these
   problems, and the main disadvantage of the proposal is that
   complicated signaling should be implemented within mobile nodes and
   correspondent nodes.

   A framework for policy-based admission control is described in
   [RFC2753].  The framework can also be used for Mobile IPv6 firewall
   traversal.  A firewall intercepts Mobile IPv6 message and requests a
   server for policies.  The server then instructs firewalls to build
   related states for future traffic.

   Generally, Mobile IPv6 has mechanisms that control signalling is
   separated from data traffic.  Piggybacking control messages ( such as
   Binding Update,Binding Acknowledgement), authentication information
   can be used to build states in firewalls.  A New IPv6 Extension
   Header called Middlebox Hop is defined to hold these authentication
   information.


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

   Policy:  The combination of rules and services where rules define the
      criteria for resource access and usage
   PDP:  The point where policy decisions are made
   PEP:  The point where the policy decisions are actually enforced


3.  Policy Control Framework

   The framework is described in [RFC2753].  The two main architectural
   elements of the framework for policy control are the PEP and the PDP.
   Figure 1 shows a simple configuration involving these two elements;
   PEP is a component at a network node and PDP is a remote entity that
   may reside at a policy server.  The PEP represents the component that
   always runs on the policy aware node.  It is the point at which



Xia & Sarikaya          Expires November 2, 2007                [Page 3]

Internet-Draft       Policy-based Firewall Traversal            May 2007


   policy decisions are actually enforced.  Policy decisions are made
   primarily at the PDP.  The PDP itself may make use of additional
   mechanisms and protocols to achieve additional functionality such as
   user authentication, accounting, policy information storage, etc.

   The basic interaction between the components begins with the PEP.
   The PEP receives a notification or a message that requires a policy
   decision.  Given such an event, the PEP then formulates a request and
   sends it to the PDP.  The PDP returns the policy decision and the PEP
   then enforces the policy decision by appropriately accepting or
   denying the request.


        ________________         _________________
       |                |        |                | LDAP,SNMP,AAA,..
       |  Network Node  |        |  Policy server | for accessing
       |    _____       |        |    _____       | policy database,
       |   |     |      |        |   |     |      | authentication,etc.
       |   | PEP |<-----|--------|-->| PDP |------|---------------->
       |   |_____|      |        |   |_____|      |
       |                |        |                |
       |________________|        |________________|



                     Figure 1: architectural elements


4.  Middlebox Communication architecture

   [RFC3303] describes a framework of middlebox communications (MIDCOM)
   to enable complex applications through the middleboxes, seamlessly
   using a trusted third party.  Middleboxes implementing Firewall
   service typically embed application intelligence within the device.
   In [RFC3303], firewalls offload application intelligence to trusted
   third parties, as allows firewalls to continue to provide the
   services, while keeping the firewalls application agnostic.  In this
   proposal,we combine Policy Control Framework and Middlebox
   Communication architecture.  Firewalls offload MIPv6 intelligence to
   Policy server, and Policy server download rules for firewalls'
   operation.


5.  Mobile node behind a firewall

   In Figure 2, An MN is protected by a firewall that employs stateful
   packet filtering.  An external CN and an HA are also shown in the
   figure.  The MN is located in a visited network and is expecting to



Xia & Sarikaya          Expires November 2, 2007                [Page 4]

Internet-Draft       Policy-based Firewall Traversal            May 2007


   communicate with the CN.


               +----------------+                +----+
               |                |                | HA |
               |                |                +----+
               |                |              Home Agent
               |  +----+      +----+
               |  | MN |      | FW |
               |  +----+      +----+
               |                |                +----+
               |                |                | CN |
               |                |                +----+
               +----------------+              External CN
               Network protected
                 by a firewall


                      Figure 2: MN behind a firewall

5.1.  Binding Updates and Binding Acknowledgement

   In [RFC3775], IPsec is used to protect Binding Updates (BU) and
   Binding Acknowledgement(BAck).Most corporate firewalls (among others)
   are typically configured to disallow IP in IP tunneling and ESP, by
   default.  Such configuration would prevent MIPv6 control messages and
   normal data to pass through those firewalls.  As a solution, a policy
   server can be used to dynamically configure the firewall(s) based on
   authentication .  Network Access Identifier (NAI) [RFC4282] and
   Mobility Message Authentication Option defined in [RFC4285] should be
   included in BU/BAck.  A new IPv6 extension header called Middlebox
   Hop is designed in Section 8 to hold these information.  The process
   is as following:
   o  The firewall(PEP) extracts NAI and authentication information from
      Middlebox Hop Header in BU/BAck, and sends them to a policy server
      (PDP) through COPS-PR [RFC3084], RADIUS/Diameter, or other
      protocols.  To facilitate policy server to configure firewalls
      dynamically and intellectually, support information can be sent to
      policy servers.  One simple practice is sending TCP/IP, UDP/IP
      header to policy servers, or foward the complete packet to the
      server through a tunnel between the Policy server and the
      firewall.
   o  The policy server makes use of additional mechanisms and
      protocols, such as LDAP, SNMP and so on, to retrieve the user's
      profile from policy depository or user database.  Details of these
      mechanisms are out of the scope.





Xia & Sarikaya          Expires November 2, 2007                [Page 5]

Internet-Draft       Policy-based Firewall Traversal            May 2007


   o  If the user passes the authentication, the policy server build
      policy and rules for the user and sends these information to the
      firewall for creating states.

   The states installed by the policy server allow the following
   traffic:
   o  HOTI and HOT for route optimization.
   o  Bi-directional tunneling traffic.

5.2.  Route optimization

   Route optimization includes two parts, Return Routability Test (RRT)
   and Binding Updates (BU).  MN initiates RRT procedure with HoTI
   message.  HOTI and HOT can traverse the firewall because there are
   related states installed as described in Section 5.1.  In general
   speaking, firewalls don't filter outgoing traffic, and make use of
   outgoing traffic to build related states for incoming traffic.  The
   CoTI/ CoT message and the BU/BAck message can traverse the MN's ASP-
   firewall, as the CoTI/BU message are not IPsec encapsulated and the
   CoT/BAck messages correspond to the state previously installed by the
   CoTI message.

5.3.  Change of Firewalls

   If the MN roams and attaches to a different firewall, the above-
   mentioned routing methods will have problems in traversing the new
   firewall.  The same procedure can just repeat.  There are also access
   routers with built-in firewalls.  In this case, context transfer can
   be used to synchronize states between firewalls together with
   handover.


6.  Correspondent Node behind a firewall

   In Figure 3, the CN is protected by a firewall that employs stateful
   packet filtering.  An external MN and its associated HA are also
   shown in the figure.  The MN communicates with the CN.  If the CN
   initiated normal data traffic there is no problem with the SPF, as
   the communication is initiated from internal.  If MN reaches CN
   through bi-directional tunnel between MN and HA, a Middlebox Hop
   defined in Section 8 is included in first data packet to create a
   pinhole in the firewall.









Xia & Sarikaya          Expires November 2, 2007                [Page 6]

Internet-Draft       Policy-based Firewall Traversal            May 2007


           +----------------+                +----+
           |                |                | HA |
           |                |                +----+
           |                |              Home Agent
           |  +----+      +----+
           |  | CN |      | FW |
           |  +----+      +----+
           |                |                +----+
           |                |                | MN |
           |                |                +----+
           +----------------+           External Mobile
           Network protected                  Node
             by a firewall


                     Figure 3: CN behind the firewall

6.1.  Route Optimization

   The MN moves out of its home network and has to perform the return
   routability test before sending the binding update to the CN.  It
   sends a HoTI message through the HA to the CN and expects a HoT
   message from the CN along the same path.  It also sends a CoTI
   message directly to the CN and expects CoT message in the same path
   from the CN.  To allow HoTI and CoTI, A Middlebox Hop Header with NAI
   and authentication information is included in these messages, and
   there are related states installed after process as described above
   sections.


7.  Home Agent behind a firewall

   In Figure 4, A Home Agent is protected by a firewall.  An MN and a CN
   are also shown in the figure.  The MN, after entering a new network,
   sends a Binding Update to the HA.  To allow BU, A Middlebox Hop
   Header with NAI and authentication information is included in the
   message.  A policy server installs states to the firewall after
   successful authentication of the user.













Xia & Sarikaya          Expires November 2, 2007                [Page 7]

Internet-Draft       Policy-based Firewall Traversal            May 2007


           +----------------+                +----+
           |                |                | MN |
           |                |                +----+
           |                |             Mobile Node
           |  +----+      +----+
           |  | HA |      | FW |
           |  +----+      +----+
           |                |                +----+
           |                |                | CN |
           |                |                +----+
           +----------------+              External CN
           Network protected
             by a firewall


                  Figure 4: Home Agent behind a firewall


8.  New IPv6 Extension Header

8.1.  Middlebox Hop Header Description

   Some IPv6 Extension Headers are defined in [RFC2460].  A new IPv6
   Extension Header called Middlebox Hop is defined here.



























Xia & Sarikaya          Expires November 2, 2007                [Page 8]

Internet-Draft       Policy-based Firewall Traversal            May 2007


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |  MIDBOX Type  |  Reserved     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       Options                                 .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header          8-bit selector.  Identifies the type of header
                        immediately following the Middlebox Hop Options
                        header.

   Hdr Ext Len          8-bit unsigned integer.  Length of the Middlebox
                        Options header in 8-octet units, not including
                        the first 8 octets.

   MIDBOX Type          8-bit unsigned integer. Types of Middleboxes
                        are defined in [RFC3234]. In this document,
                        only firewall is referred to.

   Options              Variable-length field, of length such that the
                        complete Middlebox Hop Options header is an integer
                        multiple of 8 octets long. In MIPv6 firewall
                        traversal scenario, MN-NAI Mobility Option defined
                        in [RFC4283] and Mobility Message Authentication
                        Option defined in [RFC4285] are necessary.


8.2.  Extension Header Order

   When more than one extension header is used in the same packet, those
   headers appear in the order defined in [RFC2460], and other
   documents, such as [RFC3775] and so forth.  The Middlebox Hop
   extension header should occur at most once.  The header is
   immediately after Hop-by-Hop Option header.














Xia & Sarikaya          Expires November 2, 2007                [Page 9]

Internet-Draft       Policy-based Firewall Traversal            May 2007


            IPv6 header
            Hop-by-Hop Options header
            Middlebox Hop
            Destination Options header (note 1)
            Routing header
            Fragment header
            Authentication header
            Encapsulating Security Payload header
            Destination Options header
            upper-layer header

            note 1: for options to be processed by the first destination
                    that appears in the IPv6 Destination Address field
                    plus subsequent destinations listed in the Routing
                    header.


8.3.  Process

   The IPv6 extension header is only used for the process of middlebox
   defined in [RFC3234].  Any other network nodes just ignore the
   header.  In MIPv6 firewall traversal scenario, BU and Back includes
   the header to create a pinhole in firewalls en route between MN and
   HA.  The header is also included in control signalling or first data
   packet exchange between MN and CN, or between HA and CN to traverse
   firewalls.  Firewalls intercept packets with the IPv6 extension
   header, extract authentication material in the options and send them
   to policy servers together with other support information, such as
   source IP address, destination IP address, protocol type and so on.
   Policy server download rules for firewalls.


9.  Consideration of Mobile IPv6 Authentication Protocol

   As an alternative of [RFC3775], [I-D.ietf-mip6-rfc4285bis] proposes a
   method for securing MIPv6 signaling messages between Mobile Nodes and
   Home Agents.  The alternate method consists of a MIPv6-specific
   mobility message authentication option that can be added to MIPv6
   signaling messages.  In such case, Middlebox Hop extension header may
   not be included in related messages.


10.  Security Considerations

   This proposal is based on the frame work defined in [RFC2753], and no
   additional security problem is introduced.





Xia & Sarikaya          Expires November 2, 2007               [Page 10]

Internet-Draft       Policy-based Firewall Traversal            May 2007


11.  IANA consideration

   None.


12.  Acknowledgements


13.  References

13.1.  Normative References

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3776]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

   [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
              (MIPv6)", RFC 4283, November 2005.

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

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC3084]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
              K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
              Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
              RFC 3084, March 2001.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

13.2.  Informative references

   [RFC4067]  Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
              "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.

   [I-D.ietf-mip6-rfc4285bis]
              Patel, A., "Authentication Protocol for Mobile IPv6",
              draft-ietf-mip6-rfc4285bis-00 (work in progress),
              March 2007.

   [I-D.thiruvengadam-nsis-mip6-fw]



Xia & Sarikaya          Expires November 2, 2007               [Page 11]

Internet-Draft       Policy-based Firewall Traversal            May 2007


              Tschofenig, H., "Mobile IPv6 - NSIS Interaction for
              Firewall traversal", draft-thiruvengadam-nsis-mip6-fw-06
              (work in progress), March 2007.

   [RFC2753]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
              for Policy-based Admission Control", RFC 2753,
              January 2000.

   [RFC4487]  Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile
              IPv6 and Firewalls: Problem Statement", RFC 4487,
              May 2006.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, February 2002.

   [RFC3303]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
              A. Rayhan, "Middlebox communication architecture and
              framework", RFC 3303, August 2002.

   [RFC3304]  Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
              "Middlebox Communications (midcom) Protocol Requirements",
              RFC 3304, August 2002.

   [RFC4285]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Authentication Protocol for Mobile IPv6",
              RFC 4285, January 2006.

























Xia & Sarikaya          Expires November 2, 2007               [Page 12]

Internet-Draft       Policy-based Firewall Traversal            May 2007


Authors' Addresses

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org

































Xia & Sarikaya          Expires November 2, 2007               [Page 13]

Internet-Draft       Policy-based Firewall Traversal            May 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Xia & Sarikaya          Expires November 2, 2007               [Page 14]