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]