MIP6 Working Group Gabor Bajko
Internet Draft
Document: <draft-bajko-mip6-rrtfw-01.txt> October, 2006
Firewall friendly RTT for MIPv6
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 April 20, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
1. Abstract
Firewalls represent an integral part of today's IP networks,
currently based on IPv4 technology. Deployment of IPv6 is under way,
and firewall vendors will need to deploy firewalls which will be
able to handle IPv6 packets, including its many extensions. Mobile
IPv6, standardized in RFC3775, specifies a number of extensions and
procedures to IPv6, which do not work when firewalls are on the data
communication path [1].
This document defines a slightly modified Return Routability Test
(RRT) for MIPv6 [2]. The new method is firewall friendly and allows
a mobile node to send Binding Update message to its correspondent
1
Firewall friendly RTT for MIPv6
October 2006
node (so that Route Optimization can be applied) and ensures that
the CN receives the Binding Update, even when either the mobile
node, the CN, or both are located behind firewalls.
2. Conventions used in this document
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 RFC-2119 [1].
3. Abbreviation used in this document
This document uses the following abbreviations:
o CN: Correspondent Node
o CoA: Care of Address
o CoT: Care-of Test
o CoTI: Care-of Test Init
o HA: Home Agent
o HoA: Home Address
o HoT Home Test
o HoTI: Home Test Init
o MN: Mobile Node
o RO: Route Optimization
o RRT: Return Routability Test
3. Table of Content
1. Abstract 1
2. Conventions used in this document 1
3. Table of Content 2
4. Introduction 3
5. Enabling basic mobile IPv6 operation through firewalls 4
6. Enabling route optimization through firewalls 4
5. New RRT proposal 8
5.1 RRT procedures at the MN 9
5.2 RRT procedures at the CN 9
5.3 HA processing of CoTI-FW 9
5.4 CoTI-FW message 9
5.5 New Mobility Options 10
6. Race conditions 10
7. Security considerations 10
8. Contributors 10
9. References 11
10. Author's Addresses 12
4. Introduction
Current firewalls typically create state and filter data traffic
based on the five tuple (sourceIP, destIP, Prot, sourcePort,
MIP6 Working Group Expiration 08/25/06 2
Firewall friendly RTT for MIPv6
October 2006
destPort). Filtering may be applied either to only incoming
traffic or both incoming and outgoing traffic.
RFC3775 recommends the use of IPsec ESP to protect packets between
the MN and its home agent, while today's firewalls, as a default
rule, drop ESP packets, thus preventing the use of mobile IPv6. As
mobile IPv6 could be regarded as a service offered to the mobile
nodes, it is expected that firewalls placed between the access
network, where the mobile node acquires its CoA, and the home
network, where the mobile node's HA is residing, will relax the
filtering rules based on some roaming agreements, thus allowing
mobile nodes to register their CoA with the HA and use mobile IP.
Even though mobile IPv6 signaling between the MN and its HA could
be guaranteed using static configurations in the firewalls, there
is no way to ensure the same for the signaling between the MN and
the CN (for the return routability test purposes). Without
applying route optimization the MN and the CN would be forced to
communicate through their home agents, and that, based on their
topological location, could result in a trombone effect
introducing delays. Such additional delays might not be tolerated
by interactive applications sensitive to delays.
In order to ensure a successful deployment of IPv6 and mobile IPv6
in current IP networks, it is important to have mechanisms and
guidelines in place which help the smooth operation of the
protocol in a firewalled environment.
There are a limited number of possibilities on how to enable
mobile IPv6 through firewalls. One proposal, using the NSLP NATFW
protocol can be found in [3]. The document proposes that the
mobile node running mobile IPv6 uses the NSLP NATFW protocol to
open the required pinholes in the firewalls on the path between
the MN and the CN, before any and each mobile IPv6 signaling is
initiated. The proposal also requires that all the firewalls on
the path support the NSLP NATFW protocol.
The proposal in this document describes an alternative solution
for the problem by making some recommendations on firewall
configuration and defining an extension to mobile IPv6.
5. Enabling basic mobile IPv6 operation through firewalls
MIP6 Working Group Expiration 04/20/07 3
Firewall friendly RTT for MIPv6
October 2006
In order to enable the mobile node to use mobile IPv6, it is
required to allow a communication path between the MN and its HA.
More specifically, the Binding Update, Binding Acknowledgement,
Binding error and Binding Refresh Request messages will need to
pass through the firewalls on the path unaltered.
RFC3775 mandates the use of IPsec and recommends the use of ESP
for these messages.
It is thus recommended that firewall administrators create a rule
in the firewall to allow ESP protected packets between the MN and
its HA to pass through. As these packets might not necessarily be
ESP protected, the firewall would need to recognize mobility
header packets and create a rule to allow these packets to pass
through. One example of such a rule could be to filter on the
sourceIP, destIP and next header value of 135.
6. Enabling route optimization through firewalls
In order to enable route optimizations through firewalls, both
HoTI and CoTI messages (and the corresponding HoT and CoT) need to
successfully pass through.
It is assumed that at the time when the MN initiates a route
optimization procedure towards the CN, there is already some sort
of data communication between the MN and the CN. If the CN is
behind firewall and that firewall does have a rule to allow
packets from the HoA of the MN to the address of the CN, then
there is a good chance that HoTI would also make it through the
firewall. The filtering rule would need to be relaxed to allow in
addition MH packets through between the two destinations (HoA of
the MN and the address of the CN).
If such a rule does not exist in the firewall protecting the CN,
then HoTI will be dropped and the return routability test will
fail.
In order to facilitate the communication between the mobile nodes,
firewalls on the data path between an MN and a CN could also
create the following pinholes automatically:
- a pinhole from the address of the CN to the HoA of the MN
present in the type 2 Routing Header
- - a pinhole from the CoA of the MN to the HoA of the CN present
in the Destination Options extension Header
MIP6 Working Group Expiration 04/20/07 4
Firewall friendly RTT for MIPv6
October 2006
If it is only the MN protected by firewalls but the CN is not,
then HoTI will successfully arrive to the CN. The firewall
protecting the MN would need to allow the corresponding HoT to
pass through and reach the MN. For this, the firewall may need to
create a rule when forwarding the HoTI. An example of such a rule
is to allow packets between the HoA of the MN and the address of
the CN with the Next Header value of 135 to pass through.
Once HoTI is sent out and a HoT response is received, the MN will
send a CoTI message from its current CoA. If there is a firewall
protecting the CN, that firewall will drop the CoTI message as it
is coming from an untrusted source.
In order to illustrate the problem, let’s assume a communication
between an inner node A (protected by the firewall), and an
external mobile node B. It is assumed that the Firewall protecting
the CN (node A) trusts the HoA of the mobile node B, therefore MH
packets like HoTI are allowed to pass through the Firewall without
problems.
As specified in the Mobile IP [2], the transport and above layers
of the ongoing communications should be based on the Home IP
address and HoA of node B, and not the local IP address that node
B might get while roaming in order to support mobility.
The state created in the firewall protecting node A is therefore
initially based on the IP address of node A, and the home address
of the node B, HoA of node B.
If the mobile node B is in its home network, the packets are
directly exchanged between the nodes A and B.
If the mobile node B is roaming, the session can be maintained
thanks to the Home Agent of node B and the reverse tunneling
mechanism [2]. Packets forwarded by the Home Agent to node A will
have the source IP address indicating the Home IP address of node
B and the destination IP address indicating the IP address of node
A. Such packets can thus pass the packet filter inspection in the
firewall protecting node A.
However nodes A and B might be close while node B’s Home agent may
be far, resulting in a 'trombone effect' that can create delay and
degrade the performance. The Mobile IP specifications have defined
the route optimization procedure [2] in order to solve this issue.
The mobile node should first execute a Return Routability Test:
the Mobile Node B should send a Home Test Init message (HoTI) via
MIP6 Working Group Expiration 04/20/07 5
Firewall friendly RTT for MIPv6
October 2006
its Home Agent and a Care of Test Init (CoTI) message directly to
its correspondent node A as illustrated in the figure below [1]:
MIP6 Working Group Expiration 04/20/07 6
Firewall friendly RTT for MIPv6
October 2006
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |<----------------|HA B|
| +----X +----+
| +---+ | ^ CoTI – dropped ^
| | A | | | by the FW |
| +---+ | | | HoTI
| | | |
| | | CoTI (CoA)+---+
| | +------------------| B |
+----------------+ +---+
Network protected External Mobile
by a firewall Node
The Care of Test Init message is more particularly sent from the
new CoA, however such packet will not match any entry in the
packet filter in the firewall and, the CoTI message will thus be
dropped.
As a consequence, the RRT cannot be completed and Route
optimization cannot be applied due to the presence of a firewall.
Support for route optimization is not a non-standard set of
extensions, but a fundamental part of the protocol. Firewalls
however prevent route optimisation to be applied by blocking the
Return Routability Test messages.
The above scenario is one from the problem statements described in
[1].
One could argue that CoTI could be reverse tunneled in the same
way as HoTI, and the problem would be solved. Even though sending
CoTI through the HA provides solution for the case when the CN is
behind Firewall, the problem would not be solved for the symmetric
scenario, when the MN is behind Firewall: if a CoTI is not sent
from the CoA of the MN, the Firewall protecting the MN would not
open a pinhole for the <MN CoA, CN CoA> address pair, and thus CoT
will be dropped, resulting in a failed RRT.
If CoTI would follow the path of HoTI and CoT would follow the
path of HoT, then the Return Routability Test would be successful,
without actually testing the direct path between the MN and CN. If
Firewalls are on the path of the data between MN and CN, the data
MIP6 Working Group Expiration 04/20/07 7
Firewall friendly RTT for MIPv6
October 2006
packets would be dropped, as corresponding pinholes were not
opened. Thus RRT would not reach its purpose.
7. New RTT proposal
This document proposes an additional procedure for the Return
Routability Test to be performed by mobile nodes who wish to
communicate with CNs and either or both parties are behind
Firewalls.
A failure in RRT is usually detected in the CN by not receiving a
CoTI after HOT was sent out. The MN detects the RRT failure by not
receiving a CoT after sending out a CoTI. To solve this problem,
this document proposes that when the MN detects the RRT failure, it
will send out a new MH message, called CoTI-FW. The CoTI-FW will
contain the CoA of the MN in the Mobility Options header field and
it will need to be reverse tunneled through the HA. A CN receiving a
CoTI-FW will know that a CoTI has been probably dropped by the
Firewall. It will send a CoT message to the CoA of the MN in
response to the CoTI-FW. Even if the MN is behind Firewall, the
initial CoTI opened a pinhole which would allow the CoT response to
CoTI-FW to pass through the Firewall and reach the MN.
Figure 1 illustrates the new RRT procedure (the first three messages
are part of the original RRT):
Mobile node Home agent Correspondent node
| |
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|-----------|FW|---------------------->x|FW| dropped |
| |
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| | |
| CoT not sent (as CoTI was not received by CN)<......|
timeout waiting for CoT
| |
| CoTI-FW | |
|------------------------->|------------------------->|
| Care-of Test (CoT) |
|<----------|FW|------------------------|FW|----------|
| |
Figure 1 The new RRT procedure
MIP6 Working Group Expiration 04/20/07 8
Firewall friendly RTT for MIPv6
October 2006
A MN SHOULD always perform the herein described procedure when it
experiences problems with the original RTT described in [2].
7.1 RRT procedures at the MN
A MN MUST NOT send a COTI-FW without sending first a COTI. The MN
MUST NOT send a COTI-FW if a CoT response has been received for the
CoTI.
A MN SHOULD always send a CoTI-FW if it does not receive a CoT
response to the previously sent CoTI. The CoTI-FW MUST contain the
same care-of init cookie as the one sent out in CoTI.
A CoTI-FW MUST contain the MN's CoA in the Mobility Options field.
7.2 RRT procedures at the CN
Upon receiving a CoTI-FW request, the CN creates a care-of keygen
token and uses the current nonce index as the Care-of Nonce Index.
It then creates a Care-of Test message and sends it to the care-of
address of the mobile node found in the Mobility Options field.
7.3 HA processing of CoTI-FW
A CoTI-FW message MUST be processed by the HA as any other Mobility
Header message, as described in [2].
7.4 CoTI-FW message
A mobile node uses the CoTI-FW message to finalize the return
routability procedure and request a care-of keygen token from a
correspondent node when a CoT response to CoTI has not been
received. The CoTI-FW message uses the MH Type value 22 (to be
registered with IANA).
A CoTI-FW message MUST include a mobility options carrying the CoA
of the MN sending it.
MIP6 Working Group Expiration 04/20/07 9
Firewall friendly RTT for MIPv6
October 2006
7.5 New Mobility Options
This specification defines a new Mobility Options called 'MN FW-RRT
CoA' which has an alignment requirement of 8n+6. Its format is as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MN FW-RRT Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MN FW-RRT CoA mobility options is defined to be carried in a
CoTI-FW message.
8. Race conditions
There are a few cases when the CN may receive both CoTI and CoTI-FW
messages, e.g. when CoT got delayed and the MN sends a CoTI-FW after
sending a CoTI.
The CN can and SHOULD detect whether CoTI and CoTI-FW were sent from
the same CoA or not. If they came from the same CoA, the CN SHOULD
NOT respond to both with a CoT, but only to one of them. If CoTI and
CoTI-FW came from different CoA, that might be the result of the MN
changing CoA (e.g. from a CoA not belonging to the same FW protected
network as the CN, to a CoA belonging there) and initiating RRT from
both CoA. The CN SHOULD respond to both messages with a CoT.
9. Security considerations
The proposal herein assumes that future Firewalls supporting MIPv6,
will install states for MH packet initiated flows too, in the same
way as it is currently done for UDP flows. It is the understanding
of the authors, that this does not introduce any additional security
threads to the system.
10. Contributors
Acknowledgements to Franck Le for contributing to this draft. Thanks
to Lassi Hippelainen for valuable comments.
MIP6 Working Group Expiration 04/20/07 10
Firewall friendly RTT for MIPv6
October 2006
11. References
[1] Franck Le, Stefano Faccin, Basavaraj Patil, Hannes Tschofenig,
'Mobile IPv6 and Firewalls, Problem statement' IETF Internet
draft, May 2005.
[2] D. Johnson, C. Perkins, J. Arkko ’Mobility support in IPv6’,
RFC3775, June 2004
[3] http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-
mip6-fw-04.txt, wprk in progress
12. Author's Addresses
Gabor Bajko
gabor.bajko@nokia.com
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
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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
MIP6 Working Group Expiration 04/20/07 11
Firewall friendly RTT for MIPv6
October 2006
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
MIP6 Working Group Expiration 04/20/07 12