Internet Engineering Task Force Internet Draft S. Davies draft-davies-fw-nat-traversal-00.txt S. Read March 18, 20001 P. Cordell Expires: September 2001 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 In this draft, we present a method that enables real-time session-oriented protocols, such as SIP, H.323, 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 and H.323 are presented here as examples. Contents 1. Definitions, symbols and abbreviations 3 1.1 Definitions 3 1.2 Abbreviations 3 2. Introduction 3 3. Problems Introduced by Firewalls and NATs 4 4. Options for Firewalls and NATs in an MoIP Environment 4 Davies, Read, Cordell [Page 1] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 5. Traversal of non-Protocol Aware Firewalls and NATs 5 5.1 Components of the System 5 5.2 Communication Paths of the System 8 5.3 Principles of Operation 9 5.4 Examples of Operation 10 5.4.1. Operation at System Start Up 10 5.4.2. Handling Inbound SIP Call Signalling 11 5.4.3. Handling Outbound SIP Call Signalling 13 5.4.4. Handling Incoming H.323 Signalling Connections 15 5.4.5. Handling Outgoing H.323 Signalling Connections 16 5.4.6. Establishing Outbound H.323 UDP Paths 17 5.4.7. Establishing Inbound H.323 UDP Paths 18 5.4.8. H.323 Post Call Clean Up 19 6. Primitives 20 6.1 Registration 20 6.2 Create TCP Listener 21 6.3 Create TCP sub-channel with TCP Listener 21 6.4 Create TCP sub-channel - PS to PIA 22 6.5 Create TCP sub-channel - PIA to PS 22 6.6 Create UDP Port / Port Pair 23 6.7 Modify UDP Port / Port Pair 23 6.8 Close TCP Listener 24 6.9 Close TCP sub-channel 24 6.10 Close UDP Ports 24 7. Multiplex Structure of the Multiplexed Connection 25 8. Further Benefits of the Scheme:Security, QoS and Management 26 9. Security Considerations 26 10. Conclusion 27 11. Acknowledgements 27 12. Authors Addresses 27 13. Bibliography 27 1. Definitions, symbols and abbreviations 1.1 Definitions For the purposes of the present document, the following terms and definitions apply. Administrative Domain: An administrative domain is a bounded entity within which all encompassed constituent elements are under common ownership, operation and management. IP Network: It is assumed that multiple administrative domains will exists on the IP network (like traditionally the SCN networks). Such domains will have their own policies on accounting, QoS, etc. network: telecommunications network which provides telecommunications services. network operator: entity which is responsible for the development, Davies, Read, Cordell [Page 2] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 provisioning and maintenance of telecommunications services and for operating the corresponding networks. service provider: entity which provides services to its service subscribers on a contractual basis and who is responsible for the services offered. The same organization may act as a network operator and a service provider. service provider access interface: interface between a network and a service provider's equipment for enabling the service provider to access specific functionality of a network. 1.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ALG Application Level Gateway MoIP Multimedia over IP SP Service Provider VoIP Voice over IP 2. Introduction Much is now understood, and 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 ride on existing firewall and NAT behaviour in order to get the protocols through the firewall and NAT functions. . This solution is necessary for deployments where it is impossible or undesirable to upgrade 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 Davies, Read, Cordell [Page 3] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 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. The method and architecture has been implemented and proven to work. 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 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 also introduces problems when deploying MoIP systems. Firstly, both basic NAT and NAPT typically require all sessions to be initiated on the private network. This restriction is problematic when calls need to be made from the public network into the private network. Additionally, NAT functions effectively scramble the source and destination addresses used for packets and without special processing by the NAT (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 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 Davies, Read, Cordell [Page 4] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 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 public 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 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 processing and can therefore continue to provide protection to 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 method is consistent with and complimentary to deployments aimed at delivering known QoS levels. First and foremost the exchange of media traffic is extremely lightweight (it is almost a NULL function). Secondly, where existing exit routes through firewalls and NAT devices are deemed to have undesirable QoS characteristics, parallel exit routes can be created using off-the-shelf firewall and NAT devices with known performance characteristics - an easy task for any IT manager. Thirdly, the method is extensible to support a variety of QoS signalling and performance measurement methods to enable steps to be taken to ensure a 'service' does not degrade. The Davies, Read, Cordell [Page 5] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 CPE implementation scales down as well as up. In the simplest of cases, the CPE may be software executing on an endpoint such as a PC. In large deployments, the CPE 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. Traversal of non-Protocol Aware Firewalls and NATs This section describes the components and operation of the system used to deploy multimedia communication systems across private-public network boundaries that employ firewall and NAT/NAPT functions. 5.1 Components of the System The use of tunnels and probe packets to traverse firewalls and NATs is described with reference to Figure 1. Davies, Read, Cordell [Page 6] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 ........................ ....................... . Enterprise A . . Enterprise B . . . . . . Private IP . . Private IP . . addresses . . addresses . . . . . . . . . . Terminal ___ . ______ . ___ Terminal . . User A | |_| _ . _ ( ) _ . _ |_| | User B . . 10.1.1.1 |___| | | |. |N| ( Shared ) |N| .| | | |___| 10.1.1.1 . . ___ |_|F|__|A|__( IP )__|A|__|F|__| ___ . . PIA A | |_| |W|. |T| ( Network ) |T| .|W| |_| | PIA B . . 10.1.1.3 |___| | |_|. |_| ( ) |_| .|_| | |___| 10.1.1.4 . . . a (______) b . . . . | . . ....................... | ........................ | ................|................... . ------- . . | F W | . . ------- . . _________|_________ . . | . . ___|__ . . | | Proxy Server . . | \ / | 45.6.7.8 . . | \/ | . . |______| Well known port . . numbers X, Y, Z . . Service Centre . .................................... PIA = Proxy Interface Agent FW = Firewall function N = Full NAPT function a = Full NAPT function provides public address(es) for Enterprise A, eg. 192.1.1.1 b = Full NAPT function provides public address(es) for Enterprise B, eg. 206.1.1.1 Figure 1 - Overview of MoIP System This shows a communication environment comprising two enterprises, A and B, each of which have private networks. Both have one or more MoIP terminals (e.g. H.323 or SIP). One or both of the enterprises have non-globally unique private IP addresses typically within the 10.x.x.x address range. The private IP addresses may result from a static assignment or dynamic assignment through normal DHCP procedures. To support the traversal operation, the private networks contain Davies, Read, Cordell [Page 7] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 Proxy Interface Agents that act on behalf of the terminals. The Proxy Interface Agents may be implemented as part of the terminal, may be independent of the terminal implementation, but operate on the same device as the terminal, or may be installed on a separate device. (Figure 1 illustrates the case where the Proxy Interface Agent is installed on a separate device.) If a Proxy Interface Agent is deployed on a separate device to their respective terminal(s), then the Proxy Interface Agent(s) will have a unique IP address within the range of their respective private networks. In such cases, each Proxy Interface Agent may act on behalf of multiple terminals. External communication is via a shared, managed or public IP network. For external communication, enterprise A has one or more public IP address(es), for example in a range beginning at 192.1.1.1 and enterprise B has one or more public IP address(es), for example in a range beginning at 206.1.1.1. Each enterprise has a router that may apply Network Address Port Translation (NAPT) to dynamically map between internal (private) IP addresses and port numbers and one of the external (public) IP addresses and the port numbers. The private networks are optionally each protected at their edges with firewall functions. An example of the rules that need to be included in the firewall configuration to allow real-time communication using the method is shown in Table 1. The reason for each rule is captured in the table. Davies, Read, Cordell [Page 8] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 ----------------------------------------------------------------------- |Rule | From IP | From | To IP | To | IP | Purpose | | | Address | Port | Address | Port | Protocol | | ----------------------------------------------------------------------- | 1 | Any | Any | Proxy | Z | TCP | Outbound | | | | | Server | | | Multiplex | | | | | | | | Connection | ----------------------------------------------------------------------- | 2 | Proxy | Z | Any | Any | TCP (with | Inbound | | | Server | | | | Ack bit | Multiplex | | | | | | | set) | Connection | ----------------------------------------------------------------------- | 3 | Any | Any | Proxy | Z | UDP | Outbound | | | | | Server | | | Media | | | | | | | | (RTP) | ----------------------------------------------------------------------- | 4 | Proxy | Z | Any | Any | UDP | Inbound | | | Server | | | | | Media | | | | | | | | (RTP) | ----------------------------------------------------------------------- | 5 | Any | Any | Proxy | Y | UDP | Outbound | | | | | Server | | | Media | | | | | | | | (RTCP) | ----------------------------------------------------------------------- | 6 | Proxy | Y | Any | Any | UDP | Inbound | | | Server | | | | | Media | | | | | | | | (RTCP) | ----------------------------------------------------------------------- Table 1 - Example Firewall Configuration for Permitting Traversal In the above table, ideally the listed port numbers X, Y and Z are registered according to standards agreed to by IANA. The advantage of these ports being industry standard ports is that intermediary equipment such as firewalls and routers would know the associated media is real-time traffic and could, therefore, handle it appropriately, for example a router could give it higher priority forwarding in order to minimise delays. In order for terminals in enterprise A to communicate with other terminals in enterprise B, there must exist a shared network to which a Proxy Server is connected. The Proxy Server has a public IP address, for example 45.6.7.8. The Proxy Server would also make use of the new well-known ports numbers X, Y and Z registered with IANA. Figure 2 shows a similar enterprise configuration that incorporates a local gatekeeper/SIP proxy. This allows internal calls to be made without contacting the public Proxy Server. In this configuration the Proxy Server would typically be manually configured to route a block of numbers to the Proxy Interface Agent, which would then route the calls to the local gatekeeper/SIP proxy. Alternatively, the gatekeeper/SIP proxy may dynamically signal to the Proxy Server the Davies, Read, Cordell [Page 9] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 addresses of terminals for which it is responsible. ______ | |________________ ( ) | \ / | ( Shared IP ) | \/ |- - - - - - - - ( Network ) |______|. . . . . . | ( ) . | | Proxy Server . \ __|__ . | | | Access Router . | |_____| w/ NAPT . | | . | __|__ . | | FW | Firewall . | |_____| . | | _____ _____ . / | | SIP | | PIA | . / | | .|. . .|. . .|. . / | | . | |_ _ _|_ _ / |_ _._| /|_____| | ___________|_._____/___|_________________|__ | | . / | | | | . / | | | | . / | | _|___ _|_._/ _|___ _|___ | P | | P | | P | | P | |_____| |_____| |_____| |_____| P = IP Desktop Phones (maybe PC based) PIA = Proxy Interface Agent SIP = SIP Proxy/Gatekeeper - - - = Media Path . . . = Call Signaling path Figure 2 - Example Network Configuration with Local Gatekeeper / SIP Proxy Davies, Read, Cordell [Page 10] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 5.2 Communication Paths of the System ___ ____ ____ ____ ____ | T | | P | ......| F |...| N |............... | P | | e | | r | . | i | | A | Multiplexed . | r | | r | | o | . | r | | P | Connection . | o | | m | | x | .--c--| e |---| T |--------------.PZ| x | | i |---a---| y | .--b--| W |---| |--------------. | y | | n |---a---| | .--b--| a |---| R |--------------. | | | a | | I/F| ......| l |...| o |............... | S | | l | | | | l | | u | | e | | | | A | PB____| |___| t |_______________PX| r | | | | g | PB____| ___| e |_______________PY| v | | | | e | | | | r | | e | | | | n | | | | | | r | | |---d---| t |---d---| |---| |--------------PXR| | |___|---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) Figure 3 - Interface Connections Between System Entities Figure 3 shows the communications paths between the various entities from the perspective of entities associated with enterprise A, including the terminal, the Proxy Interface Agent, the firewall, the NAPT router and the Proxy Server. Note that it does not include a gatekeeper/SIP proxy between the Terminal and the Proxy Interface Agent, but such a configuration is equally possible. The method allows the Proxy Interface Agent to operate in a protocol agnostic way. As such, the Proxy Server will command the Proxy Interface Agent to open and close any UDP (or TCP) sockets needed. This is very flexible as it allows terminals employing new protocols to be added to the private network without upgrading the Proxy Interface Agents. 5.3 Principles of Operation Figure 3 shows a Multiplexed Connection between the Proxy Interface Agent and the Proxy Server, via the firewall and NAPT router. Within the Multiplexed Connection (which may be authenticated and encrypted using techniques such as TLS) are one or more logical channels. One of these is the multiplex control channel, while the others carry UDP or TCP based signalling protocols such as H.225 RAS, H.225 call Davies, Read, Cordell [Page 11] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 signalling, H.245, SIP and MEGACO/H.248. This connection is used for all communications between the terminal and Proxy Server for which the performance characteristics of a TCP connection are acceptable. Some of the logical channels within the Multiplexed Connection will be statically allocated - in particular the control channel - while other logical channels can be dynamically created as the need arises. Some of the logical channels will be relayed to/from the terminal by the Proxy Interface Agent. With each such logical channel the Proxy Interface Agent associates the IP addresses and ports of the specific TCP or UDP connection used between the Proxy Interface Agent and the terminal. In other words, the Proxy Interface Agent makes an association between a transport address on the terminal and one of its own addresses and ports for each logical channel. Both the Proxy Server and the Proxy Interface Agent have the ability to open logical channels within the Multiplexed Connection. The Proxy Server is also able to instruct the Proxy Interface Agent to listen for new TCP connections on either specific ports, or any available port. It is also necessary to be able to establish outbound and inbound RTP media paths between the terminal and the Proxy Server. RTP is based on 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 Server via the Proxy Interface Agent, and from the Proxy Server to the terminal, again via the Proxy Interface Agent. Additionally, the RTP and RTCP connections require a fixed relationship between the ports they use. Consequently, in addition to being able to open a single port at a time, it is necessary for the Proxy Server to be able to instruct the Proxy Interface Agent to open UDP port pairs which have the necessary RTP/RTCP port number relationship. To minimise the size of the holes opened up in the firewall, all RTP and RTCP packets sent to the Proxy Server are directed towards the same well-known port pair. Additionally, the source of the packets as viewed by the Proxy Server will have been essentially randomised by the NAPT. Without further information, the Proxy Server will not be able to associate the RTP/RTCP packets with the correct call. This is solved using Probe Packets. Prior to forwarding UDP packets to the Proxy Server, the Proxy Interface Agent sends Probe Packets that contain a token specified by the Proxy Server when it instructed the Proxy Interface Agent to open the UDP connection. The presence of the token in the Probe Packets allows the Proxy Server to associate any further UDP packets received from the observed NAPT modified source address with the correct UDP channel. It is also necessary to be able to send UDP packets from the Proxy Server to the Proxy Interface Agent so that they can be forwarded onto the terminal. This requires a public-to-private address mapping Davies, Read, Cordell [Page 12] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 to be created in the NAPT. This is again done by asking the Proxy Interface Agent to send a Probe Packet to the Proxy Server containing a token specified by the Proxy Server. This creates a private-to-public mapping in the NAPT which in turn can be used as a public-to-private mapping. The token in the Probe Packet allows the Proxy Server to determine the correct address on the NAPT to send future UDP packets to for the given UDP session. It can be seen that the procedure for establishing inbound and outbound UDP forwarding is very similar. As the UDP ports used for RTP and RTCP are often configured to be bi-directional, the commands used to establish UDP forwarding are actually bi-directional by default. If a UDP forwarding instance is initially uni-directional, it can be made into a bi-directional instance at a later time. 5.4 Examples of Operation This section contains examples that demonstrate the traversal mechanism applied to various VoIP signalling protocols. 5.4.1. Operation at System Start Up Terminal PIA Firewall & NAT Server | | ---- ---- | | | Create TCP | | | | | | | Connection | | | | | | |-+-+-+-+-+-+-+-+-+->>>| |-| |+-+->>>| | | | | | | | | | Registration | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | | | | | | | | Create 5060/1720 | | | | | | | Listener | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | ---- ---- | ----->>> = Control Channel Messages - - ->>> = Sub-channel Messages =====>>> = UDP Packets = = =>>> = Messages over TCP Figure 4 - Operation at Proxy Interface Agent Start Up When the Proxy Interface Agent is enabled it establishes a Multiplexed Connection to the Proxy Server by initiating an outbound TCP connection to the address and port of the Proxy Server, as shown in Figure 4. This connection will typically be authenticated and encrypted, perhaps using SSL or TLS. Davies, Read, Cordell [Page 13] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 As part of the initial configuration, the Proxy Server may instruct the Proxy Interface Agent to create sockets to listen for registration information and outgoing call attempts from the terminal. If the terminal subsequently attempts to register with a gatekeeper/SIP proxy, such messages (SIP REGISTER, H.225 RAS etc.) may be sent to the Proxy Interface Agent. The Proxy Interface Agent will forward the registration messages to the Proxy Server via a logical channel. Any responses are sent using the reverse route. The Proxy Server will store the terminal's private transport address along with the identity or transport address of the Multiplexed Connection on which the registration was received. This information is sufficient to forward incoming calls to the terminal when the need arises. Davies, Read, Cordell [Page 14] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 5.4.2. Handling Inbound SIP Call Signalling Terminal PIA Firewall & NAT Server | | ---- ---- | | | (1) Create sub- | | | | | | | channel to terminal | | | | | | | port 5060 | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (2) Create UDP Port | | | | | | | (pair) Token = 1234 | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (3) UDP Ports = A(B) | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | (4) UDP Probe Packet | | | | | | |===================>>>| |=| |====>>>| | | | | | | | | | (5) INVITE + | | | | | | (6) INVITE + | ports A(B) | | | | | | ports A(B) |<<<- - - - - - - - - -| |-| |- - - -| |<<<===============| | | | | | | | | | | | | | (7) UDP Media | | | | | | | Packet | (8) UDP Media | | | | | |===============>>>| Packet | | | | | | |===================>>>| |=| |====>>>| | (9) 200 OK + | | | | | | | ports C(D) | (10) 200 OK + | | | | | |===============>>>| ports C(D) | | | | | | |- - - - - - - - - - ->| |-| |- - >>>| | | | | | | | | | (11) Modify UDP Port | | | | | | | (pair) - Forward | | | | | | | to C(D) | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (12) UDP Media | | | | | | (13) UDP Media | Packet | | | | | | Packet |<<<===================| |=| |=======| |<<<===============| | | | | | | | (14) Ack | | | | | | (15) Ack |<<<- - - - - - - - - -| |-| |- - - -| |<<<===============| | | | | | | | ---- ---- | ----->>> = Control Channel Messages =====>>> = UDP Packets - - ->>> = Sub-channel Messages = = =>>> = Messages over TCP Figure 5 - Signalling During an Incoming SIP Call Davies, Read, Cordell [Page 15] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 Figure 5 illustrates the signalling for an incoming SIP call. First the Proxy Server creates a logical channel within the Multiplexed Connection for the SIP signalling (1). The Proxy Server also instructs the Proxy Interface Agent to create a UDP port pair that can receive media from the terminal. As part of this command the Proxy Server specifies a token (2). The Proxy Interface Agent replies to the request with the allocated port numbers when it has completed the operation (3). The Proxy Interface Agent also sends a Probe Packet to the Proxy Server containing the token specified in the UDP port pair open command (4). The Probe Packet along with the token allows the Proxy Server to associate further UDP packets received from the observed NAPT modified source address with the correct RTP session. The Proxy Server now has sufficient information to populate the SIP INVITE message along with its associated SDP, and forwards this to the Proxy Interface Agent (5) which in turn forwards it to the user agent (6). At this point the user agent is able to send UDP packets to the Proxy Interface Agent, which will then forward them onto the Proxy Server - although typically such media flow would be initiated later in the sequence (7, 8). At some point the user agent will typically reply to the INVITE with a 200 OK message. This will include the ports that the user agent wishes to receive RTP/RTCP media on (9). This message is again forwarded to the Proxy Server (10). To enable the Proxy Interface Agent to correctly forward UDP packets from the Proxy Server on to the user agent, the Proxy Interface must be informed of the relevant ports on the user agent. Rather than creating a new UDP port pair for this purpose, the Proxy Server instructs the Proxy Interface Agent to modify the parameters of the existing UDP ports so that they can be used for forwarding (11). This establishes the preferred relationship between RTP and RTCP ports for a bi-directional RTP session. Once this is completed, the Proxy Server is able to forward UDP packets received from the outside network to the NAPT modified public address. This will result in the packets being sent to the correct private address on the Proxy Interface Agent (12). The Proxy Interface Agent can forward such received packets to the user agent using the information previously received (13). At a later time, the SIP ACKs will be received thus completing the SIP signalling (14, 15). Davies, Read, Cordell [Page 16] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 5.4.3. Handling Outbound SIP Call Signalling Terminal PIA Firewall & NAT Server | | ---- ---- | | (1) INVITE + | | | | | | | Ports = E(F) | (2) Create | | | | | |===============>>>| sub-channel | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | (3) INVITE + | | | | | | | Ports = E(F) | | | | | | |- - - - - - - - - - ->| |-| |- - >>>| | | | | | | | | | (4) Create UDP Port | | | | | | | (pair) forwarding | | | | | | | to ports E(F) | | | | | | | token = 5678 | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (5) UDP Ports = G(F) | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | (6) UDP Probe Packet | | | | | | | token = 5678 | | | | | | |===================>>>| |=| |====>>>| | | | | | | | | (8) UDP Media | (7) UDP Media Packet | | | | | | Packet |<<<===================| |=| |=======| |<<<===============| | | | | | | | (9) 200 OK + | | | | | | (10) 200 OK + | Ports = G(H) | | | | | | Ports = G(H) |<<<- - - - - - - - - -| |-| |- - - -| |<<<===============| | | | | | | | | | | | | | (11) UDP Media | | | | | | | Packet | (12) UDP Media | | | | | |===============>>>| Packet | | | | | | |===================>>>| |=| |====>>>| | (13) Ack | | | | | | |===============>>>| (13) Ack | | | | | | |- - - - - - - - - - ->| |-| |- - >>>| | | | | | | | | | ---- ---- | ----->>> = Control Channel Messages - - ->>> = Sub-channel Messages =====>>> = UDP Packets = = =>>> = Messages over TCP Figure 6 - Signalling During an Outgoing SIP Call Figure 6 shows the messaging sequence for a typical outbound SIP Davies, Read, Cordell [Page 17] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 call. The sequence is started when the Proxy Interface Agent receives an INVITE message from the user agent (1). This causes the Proxy Interface Agent to create a new sub channel within the Multiplexed Connection (2). The Proxy Interface Agent can then forward the INVITE to the Proxy Server (3). The Proxy Server instructs the Proxy Interface Agent to create a bi-directional UDP port pair that can be used to both forward UDP packets from the Proxy Server to the user agent and from the user agent to the Proxy Server (4). The Proxy Interface Agent responds to this command with the values of the ports that it has created (5). It also sends a Probe Packet containing a token contained in the command (6). The Proxy Server uses the token to associate the Probe Packet with the correct call. The Proxy Server can then send UDP media packets for this RTP/RTCP session to the observed NAPT modified source address of the Probe Packet (7) which the Proxy Interface Agent will receive on the appropriate ports to be able to forward to the correct user agent ports (8). Some time later the Proxy Server will typically receive a 200 OK message from the remote user agent. The Proxy Server modifies the port information in this message to be that of the ports configured on the Proxy Interface Agent and forwards the message to the Proxy Interface Agent (9), which in turn forwards the message to the user agent (10). The user agent is now able to send UDP media packets (11, 12). The user agent completes the SIP signalling by sending an ACK message to the Proxy Interface Agent (13), which is forwarded to the Proxy Server (14). Davies, Read, Cordell [Page 18] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 5.4.4. Handling Incoming H.323 Signalling Connections Terminal PIA Firewall & NAT Server | | ---- ---- | | | (1) Create sub- | | | | | | | channel to terminal | | | | | | | Port 1720 | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (2) H.225 SETUP | | | | | | (3) H.225 SETUP |<<<- - - - - - - - - -| |-| |- - - -| |<<<= = = = = = = =| | | | | | | | | | | | | | (4) H.225 CONNECT| | | | | | | (H.245 Port=A) | (5) H.225 CONNECT | | | | | |= = = = = = = =>>>| (H.245 Port = A) | | | | | | |- - - - - - - - - - ->| |-| |- - >>>| | | | | | | | | | (6) Create sub- | | | | | | | channel to terminal | | | | | | | Port A | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | (7) H.245 | (7) H.245 Messages | | | | | | Messages | | | | | | |<<<= = = = = = >>>|<<<- - - - - - - - - -| |-| |- - - -| | | ---- ---- | Figure 7 - Signalling During an Incoming H.323 Call To establish an incoming call the signalling steps illustrated in Figure 7 are followed. The Proxy Server needs to establish an H.225 call control channel to the terminal. This is done via the Proxy Interface Agent. If an appropriate logical channel does not already exist between the Proxy Server and the Proxy Interface Agent, such a logical channel is created (1). As part of this process, the private transport address (IP address and port) of the terminal to which the Proxy Interface Agent is to create the onward TCP or UDP connection is specified. The messages needed to create the logical channel are exchanged between the Proxy Server and the Proxy Interface Agent using the control logical channel. Once the logical channel for the call control signalling has been created the Proxy Server can send an H.323 SETUP message to the Proxy Interface Agent (2). The Proxy Interface Agent will then relay this message on to the terminal using the TCP connection established when the logical channel was created (3). In H.323 it may be necessary to establish an H.245 connection between the Proxy Server and the terminal. The address within the terminal to which this connection is to connect is contained in the responses sent back to the Proxy Server by the terminal (4, 5). If the Proxy Davies, Read, Cordell [Page 19] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 Server chooses to establish such an H.245 session, then it creates a new logical channel in the same way it created the call-signalling channel (6). As part of this procedure the Proxy Interface Agent will establish a TCP connection to the private IP address and port specified in the terminal's responses. Establishing media for a call is common for both incoming and outgoing calls, and is described later. 5.4.5. Handling Outgoing H.323 Signalling Connections Terminal PIA Firewall & NAT Server | | ---- ---- | | (1) H.225 SETUP | | | | | | |= = = = = = = =>>>| (2) Create sub- | | | | | | | channel | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | (3) H.225 SETUP | | | | | | |- - - - - - - - - - ->| |-| |- - >>>| | | | | | | | | | (4) Create sub- | | | | | | | channel with | | | | | | | listener on | | | | | | | any port | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (5) Sub-channel | | | | | | | listening on | | | | | | | port B | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | (6) H.225 CONNECT | | | | | |(7) H.225 CONNECT | (H.245 Port = B) | | | | | | (H.245 Port = B) |<<<- - - - - - - - - -| |-| |- - - -| |<<<= = = = = = = =| | | | | | | | | | | | | | (8) H.245 | (8) H.245 | | | | | | Messages | Messages | | | | | |= = = = = = = =>>>|<<<- - - - - - - - - -| |-| |- - >>>| | | ---- ---- | Figure 8 - Signalling During an Outgoing H.323 Call The steps needed to handle an outgoing call are illustrated in Figure 8. A signalling path is created between the terminal and the Proxy Server when the terminal connects and sends a SETUP message to the Proxy Interface Agent (1). If a logical channel for this type of connection does not already exist within the Multiplexed Connection, then such a channel is created by the Proxy Interface Agent using the control channel (2). The Proxy Interface Agent can then relay the message(s) to the Proxy Server (3). Davies, Read, Cordell [Page 20] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 If a separate H.245 connection is required for the outgoing call, the Proxy Server will create an additional logical channel within the Multiplexed Connection and instruct the Proxy Interface Agent to create a listening socket (4). The values of address and port of the created socket are returned to the Proxy Server (5), which it includes in the H.323 signalling sent in response to the Setup message (6, 7). This information allows the terminal to connect to the listening socket created by the Proxy Interface Agent. Once the H.245 connection has been established, H.245 signalling can take place. Establishing media for a call is common for both incoming and outgoing calls, and is described below. 5.4.6. Establishing Outbound H.323 UDP Paths To establish a UDP path (illustrated in Figure 9) between the terminal and the Proxy Server, the Proxy Server instructs the Proxy Interface Agent to open a UDP port (or port pair) that the terminal can connect to. The Proxy Server also specifies a token that the Proxy Interface Agent should associate with the connection (1). Terminal PIA Firewall & NAT Server | | ---- ---- | | | (1) Create UDP Port | | | | | | | (pair) | | | | | | | Token = 1234 | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (2) UDP Ports = C(D) | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | (3) UDP Probe Packet | | | | | | | Token = 1234 | | | | | | |===================>>>| |=| |====>>>| | | | | | | | | (5) H.245 OLC / | (4) H.245 OLC/OLC ACK| | | | | | OLC ACK | Ports = C(D) | | | | | | Ports = C(D) |<<<- - - - - - - - - -| |-| |- - - -| |<<<= = = = = = = =| | | | | | | | | | | | | | (6) UDP Media | | | | | | | Packet | (7) UDP Media | | | | | |===============>>>| Packet | | | | | | |===================>>>| |=| |====>>>| | | ---- ---- | Figure 9 - Establishing Outbound UDP Paths On successfully opening the port, the Proxy Interface Agent indicates Davies, Read, Cordell [Page 21] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 to the Proxy Server the identity of the port and its address (2). The Proxy Server is then able to issue the necessary signalling commands to open a media channel (e.g. H.245 Open Logical Channel and Open Logical Channel Ack in the case of H.323) containing the private IP address and port on the Proxy Interface Agent to which the terminal should send its UDP data (3). On reception of this message, the Proxy Interface Agent relays it to the terminal using the connection established previously for this purpose (4). The terminal can now start sending RTP and RTCP UDP packets to the Proxy Interface Agent (5). However, because all RTP and RTCP packets are sent to the allocated well-known ports on the Proxy Server, and the source of the packets as viewed by the Proxy Server will have been essentially randomised by the NAPT, without additional information, the Proxy Server will not be able to associate the RTP/RTCP packets with the correct call. Therefore, prior to forwarding the packets to the Proxy Server, the Proxy Interface Agent must send Probe Packets that contain the token specified by the Proxy Server when the connection was initially configured (6). In addition to creating a private-to-public address mapping in the NAPT, the presence of the token allows the Proxy Server to associate the UDP packets received from the source of the Probe Packets with the correct logical media channel. Note that it is preferable to defer sending the Probe Packets for as long as possible as if they are sent too early the address mappings created in the NAT may time out before any media data is sent. Also, it is necessary to be aware that, being UDP, the Probe Packets may be lost. It is therefore necessary to have the ability to send more than one Probe Packet for a given connection. Once a Probe Packet has been sent, the Proxy Interface Agent can relay UDP data received from the terminal to the Proxy Server (7). (Alternatively, as a variation of this method, the token information can be multiplexed into each UDP packet that is sent.) On successfully opening the port, the Proxy Interface Agent indicates to the Proxy Server the identity of the port and its address (2). The Proxy Interface Agent immediately starts sending Probe Packets containing the specified token. This action subsequently allows the Proxy Server to associate RTP/RTCP media received from this NAT modified address and port with the correct call. Note that it is may be necessary to send Probe Packets at regular intervals in order to prevent the address mappings created in the NAT from timing out before any media data is sent. Such action also allows for the possibility that any UDP based Probe Packet may be lost. The Proxy Server is then able to issue the necessary signalling commands to open a media channel (e.g. H.245 Open Logical Channel and Open Logical Channel Ack in the case of H.323) containing the private IP address and port on the Proxy Interface Agent to which the terminal should send its UDP data (4). On reception of this message, the Proxy Interface Agent relays it to the terminal using the connection established previously for this purpose (5). The terminal can now start sending RTP and RTCP UDP packets to the Davies, Read, Cordell [Page 22] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 Proxy Interface Agent (6). The Proxy Interface Agent can relay UDP data received from the terminal to the Proxy Server (7). 5.4.7. Establishing Inbound H.323 UDP Paths The method of operation for an inbound UDP connection is similar to that of an outbound connection. A typical sequence of operations is shown in Figure 10. Terminal PIA Firewall & NAT Server | | ---- ---- | | (1) H.245 OLC / | | | | | | | OLC ACK | (2) H.245 OLC / | | | | | | Ports = E(F) | OLC ACK | | | | | |= = = = = = = =>>>| Ports = E(F) | | | | | | |- - - - - - - - - - ->| |-| |- - >>>| | | | | | | | | | (3) Create UDP Port | | | | | | | (pair) | | | | | | | Token = 5678 | | | | | | |<<<-------------------| |-| |-------| | | | | | | | | | (4) UDP Ports = G(H) | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | | (5) UDP Probe Packet | | | | | | | Token = 5678 | | | | | | |===================>>>| |=| |====>>>| | |===================>>>| |=| |====>>>| | | | | | | | | | (6) UDP Media | | | | | | (7) UDP Media | Packet | | | | | | Packet |<<<===================| |=| |=======| |<<<===============| | | | | | | | ---- ---- | Figure 10 - Establishing Inbound UDP Connections On reception of protocol signalling that indicates an address and port on which UDP packets are to be received (1, 2), the Proxy Server instructs the Proxy Interface Agent to open a port (or port pair) that can be used to send UDP data from the Proxy Interface Agent to the terminal (3). The Proxy Interface Agent will inform the Proxy Server of the identity of the UDP ports that it has opened (4), (although the information is of no immediate use to the Proxy Server). Further, to create the public-to-private address mapping in the NAT, as part of this command the Proxy Server requests that the Proxy Interface Agent send Probe Packets for this connection to the Proxy Server containing a specific token. This creates a private-to-public address mapping in the NAT that in turn acts as a Davies, Read, Cordell [Page 23] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 public-to-private address mapping for data sent in the reverse direction (5). The Proxy Server uses the token in the Probe Packet to determine which NAT address and port it should use to send UDP data to for this session. The Proxy Server may now start sending UDP media to this address (6). The NAT will relay this to the Proxy Interface Agent, which will in turn relay it to the terminal, thus completing the connection (7). 5.4.8. H.323 Post Call Clean Up When the UDP connections are no longer required, the Proxy Server will instruct the Proxy Interface Agent to close the associated sockets that it uses to connect to the terminal. Any private-to-public address mappings in the NAPT will eventually time out as no data will be passing through them. Aspects of this phase are shown in Figure 11. Terminal PIA Firewall & NAT Server | | ---- ---- | | (1) H.245 TCP | | | | | | | Connection | | | | | | | Closed | (2) Close Sub- | | | | | | -+-+-+-+->>>| Channel (H.245) | | | | | | |------------------->>>| |-| |---->>>| | | | | | | | | (3) H.225 | | | | | | | RELEASE COMPLETE | (4) H.225 | | | | | |= = = = = = = =>>>| RELEASE COMPLETE | | | | | | |- - - - - - - - - - ->| |-| |- - >>>| | | | | | | | | (6) H.225 TCP | (5) Close Sub- | | | | | | Connection | Channel (H.225) | | | | | | Closed |<<<-------------------| |-| |-------| | <<<-+-+-+-+-| | | | | | | | | | | | | | | (7) Close UDP | | | | | | | Ports | | | | | | |<<<-------------------| |-| |-------| | | ---- ---- | Figure 11 - Post Call Clean Up 6. Primitives This section lists the various primitives that are necessary to implement the protocol. All of these primitives are exchanged on the control sub-channel within the Multiplexed Connection. 6.1 Registration Direction Davies, Read, Cordell [Page 24] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 Proxy Interface Agent to Proxy Server Description Sent by the Proxy Interface Agent to the Proxy Server when the Multiplexed Connection is first established. This allows the Proxy Interface Agent to announce its presence, and indicate the version of the protocol it supports. Request Parameters Version Response Parameters Success/Failure 6.2 Create TCP Listener Direction Proxy Server to Proxy Interface Agent Description Instructs the Proxy Interface Agent to create a persistent TCP listener port. When an entity connects to the TCP port thus created, the Proxy Interface Agent will create a new socket and a new sub-channel within the multiplexed connection. Request Parameters The port to listen on. Response Parameters Success/Failure. 6.3 Create TCP sub-channel with TCP Listener Direction Proxy Server to Proxy Interface Agent Description Instructs the Proxy Interface Agent to create a listening port that shall only receive a single TCP connection. Once a connection has been received on the listening port, the listening port will be automatically closed by the Proxy Interface Agent. Any communication received on the new socket will be forwarded to the Proxy Server on the specified sub-channel. This will Davies, Read, Cordell [Page 25] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 typically be used to receive an H.245 connection from the terminal. Request Parameters Sub-channel identifier. Response Parameters The address and port of the listening connection. 6.4 Create TCP sub-channel - PS to PIA Direction Proxy Server to Proxy Interface Agent Description Allows the Proxy Server to create a sub-channel within the Multiplexed Connection to the Proxy Interface Agent for the carriage of signalling protocols. The Proxy Interface Agent will create a TCP connection on to the specified address. Request Parameters Sub-channel identifier. The address and port to connect to on the terminal. Response Parameters Success/failure. 6.5 Create TCP sub-channel - PIA to PS Direction Proxy Interface Agent to Proxy Server Description Allows the Proxy Interface Agent to create a sub-channel within the Multiplexed Connection to the Proxy Server. This will typically be used when a previously activated listener has received a new connection. Request Parameters Sub-channel identifier. The address and port of the listening socket that resulted in the Davies, Read, Cordell [Page 26] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 message being sent. The address and port on the terminal that created the connection. Response Parameters Success/Failure 6.6 Create UDP Port / Port Pair Direction Proxy Server to Proxy Interface Agent Description Instructs the Proxy Interface Agent to generate a UDP port or a UDP port pair. Request Parameters Whether a single port or a port pair is required. Probe Packet token. One or more addresses and ports to which Probe Packets and data packets are sent on the Proxy Server. Optionally one or more addresses and ports to which packets received from the Proxy Server by the Proxy Interface Agent should be forwarded on to the terminal. Response Parameters The address and ports of the sockets on the Proxy Interface Agent. 6.7 Modify UDP Port / Port Pair Direction Proxy Server to Proxy Interface Agent Description Allows the parameters of a previously created UDP Port / Port Pair to be modified. For example, an RTP session may initially be uni-directional, but later be required to be bi-directional. Request Parameters One or more Proxy Interface Agent addresses and ports that are to be updated. Davies, Read, Cordell [Page 27] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 One or more addresses and ports to forward UDP packets on to the terminal. Response Parameters Success/failure. 6.8 Close TCP Listener Direction Proxy Server to Proxy Interface Agent Description Instructs the Proxy Interface Agent to close a TCP listener. Request Parameters The address and port of the listener to close. Response Parameters No Response 6.9 Close TCP sub-channel Direction Proxy Server to Proxy Interface Agent Description Instructs the Proxy Interface Agent to close the specified sub-channel and its associated sockets. Request Parameters The identity of the sub-channel to close. Response Parameters No Response 6.10 Close UDP Ports Direction Proxy Server to Proxy Interface Agent Description Davies, Read, Cordell [Page 28] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 Instructs the Proxy Interface Agent to close a UDP session. Request Parameters One or more addresses and ports on the UDP sockets on the Proxy Interface agent to close. Response Parameters No Response 7. Multiplex Structure of the Multiplexed Connection This section gives a brief description of the format of data on the Multiplexed Connection. The multiplex scheme requires the boundaries of individual data packets within the multiplexed stream to be identified, and the sub-channel to which the data relates to be identified. An example of such a packetising format is shown in Figure 12. -------------------- | | | Data Boundary | | Information | | e.g. TPKT Header | | | -------------------- | | | Sub-Channel | | Identifier | | | -------------------- | | | Data | | | -------------------- Figure 12 - Example Format of Data Packets within the Multiplexed Connection 8. Further Benefits of the Scheme:Security, QoS and Management Providing a MoIP aware device both in the enterprise and at the service provider allows the system to realise a number of other benefits in addition to enabling firewall/NAT traversal. Two of the most obvious are QoS and management support. With the Proxy Interface Agent and the Proxy Server both handling media packets, they are able to implement QoS mechanisms that would be difficult to deploy if these systems were not present. At their Davies, Read, Cordell [Page 29] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 simplest, routers could prioritise packet forwarding based on the source and destination addresses/ports of the UDP packets. A more sophisticated solution would be to use an IP ToS based scheme. The presence of the Proxy Server can also be used as a bridge between one QoS scheme and another, meaning that the enterprise can use a different QoS scheme to the network provider used by the service provider. This is important as the enterprise may be served by more than one service provider. Implementing security may be simplified due to the presence of the Proxy Server. For example, a web of trust can be built up between terminals and their home Proxy Server, and between different Proxy Servers. For example, Proxy Server 1 may be able to authenticate the identity of a terminal within its domain. Proxy Server 2 may not be aware of that terminal, but may trust Proxy Server 1 to specify the identity of the terminal. Similarly, the task of encryption may be broken into multiple segments along the media path. This allows different encryption methods to be used on different legs of a call, which will enable the maximum likelihood of interworking. The presence of the Proxy Server enables other benefits to the service provider. For example, the service provider is able to compare the bandwidths requested in the signalling phase with the bandwidth actually used in the call. This may be used to ensure that the enterprise is staying within its Service Level Agreement. It also helps with the QoS question as the provider knows precisely how much bandwidth is being used rather than having to rely on figures quoted in the signalling. Using this information the Proxy Server may be able to block future calls until sufficient bandwidth becomes available. Related to this, the service provider is able to monitor packet loss statistics. This can be used to relate customer experience to system performance allowing the system to be optimally tuned. The configuration of the system also facilitates effective outsourcing of the enterprises MoIP needs. Thus the service provider can act as an Applications Service Provider to the enterprise, and is able to provide direct customer support without having a continuous presence on the customer site. 9. Security Considerations From a security point of view, the scheme adds two new devices that are potential points of attack. The Proxy Interface Agent will sit behind the enterprises firewall (and possibly NAT). Rules within the firewall should prevent external devices establishing TCP connections to it, and can ensure that the only outbound TCP connections it can make are to the Proxy Server. The firewall also restricts the Proxy Interface Agent to only receiving UDP packets from the Proxy Server, and hence this route of attack is limited. Davies, Read, Cordell [Page 30] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 The Proxy Server will be in public space, but can be protected by a firewall in much the same way as a service provider would protect a hosted web or mail server on behalf of an enterprise client. The Proxy Server will only listen on specific TCP ports and will typically require authentication before it provides any further service. The Proxy Server will only be expecting to receive UDP data on specific ports, and the external firewall can enforce this. If further confidence is needed in the system, the Proxy Interface Agent can monitor and log the commands exchanged with the Proxy Server. This can be done in a protocol agnostic way. If more confidence is required, the Proxy Interface Agent can be made to restrict the internal/private addresses and ports to which it makes connections to, or (/and) may be made fully protocol aware. In the latter variant, the Proxy Interface Agent will still create ports as instructed by the Proxy Server, but will not implement packet forwarding between the inbound and outbound ports until it has observed appropriate signalling. By adopting this approach, the operation of the Proxy Server is unaffected by whether the Proxy Interface Agent is protocol aware or agnostic. 10. Conclusion 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 public network via firewall and NAT 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 NAT function interpreting or understanding the communication protocols being used. 11. Acknowledgements We would like to thank Ditta Khan, Barry Scott and Greg Adams in the team at Ridgeway Systems & Software for helping to architect, implement and verify this method. 12. Authors Addresses Steven Davies Ridgeway Systems & Software 66 Suttons Business Park Reading, Rg6 1AZ England sdavies@ridgeway-sys.com Davies, Read, Cordell [Page 31] Internet Draft Non Protocol Aware Firewall & NAT Traversal March 2001 Stephen Read Ridgeway Systems & Software 66 Suttons Business Park Reading, Rg6 1AZ England sread@ridgeway-sys.com Pete Cordell Ridgeway Systems & Software 66 Suttons Business Park Reading, Rg6 1AZ England pete@tech-know-ware.com 13. 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. Davies, Read, Cordell [Page 32]