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 ScenarioFigure 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.
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.
