Internet DRAFT - draft-boer-sip-src
draft-boer-sip-src
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
