MEXT Working Group X.Cui
Internet Draft Huawei
Intended status: Standards Track February 10, 2010
Expires: August 2010
Stateful Firewall Traversing for Route Optimization
draft-cui-mext-firewall-traversing-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 10, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Cui Expires August 10, 2010 [Page 1]
Internet-Draft Firewall Traversing for RO February 2010
Abstract
This document presents a new approach for the scenario where the
correspondent node is in a network protected by stateful firewall.
The approach extends the mobility management procedure and enables
the Return Routability related messages to traverse the stateful
firewall and Route Optimization may also be achieved well in such
scenario.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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].
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
3. Scenario and Solution Consideration............................4
3.1. Scenario..................................................4
3.2. Solution Consideration....................................5
4. Messages Formats...............................................8
4.1. Extension of HoTI Message.................................8
4.2. Care-of Test Allowance Message............................9
5. Security Considerations........................................9
6. IANA Considerations...........................................10
7. Acknowledgments...............................................10
8. References....................................................11
8.1. Normative References.....................................11
8.2. Informative References...................................11
Author's Addresses...............................................11
Cui Expires August 10, 2010 [Page 2]
Internet-Draft Firewall Traversing for RO February 2010
1. Introduction
Mobile IP [RFC3775] is standardized to support mobility of IPv6 and
the Mobile Node with support of Mobile IP can keep the established
session when it is moving.
Firewall is security device that can protect IP nodes inside the
security domain and resist hostile attacks.
Mobility and security are the most important features of IPv6 but in
current specifications they can not cooperate well.
As specified in [RFC4487], many issues will happen in some scenarios.
Section 5.2 of [RFC4487] shows the scenario where the correspondent
node is in a network protected by firewall. Some analyses for this
scenario are also provided in [RFC4487].
In principle, the issues may be resolved in two different ways,
extension of firewall or extension of mobility management.
One approach, which is based on extensions and configuration of
static firewall, is introduced in [draft-ietf-mext-firewall-admin]
and [draft-ietf-mext-firewall-vendor]. But at present many network
administrators use stateful firewall as the security device and the
configuration of static firewall is not welcomed in many scenarios.
This document presents another approach, which is based on the
combination of extension of Mobility management and stateful
firewall. In this approach the requirements of firewall may be
simplified and the complex configuration on firewall may be avoided.
2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC3775] and
Problem Statement of Mobile IPv6 and Firewalls [RFC4487].
Cui Expires August 10, 2010 [Page 3]
Internet-Draft Firewall Traversing for RO February 2010
3. Scenario and Solution Consideration
3.1. Scenario
This document focuses on the scenario described in section 5.2 of
[RFC4487]. In this scenario the Corresponding Node is protected by
the firewall.
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| | C | +----+
| +---+ | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
Figure 1 CN Is in a Network Protected by Firewall.
Since the stateful firewall is the most common firewall device in
current network, this draft takes the fact as a precondition.
The stateful firewalls implement the Stateful packet filtering
function which is defined in [RFC2647] as "forwarding or rejecting
traffic based on the contents of a state table maintained by a
firewall." [RFC2647] also specifies that "devices using stateful
packet filtering will only forward packets if they correspond with
state information maintained by the device about each connection".
Additionally, the connection is established by data exchanged between
hosts.
In such scenario, the connection between corresponding node C and
external node B is established in the firewall based on the address
of corresponding node C and home address of mobile node B. At this
stage the corresponding node C may send packets to home address (by
existing connection state) and care of address (by dynamically
established connection state) of external mobile node B. The external
node B can send packets to corresponding node only with its home
address but can not send packets to C with its care of address,
Cui Expires August 10, 2010 [Page 4]
Internet-Draft Firewall Traversing for RO February 2010
because there is no corresponding connection state for the care of
address of node B.
3.2. Solution Consideration
This document presents a new approach for the above scenario. The
solution extends the route optimization establishment procedure and
use 'Hole Punching' techniques to set up a connection state for care
of address of external node B.
The message flow of this solution is as follows:
Cui Expires August 10, 2010 [Page 5]
Internet-Draft Firewall Traversing for RO February 2010
CN C Firewall HA MN B
| | | |
| Connection state | |
| for C & HoA of B | |
| | | |
| packets | | |
|------------>| packets | |
| |-------------->| packets |
| | |---------->|
| | | packets |
| | packets |<----------|
| packets |<--------------| |
|<------------| | |
| | | |
| | | HoTI |
a1 | | HoTI |<----------|
a2 | |<--------------| |
| | | CoTI |
a3 | HoTI X<--------------------------|
b1 |<------------| |
| HoT | | |
c1 |------------>| HoT | |
c2 | |-------------->| HoT |
c3 | CoTA | |---------->|
d1 |------------>| CoTA | |
d2 | |-------------------------->|
| | CoTI |
e1 | CoTI |<--------------------------|
e2 |<------------| |
| CoT | |
f1 |------------>| CoT |
f2 | |-------------------------->|
| | Binding Update |
g1 | BU |<--------------------------|
g2 |<------------| |
| Binding Ack | |
g3 |------------>| Binding Ack |
g4 | |-------------------------->|
| | |
| packets | packets |
|<----------->|<------------------------->|
| | |
| | |
Figure 2 Route Optimization Extension for Firewall.
Cui Expires August 10, 2010 [Page 6]
Internet-Draft Firewall Traversing for RO February 2010
The detailed descriptions are as follows:
At the initiatory stage, the stateful firewall establishes a
connection state for the internal node (i.e., CN C) and external node
(i.e., MN B). CN C can send packets to MN B by home address of MN B,
which is included in the destination IP address field of the packet.
Since the firewall maintains the connection state, the packets are
allowed to go through the firewall. MN B can also send packets to CN
C by home address of MN B, which is included in the source IP address
field of the packet. Since the firewall maintains the connection
state, the packets are also allowed to go through the firewall.
(a1~a3) MN B initiates the Return Routability procedure and sends
HoTI and CoTI messages to CN C as specified in [RFC3775], with the
exception that the Punching Flag and Alternate Care-of Address Option
are included in the HoTI message. HoA of MN B is included in the
source IP address field of HoTI and CoA of MN B is included in the
source IP address field of CoTI message.
(b1) Since the firewall maintains the state of HoA connection (i.e.,
between the address pair of CN and HoA of MN), the HoTI message is
allowed to go through the firewall. But the firewall doesn't
maintain the state of CoA connection (i.e., between the address pair
of CN and CoA of MN), the CoTI message is not allowed to go through
the firewall. The firewall drops the CoTI packet.
(c1~c3) CN C receives the HoTI message and replies a HoT message as
specified in [RFC3775]. The HoT message can traverse the firewall and
arrive at MN B.
(d1~d2) The Punching Flag included in HoTI message trigger the CN B
to respond a Care-of Test Allowance (CoTA) message to the address
which is included in the Alternate Care-of Address Option. CN C
copies the care of address from the HoTI message and sends the Care-
of Test Allowance message to the care of address of MN B. Since the
stateful firewall permits the protected node to send packets to the
outside network, the CoTA message can traverse the firewall and
arrive at MN B. The firewall simultaneously establishes a new
connection state for the care of address of MN B in its connection
state table.
(e1~e2) MN B receives the CoTA message and immediately resends the
CoTI message to CN C. Since there is corresponding connection state
in the firewall at this time, the CoTI can go through the firewall.
Cui Expires August 10, 2010 [Page 7]
Internet-Draft Firewall Traversing for RO February 2010
(f1~f2) The CN C receives the CoTI message and responds CoT as
specified in [RFC3775]. The CoT packet goes through the firewall and
arrives at MN B.
(g1~g4) Normal corresponding binding update is implemented as
specified in [RFC3775].
After the Route Optimization is established, packets can be delivered
without the involvement of Home Agent.
4. Messages Formats
4.1. Extension of HoTI Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A new flag (P)unching is added in Home Test Init message to request
firewall punching and Alternate Care-of Address option SHOULD be
included in extended HoTI message.
When the P flag is set to a value of 1 the receiver of HoTI message
SHOULD respond CoTA message to the care of address included in the
same HoTI message.
Cui Expires August 10, 2010 [Page 8]
Internet-Draft Firewall Traversing for RO February 2010
4.2. Care-of Test Allowance Message
A node in the protected network uses the Care-of Test Allowance
(CoTA) message to punch a hole in the stateful firewall for the
Return Routability procedure. The Care-of Test Allowance message
uses the MH Type value TBD1. When this value is indicated in the MH
Type field, the format of the Message Data field in the Mobility
Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. The value MUST be initialized
to zero by the sender, and MUST be ignored by the receiver.
Mobility Options
Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field contains
zero or more TLV-encoded mobility options. The receiver MUST ignore
and skip any options which it does not understand.
5. Security Considerations
The security must be carefully considered for this solution. Since
the attacker can forge the Home Test Init message and cheat the
firewall for a dangerous hole, the protected node must carefully
check the HoTI message and some security extensions may be integrated
in this solution.
Cui Expires August 10, 2010 [Page 9]
Internet-Draft Firewall Traversing for RO February 2010
6. IANA Considerations
TBD1 is a new Mobility Header type value introduced in this document.
IANA is requested to assign the new type value for the Care-of Test
Allowance message.
7. Acknowledgments
TBD.
Cui Expires August 10, 2010 [Page 10]
Internet-Draft Firewall Traversing for RO February 2010
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
8.2. Informative References
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall
Performance", RFC 2647, August 1999.
[RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile
IPv6 and Firewalls: Problem Statement", RFC 4487, May
2006.
Author's Addresses
Xiangsong Cui
Huawei Technologies
KuiKe Bld., No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District, Beijing, P.R. China, 100085
Email: Xiangsong.Cui@huawei.com
Cui Expires August 10, 2010 [Page 11]