Internet Engineering Task Force MidCom WG Internet Draft S. Davies draft-davies-fw-nat-traversal-01.txt S. Read October 12, 2001 B. A. Scott Expires: April 2002 P. Cordell Ridgeway Systems & Software Traversal of non-Protocol Aware Firewalls & NATS 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 We present a method that enables real-time session-oriented protocols, such as SIP, H.323, Megaco/H.248 and MGCP, to traverse through enterprise and residential firewalls and NATs. The method requires no protocol awareness in the firewall or NAT device and it is transparent to the endpoint. The method benefits from being protocol agnostic - one method may be used for all protocols. Profiles for SIP are presented here as examples. This is a revision to an earlier draft. The main change in this draft is to move the intelligent part of the solution into the private network so that it is protected by the firewall. The details of the various signalling flows have been modified to accommodate this change. Davies, Read, Scott, Cordell [Page 1] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 0. Changes since Last Version For those that are familiar with the contents of the previous draft, the main change in this version is to swap the locations of the Proxy Server and Proxy Interface Agent. Thus the intelligent Proxy Server function that was located in the public network is now located in the private network, and the dumb Proxy Interface Agent has been moved out of the private network into the public network. The main benefit of this change is that it obviates the need for a trust relationship with the 'provider'. In the former version, the security of the solution relied on the efforts of the provider of the 'service'. In this version, the security of the solution remains with the users of the service, i.e. the enterprise, SOHO, or home user. The disadvantage of this version compared with the former is that the enterprise has a separate client solution for each protocol it wants to use and any protocol changes result in upgrades to many client systems. In the former version, the client component was protocol agnostic allowing a single system to support multiple applications and any changes to the protocol required only the server to be updated. In all other respects, this version supports similar deployment scenarios. The second change is a change in philosophy rather than a specific change in how the solution operates. It has been observed that the solution is not specific to VoIP and multimedia over IP, but rather a firewall / NAT traversal solution for a particular class of applications - proxiable applications that contain multiple, associated flows. To do this the solution involves the introduction of some additional devices. Because the solution accommodates a generic class of applications, we no longer look upon these additional components as augmenting the application installation, but augmenting the firewall / NAT installation so that it may accommodate this class of application. This is discussed further below. In accordance with these changes, what was previously known as the Proxy Server is now called the Application Proxy, and the Proxy Interface Agent is now called the Proxy Extension Agent (PEA). The result is that in this version the client component is referred to as the Application Proxy (AP), and the server component is referred to as the Proxy Extension Agent. 1. Abbreviations MoIP Multimedia over IP VoIP Voice over IP 2. Introduction Davies, Read, Scott, Cordell [Page 2] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Much is now understood, and been written [1], [2], [3], [4] about the problems caused by firewalls and NATs for real-time session-oriented protocols. Three classes of solution seem to be emerging. The first solution is to embed the firewall and NAT devices with ALGs (application level gateway). The second solution, as is being explored within the MidCom architecture, is to define a new control protocol to enable another device (typically a signalling entity) to control intermediary firewalls or NATs. These two solutions, ALGs and MidCom, require upgrades to firewall and NAT devices and is therefore only appropriate to deployments where this is possible. The third solution is to 'traverse' firewalls and NATs. This type of solution seeks to augment existing firewall and NAT behaviour by the addition of extra components to the overall firewall and NAT installation in order to allow the protocols securely through existing firewall and NAT functions. This solution is necessary for deployments where it is undesirable or impossible to upgrade deployed firewall and NAT devices with ALGs or a new control protocol. The challenges for this type of solution is not to compromise security while at the same time meeting the real-time characteristics of the application - the delivery of voice and video over IP. This draft presents an architecture and method for the traversal of firewalls and NATs for real-time session-oriented protocols such as SIP and H.323. 3. Problems Introduced by Firewalls and NATs The problems caused by firewalls and NAT devices are summarised as follows: With regard to firewalls, in addition to the TCP connection needed for the call-signalling channel, an H.323 call typically requires an additional TCP connection for H.245 signalling. There is no well-known port associated with the H.245 channel and consequently it is not possible to configure a sufficiently stringent static rule that allows such a channel to pass through a firewall while at the same time blocking other undesired TCP connections. Similarly, all current VoIP/MoIP protocols use RTP for media transport, which is UDP based. Again there are no fixed ports associated with this protocol and it is thus impossible to define static rules that can allow RTP media through a firewall without also allowing through data from other undesired protocols. NAT and NAPT also introduce problems when deploying MoIP systems. The behaviour of a NAT/NAPT is to open up a bi-directional path when a packet is sent from the private network to the shared network. But Davies, Read, Scott, Cordell [Page 3] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 they will not allow packets from the shared network sent to the private network to open such a path. The path is usually closed after a period of inactivity. When the NAPT creates a new path it will allocate an IP address and port from a pool of resources available to the NAPT. These characteristics are problematic when calls need to be made from the shared network into the private network. Additionally, the NAPT function effectively scrambles the source and destination addresses used for packets and without special processing by the NAPT (or some associated function) these values will not correspond with the values used in the control connections. The result is that the various MoIP entities are unable to associate the RTP sessions with the correct call. 4. Options for Firewalls and NATs in an MoIP Environment Both NATs and firewalls can be made MoIP protocol aware. However, there may be a number of problems with adopting this strategy. For example, your existing firewall vendor may not support the protocols that you wish to deploy. Alternatively the functionality that your firewall vendor supports for a particular protocol might be limited, and restrict what you can do with the protocol. Indeed, in a typical firewall installation connections need to pass through two dissimilar firewalls. This further restricts the options that the combined firewall configuration is likely to support. As security is a sensitive issue, enterprises are unlikely to replace their firewall with one that supports MoIP, especially if MoIP is only being deployed on an experimental basis. Also, one of the firewalls involved in the configuration may be owned and operated by the ISP, and as such the enterprise has even less control. Even if suitable firewalls can be deployed, MoIP awareness incurs additional processing burden for the firewalls and NATs to keep track of the state of the protocol. Such processing may mean that the firewall becomes vulnerable to overload attacks, or it has to have such powerful processing capabilities that it is not economic to deploy. Alternatively, both the firewall and NAT may have to refer to a remote ALG function, incurring additional complexity and delay in the system. Another option is to deploy proxy systems that by-pass the NAT and firewall installation. That is, one interface is connected directly to the private network, and another interface is connected directly to the shared network. This arrangement provides the attacker with another route of attack. It also means that the configuration to protect the private network is spread across a number of devices increasing the likelihood of mis-configuration. It may also require additional IP addresses to be allocated in order to support the device. And it may require a separate network connection between the enterprise and carrier. This latter restriction removes one of the benefits that switching to VoIP technology enables. Even if such solutions were acceptable, the pin-holes that a firewall has to open up for media need to accept UDP data from all remote IP Davies, Read, Scott, Cordell [Page 4] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 addresses and ports. This is due to the fact that current MoIP signalling does not include the source from which the UDP packets will arrive. The resultant rules that 'protect' internal MoIP terminals are thus no more stringent than would be used to protect a public web server, a device that would normally be a bastion host and/or sacrificial. The solution described in this document uses a combination of techniques including tunnels and probe packets to enable operation through firewall and NAT functions to facilitate the deployment of MoIP. The system does not require firewalls and NATs to be upgraded, and allows them to continue to be the primary security point. The firewalls and NATs are not burdened with additional application specific processing and can therefore continue to provide protection to the private network in the light of things like flood attacks. Additionally, it allows MoIP to be deployed with minimal change to the existing set of security rules, with the result that administrators can have confidence in the resultant solution. The implementation scales down as well as up. In the simplest of cases, the Application Proxy may be software executing on an endpoint such as a PC. In large deployments, the Application Proxy and Proxy Extension Agent may be dedicated equipment or logic executing in high performance routers, for example. The solution can, therefore, be scaled over time according to demand without requiring key equipment (such as firewalls and NATs) to be repeatedly swapped out as MoIP demand grows. As such, in addition to being a preferable solution in its own right, it can be a key enabler to enterprises that wish to have an experimental phase before moving to a full-scale deployment of MoIP. 5. Philosophy Figure 1 shows a typical enterprise firewall and NAT installation for connecting an enterprise to a public network. There are many variants of this in use, but most can be mapped to this configuration to a greater or lesser extent. Davies, Read, Scott, Cordell [Page 5] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 ( ) ( Shared ) ( Network ) ( ) ( ) | .................................|..................................... : Boundary of Firewall / ___|__ : : NAT Installation | | : : | NAPT | : : |______| : : | | : : | FW1 | : : |______| : : | DMZ : : |-------------------------- : : | ____|____ : : | | | : : | | Bastion | : : ____|____ | Host | : : | | |_________| : : | FW2 | : : | [+NAPT] | : : |_________| : : | : .................................|..................................... | Private Network | --------------------------------------------------------------------- ____|____ ____|____ ____|____ ____|____ | | | | | | | | | Private | | Private | | Private | | Private | | Host | | Host | | Host | | Host | |_________| |_________| |_________| |_________| Figure 1 - Typical Enterprise Firewall / NAT Installation In the installation shown in Figure 1, it should be observed that a distinction has been made between a firewall and a firewall installation. For the purposes of this document the firewall installation is made up of a number of components, including stand-alone devices that implement firewall (typically packet filtering) and NAT functions. The distinction between a firewall and a firewall installation is important for the rest of this document. The set of filtering rules implemented by firewall FW1 are typically minimally restrictive, and its main function is to prevent packets from the public network spoofing that they are from the private network and vice versa. Firewall FW2 is the main firewall where application specific filtering rules are applied. It may also perform a NAPT function, either as a substitute to the NAPT near FW1, Davies, Read, Scott, Cordell [Page 6] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 or in addition to it. The bastion host in the diagram is shown mainly for illustrative purposes. Such a host may be an SMTP proxy, or be a web server. Davies, Read, Scott, Cordell [Page 7] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 ( ) ( Shared ) ( Network ) ( ) ( ) | ....................|........................ :Service | _________ : :Provider | | | : :Boundary |----------| PEA | : : | |_________| : : | : :...................|.......................: ____|____ | In | | Network | | NATs | |_________| .................................|..................................... : Boundary of Firewall / ___|__ : : NAT Installation | | : : | NAPT | : : |______| : : | | : : | FW1 | : : |______| : : | DMZ : : |-------------------------------- : : | ____|____ : : ____|____ | | : : | | | Bastion | : : | FW2 | | Host | : : | [+NAPT] | |_________| : : |_________| _____________ : : | | | : : |---------| Application | : : | | Proxy | : : | |_____________| : .................................|..................................... | Private Network | --------------------------------------------------------------------- ____|____ ____|____ ____|____ ____|____ | | | | | | | | | Private | | Private | | Private | | Private | | Host | | Host | | Host | | Host | |_________| |_________| |_________| |_________| Figure 2 - Firewall / NAT Installation Augmented with Application Proxy The need to upgrade the firewall and NAT components with ALGs can be Davies, Read, Scott, Cordell [Page 8] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 removed by providing an Application Proxy that sandwiches the firewall and NAT components between itself and a Proxy Extension Agent (PEA) as shown in Figure 2. These two devices work together so that the various packet flows within the sandwich are both firewall and NAT friendly. Outside of the sandwich the packet flows have the characteristics of the relevant standardised application. The result is that the ALG function containing the application specific knowledge has been effectively removed from the individual firewall and NAT components and placed in the Application Proxy. Being stand-alone, these devices can more readily be upgraded without affecting the individual firewall and NAT components. Davies, Read, Scott, Cordell [Page 9] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 ( ) ( Shared ) ( Network ) ( ) ( ) | | .................................|..................................... : Boundary of Firewall / ___|__ : : NAT Installation | | : : | NAT | : : |______| : : | | : : | FW1 | : : |______| : : | DMZ : : |------------------------------- : : | ____|____ ____|____ : : | | | | | : : | | PEA | | Bastion | : : ____|____ | | | Host | : : | | |_________| |_________| : : | FW2 | : : | NAPT | : : |_________| : : | _____________ : : | | | : : |---------| Application | : : | | Proxy | : : | |_____________| : .................................|..................................... | Private Network | --------------------------------------------------------------------- ____|____ ____|____ ____|____ ____|____ | | | | | | | | | Private | | Private | | Private | | Private | | Host | | Host | | Host | | Host | |_________| |_________| |_________| |_________| Figure 3 - Proxy Extension Agent (PEA) located in DMZ In the configuration shown in Figure 2 the Proxy Extension Agent is provided by a service provider. Such an arrangement removes the need for an additional IP address to be assigned to the enterprise. For enterprises that have sufficient IP addresses and do not want to engage a service provider, the configuration shown in Figure 3 can be deployed. However, this does require the NAT function to implement at least one instance of 1 to 1 NAT, and the firewall labelled FW1 to allow all traffic needed by the MoIP protocol to access the Proxy Extension Agent from other devices. The NAPT function can be Davies, Read, Scott, Cordell [Page 10] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 colocated with FW2. ( ) ( Shared ) ( Network ) ( ) ( ) | ....................|........................ :Service | _________ : :Provider | | | : :Boundary |----------| PEA | : : | |_________| : : | : :...................|.......................: ____|____ | In | | Network | | NATs | |_________| .................................|..................................... : Boundary of Firewall / ____|____ : : NAT Installation | | : : | NAPT | : : |_________| : : | | : : | FW1 | : : |_________| : : | : : ____|____ : : | | : : | FW2 | : : | [+NAPT] | : : |_________| : .................................|..................................... | Residential Network | --------------------------------------------------------------------- ______|______ | | | Application | | Proxy | |_____________| | | | Private | | Host | |_____________| Figure 4 - Application Proxy in a Residential Configuration Figure 4 shows a variation of the firewall installation for a residential environment in which only minimal devices are available, Davies, Read, Scott, Cordell [Page 11] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 and certainly no DMZ is present. In this case the NAPT and the firewall labelled FW1 are owned and administered by the network provider. The firewall labelled FW2 most likely forms part of the device that is used to access the network. Even if it is not owned and administered by the network provider, the provider most likely specifies it. In such a situation, the Application Proxy can be deployed in the host running the voice / video over IP protocol. Due to the lack of a DMZ, this configuration does require the Proxy Extension Agent to be provided by a service provider, although this service provider need not be the same as the network provider or the ISP. 6. Principles of Operation As mentioned earlier the Application Proxy and the Proxy Extension Agent make the various packet flows associated with a session firewall and NAT friendly for the devices that they sandwich. There are two main parts to this; using well-known ports and always initiating new packet flows from the private network out to the shared network. The use of well-known ports (or as a minimum, fixed ports) means that the firewall is able to apply secure filtering rules. Initiating connections always from the private to the public network makes the protocol NAT (and in particular NAPT) friendly. As part of the connection initiation procedure, a mechanism is used to discover the public addresses that the NAT has assigned to the new packet flow. To achieve this some control information is needed in addition to what is available in the protocol that is being traversed across the firewall installation. This introduces the need for a control channel to be set up between the two devices. This is called the Multiplexed Connection in the rest of this document. The relationship of the Multiplexed Connection to the other devices in the system is shown in Figure 5. (Note that in Figure 5 both firewalls have been merged into a single block as drawing them as separate units does not add to the clarity of the diagram.) Davies, Read, Scott, Cordell [Page 12] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 ___ _____ ____ ____ ____ | T | | A | ......| F |...| N |............... | P | | e | | p | . | i | | A | Multiplexed . | r | | r | | p | . | r | | P | Connection . | o | | m | | l | .--c--| e |---| T |--------------.PZ| x | | i |---a---| i | .--b--| W |---| |--------------. | y | | n |---a---| c | .--b--| a |---| R |--------------. | | | a | | a | ......| l |...| o |............... | Ext| | l | | t | | l | | u | | | | | | i P | PB____| |___| t |_______________PX| A | | | | o r | PB____| 1 ___| e |_______________PY| g | | | | n o | | & | | r | | e | | | | x | | 2 | | | | n | | |---d---| y |---d---| |---| |--------------PXR| t | |___|---d---|_____|---d---|____|---|____|--------------PYR|____| a = TCP and UDP Control Channels b = Multiplexed Sub-channels c = Multiplex Control Sub-Channel d = RTP/ RTCP Media PB = Probe Packets PX = Port X PY = Port Y PZ = Port Z (TCP) PXR = Port X (RTP) PYR = Port Y (RTCP) (Note that it is anticipated that PX == PZ) Figure 5 - Communication Paths between Application Proxy and Proxy Extension Agent The Multiplexed Connection runs over TCP and is initiated by the Application Proxy when the proxy is started. As part of the start up procedure, the Application Proxy and Proxy Extension Agent may authenticate each other. For extra security the Multiplexed Connection may be encrypted using TLS [5] or an equivalent. The Multiplexed Connection can carry multiple signalling flows over a number of Sub-Channels. The information for the traversal protocol is carried over what is called the Control Channel. Other sub-channels may be reserved for specific purposes (such as authentication and key exchange) and others can be dynamically assigned. The dynamically assigned sub-channels carry UDP or TCP based signalling protocols such as SIP, H.225 RAS, H.225 call signalling, H.245 and MEGACO/H.248. The data on the dynamically assigned sub-channels will typically be relayed to and from the terminal by the Application Proxy and to and from the remote party by the Proxy Extension Agent. The Application Proxy has the ability to open sub channels within the Multiplexed Connection. It is also able to instruct the Proxy Davies, Read, Scott, Cordell [Page 13] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Extension Agent to listen for new TCP connections on specific ports, or any available port. The Application Proxy can also instruct the Proxy Extension Agent to create UDP ports for signalling, either on a specific port or any available port. It is also necessary to be able to establish outbound and inbound RTP media flows. RTP is transported by UDP, and a unidirectional RTP connection requires both forward and reverse UDP paths to be established. It is, therefore, necessary to establish UDP paths from the terminal to the Proxy Extension Agent via the Application Proxy, and from the Proxy Extension Agent to the terminal, again via the Application Proxy. Additionally, the RTP and RTCP connections require a fixed relationship between the ports they use. Consequently it is necessary for the Application Proxy to be able to instruct the Proxy Extension Agent to open a Media Flow consisting of a pair of UDP ports which have the necessary RTP/RTCP port number relationship. To minimise the size of the holes opened up in the firewall, all outbound RTP and RTCP packets sent to the Proxy Extension Agent from the Application Proxy are directed towards the same well-known port pair. The source-address of the packets as viewed by the Proxy Extension Agent will have been modified in a non-deterministic way by the NAPT. Without further information, the Proxy Extension Agent will not be able to associate the RTP/RTCP packets with the correct Media Flow. This is solved using Probe Packets containing tokens. When the Application Proxy instructs the Proxy Extension Agent to establish a Media Flow, the Proxy Extension Agent will specify tokens that are to be included in Probe Packets. These Probe Packets, one for RTP and one for RTCP, are sent over UDP from the Application Proxy to the Proxy Extension Agent along the same path that the media will subsequently take. The token in each Probe Packet allows the Proxy Extension Agent to associate any further UDP packets received from the observed NAPT-modified source address with the correct part of the correct Media Flow. The NAPT function is expected to allow two-way communications between the Application Proxy and the Proxy Extension Agent triggered by the Probe Packets. Typically the NAPT will use a timer to detect when the path is no longer in use. The Media Flows created by this method are capable of bi-directional or uni-directional use. It has been mentioned that the Multiplexed Connection and all the UDP packets are handled by the same set of well-known ports on the Proxy Extension Agent in order to make the set of filtering rules in the firewall manageable and secure. To enable the scheme, any firewall between the Application Proxy and the Proxy Extension Agent must allow any TCP packet from any port with a source address of the Davies, Read, Scott, Cordell [Page 14] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Application Proxy to the well-known TCP port on the Proxy Extension Agent and vice versa. In addition, they must allow packets from any UDP port on the Application Proxy to be sent to the well-known UDP ports on the Proxy Extension Agent and vice versa. The resultant set of firewall rules is summarised in Table 1, below. ----------------------------------------------------------------------- |Rule | To/From IP| To/From| From/To IP| From/To| IP | Purpose | | | Address | Port | Address | Port | Protocol| | ----------------------------------------------------------------------- | 1 |Application| Any | Proxy | Z | TCP | Multiplex | | | Proxy | | Extension | | | Connection| | | | | Agent | | | | ----------------------------------------------------------------------- | 2 |Application| Any | Proxy | X | UDP | RTP | | | Proxy | | Extension | | | Media | | | | | Agent | | | | ----------------------------------------------------------------------- | 3 |Application| Any | Proxy | Y | UDP | RTCP | | | Proxy | | Extension | | | Media | | | | | Agent | | | | ----------------------------------------------------------------------- Table 1 - Example firewall filtering rules to enable communication between Application Proxy and Proxy Extension Agent (Note that it is anticipated that X == Z) (Note: These rules are bi-directional) 7. Operational Procedures This section describes the operation of the various procedures that make up the traversal scheme. Note that a number of devices in the private network may communicate with the Application Proxy, such as User Agents, Proxies and Gateways. Similarly, a number of devices may communicate with the Proxy Extension Agent on the shared network side, including other Proxy Extension Agents. Therefore, rather than draw and annotate a line to represent these devices, the diagrams show the Application Proxy receiving and sending messages to the private network, and the Proxy Extension Agent receiving and sending messages to the shared network. The actual devices that send or terminate these messages are not important to the discussion here. Davies, Read, Scott, Cordell [Page 15] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 7.1. Initialisation and Registration Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) Create TCP | | | | Connection | | | |-+-+-+-+-+-+-+-+-+->>>| |+-+->>>| | | | | | (2) Registration | | | |------------------->>>| |---->>>| | | | | | | | | | (3) Registration Ack | | | |<<<-------------------| |<<<----| | | | | | ---- | ----->>> = Control Channel Messages =====>>> = UDP Packets - - ->>> = Sub-channel Messages = = =>>> = Messages over TCP Figure 6 - Creating the Multiplex Connection and Registration Figure 6 shows the procedure when the Application Proxy is initially enabled. It will attempt to create a TCP connection to the Proxy Extension Agent (1) and then register (2) and (3). Part of the registration process may include authentication. As different authentication schemes may require different numbers of messaging round-trips, the actual sequence of messages will likely be different to that shown in the figure. Additionally, the TCP connection may be encrypted, possibly using TLS. Davies, Read, Scott, Cordell [Page 16] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 7.2. Opening a TCP Channel Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) Open TCP channel | | | | forward to A | | | |------------------->>>| |---->>>| | | | | (2) TCP Open | | | |<-+-+-+-+-+->>> | (3) TCP Open Ack | | | |<<<-------------------| |<<<----| | | | | | : | | | | | | | | : | | | | | | | | (4) Close TCP | | | |------------------->>>| |---->>>| (5) TCP Close | | | |<-x-x-x-x-x->>> | (6) Close TCP | | | |<<<-------------------| |<<<----| | | | | | ---- | ----->>> = Control Channel Messages =====>>> = UDP Packets - - ->>> = Sub-channel Messages = = =>>> = Messages over TCP Figure 7 - Opening an Outbound TCP Connection Figure 7 shows the Application Proxy opening a TCP connection to a remote party via the Proxy Extension Agent. The data for the connection is conveyed on a sub-channel in the Multiplexed Connection for the section of the path between the Application Proxy and the Proxy Extension Agent. The Application Proxy will begin by opening a sub-channel within the Multiplexed Connection. This involves informing the Proxy Extension Agent of the new sub-channel and telling it where it the destination address that it will try to connect to (1). When the TCP connection to the specified remote party has been established (2), the Proxy Extension Agent will inform the Application Proxy (3). After (3) the connection can be used to carry data in both directions. Note that if it is not possible to establish the connection, either because the Proxy Extension Agent does not have sufficient resources, or is unable to establish the connection to the remote party, the response message to the Application Proxy will indicate that the Open TCP Connection has failed. Davies, Read, Scott, Cordell [Page 17] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Either the Application Proxy or the Proxy Extension Agent can close the connection, usually when they receive a close notification from the corresponding TCP connections. The figure shows the case where the Application Proxy closes the TCP connection. In this case the Application Proxy sends a close message to the Proxy Extension Agent (4). Note that even though the Application Proxy has sent close, it should still continue to forward any data received from the Proxy Extension Agent on to the private network. Finally, when the Proxy Extension Agent has forwarded all the data it needs to send, it will close the TCP connection (5) and send a close message of its own (6), thus completing the close down of the connection. Davies, Read, Scott, Cordell [Page 18] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 7.3. Creating a TCP Listener Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) Create TCP | | | | Listener on port K | | | |------------------->>>| |---->>>| | | | | | | | | | (2) TCP Listen Ack | | | |<<<-------------------| |<<<----| | | | | | : | | | | | | | | : | | | (3) TCP | | | | Establish | (4) TCP channel Ready| | |<<<-+-+-+-+-+- | from Port K | | | |<<<-------------------| |<<<----| | | | | | (5) TCP Ready Ack | | | |------------------->>>| |---->>>| | | | | | : | | | | | | | | : | | | (6) TCP | | | | Establish | (7) TCP channel Ready| | |<<<-+-+-+-+-+- | from Port K | | | |<<<-------------------| |<<<----| | | | | | (8) TCP Ready Ack | | | |------------------->>>| |---->>>| | | | | | : | | | | | | | | : | | | | | | | | (9) Close TCP | | | | Listener on port K | | | |------------------->>>| |---->>>| | | | | | (10) Close TCP Ack | | | |<<<-------------------| |<<<----| | ---- | Figure 8 - Opening a TCP Listener Figure 8 illustrates the operation of a TCP listener. Such a listener might be used to listen for new incoming SIP calls over TCP, Davies, Read, Scott, Cordell [Page 19] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 or H.323 calls. The Application Proxy begins by instructing the Proxy Extension Agent to listen on a specified port or a port chosen by the Proxy Extension Agent (1). If the Proxy Extension Agent is able to do this it will acknowledge the listen request (2). If the Proxy Extension Agent is not able to post the listen, then it will reject the request. Subsequently, when a new connection is made to the listening TCP port (3), the Proxy Extension Agent will inform the Application Proxy using a TCP channel Ready message (4). Part of the information in the TCP channel Ready message will indicate the identity of the listening port that caused the TCP channel Ready message to be sent. If the Application Proxy is willing to accept the connection it will send a TCP channel Ready Ack message (5), which will also create a new sub-channel in the Multiplexed Connection. The Proxy Extension Agent should only accept the new connection once it has received the acknowledgement from the Application Proxy. The same listener may be the source of the many TCP connections as shown by (6), (7) and (8). When the Application Proxy no longer requires the listener it can instruct the Proxy Extension Agent to close it (9). The TCP connections that are opened as a result of the listener will be closed in the same way as TCP connections that are created by the Application Proxy. See Figure 7. Davies, Read, Scott, Cordell [Page 20] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 7.4. Opening a UDP Signalling Connection Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) Open UDP channel | | | | bind to port A | | | |------------------->>>| |---->>>| | | | | | (2) UDP Open Ack | | | |<<<-------------------| |<<<----| | | | | | : | | | | | | | | : | | | | | | | | (3) Close UDP Chan | | | |------------------->>>| |---->>>| | | | | | (4) Close UDP Chan | | | |<<<-------------------| |<<<----| | | | | | ---- | ----->>> = Control Channel Messages =====>>> = UDP Packets - - ->>> = Sub-channel Messages = = =>>> = Messages over TCP Figure 9 - Opening a UDP Signalling Connection UDP signalling connections (as opposed to UDP based Media Flows) are also made through the Multiplexed Connection. Note that such a connection is NOT suitable for data that is delay sensitive such as audio and video. Such data must use Media Flows. To create a UDP signalling path (see Figure 9), the Application Proxy sends a message to the Proxy Extension Agent. This message will create a sub-channel within the Multiplexed Connection and specify the port to which the UDP socket should bind, or specify that the Proxy Extension Agent should bind to a port of its choice (1). If the Proxy Extension Agent is able to create the sub-channel and socket, it will acknowledge the request (2), otherwise it will reject the request. Once the UDP signalling connection has been created, the connection emulates BSD sockets sendto and recvfrom semantics. This is achieved by pre-fixing each packet of data sent or received with the transport address of where it is to be sent to, or it has been received from. Only the Application Proxy is able to close the UDP connection when it is finished with. When the Application Proxy has no more data to Davies, Read, Scott, Cordell [Page 21] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 send, it will send the Close UDP message (3). On reception of the Close UDP message, the Proxy Extension Agent MUST close the associated UDP port. It MAY continue to forward any queued UDP data to the Application Proxy. Once the queued data has been sent, the Proxy Extension Agent MUST send the Close UDP message, thus completing the closure of the connection (4). 7.5. Opening a Media Flow Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) Create Media Flow| | | |------------------->>>| |---->>>| | | | | | (2) Create Media | | | | Flow Ack | | | | Ports = A:a,A:a+1 | | | | Tokens = 1234, 2345 | | | |<<<-------------------| |<<<----| | | | | | (3) UDP Probe Packet | | | | token = 1234 | | | |===================>>>| |====>>>| | | | | | (4) UDP Probe Packet | | | | token = 2345 | | | |===================>>>| |====>>>| | | | | | (5) Probe Ack (RTP) | | | |<<<-------------------| |<<<----| | | | | | (6) Probe Ack (RTCP) | | | |<<<-------------------| |<<<----| | | | | | | | | | ---- | Figure 10 - Opening a Media Flow To enable RTP media to flow between the shared network and the private network (Figure 10), the Application Proxy must first instruct the Proxy Extension Agent to open a Media Flow (1). If the Proxy Extension Agent is able to create the Media Flow it will notify the Application Proxy of the port numbers (a and a+1) it has allocated on address (A), and specify the tokens that are to be used in subsequent Probe Packets (2). Note: The RTP specification recommends that the RTP port number a is an even number and that the RTCP port number is one bigger, a+1. The Application Proxy will send the Probe Packets, with the supplied Davies, Read, Scott, Cordell [Page 22] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 token values, from ports that it has assigned to this Media Flow, to the Proxy Extension Agent (3) and (4). When the Proxy Extension Agent receives the Probe Packets, it will acknowledge each one with a Probe Ack (5) and (6). The Application Proxy will send Probe Packets periodically until the Probe Ack has been received or a time out limit is exceeded. The values of these timers are for further study. 7.6. Configuring a Media Flow Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) Set Remote(RTP) | | | |------------------->>>| |---->>>| | | | | | (2) Set Remote(RTCP) | | | |------------------->>>| |---->>>| | | | | | (3) | | | |------------------->>>| |---->>>|------->>> | | | | | (4) RTP packet | | | ===============>>>|===================>>>| |====>>>|=======>>> | | | | | (5) RTP packet | | | <<<===============|<<<===================| |<<<====|<<<======= | | | | | (6) RTCP Recv Report | | | ===============>>>|===================>>>| |====>>>|=======>>> | | | | | (7) RTCP Send Report | | | <<<===============|<<<===================| |<<<====|<<<======= | | | | | (8) RTCP Send Report | | | ===============>>>|===================>>>| |====>>>|=======>>> | | | | | (9) RTCP Recv Report | | | <<<===============|<<<===================| |<<<====|<<<======= | ---- | Figure 11 - Configuring a Bi-directional Media Flow Figure 11 shows the sequence of messages required to set up a bi-directional Media Flow. The Application Proxy must set the remote addresses that the Proxy Extension Agent will send RTP and RTCP packets to, (1) and (2). Having set the addresses the Application Proxy will use the Davies, Read, Scott, Cordell [Page 23] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 signalling protocol (H.323, SIP etc.) to send the RTP and RTCP addresses and ports to the device in the Shared Network (3). RTP and RTCP messages can now flow in both directions, (4), (5), (6), (7), (8) and (9). Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (2) Set Remote(RTCP) | | | |------------------->>>| |---->>>| | | | | | (3) | | | |------------------->>>| |---->>>|------->>> | | | | | (5) RTP packet | | | <<<===============|<<<===================| |<<<====|<<<======= | | | | | (6) RTCP Recv Report | | | ===============>>>|===================>>>| |====>>>|=======>>> | | | | | (7) RTCP Send Report | | | <<<===============|<<<===================| |<<<====|<<<======= | ---- | Figure 12 - Configuring an Incoming Media Flow Figure 12 shows the sequence of messages required to set up an incoming uni-directional Media Flow. Note: The numbering of messages in Figure 11 is carried over to Figure 12 to show the commonality between the procedures. The Application Proxy must set the remote address that the Proxy Extension Agent will send RTCP packets to (2). Having set the address the Application Proxy will use the signalling protocol (H.323, SIP etc.) to send the RTP and RTCP addresses and ports to the device in the Shared Network (3). RTP messages can be received from the Shared Network (5), and RTCP messages can be sent and received, (6) and (7). Davies, Read, Scott, Cordell [Page 24] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) Set Remote(RTP) | | | |------------------->>>| |---->>>| | | | | | (2) Set Remote(RTCP) | | | |------------------->>>| |---->>>| | | | | | (3) | | | |------------------->>>| |---->>>|------->>> | | | | | (4) RTP packet | | | ===============>>>|===================>>>| |====>>>|=======>>> | | | | | (8) RTCP Send Report | | | ===============>>>|===================>>>| |====>>>|=======>>> | | | | | (9) RTCP Recv Report | | | <<<===============|<<<===================| |<<<====|<<<======= | ---- | Figure 13 - Configuring an Outgoing Media Flow Figure 13 shows the sequence of messages required to set up an outgoing uni-directional Media Flow. Note: The numbering of messages in Figure 11 is carried over to Figure 13 to show the commonality between the procedures. The Application Proxy must set the remote addresses that the Proxy Extension Agent will send RTP and RTCP packets to, (1) and (2). Having set the addresses the Application Proxy will use the signalling protocol (H.323, SIP etc.) to send the RTCP address and port to the device in the Shared Network (3). RTP can be sent into the shared network (4), and RTCP messages can be sent and received, (8) and (9). Davies, Read, Scott, Cordell [Page 25] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 7.7. Closing a Media Flow Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | | | | | (1) Close Media Flow | | | |------------------->>>| |---->>>| | | | | | (1) Close Media Flow | | | | Ack | | | |<<<-------------------| |<<<----| | | | | | ---- | Figure 14 - Closing a Media Flow Figure 14 shows the message sequence used to close a Media Flow. 8. Examples of Operation This section contains examples that demonstrate the traversal mechanism applied to the SIP VoIP signalling protocol. Davies, Read, Scott, Cordell [Page 26] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 8.1. Handling Inbound SIP Call Signalling Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | | (1) INVITE + | | | | ports a,a+1 | | | |<<<- - - - - - - - - -| |- - - -|<<<=========== | | | | | (2) Create Media Flow| | | |------------------->>>| |---->>>| | | | | | (3) Create Media | | | | Flow Ack | | | | Ports = A:b,A:b+1 | | | | Tokens = 1234, 2345 | | | |<<<-------------------| |<<<----| | | | | | (5,6) RTP/RTCP Probes| | | | Token = 1234, 2345 | | | |===================>>>| |====>>>| | | | | | (7,8) Probe Acks | | | |<<<-------------------| |<<<----| | | | | | (9,10) Set RTP/RTCP | | | | Remote Addr | | | (11) INVITE + | ports a,a+1 | | | ports c,c+1 |------------------->>>| |---->>>| <<<===============| | | | | | | | (12,13) RTP/RTCP | (14,15) RTP/RTCP | | | Packets | Packets | | | ===============>>>|===================>>>| |====>>>|===========>>> | | | | (16) 200 OK + | (17) 200 OK + | | | ports c,c+1 | ports b,b+1 | | | ===============>>>|- - - - - - - - - - ->| |- - >>>|===========>>> | | | | (20,21) RTP/RTCP | (18,19) RTP/RTCP | | | <<<===============|<<<===================| |<<<====|<<<=========== | | | | (23) SIP ACK | (22) SIP ACK | | | <<<===============|<<<- - - - - - - - - -| |<<< - -|<<<=========== | | | | | ---- | ----->>> = Control Channel Messages =====>>> = UDP Packets - - ->>> = Sub-channel Messages = = =>>> = Messages over TCP Figure 15 - Signalling During an Incoming SIP Call Davies, Read, Scott, Cordell [Page 27] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Figure 15 shows how some of the elements of the mechanism combine to handle an incoming SIP call. It is assumed that the Proxy Extension Agent has already been instructed to create a UDP socket bound to port 5060 that can receive incoming SIP messages. When such a message is received, it will be forwarded to the Application Proxy along with the transport information from where the message was received (1). The Application Proxy will analyse the SIP messages and determine what it requires in terms of media forwarding ports on the Proxy Extension Agent. Once it has done this it will instruct the Proxy Extension Agent to create media connections (2). If the Proxy Extension Agent is able to allocate the required ports, it will acknowledge the Create Media message, specifying the public addresses it has created, and a set of tokens to be used in the probe packets (3). The Application Proxy is now able to create the required NAT bindings using probes (5) (6) which the Proxy Extension Agent should acknowledge (7) (8). Having received acknowledgement that the probing has been successful, the Application Proxy informs the Proxy Extension Agent where the RTP and RTCP media should be forwarded to (9) (10). At this point the Application Proxy has enough information to modify the INVITE message before forwarding it into the private network (11). Once this is done, any RTP and RTCP received from the private network can be forwarded onto the shared network (12) (13) (14) (15). At some point the Application Proxy should receive a final response from the private network (in this case a 200 OK) (16), which the Application Proxy forwards after modifying the SDP media addresses to point to the Proxy Extension Agent (17). It is now possible for bi-directional RTP/RTCP to flow (18) (19) (20) (21). The process is completed when the Proxy Extension Agent receives a SIP ACK from the shared network (22) (23). Davies, Read, Scott, Cordell [Page 28] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 8.2. Handling Outbound SIP Call Signalling Proxy Private Application Firewall Extension Shared Network Proxy & NAPT Agent Network | ---- | (1) INVITE + | | | | Ports = l,l+1 | | | | ===============>>>| (2) Create Media Flow| | | |------------------->>>| |---->>>| | | | | | (3) Create Media | | | | Flow Ack | | | | Ports = A:m,A:m+1 | | | | Tokens = 3456, 4567 | | | |<<<-------------------| |<<<----| | | | | | (4,5) RTP/RTCP Probes| | | | Token = 3456, 4567 | | | |===================>>>| |====>>>| | | | | | (6,7) Probe Acks | | | |<<<-------------------| |<<<----| | | | | | (8) INVITE + | | | | Ports = m,m+1 | | | |- - - - - - - - - - ->| |- - >>>|===========>>> | | | | | (9,10) RTP/RTCP | | | (11,12) RTP/RTCP | Packets | | | Packets |<<<===================| |<<<====|<<<=========== <<<===============| | | | | (13) 200 OK + | | | | Ports = n,n+1 | | | |<<<- - - - - - - - - -| |<<< - -|<<<=========== | | | | | (14,15) Set RTP/RTC | | | | Remote Addr | | | (16) 200 OK + | ports n,n+1 | | | Ports = o,o+1 |------------------->>>| |---->>>| <<<===============| | | | | | | | (17,18) RTP/RTCP | (19,20) RTP/RTCP | | | Packets | Packets | | | ===============>>>|===================>>>| |====>>>|===========>>> | | | | (21) SIP ACK | (22) SIP ACK | | | ===============>>>|- - - - - - - - - - ->| |- - >>>|===========>>> | | | | | ---- | Figure 16 - Signalling During an Outgoing SIP Call Davies, Read, Scott, Cordell [Page 29] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Figure 16 shows the handling of an outbound SIP call. The sequence of events is initiated when the Application Proxy receives a SIP INVITE on a port that it has already allocated for receiving SIP messages (1). The allocation of media ports and the probing is identical to that shown in Figure 15 for an inbound call (2) (3) (4) (5) (6) (7). From these steps the Application Proxy will have learnt the addresses and ports allocated by the Proxy Extension Agent for this media flow, and is able to modify and forward the INVITE message accordingly (8). The Proxy Extension Agent is now able to forward any received RTP and RTCP packets on to the Application Proxy, which will in turn forward them on to the private network (9) (10) (11) (12). If the call is to complete, the Proxy Extension Agent will receive a 200 OK, which it will forward to the Application Proxy (13). From this the Application Proxy can tell where the Proxy Extension Agent should forward RTP and RTCP packets, and informs the Proxy Extension Agent accordingly (14) (15). Prior to forwarding the 200 OK to the private network, the Application Proxy modifies the message so that RTP and RTCP packets will be sent to it, rather than the original addresses (16). RTP and RTCP packets may now flow from the private to the shared network (17) (18) (19) (20). The sequence is completed by the exchange of a SIP ACK message (21) (22). 9. Intra-Enterprise Calls When a call is made between two agents within the same enterprise, it is desirable to avoid sending media out onto the shared network and then looping it back into the private network. Not only does this needlessly occupy precious bandwidth on the connection path to the network provider, but it also exposes the media to eavesdropping and is thus a security risk. To prevent this the Application Proxy can analyse the media addresses received in the signalling. If the returned addresses are those of its Proxy Extension Agent, then it can deduce that the call is being looped back. It is then able to modify the signalling so that the calling devices send media directly, without traversing the firewall installation. Davies, Read, Scott, Cordell [Page 30] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 _____ | Ext | |Agent| |__ __| | | --------------------- __|__ | | | PEA | |__ __| | __|__ | FW | | NAT | |__ __| | __|__ | | | AP | |__ __| | ----------------------------------------------- | | __|__ __|__ | | | | | UA1 | | UA2 | |_____| |_____| Figure 17 - Intra-Enterprise Call In Figure 17 UA1 wishes to call UA2 using the services of the External Agent, ExtAgent. But the media must flow directly between UA1 and UA2. Call signalling will be routed from UA1 via the Application Proxy and the Proxy Extension Agent to ExtAgent and then from ExtAgent via the Proxy Extension Agent and the Application Proxy to UA2. Two Media Flows will be created as a consequence of the signalling, one between UA1 via the Application Proxy and the the Proxy Extension Agent to the Shared Network, the other between UA2 via the Application Proxy and the Proxy Extension Agent to the Shared Network. UA1 advertises its media address to the Application Proxy. The Application Proxy sets up a Media Flow for UA1 and advertises the media address information at the Proxy Extension Agent to the ExtAgent. The ExtAgent forwards the media address information received from the Davies, Read, Scott, Cordell [Page 31] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Proxy Extension Agent back via the Proxy Extension Agent to the Application Proxy. At this point UA1 has not been told any media address information, it is waiting for the signalling to complete. The Application Proxy has not yet started the signalling to create the media flow for UA2. The Application Proxy looks up the media address information and finds that there is a matching Media Flow for UA1. The Application Proxy advertises UA1's media address information to UA2 and remembers that when it completes media set up signalling to UA1 it must supply UA2's media address information. The Application Proxy sets up a second Media Flow for UA2 whose media address information is advertised to ExtAgent, even though the Media Flow will not be used. The media address information is required to complete the signalling with ExtAgent. ExtAgent completes the media signalling via the Proxy Extension Agent to the Application Proxy for UA1. The Application Proxy advertises UA2's media address information to UA1 as it has remembered to do. 10. Security Considerations The major change in this new version is to swap around the locations of the two main functional components. This places the controlling component behind the firewall, thus offering it some protection against attack. Threat analysis has still to be fully completed, but it is anticipated that locating the controlling component within the protection offered by the firewall should ensure that the method offers no more of a threat than any other host located behind a firewall. While, with the new swapped configuration, there is less of a need for the Application Proxy and the Proxy Extension Agent to authenticate each other, we still recommend that this procedure take place. This will ensure that the Proxy Extension Agent knows that it is acting on genuine commands, and means that a malicious agent acting within the firewall protected zone is unable to use the method to effectively open more holes in the firewall than would otherwise be available to them. As the Application Proxy is interpreting the signalling involved it can make sure that all the signalling is valid, and thus provides full stateful inspection capabilities rather than relying on simple packet filtering. Similarly, the Application Proxy can check that the media packets have the correct structure for RTP and RTCP. At present it is anticipated that the authentication scheme will have Davies, Read, Scott, Cordell [Page 32] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 a modular nature so that the mechanism is not locked into one particular authentication scheme. There is still some work to do in this area, and input on the various options for authentication (and encryption) are solicited. One area that does need further attention is that of end-to-end authentication and encryption. As the Application Proxy and Proxy Extension Agent have to handle media, the Application Proxy will have to modify the protocol messages involved in the signalling so that media is sent to them rather than directly to the destination host. This will affect any message integrity-checking scheme that is employed between the two end systems. Note that it should still be possible to employ end-to-end encryption of the media, but the Application Proxy will no longer be able to analyse whether the packets have the correct format to be RTP or RTCP (although it will be able to analyse whether they appear at the correct rate and have roughly the correct size). 11. Conclusions In summary, the technique provides a method for allowing multimedia systems (such as those using SIP, H.323 and MEGACO/H.248) located in private IP networks to connect to a shared network via firewall and NAPT functions. The method does not compromise the existing security procedures and measures, and avoids the need to upgrade existing firewalls, routers and proxies. It also allows full NAPT to be applied to IP connections without the NAPT function interpreting or understanding the communication protocols being used. Multiple NAT functions can be traversed, either by suitable positioning of a single Application Proxy / Proxy Extension Agent pair, or by deploying multiple Application Proxy / Proxy Extension Agent pairs. 12. Acknowledgements We would like to thank Greg Adams in the team at Ridgeway Systems & Software for helping to architect, implement and verify this method. 13. Authors' Addresses Steven Davies Ridgeway Systems & Software 66 Suttons Business Park Reading, RG6 1AZ England sdavies@ridgeway-sys.com Davies, Read, Scott, Cordell [Page 33] Internet Draft Non Protocol Aware Firewall & NAT Traversal Oct 2001 Steve Read Ridgeway Systems & Software 66 Suttons Business Park Reading, RG6 1AZ England sread@ridgeway-sys.com Barry Scott Ridgeway Systems & Software 66 Suttons Business Park Reading, RG6 1AZ England bscott@ridgeway-sys.com Pete Cordell Ridgeway Systems & Software 66 Suttons Business Park Reading, RG6 1AZ England pete@tech-know-ware.com 14. Bibliography [1] M. Holdrege and P. Srisuresh, "Protocol complications with the IP network address translator (NAT)," Request For Comment 3027, Internet Engineering Task Force, Jan. 2001. [2] ETSI TIPHON Requirements Definitions Study DTR 01012 "Firewall Aspects of Inter-domain Routing". Sept. 2000. Work in progress. [3] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through firewalls and NATs," Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress. [4] P. Srisuresh, J. Kuthan, and J. Rosenberg, "Middlebox communication architecture and framework," Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. [5] T. Dierks, C. Allen, "The TLS Protocol Version 1.0." Request For Comment 2246, Internet Engineering Task Force, January 1999. Davies, Read, Scott, Cordell [Page 34]