M. de Boer Internet Draft W. van Willigenburg Document: draft-boer-sip-src-00.txt P. Sijben Expires: January 2002 Lucent Technologies July 2001 Specifying unicast media source addresses in SIP 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 a method to specify source IP addresses and ports of a media stream in a SIP call. 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]. 3. Introduction A SIP call crossing the boundaries of several networks need to traverse the firewalls that secure these networks. During call setup the SIP proxies request the firewalls to open pinholes for the passage of the media streams [5,6,7]. For security reasons these pinholes should be as specific as possible, i.e. only packets satisfying specific values for the following fields are allowed to pass: de Boer Expires January 2002 1 Specifying unicast source media addresses in SIP July 2001 - source IP address - source port - destination IP address - destination port - transport protocol (TCP/UDP) SIP carries the media specification as SDP bodies in its signalling messages. Unfortunately the SDP specification as used in SIP, where bi-directional streams are specified as send-and-receive, does not specify the source IP address and port of a media stream. Hence the pinhole in a firewall can only allow packets from all source IP addresses and ports to pass, introducing a vulnerability in the security the firewall offers. +-------------+ +------------+ | +-+ RTP X +-+ | | CALLER |A|--------------->|C| CALLEE | | +-+ +-+ | | +-+ RTP Y +-+ | | |B|<---------------|D| | | +-+ +-+ | +-------------+ +------------+ Figure 1 RTP --- Figure 1 shows the RTP streams between a caller and a callee associated with a SIP session. A and D represent the source addresses and ports for the RTP streams X and Y respectively. B and C represent the sink addresses and ports. To setup these RTP streams, the caller starts with sending an INVITE to the callee specifying that it wants to receive RTP on B. In a response the callee specifies that it wants to receive RTP, on C. So A and D will not be signalled. As a consequence, a firewall between the caller and callee has to pass all RTP packets destined for B and C regardless of the sender of the packets. RTCP ---- The IP address and port of an RTP stream implicitly specify the IP address and port of the RTCP packets. If a SIP message indicates that the sender of the message wants to receive RTP on port B then, it implicitly specifies that it wants to receive RCTP on port B+1. de Boer Expires January 2002 2 Specifying unicast source media addresses in SIP July 2001 +-------------+ +------------+ | +---+ RTP X +---+ | | CALLER | A|--------------->|C |CALLEE | | +---+ RTCP Y' +---+ | | |--------------->|C+1| | | | +---+ | | +---+ RTP Y +---+ | | | B|<---------------|D | | | +---+ RTCP X' +---+ | | |B+1|<---------------| | | +---+ | | +-------------+ +------------+ Figure 2 Figure 2 shows the RTP and RTCP streams between a caller and a callee. Again the source IP addresses and ports of the RTCP streams are not signalled. Apart from the lack of explicit source IP addresses and ports, the destination IP addresses and ports for the RTCP streams are illogical. The caller sends RTP stream X from port A and receives the feedback on that stream, i.e. RTCP stream X' on port B+1. In a multihomed host ports A and B could reside on different IP addresses. The RTCP feedback is then received on another IP address than the address where the RTP is sent from. It would make more sense if the RTCP stream X' is received on port A+1 as shown in figure 3. +-------------+ +------------+ | +---+ RTP X +---+ | | CALLER | A|--------------->|C |CALLEE | | +---+ RTCP X' +---+ | | |A+1|<---------------|C+1| | | +---+ +---+ | | +---+ RTP Y +---+ | | | B|<---------------|D | | | +---+ RTCP Y' +---+ | | |B+1|--------------->|D+1| | | +---+ +---+ | +-------------+ +------------+ Figure 3 This draft shows how the source IP addresses and ports, i.e. A and D can be specified in SIP using standard SDP as defined in [3]. It also shows that a more logical place of RTCP ports as shown in Figure 3 is possible too. 4. Source IP address and port in SIP/SDP de Boer Expires January 2002 3 Specifying unicast source media addresses in SIP July 2001 By default a media stream specified by an m-line is a send-and- receive stream. The IP address and port specified, indicates where the sender of the SDP wants to receive RTP. Example: m=audio 1110 RTP/AVP 0 c=IN IP4 1.1.1.1 This SDP specifies a send-and-receive G.711 audio stream. The sender of this SDP expects RTP packets to be sent to 1.1.1.1:1110 and RTCP packets to 1.1.1.1:1111. RFC 2327 [3] defines attributes to explicitly set the direction of the stream. For the sendonly attribute it says: An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be use, one sendonly and one recvonly. So, by explicitly specifying the send-and-receive stream by as a send-only and receive-only stream, it is possible to specify the IP address and port where RTP should be sent to AND the IP address and port where RTP will be sent from as follows: - The receive-only stream specifies the IP address and port where RTP should be sent to. Implicitly (port + 1) is the port where the RTCP feedback on this RTP stream will be sent from. - The send-only stream specifies the IP address and port where RTP will be sent from. Implicitly (port + 1) is the port where the RTCP feedback on this RTP stream should be sent to. Example: m=audio 1110 RTP/AVP 0 c=IN IP4 1.1.1.1 a=recvonly m=audio 2220 RTP/AVP 0 c=IN IP4 2.2.2.2 a=sendonly The sender of this SDP specifies that it wants to receive RTP packets on 1.1.1.1:1110 and send RTCP packets from 1.1.1.1:1111. It will send RTP packets from 2.2.2.2:2220 and receive RTCP packets on 2.2.2.2:2221. Note that for the meaning of sendonly and recvonly the definition as given in Appendix B.2.1 of [4] for unicast sessions is used. The recvonly and sendonly attribute are specifying the sender side behaviour of this message. In multicast it would be a instruction to the receiver. de Boer Expires January 2002 4 Specifying unicast source media addresses in SIP July 2001 4.1 Integration with semantics currently defined by SIP The semantics we assign to receive-only and send-only streams fits well into the semantics already assigned to the IP address and port of a uni-directional stream in [4]. Appendix B of [4] states: For recvonly and sendrecv streams, the port number and address in the session description indicate where the media stream should be sent to. For send-only RTP streams, the address and port number indicate where RTCP reports are to be sent to. Specifically, RTCP reports are sent to the port number one higher than the number indicated. In this definition the following elements are left undefined: 1 For a recvonly stream: the port number one higher than the port number specified in the m-line, e.g. m=audio 1110 RTP/AVP 0 c=IN IP4 1.1.1.1 a=recvonly Port 1110 is the port where RTP should be sent to. Port 1111 is not assigned any meaning in the current SIP specification [4]. 2 For a sendonly stream: the port specified in the m-line, e.g. m=audio 2220 RTP/AVP 0 c=IN IP4 2.2.2.2 a=sendonly Port 2221 is the port where RTCP should be sent to. Port 2220 is not assigned any meaning the current SIP specification [4]. It is these currently undefined elements that get meaning in this draft. Element 1 (port 1111 in the example) becomes the port where RTCP packets will be sent from. Element 2 (port 2220 in the example) becomes the port where the RTP packets will be sent from 5. Conclusion By specifying a bi-directional stream as two uni-directional streams it is possible to specify the source and destination IP addresses and ports for RTP and RTCP packets. In addition you get a more logical relationship between the port numbering for RTP and RTCP packets. To enable the opening of secure pinholes in a firewall the SDP bodies of SIP messages SHOULD specify the source and sink IP addresses and ports of the media streams. de Boer Expires January 2002 5 Specifying unicast source media addresses in SIP July 2001 Besides SIP this method can be used in any protocol relying on SDP for media specification, e.g. MEGACO. 6. Security Considerations The proposed solution enables the opening of specific pinholes in a firewall for media stream traversal resulting in higher network security. The solution described in this draft proposes that SIP user agents should signal the source IP address and port of their RTP and RTCP streams. To prevent unauthorised parties to snoop this information, the SDP bodies should be encrypted. 7. References 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, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, IETF, April 1998 4 Handley, Schulzrinne, Schooler, Rosenberg, "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-03.txt, IETF, May 2001, Work in progress 5 P. Sijben, W. van Willigenburg, M. de Boer, "RTP gateways for firewall traversal", draft-sijben-rtp-gateway-00.txt, IETF, July 2001, Work in progress 6 R.P. Swale, P.A. Mart, P. Sijben, "Middlebox Control (MIDCOM) Protocol Architecture and Requirements", draft-ietf-midcom- requirements-01.txt, IETF, May 2001, Work in progress 7 P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "Middlebox Communication Architecture and framework", draft-ietf- midcom-framework-02.txt, IETF, June 2001, Work in progress 8. 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 de Boer Expires January 2002 6