NSIS Working Group C. Aoun Internet-Draft Nortel Networks Expires: January 17, 2005 H. Tschofenig Siemens M. Stiemerling M. Brunner M. Martin NEC July 19, 2004 NAT/Firewall NSLP Intra-Realm Considerations draft-aoun-nsis-nslp-natfw-intrarealm-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 January 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document discusses NAT/FW NSLP issues and solutions for cases where NATFW NSLP NEs within the same addressing realm communicate with each other. The document will serve as input to the NSIS NAT/FW NSLP document to meet these intra-realm communications' requirements. Aoun, et al. Expires January 17, 2005 [Page 1] Internet-Draft NAT/FW NSLP migration July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem statement . . . . . . . . . . . . . . . . . . . . . 5 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 6. Application Signaling Protocol Impacts . . . . . . . . . . . 15 7. NATFW NSLP required extensions . . . . . . . . . . . . . . . 16 8. Perfomance considerations . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1 Normative References . . . . . . . . . . . . . . . . . . . 24 13.2 Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 27 Aoun, et al. Expires January 17, 2005 [Page 2] Internet-Draft NAT/FW NSLP migration July 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: one (or several) global scoped address and its locally scoped address(es). The following question arises: Which address does it provide to the NSIS initiator? This document will cover the NSIS Responder address selection as well as the impact on applications and the NSIS protocol suite. The document will serve as input to the NSIS WG documents. Aoun, et al. Expires January 17, 2005 [Page 3] Internet-Draft NAT/FW NSLP migration July 2004 2. Terminology The terminology used in this document is defined in [1]. Aoun, et al. Expires January 17, 2005 [Page 4] Internet-Draft NAT/FW NSLP migration July 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 a global scoped address over a local scoped address arbitrarily may imply non-optimal routing for communication between NSIS elements hosted within the same addressing realm. For certain NAT/Firewall implementations it is not only a matter of path optimization: if a global scoped address is used to reach an internal host, the NSIS messages may get dropped due to a conflict with the anti-spoofing rules on the NAT/Firewall NE, hence no communication could be established. 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 (for example, additional delay or additional bandwidth consumption in certain parts of the network). +---------------------+ +--------------------+ | +------+ | | +------+ | | |Host A| | ,-----------. | |Host B| | | +------+ +-----+| ,-' Public `-. | +------+ | | | MB1 |+-- Internet --+ | | +-----+| `-. ,-' | | | | `-----------' | | |Network A | | Network B| +---------------------+ +--------------------+ 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: Intra-Realm Signaling Scenario Aoun, et al. Expires January 17, 2005 [Page 5] Internet-Draft NAT/FW NSLP migration July 2004 +---------------------+ +--------------------+ |+------+ | | +------+ | ||Host A|-. | ,-----------. | |Host B| | |+------+ `. +-----+| ,-' Public `-. | +------+ | |+------+ i.. MB1 |+-- Internet --+ | ||Host C|.-'' +-----+| `-. ,-' | | |+------+ | `-----------' | | | | | Network B| |Network A | +--------------------+ +---------------------+ 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: Intra-Realm Signaling Scenario 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 message (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/RESPONSE messages (defined in [1]) are exchanged to host B/A global addresses and the impact on the data path. Aoun, et al. Expires January 17, 2005 [Page 6] Internet-Draft NAT/FW NSLP migration July 2004 Host C Host A MB1 App server/proxy 10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d | | REA | | | | -------------> | | | | RESPONSE | | | | <------------- | | | | External | | | |Address=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 | | | -----------------------> | | | RESPONSE | | | <------------------------ | | | External Address= 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: Message flow for routing via the Middlebox Aoun, et al. Expires January 17, 2005 [Page 7] Internet-Draft NAT/FW NSLP migration July 2004 Host C Host A MB1 App server/proxy 10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d | | CREATE | | | | -------------> |--, | | | | | | | | | | | | | CREATE | | | | <---------------------------- |<-' | | RESPONSE | | | | ----------------------------> |--, | | | RESPONSE | | | | |<------------- |<-' | | | | | | App signaling | | | continues ... | | <==============================================> | | <================================> | |<+++++++++++++++++++++++++++++++++ | | | App data | | | | |<++++++++++++++++++ | | | | | | | | | ---- NATFW NSLP signaling ==== User Application signaling (SIP, H323, MGCP, MEGACO etc) Figure 4: NSIS signaling for routing via the Middlebox Aoun, et al. Expires January 17, 2005 [Page 8] Internet-Draft NAT/FW NSLP migration July 2004 4. Solution Approaches There are two ways to deal with this non-optimal routing of packets for intra-realm communications between NSIS entities. The NSIS Responder could either: 1. Use a local policy to decide which address to provide to the NSIS Initiator 2. Make all addresses available to the NSIS Initiator to let it decide which address to use Approach (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 knowledge about the far end host. This might not always be practical. An example of such local based address selection is the IPv6 default address selection mechanism (see [6]) 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. Approach (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 needs to decide which address to use. One possible way for the NSIS Initiator to decide which NSIS Responder address to use is to check which address the NSIS responder will reply back. This security mechanism is typically referred as return-routability check. ICE [7] discusses the usage of approach (2) for SIP User Agents (SIP UA) whereby the SIP UA will probe the far end SIP UA to see from which address it will send a response back to the probe. ICE [7] uses the STUN protocol [14] for the return-routability check. In [9] the reverse routability, provided by the STUN response, is used to check which address to respond to counter RTP Denial of Service attacks. The same reverse routability check could be achieved by the NSIS NATFW NSLP. In the context of NSIS, the NSIS protocol itself should be used as Aoun, et al. Expires January 17, 2005 [Page 9] Internet-Draft NAT/FW NSLP migration July 2004 the probing mechanism. Consequently, the NSIS Initiator will simultaneously send several NSIS messages towards the NSIS Responder, one message per provided address. Figure 5 and Figure 6 show approach (2) graphically. Host C Host A MB1 App server/proxy 10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d | | REA | | | | -------------> | | | | RESPONSE | | | | <------------- | | | |External Address| | | | 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 | | | -----------------------> | | | RESPONSE | | | <------------------------ | | | External Address=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: Message flow for optimal routing In Figure 5 Host A (same one as in Figure 2) uses a Reserve External Address (REA) message which is intercepted by the edge NAT (in this case MB1). The edge NAT responds with a RESPONSE message providing the External Address (the global scoped address) to host A. Host A, collects all available addresses where it could receive application data, and then informs its application server that it wishes to Aoun, et al. Expires January 17, 2005 [Page 10] Internet-Draft NAT/FW NSLP migration July 2004 communicate with Host C while receiving data on the global and local scoped address (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 simultaneously 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. The problem is that an NSIS host might not be able to distinguish a global scoped address from a local scoped address. To cope with that problem, the following method is proposed: The NATFW NSLP will have a NAT counter object, inserted in CREATE messages and echoed back within CREATE responses. Every time an NSIS aware NAT is traversed the NAT counter object is incremented. When the NI host receives several RESPONSE messages, it will compare the received NAT counter objects, the NR that responded with the smallest NAT count will be the NR with which the NI will continue communicating with. In Figure 6, since no NSIS aware NAT (one returned NAT counter was 0) and no Firewalls (NTLP layer [2] confirmed that there was no NATFW NSLP intermediaries) are on the path between host A and host C (when using the local scoped addresses), host A would either send a DELETE message or let the NSIS state expire on its own; the NATFW NSLP protocol is sufficiently robust to handle both. The behavior is left to implementors and network administrators, since it has performance implications. Aoun, et al. Expires January 17, 2005 [Page 11] Internet-Draft NAT/FW NSLP migration July 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 2 | | | CREATE 1 | -------------> |--, | | <------------| NAT count=0 | | | |RESPONSE1 | | |NAT count=1 | | ------------>| | | | |NAT count=0 | | | | | CREATE 2 | | | | <---------------------------- |<-' | | RESPONSE 2 | | | | ----------------------------> |--, | | | RESPONSE 2 | | | | |<------------- |<-' | | | NAT count=1 | | | App signaling | | continues ... | <==============================================> | <================================> | |+++++++++++> | | | App data | | |<+++++++++++ | | | exchanges | | | | | | ---- NATFW NSLP signaling ==== User Application signaling (SIP, H323, MGCP, MEGACO etc) Figure 6: NSIS signaling for optimal (intra realm) routing With regard to the message flow in Figure 6 we can distinguish between the following cases: o In case that the NSIS Responder and the NSIS Initiator are located within the same addressing realm, the NSIS Responder should receive a response from all the addresses to which an NSIS message was sent. The NSIS Initiator will then choose the address from which RESPONSE message was returned with the smallest NAT counter, as the destination address for messages destined to the NSIS Responder. o In case that the NSIS Responder and the NSIS Initiator are not located within the same addressing realm, the NSIS Initiator would only receive a response from the valid global scope address. In case there is another NE within the network that has the same local scoped address as the originally targeted NSIS Responder, Aoun, et al. Expires January 17, 2005 [Page 12] Internet-Draft NAT/FW NSLP migration July 2004 the wrongly targeted NSIS Responder should send back an error or discard the message (the later would be preferable), Section 5 discusses the related security implications for this behavior. This requires that the NR knows if it is the intended recipient, this knowledge could be provided by the user application which is aware of the application context requiring the establishment of an NSIS session. However this assumption is no longer valid during migration phases where a proxy operation mode is required ([1] and [10]). Aoun, et al. Expires January 17, 2005 [Page 13] Internet-Draft NAT/FW NSLP migration July 2004 5. Security Considerations Deployments having NRs with local scoped and global scoped address, are subject to the same threats as the ones discussed in [4], [5] and [3] as well as to the 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). This type of end-to-end security mechanism (irrespectively which degree of security it offers) have an impact on NSIS signaling protocol and on the application layer protocol. If the responding NE is not the application end host then the protocol operation is made more complicated since the NE would have to act on behalf of the application end host. This would be the case when the application end host does not yet support the NATFW NSLP (this is the case of the proxy mode scenario discussed in [1] and [10]). To avoid the leakage of network topology information, when the CREATE message is leaving the network the network Edge NAT or Edge Firewall supporting the NATFW NSLP will need to remove the NAT count object. Aoun, et al. Expires January 17, 2005 [Page 14] Internet-Draft NAT/FW NSLP migration July 2004 6. Application Signaling Protocol Impacts The proposed intra realm path optimization proposal requires that an NR provides several data recipient addresses within the application protocol, has obviously a certain impact on the application protocol. 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 (preferred way). Certain applications already provide the ability to advertise several recipient addresses, [8] discusses the impact to SDP [11] 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 [12] and others requiring usage of NSIS with multiple addresses for the NR.In addition [7] proposes the usage of a challenge response parameter within SDP in the context of applications using SIP, a similar approach should be used for other applications. Aoun, et al. Expires January 17, 2005 [Page 15] Internet-Draft NAT/FW NSLP migration July 2004 7. NATFW NSLP required extensions As shown in Section 4, to solve the intra-realm problem a new object is required for the NATFW NSLP, a NAT count object. It is suggested that this parameter be used in all CREATE messages ([1]). Another required change for the NATFW NSLP are more of behavioral type: None Edge-NAT NATs traversed by REA messages: when the Edge NAT responds to REA messages, these NATs will add to the RESPONSE message an External Address object. This new behavior will allow the support of several level of NATs, as shown in Figure 7, in the network while supporting the intra-realm solution (approach 2) discussed in Section 4. When the Edge NAT responds to REA messages, these NATs will add to the RESPONSE message an External Address object. This new behavior will allow the support of several level of NATs in the network, as shown in Figure 7, Figure 8 and Figure 9, while supporting the intra-realm solution (approach 2) discussed in Section 4. +-----------------------------------+ | 10/8 + | Host A`-. 192.168.2/24 + ,-----------. | 10.1.2.2 `. +-----+ +-----+ ,-'The NET `-. | i.. MB1 |+-------| MB2 +- - | Host C_.-'' +----- +-----+ `-. ,-' | 10.1.2.3 Host B + `-----------' | 192.168.2.30 + +-----------------------------------+ MB: NSIS NATFW NSLP aware NATFW 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 7: Nested NATs intra-realm communications support Aoun, et al. Expires January 17, 2005 [Page 16] Internet-Draft NAT/FW NSLP migration July 2004 Host A MB1 Host B MB2 App server/proxy 10.1.2.3 192.168.2.2 192.168.2.30 192.168.2.4 a.b.c.d | | REA | |a.b.c.e | |------------------------------------>| | |RESPONSE[ExtADD, RESPONSE[ExtADD] | | | ExtADD]-------------------- | | |<----------- ExtADD=a.b.c.e | | |ExtADD=a.b.c.e | | | |ExtADD=192.168.2.2 start-app with B| | |================================================> | | from A at: 10.1.2.3,a.b.c.e,192.168.2.2 | | | | | | | | | start-App with B | | | |<================== | | | from A at: 10.1.2.3,a.b.c.e,192.168.2.2 | | | | | | | | REA | | | | |------->| | | | RESPONSE[ExtADD] | | | +<-------| | | | |ExtADD=a.b.c.e | | | | | | | | start-App with B ACK B:a.b.c.e,192.168.2.30 | | |====================>| | | from A at: 10.1.2.3,a.b.c.e,192.168.2.2 Figure 8: Nested NATs intra-realm message sequences: REA and NR address advertisement Aoun, et al. Expires January 17, 2005 [Page 17] Internet-Draft NAT/FW NSLP migration July 2004 Host A MB1 Host B MB2 App server/proxy 10.1.2.3 192.168.2.2 192.168.2.30 192.168.2.4 a.b.c.d | CREATE1 | | |a.b.c.e | |------------>| | | | | |CREATE1[NAT count=1] | | | |------------->| | | | | RESPONSE[NAT count=1] | | | |<-------------| | | | RESPONSE[NATcount=1] | | | |<------------| | | | | | | | | | CREATE2 | | | | |------------>|CREATE2[NAT count=1] | | | | -------------------------+ | | | CREATE2[NAT count=2]| NAT count=2.2.2 | | |<----------- | | | | | | | RESPONSE[NATcount=2] | | | |<-------------| | | | RESPONSE[NATcount=2] | | | |<------------| | | | Figure 9: Nested NATs intra-realm message sequences: CREATE and RESPONSE exchanges Aoun, et al. Expires January 17, 2005 [Page 18] Internet-Draft NAT/FW NSLP migration July 2004 8. Perfomance considerations 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 that 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 (Section 5) provided by the application signaling protocol then the address selection process ends, and the NSIS protocol operations continue. Aoun, et al. Expires January 17, 2005 [Page 19] Internet-Draft NAT/FW NSLP migration July 2004 9. IANA Considerations There are no IANA considerations defined in this document. Aoun, et al. Expires January 17, 2005 [Page 20] Internet-Draft NAT/FW NSLP migration July 2004 10. 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 challenge response parameter o Where should the NSIS challenge response be done? within the NTLP or the NSLP? if done in the NSLP several messaging associations would have been established for no reasons, hence it seems more interesting that the challenge response be handled at the NTLP level. Aoun, et al. Expires January 17, 2005 [Page 21] Internet-Draft NAT/FW NSLP migration July 2004 11. Conclusion Approach (2) provides a reasonable solution to the intra-realm communication problem, while introducing a NATFW NSLP new object to be added within CREATE messages. Although a new threat is added, its mitigation is very similar to other NATFW NSLP threats discussed in [5] hence no additional extensions would be required when this solution is used. Aoun, et al. Expires January 17, 2005 [Page 22] Internet-Draft NAT/FW NSLP migration July 2004 12. Acknowledgments The idea of using a NAT count object came out of discussions with Georg Kullgren and Kenneth Sundell. Thanks to Elwyn Davies for his comments on the draft. Aoun, et al. Expires January 17, 2005 [Page 23] Internet-Draft NAT/FW NSLP migration July 2004 13. References 13.1 Normative References [1] Stiemerling, M., Martin, M., Tschofenig, H. and C. Aoun, "A NAT/ Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT draft-ietf-nsis-nslp-natfw-03.txt, July 2004. [2] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", DRAFT draft-ietf-nsis-ntlp-03.txt, November 2004. [3] Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Quality-of-Service signaling", DRAFT draft-ietf-nsis-qos-nslp-03.txt, May 2004. [4] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", DRAFT draft-ietf-nsis-threats-01.txt, January 2003. [5] Fessi, A., Brunner, M., Stiemerling, M., Thiruvengadam, S., Tschofenig, H. and C. Aoun, "Security Threats for the NAT/ Firewall NSLP", DRAFT draft-fessi-nsis-natfw-threats-01.txt, July 2004. 13.2 Informative References [6] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", draft-ietf-mmusic-ice-01 (work in progress), February 2004. [8] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for the Session Description Protocol Grouping Framework", draft-camarillo-mmusic-alt-02 (work in progress), October 2003. [9] 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. [10] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. Tschofenig, "NAT/Firewall NSLP Migration Considerations", DRAFT draft-aoun-nsis-nslp-natfw-migration-01.txt, Februar 2004. [11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Aoun, et al. Expires January 17, 2005 [Page 24] Internet-Draft NAT/FW NSLP migration July 2004 [12] ITU-T SG16, "Packet-based multimedia communications systems", ITU-T H.323, November 2000. [13] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in progress), November 2001. [14] Rosenberg et al, J., "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. Authors' Addresses Cedric Aoun Nortel Networks France EMail: cedric.aoun@nortelnetworks.com Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany Phone: EMail: Hannes.Tschofenig@siemens.com URI: 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: Aoun, et al. Expires January 17, 2005 [Page 25] Internet-Draft NAT/FW NSLP migration July 2004 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 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 January 17, 2005 [Page 26] Internet-Draft NAT/FW NSLP migration July 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. Aoun, et al. Expires January 17, 2005 [Page 27] <