NSIS Working Group C. Aoun
Internet-Draft Nortel Networks
Expires: August 9, 2004 M. Brunner
M. Stiemerling
M. Martin
NEC
H. Tschofenig
Siemens
February 9, 2004
NATFirewall NSLP Intra-realm considerations
draft-aoun-nsis-nslp-natfw-intrarealm-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 9, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document discusses NAT/FW NSLP intra-realm issues and solutions.
The document will serve as input to the NSIS NATFW NSLP document.
Aoun, et al. Expires August 9, 2004 [Page 1]
Internet-Draft NAT/FW NSLP migration February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Potential solutions to the problem . . . . . . . . . . . . . . 9
4.1 Intra realm solution protocol operation impacts . . . . . . . 12
4.2 Intra realm solution application protocols impacts . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
Normative References . . . . . . . . . . . . . . . . . . . . . 17
Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 21
Aoun, et al. Expires August 9, 2004 [Page 2]
Internet-Draft NAT/FW NSLP migration February 2004
1. Introduction
The NSIS NATFW NSLP responder provides the NSIS NATFW NSLP Initiator
with its address, in some cases the NSIS responder may have several
addresses: a (or several) global scoped address and its locally
scoped address(es). Which address does it provide to the NSIS
initiator? This document will cover the NSIS Responder address
selection as well as the impact on the applications and the NSIS
protocol suite. The document will serve as input to the NSIS WG
documents.
Aoun, et al. Expires August 9, 2004 [Page 3]
Internet-Draft NAT/FW NSLP migration February 2004
2. Terminology
The terminology used in this document is defined in [1]
Aoun, et al. Expires August 9, 2004 [Page 4]
Internet-Draft NAT/FW NSLP migration February 2004
3. Problem statement
An NSIS Element hosting an NSIS NATFW NSLP may have more than one
address, its local scoped address(es) and global scoped address(es).
A default address selection that priorities arbitrarily a global
scoped address over a local scoped address may imply none optimal
routing for communications between NSIS elements hosted within the
same addressing realm.
In Figure 1 the arbitrary selection of the global scoped address,
works properly to receive NSIS signaling from Host B. However in
deployment scenario shown in Figure 2, host A and host C end-up
communicating through their local MB1 middlebox resulting in a non
optimal data path with all its implications (additional delay,
additional bandwidth in certain parts of the network infrastructure,
etc ...).
+---------------------+ +--------------------+
| | | |
| Host A | ,-----------. | Host B |
| +-----+| ,-'The NET `-. | |
| | MB1 |+-- --+ |
| +-----+| `-. ,-' | |
| | `-----------' | |
| | | |
+---------------------+ +--------------------+
MB: Middle box (NAT or Firewall or a combination)
Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities
Figure 1
Aoun, et al. Expires August 9, 2004 [Page 5]
Internet-Draft NAT/FW NSLP migration February 2004
+---------------------+ +--------------------+
| | | |
| Host A`-. | ,-----------. | Host B |
| `. +-----+| ,-'The NET `-. | |
| i.. MB1 |+-- --+ |
| Host C_.-'' +-----+| `-. ,-' | |
| | `-----------' | |
| | | |
+---------------------+ +--------------------+
MB: Middle box (NAT or Firewall or a combination)
Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities
Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities
Figure 2
Figure 3 and Figure 4, show clearly the impact when the global scoped
address is used to signal an NE within the same addressing realm.
Figure 3 show how host A will use the Reserve External Address
(defined in [1] to get its global scoped address (i.e. the external
address), same happens to host B. Figure 4 shows how the CREATE/
CREATE ACK message (defined in [1]) are exchanged to host B/A global
addresses and the impact on the data path.
Aoun, et al. Expires August 9, 2004 [Page 6]
Internet-Draft NAT/FW NSLP migration February 2004
Host C Host A MB1 App server/proxy
10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e
| | REA | |
| | -------------> | |
| | REA ACK | |
| | <------------- | |
| | a.b.c.e | |
| | |
| | start-app with C |
| | ==============================> |
| | from A at a.b.c.e |
| |
| start-app with C | |
| <============================================= |
| from A at a.b.c.e |
| |
| REA | |
| -----------------------> | |
| REA ACK | |
| <------------------------ | |
| a.b.c.e | |
| | |
| start-app with C ACK C:a.b.c.e |
| ==========================================> |
| from A at a.b.c.e |
--- NATFW NSLP signaling
=== User Application signaling (SIP, H323, MGCP, MEGACO etc)
Figure 3
Aoun, et al. Expires August 9, 2004 [Page 7]
Internet-Draft NAT/FW NSLP migration February 2004
Host C Host A MB1 App server/proxy
10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e
| | CREATE | |
| | -------------> |--, |
| | | | |
| | | | |
| | CREATE | | |
| <---------------------------- |<-' |
| CREATE ACK | | |
| ----------------------------> |--, |
| | CREATE ACK | | |
| |<------------- |<-' |
| | | |
| App signaling | |
| continues ... |
| <==============================================> |
| <================================> |
|<+++++++++++++++++++++++++++++++\ |
| | App data | | |
| |<++++++++++++++++++ |
| | | |
| | | |
---- NATFW NSLP signaling
==== User Application signaling (SIP, H323, MGCP, MEGACO etc)
Figure 4
Aoun, et al. Expires August 9, 2004 [Page 8]
Internet-Draft NAT/FW NSLP migration February 2004
4. Potential solutions to the problem
There are two ways to deal with this non-optimal routing of packets
for intra-realm communications between NSIS entities. The NSIS
Responder should either:
1. Decide based on local decision, which address to provide to the
NI to signal it or,
2. Let the far end NSIS Initiator decide which address to select
based on the NSIS Responder's provided addresses
(1) lets the NSIS Responder decide on its own, which address to
provide based on certain hints, which may not be the most optimal
decision since the NSIS Responder may not have sufficient knowledge
about the NSIS Initiator at the time of delivering its address via
user applications. In most cases local decision for address selection
requires to know about the far end host, which is not always
practical.
An example of such local based address selection is the IPv6 default
address selection mechanism ([2]) where an IPv6 (or IPv6/v4) node has
to select which source and destination address to pick in order to
communicate with a far end node. The mechanism relies on receiving
input from the local resolver (DNS client or local hosts file) about
the far end node. In the context of multimedia applications (and
probably others as well), this address selection mechanism will not
be sufficient since the far end application device is not necessarily
known (the resolver client may return the address(es) of the
application signaling and not the addresses of the actual application
data flow recipient). Hence it can not decide successfully in all
cases which address to provide to the NSIS Initiator.
(2) is more efficient as it requires the NSIS Responder to provide
all its addresses (local scoped and global scoped ones) to the NSIS
Initiator. The NSIS Initiator will need to decide on which address to
signal the NSIS Responder among all the provided ones. One possible
way for the NSIS Initiator to decide from which NSIS Responder
address to use is to check on which address the NSIS responder will
reply back. An existing proposal [3] discusses the usage of (2) for
SIP User Agents (SIP UA), the SIP UA will probe the far end SIP UA to
see from which address it will response back. In [3], the STUN
protocol [7] is used to check the responsiveness of the far end host.
In [6] the reverse routability, provided by the STUN response, is
used to check which address to respond to counters RTP DOS attacks.
The same reverse routability could be achieved by the NSIS NATFW
NSLP.
Aoun, et al. Expires August 9, 2004 [Page 9]
Internet-Draft NAT/FW NSLP migration February 2004
In the context of NSIS, the NSIS protocol itself should be used as
the probing mechanism. Consequently the NSIS Initiator will send
simultaneously several NSIS messages towards the NSIS Responder, one
message per provided address. Figure 5 and Figure 6 provide a good
view of method (2).
Host C Host A MB1 App server/proxy
10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e
| | REA | |
| | -------------> | |
| | REA ACK | |
| | <------------- | |
| | a.b.c.e | |
| | |
| | start-app with C |
| | ==============================> |
| | from A at 10.1.2.2,a.b.c.e |
| |
| start-app with C | |
| <============================================= |
| from A at 10.1.2.2,a.b.c.e |
| |
| REA | |
| -----------------------> | |
| REA ACK | |
| <------------------------ | |
| a.b.c.e | |
| | |
| start-app with C ACK C:10.1.2.3,a.b.c.e |
| ==========================================> |
| from A at 10.1.2.2,a.b.c.e |
' ' '
---- NATFW NSLP signaling
==== User Application signaling (SIP, H323, MGCP, MEGACO etc)
Figure 5
In Figure 5 Host A (same one as in Figure 2) a Reserve External
Address (REA) message which is intercepted by the edge NAT (in this
case MB1). The edge NAT responds with a REA ACK message providing the
External Address (the global scoped address) to host A. Once host A
has collected all the addresses where it could receive application
data it informs its Application server about the remote application
Aoun, et al. Expires August 9, 2004 [Page 10]
Internet-Draft NAT/FW NSLP migration February 2004
party as well as host A's data recipients addresses (and ports),
10.1.2.2 and a.b.c.e. The same will happen with Host C, and Host C
will be able to respond with the application protocol to Host A about
its data recipient addresses (local and global scoped ones). Figure 6
shows how the CREATE messages are simulatenously sent by A to all the
returned addresses for C. Host A receives both CREATE ACKs, the local
scoped address will therefore be considered as the address to use to
send NSIS NATFW messages to C. Since no NSIS aware NAT and Firewalls
are on the path between host A and host C (when using local scoped
addresses), host A would either send a DELETE message or let the NSIS
state expire on its own.
Host C Host A MB1 App server/proxy
10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e
| | CREATE 2 | |
| CREATE 1 | -------------> |--, |
| <------------| | | |
| CREATE ACK 1 | | | |
| ------------>| CREATE 2 | | |
| <---------------------------- |<-' |
| CREATE ACK 2| | |
| ----------------------------> |--, |
| | CREATE ACK 2 | | |
| |<------------- |<-' |
| | |
| App signaling |
| continues ... |
<==============================================> |
<================================> |
|+++++++++++> | |
| App data | |
|<+++++++++++ | |
| exchanges | |
| | |
|
---- NATFW NSLP signaling
==== User Application signaling (SIP, H323, MGCP, MEGACO etc)
Figure 6
The following occur during the process:
Aoun, et al. Expires August 9, 2004 [Page 11]
Internet-Draft NAT/FW NSLP migration February 2004
o In case the NSIS Responder and Initiator are located within the
same addressing realm, the NSIS Responder should receive a
response from all the addresses to which it has sent NSIS
messages. The NSIS Initiator will then choose the local scoped
address as the destination address for messages destined to the
NSIS Responder.
o In case the NSIS Responder and Initiator are not located within
the same addressing realm, the NSIS Initiator would only receive a
response from the valid global scope address. In event that there
is another NE within the network that has the same local scoped
address as the originally targeted NSIS Responder, the wrongly
targeted NSIS Responder should send back an error or discard the
message (the later would be preferable).
4.1 Intra realm solution protocol operation impacts
As opposed to the normal NSIS mode of operation, an NI that has
already a security association with the neighboring NE on the path to
a specific NR would need to verify that the target local scoped NR
address is the same as the one already cached in its NSIS neighbor
table cache (association of Next hop NE with the target NR
table).This would be required to avoid any confusion with an NSIS
node that could be hosted within the same addressing realm and that
would have the same local scoped address.
There is a potential threat where a malicious NE with the same local
scoped address as the target NR respond back positively to the NSIS
message and consequently hijack the data flow. This threat could be
counter-measured by requiring the NR to respond back with a challenge
response information communicated by the application signaling
(assuming that the application was secured).
The procedure requiring an NSIS Initiator to send NSIS messages to
several NR addresses, requires that the NI sends his NSIS messages at
the same time to avoid impacting real-time sensitive applications. In
case the response to the message sent to the global scoped is
received first, it could potentially be used as a hint that no
response will be received from the NR's local scoped address. Hence
there is no point to continue to delay the address selection process
and proceed with the NSIS protocol operations. This assumption may
not be always applicable depending on the network topology and
network load at the moment of the protocol message exchanges. In case
the first response is received from a local scoped address and has
succefuly provided the challenge response maerial provided by the
application signaling protocol then the address selection process
ends, and the NSIS protocol operations continue.
Aoun, et al. Expires August 9, 2004 [Page 12]
Internet-Draft NAT/FW NSLP migration February 2004
4.2 Intra realm solution application protocols impacts
The proposed intra realm path optimization proposal requiring an NR
to provide several data recipient addresses within the application
protocol, has obviously a certain impact on the application protocol.
[5] discusses the impact to SDP [8] and should be used by all the
application protocols using SDP. A similar approach should be
followed by other protocols, not using SDP, including H.323 [9] and
others requiring usage of NSIS with multiple addresses for the NR. In
addition the application signaling needs to provide a challenge
response allowing the NR to respond back properly. This information
either need to be added to the application protocols or existing
protocol fields need to be used (prefered way).
Aoun, et al. Expires August 9, 2004 [Page 13]
Internet-Draft NAT/FW NSLP migration February 2004
5. Security Considerations
The challenge response approach helps in checking if the responding
NR is the correct one, however the method has an issue in case the
responding NR is not the end application host (this would be the case
when the application end host does not yet support the NATFW NSLP).
External means to the NSIS protocol suite need to ensure that the
last NSIS hop responding on behalf on the application endpoint
provide the challenge response information.
Aoun, et al. Expires August 9, 2004 [Page 14]
Internet-Draft NAT/FW NSLP migration February 2004
6. IANA Considerations
There are no IANA considerations defined in this document.
Aoun, et al. Expires August 9, 2004 [Page 15]
Internet-Draft NAT/FW NSLP migration February 2004
7. Open issues
o Get agreement on solving the problem and its associated security
issue, is the challenge response sufficient?.
o Get feedback on which parameter is used within certain application
protocols (SIP, MEGACO, MGCP, H323) as the response parameter
Aoun, et al. Expires August 9, 2004 [Page 16]
Internet-Draft NAT/FW NSLP migration February 2004
Normative References
[1] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H.,
Schulzrinne, H. and C. Aoun, "A NAT/Firewall NSIS Signaling
Layer Protocol (NSLP)", DRAFT draft-ietf-nsis-nslp-natfw-00.txt,
October 2003.
Aoun, et al. Expires August 9, 2004 [Page 17]
Internet-Draft NAT/FW NSLP migration February 2004
Informative References
[2] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
the Session Initiation Protocol (SIP)", DRAFT
draft-rosenberg-sipping-ice-01.txt, June 2003.
[4] A. Huttunen et all, A., "UDP Encapsulation of IPsec Packets",
DRAFT draft-camarillo-mmusic-alt-01.txt, Jan 2003.
[5] Camarillo, J. and J. Rosenberg, "The Alternative Semantics for
the Session Description Protocol Grouping Framework", DRAFT
draft-camarillo-mmusic-alt-01.txt, June 2003.
[6] Rosenberg, J., "The Real Time Transport Protocol (RTP) Denial
of Service (Dos) Attack and its Prevention", DRAFT
draft-camarillo-mmusic-alt-01.txt, June 2003.
[7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[9] ITU-T SG16, "Packet-based multimedia communications systems",
ITU-T H.323, November 2000.
[10] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for
SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in
progress), November 2001.
[11] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-01 (work in progress), March 2003.
[12] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements", RFC
3304, August 2002, <reference.RFC.3304.xml>.
[13] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
Set-up with Media Authorization", RFC 3521, April 2003,
<reference.RFC.3521.xml>.
[14] Katz, D., "IP Router Alert Option", RFC 2113, February 1997,
<reference.RFC.2113.xml>.
Aoun, et al. Expires August 9, 2004 [Page 18]
Internet-Draft NAT/FW NSLP migration February 2004
Authors' Addresses
Cedric Aoun
Nortel Networks
France
EMail: cedric.aoun@nortelnetworks.com
Marcus Brunner
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 29
EMail: brunner@ccrle.nec.de
URI: http://www.brubers.org/marcus
Martin Stiemerling
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 13
EMail: stiemerling@ccrle.nec.de
URI:
Miquel Martin
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 16
EMail: miquel.martin@ccrle.nec.de
URI:
Aoun, et al. Expires August 9, 2004 [Page 19]
Internet-Draft NAT/FW NSLP migration February 2004
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
Munich 81739
Germany
Phone:
EMail: Hannes.Tschofenig@siemens.com
URI:
Aoun, et al. Expires August 9, 2004 [Page 20]
Internet-Draft NAT/FW NSLP migration February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Aoun, et al. Expires August 9, 2004 [Page 21]
Internet-Draft NAT/FW NSLP migration February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Aoun, et al. Expires August 9, 2004 [Page 22]