NSIS S. Thiruvengadam Internet-Draft H. Tschofenig Expires: April 27, 2006 Siemens F. Le CMU October 24, 2005 Mobile IPv6 - NSIS Interaction for Firewall traversal draft-thiruvengadam-nsis-mip6-fw-03.txt 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 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 Thiruvengadam, et al. Expires April 27, 2006 [Page 1] Internet-Draft Mobile IPv6-NSIS October 2005 for successful deployment of Mobile IPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Mobile Node behind a firewall . . . . . . . . . . . . . . . . 5 3.1. Binding updates . . . . . . . . . . . . . . . . . . . . . 5 3.2. Route optimization . . . . . . . . . . . . . . . . . . . . 5 3.3. Bi-directional tunneling . . . . . . . . . . . . . . . . . 6 3.4. Triangular routing . . . . . . . . . . . . . . . . . . . . 8 3.5. Change of Firewalls . . . . . . . . . . . . . . . . . . . 9 4. Correspondent Node behind a firewall . . . . . . . . . . . . . 10 4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 10 4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 12 4.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 13 4.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 14 5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 15 5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 15 5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 16 5.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Thiruvengadam, et al. Expires April 27, 2006 [Page 2] Internet-Draft Mobile IPv6-NSIS October 2005 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 [1]. The other modes of communication in Mobile IPv6 namely bi-directional tunneling and triangular routing also do not work under some firewall placements. Apart from this, the Mobile IPv6 binding updates (ESP) packets also have problems with Firewall traversal. 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, as described in [2], allows to establish, maintain and delete middlebox state (i.e., NAT bindings and Firewall rules) to allow packets to traverse these boxes. We identify NSIS as possible solution to the aforementioned problem and describe the solution in detail. For every scenario mode, we will consider the application of NSIS signaling for the three routing modes. We also study other problematic aspects in these scenarios: o Correspondent 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 Correspondent 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 27, 2006 [Page 3] Internet-Draft Mobile IPv6-NSIS October 2005 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 [4], [2], and [5]. 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. Signaling-D is used as an abbreviation for signaling packet filters to allow data traffic to traverse a firewall. Signaling-C is used as an abbreviation for signaling packet filters to allow MIPv6 signaling messages to traverse a firewall. The term 'DS' refers to data sender and the term 'DR' to data receiver. Thiruvengadam, et al. Expires April 27, 2006 [Page 4] Internet-Draft Mobile IPv6-NSIS October 2005 3. Mobile Node behind a firewall 3.1. Binding updates IPsec protected Binding Updates cause problems in some deployment environments, as described in [1]. An interim solution might in some environments the configuration of a firewall to allow the IPsec packets and associated traffic like IKE/IKEv2 packets to traverse. For both inbound and outbound filters, in order to allow IPsec ESP, IP Protocol ID 50 should be allowed in the filter policies. Similarly, to allow IPsec AH, IP Protocol ID 51 should be allowed. The firewall should also allow IKE packets (to UDP port 500) to bypass. These packet filters can be configured manually or dynamically using NSIS before sending the binding updates. 3.2. Route optimization In Figure 1, the message flow for MN behind firewall scenario is shown (with CN as data sender). Here, all the messages initiated by 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 the 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 raises 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 successful, 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, the CN has to initiate Signaling-D to the MN but this happens after the RRT. The MN has to perform a 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. 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 Thiruvengadam, et al. Expires April 27, 2006 [Page 5] Internet-Draft Mobile IPv6-NSIS October 2005 port. Network protected +-------------------------+ | | | +-----+ +-----+ +----+ | | | | | | | | | |Binding Update| | | | | | |-------->-----+ +--------->----------+ | | | | | | Binding ACK | | | | |--------<-----+ +---------<----------+ | | | | | | | | | | MN | | FW | CREATE-C | HA | | | +--------<-----+ +---------<----------+ | | |(DS) | SUCCEED | | | | | | +-------->-----+ +--------->----------+ | | | | | | HoTI | | | | +-------->-----+ +--------->----------+ | | | | HoT | | | | | | +--------<-----+ +---------<----------+ | | | | | | | | | +-----+ +-----+ +----+ | | | | | ^ +-------------------------+ v | +----+ | CN | | | |(DR)| +----+ ----- = signaling traffic Correspondent node Figure 1: NSIS signaling for MN behind the firewall 3.3. Bi-directional tunneling 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 aware of this situation. For this scenario, the HA is forced to do the NSIS signaling. This is unavoidable because the outer header (in the encapsulated packet) Thiruvengadam, et al. Expires April 27, 2006 [Page 6] Internet-Draft Mobile IPv6-NSIS October 2005 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 2. 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. Ideally, when the HA receives data from the CN (destined to MN) for the first time, it should initiated the Signaling-D to the MN. 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. Protected network +-------------------------+ External Mobil | | Node | +-----+ +-----+ +----+ | | | | | | | | | |Binding update| | | | | | |-------->-----+ +--------->----------+ | | | | | | Binding ACK | | | | |--------<-----+ +---------<----------+ | | | | | | | | | | MN | | FW | CREATE-D | HA | | |(DR) +--------<-----+ +---------<----------+ | | | | SUCCEED | | | | | | +-------->-----+ +--------->----------+ | | | | | | | | | | | | | Data traffic | | | | +*******<******+ +*********<**********+ | | | | | | | | | +-----+ +-----+ +----+ | | * +-------------------------+ ^ * +----+ | CN | |(DS)| ***** = Data traffic +----+ ----- = Signaling traffic Correspondent node Thiruvengadam, et al. Expires April 27, 2006 [Page 7] Internet-Draft Mobile IPv6-NSIS October 2005 Figure 2: NSIS signaling for MN behind the firewall 3.4. Triangular routing 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 to initiate signaling to the MN. The HA to MN signaling is completely transparent to the 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. 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 3. Thiruvengadam, et al. Expires April 27, 2006 [Page 8] Internet-Draft Mobile IPv6-NSIS October 2005 Network protected +-------------------------+ | | Home Agent | +-----+ +-----+ +----+ | | |Binding update| | | | | | |-------->-----+ +--------->----------+ | | | | | | Binding ACK | | | | |--------<-----+ +---------<----------+ | | | | | | CREATE-D | HA | | | +--------<-----+ +---------<----------+ | | | | SUCCEED | | | | | | +-------->-----+ +--------->----------+ | | | MN | | FW | Tunneled packets | | | |(DR) +########<#####+ +#########<##########+ | | | | | | | | | | | | | +----+ | | | | | * | | | | | ^ | | | | | * | | | | | +----+ | | | | | | CN | | +-----+ +-----+ |(DS)| | | +----+ +-------------------------+ Correspondent Node ----- = Signaling traffic ***** = Data traffic ##### = Tunneled data traffic Figure 3: NSIS signaling for MN behind the firewall 3.5. Change of Firewalls If the MN roams and attaches to a different firewall, the above- mentioned routing methods will have problems in traversing the new firewall. In this case the data sender (where it is MN or the CN or the HA) should re-signaling to the firewall using NSIS and establish the policies accordingly (mentioned above according to the routing methods). Thiruvengadam, et al. Expires April 27, 2006 [Page 9] Internet-Draft Mobile IPv6-NSIS October 2005 4. Correspondent Node behind a firewall 4.1. Route Optimization In Figure 4, 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 along 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. +----------------+ +----+ | | | HA | | | +----+ | | Home Agent | +----+ +----+ of MN | | CN | | FW | | +----+ +----+ | | +----+ | | | MN | | | +----+ +----------------+ External Mobile Network protected Node by a firewall Figure 4: CN behind the firewall in RRT 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 Thiruvengadam, et al. Expires April 27, 2006 [Page 10] Internet-Draft Mobile IPv6-NSIS October 2005 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. The message flow for NSIS signaling (with MN as data sender) is shown in Figure 5. 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. The prospect of combined Signaling (for control and data traffic) could be useful, but currently the NSIS NAT/FW protocol does not support installing multiple rules at the same time. For the Signaling-D CREATE message from MN to CN, the flow-id will be: SA: CoA, DA: CN This solution works with the assumption that the firewalls will allow NSIS messages from external network to bypass with delayed packet filter state establishment and authorization from the CN. However, operators might be reluctant to allow NSIS message from external network as this might lead to DoS attacks. The CR might therefore be required to authorize the traversal of NSIS signaling message implicitly to reduce unwanted traffic. 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 as explained in [2]. Thiruvengadam, et al. Expires April 27, 2006 [Page 11] Internet-Draft Mobile IPv6-NSIS October 2005 +-----------------------+ | | Home Agent | +-----+ +----+ | | | | HA | | | | +----+ |+----+ | | || | | | CREATE-C +----+ || +--------<-----+ +---------<----------+ | || | SUCCEED | | | | || +-------->-----+ FW +--------->----------+ | || | | | CoTI | | || CN +--------<-----+ +---------<----------+ MN | || | CoT | | | | ||(DR)+-------->-----+ +--------->----------+(DS)| || | | | Binding update | | || +--------<-----+ +---------<----------+ | || | | | | | |+----+ +-----+ +----+ | | Mobile | | Node +-----------------------+ Network protected by a firewall Figure 5: NSIS signaling for CN behind the firewall 4.2. Bi-directional Tunneling If we consider the scenario of the CN being protected by a firewall, there is no need for any signaling if the CN starts sending data traffic. The CN sends the data traffic and hence the SPF will store relevant state information and accepts packets from 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 6. Thiruvengadam, et al. Expires April 27, 2006 [Page 12] Internet-Draft Mobile IPv6-NSIS October 2005 Protected network +-------------------------+ External Mobile | | Node | +-----+ +-----+ +----+ | | | | | | | | | | | | | | | | CN | | FW | CREATE-D | HA | | | +--------<-----+ +---------<----------+ | | |(DR) | SUCCEED | | | | | | +-------->-----+ +--------->----------+ | | | | | | | | | | | | | Data traffic | | | | +**************+ +********************+ | | | | | | | | | +-----+ +-----+ +----+ | | # +-------------------------+ # # +----+ | MN | |(DS)| ***** = Data traffic (both direction) +----+ ----- = signaling traffic Correspondent node ##### = tunneled traffic Figure 6: NSIS signaling for CN behind the firewall 4.3. Triangular routing This section considers the scenario shown in Figure 7 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 a sucessful response. 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 27, 2006 [Page 13] Internet-Draft Mobile IPv6-NSIS October 2005 +-------------------------+ 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 7: 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. 4.4. Change of Firewalls If the MN roams and attaches to a network with a different firewall then the above-mentioned routing methods will have problems in traversing the new firewall. In this case the data sender (where it is MN or the CN or the HA) should re-signaling to the firewall using NSIS and establish the policies accordingly (mentioned above according to the routing methods). Thiruvengadam, et al. Expires April 27, 2006 [Page 14] Internet-Draft Mobile IPv6-NSIS October 2005 5. Home Agent behind a firewall 5.1. Route Optimization This is a special case which requires the HA also to be NSIS aware. The HA should have NR (NSIS) responder capabilities. The 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 recognize IPsec traffic and hence drop the packets because of the absence of any transport header. Hence UDP encapsulation of IPsec traffic might be needed to alleviate this problem. The MN initiates the NSIS Signaling-C to create rules that will allow the Binding Update messages to bypass. The MN then performs the Binding Update to the HA. For the Signaling-C CREATE message from MN to the HA, the flow-id will be: SA: MN, DA: HA, SPIx. (if not UDP encapsulated) Note that this section does not consider the usage of the 'Authentication Protocol for Mobile IPv6' protocol [6]. The firewall rules previously installed will not allow the HoTI message to bypass. Hence, the MN has to install a different set of rules for these signaling messages, by initiating another Signaling-C exchange and then it sends the HOTI message to the 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 the CN to the HA is also allowed by the SPF as it belongs to the session previously initiated by the HA. The HoT message from the HA to the MN is also allowed as it is initiated by the HA. The RRT completes successfully. For the Signaling-C CREATE message from the MN to the HA, the flow-id will be: SA: MN, DA: HA Detailed message flow (with MN as data sender) is shown in Figure 8. Note, only the interaction between the HA and the MN is shown in the figure. Thiruvengadam, et al. Expires April 27, 2006 [Page 15] Internet-Draft Mobile IPv6-NSIS October 2005 +------------------------+ +----+ | | | 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 8: 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. 5.2. Bi-directional tunneling This is a special case which requires the HA also to be NSIS aware. The HA should have the capabilities of the NSIS responder. The CN has to open pin-holes in the FW protecting the HA by initiating a Signaling-D exchange. The CN is then allowed to send the data traffic through the FW. After intercepting the packets, the HA tunnels the packet to the MN. Figure 9 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 Thiruvengadam, et al. Expires April 27, 2006 [Page 16] Internet-Draft Mobile IPv6-NSIS October 2005 port. HA Network protected +-------------------------+ | | | +-----+ +-----+ +----+ | | | | | | | | | | | | CREATE-D | | | | |--------<-----+ +---------<----------+ CN | | | | SUCCEED | | |(DS)| | | |-------->-----+ +---------<----------+ | | | | | | Data traffic | | | | HA |********<*****+ FW +*********<**********+ | | | | | | | | | | | | | +----+ | | | | | | | | | | +----+ | | | | | | | | | +########>#####+ +#########>##########+ MN | | | | | | |(DR)| | | | | | | | | +-----+ +-----+ +----+ | | +-------------------------+ ----- = Signaling traffic ***** = Data traffic ##### = Tunneled data packet Figure 9: NSIS signaling for HA behind the firewall 5.3. Triangular routing 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. 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. Thiruvengadam, et al. Expires April 27, 2006 [Page 17] Internet-Draft Mobile IPv6-NSIS October 2005 +------------------------+ | | | +----+ +-----+ | | | | | 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 27, 2006 [Page 18] Internet-Draft Mobile IPv6-NSIS October 2005 6. Security Considerations The NAT/FW NSLP is in itself a very security sensitive service. A detailed description of possible threats and countermeasures are described in [2]. Thiruvengadam, et al. Expires April 27, 2006 [Page 19] Internet-Draft Mobile IPv6-NSIS October 2005 7. Acknowledgements We would like to thank Martin Stiemerling, Cedric Aoun and Elwyn Davies for the discussions about the NAT/Firewall NSLP. Additionally, we would like to thank Marcus Brunner and Miquel Martin for their feedback. Thiruvengadam, et al. Expires April 27, 2006 [Page 20] Internet-Draft Mobile IPv6-NSIS October 2005 8. References 8.1. Normative References [1] Le, F., "Mobile IPv6 and Firewalls: Problem statement", draft-ietf-mip6-firewalls-03 (work in progress), October 2005. [2] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-07 (work in progress), July 2005. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 8.2. Informative References [5] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [6] Leung, K., "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth-protocol-07 (work in progress), September 2005. Thiruvengadam, et al. Expires April 27, 2006 [Page 21] Internet-Draft Mobile IPv6-NSIS October 2005 Authors' Addresses Srinath Thiruvengadam Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: srinath@mytum.de Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com Franck Le Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213 USA Email: franckle@cmu.edu Thiruvengadam, et al. Expires April 27, 2006 [Page 22] Internet-Draft Mobile IPv6-NSIS October 2005 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 (2005). 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 27, 2006 [Page 23]