This can be mitigated by sending occasional silence packets to keep
the binding alive. However, the result is additional brittleness;
proper operation depends on the silence suppression algorithm in use,
the usage of a comfort noise codec, the duration of the silence
period, and the binding lifetime in the NAT.
14.6 In Closing
The problems with STUN are not design flaws in STUN. The problems in
STUN have to do with the lack of standardized behaviors and controls
in NATs. The result of this lack of standardization has been a
proliferation of devices whose behavior is highly unpredictable,
extremely variable, and uncontrollable. STUN does the best it can in
such a hostile environment. Ultimately, the solution is to make the
environment less hostile, and to introduce controls and standardized
behaviors into NAT. However, until such time as that happens, STUN
provides a good short term solution given the terrible conditions
under which it is forced to operate.
15. Acknowledgments
The authors would like to thank Cedric Aoun, Pete Cordell, Cullen
Jennings, Bob Penfield and Chris Sullivan for their comments, and
Baruch Sterman and Alan Hawrylyshen for initial implementations.
Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning
Schulzrinne for IESG and IAB input on this work.
16. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS protocol Version 1.0", RFC
2246, January 1999.
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC2782,
February 2000.
[4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC3268, June 2002.
[5] Rescorla, E., "HTTP over TLS", RFC2818, May 2000.
[6] Postel, J., "Internet Protocol", STD 5, RFC791, September 1981.
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC2827, May 2000.
17. Informative References
[8] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC3235, January 2002.
[9] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox Communication Architecture and Framework",
RFC3303, August 2002.
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC3261, June 2002.
[11] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC3027, January 2001.
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC2104, February 1997.
[14] Kohl, J. and C. Neuman, "The kerberos Network Authentication
Service (V5)", RFC1510, September 1993.
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC2616, June 1999.
[16] Baugher M., et al., "The secure real-time transport protocol",
Work in Progress.
[17] Daigle, L., Editor, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", RFC
3424, November 2002.
[18] Huitema, C., "RTCP attribute in SDP", Work in Progress.
18. Authors' Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.com
Joel Weinberger
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
EMail: jweinberger@dynamicsoft.com
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
Rohan Mahy
Cisco Systems
101 Cooper St
Santa Cruz, CA 95060
EMail: rohan@cisco.com
19. 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 assigns.
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 RFCEditor function is currently provided by the
Internet Society.