Internet DRAFT - draft-stiemerling-nsis-natfw-mrm
draft-stiemerling-nsis-natfw-mrm
NSIS Working Group M. Stiemerling
Internet-Draft NEC
Expires: January 18, 2006 July 17, 2005
Loose End Message Routing Method for NATFW NSLP
draft-stiemerling-nsis-natfw-mrm-02
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 January 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
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
locate 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 limited to the usage of locating upstream Network
Address Translator.
Stiemerling Expires January 18, 2006 [Page 1]
Internet-Draft NSIS NATFW NSLP MRM July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling the Wrong Way . . . . . . . . . . . . . . . . . . . 5
3. Loose End Message Routing Method . . . . . . . . . . . . . . . 8
4. GIMPS Message Routing Method . . . . . . . . . . . . . . . . . 11
4.1 Signaling Destination Address . . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 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 January 18, 2006 [Page 2]
Internet-Draft NSIS NATFW NSLP MRM July 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 can
be placed in parallel or NATs can 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 January 18, 2006 [Page 3]
Internet-Draft NSIS NATFW NSLP MRM July 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 the ultimately IP address of the data sender.
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 not consider firewalls.
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 and thus 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 January 18, 2006 [Page 4]
Internet-Draft NSIS NATFW NSLP MRM July 2005
2. Signaling the Wrong Way
The NATFW NSLP protocol specification defines a mechanism to locate
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).
NR+ 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 (MRI) for the REA message as follows
o the NTLP signaling destination address is set to the faked data
sender's address (Opportunistic Address, NR+),
Stiemerling Expires January 18, 2006 [Page 5]
Internet-Draft NSIS NATFW NSLP MRM July 2005
o the NTLP signaling source address is set to data receiver's
address (NI+), and
o the signaling direction is set to downstream.
Further information like port numbers, transport protocol, etc might
be set in the MRI, 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 enable data transmission, 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 January 18, 2006 [Page 6]
Internet-Draft NSIS NATFW NSLP MRM July 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
data sender.
Stiemerling Expires January 18, 2006 [Page 7]
Internet-Draft NSIS NATFW NSLP MRM July 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 the retrieval of 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
of this memo.
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 messages 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
performed as described in Section 2. NTLP and NSLP state is 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 January 18, 2006 [Page 8]
Internet-Draft NSIS NATFW NSLP MRM July 2005
Firewall
+------+
|NATFW | +-----+
|NSLP | | SDA |
|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 implementing 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 of the NTLP D-MODE
exchange 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.
Stiemerling Expires January 18, 2006 [Page 9]
Internet-Draft NSIS NATFW NSLP MRM July 2005
o TCP connections initiated from the NSIS peer located internally
(the upstream peer) are allowed to traverse towards the NSIS peer
located externally (the downstream peer). In the above figure NR
is able to initiated a TCP connection to the edge-NAT. This
assumes TCP for C-MODE.
Assuming other transport protocols than TCP and UDP will result in
even more complicated problems, since firewalls usually understand
TCP and UDP at best.
The LEMRM may require intermediate NATFW NSLP peers implementing
firewall functionality to 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.
Stiemerling Expires January 18, 2006 [Page 10]
Internet-Draft NSIS NATFW NSLP MRM July 2005
4. GIMPS Message Routing Method
This section describes the message routing method (MRM) definition
for GIMPS of the LEMRM. Section 3.3 of [3] outlines the elements
need for a MRM definition. The elements of the LEMRM are:
o Path-coupled transport is required.
o Flow-identifier as defined in Section 5.7.1.1 of [3]. The source-
address field must be set to the data sender's address (NI), if
known. Otherwise, this field must be wildcarded. The
destination-address field must be set to data receiver's address
(NR, NI+). All other fields of the flow-identifier are set
accordingly to the source or destination properties, for instance,
the destination's port number.
o Signaling direction is upstream.
o A new object containing the signaling destination address (SDA).
The signaling destination address must contain a publicly
reachable IP address and must not contain a private IP address
defined in [8].
o The QUERY encapsulation follows the same rules as defined in
Section 5.7.1.2 of [3] with the exception of using the SDA as
signaling destination. The destination address must be set to the
SDA and the source address must be set to NR's address.
4.1 Signaling Destination Address
The signaling destination address (SDA) object contains the IP
address of NR+.
Type: Signaling-Destination-Address
Length: 1 for IPv4 and 4 for IPv6.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SDA //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
Stiemerling Expires January 18, 2006 [Page 11]
Internet-Draft NSIS NATFW NSLP MRM July 2005
5. 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 January 18, 2006 [Page 12]
Internet-Draft NSIS NATFW NSLP MRM July 2005
6. Security Considerations
Security considerations are to be done.
Stiemerling Expires January 18, 2006 [Page 13]
Internet-Draft NSIS NATFW NSLP MRM July 2005
7. References
7.1 Normative References
[1] Klensin, J., "Terminology for Describing Internet Connectivity",
BCP 104, RFC 4084, May 2005.
[2] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work
in progress), May 2005.
[4] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress),
May 2005.
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 K. 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] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5,
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 January 18, 2006 [Page 14]
Internet-Draft NSIS NATFW NSLP MRM July 2005
Appendix A. Acknowledgments
The author would like to thank Robert Hancock, Hannes Tschofenig, and
Cedric Aoun for discussing the LEMRM.
Stiemerling Expires January 18, 2006 [Page 15]
Internet-Draft NSIS NATFW NSLP MRM July 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 January 18, 2006 [Page 16]
