rfc3257.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

   connection when SYN-cookies are used.

5.2 Security issues with SCTP

   SCTP has been designed with the experiences made with TCP in mind.
   To make it hard for blind attackers (i.e., attackers that are not
   man-in-the-middle) to inject forged SCTP datagrams into existing
   associations, each side of an SCTP association uses a 32 bit value
   called "Verification Tag" to ensure that a datagram really belongs to
   the existing association.  So in addition to a combination of source
   and destination transport addresses that belong to an established
   association, a valid SCTP datagram must also have the correct tag to
   be accepted by the recipient.

   Unlike in TCP, usage of cookie in association establishment is made
   mandatory in SCTP.  For the server, a new association is fully
   established after three messages (containing INIT, INIT-ACK, COOKIE-
   ECHO chunks) have been exchanged.  The cookie is a variable length
   parameter that contains all relevant data to initialize the TCB on
   the server side, plus a HMAC used to secure it.  This HMAC (MD5 as
   per [RFC1321] or SHA-1 [SHA1]) is computed over the cookie and a
   secret, server-owned key.





Coene                        Informational                      [Page 7]

RFC 3257              SCTP Applicability Statement            April 2002


   As specifically prescribed for SCTP implementations [RFC2960],
   additional resources for new associations may only be reserved in
   case a valid COOKIE-ECHO chunk is received by a client, and the
   computed HMAC for this new cookie matches that contained in the
   cookie.

   With SCTP the chances of an attacker being able to blindly forge a
   connection are even lower than in the case of TCP using SYN-cookies,
   since the attacker would have to guess a correct value for the HMAC
   contained in the cookie, i.e., lower than 1 in 2^128 which for all
   practical purposes is negligible.

   It should be noted that SCTP only tries to increase the availability
   of a network.  SCTP does not contain any protocol mechanisms that are
   directly related to user message authentication, integrity and
   confidentiality functions.  For such features, it depends on the
   IPsec protocols and architecture and/or on security features of the
   application protocols.

   Transport Layer security(TLS)[RFC2246] using SCTP must always use
   in-order streams.

   Currently the IPSEC working group is investigating the support of
   multi-homing by IPSEC protocols.  At the present time to use IPSEC,
   one must use 2 * N * M security associations if one endpoint uses N
   addresses and the other M addresses.

5.3 Security Issues with both TCP and SCTP

   It is important to note that neither TCP nor SCTP protect itself from
   man-in-the-middle attacks where an established session might be
   hijacked (assuming the attacker can see the traffic from and inject
   its own packets to either endpoints).

   Also, to prevent blind connection/session setup forgery, both TCP
   implementations supporting SYN-cookies and SCTP implementations rely
   on a server-known, secret key to protect the HMAC data.  It must be
   ensured that this key is created subject to the recommendations
   mentioned in [RFC1750].

   Although SCTP has been designed carefully as to avoid some of the
   problems that have appeared with TCP, it has as of yet not been
   widely deployed.  It is therefore possible that new security issues
   will be identified that will have to be addressed in further
   revisions of [RFC2960].






Coene                        Informational                      [Page 8]

RFC 3257              SCTP Applicability Statement            April 2002


6 References and related work

   [RFC2960]   Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
               Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
               Zhang, L. and V. Paxson, "Stream Control Transmission
               Protocol", RFC 2960, October 2000.

   [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

   [RFC2663]   Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

   [RFC2694]   Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
               Heffernan, "DNS extensions to Network Address Translators
               (DNS_ALG)", RFC 2694, September 1999.

   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.

   [RFC2719]   Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
               L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp,
               "Architectural Framework for Signaling Transport", RFC
               2719, October 1999.

   [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.

   [RFC1323]   Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
               for High Performance", RFC 1323, May 1992.

   [RFC1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
               Recommendations for Security", RFC 1750, December 1994.

   [SHA1]      NIST FIPS PUB 180-1, "Secure Hash Standard," National
               Institute of Standards and Technology, U.S. Department of
               Commerce, April 1995.

   [SYNCOOK]   Dan J. Bernstein, SYN cookies, 1997, see also
               <http://cr.yp.to/syncookies.html>

   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.




Coene                        Informational                      [Page 9]

RFC 3257              SCTP Applicability Statement            April 2002


   [RFC1889]   Schulzrinne, H., Casner, S., Frederick, R. and V.
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", RFC 1889, January 1996.

7 Acknowledgments

   This document was initially developed by a design team consisting of
   Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart,
   Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas
   Jungmaier, Gery Verwimp and Lyndon Ong.

   The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer,
   J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, T.
   George, M. Stillman, N. Makinae, S. Bradner, A. Mankin, G. Camarillo,
   H. Schulzrinne, R. Kantola, J. Rosenberg, R.J. Atkinson, and many
   others for their invaluable comments.



































Coene                        Informational                     [Page 10]

RFC 3257              SCTP Applicability Statement            April 2002


Appendix A: Major functions provided by SCTP

   - Reliable Data Transfer

   - Multiple streams to help avoid head-of-line blocking

   - Ordered and unordered data delivery on a per-stream basis

   - Bundling and fragmentation of user data

   - TCP friendly Congestion and flow control

   - Support continuous monitoring of reachability

   - Graceful termination of association

   - Support of multi-homing for added reliability

   - Some protection against blind denial-of-service attacks

   - Some protection against blind masquerade attacks






























Coene                        Informational                     [Page 11]

RFC 3257              SCTP Applicability Statement            April 2002


8  Editor's Address

   Lode Coene
   Siemens Atea
   Atealaan 34
   B-2200 Herentals
   Belgium

   Phone: [phone]
   EMail: [e-mail]









































Coene                        Informational                     [Page 12]

RFC 3257              SCTP Applicability Statement            April 2002


9.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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 RFC Editor function is currently provided by the
   Internet Society.



















Coene                        Informational                     [Page 13]