BEHAVE Working Group D. Stott Internet Draft R. Townsend Expires: December 31, 2005 Lucent Technologies/Bell Labs June 29, 2005 SAFENeT: Server-based Architecture For Enterprise NAT and Firewall Transversal draft-stott-behave-safenet-00.txt IPR Statement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Abstract One of the main challenges hindering the acceptance of VoIP is a standards-based solution for traversing middleboxes such as Network Address Translation (NAT) and FireWall (FW) boxes. This Internet- Draft presents SAFENeT, a protocol that is intended to operate in an enterprise environment and that allows the accommodation of real-time services by the call server, internal to the enterprise network, to communicate with the NAT/FW to enable the transversal of real-time services including VoIP. This document describes the SAFENeT architecture and protocol and shows how it overcomes the problems caused by NATs/FWs. The SAFENeT architecture also enables security features such as data confidentiality and digital integrity to be used for the VoIP traffic traversing the NAT/FW. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 The NAT Routable Address Problem . . . . . . . . . . . . . 3 1.3 The VoIP Binding Problem . . . . . . . . . . . . . . . . . 3 1.4 Security Problems Caused by NATs and FWs . . . . . . . . . 4 1.5 SAFENeT as a Solution for Real-time Services . . . . . . . 4 1.6 Organization of This Internet-Draft . . . . . . . . . . . . 5 2. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Application Layer Gateways (ALGs) . . . . . . . . . . . . . 5 2.2 Media Relays (MRs) . . . . . . . . . . . . . . . . . . . . 6 2.3 Session Border Controllers (SBCs) . . . . . . . . . . . . . 6 2.4 The MIDCOM and NSIS Solutions . . . . . . . . . . . . . . . 7 Stott & Townsend Expires – December 31, 2005 [Page 1] Internet Draft SAFENeT June 29, 2005 2.5 RTP-based Solutions . . . . . . . . . . . . . . . . . . . 7 2.6 Controllable Firewalls . . . . . . . . . . . . . . . . . . 8 3. The SAFENeT Solution - Server-based Architecture For Enterprise NAT/FW Transversal . . . . . . . . . . . . . 8 3.1 An Overview of SAFENeT . . . . . . . . . . . . . . . . . . 8 3.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Improvement Rationales . . . . . . . . . . . . . . . . . . 11 4. Examples and Details of SAFENeT . . . . . . . . . . . . . . . 13 4.1 Overview of Examples Illustrating SAFENeT . . . . . . . . . 13 4.2 Diagrams of Examples Illustrating SAFENeT . . . . . . . . . 14 4.3 Details of SAFENeT Communication Protocol (SCP) . . . . . . 21 4.4 Details of SAFENeT UA Communication Protocol (SUCP) . . . . 23 4.5 Illustrative Example of SCP and SUCP . . . . . . . . . . . 24 4.6 SAFENeT Block Caching Optimization . . . . . . . . . . . . 26 5. Discussion of Concerns . . . . . . . . . . . . . . . . . . . . 27 5.1 Don’t Mess with the Firewall . . . . . . . . . . . . . . . 27 5.2 Multiple NATs . . . . . . . . . . . . . . . . . . . . . . . 28 5.3 Complex Enterprise Topologies . . . . . . . . . . . . . . . 29 6. UNSAF Architectural Considerations . . . . . . . . . . . . . . 29 6.1 Addressing UNSAF Architectural Considerations in General . 29 6.2 Addressing Specific UNSAF Architectural Considerations Per IAB . . . . . . . . . . . . . . . . . 30 6.3 IAB Consideration Summary . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1 Normative References . . . . . . . . . . . . . . . . . . . 33 9.2 Informative References . . . . . . . . . . . . . . . . . . 33 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 35 Status of This Document . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction 1.1 Overview Firewalls (FW) are essential in today’s environment for protecting corporate and academic university networks from outside attacks and for partitioning large internal networks for security reasons such as between different organizations within these internal networks. While Network Address Translation (NAT) boxes are common for overcoming the limitations due to the scarcity of available IP addresses, they also provide privacy through isolation of internal networks (and the identity of individual users) from visibility from Stott & Townsend Expires – December 31, 2005 [Page 2] Internet Draft SAFENeT June 29, 2005 the outside. One of the challenges hindering the acceptance of VoIP is a standards-based method for traversing boxes such as NATs and FWs. "Middleboxes" are defined as in [MIDBOX] – any intermediary box performing functions apart from normal, standard functions of an IP router on the datagram path between a source host and destination host. In this Internet-Draft, middlebox refers only to NATs and FWs. 1.2 The NAT Routable Address Problem The way VoIP establishes an RTP session creates problems when a NAT is involved. The VoIP protocols assume that the initiating endpoint advertises an IP address/port number that is routable from the remote receiving host and is unmodified by any network equipment. Neither of these conditions are true when a NAT is present. The Initiating Phone’s IP address is generally a private address that is not routable (i.e., known) from outside the NAT and the transmitted port number is not the same as the one determined by the Initiating Phone because the NAT changes it. Therefore, the recipient has no way to determine a connection back to the Initiating Phone. 1.3 The VoIP Binding Problem Typical Internet applications use a simple client/server model in which the client connects to a well-known port number on the server. VoIP is different from these typical Internet applications because it uses separate signaling and bearer sessions (and may even have additional sessions (e.g., RTCP) to monitor the quality of the bearer channel). The bearer and signaling channels must be bound so that the bearer traffic goes to the correct endpoint. The signaling session uses the familiar client/server model for setting up and taking down the bearer connection but is also responsible for establishing parameters for that bearer connection. The bearer session is peer-to-peer. FWs are usually configured to (a) allow traffic to specific ports on specific servers (usually in a demilitarized zone (DMZ)), (b) permit local/private hosts behind the FW to open connections to outside servers, and (c) permit the reply via an authorized, previously made connection. When the FW opens a connection based on a request from an internal client and permits packets to flow through, it records the ports and addresses of the internal Initiating Phone to identify where to send the reply. With VoIP, the endpoints (i.e., both Initiating Phone and Receiving Phone) independently open sockets to receive bearer traffic. Because the FW does not initiate the traffic, it is unable to anticipate the traffic from a remote host (to say nothing about guaranteeing the binding of both the bearer and Stott & Townsend Expires – December 31, 2005 [Page 3] Internet Draft SAFENeT June 29, 2005 signaling channels for the VoIP session) and blocks the connection. Further, since the RFC 3550 on RTP [RTP] does not specify definitively what the endpoint must choose as port numbers (on a session–by-session basis), the FW administrator cannot know which ports to open to incoming replies (as would be done for normal Internet replies from servers) and is faced with opening nearly all UDP ports – not a good thing for security reasons. 1.4 Security Problems Caused by NATs and FWs For environments needing a secure connection (bearer channel, signaling channel or both), Application Layer Gateways (ALG), traditionally used to add intelligence to middleboxes to handle applications such as VoIP, create difficulties for encrypted traffic. Security measures such as encryption that are designed to protect signaling data from malicious network entities have the effect of hiding the data from the ALG. Since ALGs cannot look at the data being transported, they block VoIP bearer traffic. So VoIP cannot be supported in secure environments. UAs wishing to set up a secure connection to achieve data confidentiality and data integrity for signaling likewise find that the current systems do not support this functionality. Additionally, since the NAT changes the source address, the hash produced by the initiating host in a digital signature will not be confirmed by the receiving host and an error message will be generated. 1.5 SAFENeT as a Solution for Real-time Services SAFENeT is proposed as a solution for any real-time services and, specifically, for VoIP for enterprise or academic environments. This Internet-Draft distinguishes an enterprise network from the residential case in which each customer may have his or her own NAT and the ISP on the public side of the NAT owns the call server. The residential case is more likely to accept ICE because they have to trust the ISP's call server (and might as well trust the path to the STUN server the call server that the ISP also owns) and they have fewer concerns about potential "bad" behaviors from ICE, such as routing internal calls though the STUN/TURN server). In this Internet-Draft, the term VoIP is used to reflect the characteristics of real-time services including VoIP as well as other applications such as video and IM. This Internet-Draft proposes a solution optimized for VoIP. SAFENeT solves the problems of return routable addresses, binding the signaling and bearer streams, and the security issues of encryption for confidentiality (supporting hop-by-hop encryption and end-to-end encryption by the UA of S/MIME bodies) and digital signatures for Stott & Townsend Expires – December 31, 2005 [Page 4] Internet Draft SAFENeT June 29, 2005 integrity. SAFENeT does not address privacy in the Rec. X.805 [X805] sense. Note: In this Internet-Draft, the term ‘encryption and digital signatures’ and its variants is meant to convey the concepts of both encryption, i.e., data confidentiality, and digital signatures including using message digests with a hash calculation on the message contents, i.e., data integrity, as in [X805]. The intent of this version of the Internet-Draft is to see if there is any interest in pursuing the proposal and to elicit comments and discussions on problem areas that need more work. 1.6 Organization of This Internet-Draft While some solutions exist for handling NAT/FW transversal, all have drawbacks; Section 2 describes these existing solutions. Section 3 proposes the SAFENeT solution with assumptions and rationales. Section 4 gives examples and details of the SAFENeT solution. Section 5 adds further discussion of concerns of NAT/FW traversal. Section 6 covers considerations to be made when selecting a technique for traversing a NAT per the IAB draft [NAT-TRAV]. Section 7 is the section on security. Section 8 is the IANA considerations and Section 9 contains references. 2. Existing Solutions This section describes a number of technologies that have been proposed to solve the NAT/FW transversal problem. As we show, clearly none of them is suitable for enterprise VoIP systems in which a high level of security is a principal requirement. An IAB draft [NAT-TRAV] details considerations to be made when selecting a technique for traversing a NAT. From Rosenberg, [ICE], “Unfortunately, these techniques all have pros and cons which make each one optimal in some network topologies, but a poor choice in others.” 2.1 Application Layer Gateways (ALGs) ALGs are often integrated with NAT boxes. They process every packet sent through the box and inspect the packet contents for pre- programmed application-specific fields with address or port information. For example, an ALG with VoIP support might inspect the packets looking for INVITE messages. The ALG would read the INVITE message to get the UA’s address and port number (from the SDP), bind Stott & Townsend Expires – December 31, 2005 [Page 5] Internet Draft SAFENeT June 29, 2005 a new address and port number for that media stream, and rewrite the SDP with the new (public) address and port number. The key difficulties in using an ALG in this situation are (a) the need to reprogram the ALG to support each new protocol, (b) the need to address the resource intensiveness of a box in the main stream of communication, and (c) the obvious inability to support protocols using cryptography (e.g., S/MIME) if the application requires confidentiality. 2.2 Media Relays (MRs) Another class of transversal techniques is illustrated by a type of box called an MR. MRs terminate the signaling protocol on each side of the relay (similar to a media gateway but using the same protocol on both the input and output sides). The advantages of an MR are that (a) the signaling and bearer paths are forces through the same point, (b) the session is broken into 2 independent sessions such that any end-to-end requirements of the protocol do not need to apply across the box, and (c) the box serves as an endpoint for encryption, i.e., the clear text is available for reading and rewriting in the box. One example of this technique in SIP is called a back-to-back UA (B2BUA). The B2BUA box implements a complete SIP stack on each side of the B2BUA function. MRs are generally the network engineers last choice. They are clearly performance and reliability bottlenecks and they break security assumptions including end-to-end authentication. MRs limit the effectiveness of the signaling protocol because messages are no longer truly end-to-end. For example, they are likely to drop headers they do not understand, i.e., new features may require reprogramming of the MR. 2.3 Session Border Controllers (SBCs) A special case of an MR is the SBC. SBCs are gateway boxes meant to sit at the edge of a network and provide peering to various telephony networks, including video, IM, and gateways to other IP or TDM networks. They often add features such as firewalling, QoS and SLA management, and limited intrusion detection/prevention. SBCs advertise the capability of providing NAT transversal and FW pinholing. A careful study of these claims reveals that they are implementations of an ALG and, as such, have the same limitations described in the ALG section above; additionally, most SBCs are MRs and have the attributes of Section 2.2. Stott & Townsend Expires – December 31, 2005 [Page 6] Internet Draft SAFENeT June 29, 2005 2.4 The MIDCOM and NSIS Solutions The MIDCOM WG has been addressing solutions in which one trusted third party entity controls the transport layer behavior of another entity in the network to support the transport of an application. The WG has discussed protocols where a call server controls a FW to support VoIP is one such example. The WG has also developed a series of NAT transversal protocols for VoIP: Interactive Connectivity Establishment [ICE], Simple Transversal of UDP Through Network Address Translators [STUN], Traversal Using Relay NAT [TURN]. The basic architecture of these protocols is to (a) place a protocol server outside the NAT and (b) modify the client application to work with the protocol. The basic distinction between STUN and TURN is that STUN only supports UDP and TURN requires all traffic to go through the server. SAFENeT has an advantage over ICE in that it requires a smaller number of messages to determine which protocol it should use and that packet loss may cause ICE to choose non-ideal paths (e.g., hosts on the same network may end up communicating through the STUN server if the wrong packet is lost). Both STUN and TURN have security problems as stated in their respective specifications. TURN requires all packets to go through the TURN server, becoming a performance bottleneck and coming at high cost to the provider of the TURN service. [TURN] also states a reliability issue, “TURN will **almost always** provide connectivity to a client.” The NSIS WG has also been working on middlebox transversal. These protocols generally allow, but not require, a third party such as a proxy to control the middlebox to support traversal features. Future efforts in NSIS are expected to provide significant help in supporting communication between the proxy and the middlebox. Unfortunately, the recent NSIS effort is currently incomplete and does not meet the needs for enterprise quality VoIP. 2.5 RTP-based Solutions VoIP’s separation of control and bearer streams (and, in particular, negotiating the bearer port numbers from inside the control protocol) causes problems for administering FWs. FW administrators need to (a) use bulky ALGs to handle VoIP traffic or (b) essentially allow transversal for all UDP traffic. When the control messages (e.g., the SDP bodies) are encrypted or even just authenticated with an integrity check, the network administrator is placed in the bad situation of allowing insecure traffic or barring certain traffic. One Internet-Draft [expired], now expired, modified the RTP specification to allow all RTP streams to a single host to be Stott & Townsend Expires – December 31, 2005 [Page 7] Internet Draft SAFENeT June 29, 2005 multiplexed to the same port. Multiplexing RTP streams to a single well-known port substantially reduces the FW administration problem and VoIP will behave similarly to most typical Internet applications. In theory, the FW could communicate with the call server to determine which initiating and receiving hosts have valid connections open. [expired] advocates having RTP and RTPC on separate well-known ports. While they could share the same port, there are arguments against doing that, namely, that (a) the 2 streams may have different QoS parameters since those parameters are assigned on a per-connection basis and not on a per-packet basis and (b) sending both RTP and RTPC packets to the same port may cause existing RTP stack to fail. These authors do not know if this work will be continued in the future. 2.6 Controllable NAT/FWs One study [BLTJ] demonstrated a VoIP system that communicated with a specialized NAT/FW to support address and port mapping and pinholing under the control of a SIP proxy connecting two SIP phones. In this architecture, the SIP proxy used ITU-T Rec. H.248/MEGACO [H248] to communicate with the NAT/FW to request address and port mappings to open pinholes based on the MEGACO messages. The architecture solved the problem for NAT/FW transversal but not end-to-end integrity. 3. The SAFENeT Solution - Server-based Architecture For Enterprise NAT/FW Transversal 3.1 An Overview of SAFENeT SAFENeT uses a different approach in solving the NAT/FW traversal problem from those described above and is inherently simpler in operation. SAFENeT solves the NAT problem by having a SIP proxy function as a call server internal to the enterprise network. The call server communicates with the NAT/FW, negotiates an addressing mapping for the session, then communicates the result to the local/private endpoint. Optionally, it moves the transversal logic from the endpoints to a call server, one under the control of the enterprise, and opens up the possibility of allowing a secure environment. This architecture solves the NAT routable address problem, provides for appropriate binding of the two sessions needed by VoIP, and optionally allows for security measures (data confidentiality and integrity) if desired. SAFENeT requires two area of specification. The first area of specification is a standard secure interface to the NAT/FW to allow a Stott & Townsend Expires – December 31, 2005 [Page 8] Internet Draft SAFENeT June 29, 2005 trusted server (e.g., the call server) to cooperate with the NATs/FWs to establish safe bindings that allows the authorized traffic (i.e., bearer stream) to traverse the NAT/FW. The first part is nothing more than an application protocol for SIP proxies to communicate with the NAT/FW as in and drafts in NSIS similar to [NSIS-FW] and [NSLP]. The call server would obtain a NAT binding for the session and open a pinhole in the FW. In a system not needing end-to-end cryptography or digital signatures for confidentiality or integrity respectively, this SAFENeT Communication Protocol (SCP) alone is sufficient for a viable, working system; see Section 4.3 for details. SCP differs from the other work in NSIS in that it is meant to be used for VoIP and similar applications while using the procedures/protocols for controlling middleboxes (NATs and FWs) [NSLP] in allowing the transversal of application streams. It is intended to be used between a trusted server and the relevant middleboxes and covers the case in which the bearer and signaling paths are separate. It is not meant to be a replacement for the NSIS work but does allow a migration from SCP to the NSIS solution. NSIS- aware middleboxes could be configured to use SCP and the SAFENeT architecture. A second area of specification is an extension to the SIP specification to allow the User Agents (UAs) to learn about the NAT bindings thereby enabling end-to-end cryptography or digital signatures between UAs (e.g., S/MIME encoded Session Description Protocol (SDP) bodies as described in RFC 3261 [SIP]). This optional protocol is known as SUCP for SAFENeT UA Communication Protocol, the details being described in Section 4.4. Since the rationale of end- to-end cryptography is to ensure the SDPs are not read by a malicious interloper, eliminating the need to traverse network boxes that can read or modify the bit stream provides an extra bonus for security. Offering a protocol allowing digital signatures adds data integrity as a security attribute. The UA needs to generate the SDP body with the public address and port number as established by the SIP proxy. The UA must obtain this information from the call server before sending the INVITE or OK messages and before computing the hash that is sent to the remote receiver (the description in Section 4.2 below will illuminate these details better). 3.2 Assumptions This section describes some simple assumptions about the target system under which SAFENeT correctly operates. They were selected to reflect a typical enterprise or academic VoIP system with high security needs. Most medium and large business firms, including Stott & Townsend Expires – December 31, 2005 [Page 9] Internet Draft SAFENeT June 29, 2005 those in the fields of finance, medical and military are expected to be in this category. 1) The basic example of an enterprise network has NAT(s) and/or FW(s) at the boundary to the public network. See Figure 1. The FW allows incoming SIP messages between remote hosts and an internal SIP proxy. +----------+ | Call | | Server | +----------+ \ \ \ __\________ ___ ____ / \ / \\/ \ | \ // )) \\ +----------+ +----------+ // \\ +----------+ | IP | | NAT/ |____( Internet )_____| Remote | | Phone | | FW | \\ // | Phone | +----------+ +----------+ \\ ) // +----------+ \___/ \___/ Figure 1: Architecture of SAFENeT 2) The enterprise IT management controls the servers in the enterprise network and knows and controls the topology of the private network (e.g., between local/private clients and their SIP proxy(ies)). The enterprise administrator can configure the NAT/FW to permit only certain addresses and ports to be used for VoIP connections involving particular servers. While the NAT/FW may be owned by an entity other than the enterprise, the enterprise must be able to control the NAT/FW. 3) The signaling path is constrained to always pass through the call server. 4) Traditional security mechanisms by the enterprise protect the call server and middlebox from unauthorized physical or administrative access. 5) The internal call server is a trusted entity. 6) Communication between UAs in the local/private realm and their call server(s) does not traverse the boundary with the public network. Stott & Townsend Expires – December 31, 2005 [Page 10] Internet Draft SAFENeT June 29, 2005 7) The protocol proposed in this Internet-Draft is assumed to run over a secure protocol such as TLS using mutually authenticated certificates to provide authentication, confidentiality, and integrity. 8) Without loss of generality, UAs have local/private addresses that, in general, have no valid route from the remote UA. 9) The system supports hop-by-hop encryption techniques such as SIPS over TLS [SIP]. Encrypted messages can only be processed by SIP entities, i.e., SIP proxies and UAs. 10) The system supports S/MIME. UAs can choose to add (a) end-to- end message integrity on S/MIME bodies with digital signatures, (b) end-to-end encryption of S/MIME bodies, or (c) both. UAs generally use S/MIME to protect the SDP but can also protect a copy of the SIP headers. Only UAs can process cryptographic S/MIME bodies. The solution cannot require UAs to copy encrypted headers (such as media addresses) into clear text headers as this defeats the purpose of encryption and introduces potential coherency (i.e., improperly modified headers) issues. 11) NAT vendors may implement their devices however they see fit. Without loss of generality, NATs will display behavior as symmetric NAT [STUN] where the NAT selects new external address and port numbers for each new connection. 12) It is not acceptable to route traffic between local/private UAs via the public network. It is also not acceptable for a UA to send local/private addresses outside the NAT for the reasons described in the Introduction. 13) The solution may support the case where the call server applies cryptographic functions on behalf of the UA. Under this method, the call server could be signing or encrypting messages on behalf of the UA because the UA do not have the capability to do so themselves (e.g., lack of a public key certificate or lack of a software application). 3.3 Improvement Rationales There are five basic reasons for SAFENeT being a viable (and better) alternative as a solution to the NAT/FW transversal problem. 1) The call server (a trusted entity inside the enterprise FW) controls the packet routing for signaling messages. Stott & Townsend Expires – December 31, 2005 [Page 11] Internet Draft SAFENeT June 29, 2005 2) The trusted call server handles all signaling message processing. 3) No additional proxies or servers are required; a call server is presumed to exist. 4) The UA communicates only signaling/control information with a trusted SIP proxy, i.e., does not rely on an unknown trust relationship with a server in the public network. 5) There are no restrictions on types of NATs/FWs SAFENeT can support. The first advantage is a clear improvement over ICE and UNSAF-like systems. The SIP proxy is configured with the simple routing instructions (such as the subnets with voice endpoints that connect to the public network, those solely within the local/private network, default routes toward the NAT/FW, or even where IPv4/IPv6 mappings should be applied) to determine how to route the bearer streams. Recall that ICE requires complex procedures and message exchanges to (a) determine the type of NAT as input to selecting the proper procedure in the STUN server and (b) determine if alternate paths to the remote host exist. The second advantage is in contrast to ALG-based solution that require code to process the VoIP signaling messages. Besides having a maintenance advantage, the SAFENeT approach makes it easier to enforce policies because they are processed within a single entity. The same reasoning can also be applied to note that security is improved using the SAFENeT architecture. Unlike several of the alternative solutions, SAFENeT requires no additional boxes (presuming a server, such as one for session control, already exists), thereby improving performance, reliability, and security, and lowering cost. With SAFENeT, the only entities the UA communicates with are its SIP proxy (for signaling) and the remote UAs (for bearer traffic). The SIP proxy provides the binding requests on behalf of the UA, thereby minimizing the configuration setup/data needed by the UA, this latter function being applicable only for the option of end-to-end encryption. The only changes in the UA behavior are (a) code to handle the slight modification to the SIP headers and (b) the addition of the functionality for processing a response to the call server with the NAT mappings between the local/private and public addresses (described below). In contrast, with the ICE approach, the UAs in the local/private network all need to be configured with the addresses of any available STUN or TURN servers with weights to probabilistically determine how to select each. Regarding the last advantage, SAFENeT needs to make no distinctions about NAT behavior as do the alternatives as stated in [ICE]. Stott & Townsend Expires – December 31, 2005 [Page 12] Internet Draft SAFENeT June 29, 2005 The problems discussed in [NSLP] are either resolved by the SAFENeT proposal or are not relevant – save one. The issue of QoS signaling is still relevant and needs to be addressed. 4. Examples and Details of SAFENeT 4.1 Overview of Examples Illustrating SAFENeT Figure 2 illustrates a VoIP transaction with no NAT in the system; the system works fine. While the Receiving Phone is shown without a NAT/FW, there is no loss of generality; the connection protocol is simply carried out on the receiving side too. Figure 3 illustrates the well-known NAT problem of an external address that is not routable from the remote host. Figure 4 shows a basic version of the SAFENeT solution, i.e., one in which the message does not involve encryption. As noted earlier, a similar situation holds true for ALGs with encryption. Notes for the succeeding diagrams: Recall that in this Internet-Draft, the term ‘encryption and digital signatures’ and its variants are meant to convey the concepts of both encryption, i.e., data confidentiality, and digital signatures including any hash-oriented message contents, i.e., data integrity. The OpenRequest and OpenReply messages signify that the NAT has generated a binding between the local/private phone and the public address. This document distinguishes "end-to-end" encryption (e.g., S/MIME) from hop-by-hop encryption (e.g., TLS or IPSec); end-to-end encryption is hidden from the call server and middlebox whereas hop-by-hop encryption is processed by the call server, but not the middlebox The bindings in the RTP part of the diagram are shown as the attached destination address/port numbers. The public IP addresses used in all the examples of this document are shown as assigned in the TEST-NET and Benchmark Testing blocks [RFC 3330] and are just that – examples. The two different blocks were chosen to reflect that, in a real world implementation, the Initiating Phone and Receiving Phone will be on different nets. Figure 5 shows how the basic version fails if the message is digitally signed. A similar case holds for encrypted messages. Stott & Townsend Expires – December 31, 2005 [Page 13] Internet Draft SAFENeT June 29, 2005 Figure 6 shows the SAFENeT version that correctly handles both encryption and digital signatures. Figure 7 shows an incoming call and confirms the assertion made above about no loss of generality. 4.2 Diagrams of Examples Illustrating SAFENeT Figure 2 depicts a system with null NAT functionality; no problems arise. +----------+ +---------+ +---------+ +---------+ |Initiating| | Call | | NAT/FW | |Receiving| | Phone | | Server | | | | Phone | +----------+ +---------+ +---------+ +---------+ 10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4 | | | | | F1: INVITE | | | |------------------>| | | | | F2: INVITE | | | |-------------------+------------------>| | | | F3: OK | | |<------------------+-------------------| | F4: OK | | | |<------------------| | | | F5: ACK | | | |------------------>| | | | | F6: ACK | | | |-------------------+------------------>| | | RTP | | | | 10.0.1.2.:12000 | | |<------------------+-------------------+-------------------| | | RTP | | | | 198.18.2.4:5600 | | |-------------------+-------------------+------------------>| | | | | Figure 2: Example without NAT’s Address Translation Function Active Stott & Townsend Expires – December 31, 2005 [Page 14] Internet Draft SAFENeT June 29, 2005 Figure 3 shows the well-known NAT problem in which case the Initiating Phone is unaware of the NAT. The Receiver is unable to route back using the local/private address since the public Internet has no knowledge of it. ALGs can also offer a specialized solution to the problem by rewriting the SDP. Subsequently, if the message is encrypted, the ALG cannot process the message and the transaction fails. For digital signatures, the message digest is incorrect and the message is rejected by the Receiver. +----------+ +---------+ +---------+ +---------+ |Initiating| | Call | | NAT/FW | |Receiving| | Phone | | Server | | | | Phone | +----------+ +---------+ +---------+ +---------+ 10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4 | | | | | F1: INVITE | | | |------------------->| | | | | F2: INVITE | | | |-------------------+------------------>| | | | F3: OK | | |<------------------+-------------------| | F4: OK | | | |<-------------------| | | | F5: ACK | | | |------------------->| | | | | F6: ACK | | | |-------------------+------------------>| | | | RTP | | | | 10.0.1.2.:12000 | | | | ?? <-----------| | | | | Figure 3: Example showing the well-known problem with NATs for the case of encryption without any attempt to mitigate and the transaction fails Stott & Townsend Expires – December 31, 2005 [Page 15] Internet Draft SAFENeT June 29, 2005 Figure 4 show how a basic SAFENeT offers a solution in the case in which the message is neither encrypted or digitally signed. The Proxy generates an exchange with the Initiating Phone to generate, then later activate, a binding between the local/private address and the public address being transmitted. No end-to-end encryption nor digital signature is involved. +----------+ +---------+ +---------+ +---------+ |Initiating| | Call | | NAT/FW | |Receiving| | Phone | | Server | | | | Phone | +----------+ +---------+ +---------+ +---------+ 10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4 | | | | | F1: INVITE | | | |------------------>| | | | | F2: OpenRequest | | | |------------------>| | | | F3: OpenReply | | | |<------------------| | | | F4: INVITE | | | |-------------------+------------------>| | | | F5: OK | | |<------------------+-------------------| | F6: OK | | | |<------------------| | | | |F7: UpdateRequest | | | |------------------>| | | | F8: UpdateReply | | | |<------------------| | | F9: ACK | | | |------------------>| | | | | F10: ACK | | | |-------------------+------------------>| | | | RTP | | | | 192.0.2.11:2346 | | | |<------------------| | | RTP | | | | 10.0.1.2.:12000 | | |<------------------+-------------------| | | | RTP | | | | 198.18.2.4:5600 | | |-------------------+-------------------+------------------>| | | | | | | | | Figure 4: Example with NAT using a basic SAFENeT without end-to-end encryption and digital signature support (and no encryption or digital signing) giving a successful transaction Stott & Townsend Expires – December 31, 2005 [Page 16] Internet Draft SAFENeT June 29, 2005 In Figure 5, we show that encryption and digital signing add another level of complication. For case with encryption, the INVITE message cannot be processed by the FW and, for the case with digital signing, the digest in the F4: INVITE message has not been recalculated to reflect the proper public address and is therefore rejected by the Receiver. The transaction does not proceed. +----------+ +---------+ +---------+ +---------+ |Initiating| | Call | | NAT/FW | |Receiving| | Phone | | Server | | | | Phone | +----------+ +---------+ +---------+ +---------+ 10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4 | | | | | F1: INVITE | | | |------------------->| | | | | F2: OpenRequest | | | |------------------>| | | | F3: OpenRepy | | | |<------------------| | | | F4: INVITE | | | |-------------------+------------------>| | | | F5: 403 Forbidden | | |<------------------+-------------------| | F6: 403 Forbidden | | | |<-------------------| | | | | | | Figure 5: Example with NAT using the basic SAFENeT without digital signature support (but with digital signature) Stott & Townsend Expires – December 31, 2005 [Page 17] Internet Draft SAFENeT June 29, 2005 In Figure 6, we show SAFENeT with security support to allow encryption or digital signatures. The public address must be sent back to the Initiating Phone to encrypt the message including the public address for the encryption case or to generate a new hash using the public address before sending out the INVITE* message to the Receiving Phone for the digital signature case. Now the transaction can proceed successfully. When the outgoing message relies on a security certificate, the hash in the certificate must be recalculated with the proper public address replacing the local/private address. The term ‘with mappings’ is used to signify elements in that action. +----------+ +---------+ +---------+ +---------+ |Initiating| | Call | | NAT/FW | |Receiving| | Phone | | Server | | | | Phone | +----------+ +---------+ +---------+ +---------+ 10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4 | | | | | F1: INVITE | | | |------------------->| | | | | F2: OpenRequest | | | |------------------>| | | | F3: OpenReply | | | |<------------------| | | F4: 444 Response* | | | |<-------------------| | | | F5: ACK | | | |------------------->| | | | F6: INVITE** | | | |------------------->| | | | | F7: INVITE** | | | |-------------------+------------------>| | | | F8: OK | | |<------------------+-------------------| | | F9: UpdateRequest | | | |------------------>| | | | F10: UpdateReply | | | |<------------------| | | F11: OK | | | |<-------------------| | | | F12: ACK | | | |------------------->| | | | | F13: ACK | | | |-------------------+------------------>| -- Continued on next page -- Stott & Townsend Expires – December 31, 2005 [Page 18] Internet Draft SAFENeT June 29, 2005 -- From previous page -- | | | RTP/RTCP | | | | 192.0.2.11:2346/ | | | | 2347 | | | |<------------------| | | RTP/RTCP | | | | 10.0.1.2.:12000/ | | | | 12001 | | |<-------------------+-------------------| | | | RTP/RTCP | | | | 198.18.2.4:5600/ | | | | 5601 | | |--------------------+-------------------+------------------>| | | | | * with mapping information ** with proper credentials Figure 6: Example with NAT using SAFENeT with end-to-end encryption and digital signature support (and with an encrypted or digitally signed message) Stott & Townsend Expires – December 31, 2005 [Page 19] Internet Draft SAFENeT June 29, 2005 Figure 7 shows an incoming call. With similar interactions between the call server and the local/private phone as described above, the transaction can proceed successfully. +----------+ +---------+ +---------+ +----------+ |Receiving | | Call | | NAT/FW | |Initiating| | Phone | | Server | | | | Phone | +----------+ +---------+ +---------+ +----------+ 10.0.1.2 192.0.2.9 192.0.2.11 198.18.2.4 | | | | | | | F1: INVITE | | |<------------------+-------------------| | F2: INVITE | | | |<-------------------| | | | F3: OK | | | |------------------->| | | | | F4: OpenRequest | | | |------------------>| | | | F5: OpenReply | | | |<------------------| | | F6: 444 Response* | | | |<-------------------| | | | F7: OK** | | | |------------------->| | | | | | | | | F8: OK** | | | |-------------------+------------------>| | | | F9: ACK | | |<------------------+-------------------| | F10: ACK | | | |<-------------------| | | | RTP | | | | 198.18.2.4:5600 | | | |--------------------+-------------------+------------------>| | | | RTP | | | | 192.0.2.11:2346 | | | |<------------------| | | RTP | | | | 10.0.1.2.:12000 | | |<-------------------+-------------------| | | | | | * with mapping information ** with proper credentials Figure 7: Example of an incoming call using SAFENeT with encryption and digital signature support Stott & Townsend Expires – December 31, 2005 [Page 20] Internet Draft SAFENeT June 29, 2005 4.3 Details of SAFENeT Communication Protocol (SCP) SAFENeT defines a protocol (SCP) for communicating between the SIP proxy (call server) and the NAT/FW similar in functionality to that of RFC 3303 [RFC3303]. Illustrated in Figure 4, the process includes (a) the call server acting as a manager requesting a NAT mapping for the RTP stream described in the SIP SDP, (b) the NAT/FW reserving the binding and replying to the manager with the requested mapping, (c) the manager requesting the binding be enabled, (d) the RTP communication taking place, and (e) the manager closing the binding after the call completes. The protocol is assumed to run over a secure transport protocol such as TLS [TLS]. TLS is an excellent choice because proxies are already required to support it. Mutual authentication through public key certificate validation is required for the system to be secure. TLS, using mutually authenticated certificates, provides authentication, confidentiality, and integrity. These properties provided by TLS, protection against many common security threats, such as eavesdropping and masquerading. Additionally, mutual certificate authentication (with Diffie-Hellman-based session key exchanges, used in most common public-key systems) is used to prevent man-in-the-middle attacks. Access control to the SCP manager and agent is well defined and manageable because the set of managers and agents that can communicate with the SCP boxes is small. It is recommended that both the call server and the NAT/FW be configured with its peer’s public key and that it only accept connections from devices if it has that device’s public key configured. The call server is located in a DMZ. In this process the NAT/FW is an SCP agent and the call server is the SCP manager. SCP contains the basic messages for opening a session, updating session parameters, and closing the session. TLS provides the secure connection. The manager connects to the NAT/FW acting as an SCP agent once (e.g., at boot time) and reuses the same TLS connection for all sessions. Because no communication protocol currently exists to exchange these types of messages, SAFENeT defines a simple, text-based message format. The format is conceived to be easy to implement and enhance. As new protocol are developed (e.g., future NSIS protocols), this protocol can migrate to the newer one. The first SCP message from the manager to the agent is the stream header, used to inform the agent the SCP version number the manager Stott & Townsend Expires – December 31, 2005 [Page 21] Internet Draft SAFENeT June 29, 2005 is using. All subsequent messages are a single request or reply separated by a pair of CRLF as do many applications like SMTP. The manager can send any of three message types: OpenRequest, UpdateRequest, and CloseRequest. The agent can reply using OpenReply, UpdateReply, CloseReply, or ErrorMessage. The agent replies to a request with a reply message or an error message. Replies must correspond to the appropriate last request. If at any point the agent detects an error in request (such as a bad value or unsupported feature), it replies with an ErrorMessage instead of the normal reply message. The error message indicates which field caused the error, the type of error, and an optional text description of the error. The agent can also send Info messages to provide asynchronous notifications to the manager, e.g., a time-out due to inactivity. Each message follows a common format. The first line is the header indicating the message type and unique session ID. Because the agent established the ID, the OpenRequest does not specify one; the agent chooses one and includes it in the OpenReply message. A message body consisting of a sequence of request fields, follows the header. Table 1 shows the possible request fields. Most parameters can be set to 0 (zero) to indicate the value is unassigned or to –1 to indicate a wildcard. When the session is activated, the agent must verify that all the appropriate fields have been set – e.g., a NAT’s policy may require that the local/private address and port number be set as well as the remote address. The interface parameter can be used to specify a particular interface on the NAT/FW. In general, the manager needs to know *a priori* the meaning of the interface value (e.g., the NAT/FW may expect the SNMP ifIndex or some other interpretation). The manager should set the interface value to 0 (zero) as unassigned unless it knows the specific interface value. Stott & Townsend Expires – December 31, 2005 [Page 22] Internet Draft SAFENeT June 29, 2005 Table 1 – Request Field Types +-------------------------------------------------------------------+ | Request | Parameters | Description | | Type | | | |----------+---------------+----------------------------------------| | From: |address port# | The local/private address and port | | | interface | number and NAT/FW interface | | | | | | To: |address, port# | The mapped (public) address and port# | | | | | | For: |address, port# | The remote destination | | | interface | | | | | | | Proto: |IP protocol | Specific IP protocol 9E.g., UDP, TCP) | | | | | | Active: |Boolean | True to indicate activation of mapping;| | | | False – not activated | | | | | | Action: |type | FW action can be block, reject, allow,| | | | or log | +-------------------------------------------------------------------+ 4.4 Details of SAFENeT UA Communication Protocol (SUCP) Just as we need to add a protocol for the manager (call server) to the agent (NAT/FW), we also need to devise an optional communication protocol for use between the manager and the UA (agent). This section defines such a protocol. If another mechanism comes into use, these messages could be included to enhance that protocol. This part of the protocol might not be needed if the end-to-end security aspects of the protocol are not used. Using Figure 6 as an illustration, SUCP is an extension to the SIP headers as well as requiring additional SCP interactions. On an INVITE message, SUCP adds a single header specifying the local/private address and port number and the remote addresses of the media sessions (or a list of such tuples if it opens multiple sessions). Next the manager checks if the message is to traverse (a) a NAT, (b) a FW and no NAT, (c) both a FW and a NAT, or (d) neither. For (a) the call server obtains the mappings as describe in Section 4.3, communicates them to the UA, and proceeds using a modified SCP as in Figure 6. For (b), the call server requests a pinhole be opened and passes the INVITE as normal. For (c), use the combined actions for (a) and (b). For(d), the call server passes the INVITE directly to the remote UA and removes the OpenRequest. Stott & Townsend Expires – December 31, 2005 [Page 23] Internet Draft SAFENeT June 29, 2005 An example of the initial SIP header would include information with the UA address and port number: MediaMapRequest: saddr=10.0.1.2,sport=12000. The call server can determine if the session will be using a NAT. If a NAT is not involved, the call server ignores (or removes) the request and processes the message as normal. If a NAT is involved, the call server uses SCP with additional messages to communicate the binding information to the UA and proceeds similarly as in Section 4.3. The UpdateRequest/Reply messages (that are SIP messages) secure the binding from the NAT and transmits it to the UA. The UA uses this information to encrypt the SDP or recalculate the message digest. The UA will reconstruct the SDP with the public address and port numbers (the only address the remote UA sees), acknowledge the SIP message, and send the new INVITE with public address, the same Call-ID as the original INVITE, and the appropriate CSeq number: MediaMapRequest: saddr=192.0.2.11,sport=2346. The remote host will then have a routable address and any encrypted or digitally signed message can be deciphered correctly by the remote host. On teardown, the call server uses SCP to delete the binding and/or close the pinhole. There is the possibility of using policy use-cases to provide the communication between the call server and the UA as is currently being introduced in the SIPPING WG [usecase] since the knowledge and mechanism may already exist. 4.5 Illustrative Example of SCP and SUCP In a scenario for an outbound call, using encryption or digital signature, through a NAT/FW as in Figure 6, the UA sends an INVITE message (F1) to the call server (see Figures 8a-f). F1: INVITE +---------------------------------+ | MediaMapRequest: \ | | saddr=10.0.1.2,sport=12000; \ | | saddr=10.0.1.2,sport=12001 | +---------------------------------+ Figure 8a – INVITE Message Recognizing the sender is inside the NAT/FW, the call server/manager uses SCP to obtain a mapping for the UA. The manager sends an OpenRequest message (F2) to the agent (NAT) to open a session based on the Initiating Phone’s (the local UA’s) private address and port Stott & Townsend Expires – December 31, 2005 [Page 24] Internet Draft SAFENeT June 29, 2005 number and the Receiver’s (the remote UA) address. The remote UA is free to choose any ephemeral port. F2: OpenRequest +-------------------------------+ | OpenRequest | | From: 10.0.1.2 12000-12001 0 | | For: 0 0 | | Proto: UDP | | Active: False | +-------------------------------+ Figure 8b – Request to Open Message The agent then chooses a session ID and builds a mapping for the given addresses and port number and replies with an OpenReply message (F3) that establishes a session ID, 31824 in this example. F3: OpenReply +-------------------------------+ | OpenReply 31824 | | From: 10.0.1.2 12000-12001 1 | | To: 192.0.2.11 2346-2347 | | Proto: UDP | | Active: False | +-------------------------------+ Figure 8c – Reply Message The manager sends the mapped (public) address and port number to the UA (F4). F4: 444 Response +----------------------------------+ | 444 UseMediaMapping: \ | | saddr=10.0.1.2,sport=12000; \ | | maddr=192.0.2.11,mport=2346; \ | | saddr=10.0.1.2,sport=12001; \ | | maddr=192.0.2.11,mport=2347 | +----------------------------------+ Figure 8d – Mapping Information to UA Message At this point, the UA has the NAT mapping it needs to advertise the public address and port number to the remote UA as F5 F6in Figure 6 F5and the call server forwards the new INVITE to the remote UA as F6 F7using the public address and port numbers. Stott & Townsend Expires – December 31, 2005 [Page 25] Internet Draft SAFENeT June 29, 2005 Once the network accepts the call, the manager sends an UpdateRequest message (F9) to activate the binding for this session (and/or open a FW pinhole). F9: UpdateRequest +-------------------------------+ | UpdateRequest 31824 | | For: 198.18.2.4 –1 0 | | Active: True | +-------------------------------+ Figure 8e – Activate the Binding Message The agent replies with an UpdateReply as F10. F10: UpdateReply +-------------------------------+ | UpdateReply 31824 | | For: 198.18.2.4 –1 2 | | Active: True | +-------------------------------+ Figure 8f – Reply to the Activation Message After the proper OKs and ACKs, the NAT/FW is ready to accept/traverse RTP traffic between the remote UA at 192.0.2.11:2346 and mapping it to the local/private UA address/port number at 10.0.1.2:12000. Similarly, the RTCP stream uses port 2347 on the public side and 12001 on the private side. When the call is complete, the manager sees an acknowledged BYE SIP message and sends a CloseRequest with the session ID to the agent to delete the binding. 4.6 SAFENeT Block Caching Optimization The performance of SAFENeT for applications like VoIP can optionally be improved by pre-allocating NAT mappings. This allows the manager to choose the public address and port number without contacting the NAT. Thus, the SIP INVITE can complete with a single message between the manager and the agent instead of the two described in Section 4.3 and illustrated in Section 4.2. To enable this optimization, the manager needs to reserve a block of public port numbers (and addresses if appropriate) from the NAT for future mappings. The manager obtains a block of port numbers and session IDs from the agent using a new message type, ReserveBlock. The manager can specify the size of the block in the message body. The agent finds a suitable block of addresses and returns a list with the public address, port number, and session ID for each. The manager can then Stott & Townsend Expires – December 31, 2005 [Page 26] Internet Draft SAFENeT June 29, 2005 choose its own mappings from the list. It still needs to use the UpdateRequest message to activate the mappings at the NAT. The manager is contacted when the call completes. For example, if the remote UA dos not answer or redirects the call to another endpoint (i.e., call forwarding), the manager would disregard the original binding and choose a new one when the UA sends the INVITE to the next remote UA. 5. Discussion of Concerns This section discusses some issues of concern for middlebox traversal solutions. Because enterprises rely on the security of their FW, it is reasonable to be concerned that changes to the FW may have adverse effects on security. The issue of enterprises having multiple FWs is covered as well as the issue of complex enterprise topology. 5.1 Don’t Mess with the Firewall A valid question for any middlebox solution is why an administrator who is responsible for the enterprise’s network security should trust the SAFENeT solution enough to install it in his/her network. Administrators should be concerned that the solution allows applications to open *bad* holes through the FW. An example is a solution that allows middlebox-aware viruses to open backdoors through the FW to propagate or release sensitive data back through the FW; obviously unacceptable. Similarly, a solution that allows a remote host to control the access through the FW would likely result in severe problems. SAFENeT offers an architecture and protocol that allows restrictions to be placed on how the system is provisioned that address the above concerns. The SAFENeT architecture is proposed to allow only a small set of authorized hosts (e.g., the local call servers hat are often physically co-located with the agents) can access the middlebox. This restriction can be enforced by the enterprise with various key management policies, access control mechanisms, and social engineering mechanisms. For example, some administrators may statically configure the managers and agents by entering the other element’s public key manually. Others may find a public key infrastructure (PKI) system or symmetric key-based authentication system to be more effective. Vendors and administrators are also free to use host-based access control mechanisms to restrict the set of managers that can connect using SCP. The fundamental purpose of the solution is to allow VoIP traffic to traverse the middlebox but not allow any additional connections. As a point of reference, consider ALGs. These devices are generally accepted as allowable at the enterprise edge for non-encrypted VoIP. Stott & Townsend Expires – December 31, 2005 [Page 27] Internet Draft SAFENeT June 29, 2005 A key differentiator for SAFENeT over ALG is where the VoIP logic for parsing the VoIP message is processed. With ALGs, the logic must be programmed into the middlebox and must be changed to correctly deal with each newest VoIP message format and feature set. With SAFENeT, it is handled by the call server which needs only a secure communication channel to the middlebox. It can be a debatable issue whether it is better to trust a middlebox vendor’s VoIP processing code or a service provider’s VoIP code. FW vendors might not be current with the latest VoIP protocol developments but service providers might not have the most secure software engineering practices. If one must be flawed in such a way that the system is vulnerable to DoS attacks or exploitable code, better that the failure be confined to the call server instead of affecting the FW. If properly built, the agent failure mode when it detects an improperly formed SCP message should failsafe by dropping the connection to the agent. We are unaware of any ALG product that would prevent such an attacking (or zombie) host from spoofing a call session message to open a connection through the FW. This situation cannot happen with SAFENeT because the SCP messages are authenticated. Compared to other proposed solutions, SAFENeT clearly provides a more secure solution. SAFENeT does not open FW pinholes until both endpoints have acknowledged the call. Most host-based solutions (e.g., ICE and those based on NSIS solutions) open a pinhole before signaling the remote endpoint, and will do so even in the case when the endpoint refuses the call or diverts to voice mail. With other host-based solutions, any internal host is capable of opening pinholes through the FW whereas in SAFENeT only a call server can establish a connection. 5.2 Multiple NATs While SAFENeT is not optimized for multiple NATs (e.g., where traffic passes through back-to-back NATs), it is supported. The SAFENeT architecture can accommodate the case for multiple NATs such as between department boundaries with multiple NAT instantiations, each with its own manager. The manager needs to be aware of the connecting NATs and the routing between them. The trick to making this work is to issue multiple SCP commands to each involved NAT. The first set of SCP messages are to reserve a port and address from each NAT. The second set is to update each mapping with the ports from the other NAT(s). Once all the bindings have been specified, the manager can send to the endpoint the mapping from the NAT nearest to the endpoint and then specify ports to neighboring NATs along the path. Stott & Townsend Expires – December 31, 2005 [Page 28] Internet Draft SAFENeT June 29, 2005 If the manager uses the option of reserving multiple NAT port bindings ahead of time, the process is much simpler. The manager simply needs to choose ports for each involved NAT and send updates to each NAT along the path as before. 5.3 Complex Enterprise Topologies SAFENeT assumes that the manager can be configured with routing data for the enterprise. In particular, the manager must know what middleboxes are along the path from the local endpoint to the NAT/FW at the enterprise edge. As the enterprise topology becomes more complex, distributing managers throughout the network helps in scaling the problem. One difficult problem for any middlebox solution, that does not restrict the data path, is the handling of multiple potential routes. An underlying assumption is that the solution is able to predict the data path. If the network permits per-packet load sharing over two different paths with different (logically separate) NATs, it may not be possible for NATs in the two different paths to assign the same bindings because of previous assignments. Judicious choices in network architecture design may be needed to alleviate problems like these. 6. UNSAF Architectural Considerations While the authors believe SAFENeT is not an UNSAF architecture as described in RFC 3424 [UNSAF] and does not suffer the same limitations, some discussion is warranted for completeness both on how SAFENeT differs from the UNSAF architecture and on how SAFENeT addresses the architectural considerations proscribed in Section 4 of [UNSAF]. This discussion can also serve both to highlight the value of SAFENeT in solving the NAT/FW traversal of VoIP traffic while enabling a higher level of security in transactions requiring it and to note the longer term use of NATs/FWs for corporate/enterprise environments. 6.1 Addressing UNSAF Architectural Considerations in General The discussion of UNSAF considerations should start with a listing of what problems we are solving by the use of NATs/FWs at the edge of enterprise networks. The rationale behind the solutions to those problems are generally considered to be (a) relief from the limitations of the IPv4 address space, (b) keeping the topology of the enterprise network private from the outside world, (c) providing an isolation of unwanted traffic from the outside, and (d) using NAT/FW as the endpoint for secure tunnels in providing secure VPN transport across the external domain. Stott & Townsend Expires – December 31, 2005 [Page 29] Internet Draft SAFENeT June 29, 2005 The UNSAF considerations are based on two premises. One is that UNSAF solutions are short term workarounds and “MUST be considered transitional in IETF proposals, and a better architectural solution is being sought” [UNSAF]. For enterprises with the need for strict security, the authors note that while IPv6 solves reason (a), it does not hold a solution to either (b), (c), or (d). Therefore, the SAFENeT proposal may be a longer term solution to the VoIP NAT/FW traversal problem. Nonetheless, as noted in the proposal description above, this solution is simple enough that it can likely be migrated into a more general, long term solution if/when one becomes available. Secondly, the [UNSAF] document prescribes certain considerations that are addressed below. 6.2 Addressing Specific UNSAF Architectural Considerations Per IAB The IAB has mandated [UNSAF] that any protocols developed by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism document a specific set of considerations. From Section 4 of [UNSAF]: “By distinguishing these approaches as short term fixes, the IAB believes the following considerations must be explicitly addressed in any proposal: 1. Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems. Such generalizations lead to the the (sic) prolonged dependence on and usage of the supposed short term fix -- meaning that it is no longer accurate to call it "short term". 2. Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed. 3. Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition. 4. Identify requirements for longer term, sound technical solutions; contribute to the process of finding the right longer term solution. 5. Discussion of the impact of the noted practical issues with Stott & Townsend Expires – December 31, 2005 [Page 30] Internet Draft SAFENeT June 29, 2005 existing deployed NATs and experience reports.” For consideration (1), SAFENeT covers the case of VoIP (and similar applications) traversing NATs/FWs in an enterprise environment. Additionally, it covers the further cases in which encryption is used for data confidentiality and digital signatures used for data integrity. For (2), as in other cases, the problem for some may be self-healing (by use of IPv6) for some of its attributes but others may be long term issues (isolation of data from the public network, isolation of the enterprise topology from the public network) leaving SAFENeT as a long term solution. Even the long term SAFENeT solution can likely be merged into more comprehensive solutions as will be determined in the marketplace, e.g, as might be developed in NSIS. For (3), neither discovery nor security is an issue as it is with STUN because the call server is a defined part of the enterprise network, i.e., inside the NAT/FW. Every solution that works with applications and addresses/ports uses data at multiple network layers and thereby creates debugging issues – seems unavoidable for this type of protocol. On the long term issue (4) and referencing the considerations in the Internet-Draft on STUN: - the bindings for SAFENeT are explicit, - although the control is not “in-band”, the enterprise topology is known and the call server is provisioned only with appropriate addresses as described in section 4.3, thereby relieving the problem, - limiting control is not an issue since the call server resides within the private enterprise network, and - SAFENeT is simple. For (5), no assumptions have been made about NATs/FWs. Assigning the ports does not seem to be a problem. Likewise for timeouts; SCP is assumed to run over a protocol like TCP (e.g., TLS over TCP) that provides reliable delivery; the endpoint will eventually disconnect if the signaling cannot complete. 6.3 IAB Consideration Summary SAFENeT has less of an issue with the IAB considerations than other schemes. Having the call server inside the NAT/FW allows the enterprise to manage its own topology and, in fact, opens the door to allowing to better security operation. This architecture, as contrasted with others requiring a box outside the FW and as contrasted with the residential case assumed to have the call server Stott & Townsend Expires – December 31, 2005 [Page 31] Internet Draft SAFENeT June 29, 2005 outside the FW, alleviates the majority of the IAB considerations for NAT traversal. 7. Security Considerations As in STUN, attack possibility discussions can be limited to denial of service (DoS), masquerading, and eavesdropping attacks. These descriptions do not include attacks from within the enterprise from trusted sources; untrusted ones are summarily fired. Like all Internet applications, it is possible to flood the agent with spoofed packet (e.g., SYN packets for TCP). The underlying transmission protocol provides authentication. For a distributed DoS (DDoS) attack in which a remote UA with a legitimate return address distributes that address to other evil UAs all of whom call try to call in, the NAT/FW should reject all of those extra calls because it will not have a mapping with the outgoing call. If there was no original outgoing call, the attack is no different from any DDoS attack. Attempts to trick the local/private UAs by providing them with fake mapped addresses won’t work because only the call server can supply addresses via its interaction with the NAT/FW in setting up call bindings. Other varieties of attacks using fake addresses are thwarted similarly. Eavesdropping attacks are carried out using a faked address to the attacker who then passes the traffic on to the original recipient. As above SAFENeT precludes a faked address because of the isolation of the call server and its local/private connection with the NAT/FW in setting up the bindings. Other attacks rely on one primitive, namely injecting a response with a faked address. Not being able to do this in an SAFENeT environment precludes virus and Trojan horse attacks. Not running SAFENeT on general-purpose computers and using best-practices to harden the platforms is the best approach to attacks of these sorts. Public-key authentication provides a mechanism to verify each host's identity (including the DNS mapping between the host and it address). Public-key authentication also prevent Man-in-the-Middle attacks because each host authenticates the other using its respective private key, which the potential MitM cannot know. After exchanging session keys between the authenticated hosts, the session keys are used to encrypt each message and to include a data integrity check. These two mechanisms provide confidentiality, integrity and authentication. Stott & Townsend Expires – December 31, 2005 [Page 32] Internet Draft SAFENeT June 29, 2005 8. IANA Considerations A standard port over which to run SCP is TBD. 9. References 9.1 Normative References None 9.2 Informative References [MIDBOX] RFC 3234, B. Carpenter and S. Brim, “Middleboxes: Taxonomy and Issues”. [RTP] RFC 3550, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications”. [X805] ITU-T Rec. X.805, “Security architecture for systems providing end-to-end communications”. [NAT-TRAV] J. Rosenberg, draft-iab-nat-traversal-considerations-00, “Considerations for Selection of Techniques for NAT Traversal”. [ICE] J. Rosenberg, draft-ietf-mmusic-ice-04, “Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols”. [STUN] RFC 3489, J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. “Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)”. [TURN] J. Rosenberg, R. Mahy, and C. Huitema, draft-rosenberg- midcom-turn-07, “Traversal Using Relay NAT (TURN)”. [expired] J. Peterson and J.Rosenberg, draft-peterson-rosenberg-avt- rtp-ssrc-demux-00, “A Multiplexing Mechanism for Real-Time Protocol (RTP)”, July 2004. [BLTJ] P. Sijben, W. van Willigenburg, M. de Boer, and S. van der Gaast, “Middleboxes: Controllable Media Firewalls,” Bell Labs Technical Journal, vol. 7, pp.141-157, August 2002. [H248} ITU-T Rec. H.248, “Gateway control protocol”. Stott & Townsend Expires – December 31, 2005 [Page 33] Internet Draft SAFENeT June 29, 2005 [NSIS-FW] R. Hancock, G. Karagiannis, J. Loughney, and S. van den Bosch, draft-ietf-nsis-fw-07, “Next Steps in Signaling: Framework”. [NSLP] M. Stiemerling, H. Tschofenig, C. Aoun, draft-ietf-nsis-nslp- natfw-05, “NAT/Firewall NSIS Signaling Layer Protocol (NSLP)”, (Status is ‘AD is watching’). [SIP] RFC 3261, J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, “SIP: Session Initiation Protocol”. [RFC3303] RFC 3303, P. Srisuresh et al, “Middlebox Communication Architecture and Framework”. [TLS] RFC 2246, T. Dierks, C. Allen, “The TLS Protocol Version 1.0”. [usecase] V. Hilt, draft-hilt-sipping-policy-usecases-00, “Use Cases for Session-Specific Session Initiation Protocol (SIP) Session Policies”. [UNSAF] RFC 3424, L. Daigle, Ed., “IAB Considerations for Unilateral Self-Address Fixing (UNSAF), November 2002. Author's Addresses David Stott Phone: +1 973 386 3898 Room 15A-149 Email: stott@lucent.com Lucent Technologies, Bell Labs URI: 67 Whippany Road Whippany, NJ 07981 USA Rick Townsend Phone: +1 732 949 8667 Room 4C-605A Email: rltownsend@lucent.com Lucent Technologies, Bell Labs URI: 101 Crawfords Corner Road Holmdel, NJ 07733 USA Comments are solicited and should be addressed to the working group's mailing list at ietf-behave@list.sipfoundry.org and/or to the authors. Stott & Townsend Expires – December 31, 2005 [Page 34] Internet Draft SAFENeT June 29, 2005 Full Copyright Statement "Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "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." Status of This Document "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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This Internet-Draft will expire on December 31, 2005. Stott & Townsend Expires – December 31, 2005 [Page 35]