One document matched: draft-stiemerling-nsis-natfw-mrm-00.txt
NSIS Working Group M. Stiemerling
Internet-Draft NEC
Expires: April 18, 2005 October 18, 2004
Loose End Message Routing Method for NATFW NSLP
draft-stiemerling-nsis-natfw-mrm-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 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 April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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 on the upstream data path. This
message routing method is used by NSIS nodes behind a NAT to allocate
a public reachable IP address and/or port number. The current way to
do so has been name 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.
Stiemerling Expires April 18, 2005 [Page 1]
Internet-Draft NSIS NATFW NSLP MRM October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling the Wrong Way . . . . . . . . . . . . . . . . . . . 4
3. Loose End Message Routing Method . . . . . . . . . . . . . . . 6
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Stiemerling Expires April 18, 2005 [Page 2]
Internet-Draft NSIS NATFW NSLP MRM October 2004
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 (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 to
the data sender where to send its data. Note that there may be
several NATs connecting this private network to the public network.
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
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.
The remaining document describes the current proposed way of finding
the external NAT as described in [4] in Section 2 and the new
proposed way of locating the NAT in Section 3.
The terminology used throughout this memo is aligned to the NSIS
terminology.
Stiemerling Expires April 18, 2005 [Page 3]
Internet-Draft NSIS NATFW NSLP MRM October 2004
2. Signaling the Wrong Way
In [4] Section 5.4.2 the wrong way signaling approach is mentioned.
This way of signaling fakes a data sender's address and uses the
standard downstream message routing method (MRM) defined in [3].
edge NAT
+------+
|NATFW | +----+
.'+NSLP `. ' NS*+
/ |w/ NAT| \ ,-----. +----+
+------+ .' +------+ `./ .
+----+ |NATFW | / / \
| NR |----+NSLP |+ ( Internet )
+----+ |w/ NAT| \ \ /
+------+ `. +------+ .' `.
\ |NATFW | .' `-----' `. +----+
`.+NSLP .' `.| NS +
|w/ NAT| +----+
+------+
edge NAT
Figure 1: NATFW NSLP elements
The NTLP message routing information is set NSLP receiver (NR) to
source-address, faked NSLP sender (NS*) to destination-address.
Where, NR is the NSLP receiver for the later happening CREATE request
message exchange and NS* is an arbitrary public IP address. Further
information like port numbers might be set, too. The NSLP uses the
RESERVE-EXTERNAL-ADDRESS (REA) request message. The signaling
message is sent downstream to NS*, intercepted and processed by NATFW
NSLP nodes implementing Network Address Translation (NAT). NATFW
NSLP nodes implementing Firewall functionality only, just 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 the 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
Stiemerling Expires April 18, 2005 [Page 4]
Internet-Draft NSIS NATFW NSLP MRM October 2004
the NR to indicate its reachable address.
To make data transmission work, a real NSIS sender (NS) must now send
a CREATE request message to the allocated IP address 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 NS to NR and
installing NSIS state and Firewall/NAT rules in he NATFW NSLP nodes.
Please note that the NSIS sender of this CREATE message is not
necessary the same as used by the REA message noted as NS*.
This method of finding a NAT on the data path installs several states
on NTLP and NSLP level. First of all, a state on the NTLP level is
installed from NR until the edge-NAT with final destination of NS* at
each NATFW NSLP node. This state must be maintained with repeating
REA 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 never used by any incoming CREATE request message and is to
a certain degree misleading, since the later source NS* is not the
real NSIS sender.
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 and
minimizing state and giving a clean way of finding NATs even without
knowing the NSIS sender NS.
Stiemerling Expires April 18, 2005 [Page 5]
Internet-Draft NSIS NATFW NSLP MRM October 2004
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 get a public reachable IP address/port number
without knowing where the data traffic is coming from, meaning that
NSIS sender (NS) is unknown. Therefore, signaling messages must be
sent to a faked address NS*, resulting in a loose end with respect to
the signaling since this not the actual fixed sender's address. This
faked address of the NSIS sender NS* is called signaling destination
address (SDA).
The loose end message routing method (LEMRM) requires that the NTLP
is routing messages upstream from NR to NS* and requires that NATFW
NSLP nodes implementing NAT are processing these messages only. All
other NTLP nodes just forward the message and NATFW NSLP nodes
implementing Firewall functionality do not process this message 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) 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 sender's
address, but the SDA and that LEMRM is to be used. 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. The C-MODE
connection are being established between NR and the NATFW NSLPs
implementing NAT functionality only.
A real NSIS sender (NS) 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 NS 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 April 18, 2005 [Page 6]
Internet-Draft NSIS NATFW NSLP MRM October 2004
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. The current text contained within this
document is a first cut and needs further refinement.
Stiemerling Expires April 18, 2005 [Page 7]
Internet-Draft NSIS NATFW NSLP MRM October 2004
5. Security Considerations
Security considerations are to be done.
Stiemerling Expires April 18, 2005 [Page 8]
Internet-Draft NSIS NATFW NSLP MRM October 2004
6. Open Issues
o Asymmetric routing and why it is not a problem with NATs
o Spotting the NAT with SDA equal to real NS
o Using LEMRM for locating Firewalls
Stiemerling Expires April 18, 2005 [Page 9]
Internet-Draft NSIS NATFW NSLP MRM October 2004
7. References
7.1 Normative References
[1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT
draft-ietf-nsis-fw-05.txt, October 2003.
[2] Brunner et al., M., "Requirements for Signaling Protocols",
DRAFT draft-ietf-nsis-req-09.txt, October 2003.
[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
Messaging Protocol for Signaling", DRAFT
draft-ietf-nsis-ntlp-02.txt, October 2003.
[4] Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT
draft-ietf-nsis-nslp-natfw-03.txt, July 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 April 18, 2005 [Page 10]
Internet-Draft NSIS NATFW NSLP MRM October 2004
Appendix A. Acknowledgments
The author would like to thank Robert Hancock, Hannes Tschofenig, and
Cedric Aoun for the discussions.
Stiemerling Expires April 18, 2005 [Page 11]
Internet-Draft NSIS NATFW NSLP MRM October 2004
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 (2004). 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 April 18, 2005 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-26 15:18:46 |