One document matched: draft-thiruvengadam-nsis-mip6-fw-00.txt
NSIS S. Thiruvengadam
Internet-Draft H. Tschofenig
Expires: January 10, 2005 Siemens
F. Le
Nokia
July 12, 2004
Mobile IPv6 - NSIS interaction for Firewalls
draft-thiruvengadam-nsis-mip6-fw-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Most of the firewalls deployed today are Mobile IPv6 unaware.
Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6
messages are allowed to pass through these firewalls. A signaling
protocol is needed which can communicate with these firewalls and
instruct them to bypass these Mobile IPv6 messages. The goal of this
document is to describe the interaction between NSIS and Mobile IPv6
for successful deployment of Mobile IPv6.
Thiruvengadam, et al. Expires: January 10, 2005 [Page 1]
Internet-Draft Mobile IPv6-NSIS July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Correspondant Node (CN) behind a firewall . . . . . . . . 3
3.2 Mobile Node (MN) behind a firewall . . . . . . . . . . . . 5
3.3 Home Agent (HA) behind a firewall . . . . . . . . . . . . 6
4. Other Routing Considerations . . . . . . . . . . . . . . . . . 8
4.1 Triangular routing (CN behind Firewall) . . . . . . . . . 8
4.2 Bi-directional routing (MN behind firewall) . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Thiruvengadam, et al. Expires: January 10, 2005 [Page 2]
Internet-Draft Mobile IPv6-NSIS July 2004
1. Introduction
Route optimization, an integral part of Mobile IPv6 specification
does not work with state of the art firewalls that employ stateful
packet filtering. This problem is well described in
[I-D.le-mip6-firewalls]. There is a need for identifying a signaling
protocol that can install some firewall rules to allow these Mobile
IPv6 messages to pass through. The NSIS NAT/FW NSLP described in
[I-D.ietf-nsis-nslp-natfw], allows other protocols to establish/
maintain/delete Middlebox state(NAT bindings and Firewall rules). We
identify NSIS as possible solution to the aforementioned problem and
describe the solution in detail.
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].
Furthermore, we use the same terminology as in [RFC3775],
[I-D.ietf-nsis-nslp-natfw], and [I-D.ietf-nsis-requirements].
3. Route Optimization
In this section we will consider the application of NSIS signaling
for some simple scenarios. It is to be noted that a real scenario
could include a combination of these cases. In all the scenarios, we
assume that the Correspondant Node(CN), Mobile Node(MN) and the
Firewalls(FW) are NSIS aware. When we mention that a network is
protected by a firewall, we assume that there is one central firewall
for the whole network. This assumption will be relaxed in the later
versions of this draft.
o Correspondant Node (CN) behind a firewall
o Mobile Node (MN) behind a firewall
o Home Agent (HA) behind a firewall
3.1 Correspondant Node (CN) behind a firewall
In Figure 1, the correspondant node (CN) is protected by a firewall
that employs stateful packet filtering (SPF). The external mobile
node (MN) and its associated home agent (HA) are also shown in the
figure. The MN is in its home network and is communicating with CN.
Here it is assumed that CN has initiated the communication and hence
it has no problems with the SPF.
The MN moves out of its home network and has to perform the return
routability test (RRT) before sending the binding update to the CN.
It sends a home test init (HoTI) message through the HA to the CN and
Thiruvengadam, et al. Expires: January 10, 2005 [Page 3]
Internet-Draft Mobile IPv6-NSIS July 2004
expects a home test (HoT) message from the CN in the same path. It
also sends a Careof test init (CoTI) message directly to the CN and
expects Careof test (CoT) message in the same path from the CN. The
SPF will only allow packets that belong to an existing session and
hence will drop the COTI packet as this packet has a new source
address.
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +----+ +----+ of MN
| | CN | | FW |
| +----+ +----+
| | +----+
| | | MN |
| | +----+
+----------------+ External Mobile
Network protected Node
by a firewall
Figure 1: CN behind the firewall scenario
The MN initiates the NSIS session by sending a 'create-session'
message to the CN. The FW may not necessarily know the MN and it may
not be able to authenticate the MN. Hence it stores some relevant
state regarding this 'firewall policy installation' request and waits
for the CN's authentication result. Once the CN approves the
request, the FW will install the relevant policy requested by the MN.
When the MN receives both the messages CoT and HoT, it will construct
the binding key and perform binding update to the CN. Note, the
signaling that was aforementioned was only to allow the Mobile IPv6
messages. This will be referred to as Signaling-C from hereon. If
the CN wants to continue sending data traffic to the new CoA, it can
do so without any additional signaling. But if the MN wants to
continue sending data traffic, it has to perform one more round of
signaling to install filter rules for data traffic. This will be
referred to as Signaling-D from hereon. The possibility of combined
signaling is a topic for further discussion. The message flow for
NSIS signaling is shown in Figure 2. Note, only the message flow
between MN and CN is shown in the diagram.
Thiruvengadam, et al. Expires: January 10, 2005 [Page 4]
Internet-Draft Mobile IPv6-NSIS July 2004
+-----------------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| | of MN
| |
| |
|+----+ +-----+
|| | | | CREATE-SESSION +----+
|| +--------<-----+ +---------<----------+ |
|| | PATH-SUCCEED | | | |
|| +-------->-----+ +--------->----------+ |
|| CN | | FW | CoTI | MN |
|| +--------<-----+ +---------<----------+ |
|| | CoT | | | |
|| +-------->-----+ +--------->----------+ |
|| | | | Binding update | |
|| +--------<-----+ +---------<----------+ |
|| | | | Binding ACK | |
|| +-------->-----+ +--------->----------+ |
|| | | | | |
|+----+ +-----+ +----+
| |
| | External Mobile
| | Node
+-----------------------+
Network protected
by a firewall
Figure 2: NSIS signaling for CN behind the firewall
3.2 Mobile Node (MN) behind a firewall
In Figure 3, the least problematic scenario is shown. This is
because the MN is protected by the firewall and all the messages
initiated by the MN will be bypassed. Immediatly after moving to a
new network, the MN acquires a new CoA and it performs the binding
update to the HA. The RRT procedure follows and then it performs the
binding update to the CN. If the MN wants to continue sending data
traffic, then no NSIS signaling is needed at all for this scenario.
However, if the CN wants to send data traffic, CN has to initiate
Signaling-D.
Thiruvengadam, et al. Expires: January 10, 2005 [Page 5]
Internet-Draft Mobile IPv6-NSIS July 2004
Home Network
+----------------+
| |
| +----+ |
| | HA | |
| +----+ |
| : |
+----------------+ | : |
| | | : |
| | +---------:------+
| +----+ | :
| | CN | | :
| +----+ | :
| | v
| | :
+----------------+ +---------:------+
CN's Network | : |
| : |
+----+ +----+ |
| FW | | MN | |
+----+ +----+ |
| |
| |
+----------------+
Visited Network
...... = Mobility direction
Figure 3: MN behind the firewall scenario
3.3 Home Agent (HA) behind a firewall
This is a special case which requires the HA also to be NSIS aware.
The first thing the MN has to do after entering a new network is to
send a binding update to the HA. But as it is initiated by the MN,
it first has to install some filter rules in the FW before sending
the binding update. Hence, it initiates the NSIS Signaling-C to
create rules that will allow the binding update messages.
Then it performs the binding update to the HA. The MN-HA binding
update message is assumed to be IPsec protected. This might cause
problems, as some firewalls do not allow IPsec traffic. Hence UDP
encapsulation of IPsec traffic might be needed to alleviate this
problem. The authors are awaiting feedback from the MIP6 WG which is
Thiruvengadam, et al. Expires: January 10, 2005 [Page 6]
Internet-Draft Mobile IPv6-NSIS July 2004
currently discussing the possibility of using Authentication Data
field to carry Binding Update/Acknowledgement. This might be a
possible alternative for Binding update protection.
The firewall rules previously installed will also allow the HoTI
message. The HA will then send the HoTI to CN and obviously this
message is allowed as it is initiated by the HA. The HoT message
from CN to HA is also allowed by the SPF as it belongs to the session
previously initiated by the HA. The HoT message from HA to MN is
also allowed as it is initiated by the HA. The RRT completes
successfully.
Now the MN has to perform Signaling-D so that the tunneled packets
will be allowed by the FW. Detailed message flow is shown in Figure
4. Note, only the interaction between HA and MN is shown in the
figure.
+------------------------+ +----+
| | | CN |
| | +----+
| | Correspondant node
| |
| +----+ +-----+ +------------------+
| | | | | CREATE-SESSION | +----+ |
| | +--------<-----+ +---------<------|---<---+ | |
| | | PATH-SUCCEED | | | | | |
| | +-------->-----+ +--------->------|--->---+ | |
| | | | | Binding update | | | |
| | +--------<-----+ +---------<------|---<---+ | |
| | | | | Binding ACK | | | |
| | +-------->-----+ +--------->------|--->---+ | |
| | | | | HoTI | | | |
| | +--------<-----+ +---------<------|---<---+ | |
| | | | | HoT | | | |
| | +-------->-----+ +--------->------|--->---+ | |
| | HA | | FW | | | | |
| | | | | | | MN | |
| | | | | | | | |
| | | | | CREATE-SESSION | | | |
| | +--------<-----| +---------<------|---<---+ | |
| | | PATH-SUCCEED | | | | | |
| | +-------->-----+ +--------->------|--->---+ | |
| | | | | DATA | | | |
| | +========<=====+ +=========<======|===<===+ | |
| | | | | | | | |
| +----+ +-----+ | +----+ |
Thiruvengadam, et al. Expires: January 10, 2005 [Page 7]
Internet-Draft Mobile IPv6-NSIS July 2004
| | | |
| | | |
+------------------------+ +------------------+
HA protected by firewall Visited Network
(Home Network)
Figure 4: NSIS signaling for HA behind the firewall
4. Other Routing Considerations
In this section we will consider the application of NSIS signaling
for the other routing scenarios namely:
o Triangular routing
o Bi-directional tunneling
We will treat only some scenarios here. More scenarios will be
treated in later versions of this draft.
4.1 Triangular routing (CN behind Firewall)
In this routing mode, the CN sends the packets with MN's HoA as the
destination address and CN's address as the source address. The HA
intercepts it and encapsulates this packet as explained in [RFC2473].
The HA then sends the encapsulated packet to the MN which has HA's
address as the source address and MN's address as the destination
address. The MN decapsulates the packet and gets to know the address
of the CN. The MN now sends the packets directly to the CN.
Consider the scenario shown in Figure 5. The CN is protected by a FW
that has SPF functionality. It will not allow the packets in the
other direction as it does not belong to any connection that exists
already.
Hence, the MN has to initiate Signaling-D by sending the
'create-session' message to the CN and the FW will install the
policies when it receives the 'path-succeed' message. Now the MN is
allowed to communicate in the reverse direction.
Thiruvengadam, et al. Expires: January 10, 2005 [Page 8]
Internet-Draft Mobile IPv6-NSIS July 2004
+-------------------------+ Home Agent
| | of MN
| +-----+ +-----+ +----+
| | | | | Tunneled packets | HA |
| | +******>*******+ +**********>*********+ |
| | | | | +-+--+
| | | | | *
| | | | | *
| | | | | v
| | CN | | FW | *
| | | | | CREATE-SESSION +-+--+
| | +--------<-----+ +---------<----------+ |
| | | PATH-SUCCEED | | | |
| | +-------->-----+ +--------->----------+ |
| | | | | | |
| | | | | Data traffic | MN |
| | +********<*****+ +*********<**********+ |
| | | | | | |
| +-----+ +-----+ +----+
| |
| | External Mobile
| | Node
+-------------------------+
Network protected
----- = signaling traffic
***** = Data traffic
Figure 5: NSIS signaling for CN behind the firewall in triangular
routing
4.2 Bi-directional routing (MN behind firewall)
If we consider the scenario of the CN being protected by a firewall,
there is no need for any signaling. The CN initiates the data
transfer and hence the SPF will store relevant connection information
and allow the packets in the reverse direction. If we consider the
scenario where the MN is protected by a SPF, then we would require an
NSIS aware HA. Even though the MN had earlier initiated a connection
for the purpose of binding update, new filter rules have to be
installed to allow the tunneled data traffic. The message flow is
shown in Figure 6.
Thiruvengadam, et al. Expires: January 10, 2005 [Page 9]
Internet-Draft Mobile IPv6-NSIS July 2004
Network protected
+-------------------------+ External Mobil
| | Node
| +-----+ +-----+ +----+
| | | | | | |
| | |Binding update| | | |
| | |-------->-----+ +--------->----------+ |
| | | | | Binding ACK | |
| | |--------<-----+ +---------<----------+ |
| | | | | | |
| | MN | | FW | CREATE-SESSION | MN |
| | +--------<-----+ +---------<----------+ |
| | | PATH-SUCCEED | | | |
| | +-------->-----+ +--------->----------+ |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | Data traffic | |
| | +**************+ +********************+ |
| | | | | | |
| +-----+ +-----+ +----+
| | *
| | *
| | *
+-------------------------+ *
*
+----+
| CN |
+----+
----- = signaling traffic Correspondant
***** = Data traffic (both direction) node
Figure 6: NSIS signaling for CN behind the firewall in
bi-directional tunneling
5. Security Considerations
TBD
6. Acknowledgements
Many parts of this documents are the result of some discussions
within the NAT/firewall-NSLP-team including: Marcus Brunner, Miquel
Martin, Martin Stiemerling, and Cedric Aoun.
Thiruvengadam, et al. Expires: January 10, 2005 [Page 10]
Internet-Draft Mobile IPv6-NSIS July 2004
7. Open Issues
o Detailed NSIS signaling message description
o Detailed Route optimization description
o Combining Signaling-C and Signaling-D
o More scenarios to be analysed in 'Other Routing Considerations'
sections
o Relaxing the 'NSIS awareness' requirement for HA
o Relaxing the 'central firewall' assumption
o NAT handling
o Completion of TBDs
8. References
8.1 Normative References
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.le-mip6-firewalls]
Le, F., "Mobile IPv6 and Firewalls",
draft-le-mip6-firewalls-00 (work in progress), February
2004, <reference.I-D.le-mip6-firewalls.xml>.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., Tschofenig, H. and M. Martin, "A NAT/
Firewall NSIS Signaling Layer Protocol (NSLP)",
draft-ietf-nsis-nslp-natfw-01 (work in progress), February
2004, <reference.I-D.ietf-nsis-nslp-natfw.xml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[I-D.ietf-nsis-requirements]
Brunner, M., "Requirements for Signaling Protocols",
draft-ietf-nsis-requirements (work in progress), April
2004, <reference.I-D.ietf-nsis-.requirements.xml>.
8.2 Informative References
[I-D.aoun-nsis-nslp-natfw-migration]
Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.
Tschofenig, "NAT/Firewall NSLP Migration Considerations",
draft-aoun-nsis-nslp-natfw-migration-01 (work in
progress), February 2004,
Thiruvengadam, et al. Expires: January 10, 2005 [Page 11]
Internet-Draft Mobile IPv6-NSIS July 2004
<reference.I-D.aoun-nsis-nslp-natfw-migration.xml>.
Authors' Addresses
Srinath Thiruvengadam
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: srinath@mytum.de
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Franck Le
Nokia Research Center
6000 Connection Drive, Irving
Dallas, Texas 75063
USA
EMail: franck.le@nokia.com
Thiruvengadam, et al. Expires: January 10, 2005 [Page 12]
Internet-Draft Mobile IPv6-NSIS July 2004
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 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 (2004). 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.
Thiruvengadam, et al. Expires: January 10, 2005 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 11:20:10 |