P. Sijben Internet Draft W. van Willigenburg Document: M. de Boer Lucent Technologies Expires January 2002 July 2001 RTP proxies 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 This draft describes how a MEGACO controlled RTP proxy can be used to provide firewall traversal for media flows for SIP calls. The MEGACO profile described in this draft can be used to support any UDP flow. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2.1 Definitions Early media Media flowing in backward direction (to the caller) before the callee answers the call. Pinhole A passage through a middlebox that allows traversal of IP packets satisfying specific characteristics, i.e. source address/port, destination address/port and protocol. Sijben Expires January 2002 1 RTP proxys for firewall traversal July 2001 RTP proxy A host that transparently passes RTP streams. 3. Introduction Firewalls provide a means to control access to a network. The main reason to do this is to prevent unauthorised access. Authorised access must be impeded as little as possible. For reasons of security the majority of today's firewalls do not allow UDP traffic to pass. This hampers the deployment of Voice over IP (VoIP) and multimedia conferencing applications, such as those enabled by SIP [3], that use RTP [4] for media transport. As RTP runs over UDP it cannot pass these firewalls. To allow for a wide deployment of streamed media applications a mechanism is needed that will get the RTP streams through a firewall unimpeded while at the same time preserving the security provided by the firewall. This means that such streams must be authorised before the firewall will pass them. The ideal solution would be a firewall that is managed by a SIP proxy[9] , i.e. the SIP proxy requests the firewall to open pinholes for the traversal of RTP streams. 3.1 Approach Obviously, today's firewalls cannot open and close pinholes on demand. In this draft we present an intermediate solution for the firewall traversal of the RTP streams associated with a SIP call without the need to replace existing firewalls. A prerequisite for our solution is that the firewall should be configured such that SIP messages can traverse the firewall. A SIP proxy that is behind the firewall in the intranet should be able to communicate to SIP proxies in the internet. SIP messages coming from the Internet destined for the SIP proxy are allowed to enter the intranet and SIP messages sent by the SIP proxy are allowed to leave the intranet. All SIP signalling MUST go via the SIP proxy. Figure 1 shows the problem of getting RTP through a firewall. The figure shows one firewall. If there are multiple firewalls SIP and RTP do not need to go through the same firewall. +----------+ +-----------+ | | | | ------+ FIREWALL +---------+ SIP PROXY | SIP | | SIP | | | | +-----------+ ------+ | RTP | | +----------+ Figure 1: RTP is blocked by the firewall Sijben Expires January 2002 2 RTP proxys for firewall traversal July 2001 Figure 2 shows the solution we propose in this document. Parallel to the firewall an RTP proxy is placed. The RTP proxy is controlled by the SIP proxy via MEGACO [5]. It receives RTP packets from the internet and if they are allowed to pass, sends them out in the intranet and vice versa. +----------+ +-----------+ | | | | ------+ FIREWALL +---------+ SIP PROXY | SIP | | SIP | | +----------+ +-----+-----+ | +--------------------+ | MEGACO +-----+----+ | | ------+ RTP +------------- RTP | PROXY | RTP | | +----------+ Figure 2: RTP proxy parallel to firewall Alternatively the RTP proxy can be placed behind the firewall, such that the firewall is the only point of access to the intranet. In this case the firewall needs to allow the traversal of all RTP traffic to and from the RTP proxy. RTP traffic destined for another host than the RTP proxy will be blocked by the firewall. A prerequisite for this topology is that the firewall has good real time characteristics, it should not introduce unacceptable delay and jitter in the RTP stream. Figure 3 shows this alternative. Sijben Expires January 2002 3 RTP proxys for firewall traversal July 2001 +----------+ +-----------+ | | | | ------+ FIREWALL +---------+ SIP PROXY | SIP | | SIP | | | | +-----+-----+ | | | | | | MEGACO | | | | | +-----+----+ | | | | ------+ +---------+ RTP +------- RTP | | RTP | PROXY | RTP | | | | +----------+ +----------+ Figure 3: RTP proxy behind firewall In the remainder of this draft we will use the architecture of figure 2. Considering the wider implication of this model we can regard the RTP proxy as an instance of what is called a middlebox [10], this will be explored later in this draft. 3.2 Outline of the document Section 4 describes a protocol independent model of a VoIP call providing a framework for the subsequent protocol flows. From this model we derive the requirements for a protocol for middlebox control. Section 5 shows that this call model can be mapped to SIP and that MEGACO satisfies the requirements for a protocol controlling the RTP proxy. 4. Generic VoIP call flows The requirements on protocols for firewall traversal are determined by the applications that needs to traverse a firewall. The need for the MIDCOM WG was born from Voice over IP applications. In this draft we shall use the signalling flows necessary for VoIP applications as a guideline to derive these requirements. 4.1 VoIP derived Requirements on firewall traversal The needs of VoIP applications are a big driver for the work on firewall traversal. Therefore, a part of the requirements on firewall traversal can be derived from the behaviour of telephony- type applications. Unfortunately, these telephony applications derive their requirements from the behaviour of the PSTN. This is unfortunate but necessary since VoIP networks will coexist with PSTN networks and therefore these networks need to interwork with each other. A call originating from an IP phone may terminate in the Sijben Expires January 2002 4 RTP proxys for firewall traversal July 2001 PSTN. Users expect similar semantics of such a call as perceived with an all-PSTN call: - Users expect short post-pickup delays and expect to be able to speak (and be heard) promptly after they pick up the phone. So clipping of the first voice packets should be avoided. - The ability to pass early media for announcements before the call is accepted (this allows for free of charge announcements as the acceptance of the call is the usual trigger in the PSTN to start charging). While such expectations may be changed over time or defined differently for, for instance, calls between soft-clients the reality of deployments today is that one may expect to uphold these conventions. These semantics make the passing of firewalls an interesting affair as they impose constraints on the establishment of media streams and thus on the opening of pinholes in. The protocol for firewall traversal should satisfy the following requirements in order to create such semantics: * REQUIREMENT 1: A hole should be opened during call setup to allow media to flow in the backward direction for early media. * REQUIREMENT 2: Immediate opening of a hole when the called party picks up for a short post-pickup delay. * REQUIREMENT 3: To prevent fraud, the hole should only allow bi- directional media after the call is answered. The signalling flow in the next section refers to these requirements. 4.2 signalling flow In this section we provide a generic call setup flow to meet the requirements outlined above. This generic flow was derived from [11]. By describing the flow in generic terms we show a solution for firewall traversal that is independent from specific protocols so it will work equally well for SIP, H.323 and the next big thing. In the next section we show how SIP and MEGACO can be mapped to this generic flow. Figure 4 shows the network: Sijben Expires January 2002 5 RTP proxys for firewall traversal July 2001 . Internet . Intranet +----+ +----+ +------+ +------+ ------ | | sig | | sig | | sig | | / \ | +--..--+ FW +------+ AS +--------+ +------- \ | | | | | | | | / \ | UA | +----+ +--+---+ | | | | | | . MIDCOM | | PSTN | | | | | .+-----------+ | GW | | PSTN | | | .| | | | | | | media+--+-+ media | | | | | +--..--+ +----------------------+ +------ / | | | MB | | | \ / +----+ +----+ +------+ \ / . ------ . Figure 4 UA - user agent, e.g. an IP phone FW - firewall MB - Middle box, e.g. the proposed RTP proxy AS - Application server PSTN GW - gateway into the PSTN sig - call setup signalling media - media stream The signalling path between the UA and the AS will traverse other application servers and the media path will traverse other middleboxes, which are not explicitly shown here. There may be multiple MB's at the edge of the intranet. The AS must inform the UA which MB to use. The generic message flow necessary to set up a call is as follows. Sijben Expires January 2002 6 RTP proxys for firewall traversal July 2001 UA AS MB PSTN GW PSTN | | | | | | CallRequest | | | | |------------------->| | | | | | TransportResvRequest | | | | |--------------------->| | | | | TransportResvConfirm | | | | |<---------------------| | | | | CallRequest | | | | |----------------------------->| | | | | | CallRequest | | | | |------------>| | | | | | | | | | Ringing | | | CallReport.Ringing |<------------| | |<-----------------------------| | | | TranspEstablishReq | | | | |--------------------->| | | | | TranspEstablishConf | | | | |<---------------------| | | | CallReport.Ringing | | | | |<-------------------| | | CallConfirm | | | CallConfirm | |<------------| | |<-----------------------------| | | | TransportIndication | | | | |--------------------->| | | | CallConfirm | | | | |<-------------------| | | | | | | | | Figure 5 UA -> AS: CallRequest(called party ID, calling party ID, calling party authorisation token, offered media information) The AS authorises the calling party by verifying its authorisation token. The offered media information indicates what media streams the calling party wants to establish. AS -> MB: TransportReservationRequest(offered media information) The AS uses the offered media information from CallRequest to inform the MB about the media flows the UA is offering to send and receive. The MB can now prepare for sending and receiving media on the UA side and offers its address and port for the PSTN GW side. To allow for early media the MB should open a hole for the media in backward direction now (REQUIREMENT 1). This also supports a short post pick-up delay as the backward media flow is in place as soon as the called party picks up (REQUIREMENT 2). Sijben Expires January 2002 7 RTP proxys for firewall traversal July 2001 MB -> AS: TransportReservationConfirm(committed media information UA side, offered media information PSTN GW side) Confirming this request means the MB has committed to support the media flows. The AS now has information on the media flows the MB is willing to send and receive on the PSTN GW side so these can be presented to the PSTN GW. The MB also provides the address and ports on which it wants to receive media flows from the UA. AS -> PSTN GW: CallRequest(called party ID, calling party ID, offered media information) The PSTN GW now knows the media flow properties the UA (passed through the MB) is willing to send and receive and can match its own offer. It can also setup the call to the PSTN. Note that at this time it is possible to send early media from the PSTN assuming all intermediate nodes on the media path to the UA accept incoming media from any address. PSTN GW ->PSTN: CallRequest(called party ID, calling party ID) The PSTN sets up the call in the normal fashion. PSTN -> PSTN GW: CallReport.Ringing() The PSTN indicates that the remote phone is ringing. By now the circuit side is connected. The PSTN GW can establish the media flows with the UA. It will pass the codec(s) it will use to send and receive media and will give its own media address and port. PSTN GW -> AS: CallReport.Ringing(committed media information both sides) The AS now can inform the MB of the remaining media flow information. AS -> MB: TransportEstablishementRequest(committed media information PSTN GW side) The MB now has media information from both sides. The MB can now offer its address and port from which it will send media to the UA side. MB -> AS: TransportEstablishmentConfirm(committed media information UA side) Sijben Expires January 2002 8 RTP proxys for firewall traversal July 2001 The AS now can tell the UA the address on the MB to send its media to and which of its offers for receiving media has been taken up. AS -> UA: CallReport.Ringing(committed media information both sides) The UA now can free resources reserved for any of the media flow proposals it made that have not been accepted and wait for the call to be answered. PSTN -> PSTN GW: CallConfirm() The call is answered. PSTN GW -> SSw: CallConfirm() The AS may start to charge for the call now. In order to prevent fraud it may have chosen earlier not to connect the forward media channel, so it must be opened now (REQUIREMENT 3). AS -> MB: TransportIndication() The MB will now allow bi-directional media to pass. AS -> UA: CallConfirm() The caller is notified that the callee picked up the phone. 5 Implementation In this section we show how the generic flow can be mapped to a network using SIP for call setup and MEGACO for transport establishment. We show that a subset of MEGACO is sufficient to satisfy the requirements imposed on firewall traversal. Figure 6 shows a network operated by a service provider who offers access from the Internet to the PSTN. This network is derived from the generic archticture shown in Figure 4 by replacing the middlebox with an RTP proxy and the application server with a SIP proxy. The service provider network is secured from the Internet by a firewall. For brevity this figure does not show the PSTN. Sijben Expires January 2002 9 RTP proxys for firewall traversal July 2001 . Internet . Service provider network . +------+ +------+ +-------+ +-------+ | | | FIRE | | SIP | | | | +--..--+ WALL +------+ PROXY +---------+ | | | SIP | | SIP | | SIP | | | | +------+ +---+---+ | | | | . | | | | | . | | PSTN | | UA | . +--------------+ | GW | | | . | MEGACO | | | | . | | | | | +--+------+ | | | | | RTP | | | | +--..--+ PROXY +---------------------+ | | | RTP | | RTP | | +------+ +---------+ +-------+ Alice . Figure 6 The SIP proxy receives all SIP messages for calls crossing the boundary between the Internet and service provider network. It parses the SDP in the messages to find out on which addresses and ports the parties want to receive RTP streams. Via MEGACO it requests the RTP proxy to open holes to allow traversal of the RTP between the parties of a call. The holes are defined by the sink address and port specified in the SDP. The RTP proxy replies to the SIP proxy which IP addresses and ports it has opened. The SIP proxy then replaces the IP addresses and ports in the SDP with the IP addresses and ports from the RTP proxy in the SIP message and sends it to the intended recipient. Example: The SIP proxy receives the following SDP in a SIP INVITE: c=IN IP4 111.1.1.1 m=audio 1110 RTP/AVP 0 4 The SIP proxy requests the RTP proxy to open a hole. The RTP proxy replies that it opened IP address 10.2.2.44 and port 2002 with the following SDP: c=IN IP4 10.2.2.44 m=audio 2002 RTP/AVP 0 4 The SIP proxy puts the following SDP in the INVITE that it sends to the intended recipient: c=IN IP4 10.2.2.44 m=audio 2002 RTP/AVP 0 4 Sijben Expires January 2002 10 RTP proxys for firewall traversal July 2001 When a call terminates, i.e. the SIP proxy receives a BYE, then the SIP proxy will request the RTP proxy via MEGACO to remove the hole. The SIP proxy MUST be stateful as it must close the hole in the RTP proxy when a call terminates. Note that the RTP proxy terminates and originates media streams on the IP level and NOT on the RTP level. The RTP proxy does not encode nor decode media streams. It transparently passes all RTP and RTCP packets. This makes this approach generic and usable for any protocol not just RTP and RTCP. 5.1 SIP/MEGACO flow This section shows the resulting SIP/MEGACO flow for call setup and tear down. In this flow Alice dials the E.164 number +31 20 1234567. For brevity we do not show the signalling in the PSTN. 5.1.1 Call setup Alice (UA) SIP proxy RTP proxy PSTN GW 111.1.1.1 10.2.2.33 222.2.2.44/10.2.2.44 10.2.2.2 |<=== SIP ====>|<=== MEGACO ====>| | | |<============= SIP ===========>| | | | | | 1 INVITE | | | |------------->| | | | | 2 Add T1,T2 | | | |---------------->| | | | 3 Reply | | | |<----------------| | | | | 4 INVITE | | |------------------------------>| | | | 5 180 | | |<------------------------------| | | 6 Modify T2 | | | |---------------->| | | | 7 Reply | | | |<----------------| | | 8 180 | | | |<-------------| | | | | | 9 200 | | |<------------------------------| | | 10 Modify T1,T2| | | |---------------->| | | | 11 Reply | | | |<----------------| | | 12 200 | | | |<-------------| | | | 13 ACK | | | |------------->| | | | | 14 ACK | | | |------------------------------>| Figure 7: Call setup Sijben Expires January 2002 11 RTP proxys for firewall traversal July 2001 The RTP proxy has a public IP address for receiving media flows from the Internet and a private address to receive media flows from the service provider network. Below the message details are given. For each message the mapping to a primitive from the generic call flow is shown between brackets. 1 INVITE Alice --> SIP proxy (CallRequest) INVITE sip:+31201234567@telco.com;user=phone SIP/2.0 Via: SIP/2.0/UDP a.wonderland.com:5060 From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone Call-ID: 12345678@a.wonderland.com CSeq: 1 INVITE Contact: sip:Alice@wonderland.com Content-Type: application/sdp Content-Length: v=0 o=Alice 123456 123456 IN IP4 a.wonderland.com c=IN IP4 111.1.1.1 m=audio 1110 RTP/AVP 0 4 2 Add T1,T2 SIP proxy --> RTP proxy (TransportReservationRequest) The SIP proxy requests the RTP proxy to create 2 terminations: one termination to send and receive media streams to and from Alice (111.1.1.1:1110) and one termination to send and receive media streams to and from the PSTN GW (address and port not known yet). MEGACO/1 [10.2.2.33]:55555 Transaction = 1 { Context = $ { Add = $ { Media { Stream = 1 { LocalControl { Mode = SendOnly }, Local { ; receive RTP from Alice here v=0 c=IN IP4 222.2.2.44 ; public IP address of RTP proxy m=audio $ RTP/AVP 0 4 }, Remote { ; send RTP to Alice here v=0 c=IN IP4 111.1.1.1 m=audio 1110 RTP/AVP 0 4 } } Sijben Expires January 2002 12 RTP proxys for firewall traversal July 2001 } }, Add = $ { Media { Stream = 1 { LocalControl { Mode = ReceiveOnly }, Local { ; receive RTP from the PSTN GW here v=0 c=IN IP4 10.2.2.44 ; private IP address of RTP proxy m=audio $ RTP/AVP 0 4 } } } } } } The stream to Alice is created in SendOnly mode and the stream to the PSTN GW in ReceiveOnly mode. This allows for early media streaming from the PSTN GW towards Alice. The media specification in the Local and Remote descriptors comes directly from the SDP in the INVITE. Most of this is superfluous for the RTP proxy as it does not need to decode/encode the media. All it needs are the address and port. The termination for the PSTN GW does not have a Remote descriptor as it is not known yet on which address and port the PSTN GW wants to receive RTP. 3 Reply RTP proxy --> SIP proxy (TransportReservationConfirm) The RTP proxy assigns 222.2.2.44:2000 to receive RTP from Alice and 10.2.2.44:2002 to receive RTP from the PSTN GW. The RTP proxy has assigned ports 2001 and 2003 to receive RTCP from Alice and the PSTN GW. An RTCP port should be (RPT port + 1) and RTP port should be even. MEGACO/1 [10.2.2.44]:55555 Reply = 1 { Context = 1 { Add = T1 { Media { Stream = 1 { Local { ; receive RTP from Alice here v=0 c=IN IP4 222.2.2.44 m=audio 2000 RTP/AVP 0 4 } } Sijben Expires January 2002 13 RTP proxys for firewall traversal July 2001 } }, Add = T2 { Media { Stream = 1 { Local { ; receive RTP from the PSTN GW here v=0 c=IN IP4 10.2.2.44 m=audio 2002 RTP/AVP 0 4 } } } } } } Figure 8 shows the configuration of the RTP proxy at this point allowing early media from the PSTN GW to the UA. It shows the IP addresses and ports in the Local and Remote descriptors of terminations T1 and T2. +--------+ +---------------------------+ +---------+ | | | T1 RTP proxy T2 | | | | | +----------+ +---------+ | | | | |SendOnly | | RecvOnly| | | | | +----------+ +---------+ | | | | |local | | remote| | | | | |222.2.2.44| | | | | | UA | |2000 | | | | PSTN GW | | | +----------+ +---------+ | | | | |remote | | local| | | | |<-------|111.1.1.1 |<-----|10.2.2.44|<-----| | | | RTP |1110 | | 2002| RTP | | | | +----------+ +---------+ | | +--------+ +---------------------------+ +---------+ Figure 8 According to the RFC 3015 [5], a media gateway (MG) will only reply with all codecs in case ReserveValue is set to true and the MG has reserved all resources for these codecs. To comply to MEGACO the SIP proxy could set ReserveValue to true even though the RTP proxy does not need to reserve any resources for the codecs as it will not do encoding or decoding. As stated before the media specifications are not really of importance for the RTP proxy, so it doesn't matter what codecs are in the reply as long as it states the address and port. It could be useful, however, when you use the RTP proxy for policy enforcement, e.g. do not allow video streams to enter the network. 4 INVITE SIP proxy --> PSTN GW (CallRequest) Sijben Expires January 2002 14 RTP proxys for firewall traversal July 2001 The SIP proxy replaces the address and port in the SDP of the INVITE with the address (10.2.2.44) and port (2002) in the Local descriptor of termination T2. A Record-Route header is inserted in the INVITE to indicate that the SIP proxy wants to stay in the signalling path. INVITE sip:+31201234567@telco.com;user=phone SIP/2.0 Via: SIP/2.0/UDP sp.telco.com:5060;branch=1 Via: SIP/2.0/UDP a.wonderland.com:5060 Record-Route: sip:+31201234567@telco.com;user=phone;maddr=sp.telco.com From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone Call-ID: 12345678@a.wonderland.com CSeq: 1 INVITE Contact: sip:Alice@wonderland.com Content-Type: application/sdp Content-Length: v=0 o=Alice 123456 123456 IN IP4 a.wonderland.com c=IN IP4 10.2.2.44 m=audio 2002 RTP/AVP 0 4 5 180 Ringing PSTN GW --> SIP Proxy (CallReport.Ringing) The PSTN GW (10.2.2.2) indicates that the called party is ringing and provides the SDP specifying the media that the called party wants to receive. Alice will now hear ringing or any announcements coming from the PSTN. As SDP is carried in a provisional response it should be acknowledged by a PRACK [8] to guarantee the delivery of the 180 response. For brevity we have not included PRACK in our signalling flow. SIP/2.0 180 Ringing Via: SIP/2.0/UDP sp.telco.com:5060;branch=1 Via: SIP/2.0/UDP a.wonderland.com:5060 Record-Route: sip:+31201234567@telco.com;user=phone;maddr=sp.telco.com From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 1 INVITE Contact: sip:+31201234567@telco.com;user=phone Content-Type: application/sdp Content-Length: v=0 o=PSTNGW 654321 654321 IN IP4 gw.telco.com c=IN IP4 10.2.2.2 m=audio 2222 RTP/AVP 0 Sijben Expires January 2002 15 RTP proxys for firewall traversal July 2001 6 Modify T2 SIP proxy --> RTP proxy (TransportEstablishmentRequest) The SIP proxy uses the SDP from the 180 response to specify the Remote descriptor of termination T2. MEGACO/1 [10.2.2.33]:55555 Transaction = 2 { Context = 1 { Modify = T2 { Media { Stream = 1 { Remote { ; send RTP to the PSTN GW here v=0 c=IN IP4 10.2.2.2 m=audio 2222 RTP/AVP 4 } } } } } } 7 Reply RTP proxy --> SIP proxy (TransportEstablishmentConfirm) MEGACO/1 [10.2.2.44]:55555 Reply = 2 { Context = 1 { Modify = T2 } } Figure 9 shows the configuration of the RTP proxy at this point. The Remote descriptor of termination T2 is now filled in. +--------+ +---------------------------+ +---------+ | | | T1 RTP proxy T2 | | | | | +----------+ +---------+ | | | | |SendOnly | | RecvOnly| | | | | +----------+ +---------+ | | | | |local | | remote| | | | | |222.2.2.44| | 10.2.2.2| | | | UA | |2000 | | 2222| | PSTN GW | | | +----------+ +---------+ | | | | |remote | | local| | | | |<-------|111.1.1.1 |<-----|10.2.2.44|<-----| | | | RTP |1110 | | 2002| RTP | | | | +----------+ +---------+ | | +--------+ +---------------------------+ +---------+ Figure 9 8 180 Ringing SIP proxy --> Alice (CallReport.Ringing) Sijben Expires January 2002 16 RTP proxys for firewall traversal July 2001 The SIP proxy replaces the address and port in the SDP of the 180 response with the address (10.2.2.44) and port (2000) from the Local descriptor of termination T1. SIP/2.0 180 Ringing Via: SIP/2.0/UDP a.wonderland.com:5060 From: sip:Alice@wonderland.com Record-Route: sip:+31201234567@telco.com;user=phone;maddr=sp.telco.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 1 INVITE Contact: sip:+31201234567@telco.com;user=phone Content-Type: application/sdp Content-Length: v=0 o=PSTNGW 654321 654321 IN IP4 gw.telco.com c=IN IP4 10.2.2.44 m=audio 2000 RTP/AVP 4 9 200 OK PSTN GW --> SIP proxy (CallConfirm) SIP/2.0 200 OK Via: SIP/2.0/UDP sp.telco.com:5060;branch=1 Via: SIP/2.0/UDP a.wonderland.com:5060 Record-Route: sip:+31201234567@telco.com;user=phone;maddr=sp.telco.com From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 1 INVITE Contact: sip:+31201234567@telco.com;user=phone Content-Length: 0 10 Modify T1,T2 SIP proxy --> RTP proxy (TransportIndication) The mode for both terminations T1 and T2 is updated to SendReceive to allow for a bi-directional media stream. MEGACO/1 [10.2.2.33]:55555 Transaction = 3 { Context = 1 { Modify = T1 { Media { Stream = 1 { LocalControl { Mode = SendReceive } } } }, Modify = T2 { Media { Sijben Expires January 2002 17 RTP proxys for firewall traversal July 2001 Stream = 1 { LocalControl { Mode = SendReceive } } } } } } 11 Reply RTP proxy --> SIP proxy MEGACO/1 [10.2.2.44]:55555 Reply = 3 { Context = 1 { Modify = T1, Modify = T2 } } Figure 10 shows the configuration of the RTP proxy at this point. The RTP proxy now allows for a bi-directional media flow. +--------+ +---------------------------+ +---------+ | | | T1 RTP proxy T2 | | | | | +----------+ +---------+ | | | | |SendRecv | | SendRecv| | | | | +----------+ +---------+ | | | | |local | | remote| | | | |------->|222.2.2.44|----->| 10.2.2.2|----->| | | UA | RTP |2000 | | 2222| RTP | PSTN GW | | | +----------+ +---------+ | | | | |remote | | local| | | | |<-------|111.1.1.1 |<-----|10.2.2.44|<-----| | | | RTP |1110 | | 2002| RTP | | | | +----------+ +---------+ | | +--------+ +---------------------------+ +---------+ Figure 10 12 200 OK SIP proxy --> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP a.wonderland.com:5060 From: sip:Alice@wonderland.com Record-Route: sip:+31201234567@telco.com;user=phone;maddr=sp.telco.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 1 INVITE Contact: sip:+31201234567@telco.com;user=phone Content-Length: 0 Details of the ACK messages are not shown for brevity. The ACK messages do not have any impact on the RTP proxy. Sijben Expires January 2002 18 RTP proxys for firewall traversal July 2001 5.1.2 Call tear down Alice (UA) SIP proxy (SP) RTP proxy PSTN GW 111.1.1.1 10.2.2.33 10.2.2.44 10.2.2.2 222.2.2.44 |<=== SIP ====>|<=== MEGACO ====>| | | |<============= SIP ===========>| | 1 BYE | | | |------------->| | | | | 2 Subtract | | | |---------------->| | | | 3 Reply | | | |<----------------| | | | | 4 BYE | | |------------------------------>| | | | 5 200 OK | | |<------------------------------| | 6 200 OK | | | |<-------------| | | | | | | | | | | Figure 11: Call tear down 1 BYE Alice --> SIP proxy BYE sip:+31201234567@telco.com;user=phone SIP/2.0 Via: SIP/2.0/UDP a.wonderland.com:5060 Route: sip:+31201234567@telco.com;user=phone From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 2 BYE Content-Length: 0 2 Transaction SIP proxy --> RTP proxy The SIP proxy requests the RTP proxy to remove both terminations and thereby closing the hole for the RTP stream. It could be argued to close the hole only after the 200 OK from the PSTN GW has been received, but as Alice has dropped the call it does not make sense to pass media at this point anymore. MEGACO/1 [10.2.2.33]:55555 Transaction = 4 { Context = 1 { Subtract = * } } 3 Reply RTP proxy --> SIP proxy Sijben Expires January 2002 19 RTP proxys for firewall traversal July 2001 The RTP proxy replies with the terminations that are removed. MEGACO/1 [10.2.2.44]:55555 Reply = 4 { Context = 1 { Subtract = T1, Subtract = T2 } } 4 BYE SIP proxy --> PSTN GW BYE sip:+31201234567@telco.com;user=phone SIP/2.0 Via: SIP/2.0/UDP sp.telco.com:5060;branch=1 Via: SIP/2.0/UDP a.wonderland.com:5060 From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 2 BYE Content-Length: 0 5 200 OK PSTN GW --> SIP proxy SIP/2.0 200 OK Via: SIP/2.0/UDP sp.telco.com:5060;branch=1 Via: SIP/2.0/UDP a.wonderland.com:5060 From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 2 BYE Content-Length: 0 6 200 OK SIP proxy --> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP a.wonderland.com:5060 From: sip:Alice@wonderland.com To: sip:+31201234567@telco.com;user=phone;tag=31415 Call-ID: 12345678@a.wonderland.com CSeq: 2 BYE Content-Length: 0 5.2 All SIP call We used a scenario with PSTN to show that the proposed solution allows for interworking with the PSTN with respect to media establishment, i.e. early media and short post pickup delay. A similar SIP/MEGACO flow however can be created for an all SIP call. 6. MEGACO profile Sijben Expires January 2002 20 RTP proxys for firewall traversal July 2001 MEGACO is a protocol to control a media gateway. An RTP proxy is much simpler than a media gateway and hence is easier to control. Only subset of MEGACO is needed to implement the solution as described in this document. 6.1 Descriptors The following subset of descriptors is needed: - Media - Stream - Local - Remote - LocalControl - ServiceChange 6.2 Commands The following subset of commands is needed: - Add - Modify - Subtract - ServiceChange The ServiceChange command is not mentioned in the signalling flows before. It could be used by the RTP proxy to register itself with the SIP proxy. 6.3 Packages No additional packages are needed. 7. Security Considerations 7.1 Communication between SIP proxy and RTP proxy No other entity than the SIP proxy should be able to request the opening and closing of holes in the RTP proxy. The communications channel between the SIP proxy and the RTP proxy SHOULD be secured with authentication and encryption mechanisms. 7.2 Denial of service attack The SDP in the SIP messages does not specify from which address and port RTP will be sent. Therefore the RTP proxy can not filter packets based on the source address and port. This gives an opportunity for a denial of service attack. A malicious person could continuously send RTP packets to various ports on the RTP proxy. As some of the ports will be open, some of these packets will get through and disrupt the media streams that flow through these ports. The source address and port are only known after the first RTP Sijben Expires January 2002 21 RTP proxys for firewall traversal July 2001 packet is received. The RTP proxy could narrow the hole by only allowing subsequent RTP packets from the same source address and port. If, however, the first RTP packet comes from the malicious person then the correct media stream will be blocked. A future draft will elaborate on the issue of source addresses. 7.3 Address spoofing The SIP proxy should only accept incoming INVITEs from the internet if they are destined to a host in the intranet. Otherwise someone from outside can punch a hole in the RTP proxy by addressing an INVITE to him or herself. One could send an INVITE with their own request URI to the SIP proxy and put an address and port of a host behind the firewall in the SDP. If the SIP proxy would accept this blindly it opens a hole in the RTP proxy and returns the INVITE with the modified SDP. 8. Conclusion In this draft we have shown that MEGACO can be used to dynamically open and close holes in an RTP proxy for the traversal of RTP streams associated with a SIP call. Considering the wider implication of this model we can regard the RTP proxy as an instance of what is called a middlebox in the MIDCOM WG. Therefore MEGACO can be used as a protocol for middlebox control. The RTP proxy terminated and originated the RTP streams on the IP level. No processing at the RTP level was needed. Therefore MEGACO can be used to open holes for the traversal of other protocols as well. By terminating the RTP streams on the IP level, the RTP proxy effectively is a NAT. In general a NAT breaks the session setup as it dynamically translates addresses without the involvement of the SIP proxy causing the IP addresses in the SDP bodies of the SIP messages to become meaningless. This problem does not arrise in the architecture proposed in this draft as the SIP proxy rewrites the SDP bodies using the translated IP addresses given by the RTP proxy. So, when there is a need for NAT to translate addresses from one address realm to another, then the NAT should be controlled by the SIP proxy. In [6] a similar approach for firewall traversal using MGCP is described. [7] describes a solution for a network where the user has to live with a firewall that blocks both SIP and RTP. That solution uses TCP connections or in the worst case TLS through port 443 (HTTPS) to get SIP and RTP through a firewall. One may question the real-time performance of such an approach. 9. References Sijben Expires January 2002 22 RTP proxys for firewall traversal July 2001 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF, March 1999 4 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, IETF, January 1996 5 F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, IETF, November 2000 6 F. Thernelius and B. Engelholm, "SIP Firewall Solution", draft- thernelius-sip-firewall-solution-00.txt, IETF, July 2000, Work in progress 7 J. Rosenberg, H. Schulzrinne, "SIP Traversal through Resedential and Enterprise NATs and Firewalls", draft-rosenberg,sip-entfw- 01.txt, IETF, Work in progress 8 J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses in SIP", draft-ietf-sip-100rel-03.txt, IETF, Work in progress 9 P. Sijben, "Threat analysis of architectures for architectures for firewall traversal", draft-sijben-midcom-threat-analysis- 00.txt, IETF Work in progress 10 R. P. Swale, P. Mart, P. Sijben, " Requirements for the MIDCOM architecture and control language", draft-ietf-midcom- requirements-00.txt, IETF Work in progress 11 TIPHON Release 2;Network architecture and reference configurations, ETSI http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07-drafts/wg2/DTS02003/V0.10.10/ 10. Author's Addresses Paul Sijben Willem van Willigenburg Michel de Boer Lucent Technologies Lucent Technologies Lucent Technologies Huizen Huizen Huizen Netherlands Netherlands Netherlands Email: Email: Email: sijben@lucent.com willigenburg@lucent.com michelboer@lucent.com Sijben Expires January 2002 23