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]