Midcom Working Group Sanjoy Sen Internet Draft Patrick Sollee Sean March Category: Standards Track Nortel Networks Expires on March 2002 September 2001 Midcom-unaware NAT/Firewall Traversal 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 Abstract Bundled session applications such as FTP, H.323, SIP and RTSP, which use a signaling/control connection to establish a data/media flow, are usually broken, en-route, by Middleboxes such as NAT. Midcom proposes to solve this problem by allowing the Middlebox to be controlled through a generalized control interface by an application-aware entity called Midcom Agent. Since ubiquitous deployment of Midcom is still a few years away, an interim solution is needed to allow applications traverse NAT and Firewalls seamlessly without the help of embedded Application Layer Gateways (ALG). In this draft, a pre-Midcom solution framework is developed. A solution for the problem of NAT/FW traversal is needed both for the signaling and media/data paths. Two key components of the proposed solution are: (1) a Signaling Proxy server on the signaling path, and (2) a Media Proxy server on the media path. The Signaling server interacts with the Media server through a control interface. Although the primary applicability of this framework is shown for real-time RTP/UDP-based SIP multimedia sessions, these concepts Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 should be generally applicable to other types of data sessions established through a control connection. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction ...................................................2 2 Conventions used in this document ..............................3 3 NAT Terminologies and Concepts .................................3 4 Problem Statement ..............................................4 5 Key Solution Requirements ......................................4 6 A Solution Framework ...........................................5 6.1 Approach ........................................................5 6.2 Signaling Path ..................................................6 6.3 Media Path: The Case for RTP (Media) Proxy ......................8 7 Advantages and Disadvantages of the Solution ..................11 8 New Requirements on SIP Client, Signaling Proxy Server and RTP Proxy.............................................................12 9 Consistency with the Midcom Framework .........................12 10 Security Considerations .......................................13 11 References ....................................................13 12 Acknowledgments ...............................................13 13 Author's Address ..............................................13 14 Intellectual Property Statement ...............................14 15 Full Copyright Statement ......................................14 1 Introduction Bundled session applications such as FTP, H.323, SIP and RTSP, which use a signaling/control connection to establish a data/media flow, are usually broken, en-route, by Middleboxes such as NAT. Midcom proposes to solve this problem by allowing the Middlebox to be controlled through a generalized control interface by an application-aware entity called Midcom Agent. Since ubiquitous development of Midcom is still a few years away, an interim solution is needed to allow applications traverse NAT and Firewalls seamlessly without the help of embedded Application Layer Gateways (ALG). In this draft, a pre-Midcom solution framework is developed. A solution for the problem of NAT/FW traversal is needed both for the signaling and media/data paths. Two key components of the proposed solution are: (1) a Signaling Proxy server on the signaling path, and (2) a Media Proxy server on the media path. The Signaling server interacts with the Media server through a control interface. Although the primary applicability of this framework is shown for real-time RTP/UDP-based multimedia sessions, these concepts are Sen Expires March 2002 [Page 2] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 generally applicable to other types of data sessions established through a control connection. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3 NAT Terminologies and Concepts The types of NAT considered in this draft fall under the Traditional NAT category as discussed in [1]: Traditional (or Outbound) NAT: In a traditional NAT, sessions are uni-directional, outbound from the private network. This is in contrast with Bi-directional NAT, which permits sessions in both inbound and outbound directions. Traditional NAT's are of two types: Basic NAT: With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. Network Address and Port Translation: NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). [1] also describes two other types of NAT's - Bi-directional NAT and Twice NAT. In [2], the Traditional NAT's have been classified as follows: Symmetric NAT: These create an address binding when routing the first packet from 'private' to 'public' address realms in the usual way, but will only allow return packets from the public host address/port to which the first packet was sent. Full Cone NAT: Unlike Symmetric NAT, they will allow return packets from any host on the public network. Needless to say that, the Symmetric NAT's offer the most excruciating constraints for media traversal. We also note that, Full Cone NAT's by themselves, without the aid of a Firewall, may not provide adequate level of security for the Enterprises. Sen Expires March 2002 [Page 3] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 4 Problem Statement As discussed in [3], bundled session applications such as FTP, H.323, SIP and RTSP, which use a control connection to establish a data/media flow are usually broken by NAT devices en-route (Note: media and data are used synonymously in this draft). The reason is as follows: these applications exchange, within control sessions, address and port parameters for the media sessions, which may be realm-specific and not valid (i.e., not reachable) outside the realm boundary. Another problem is that the media session, being established by the control session, may not be permitted through the NAT. The problem can be decomposed into two sub-components: 1) Problem of establishing and maintaining the control session through the NAT/FW 2) Problem of establishing and maintaining the associated media session(s) through the NAT/FW Let us illustrate the above set of problems using SIP. SIP carries within the message the IP address and ports describing the media streams that it controls. For example, the SDP in the SIP message body carries the IP address and port at which the endpoint wishes to receive media. If the endpoint has a private address (advertised through the SDP), then media from an external endpoint will not reach it, as the address is not globally routable. Note that, the above inconsistencies can be solved easily by allowing the usage of Application Level Gateways (ALG) in the FW/NAT's, which would make all the necessary changes in the SIP messages to ensure that the application works properly without any perceived changes (this would, for example, mean that all instances of private IP addresses occurring within the SIP message from the private endpoint to the public, will be replaced by the publicly reachable address provided by the NAT). However, this has not been a popular solution as the majority of the deployed NAT's continue to be SIP unaware. A stateful, packet-filter firewall has been (implicitly) assumed to exist along with the NAT, as this is the most commonly occurring Enterprise scenario. In the SIP examples, it is assumed that this firewall is configured to allow packets to and from the SIP and RTP Proxies. 5 Key Solution Requirements We envisage some of key requirements as follows: Sen Expires March 2002 [Page 4] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 - Any interim solution to be deployed today requires that the NAT/FW's need none or very minimal configuration changes. - Enable establishment of a bi-directional control session(s) through the NAT/FW's by ensuring proper routing of control messages. - Enable establishment of a bi-directional media session(s) through the NAT/FW's by ensuring proper routing of media packets. - Ensure robustness of both media and control sessions in the face of dynamic NAT binds and Firewall pin-holes. - Must require minimal changes in the end applications due to time-to-market reasons - Must provide low call set-up time by keeping the number of roundtrip message exchanges to a minimum. - Must be secured against all kinds of security attacks - denial of service, address spoofing etc. - A single simple solution should serve all types of NAT's and network topologies - Must be consistent with the Midcom framework The NAT's considered in this draft are Symmetric and Full Cone types [2]. 6 A Solution Framework 6.1 Approach We note that the above problems are most difficult to solve for Symmetric NAT's, and that a solution for this type of NAT automatically applies to the other types, e.g., Full Cone. We shall start with seemingly the most complex network topology, in which both the communicating entities are behind a Symmetric NAT in their respective Enterprise domains. Solutions for other topologies can be easily derived from this base solution. In all cases, the generic concept will be described first followed by an illustration of its application with SIP. There are two main components of the solution - one addressing the control/signaling path issues, and the other, the media path. The signaling path component consists of a stateful Signaling Proxy server exhibiting some distinct behavior to be discussed later. The media path component consists of a Media Proxy server. In the context of SIP and RTP, the signaling path component will be a SIP Proxy server called Back-to-Back-User-Agent (BBUA) and the media path component is an RTP Proxy, as shown in Figure 1. The signaling and media proxies interact using some control protocol, which is transparent to the end users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Provider Sen Expires March 2002 [Page 5] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 +-------+ +-------+ | SIP | | SIP | | Proxy |+ + + + + + + + +| Proxy | | X' | | Y' | | |\ | | +-------+ \ +-------+ + \+---------+ + + | | + + |RTP Proxy| + + ^ ^ ^ | |^ ^ ^ + + ^ +---------+ ^ + . . . + . . ^ . . . . . . . . . . . . . . ^ . + . . . + ^ ^ + + ^ ^ + +---------+ +---------+ ........|Symmetric|........... .........|Symmetric|........ . | NAT/FW | . . | NAT/FW | . . +---------+ . . +---------+ . . + ^ . . ^ + . . + ^ . . ^ + . . + ^ . . ^ + . . + ^ . . ^ + . . +-------+ . . +-------+ . . | SIP UA| . . | SIP UA| . . | X | . . | Y | . . +-------+ . . +-------+ . .............................. ............................ Enterprise or Enterprise or Residence Residence ++++ Control path for media ^^^^ Media path ---- Control path between Signaling and Media Proxies Figure 1. 6.2 Signaling Path The following perquisites must be met in order for the solution to work: 1. The solution described here, relies on the principle that connections from within the Enterprise are allowed out and that the corresponding responses to those connections are allowed back in (as in case of Traditional NAT's). This enables the end points inside the enterprise to maintain a connection to the Signaling server via a "keep-alive" mechanism. Sen Expires March 2002 [Page 6] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 2. All signaling messages must travel via the Signaling Proxy. The SIP Signaling Proxy server with whom the UA registered must be the one through which all incoming (outgoing) calls are routed to (from) the UA. 3. The SIP Signaling Proxy server must be one hop away from the UA. 4. The destination port of the requests at the Signaling Proxy server is the same as the source port of the corresponding responses. In the example configuration shown in Figure 1, the signaling path is established when the SIP UA's register with the corresponding Proxy/Register (Signaling server). The SIP REGISTER message contains an extension tag carried in the Proxy-Require header, indicating to the Proxy that the client is behind a NAT (Note: the client or the Proxy does not care about the type of NAT, as the same solution applies to all types). This packet is NAT-ed by the Enterprise NAT with a new source IP address and port. If the Proxy supports the extension tag, it creates an association between the IP address and port from which the packet arrived and the actual address of the user. The response to the Registration message is sent to this IP address and port (not to the Contact address in the REGISTER). Once the signaling path is established, this can be used to send subsequent requests and responses to the user using the above association stored at the Proxy, i.e., the request is sent (as above) to the address/port assigned by the NAT instead of to the actual address of the user. All requests and responses must be routed via this Signaling Proxy. All requests from the user should carry the Proxy-require header with the special tag indicating that it is behind NAT/FW. The signaling path is always kept open through the NAT using a keep- alive mechanism. This can be done using REGISTER refreshes as proposed in [2]. One disadvantage of using the REGISTER method for this purpose is it forces frequent (at least once every minute), unnecessary involvement on the part of the Registrar. In this solution, "keep-alive" is achieved by periodically sending a new lightweight SIP method from the UA to the Server designed specifically for this purpose. The new SIP method is called PING and contains the following mandatory SIP headers: From, To, Via, Proxy- require, Contact, Call-id, Cseq. The Proxy Server responds to the PING method with a 200 OK final response. The timeout values in Firewalls and NAT's are observed to be between 1 to 3 mins and the Sen Expires March 2002 [Page 7] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 "keep-alive" frequency must be higher than this. This keep-alive mechanism must continue during the call. The public IP address/port allocated by the NAT is returned to the Client in the Contact header of 200 OK sent by the Proxy server. This allows the UA to perform NAT/FW failure detection by - (a) not receiving 200 OK over a prolonged period of time, and (b) detecting that the NAT IP address has changed in a received 200 OK. The second event can serve as an indication that the UA needs to re-register with the Proxy server to maintain the signaling path open. The NAT address/port, although sent to the registered UA, is never carried in SIP messages towards the remote callee. This provides certain amount of security through IP address hiding. 6.3 Media Path: The Case for RTP (Media) Proxy RTP Proxy, as the name suggests, terminates an RTP session on one side and originates the same session on the other. The UA always sends (and receives) media to (and from) an assigned address and port of the RTP proxy. The RTP Proxy can perform NAPT function both on the source and destination address/port of packets. For a solution using an RTP Proxy to work, the requirement is that any media stream traversing the NAT from the private side (e.g., Enterprise) must always go through the RTP Proxy (and any intra-Enterprise traffic should be able to bypass the RTP Proxy). Since incoming packets are received from the same address and port as the outgoing packets are sent to, a Symmetric NAT will always allow the packets from the RTP proxy inside the Enterprise for the duration of the session. This implies that a Full Cone NAT (or any restricted version of it) will also allow flows to and from the RTP Proxy. This principle can be generalized to be applicable to any type of application session, not just RTP/RTCP sessions. The following are the prerequisites for this solution to work: 1. Any media stream that traverses the NAT from private side to the public will pass through the RTP Proxy. 2. The addresses and ports in the RTP Proxy are assigned either during the call set-up or before it. 3. The RTP Proxy should know where to send the received media. For example, if it is acting as a bridge between two private endpoints X and Y (X and Y are behind different NAT's), this implies that the Sen Expires March 2002 [Page 8] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 Proxy should be aware of the X's external address/port before (or at least, as soon as) it starts receiving media from Y, and vice-versa. 4. The send and receive ports of the media in the UA's are configured to be the same. Reverting back to our example configuration in Figure 1, let us illustrate using a call flow, how resource allocation in the RTP Proxy will take place when UA X wants to establish a SIP session with UA Y (only relevant parts of the call flow is shown). It is assumed that the signaling paths between the UA's and the Proxy are already established by the method described in Section 6.2. Please refer to Figure 2 for the address/port allocations at various devices and the call flow. Legends:- <><> : bi-directional flow ---- : signaling ==== : media px, px', py*, px*, py', py : ports PXA, NX, A, NY, PYA : IP addresses PXA NX A NY PYA +-----+ +-----+ +--------+ +-----+ +-----+ | | | | | | | | | | | px|<><><| px'|<><><>py* px*|<><>|py' |<><>|py | | | | | | | | | | | +-----+ +-----+ +--------+ +-----+ +-----+ UA X NAT Proxy RTP Proxy NAT UA Y X' | 1.INVITE | | | | | |---------->|------>| | | | | | |------->| | | | | | 2.Create | | | | | port bind | | | | |<-------| | | | | | |3.INVITE | | | | |------------------>|-------->| | | | | | | |<----------|<------|<------------------|<--------| | 5. 200 OK | | |4.200 OK | | | | | | | | |==========>|===============>| | | | | 6.RTP | |<=========|<========| | | | | 6.RTP | | | | | | | | |---------->|------>|------------------>|-------->| |7. ACK | | | | | Sen Expires March 2002 [Page 9] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 | | | | | | |<=========>|<==============>|<========>|<=======>| RTP Figure 2. 1. UA X sends a SIP INVITE message towards UA Y through the Proxy X' specifying that it wishes to receive media at (private) IP address, PXA and port, px, i.e., PXA:px. 2. Proxy X' instructs the RTP Proxy to reserve a pair of IP address/port, one representing each end of the connection. To UA Y, the remote end of the connection is perceived to be A:px*, whereas to UA X, this is perceived to be A:py*. Note 1: Due to the presence of the NAT's, the source IP address/port of the media packets from the UA's are yet unknown to the RTP Proxy. Note 2: Consecutive port binds are also created for RTCP sessions corresponding to RTP. 3. Proxy X' forwards the INVITE towards UA Y (perhaps through Proxy Y') specifying that Y should send media to the RTP Proxy at A:px* (by modifying the SDP). 4. UA Y responds with a 200 OK specifying that it wishes to receive media at (private) IP address, PYA and port, py, i.e., PYA:py. 5. When Proxy X' receives the 200 OK, it changes these IP address and port parameters in SDP specifying X should transmit media to the RTP Proxy at A:py*, and forwards the 200 OK towards UA X (Note: Proxy X' actually forwards the message to the external NAT-ed address/port of UA X). 6. When UA X receives the 200 OK, it starts transmitting media (e.g., background noise) towards the RTP Proxy. When the first of these NAT- ed RTP packets reach the RTP Proxy, the Proxy remembers the source address/port (say, NX, px') of that packet as the external representation for the media end point of UA X. Any media received from Y to X should be sent to this address/port. Similarly, when the first RTP packet is received from UA Y, the RTP Proxy notes down the source IP address/port (say, NY:py'), which will be used as the destination address to transmit media received from X to Y. 7. Finally, UA X responds with an ACK message and the call set-up is complete. Sen Expires March 2002 [Page 10] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 Note that, since all signaling is routed via the Proxy, which can determine whether both the UA's are in the same domain, all intra- Enterprise calls (behind the same NAT) can avoid the trip to the RTP Proxy. This is one of the key advantages of the Proxy mediating the address/port of the endpoints of a call. Once the media path is established through the NAT, keep-alive messages in the form of periodic RTP packets are sent to keep the connection alive when the users are in mute (i.e., when no speech packets are transmitted). There needs to be some control interaction between the SIP and the RTP Proxies to establish the end-to-end sessions. The protocol can be one of the device control protocols such as MGCP, Megaco etc. 7 Advantages and Disadvantages of the Solution Key Advantages: 1. Simple, one-size-fits-all solution for all types of traditional NAT's and Firewalls. We believe that the majority of the deployed NAT's are either Symmetric or restricted Full Cone (e.g., fronted by a Firewall), which will need an RTP Proxy or some form of Intermediary [2] based solution. 2. The RTP Proxy offers additional level of security as the only source (destination) of media to (from) the Enterprise NAT/FW. The Signaling Proxy also provides protection against "address spoofing" by IP address hiding. 3. Allows UA's behind the same Symmetric NAT bypass the RTP Proxy 4. Light weight refresh mechanism for FW/NAT pinhole/bind 5. Can provide advanced, value-added services such as media replication (used for legal intercept), media anchor/pivoting etc. Key Disadvantages: 1. Scalability of the solution heavily dependent on the Media Proxy 2. May be costly to maintain and provision Sen Expires March 2002 [Page 11] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 8 New Requirements on SIP Client, Signaling Proxy Server and RTP Proxy Client: (a) Support the proposed SIP PING method to keep open the NAT/FW pinholes in the signaling path. The client also has to transmit periodic RTP packets (in case of mute) to keep the NAT/FW pinholes open in the media path. (b) Support a new tag in the Proxy-require header to indicate to the Proxy that the client is behind a NAT. This and the PING method are the only extensions required for SIP. (c) The caller UA must start transmitting media after receiving the 200 OK from the callee. This is required to update the media address/port bindings in the RTP Proxy. For similar reasons, the callee must start transmitting media after sending the 200 OK. SIP Proxy Server: (a) Support the SIP PING method. (b) Be able to interpret the new tag in the Proxy-require header indicating presence of NAT. Maintain the association between the actual address/port of the UA and the NAT external address /port bind to properly route the requests and responses. (c) Request for and receive media ports and addresses from the RTP Proxy through a control interface. Perform required replacement of SDP parameters in SIP messages with address/port provided by the RTP Proxy. RTP Proxy: (a) Support detection of source address/port of the media packets and update its routing table. (b) Interact with Signaling Proxy server to allocate address/port binds for the media. 9 Consistency with the Midcom Framework The above solution is very much consistent with the Midcom framework [5] and can almost be seen as a precursor to Midcom. Nothing prevents us from viewing the RTP Proxy as a Middlebox, and then the above-mentioned control protocol (with suitable extensions, if Sen Expires March 2002 [Page 12] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 required) between the Signaling and RTP Proxies becomes the Midcom protocol. Since the RTP Proxy is only acting as terminating points for application sessions at the transport layer and below, the same concept can be generalized to other similar applications. 10 Security Considerations Denial of Service: The RTP Proxy does not open ports unnecessarily to allow media packets, i.e., ports remain closed unless specifically opened by the Proxy. This limits the possibility of DoS attacks. Also, since all media (except intra-Enterprise traffic which does not traverse the public Internet) flows through the Proxy, it is able to identify denial of service attacks by monitoring the actual bandwidth usage in the ports against the expected bandwidth utilization. IP Address Spoofing: All SIP signaling to and from the Enterprise must traverse a trusted SIP Proxy and will be authenticated. Only this Signaling Proxy is authorized to request opening of media ports at the RTP Proxy. The external IP address/port bind of the Enterprise NAT is NOT carried within any of the SIP messages towards the remote end. All these restrictions limit the possibility of address spoofing to a great extent. 11 References [1] "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663 [2] "NAT Friendly SIP", draft-rosenberg-sip-entfw-02.txt [3] "Protocol Complications with the IP Network Address Translator", draft-ietf-nat-protocol-complications-06.txt [4] "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis- 04.txt [5] "Midcom Architecture & Framework", Internet draft, draft-ietf- midcom-framework-03.txt (work in progress) 12 Acknowledgments The authors would like to thank Mark Watson, Cedric Aoun and Mary Barnes for their useful comments and suggestions related to this draft. 13 Author's Address Sen Expires March 2002 [Page 13] Internet Draft Midcom-unaware Firewall/NAT Traversal Sept 2001 Sanjoy Sen Nortel Networks sanjoy@nortelnetworks.com Patrick Sollee Nortel Networks pats@nortelnetworks.com Sean March Nortel Networks march@nortelnetworks.com 14 Intellectual Property Statement Nortel may have patent rights for technologies described in this draft. 15 Full Copyright Statement Copyright (C) The Internet Society (2000). 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Sen Expires March 2002 [Page 14]