One document matched: draft-thiruvengadam-nsis-mip6-fw-01.txt
Differences from draft-thiruvengadam-nsis-mip6-fw-00.txt
NSIS S. Thiruvengadam
Internet-Draft H. Tschofenig
Expires: April 23, 2005 Siemens
F. Le
Nokia
October 23, 2004
Mobile IPv6 - NSIS Interaction for Firewall traversal
draft-thiruvengadam-nsis-mip6-fw-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 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 April 23, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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
Thiruvengadam, et al. Expires April, 2005 [Page 1]
Internet-Draft Mobile IPv6-NSIS October 2004
document is to describe the interaction between NSIS and Mobile IPv6
for successful deployment of Mobile IPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Correspondant Node behind a firewall . . . . . . . . . . . 5
3.2 Mobile Node behind a firewall . . . . . . . . . . . . . . 7
3.3 Home Agent behind a firewall . . . . . . . . . . . . . . . 9
4. Bi-directional tunneling . . . . . . . . . . . . . . . . . . . 12
4.1 Correspondant Node behind firewall . . . . . . . . . . . . 12
4.2 Mobile Node behind firewall . . . . . . . . . . . . . . . 13
4.3 Home Agent behind firewall . . . . . . . . . . . . . . . . 14
5. Triangular routing . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Correspondant Node behind Firewall . . . . . . . . . . . . 16
5.2 Mobile Node behind Firewall . . . . . . . . . . . . . . . 17
5.3 Home Agent behind Firewall . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
Thiruvengadam, et al. Expires April, 2005 [Page 2]
Internet-Draft Mobile IPv6-NSIS October 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 [6]. The other
modes of communication in Mobile IPv6 nameley bi-directional
tunneling and triangular routing also do not work under some firewall
placements. 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 [2],
allows other protocols to establish, maintain and delete Middlebox
state (NAT bindings and Firewall rules). We identify NSIS as
possible solution to the aforementioned problem and describe the
solution in detail. For every communication mode, we will consider
the application of NSIS signaling for the following simple scenarios:
o Correspondant Node (CN) behind a firewall
o Mobile Node (MN) behind a firewall
o Home Agent (HA) behind a firewall
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. For
every NSIS message, we have also provided the NTLP flow-id which will
be used to install the firewall policies.
Thiruvengadam, et al. Expires April, 2005 [Page 3]
Internet-Draft Mobile IPv6-NSIS October 2004
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 [3].
Furthermore, we use the same terminology as in [1], [2], and [7].
Apart from this, we use some abbreviations to describe the flow-id of
the NSIS messages: SA-Source Address, DA-Destination Address,
SP-Source Port, DP-Destination Port and an asterisk is used as
wild-card.
Thiruvengadam, et al. Expires April, 2005 [Page 4]
Internet-Draft Mobile IPv6-NSIS October 2004
3. Route Optimization
In this communication mode, the CN and the MN deliver packets
directly to each other. But before this, the MN has to perform
Return Routability Test (RRT), where it has to send a home test init
(HoTI) message (through the HA) and a Careof test init (CoTI)
(directly) to the CN. The replies for these two messages home test
(HoT) message (from the HA) and the Careof test (CoT) message (from
the CN) are used to construct the binding-key which is used in the
binding update procedure.
3.1 Correspondant Node behind a firewall
In Figure 1, the CN is protected by a firewall that employs stateful
packet filtering (SPF). The external MN and its associated HA are
also shown in the figure. The MN is in its home network and is
communicating with the 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 HoTI message through the HA to the CN and expects a HoT
message from the CN in the same path. It also sends a CoTI message
directly to the CN and expects CoT message in the same path from the
CN. The SPF will only allow packets that belong to an existing
session and hence both the packets (HoTI, CoTI) will be dropped as
these packets are Mobile IPv6 packets and these packets have
different header structure. The existing rules at the firewall might
have been installed for some kind of data traffic.
Thiruvengadam, et al. Expires April, 2005 [Page 5]
Internet-Draft Mobile IPv6-NSIS October 2004
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +----+ +----+ of MN
| | CN | | FW |
| +----+ +----+
| | +----+
| | | MN |
| | +----+
+----------------+ External Mobile
Network protected Node
by a firewall
Figure 1: CN behind the firewall
As the RRT can not be executed, the firewalls rules have to be
modified to allow these MIPv6 messages to go through. The MN
initiates the NSIS session by sending a CREATE 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
authorization. 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. Signaling
to let the MIPv6 messages will be referred to as Signaling-C and
signaling to let the data traffic pass through will be referred to as
Signaling-D from hereon. The message flow for NSIS signaling (with
MN as data sender) is shown in Figure 2. Note, only the message flow
between MN and CN is shown in the diagram.
For the Signaling-C CREATE message from MN to CN, the flow-id will
be: SA: CoA, DA: CN. It is to be noted that policy rules that are to
be installed to allow the HoTI and CoTI packets are different and the
NI has to perform signaling twice.
If the CN wants to continue sending data traffic (CN is the DS) to
the new CoA, it can do so without any additional signaling. This is
because the SPF will allow the traffic initiated by the nodes that it
protects. But if the MN wants to continue sending data traffic (MN
is the DS), it has to perform Signaling-D 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.
Thiruvengadam, et al. Expires April, 2005 [Page 6]
Internet-Draft Mobile IPv6-NSIS October 2004
For the Signaling-D CREATE message from MN to CN, the flow-id will
be: SA: CoA, DA: CN
This solution works with the NSIS assumption that the firewalls will
allow NSIS message from external network. However, operators might
be reluctant to allow NSIS message from external network as this
might lead to DoS attacks. This threat assumes significant
importance if the NR is a mobile terminal.
To avoid this, it is also possible to ask the CN to open pin-holes in
the firewall on behalf of the MN. But this solution will not work in
some scenarios due to routing asymmetry concerns as explained in [5].
+-----------------------+
| | Home Agent
| +-----+ +----+
| | | | HA |
| | | +----+
|+----+ | |
|| | | | CREATE-C +----+
|| +--------<-----+ +---------<----------+ |
|| | SUCCEED | | | |
|| +-------->-----+ FW +--------->----------+ |
|| | | | CoTI | |
|| CN +--------<-----+ +---------<----------+ MN |
|| | CoT | | | |
||(DR)+-------->-----+ +--------->----------+(DS)|
|| | | | Binding update | |
|| +--------<-----+ +---------<----------+ |
|| | | | | |
|+----+ +-----+ +----+
| | Mobile
| | Node
+-----------------------+
Network protected
by a firewall
Figure 2: NSIS signaling for CN behind the firewall
3.2 Mobile Node behind a firewall
In Figure 3, the message flow for MN behind firewall scenario is
shown (with CN as data sender). Here, all the messages initiated by
Thiruvengadam, et al. Expires April, 2005 [Page 7]
Internet-Draft Mobile IPv6-NSIS October 2004
the MN will be bypassed. Immediately after moving to a new network,
the MN acquires a new CoA and it performs the Binding Update to the
HA. The HoT message received by the MN is actually a tunneled
message and as it does not belong to the session initiated by the MN,
it will be dropped by the FW. Hence, either the HA could initiate
NSIS signaling to MN and open pin-holes (only for NSIS aware HA) or
the MN can open pin-holes for these messages to traverse (for NSIS
unaware HA). The latter solution has additional concerns about
routing asymmetry.
For the Signaling-C CREATE message from HA to MN, the flow-id will
be: SA: HA, DA: CoA
Once the RRT is successfull, the binding update message is sent 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, the relevant packet filter rules have
to be installed at the firewall. Hence CN has to initiate
Signaling-D to MN but this happens after the RRT. The MN has to
perform binding update to the CN, conveying its new CoA. Then, if
the CN wants to start the data transfer, it will send an NSLP message
directly to the MN. The HA is not involved in this process (for this
scenario). In scenarios where the network is protected by a single
firewall, the MN can open pin-holes. It should be noted that the HA
signals on behalf of the CN because the CN may not know that the MN
is behind a firewall. The MN might move to different networks, some
protected by a firewall.
For the Signaling-D CREATE message from CN to MN, the flow-id will
be: SA: CN, DA: CoA, SP: data application port, DP: data application
port.
Thiruvengadam, et al. Expires April, 2005 [Page 8]
Internet-Draft Mobile IPv6-NSIS October 2004
Network protected
+-------------------------+
| |
| +-----+ +-----+ +----+
| | | | | | |
| | |Binding Update| | | |
| | |-------->-----+ +--------->----------+ |
| | | | | Binding ACK | |
| | |--------<-----+ +---------<----------+ |
| | | | | | |
| | MN | | FW | CREATE-C | HA |
| | +--------<-----+ +---------<----------+ |
| |(DS) | SUCCEED | | | |
| | +-------->-----+ +--------->----------+ |
| | | | | HoTI | |
| | +-------->-----+ +--------->----------+ |
| | | HoT | | | |
| | +--------<-----+ +---------<----------+ |
| | | | | | |
| +-----+ +-----+ +----+
| | |
| | ^
+-------------------------+ v
|
+----+
| CN |
| |
|(DR)|
+----+
----- = signaling traffic Correspondant
node
Figure 3: MN behind the firewall scenario
3.3 Home Agent behind a firewall
This is a special case which requires the HA also to be NSIS aware.
The HA should have NR (NSIS) responder capabilities.
MN, after entering a new network, sends 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.
The MN-HA binding update message is assumed to be IPsec protected.
This might cause problems, as some primitive firewalls do not
recognise IPsec traffic and hence drop the packets because of the
Thiruvengadam, et al. Expires April, 2005 [Page 9]
Internet-Draft Mobile IPv6-NSIS October 2004
absence of any transport header. Hence UDP encapsulation of IPsec
traffic might be needed to alleviate this problem. The present
firewalls use the SPI (Security Parameter Index) instead of the port
numbers for IPsec traffic.
The MN initiates the NSIS Signaling-C to create rules that will allow
the binding update messages. Then it performs the binding update to
the HA. For the Signaling-C CREATE message from MN to HA, the
flow-id will be: SA: MN, DA: HA, SPIx.
The authors are awaiting feedback from the MIP6 WG which is 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 not allow the HoTI
message. Hence the MN has to install a different set of rules to
allow these messages, by initiating another Signaling-C and then it
sends teh HOTI message to HA. 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.
For the Signaling-C CREATE message from MN to HA, the flow-id will
be: SA: MN, DA: HA
Detailed message flow (with MN as data sender) is shown in Figure 4.
Note, only the interaction between HA and MN is shown in the figure.
Thiruvengadam, et al. Expires April, 2005 [Page 10]
Internet-Draft Mobile IPv6-NSIS October 2004
+------------------------+ +----+
| | | CN |
| | |(DR)|
| | +----+
| |
| +----+ +-----+ +------------------+
| | | | | CREATE-C | +----+ |
| | +--------<-----+ +---------<------|---<---+ | |
| | | SUCCEED | | | | | |
| | +-------->-----+ +--------->------|--->---+ | |
| | | | | Binding update | | | |
| | +--------<-----+ +---------<------|---<---+ | |
| | HA | | FW | Binding ACK | | MN | |
| | +-------->-----+ +--------->------|--->---+ | |
| | | | | | |(DS)| |
| | | | | CREATE-C | | | |
| | +--------<-----+ +---------<------|---<---+ | |
| | | SUCCEED | | | | | |
| | +-------->-----+ +--------->------|--->---+ | |
| | | | | HoTI | | | |
| | +--------<-----+ +---------<------|---<---+ | |
| | | | | HoT | | | |
| | +-------->-----+ +--------->------|--->---+ | |
| | | | | | | | |
| +----+ +-----+ | +----+ |
| | | |
+------------------------+ +------------------+
HA protected by firewall Visited Network
(Home Network)
Figure 4: NSIS signaling for HA behind the firewall
For the data traffic, there is no additional signaling as the MN
sends data directly to CN and none of these networks (CN network and
MN network) are protected by firewalls. This is applicable for both
MN and CN as data senders.
Thiruvengadam, et al. Expires April, 2005 [Page 11]
Internet-Draft Mobile IPv6-NSIS October 2004
4. Bi-directional tunneling
After roaming into a new network, the MN obtains a CoA in the
visiting network. The MN registers itself with the HA. If CN is the
data sender, it sends data to the HoA of the MN. It is routed to the
Home Agent in a normal manner. HA encapsulates this packet and sends
it to the MN. The MN decapsulates the packet. In the opposite
direction, it is reverse tunneled to the Home Agent and then uses
normal IP routing from there to the CN.
4.1 Correspondant Node behind firewall
If we consider the scenario of the CN being protected by a firewall,
there is no need for any signaling if the CN initiates data traffic.
The CN sends the data traffic and hence the SPF will store relevant
connection information and allow the packets in the reverse
direction.
If MN is the DS, then the HA has to initiate signaling-D, so that the
firewall will allow the data traffic from the HA to CN. The message
flow is shown in Figure 5.
Thiruvengadam, et al. Expires April, 2005 [Page 12]
Internet-Draft Mobile IPv6-NSIS October 2004
Protected network
+-------------------------+ External Mobile
| | Node
| +-----+ +-----+ +----+
| | | | | | |
| | | | | | |
| | CN | | FW | CREATE-D | HA |
| | +--------<-----+ +---------<----------+ |
| |(DR) | SUCCEED | | | |
| | +-------->-----+ +--------->----------+ |
| | | | | | |
| | | | | Data traffic | |
| | +**************+ +********************+ |
| | | | | | |
| +-----+ +-----+ +----+
| | #
+-------------------------+ #
#
+----+
| MN |
|(DS)|
***** = Data traffic (both direction) +----+
----- = signaling traffic Correspondant node
##### = tunneled traffic
Figure 5: NSIS signaling for CN behind the firewall
4.2 Mobile Node behind firewall
Consider the scenario where the MN is protected by a SPF. The CN is
generally unaware that the MN is behind the firewall. This might
happen because, as the MN roams it might find itself protected by a
firewall in some networks and the CN is not conveyed this
information. For this scenario, the HA is forced to do the NSIS
signaling. This is unavoidable because the outer header (in the
encapsulated packet) will have HA as the source address and the CoA
as the destination address. The CN does not know the CoA of the MN
and hence it has not chance of opening the pin-hole. Ultimately, the
responsibility falls on the HA. If CN is the DS, 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. As explained earlier, it could be done either
by NSIS aware HA or by the MN itself. The latter solution might
require some topology assumptions. There is another important
question to be resolved in this approach which is the timing of the
Thiruvengadam, et al. Expires April, 2005 [Page 13]
Internet-Draft Mobile IPv6-NSIS October 2004
signaling i.e., when the HA should signal to the MN. This is an open
issue which needs further discussion. If the MN is the DS, no
signaling is needed at all.
For the Signaling-D CREATE message from HA to MN, the flow-id will
be: SA: HA, DA: MN. Note these data messages for which we do
signaling, are IP-in-IP tunneled messages and do not have any
transport header.
Protected network
+-------------------------+ External Mobil
| | Node
| +-----+ +-----+ +----+
| | | | | | |
| | |Binding update| | | |
| | |-------->-----+ +--------->----------+ |
| | | | | Binding ACK | |
| | |--------<-----+ +---------<----------+ |
| | | | | | |
| | MN | | FW | CREATE-D | HA |
| |(DR) +--------<-----+ +---------<----------+ |
| | | SUCCEED | | | |
| | +-------->-----+ +--------->----------+ |
| | | | | | |
| | | | | Data traffic | |
| | +*******<******+ +*********<**********+ |
| | | | | | |
| +-----+ +-----+ +----+
| | *
+-------------------------+ ^
*
+----+
| CN |
|(DS)|
***** = Data traffic +----+
----- = signaling traffic Correspondant node
Figure 6: NSIS signaling for MN behind the firewall
4.3 Home Agent behind firewall
This is a special case which requires the HA also to be NSIS aware.
The HA should have the capabilities of NR (NSIS responder). The CN
has to open pin-holes in the FW protecting the HA by initiating
Thiruvengadam, et al. Expires April, 2005 [Page 14]
Internet-Draft Mobile IPv6-NSIS October 2004
Signaling-D. It is now allowed to send the data traffic through the
FW. After intercepting the packet, the HA tunnels the packet and
sends it to the MN. Figure 7 shows the message flow.
For the Signaling-D CREATE message from CN to HA, the flow-id will
be: SA: CN, DA: HoA, SP: Data application port, DP: Data application
port.
HA Network protected
+-------------------------+
| |
| +-----+ +-----+ +----+
| | | | | | |
| | | | | CREATE-D | |
| | |--------<-----+ +---------<----------+ CN |
| | | SUCCEED | | |(DS)|
| | |-------->-----+ +---------<----------+ |
| | | | | Data traffic | |
| | HA |********<*****+ FW +*********<**********+ |
| | | | | | |
| | | | | +----+
| | | | |
| | | | | +----+
| | | | | | |
| | +########>#####+ +#########>##########+ MN |
| | | | | |(DR)|
| | | | | | |
| +-----+ +-----+ +----+
| |
+-------------------------+
----- = signaling traffic
***** = Data traffic
##### = tunneled packet
Figure 7: NSIS signaling for HA behind the firewall
Thiruvengadam, et al. Expires April, 2005 [Page 15]
Internet-Draft Mobile IPv6-NSIS October 2004
5. Triangular routing
The triangular routing differs from the bi-directional routing in the
reverse direction only (MN to CN direction). In bi-directional
routing, even though the MN obtains the address of the CN, it sends
replies through the HA. This is avoided in triangular routing as the
replies are directly sent to the CN.
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 performs standard Mobile IP processing. 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.
5.1 Correspondant Node behind Firewall
Consider the scenario shown in Figure 8 where the CN is protected by
a FW that has SPF functionality. If the CN is the DS, then the data
traffic will be bypassed by the firewall. But if the MN is the DS,
the firewall will not allow the data packets from the MN (packets in
the reverse direction) as it does not belong to any connection that
exists already.
Hence, the MN has to initiate Signaling-D by sending the CREATE
message to the CN and the FW will install the policies when it
receives the SUCCEED/ERROR message. The CN could also install the
relevant firewall rules for the MN in certain scenarios. Now the MN
is allowed to communicate in the reverse direction.
Thiruvengadam, et al. Expires April, 2005 [Page 16]
Internet-Draft Mobile IPv6-NSIS October 2004
+-------------------------+ Home Agent
| | of MN
| +-----+ +-----+ +----+
| | | | | | HA |
| | | | | | |
| | | | | +----+
| | | | |
| | | | |
| | CN | | FW |
| |(DR) | | | CREATE-D +-+--+
| | +--------<-----+ +---------<----------+ |
| | | SUCCEED | | | |
| | +-------->-----+ +--------->----------+ |
| | | | | |(DS)|
| | | | | Data traffic | MN |
| | +********<*****+ +*********<**********+ |
| | | | | | |
| +-----+ +-----+ +----+
| | External Mobile
| | Node
+-------------------------+
Network protected
----- = signaling traffic
***** = Data traffic
Figure 8: NSIS signaling for CN behind the firewall
For the Signaling-D CREATE message from MN to CN, the flow-id will
be: SA: MN, DA: CN, SP: Data application port, DP: Data application
port.
5.2 Mobile Node behind Firewall
This is a special case where the HA should be NSIS aware and should
have NSIS Initiator (NI) capabilities. After mobility the MN sends a
Binding update message to register its new CoA. If the CN is the DS,
it sends the data to MN through HA. It is HA's responsibility to
discover that the MN is behind a SPF and initiate signaling to MN to
send the tunneled packets. The HA to MN signaling is completely
transparent to CN. The CN is not aware of the fact that the MN is
behind a firewall. The MN could also install the firewall rules in
single firewall scenarios.
For the Signaling-D CREATE message from HA to MN, the flow-id will
be: SA: HA, DA: MN. Note these data messages for which we do
signaling, are IP-in-IP tunneled messages and do not have any
Thiruvengadam, et al. Expires April, 2005 [Page 17]
Internet-Draft Mobile IPv6-NSIS October 2004
transport header.
If the MN is the data sender, no further signaling is needed as the
session is initiated by the MN. The message flow is shown in Figure
9.
Network protected
+-------------------------+
| | Home Agent
| +-----+ +-----+ +----+
| | |Binding update| | | |
| | |-------->-----+ +--------->----------+ |
| | | | | Binding ACK | |
| | |--------<-----+ +---------<----------+ |
| | | | | CREATE-D | HA |
| | +--------<-----+ +---------<----------+ |
| | | SUCCEED | | | |
| | +-------->-----+ +--------->----------+ |
| | MN | | FW | Tunneled packets | |
| |(DR) +########<#####+ +#########<##########+ |
| | | | | | |
| | | | | +----+
| | | | | *
| | | | | ^
| | | | | *
| | | | | +----+
| | | | | | CN |
| +-----+ +-----+ |(DS)|
| | +----+
+-------------------------+ Correspondant Node
----- = signaling traffic
***** = Data traffic
##### = tunneled traffic
Figure 9: NSIS signaling for MN behind the firewall
5.3 Home Agent behind Firewall
This is also a special case where the HA is assumed to be NSIS aware
with NSIS Responder (NR) capabilities. The CN initiates NSIS
signaling to open pin-holes in the FW protecting the HA. Then it can
send the data traffic to HoA. The message flow is shown in Figure
10.
Thiruvengadam, et al. Expires April, 2005 [Page 18]
Internet-Draft Mobile IPv6-NSIS October 2004
For the Signaling-D CREATE message from HA to MN, the flow-id will
be: SA: CN, DA: HoA, SP: Data application port, DP: Data application
port.
+------------------------+
| |
| +----+ +-----+
| | | | | CREATE +----+
| | +--------<-----+ +---------<---------+ |
| | | SUCCEED | | | |
| | +-------->-----+ +--------->---------+ |
| | HA | | FW | | |
| | | | | DATA | CN |
| | +******<*******+ +*********<*********+ |
| | | | | +----+
| | | | |
| | | | |
| | | | |
| | | | | Tunneled data +----+
| | +########>#####+ +#########>#########+ MN |
| | | | | +----+
| +----+ +-----+
| |
+------------------------+
HA protected by firewall
(Home Network)
----- = signaling traffic
***** = Data traffic
##### = tunneled traffic
Figure 10: NSIS signaling for HA behind the firewall
Thiruvengadam, et al. Expires April, 2005 [Page 19]
Internet-Draft Mobile IPv6-NSIS October 2004
6. Security Considerations
The NAT/FW NSLP is in itself a very security sensitive service. A
detailed description of possible threats and counter measures are
described in [4]. In addition to that, the prospect of DoS when
firewalls allow all NSIS signaling messages is dealt with in this
draft.
Thiruvengadam, et al. Expires April, 2005 [Page 20]
Internet-Draft Mobile IPv6-NSIS October 2004
7. 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 April, 2005 [Page 21]
Internet-Draft Mobile IPv6-NSIS October 2004
8. Open Issues
o Do we need to combine Signaling-C and Signaling-D?
o The timing of the HA-MN signaling i.e., when the HA should signal
to the MN behind the firewall.
Thiruvengadam, et al. Expires April, 2005 [Page 22]
Internet-Draft Mobile IPv6-NSIS October 2004
9. References
9.1 Normative References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in progress), July
2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
9.2 Informative References
[4] Fessi, A., "Security Threats for the NAT/Firewall NSLP",
draft-fessi-nsis-natfw-threats-01 (work in progress), July 2004.
[5] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security
Problems", draft-tschofenig-nsis-natfw-security-problems-00
(work in progress), July 2004.
[6] Le, F., "Mobile IPv6 and Firewalls Problem statement",
draft-ietf-mip6-firewalls-00 (work in progress), August 2004.
[7] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
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
Thiruvengadam, et al. Expires April, 2005 [Page 23]
Internet-Draft Mobile IPv6-NSIS October 2004
Franck Le
Nokia Research Center
6000 Connection Drive, Irving
Dallas, Texas 75063
USA
EMail: franck.le@nokia.com
Thiruvengadam, et al. Expires April, 2005 [Page 24]
Internet-Draft Mobile IPv6-NSIS October 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 April, 2005 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 11:18:30 |