rfc3856 a presence event package for the session initiation protocol.txt

有关IMS SIP及Presence应用的RFC文档包

9.5.  Denial of Service Attacks Against Third Parties

   Denial of Service (DOS) attacks are a critical problem for an open,
   inter-domain, presence protocol.  Unfortunately, presence is a good
   candidate for Distributed DoS (DDOS) attacks because of its
   amplification properties.  A single SUBSCRIBE message could generate
   a nearly unending stream of notifications, so long as a suitably
   dynamic source of presence data can be found.  Thus, a simple way to
   launch an attack against a target is to send subscriptions to a large
   number of users, and in the Contact header field (which is where
   notifications are sent), place the address of the target.  RFC 3265
   provides some mechanisms to mitigate these attacks [2].  If a NOTIFY
   is not acknowledged or was not wanted, the subscription that
   generated it is removed.  This eliminates the amplification
   properties of providing false Contact addresses.





Rosenberg                   Standards Track                    [Page 22]

RFC 3856                      SIP Presence                   August 2004


   Authentication and authorization at the PA can also prevent these
   attacks.  Typically, authorization policy will not allow
   subscriptions from unknown watchers.  If the attacks are launched
   from watchers unknown to the presentity (a common case), the attacks
   are mitigated.

9.6.  Denial Of Service Attacks Against Servers

   Denial of service attacks can also be launched against a presence
   agent itself, in order to disrupt service to a community of users.
   SIP itself, along with RFC 3265 [2], describes several mechanisms to
   mitigate these attacks.

   A server can prevent SYN-attack style attacks through a four-way
   handshake using digest authentication [1].  Even if the server does
   not have a shared secret with the client, it can verify the source IP
   address of the request using the "anonymous" user mechanism described
   in Section 22.1 of RFC 3261 [1].  SIP also allows a server to
   instruct a client to back-off from sending it requests, using the 503
   response code (Section 21.5.4 of RFC 3261 [1]).  This can be used to
   fend off floods of SUBSCRIBE requests launched as a result of a
   distributed denial of service attack.

10.  IANA Considerations

   This specification registers an event package, based on the
   registration procedures defined in RFC 3265 [2].  The following is
   the information required for such a registration:

        Package Name: presence

        Package or Template-Package: This is a package.

        Published Document: RFC 3856

        Person to Contact: Jonathan Rosenberg, [e-mail].















Rosenberg                   Standards Track                    [Page 23]

RFC 3856                      SIP Presence                   August 2004


11.  Contributors

   The following individuals were part of the initial team that worked
   through the technical design of this specification:

   Jonathan Lennox
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

   EMail: [e-mail]

   Robert Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024

   EMail: [e-mail]

   Ben Campbell

   EMail: [e-mail]

   Dean Willis
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024

   EMail: [e-mail]

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

   EMail: [e-mail]











Rosenberg                   Standards Track                    [Page 24]

RFC 3856                      SIP Presence                   August 2004


   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

   EMail: [e-mail]

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

   EMail: [e-mail]

   David Gurle
   Reuters Corporation

   EMail: [e-mail]

   David Oran
   Cisco Systems
   170 West Tasman Dr.
   San Jose, CA 95134

   EMail: [e-mail]

12.  Acknowledgements

   We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy
   Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen
   Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan,
   Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their
   comments and support of this specification.

13.  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [3]  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
        August 2004.

   [4]  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.



Rosenberg                   Standards Track                    [Page 25]

RFC 3856                      SIP Presence                   August 2004


   [5]  Peterson, J., "Address Resolution for Instant Messaging and
        Presence", RFC 3861, August 2004.

   [6]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
        J. Peterson, "Presence Information Data Format (PIDF)", RFC
        3863, August 2004.

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

   [8]  Rosenberg, J., "A Watcher Information Event Template-Package for
        the Session Initiation Protocol (SIP)", RFC 3857, August 2004.

   [9]  Schulzrinne, H. Rosenberg, J., and P. Kyzivat, "Indicating User
        Agent Capabilities in the Session Initiation Protocol (SIP)",
        RFC 3840, August 2004.

14.  Informative References

   [10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
        Instant Messaging", RFC 2778, February 2000.

   [11] Peterson, J., "Enhancements for Authenticated Identity
        Management in the Session Initiation Protocol (SIP)", Work in
        Progress, May 2004.

   [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.

   [13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
        Messaging / Presence Protocol Requirements", RFC 2779, February
        2000.

   [14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211,
        December 2001.

15.  Author's Address

   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ 07054

   EMail: [e-mail]







Rosenberg                   Standards Track                    [Page 26]

RFC 3856                      SIP Presence                   August 2004


16.  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 procedures with respect to rights in RFC 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-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Rosenberg                   Standards Track                    [Page 27]