NSIS NAT Handling ================= 0. Abstract This document aims to describe different NAT handling classes in NSIS and the relationship between different solutions provided in various NSIS documents. We start with an introduction and the different NAT classes in Section 1 followed by a discussion of how to avoid intermediaries in Section 2. Section 3 goes into the details of addressing NSIS unaware NATs. With Section 4 we give a conclusion. 1. Introduction In the past mainly two approaches have been used for establishing NAT bindings: - Static configuration These NAT bindings are typically used to allow inbound initiated communications. Ephemeral binds are often not established or required. - Dynamic configuration Dynamic NAT creation can be categorized into one of the following three categories: o Implicit creation by outbound initiated communications The translated address and port is selected from a configured address and port pool. o Explicit creation by the Application Layer Gateway(ALG) either via an API call if NAT and ALG are co-located or otherwise via a separate protocol. o Separate signaling protocols which request the creation of a NAT binding An alternative classification can be done by considering the trigger for the creation of a NAT binding. In many cases an outbound data packet itself is used to cause the allocation of a NAT binding. Alternatively, a signaling protocol can be used to establish the same goal by directly addressing the NAT itself. The Midcom and the NSIS working group are trying to develop protocols of the latter category. To address the broad scope of NAT handling this document tries to describe the design considerations for the work in the NSIS WG. An important impact for the design is caused by the introduction of the two layer architecture, intermediaries and by NSIS unaware NATS. Four classes of NAT functionality can be distinguished in NSIS: 1.1. Class 1 NAT Handling We refer to Class 1 NAT handling if NATs or Firewalls implement the NAT/Firewall NSLP. Router 2+ Host A NAT Firewall +--------+ +--------+ +--------+ | NE | | NE | | NE | |+------+| |+------+| |+------+| ||QoS+ || ||QoS+ || ||QoS+ || ||NAT-FW|| ||NAT-FW|| ||NAT-FW|| ||NSLP || ||NSLP || ||NSLP || |+------+| |+------+| |+------+| | || | | || | | || | |+------+| |+------+| |+------+| ==||NTLP ||=========||NTLP ||=======||NTLP ||====> |+------+| |+------+| |+------+| +--------+ +--------+ +--------+ Figure 1: Class 1 NAT Handling The NSIS working group decided to work on two NSLP client layer applications: QoS and NAT/Firewall NSLP. The NAT/Firewall NSLP assumes that a NAT or a Firewall implements the signaling application (i.e., NTLP and NAT/Firewall NSLP implementation). [NAT-FW] describes the signaling mechanisms in more detail. 1.2. Class 2 NAT Handling In Figure 2 a number of QoS NSLP nodes are shown whereby one of the NSIS nodes is a NAT. In this scenario we assume that the NAT device does not contain a NAT/Firewall NSLP implementation. Incremental deployment an lead to such a configuration. A question raised by this scenario is whether the NSIS implementation (NTLP for example) should offer a minimal NAT implementation which allows to request a NAT binding to update the flow identifier. Host A NAT Router 2 +--------+ +--------+ +--------+ | NE | | NE | | NE | |+------+| |+------+| |+------+| ||QoS || ||QoS || ||QoS || ||NSLP || ||NSLP || ||NSLP || || || || || || || |+------+| |+------+| |+------+| | || | | || | | || | |+------+| |+------+| |+------+| ==||NTLP ||=========||NTLP ||=======||NTLP ||====> |+------+| |+------+| |+------+| +--------+ +--------+ +--------+ Figure 2: Class 2 NAT Handling There is some desire to allow an NSLP signaling message exchange (e.g., QoS signaling) to work properly even in presence of a NAT. In this case no NAT/Firewall NSLP implementation is available at the NAT and the end host might not trigger such an exchange. For some cases, the signaling message contains sufficient information to create a NAT binding based on the flow identifier in the NTLP layer. If additional security mechanisms have to be provided by the NAT/Firewall NSLP then the previously described approach will fail since, for example, a QoS NSLP will not be able to provide them. Another question of interest is whether it is possible to combine a NAT/Firewall with a QoS signaling session into a single protocol message (or to at least combine them using a shared session identifier). Error handling might be more complex since it is necessary to deal with errors of the individual signaling applications but also with the combinations. 1.3. Class 3 NAT Handling We speak about Class 3 NAT handling if there is a NAT along the path which intercepts all NSIS signaling messages but does not offer the desired NSLP implementation. In Figure 3a Host A signals for a QoS NSLP but NAT 2 only offers a NTLP implementation. This NTLP could modify a flow identifier, if it is not integrity protected or encrypted. The current GIMPS draft [GIMPS] considers such scenarios. NAT 1 is a device which was already considered in Section 1.2. Host A NAT 1 Router 2 +--------+ +--------+ +--------+ | NE | | NE | | NE | |+------+| |+------+| |+------+| ||QoS || ||QoS || ||QoS || ||NSLP || ||NSLP || NAT 2 ||NSLP || || || || || +--------+ || || |+------+| |+------+| | NE | |+------+| | || | | || | | | | || | |+------+| |+------+| |+------+| |+------+| ==||NTLP ||===||NTLP ||===||NTLP ||===||NTLP ||==> |+------+| |+------+| |+------+| |+------+| +--------+ +--------+ +--------+ +--------+ Figure 3a: Class 3 NAT Handling As a minor variation of the scenario described in Figure 3a, it is possible that the end host does not contain a NAT/Firewall implementation, but the network itself provides a NAT/Firewall solution as shown in Figure 3b. +----------------------------------------+ | Edge | Host A | Router 1 Router 2 NAT/FW | +--------+ +--------+ +--------+ +--------+ | NE | | NE | | NE | | NE | |+------+| |+------+| |+------+| |+------+| ||QoS || ||QoS+ || ||QoS+ || ||[QoS+]|| ||NSLP || ||NAT-FW|| ||NSLP || ||NAT-FW|| || || ||NSLP || || || ||NSLP || |+------+| |+------+| |+------+| |+------+| | || | | || | | || | | || | |+------+| |+------+| |+------+| |+------+| =||NTLP ||==||NTLP ||======||NTLP ||======||NTLP ||=> |+------+| |+------+| |+------+| |+------+| +--------+ +--------+ +--------+ +--------+ | Administrative Domain | +----------------------------------------+ Figure 3b: Class 3 NAT Handling The main advantage of the approach described in Figure 3b is the incremental deployment whereby an administrative domain equips their NAT/Firewalls with NAT/Firewall NSLP implementations even though the end host might not support it. Note that the NAT/FW device might not offer the QoS NSLP implementation. The edge router might create a NAT binding or open a firewall pinhole based on an incoming QoS signaling message (even though the end host is not NAT/Firewall NSLP aware). Edge Router 1 is also able to create NAT/Bindings at the NAT/FW device independently of a signaling exchange. Such a signaling exchange might be necessary if the NAT/Firewall is not equipped with the NSLP application signaled by the end host - in our example this would mean that the NAT/FW would not run a QoS NSLP implementation. 1.4. Class 4 NAT Handling We refer to a Class 4 NAT handling scenario if a NAT is along the path which does not understand NSIS at all. This issue is subject to discussion in [Migration]. Host A Router 2 +--------+ +--------+ | NE | | NE | |+------+| |+------+| ||QoS || ||QoS || ||NSLP || ||NSLP || || || NAT || || |+------+| +--------+ |+------+| | || | |+------+| | || | |+------+| ||Plain || |+------+| ==||NTLP ||=========||NAT ||=======||NTLP ||==== |+------+| |+------+| |+------+| +--------+ +--------+ +--------+ Figure 4: Class 4 NAT Handling To allow NSIS signaling message to traverse an NSIS unaware NAT it is required that they sent in non-raw IP mode. IPsec protected signaling message must use UDP encapsulation. If IKE or IKEv2 is used then NAT traversal functionality is necessary. The relevant work can be found in [AD03], [Hut03], [KS+03] and [Kau03]. 2. Avoiding Intermediaries in GIMPS Intermediaries make NSIS signaling message handling more complex. To avoid these problems it is possible to build functionality into the NTLP to make intermediate nodes to be invisible for NSIS signaling. As a solution, which was already discussed in the past, it is suggested to make the discovery message (C-Mode) or the D-Mode in general cleverer to "discover" only those nodes which implement the desired NSLP functionality. This requires indicating which NSLP functionality the signaling message is looking for along the path. A discovery message might, for example, want to know the next NSIS node along the path which supports a QoS NSLP implementation. It is for further study, whether a more fine-granular discovery is required (e.g., a QoS NSLP node which supports a certain QoS model). IANA registration would be required for the NSLPs and also for QoS models, respectively. Efficiency is an important issue here. An NSIS node which does not implement a certain NSLP application must be able to quickly distinguish whether it is interested in this message or not. Encoding these values into a router alert option, into UDP port numbers, Time-to-Live field or into an IP protocol number was discussed in the past. 3. Addressing NSIS unaware NATs (Class 4 NAT Handling) This section describes NSIS signaling in presence of a Class 4 NAT handling scenario. It is in general not possible to reuse the NAT binding created with the NSIS signaling for the data traffic As an exception it is possible to list a NAT which maps all incoming packets to the same external public IP address without modifying the port number. Hence, NSIS is only able to detect a NAT. To update the flow identifier NSIS signaling would have to interact with a NAT. Worse, an NSIS unaware firewall would in general drop NSIS signaling messages. Hence the firewall has to be configured to allow NSIS signaling message to flow through. Dynamically discovering an NSIS unaware firewall is, in general, difficult. In order to discover a NAT the following procedure can be applied to D-mode messages (which includes also discovery messages). As a solution the initiator of the discovery message would include the source IP address and the source port of the transmitted message into the signaling message payload. An NSIS unaware NAT then modifies the source IP address (and possibly the source port) of the NSIS signaling message. This is typical NAT handling. The responder of the discovery message will notice the modification by comparing the header information with the content of the discovery message. If both are equal then no NAT was present. If the responder sees a deviation then a NSIS unaware NAT was located along the path. The responder returns the source IP address and port number as a payload in the discovery reply message. Traversing an NSIS unaware NAT (from inside to outside) dynamically creates a NAT binding. Please note that only a NAT binding for the signaling traffic is created. It seems to be reasonable that neighboring NSIS nodes control the NAT and also the Firewall (of the same administrative domain) via MIDCOM protocols, such as SNMPv3. Even protocols like STUN or TURN seem to be feasible for NAT handling, although not suggested. Triggered by the end host it is possible that the network performs the necessary actions if in scenarios where - a NAT/Firewall implementation is not available and - a NSIS unaware NAT is present. 4. Conclusion To handle NAT devices properly it is necessary to address the different NAT handling scenarios individually: The impact of intermediaries causes complexity for signaling message handling. It is therefore recommended to avoid Class 2 and Class 3 NAT handling scenarios by incorporating additional knowledge into the discovery message. Class 4 NAT handling requires that some interaction with other protocols such as MIDCOM. To deal with firewalls it is also necessary to (a) allow the NSIS signaling message to pass and (b) also to create pinholes for subsequent data traffic. It is important to keep in mind to differentiate NAT bindings for the signaling traffic and for the data traffic. This separation is necessary since the NSIS signaling message and the subsequent data traffic are different in terms of the flow identifier observed by the NAT. The same is true for firewall pinholes. 5. References [NAT-FW] M. Stiemerling, H. Tschofenig, M. Martin and C. Aoun: "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", IETF Work in Progress, , October, 2003. [Migration] C. Aoun, M. Brunner, M. Stiemerling, M. Martin and H. Tschofenig: "NAT/Firewall NSLP migration and intra-realm communication considerations", IETF Work in Progress, , October, 2003. [Gimps] H. Schulzrinne and R. Hancock: "GIMPS: General Internet Messaging Protocol for Signaling", IETF Work in Progress, , October 2003. [Hut03] Huttunen, A., et al., “UDP Encapsulation of IPsec Packets,” IETF Work in Progress, , October 2003. [KS+03] Kivinen, T., et al.: "Negotiation of NAT-Traversal in the IKE", IETF Work in Progress, , September 2003. [AD03] Aboba, B., and W. Dixon, “IPsec-NAT Compatibility Requirements,” IETF Work in Progress, , October 2003. (Informational) [Kau03] Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” IETF Work in Progress, , January 2004.