NSIS Working Group M. Stiemerling
Internet-Draft NEC
Expires: August 17, 2005 February 16, 2005
Loose End Message Routing Method for NATFW NSLP
draft-stiemerling-nsis-natfw-mrm-01
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 August 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This memo describes the use cases and solution for a new NTLP message
routing method (MRM) that is used by the NATFW NSLP protocol to
located Network Address Translators (NAT) on the upstream data path.
This message routing method is used by NSIS NATFW nodes behind a NAT
to allocate a public reachable IP address and/or port number. The
current way to do so has been named as "signaling the wrong way" and
should be replaced by the proposed message routing method. The scope
of this memo is currently limited to Network Address Translator usage
only, but may be extend to Firewalls.
Stiemerling Expires August 17, 2005 [Page 1]
Internet-Draft NSIS NATFW NSLP MRM February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling the Wrong Way . . . . . . . . . . . . . . . . . . . 5
3. Loose End Message Routing Method . . . . . . . . . . . . . . . 8
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 14
7.2 Informative References . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
Stiemerling Expires August 17, 2005 [Page 2]
Internet-Draft NSIS NATFW NSLP MRM February 2005
1. Introduction
The NATFW NSIS Signaling Layer Protocol (NATFW NSLP) [4] describes a
path-coupled protocol to configure Network Address Translators (NATs)
and Firewalls to let subsequent data traffic traverse these devices.
The NSIS Transport Layer Protocol (NTLP) [3] is used to route those
NATFW NSLP signaling messages on the data path. Typically, the NATFW
NSLP signaling messages are initially sent downstream, meaning from
data sender to data receiver, and responses are sent upstream, from
receiver to sender. In this case, the data sender, and the NATFW
NSLP, know the final receiver of the data flow. Commonly, this
scenario is referred to sender behind NAT or Firewall (see Section
2.3 of [4]).
Another scenario, described in Section 2.4 of [4], describes a data
receiver behind a NAT. Data receivers located in a network that is
separated by a NAT from the public network are not directly
addressable by means of IP addresses. These data receivers are using
private IP addresses, only meaningful in their private network. To
receive data from outside this private network, data receivers must
first obtain a globally routable IP address (public IP address).
This public IP address is located at the NAT of the network and is
usually used in application level signaling exchanges to inform the
data sender where to send its data. Note that there may be several
NATs connecting this private network to the public network (NATs are
placed in parallel) or NATs may be placed in sequence. Figure 1
shows such a network configuration. The local network can consist of
several other Firewalls or NATs located on the data path and NSIS
signaling path.
//------\\ +------+ /----------\
DR ---| Local |----| edge |----| Internet |---- DS
| Network| | NAT | \----------/
\\------// +------+
private public
DS: Data sender
DR: Data receiver
Figure 1: Data Receiver behind NAT
When a data receiver knows the data sender's IP address (at least),
it will send its NSIS NATFW NSLP signaling message upstream towards
this address. The NTLP must forward this signaling message upstream
and the NATFW NSLP will stop the forwarding process a the outermost
NAT, the so-called edge-NAT. The NATFW NSLP message type to be used
Stiemerling Expires August 17, 2005 [Page 3]
Internet-Draft NSIS NATFW NSLP MRM February 2005
for this upstream signaling is RESERVE-EXTERNAL-ADDRESS (REA).
The above described assumes that the data receiver knows the IP
address of the data sender in advance. However, in many applications
the IP address of the data sender is not known in advance, such as
SIP. In this case the NATFW NSLP signaling message for REA cannot be
sent upstream towards an IP address. Nevertheless, to get a public
reachable IP address the data receiver must somehow find the external
NAT and allocated an IP address or port number, depending on the NAT
type.
This document focuses on NATs only and does currently not consider
Firewalls. However, future versions of this document may consider
Firewalls for the loose end message routing method; this would add
support for the data receivers behind Firewalls requiring NATFW NSLP
proxy mode support (see Section 3.3.9 of [4].) Limiting the scope of
this document to NATs only has a simple but compelling reason:
Locating upstream Firewalls and NATs is not a simple task to be
performed by NSIS. Other working groups, such as IETF's ICMP
traceback, trying to find the path of data streams upstream, from
data receivers to data senders. This seems to be a non-trivial task
for the regular Internet with a single IP address space. This
applies to networks with firewall deployments too. Networks using a
private IP address space are easier to handle in this case: NSIS
just needs to find an edge-NAT that is the border between the public
Internet and the private network. The IP address and port number
allocated at the edge-NAT by means of NATFW NSLP's REA message is in
fact a route pinning. All traffic will traverse this single
edge-NAT.
Section 2 describes the current proposed way of locating the external
NAT and requesting an external IP address and port number (as
described in in [4]). The new proposed way of locating the NAT is
described in Section 3.
The terminology used throughout this memo is aligned to the NSIS
terminology.
Stiemerling Expires August 17, 2005 [Page 4]
Internet-Draft NSIS NATFW NSLP MRM February 2005
2. Signaling the Wrong Way
The NATFW NSLP protocol specification defines a mechanism to located
upstream NATs; This mechanism is commonly referred to as signaling
the wrong way (see Section 5.4.2 in [4].) This way of signaling uses
a faked data sender's address and sends the RESERVE-EXTERNAL-ADDRESS
(REA) message against the intended direction of the data stream
towards the faked address. This REA messages uses the standard
downstream message routing method (MRM) defined in NTLP [3].
edge NAT
+------+
|NATFW | +----+
.'+NSLP `. ' OA |
/ |w/ NAT| \ ,-----. +----+
+------+ .' +------+ `./ . NR+
+----+ |NATFW | / / \
| NR |----+NSLP |+ ( Internet )
+----+ |w/ NAT| \ \ /
NI+ +------+ `. +------+ .' `.
\ |NATFW | .' `-----' `. +----+
`.+NSLP .' `.| NI |
|w/ NAT| +----+
+------+
edge NAT
Figure 2: NATFW NSLP elements
Figure 2 shows a typical network topology for data receivers behind
NATs. The figure denotes the data receiver as NSIS NATFW NSLP
receiver (NR) and the data sender as NSIS NATFW NSLP initiator (NI).
NI+ denotes an arbitrary IP address, named as Opportunistic Address
(OA). The naming convention NR/NI refers to the CREATE signaling
where the data sender is initiating the signaling. The naming
convention printed below the particular boxes (NI+ and NR+) refer to
the REA signaling where the data receiver is initiating the NATFW
NSLP signaling.
The data receiver acting as NI+ sets the NTLP message routing
information for the REA message as follows
o the NTLP signaling destination address is set to the faked data
sender's address (Opportunistic Address, NR+),
o the NTLP signaling source address is set to data receiver's
address (NI+), and
Stiemerling Expires August 17, 2005 [Page 5]
Internet-Draft NSIS NATFW NSLP MRM February 2005
o the signaling direction is set to downstream.
Further information like port numbers, transport protocol, etc might
be set, too. The NSLP uses the RESERVE-EXTERNAL-ADDRESS (REA)
request message. The signaling message is sent downstream to NR+,
intercepted and processed by NATFW NSLP nodes implementing Network
Address Translation (NAT). NATFW NSLP nodes implementing just
Firewall functionality, forward the message, unless they are
edge-Firewalls. Edge-Firewalls stop the message forwarding and do
reply with an error response 'no NAT here' to indicate that there is
no NAT on this path. Each NAT on the path takes the message and
processes it. An IP address/port is reserved at the NAT, but not
enabled, and the translation is prepared for future use. Reserved
and prepared refers to getting all necessary configurations done at
the NAT to enable later translations immediately. The message is
forwarded until it reaches an edge-NAT. The edge-NAT stops the
message forwarding and replies with a response message indicating the
reserved external IP address/port number. This IP address and port
number can now be used by the application at the NR to indicate its
reachable address to other parties.
To make data transmission work, a real NSIS initiator (NI) must now
send a CREATE request message to the allocated IP address/port number
at the edge-NAT. This CREATE request message enables the NATs and
Firewalls to forward the data packets. The defined rules for
processing and forwarding CREATE apply, meaning that these messages
are sent from NI to NR and install NSIS state and Firewall/NAT rules
in the NATFW NSLP nodes. Note that the NSIS initiator of this CREATE
message is not necessary the same as used by the REA message noted as
NI+.
This method of locating upstream NATs on the data path installs
several states on NTLP and NSLP level. First of all, state is
installed on the NTLP level from NR to the edge-NAT with the final
destination address set to NR+ at each NATFW NSLP node. This state
must be maintained with REA refresh messages, since it is subject to
the regular timeout handling. Second, with the arrival of the CREATE
message at NR, the state for REA must be removed since it is no
longer used. Instead of this, the state for CREATE must be
maintained. The state built during the REA phase is probably never
used by any incoming CREATE request message and is to a certain
degree misleading, since NI+ is not the real NSIS initiator. Figure
3 shows the state installed for REA and CREATE in a mixed Firewall
and NAT environment.
Stiemerling Expires August 17, 2005 [Page 6]
Internet-Draft NSIS NATFW NSLP MRM February 2005
Firewall
+------+
|NATFW | +----+
*********|NSLP |******** | OA |
* |w/ FW | * ,-----. +----+
* +------+ +--*---+ / \ NR+
+-*--+ |NATFW | / \
| NR ++++ |NSLP | ( Internet )
+----+ + +++w/ NAT+++ \ /
NI+ + +------+ + +------+ + \ /
+ |NATFW | + edge-NAT + `-----' +----+
++++NSLP ++++ +++++++++++++++++++| NI |
|w/ FW | +----+
+------+
Firewall
****: State created by REA
++++: State created by CREATE
Figure 3: Installed NATFW NSLP state
The figure shows a scenario with routing asymmetry on the path
between the edge-NAT and the NR. This highlights that the path taken
by REA signaling messages and CREATE signaling messages must not be
the same and must be treated independently. Keeping state involves
the setup and maintenance of NTLP connection mode (C-MODE, most
likely TCP based) between all neighboring NSIS peers running the
NATFW NSLP. Figure 3 shows that REA state is kept between NR and the
firewall and the edge-NAT but is never used in subsequent signaling
for CREATE.
The 'signaling the wrong way' approach seems to be more a work around
solution instead of a proper one that is well understood. Therefore,
the next section proposes a new way of spotting the NAT, minimizing
state and giving a clean way of finding NATs even without knowing the
NSIS sender NS.
Stiemerling Expires August 17, 2005 [Page 7]
Internet-Draft NSIS NATFW NSLP MRM February 2005
3. Loose End Message Routing Method
This section proposes a new message routing method (MRM) to find NATs
on the network side of data receivers. As described earlier, some
applications require to retrieve a public reachable IP address/port
number without knowing where the data traffic is coming from, meaning
that data sender and thus the later NSIS initiator (NI) is unknown,
and without being required to have knowledge about the network
topology. For the first reason, signaling messages must be sent to a
faked address NR+, resulting in a loose end with respect to the
signaling since this not the actual fixed sender's address but an
imaginary IP address located in the public IP space. This faked
address of the NSIS sender NR+ is called signaling destination
address (SDA) within this document. The current NATFW NSLP
specification uses the term Opportunistic Address, see also Section
2.
The loose end message routing method (LEMRM) requires that the NTLP
routes messages upstream from NI+ to NR+ and that NATFW NSLP nodes
implementing NAT are processing these messages only. All other NTLP
nodes just forward the messagse and NATFW NSLP nodes implementing
Firewall functionality do not process this messages at all. The
processing at NATs and edge-NATs regarding NAT configuration is
unchanged. NTLP and NSLP state is only kept at the NATs that
intercepted and processed the REA message. All other messages, such
as responses and repeated REAs for state refresh, are exchanged
directly between NATFW NSLP nodes involved. Through this, state to
be maintained is minimized and only the NR and NATFW NSLP nodes with
NAT functionality are forced to keep this NTLP and NSLP state.
A NR using the REA request message must set NTLP's MRI to signaling
destination address (SDA, NR+) as destination-address and its own
address NR as source-address. A new field (yet to be defined)
indicates to the NTLP that the destination-address is not the real
NSIS initiator's (NI) address, but the SDA and that LEMRM must be
used for routing this message. The NTLP routes the REA message
upstream to towards the SDA via D-MODE. NATFW NSLPs implementing NAT
functionality intercept and process the REA message according [4].
Edge NATs stop the message forwarding. NTLP C-MODE connections are
being established between neighboring NATFW NSLP peers that implement
NAT functionality. Figure 4 shows the state installed for REA and
CREATE in a mixed Firewall and NAT environment when using LEMRM.
Stiemerling Expires August 17, 2005 [Page 8]
Internet-Draft NSIS NATFW NSLP MRM February 2005
Firewall
+------+
|NATFW | +----+
|NSLP | | OA |
|w/ FW | ,-----. +----+
+------+ +------+ / \ NR+
+----+******************NATFW | / \
| NR ++++ |NSLP | ( Internet )
+----+ + +++w/ NAT+++ \ /
NI+ + +------+ + +------+ + \ /
+ |NATFW | + edge-NAT + `-----' +----+
++++NSLP ++++ +++++++++++++++++++| NI |
|w/ FW | +----+
+------+
Firewall
****: State created by REA
++++: State created by CREATE
Figure 4: LEMRM installed NATFW NSLP state
This approach raises questions with respect to intermediate NATFW
NSLP nodes implementating Firewall functionality only. Detecting
neighboring NTLP nodes, and NSLP nodes, is done by using NTLP's
D-MODE GIMPS-query and GIMPS-response messages. Assuming UDP as
transport protocol, with router alert option set, intermediate
Firewalls need to forward these packets and remember Firewall state
locally (this is not NATFW state). A NATFW NSLP aware edge-NAT on
the data path will intercept this UDP packet and respond back to the
particular signaling source. This UDP packet is routed back to the
signaling source and uses the regular standard routing. The packet
will reach the Firewall with stored state with symmetric routes
between the edge-NAT and the signaling source and is going to be
forwarded further. Asymmetric routing, as shown in Figure 4, will
forward the packet to the wrong firewall that most likely drops the
packet. The LEMRM as described above makes these assumptions:
o Intermediate Firewalls allow UDP packets to traverse in both
directions, from internal to external and vice versa. At least
they allow UDP packets being initiated from internal side to
external and back by storing state for this UDP packet.
o Symmetric routes are in place.
o TCP connections initiated from the NSIS peer located internally
are allowed to traverse towards the NSIS peer located externally.
In the above figure NR is able to initiated a TCP connection to
the edge-NAT. This assumes TCP for C-MODE.
Stiemerling Expires August 17, 2005 [Page 9]
Internet-Draft NSIS NATFW NSLP MRM February 2005
Assuming other transport protocols than TCP and UDP will result in
even more complicated problems, since Firewalls usually understand
TCP and UDP only.
The LEMRM may require that intermediate NATFW NSLP peers implementing
Firewall functionality only must store NTLP/NSLP state.
A real NSIS initiator (NI) can use the via REA allocated IP address/
port number to send its CREATE request message to. The CREATE
message is processed as in [4] and requires a new path discovery from
edge NAT towards NR. This path discovery will located all NATFW NSLP
nodes (Firewalls and NATs) along the data path and enable the data
path from NI to NR.
Section 8.9 of [3] describes how new MRMs must be defined. The exact
format, filtering/security, and NAT processing of MRI format are to
be done in future versions of this document.
Stiemerling Expires August 17, 2005 [Page 10]
Internet-Draft NSIS NATFW NSLP MRM February 2005
4. Conclusions
This memo discusses a new message routing method for the NATFW NSLP.
This new MRM is intended to replace the current proposed 'signaling
the wrong way' approach. Apparently, LEMRM concerns two layers of
the NSIS stack, the NTLP and NATFW NSLP. Message routing is part of
the NTLP layer and state setup is part of the NATFW NSLP layer. This
separation is not yet fully described in this document.
Stiemerling Expires August 17, 2005 [Page 11]
Internet-Draft NSIS NATFW NSLP MRM February 2005
5. Security Considerations
Security considerations are to be done.
Stiemerling Expires August 17, 2005 [Page 12]
Internet-Draft NSIS NATFW NSLP MRM February 2005
6. Open Issues
o Spotting the NAT with SDA equal to real NS
o Using LEMRM for locating Firewalls
Stiemerling Expires August 17, 2005 [Page 13]
Internet-Draft NSIS NATFW NSLP MRM February 2005
7. References
7.1 Normative References
[1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT
draft-ietf-nsis-fw-07.txt, November 2004.
[2] Brunner et al., M., "Requirements for Signaling Protocols", RFC
3726, April 2004.
[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", DRAFT
draft-ietf-nsis-ntlp-04.txt, October 2004.
[4] Stiemerling, M., Tschofenig, H. and C. Aoun, "NAT/Firewall NSIS
Signaling Layer Protocol (NSLP)", DRAFT
draft-ietf-nsis-nslp-natfw-04.txt, October 2004.
7.2 Informative References
[5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[6] Srisuresh, P. and E. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[7] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[8] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002.
[9] Rekhter et al, Y., "Address Allocation for Private Internets",
RFC 1918, February 1996.
Author's Address
Martin Stiemerling
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 13
EMail: stiemerling@netlab.nec.de
URI: http://www.stiemerling.org
Stiemerling Expires August 17, 2005 [Page 14]
Internet-Draft NSIS NATFW NSLP MRM February 2005
Appendix A. Acknowledgments
The author would like to thank Robert Hancock, Hannes Tschofenig, and
Cedric Aoun for the discussions.
Stiemerling Expires August 17, 2005 [Page 15]
Internet-Draft NSIS NATFW NSLP MRM February 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.
Stiemerling Expires August 17, 2005 [Page 16]