MIDCOM Working Group P. Sijben Internet Draft Lucent Technologies Document: June 2001 Expires January 2002 Threat analysis of architectures for firewall traversal. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract Recently a number of architectures have been proposed to allow sessions with multiple data streams to pass through firewalls. Examples of such sessions are IP telephony and multimedia sessions. This draft provides a threat analysis on three architectures offered to address this issue. 2. Conventions used in this document Domain: a bounded entity within which all encompassed constituent elements are under common ownership, operation and management. 3. Introduction A number of architectures are currently discussed to allow sessions with multiple data streams to pass through firewalls. Examples of such sessions are IP telephony and multimedia sessions. These architectures have the following aims: 1. On demand creation of pinholes in firewalls for the traversal of: o signalling streams o media streams carried over UDP o Fixing the association of the media stream with the primary (signaling) stream that is broken by autonomous network address translators. Sijben Expires November 2001 1 Threat analysis for firewall traversal June 2001 A security risk is involved with the opening of holes in a firewall. In this draft an analysis of the security of three architectures is given. It is shown to what degree each architecture compromises the security provided by a firewall. 3.1 Threats to guard against Prior to the analysis of the three architectures the threats that need to be protected against need to be identified. Enterprises (and individuals) that deploy firewalls use this perimeter defence mechanism to ward off: 1. unauthorized access to both restricted and public connected systems 2. denial-of-service attacks on connected restricted and public systems 3. unauthorized access to restricted information 4. attacks to subvert end-user terminals (e.g. through Trojan horses) Restricted connected systems are deemed virtually all computers owned by the company. The systems themselves are often important if not essential to the running of the company. The disclosure of proprietary information contained in the systems to the outside world may be considered harmful to a company or individuals. On-line information accessible through the systems is often considered proprietary and access to them must be restricted as well. Firewalls can play a part in guarding against these threats. The architectures for firewall traversal analysed in this draft will be evaluated in the context of these 4 threats. It will be investigated whether they increase the 4 kinds of threats identified before. 3.2 Threats that a firewall cannot ward off There are threats that are outside the realm of threats that a firewall can ward off and hence are beyond the benchmark of this analysis. The general unavoidable threats are security threats from inside parties. Should persons on the inside of the security perimeter be determined to leak sensitive information of sabotage systems, very little can be done against it. Allowing persons access to telecommunication systems poses a threat to the security, integrity and privacy of valuable data and services. This threat is present in the availability of any communications system such as email, telephone and fax or just even physical access to the premises from which data carriers can be taken. Sijben Expires January 2002 2 Threat analysis for firewall traversal June 2001 Where automated systems can play a role is in stopping the inadvertent disclosure of information or catching electronic transfer of information (into or out of the perimeter) that is not deemed in accordance with the company's rules. 4. Architectures In this draft a threat analysis is given of three architectures for firewall traversal: 1. the Out-of-domain intermediary architecture as described in [3] 2. the embedded agent architecture as described in [4] 3. the Meet-me architecture as described in [5] 4.1 Out-of-domain agent architecture In the out-of-domain architecture as shown in Figure 1 (copied from [3]) uses a proxy interface agent that is places as a trusted element in the intranet side of a firewall. The firewall is configured to allow traffic to and from the proxy. A proxy server outside of the trusted intranet is configured to control the proxy. ___ ____ ____ ____ ____ | 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 1. out-of-domain architecture Sijben Expires January 2002 3 Threat analysis for firewall traversal June 2001 In this approach a preconfigured path exists through the firewall and NAT that will allow the terminal to contact the proxy server. Through this proxy server the terminal can request applications (such as enabled by SIP but also others) that require additional media flows. Normally such flows would be blocked by the firewall or re-addressed by the NAT, both issues may render the media stream useless. The approach described in [3] shows how the proxy server can instruct the proxy interface agent to encapsulate the media flow in a stream to the proxy server. This stream is preconfigured in such a way that the proxy server will receive anything that is encapsulated in the right manner. Through this tunnel the proxy server can on request of the terminal open flows that are tunnelled to the proxy server and from there sent onto the Internet. Flows from the Internet can be received in a similar way. This approach has the advantages that the firewall in place does not need to be replaced and that the proxy does not need to know about any application-level protocols. The major disadvantage of this approach is that compromise of the out-of-domain proxy server or denial-of-service attacks against it may be very disruptive to communication controlled by the proxy server. This threat is increased because the proxy server is outside the control of the managers of the intranet. 4.2 Embedded agent architecture The embedded agent architecture is summarised in Figure 2 (copied from [4]). +--------+ | RSIP | hosts ------+ gate- +----- public network | way | +--------+ Figure 2. embedded agent This approach uses an agent that is to be embedded inside edge routers or address translators. Any host that is pre-authorised or authorised on demand can request a lease of an address (with all ports) or just one single port from the RSIP gateway for incoming or outgoing communication. Big advantage of this approach is that the agent is application agnostic. This has the obvious advantage that any Internet application may be passed. The two disadvantages of this approach are that Sijben Expires January 2002 4 Threat analysis for firewall traversal June 2001 (1) any compromise of the terminal may compromise the network because the terminal simply requests flows that can not be verified. This threat can be shown through the following example: Imagine the scenario where a user receives an e-mail containing a virus that installs back-orifice on the user's PC and requests an incoming stream to allow for its control... This disadvantage may be reduced IF strong authentication of requests is employed (see below). (2) because of the co-location of the control agent and the middlebox, a denial-of-service attack on the agent immediately impacts the availability of the middlebox and vice-versa. 4.3. Meet-me architecture In the meet-me architecture as shown in Figure 3, an in-domain application server is in control of the middlebox. The figure shows two hosts that wish to communicate. A traditional firewall function that may be configured to pass signaling to well known ports from semi-trusted addresses. A controllable middlebox that can be asked to pass certain media flows through some application server. The middlebox and the firewall MAY be aspects of the same physical entity. Also there MAY be more than one application servers for different applications or for redundancy and load sharing. Internet . Intranet +----+ +----+ +------+ +------+ | | sig | | sig | | sig | | | +--..--+ FW +------+ AS +--------+ | | | | | | | | | |host| +----+ +--+---+ | | | | . MIDCOM | | host | | | .+-----------+ | | | | .| | | | | media+--+-+ media | | | +--..--+ +----------------------+ | | | | MB | | | +----+ +----+ +------+ UA - user agent, e.g. an IP phone FW - firewall MB - Middle box, e.g. the proposed RTP gateway AS - Application Server sig - call setup signalling media - media stream Figure 3. meet-me architecture User agents at hosts can communicate with appropriate Application Servers either directly or via preconfigured paths through firewalls at well known ports. The Application Servers understand the demands of the application and will communicate with the middlebox to arrange appropriate holes for the flows. Sijben Expires January 2002 5 Threat analysis for firewall traversal June 2001 STRONG AUTHENTICATION The application server can insist on strong authentication of both originating and terminating parties prior to requesting the holes to be opened. The users of an application should be authorised, not the host running the application. This approach will allow only applications that are deemed to be safe enough for which the parties are known. This may prevent world accessible inbound Back-Orifice ports even if they are disguised as VoIP sessions as the opening of the ports for this application needs explicit user authentication. The advantages of this approach are: (1) Compromise of the terminal has only limited impact as communication is still monitored and users of services can be authenticated. If this authentication is conveyed through a trusted computing platform connected to the user's host, the effect of a malicious virus on the user's system as shown above can be mitigated. (This may also benefit the embedded agent approach) (2) The effect of a denial-of-service attack limited because - the application server is relatively safe behind the firewall. By replicating application servers, a successful attack of one of them may only impact part of the communication. - denial-of-service attack on the middlebox may be combated by deploying multiple middleboxes which will provide alternative routes The disadvantage of this approach is that it requires application- level servers for every application that is to be allowed to communicate with the outside world. Security wise, this can be regarded as an advantage. 5. Conclusion Of the three architectures analysed in this draft the meet-me architecture seems to be the safest. It restricts communication with the Internet to a point where only authenticated users communicate freely. All inbound and outbound signalling may be monitored and validated before it reaches internal hosts. The effects of denial-of-service attacks is limited. Attack of the server has only limited success as opposed to the out-of-domain architecture. Attack of the middlebox also has limited success as opposed tot he embedded architecture. Outgoing traffic that may export sensitive internal information can be subject to authentication providing not necessarily the end of such practices but at least a trail of proof. 6. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Sijben Expires January 2002 6 Threat analysis for firewall traversal June 2001 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3. S. Davies, S. Read, P. Cordell "Traversal of non-Protocol Aware Firewalls & NATS", draft-davies-fw-nat-traversal-00.txt March 18, 2001 4. M. Borella, J. Lo, "Realm Specific IP: Framework" ,draft-ietf- nat-rsip-framework-05.txt, july 2000 5. P.A. Mart, P. Sijben, R. Swale, "Firewall Control Requirements", draft-tiphon-foglamps-01.txt . Author's Addresses Paul Sijben Lucent Technologies NV Huizen Netherlands Email: sijben@lucent.com Sijben Expires January 2002 7