draft-ietf-mmusic-sdp4nat-00.txt   draft-ietf-mmusic-sdp4nat-01.txt 
INTERNET DRAFT C. Huitema INTERNET DRAFT C. Huitema
<draft-ietf-mmusic-sdp4nat-00.txt> Microsoft <draft-ietf-mmusic-sdp4nat-01.txt> Microsoft
Expires February 22, 2002 August 22, 2001 Expires August 19, 2002 February 19, 2002
RTCP attribute in SDP RTCP attribute in SDP
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
skipping to change at page 1, line 52 skipping to change at page 1, line 52
establish multi-media sessions on the Internet. There are often establish multi-media sessions on the Internet. There are often
cases today in which one or both end of the connection is hidden cases today in which one or both end of the connection is hidden
behind a network address translation device [RFC2766]. In this behind a network address translation device [RFC2766]. In this
cases, the SDP text must document the IP addresses and UDP ports as cases, the SDP text must document the IP addresses and UDP ports as
they appear on the "public Internet" side of the NAT; in this memo, they appear on the "public Internet" side of the NAT; in this memo,
we will suppose that the host located behind a NAT has a way to we will suppose that the host located behind a NAT has a way to
obtain these numbers; a possible way to learn these numbers is obtain these numbers; a possible way to learn these numbers is
briefly outlined in section 3. However, just learning the numbers is briefly outlined in section 3. However, just learning the numbers is
not enough. not enough.
The SIP messages use the encoding defined in SDP [RFC2237] to The SIP messages use the encoding defined in SDP [RFC2327] to
describe the IP addresses and TCP or UDP ports used my the various describe the IP addresses and TCP or UDP ports used my the various
media. Audio and video are typically sent using RTP [RFC1889], which media. Audio and video are typically sent using RTP [RFC1889], which
requires two UDP port, one for the media and one for the control requires two UDP port, one for the media and one for the control
protocol (RTCP). SDP carries only one port number per media, and protocol (RTCP). SDP carries only one port number per media, and
states that "other ports used by the media application (such as the states that "other ports used by the media application (such as the
RTCP port) should be derived algorithmically from the base media RTCP port) should be derived algorithmically from the base media
port." When the media is transmitted using RTP [RFC1889], the choice port." When the media is transmitted using RTP [RFC1889], the choice
of the port number is very specific: "for UDP and similar protocols, of the port number is very specific: "for UDP and similar protocols,
RTP uses an even port number and the corresponding RTCP stream uses RTP uses an even port number and the corresponding RTCP stream uses
skipping to change at page 4, line 5 skipping to change at page 4, line 5
requirements is legitimate. requirements is legitimate.
3.1 How do we discover port numbers ? 3.1 How do we discover port numbers ?
The proposed solution assumes that we can discover the "translated The proposed solution assumes that we can discover the "translated
port numbers", i.e. the value of the port as they appear on the port numbers", i.e. the value of the port as they appear on the
"external side" of the NAT. There are multiple ways to achieve this "external side" of the NAT. There are multiple ways to achieve this
result. One possibility is to ask the cooperation of a well result. One possibility is to ask the cooperation of a well
connected third party, using a three step process: connected third party, using a three step process:
1) The host allocates two UDP port numbers for an RTP/RTCP pair, 1) The host allocate two UDP port numbers for an RTP/RTCP pair,
2) The host sends a UDP message from each port to the third party, 2) The host send a UDP message from each port to the third party,
3) The third party reads the source address and port of the packet, 3) The third party reads the source address and port of the packet,
and copy them in the text of a reply, and copy them in the text of a reply,
4) The host parses the reply and learns the external address and 4) The host parses the reply and learns the external address and
port corresponding to each of the two UDP port. port corresponding to each of the two UDP port.
This algorithm supposes that the NAT will use the same translation This algorithm supposes that the NAT will use the same translation
for packets sent to the third party and to the "SDP peer" with which for packets sent to the third party and to the "SDP peer" with which
the host wants to establish a connection. The experience shows that the host wants to establish a connection. The experience shows that
skipping to change at page 5, line 20 skipping to change at page 5, line 20
3.4 Is a tolerant RTP legitimate? 3.4 Is a tolerant RTP legitimate?
Our solution explicitly asks implementers to disregard a part of the Our solution explicitly asks implementers to disregard a part of the
RTP specification that mandates use of even port numbers for RTP and RTP specification that mandates use of even port numbers for RTP and
the consecutive odd port number for RTCP. We believe that this is the consecutive odd port number for RTCP. We believe that this is
very much in the spirit of the robustness principle attributed to very much in the spirit of the robustness principle attributed to
Jon Postel, i.e. "Be conservative in what you do, be liberal in what Jon Postel, i.e. "Be conservative in what you do, be liberal in what
you accept from others." you accept from others."
This approach has been validated with the AVT working group of the
IETF, which is in charge of maintaining the RTP standard. We expect
that the revised version of the RTP standard will lift the
restrictions on port numbers imposed in [RFC1889], e.g. specify that
for applications in which the RTP and RTCP destination port numbers
are specified via explicit, separate parameters (using a signaling
protocol or other means), the application MAY disregard the
restrictions that the port numbers be even/odd and consecutive
although the use of an even/odd port pair is still encouraged.
4 Security Considerations 4 Security Considerations
This SDP extension is not believed to introduce any significant This SDP extension is not believed to introduce any significant
security risk to multi-media applications. One could conceive that a security risk to multi-media applications. One could conceive that a
malevolent third party would use the extension to redirect the RTCP malevolent third party would use the extension to redirect the RTCP
fraction of an RTP exchange, but this require intercepting and fraction of an RTP exchange, but this require intercepting and
rewriting the signaling packet carrying the SDP text; if an rewriting the signaling packet carrying the SDP text; if an
interceptor can do that, many more attacks are available, including interceptor can do that, many more attacks are available, including
a wholesale change of the addresses and port numbers at which the a wholesale change of the addresses and port numbers at which the
media will be sent. media will be sent.
5 IANA Considerations 5 IANA Considerations
This document does not call for an IANA action, unless the IANA is This document defines a new SDP parameter, the attribute field
registering attributes types for SDP - and there is no documentation "rtcp", which per [RFC2327] should be registered by IANA. This
to that effect on the IANA web site. attribute field is designed for use at media level only.
6 Copyright 6 Copyright
The following copyright notice is copied from RFC 2026 [Bradner, The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this 1996], Section 10.4, and describes the applicable copyright for this
document. document.
Copyright (C) The Internet Society March 21, 2001. All Rights Copyright (C) The Internet Society March 21, 2001. All Rights
Reserved. Reserved.
skipping to change at page 6, line 47 skipping to change at page 7, line 4
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
8 Acknowledgements 8 Acknowledgements
The original idea for using the "rtcp" attribute was developed by The original idea for using the "rtcp" attribute was developed by
Ann Demirtjis.
Ann Demirtjis. The draft was reviewed by the MMUSIC and AVT working
groups of the IETF.
9 References 9 References
[RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP: [RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg "SIP:
Session Initiation Protocol", RFC 2543, March 1999. Session Initiation Protocol", RFC 2543, March 1999.
[RFC2237] M. Handley, V. Jacobson, "SDP: Session Description [RFC2327] M. Handley, V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889, January A Transport Protocol for Real-Time Applications", RFC 1889, January
1996. 1996.
[RFC2766] G. Tsirtsis, P. Srisuresh. "Network Address Translation - [RFC2766] G. Tsirtsis, P. Srisuresh. "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/