the victim’s transport address to the UA. To prevent this attack,
the UA SHOULD engage in a handshake with the owner of the transport
address received in a session description (just verifying willingness
to receive media) before sending a large amount of data to the
transport address. This check can be performed by using a connection
oriented transport protocol, by using STUN [8] in an end-to-end
fashion, or by the key exchange in SRTP [7].
In any event, note that the previous security considerations are not
early media specific, but apply to the usage of the offer/answer
model in SIP to establish sessions in general.
Additionally, an early media-specific risk (roughly speaking,
equivalent to forms of "toll fraud" in the PSTN) attempts to exploit
the different charging policies some operators apply to early and
regular media. When UAs are allowed to exchange early media for
free, but are required to pay for regular media sessions, rogue UAs
may try to establish a bidirectional early media session and never
send a 200 (OK) response for the INVITE.
On the other hand, some application servers (e.g., Interactive Voice
Response systems) use bidirectional early media to obtain information
from the callers (e.g., the PIN code of a calling card). So, we do
not recommend that operators disallow bidirectional early media.
Instead, operators should consider a remedy of charging early media
exchanges that last too long, or stopping them at the media level
(according to the operator’s policy).
7. Acknowledgments
Jon Peterson provided useful ideas on the separation between the
gateway model and the application server model.
Paul Kyzivat, Christer Holmberg, Bill Marshall, Francois Audet, John
Hearty, Adam Roach, Eric Burger, Rohan Mahy, and Allison Mankin
provided useful comments and suggestions.
8. References
8.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Camarillo, G., "The Early Session Disposition Type for the
Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
8.2. Informative References
[4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[6] Rosenberg, J., "Interactive connectivity establishment (ICE): a
methodology for network address translator (NAT) traversal for
the session initiation protocol (SIP)", Work in progress, July
2003.
[7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[8] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors’ Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne
Dept. of Computer Science
Columbia University 1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.