RFC 5973
NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
Pages: 90
Experimental
Experimental
Part 5 of 5 – Pages 76 to 90
6. IAB Considerations on UNSAF
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempts to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as STUN [RFC5389] are considered as a general class of workarounds for NAT traversal and as solutions for scenarios with no middlebox communication. This memo specifies a path-coupled middlebox communication protocol, i.e., the NSIS NATFW NSLP. NSIS in general and the NATFW NSLP are not intended as a short-term workaround, but more as a long-term solution for middlebox communication. In NSIS, endpoints are involved in allocating, maintaining, and deleting addresses and ports at the middlebox. However, the full control of addresses and ports at the middlebox is at the NATFW NSLP daemon located at the respective NAT.
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the NATFW NSLP, in accordance with BCP 26, RFC 5226 [RFC5226]. The NATFW NSLP requires IANA to create a number of new registries: o NATFW NSLP Message Types o NATFW NSLP Header Flags o NSLP Response Codes It also requires registration of new values in a number of registries: o NSLP Message Objects o NSLP Identifiers (under GIST Parameters) o Router Alert Option Values (IPv4 and IPv6)7.1. NATFW NSLP Message Type Registry
The NATFW NSLP Message Type is an 8-bit value. The allocation of values for new message types requires IETF Review. Updates and deletion of values from the registry are not possible. This specification defines four NATFW NSLP message types, which form the initial contents of this registry. IANA has added these four NATFW NSLP Message Types: CREATE (0x1), EXTERNAL (0x2), RESPONSE (0x3), and NOTIFY (0x4). 0x0 is Reserved. Each registry entry consists of value, description, and reference.7.2. NATFW NSLP Header Flag Registry
NATFW NSLP messages have a message-specific 8-bit flags/reserved field in their header. The registration of flags is subject to IANA registration. The allocation of values for flag types requires IETF Review. Updates and deletion of values from the registry are not possible. This specification defines only two flags in Section 4.1, the P flag (bit 8) and the E flag (bit 9). Each registry entry consists of value, bit position, description (containing the section number), and reference.
7.3. NSLP Message Object Registry
In Section 4.2 this document defines 9 objects for the NATFW NSLP: NATFW_LT, NATFW_EXTERNAL_IP, NATFW_EXTERNAL_BINDING, NATFW_EFI, NATFW_INFO, NATFW_NONCE, NATFW_MSN, NATFW_DTINFO, NATFW_ICMP_TYPES. IANA has assigned values for them from the NSLP Message Objects registry.7.4. NSLP Response Code Registry
In addition, this document defines a number of Response Codes for the NATFW NSLP. These can be found in Section 4.2.5 and have been assigned values from the NSLP Response Code registry. The allocation of new values for Response Codes requires IETF Review. IANA has assigned values for them as given in Section 4.2.5 for the error class and also for the number of responses values per error class. Each registry entry consists of response code, value, description, and reference.7.5. NSLP IDs and Router Alert Option Values
GIST NSLPID This specification defines an NSLP for use with GIST and thus requires an assigned NSLP identifier. IANA has added one new value (33) to the NSLP Identifiers (NSLPID) registry defined in [RFC5971] for the NATFW NSLP. IPv4 and IPv6 Router Alert Option (RAO) value The GIST specification also requires that each NSLP-ID be associated with specific Router Alert Option (RAO) value. For the purposes of the NATFW NSLP, a single IPv4 RAO value (65) and a single IPv6 RAO value (68) have been allocated.8. Acknowledgments
We would like to thank the following individuals for their contributions to this document at different stages: o Marcus Brunner and Henning Schulzrinne for their work on IETF documents that led us to start with this document; o Miquel Martin for his large contribution on the initial version of this document and one of the first prototype implementations; o Srinath Thiruvengadam and Ali Fessi work for their work on the NAT/firewall threats document;
o Henning Peters for his comments and suggestions; o Ben Campbell as Gen-ART reviewer; o and the NSIS working group.9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.9.2. Informative References
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. [RFC3726] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, October 2010. [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010. [RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010. [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001. [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003. [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003. [rsvp-firewall] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as firewall Signalling Protocol", Proceedings of the 6th IEEE Symposium on Computers and Communications, Hammamet, Tunisia, pp. 57 to 62, IEEE Computer Society Press, July 2001.
Appendix A. Selecting Signaling Destination Addresses for EXTERNAL
As with all other message types, EXTERNAL messages need a reachable IP address of the data sender on the GIST level. For the path- coupled MRM, the source-address of GIST is the reachable IP address (i.e., the real IP address of the data sender, or a wildcard). While this is straightforward, it is not necessarily so for the loose-end MRM. Many applications do not provide the IP address of the communication counterpart, i.e., either the data sender or both a data sender and receiver. For the EXTERNAL messages, the case of data sender is of interest only. The rest of this section gives informational guidance about determining a good destination-address of the LE-MRM in GIST for EXTERNAL messages. This signaling destination address (SDA, the destination-address in GIST) can be the data sender, but for applications that do not provide an address upfront, the destination IP address has to be chosen independently, as it is unknown at the time when the NATFW NSLP signaling has to start. Choosing the 'correct' destination IP address may be difficult and it is possible that there is no 'right answer' for all applications relying on the NATFW NSLP. Whenever possible, it is RECOMMENDED to chose the data sender's IP address as the SDA. It is necessary to differentiate between the received IP addresses on the data sender. Some application-level signaling protocols (e.g., SIP) have the ability to transfer multiple contact IP addresses of the data sender. For instance, private IP addresses, public IP addresses at a NAT, and public IP addresses at a relay. It is RECOMMENDED to use all non-private IP addresses as SDAs. A different SDA must be chosen, if the IP address of the data sender is unknown. This can have multiple reasons: the application-level signaling protocol cannot determine any data sender IP address at this point in time or the data receiver is server behind a NAT, i.e., accepting inbound packets from any host. In this case, the NATFW NSLP can be instructed to use the public IP address of an application server or any other node. Choosing the SDA in this case is out of the scope of the NATFW NSLP and depends on the application's choice. The local network can provide a network-SDA, i.e., an SDA that is only meaningful to the local network. This will ensure that GIST packets with destination-address set to this network-SDA are going to be routed to an edge-NAT or edge-firewall.
Appendix B. Usage of External Binding Addresses
The NATFW_EXTERNAL_BINDING object carries information, which has a different utility to the information carried within the NATFW_EXTERNAL_IP object. The NATFW_EXTERNAL_IP object has the public IP address and potentially port numbers that can be used by the application at the NI to be reachable via the public Internet. However, there are cases in which various NIs are located behind the same public NAT, but are subject to a multi-level NAT deployment, as shown in Figure 35. They can use their public IP address port assigned to them to communicate between each other (e.g., NI with NR1 and NR2) but they are forced to send their traffic through the edge- NAT, even though there is a shorter way possible. NI --192.168.0/24-- NAT1--10.0.0.0/8--NAT2 Internet (public IP) | NR1--192.168.0/24-- NAT3-- | NR2 10.1.2.3 Figure 35: Multi-Level NAT Scenario Figure 35 shows an example that is explored here: 1. NI -> NR1: Both NI and NR1 send EXTERNAL messages towards NAT2 and get an external address+port binding. Then, they exchange that external binding and all traffic gets pinned to NAT2 instead of taking the shortest path by NAT1 to NAT3 directly. However, to do that, NR1 and NI both need to be aware that they also have the address on the external side of NAT1 and NAT3, respectively. If ICE is deployed and there is actually a STUN server in the 10/8 network configured, it is possible to get the shorter path to work. The NATFW NSLP provides all external addresses in the NATFW_EXTERNAL_BINDING towards the public network it could allow for optimizations. 2. For the case NI -> NR2 is even more obvious. Pinning this to NAT2 is an important fallback, but allowing for trying for a direct path between NAT1 and NAT3 might be worth it. Please note that if there are overlapping address domains between NR and the public Internet, the regular routing will not necessary allow sending the packet to the right domain.
Appendix C. Applicability Statement on Data Receivers behind Firewalls
Section 3.7.2 describes how data receivers behind middleboxes can instruct inbound firewalls/NATs to forward NATFW NSLP signaling towards them. Finding an inbound edge-NAT in an address environment with NAT'ed addresses is quite easy. It is only required to find some edge-NAT, as the data traffic will be route-pinned to the NAT. Locating the appropriate edge-firewall with the PC-MRM sent inbound is difficult. For cases with a single, symmetric route from the Internet to the data receiver, it is quite easy; simply follow the default route in the inbound direction. +------+ Data Flow +-------| EFW1 +----------+ <=========== | +------+ ,--+--. +--+--+ / \ NI+-----| FW1 | (Internet )----NR+/NI/DS NR +--+--+ \ / | +------+ `--+--' +-------| EFW2 +----------+ +------+ ~~~~~~~~~~~~~~~~~~~~~> Signaling Flow Figure 36: Data Receiver behind Multiple Firewalls Located in Parallel When a data receiver, and thus NR, is located in a network site that is multihomed with several independently firewalled connections to the public Internet (as shown in Figure 36), the specific firewall through which the data traffic will be routed has to be ascertained. NATFW NSLP signaling messages sent from the NI+/NR during the EXTERNAL message exchange towards the NR+ must be routed by the NTLP to the edge-firewall that will be passed by the data traffic as well. The NTLP would need to be aware about the routing within the Internet to determine the path between the DS and DR. Out of this, the NTLP could determine which of the edge-firewalls, either EFW1 or EFW2, must be selected to forward the NATFW NSLP signaling. Signaling to the wrong edge-firewall, as shown in Figure 36, would install the NATFW NSLP policy rules at the wrong device. This causes either a blocked data flow (when the policy rule is 'allow') or an ongoing attack (when the policy rule is 'deny'). Requiring the NTLP to know all about the routing within the Internet is definitely a tough challenge and usually not possible. In a case as described, the NTLP must basically give up and return an error to the NSLP level, indicating that the next hop discovery is not possible.
Appendix D. Firewall and NAT Resources
This section gives some examples on how NATFW NSLP policy rules could be mapped to real firewall or NAT resources. The firewall rules and NAT bindings are described in a natural way, i.e., in a way that one will find in common implementations.D.1. Wildcarding of Policy Rules
The policy rule/MRI to be installed can be wildcarded to some degree. Wildcarding applies to IP address, transport layer port numbers, and the IP payload (or next header in IPv6). Processing of wildcarding splits into the NTLP and the NATFW NSLP layer. The processing at the NTLP layer is independent of the NSLP layer processing and per-layer constraints apply. For wildcarding in the NTLP, see Section 5.8 of [RFC5971]. Wildcarding at the NATFW NSLP level is always a node local policy decision. A signaling message carrying a wildcarded MRI (and thus policy rule) arriving at an NSLP node can be rejected if the local policy does not allow the request. For instance, take an MRI with IP addresses set (not wildcarded), transport protocol TCP, and TCP port numbers completely wildcarded. If the local policy allows only requests for TCP with all ports set and not wildcarded, the request is going to be rejected.D.2. Mapping to Firewall Rules
This section describes how a NSLP policy rule signaled with a CREATE message is mapped to a firewall rule. The MRI is set as follows: o network-layer-version=IPv4 o source-address=192.0.2.100, prefix-length=32 o destination-address=192.0.50.5, prefix-length=32 o IP-protocol=UDP o L4-source-port=34543, L4-destination-port=23198 The NATFW_EFI object is set to action=allow and sub_ports=0. The resulting policy rule (firewall rule) to be installed might look like: allow udp from 192.0.2.100 port=34543 to 192.0.50.5 port=23198.
D.3. Mapping to NAT Bindings
This section describes how a NSLP policy rule signaled with an EXTERNAL message is mapped to a NAT binding. It is assumed that the EXTERNAL message is sent by a NI+ located behind a NAT and does contain a NATFW_DTINFO object. The MRI is set following using the signaling destination address, since the IP address of the real data sender is not known: o network-layer-version=IPv4 o source-address= 192.168.5.100 o destination-address=SDA o IP-protocol=UDP The NATFW_EFI object is set to action=allow and sub_ports=0. The NATFW_DTINFO object contains these parameters: o P=1 o dest prefix=0 o protocol=UDP o dst port number = 20230, src port number=0 o src IP=0.0.0.0 The edge-NAT allocates the external IP 192.0.2.79 and port 45000. The resulting policy rule (NAT binding) to be installed could look like: translate udp from any to 192.0.2.79 port=45000 to 192.168.5.100 port=20230.D.4. NSLP Handling of Twice-NAT
The dynamic configuration of twice-NATs requires application-level support, as stated in Section 2.5. The NATFW NSLP cannot be used for configuring twice-NATs if application-level support is needed. Assuming application-level support performing the configuration of the twice-NAT and the NATFW NSLP being installed at this devices, the NATFW NSLP must be able to traverse it. The NSLP is probably able to traverse the twice-NAT, as is any other data traffic, but the flow information stored in the NTLP's MRI will be invalidated through the translation of source and destination IP addresses. The NATFW NSLP implementation on the twice-NAT MUST intercept NATFW NSLP and NTLP
signaling messages as any other NATFW NSLP node does. For the given signaling flow, the NATFW NSLP node MUST look up the corresponding IP address translation and modify the NTLP/NSLP signaling accordingly. The modification results in an updated MRI with respect to the source and destination IP addresses.Appendix E. Example for Receiver Proxy Case
This section gives an example on how to use the NATFW NLSP for a receiver behind a NAT, where only the receiving side is NATFW NSLP enabled. We assume FTP as the application to show a working example. An FTP server is located behind a NAT, as shown in Figure 5, and uses the NATFW NSLP to allocate NAT bindings for the control and data channel of the FTP protocol. The information about where to reach the server is communicated by a separate protocol (e.g., email, chat) to the DS side.
Public Internet Private Address Space FTP Client FTP Server DS NAT NI+ | | | | | EXTERNAL | | |<---------------------------|(1) | | | | |RESPONSE[Success] | | |--------------------------->|(2) | |CREATE | | |--------------------------->|(3) | |RESPONSE[Success] | | |<---------------------------|(4) | | | | | <Use port=XYZ, IP=a.b.c.d> | |<=======================================================|(5) |FTP control port=XYZ | FTP control port=21 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(6) | | | | FTP control/get X | FTP control/get X | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(7) | | EXTERNAL | | |<---------------------------|(8) | | | | |RESPONSE[Success] | | |--------------------------->|(9) | |CREATE | | |--------------------------->|(10) | |RESPONSE[Success] | | |<---------------------------|(11) | | | | Use port=FOO, IP=a.b.c.d | Use port=FOO, IP=a.b.c.d | |<~~~~~~~~~~~~~~~~~~~~~~~~~~|<~~~~~~~~~~~~~~~~~~~~~~~~~~~|(12) | | | |FTP data to port=FOO | FTP data to port=20 | |~~~~~~~~~~~~~~~~~~~~~~~~~~>|~~~~~~~~~~~~~~~~~~~~~~~~~~~>|(13) Figure 37: Flow Chart
1. EXTERNAL request message sent to NAT, with these objects:
signaling session lifetime, extended flow information object
(rule action=allow, sub_ports=0), message sequence number
object, nonce object (carrying nonce for CREATE), and the data
terminal information object (I/P-flags set, sender prefix=0,
protocol=TCP, DR port number = 21, DS's IP address=0); using the
LE-MRM. This is used to allocate the external binding for the
FTP control channel (TCP, port 21).
2. Successful RESPONSE sent to NI+, with these objects: signaling
session lifetime, message sequence number object, information
code object ('Success':2), external address object (port=XYZ,
IPv4 addr=a.b.c.d).
3. The NAT sends a CREATE towards NI+, with these objects:
signaling session lifetime, extended flow information object
(rule action=allow, sub_ports=0), message sequence number
object, nonce object (with copied value from (1)); using the PC-
MRM (src-IP=a.b.c.d, src-port=XYZ, dst-IP=NI+, dst-port=21,
downstream).
4. Successful RESPONSE sent to NAT, with these objects: signaling
session lifetime, message sequence number object, information
code object ('Success':2).
5. The application at NI+ sends external NAT binding information to
the other end, i.e., the FTP client at the DS.
6. The FTP client connects the FTP control channel to port=XYZ,
IP=a.b.c.d.
7. The FTP client sends a get command for file X.
8. EXTERNAL request message sent to NAT, with these objects:
signaling session lifetime, extended flow information object
(rule action=allow, sub_ports=0), message sequence number
object, nonce object (carrying nonce for CREATE), and the data
terminal information object (I/P-flags set, sender prefix=32,
protocol=TCP, DR port number = 20, DS's IP address=DS-IP); using
the LE-MRM. This is used to allocate the external binding for
the FTP data channel (TCP, port 22).
9. Successful RESPONSE sent to NI+, with these objects: signaling
session lifetime, message sequence number object, information
code object ('Success':2), external address object (port=FOO,
IPv4 addr=a.b.c.d).
10. The NAT sends a CREATE towards NI+, with these objects:
signaling session lifetime, extended flow information object
(rule action=allow, sub_ports=0), message sequence number
object, nonce object (with copied value from (1)); using the PC-
MRM (src-IP=a.b.c.d, src-port=FOO, dst-IP=NI+, dst-port=20,
downstream).
11. Successful RESPONSE sent to NAT, with these objects: signaling
session lifetime, message sequence number object, information
code object ('Success':2).
12. The FTP server responses with port=FOO and IP=a.b.c.d.
13. The FTP clients connects the data channel to port=FOO and
IP=a.b.c.d.
Authors' Addresses
Martin Stiemerling NEC Europe Ltd. and University of Goettingen Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 113 EMail: Martin.Stiemerling@neclab.eu URI: http://www.stiemerling.org Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at Cedric Aoun Consultant Paris, France EMail: cedaoun@yahoo.fr Elwyn Davies Folly Consulting Soham UK Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com