One document matched: draft-bajko-mip6-rrtfw-00.txt
MIP6 Working Group Gabor Bajko
Internet Draft Franck Le
Document: <draft-bajko-mip6-rrtfw-00.txt> February, 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 August 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
1. Abstract
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
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
MIP6 Working Group Expiration 08/25/06 1
Firewall friendly RTT for MIPv6
February 2006
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 2
5. New RRT proposal 5
5.1 RRT procedures at the MN 6
5.2 RRT procedures at the CN 6
5.3 HA processing of CoTI-FW 6
5.4 CoTI-FW message 6
5.5 New Mobility Options 7
6. Race conditions 7
7. Security considerations 7
8. Contributors 7
9. References 7
10. Author's Addresses 8
4. Introduction
When a mobile node is behind a Firewall, and/or it is
communicating with a node behind a firewall, the Return
Routability Procedure might not succeed as the Firewalls usually
block packets coming from untrusted sources (e.g. the CoTI or CoT
message).
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 HA of the mobile node B, therefore MH
MIP6 Working Group Expiration 08/25/06 2
Firewall friendly RTT for MIPv6
February 2006
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
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 08/25/06 3
Firewall friendly RTT for MIPv6
February 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 08/25/06 4
Firewall friendly RTT for MIPv6
February 2006
packets would be dropped, as corresponding pinholes were not
opened. Thus RRT would not reach its purpose.
5. 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 08/25/06 5
Firewall friendly RTT for MIPv6
February 2006
A MN SHOULD always perform the herein described procedure when it
experiences problems with the original RTT described in [2].
5.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.
5.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.
5.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].
5.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 08/25/06 6
Firewall friendly RTT for MIPv6
February 2006
5.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.
6. 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.
7. 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.
8. Contributors
Thanks to Lassi Hippelainen for valuable comments.
9. References
MIP6 Working Group Expiration 08/25/06 7
Firewall friendly RTT for MIPv6
February 2006
[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
10. Author's Addresses
Gabor Bajko
gaborbajko@yahoo.com
Franck Le
Carnegie Mellon University
franckle@cmu.edu
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 08/25/06 8
Firewall friendly RTT for MIPv6
February 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 08/25/06 9
| PAFTECH AB 2003-2026 | 2026-04-24 07:38:28 |