PSTN switches to avoid security problems.
The mapping from a SIP response code to an ISUP Cause Code presents a
theoretical risk, so a gateway operator may implement policies
controlling this mapping. Gateways should also not rely on the
contents of the From header field for identity information, as it may
be arbitrarily populated by a user. Instead, some sort of
cryptographic authentication and authorization should be used for
identity determination. These flows show both HTTP Digest for
authentication of users, although for brevity, the challenge is not
always shown.
The early media cut-through shown in some flows is another potential
security risk, but it is also required for proper interaction with
the PSTN. Again, a gateway operator should use proper policies
relating to early media to prevent fraud and misuse. Finally, a user
agent (even a properly authenticated one) can launch multiple
simultaneous requests through a gateway, constituting a denial of
service attack. The adoption of policies to limit the number of
simultaneous requests from a single entity may be used to prevent
this attack.
As discussed in the SIP-T framework [7], SIP/ISUP interworking can be
employed as an interdomain signaling mechanism that may be subject to
pre-existing trust relationships between administrative domains. Any
administrative domain implementing SIP-T or SIP/ISUP interworking
should have an adequate security apparatus (including elements that
manage any appropriate policies to manage fraud and billing in an
interdomain environment) in place to ensure that the translation of
ISUP information does not result in any security violations.
Although no examples of this are shown in this document, transporting
ISUP in SIP bodies may provide opportunities for abuse, fraud, and
privacy concerns, especially when SIP-T requests can be generated,
inspected or modified by arbitrary SIP endpoints. ISUP MIME bodies
should be secured (preferably with S/MIME as detailed in RFC 3261
[2]) to alleviate this concern. Authentication properties provided
by S/MIME would allow the recipient of a SIP-T message to ensure that
the ISUP MIME body was generated by an authorized entity. Encryption
would ensure that only carriers possessing a particular decryption
key are capable of inspecting encapsulated ISUP MIME bodies in a SIP
request.
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. E. and Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Camarillo, G., Roach, A. B., Peterson, J. and L. Ong,
"Integrated Services Digital Network (ISDN) User Part (ISUP) to
Session Initiation Protocol (SIP) Mapping", RFC 3398, December
2002.
[5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[7] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", BCP 63, RFC
3372, September 2002.
[8] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001.
[9] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
6.2. Informative References
[10] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", RFC 3665, December 2003.
7. Acknowledgments
Thanks to Rohan Mahy, Adam Roach, Gonzalo Camarillo, Cullen Jennings,
and Tom Taylor for their detailed comments during the final review.
Thanks to Dean Willis for his early contributions to the development
of this document. Thanks to Jon Peterson for his help on the
security section.
The authors wish to thank Kundan Singh for performing parser
validation of messages.
The authors wish to thank the following individuals for their
participation in a detailed review of this call flows document: Aseem
Agarwal, Rafi Assadi, Ben Campbell, Sunitha Kumar, Jon Peterson, Marc
Petit-Huguenin, Vidhi Rastogi, and Bodgey Yin Shaohua.
The authors also wish to thank the following individuals for their
assistance: Jean-Francois Mule, Hemant Agrawal, Henry Sinnreich,
David Devanatham, Joe Pizzimenti, Matt Cannon, John Hearty, the whole
MCI WorldCom IPOP Design team, Scott Orton, Greg Osterhout, Pat
Sollee, Doug Weisenberg, Danny Mistry, Steve McKinnon, and Denise
Ingram, Denise Caballero, Tom Redman, Ilya Slain, Pat Sollee, John
Truetken, and others from MCI WorldCom, 3Com, Cisco, Lucent and
Nortel.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF’s procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
9. Authors’ Addresses
All listed authors actively contributed large amounts of text to this
document.
Alan Johnston
MCI
100 South 4th Street
St. Louis, MO 63102
USA
EMail: alan.johnston@mci.com
Steve Donovan
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: sdonovan@dynamicsoft.com
Robert Sparks
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: rsparks@dynamicsoft.com
Chris Cunningham
dynamicsoft, Inc.
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
USA
EMail: ccunningham@dynamicsoft.com
Kevin Summers
Sonus
1701 North Collins Blvd, Suite 3000
Richardson, TX 75080
USA
EMail: kevin.summers@sonusnet.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.