Internet DRAFT - draft-miao-mip6-ft
draft-miao-mip6-ft
Network Working Group Yang Shen
Internet-Draft Zhang Hongke
Expires: November, 2006 Zhang Sidong
Beijing Jiaotong University
Miao Fuyou
Huawei Technologies
May, 2006
Firewall Traversal for Mobile IPv6
draft-miao-mip6-ft-02
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, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
Miao, et al. Expires: November 2006 [Page 1]
draft-miao-mip6-ft-02.txt May 2006
As important security devices, firewalls are widely deployed in ISP
and enterprise networks. However, currently firewalls, which are
essentially designed for fixed networks, are difficult to support
Mobile IPv6. Unless firewalls are aware of the detail of mobile IPv6
protocol, they impacts smooth operation of the protocol and can be
harmful to mobile IPv6 deployment.
This internet draft intends to show some ideas to solve the problems
on mobile IPv6 firewall traversal. The solutions proposed are not an
overall solution to fix all the traversal problems.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4
3. Firewall between MN and CN . . . . . . . . . . . . . . . . . 5
3.1. Simple Analysis . . . . . . . . . . . . . . . . . . . 5
3.2. Process to Return Routability Procedure . . . . . . . 5
3.3. Home Address Matching . . . . . . . . . . . . . . . . 5
3.4. CoA Update. . . . . . . . . . . . . . . . . . . . . . 6
4. Firewall between HA and MN . . . . . . . . . . . . . . . . . 6
4.1. New Mobility Header Types . . . . . . . . . . . . . . 7
4.2. Detection Procedure . . . . . . . . . . . . . . . . . 9
5. Problem Unsolved . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations. . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Author's address . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property Statement . . . . . . . . . . . . . . . . . 11
Expiration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Miao, et al. Expires: November 2006 [Page 2]
draft-miao-mip6-ft-02.txt May 2006
1. Introduction
Network environment must be considered during the mobile IPv6
deployment. In this case, firewalls which might block Mobile IPv6
traffic become one of the critical issues. In order to support each
other's operation, some modifications must be made on both sides.
The traffic between MN and HA is encapsulated with IPsec ESP for
security, while most firewalls in use are configured to block IPsec
data. UDP encapsulation is a possible solution to help IPsec data to
pass through the firewall, but it can not be applied to all the
traffic between MN and HA for efficiency consideration. So a dynamic
firewall detection procedure is designed as a Mobile IPv6 extension
in this draft. Two detection messages are sent to HA from MN before
BU, one is UDP encapsulated while the other one is not, HA will
reponse according to the request, the existence of firewall is
determined based on the received replies. Such procedure could solve
the efficiency problem which limits the usage of UDP encapsulation.
In Mobile IPv6 specification, the cara-of address is transparent to
the upper layer, only home address can be seen. If this feature could
be introduced into firewall, most problems would get simplified.
Miao, et al. Expires: November 2006 [Page 3]
draft-miao-mip6-ft-02.txt May 2006
2. Problem Statements
There are four scenarios in which firewalls may interfere in the
smooth operation of the Mobile IPv6 Protocol.
The first scenario is that the CN is protected by a firewall and the
MN is an external node. The problem is that data sent by MN could not
pass through the firewall. Details are described in [6] in section
3.1.
The second scenario is that the MN is protected by a firewall and the
CN is an external node. The problem is that data sent by CN could not
pass through the firewall. Details are described in [6] in section
3.2.
The third scenario actually is similiar to the second one, but it is
more complicated. In this scenario, the CN is an external node and
the MN protected by a firewall moves to another networks which is
protected by another firewall. The problem is that the data sent by
CN could not pass through the firewall because there is not any entry
in the firewall for the cummunication. Details are described in [6]
in section 3.2.5.
The last scenario is about the IPsec data transmitted between MN
and HA. Most firewalls are configured to refuse IPsec data for
security consideration. If MN moves to a network protected by a
firewall, the HoTI message in the Return Routability Test will be
dropped. Details are described in [6] in section 3.2.3.
Miao, et al. Expires: November 2006 [Page 4]
draft-miao-mip6-ft-02.txt May 2006
3. Firewall between MN and CN
3.1. Simple Analysis
There are two primary reasons that Mobile IPv6 message can not pass
through firewall. One reason is that, once MN moved to a new link,
the data traffic sent to/from MN is identified by a new care-of
address, which will cause the traffic to be treated as a new
connection. The other reason is that the firewall is unware of mobile
IPv6 control messages, such as BU, BA, CoTI, HoTI and etc, each of
such messages will be treated as a new connection by firewall.
3.2. Process to Return Routability Procedure
When a firewall receives a packet from outside of the protected
network, it checks the IPv6 header, extension headers and TCP/UDP
header to get <source address, destination address, source port,
destination port, protocol>. Then, then firewall matches it to
filtering entry. It is convenient for the firewall to obverse the
mobility header. Each Mobile IPv6 control message is a part of
mobility header. An administrator who wants to support Mobile IPv6
may configure a firewall to permit the packets that contain the
mobility header to pass through. Although the process helps return
routability procedure to survive firewall, it is noted that it may
open loophole for potential attackers.
3.3. Home Address Matching
The care-of address of mobile IPv6 is designed to be transparent to
the application layer, this idea is presented by using the Type 2
Routing Header and Home Address Option. It can be utilized to
implement firewall traversal. If firewall builds its state entry
based on MN's home address, it will be very simple to traverse
firewall in some cases.
It is supposed that CN is protected by a stateful firewall which is
configured to filter incoming packets based on home address, and MN
is an external node. If CN initiates a connection to MN, the firewall
creates entries based on the first packet. For normal firewall, the
entries may be <CN, CoA, protocol, xx, yy> and <CoA, CN, ptotocol,
yy, xx>, where xx, yy represent the source port number and
destination port number respectively. Now mobile IPv6 firewall gets
the home address from type 2 routing header and replace the
destination address derived from IPv6 header with home address, so
the enties is <CN, HoA, protocol, xx, yy> and <HoA, CN, protocol, yy,
xx>. Any incoming packet sent by MN will be checked based on home
address. Mobile IPv6 firewall gets the home address from home address
destination option (which is carried by the Destination Option
extension header) and replaces the source address derived from IPv6
Miao, et al. Expires: November 2006 [Page 5]
draft-miao-mip6-ft-02.txt May 2006
header. The final filtering information should be <HoA, CN, protocol,
yy, xx>. If it matches any entry, so the data traffic is allowed to
pass through the firewall.
When the MN is protected by stateful firewall and MN moves in the
protected network, it also works. The home address is got from home
address destination option and the address order in filtering entry
is changed.
When a MN moves from one network (protected by firewall or not) to
another network protected by firewall, filtering based on home
address does not work.
3.4. CoA Update
If firewall stores both home address and CoA of a mobile node, it is
possible to update the CoA in the filtering entry whenever MN moves.
Then the same entry can be applied for all following packets without
checking home address.
The proposal reduces process for each packet and saves a lot of CPU
cycles and memory expense. But in the same time it introduces new
loophole resulting denial of service attack.
4. Firewall between HA and MN
In mobile IPv6 specification it is specified that the data passed
between home agent(HA) and MN should be encrypted and authenticated
by IPsec. But nowadays most firewalls don't support IPsec well, or
the administrator would like to configure the firewall to drop all
ESP packets. When there is such a firewall between HA and MN, it is
difficult to accomplish mobile IPv6 communication.
An approach was mentioned in [draft-ietf-mip6-firewalls-00]:
"A common approach, which is also used for NAT traversal, is to
apply UDP encapsulation of IPsec packets. Unlike with NAT traversal
it is not possible to detect the presence of a Firewall
automatically in the same fashion as with a NAT. A NAT modifies the
source IP address when an IP packet travels from the private to the
public addressing space. For a Firewall this is not true. Hence,
UDP encapsulation needs to be enabled proactively."
Enable UDP encapsulation proactively is really not a good idea, since
there will not be a firewall in every case. A mechanism is required
to detect the firewall existence between HA and MN. A mechanism is
introduced to perform this function.
Miao, et al. Expires: November 2006 [Page 6]
draft-miao-mip6-ft-02.txt May 2006
4.1. New Mobility Header Types
Two new mobility header types are defined here, Firewall Detection
and Firewall Detection Reply.
(1)Firewall Detection message
A MN uses Firewall Detection (FD) message to detect the existence of
firewall between MN and HA. The Firewall Detection message uses the
MH Type value TBD. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Firewall Detection Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. This value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Firewall Detection Cookie
64-bit field which contains a random value, the firewall detection
cookie.
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.
This specification does not define any options valid for the Home
Test Init message.
If no option presents in the message, no padding is required and the
Header Len field is set to 1.
Miao, et al. Expires: November 2006 [Page 7]
draft-miao-mip6-ft-02.txt May 2006
(2)Firewall Detection Reply message
The Firewall Detection Reply (FDR) message is a response to the
Firewall Detection message, and is sent from HA to MN. The Firewall
Detection Reply message uses the MH Type value TBD. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Firewall Detection Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. This value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Firewall Detection Cookie
64-bit field which contains a random value, the firewall detection
cookie.
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.
This specification does not define any options valid for the Home
Test Init message.
If option presents in the message, no padding is required and the
Header Len field is set to 1.
Miao, et al. Expires: November 2006 [Page 8]
draft-miao-mip6-ft-02.txt May 2006
4.2. Detection Procedure
In mobile IPv6 specification, each time MN moves into a different
link, it first updates its CoA/HoA binding in HA with BU message. But
the BU message has the possibility to be dropped by firewalls along
the path. To ensure the normal communication, the firewall detection
procedure should be performed in the first time.
when MN moves to a new link, it sends two Firewall Detection
message to HA, one message is UDP encapsulated while the other one is
not. These two messages contain the same value of Firewall Detection
Cookie which is used to match the pair of messages. HA responds
with the Firewall Detection Reply message, whether the reply is
encapsulated depends on the received message, in other word, an
encapsulated reply corresponds to an encapsulated request and an
unencapsulaten reply corresponds to an unencapsulated request. The
procedure works on the basis of fact that the encapsulated message
could always pass through the firewall.
The reply messages MN received will indicate the existence of
firewall. If MN receives two reply messages, both the encapsulated
one and the unencapsulated one, it means that there is no firewall
between HA and MN or firewall allows ESP data to pass through at
least. Neither case impacts the communication between MN and
HA, so there is no need of encapsulation for following messages. If
MN receives the encapsulated message only, it means there is firewall
between MN and HA, so UDP encapsulation is required to enable ESP
data to pass through the firewall.
There may be network congestion or failure, either of the
packets may be lost on the path. Because the two messages are sent
"at the same time", so it is very possible that they are both lost,
which will cause the retransmitting of the two requests. But it is
still possible only one message is lost, especially when the two
messages are sent along different path in the network. If only the
encapsulated message is lost, it indicates that there is no firewall
along the path. If the unencapsulated message is lost, MN may use
encapsulation according to received packet while there is no firewall
actually. It is the only case the firewall detection approach may
fail,but such failure is more acceptable than UDP encapsulation
proactively.
5. Problem Unsolved
When MN moves to a network protected by firewalls, communication whit
CN may also be blocked, as described in [6], so further research is
required.
Miao, et al. Expires: November 2006 [Page 9]
draft-miao-mip6-ft-02.txt May 2006
6. Security Considerations
When the firewall administrator wants to configure his device to
support mobile IPv6, care must be taken. Because the mobile IPv6
works on the network layer, so the rules that allow moblile IPv6
packets to pass through must have the lowest priority.
7. Acknowledgments
I would like to appreciate all the project members Chen Jian,
Ren Yan, Su Wei, Yang He, Zheng Zuzhou.
8. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Montenegro, G. and Gupta V., "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[4] Thiruvengadam S., Tschofenig H. and F. Le, "Mobile IPv6 - NSIS
Interaction for Firewall traversal",
draft-thiruvengadam-nsis-mip6-fw-01 (work in progress), October
23, 2004.
[5] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in progress), July
2004.
[6] Le, F., "Mobile IPv6 and Firewalls Problem statement",
draft-ietf-mip6-firewalls-03 (work in progress), August 2004.
9. Author's address
Miao Fuyou Tel: +86 10 8288 2350
Huawei Technologies Fax: +86 10 8288 2537
No. 3, Xinxi Road, Shangdi, Haidian
Beijing
China,100085 Email: miaofy@huawei.com
Yang Shen Tel: +86 10 5168 5677
IP Lab,EIES Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing http://iplab.njtu.edu.cn
China,100044 EMail: belton.yang@hotmail.com
Miao, et al. Expires: November 2006 [Page 10]
draft-miao-mip6-ft-02.txt May 2006
Zhang Hongke Tel: +86 10 5168 5677
IP Lab,EIES Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing http://iplab.njtu.edu.cn
China,100044 EMail: hkzhang@center.njtu.edu.cn
Zhang Sidong Tel: +86 10 5168 5677
IP Lab,EIES Fax: +86 10 5168 3682
Beijing Jiaotong University of China
Beijing http://iplab.njtu.edu.cn
China,100044 EMail: sdzhang@center.njtu.edu.cn
Full Copyright Statement
Copyright (C) The Internet Society (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.
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.
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
Miao, et al. Expires: November 2006 [Page 11]
draft-miao-mip6-ft-02.txt May 2006
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Expiration
This Internet-Draft (draft-miao-mip6-ft-02.txt) expires in
November, 2006.
Miao, et al. Expires: November 2006 [Page 12]
