rfc2974.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   all announced sessions along with the time each announcement was last
   received.  When a new SAP listeners starts, it should contact its
   local proxy to download this information, which is then sufficient
   for it to process future announcements directly, as if it has been
   continually listening.

   The protocol by which a SAP listener contacts its local proxy cache
   is not specified here.

10 Security Considerations

   SAP contains mechanisms for ensuring integrity of session
   announcements, for authenticating the origin of an announcement and
   for encrypting such announcements (sections 7 and 8).

   As stated in section 5, if a session modification announcement is
   received that contains a valid authentication header, but which is
   not signed by the original creator of the session, then the session
   must be treated as a new session in addition to the original session
   with the same SDP origin information unless the originator of one of
   the session descriptions can be authenticated using a certificate
   signed by a trusted third party.  If this were not done, there would
   be a possible denial of service attack whereby a party listens for
   new announcements, strips off the original authentication header,
   modifies the session description, adds a new authentication header
   and re-announces the session.  If a rule was imposed that such spoof
   announcements were ignored, then if packet loss or late starting of a
   session directory instance caused the original announcement to fail
   to arrive at a site, but the spoof announcement did so, this would
   then prevent the original announcement from being accepted at that
   site.

   A similar denial-of-service attack is possible if a session
   announcement receiver relies completely on the originating source and
   hash fields to indicate change, and fails to parse the remainder of
   announcements for which it has seen the origin/hash combination
   before.

   A denial of service attack is possible from a malicious site close to
   a legitimate site which is making a session announcement.  This can
   happen if the malicious site floods the legitimate site with huge
   numbers of (illegal) low TTL announcements describing high TTL
   sessions.  This may reduce the session announcement rate of the
   legitimate announcement to below a tenth of the rate expected at
   remote sites and therefore cause the session to time out.  Such an
   attack is likely to be easily detectable, and we do not provide any
   mechanism here to prevent it.




Handley, et al.               Experimental                     [Page 13]

RFC 2974             Session Announcement Protocol          October 2000


A. Summary of differences between SAPv0 and SAPv1

   For this purpose SAPv0 is defined as the protocol in use by version
   2.2 of the session directory tool, sdr.  SAPv1 is the protocol
   described in the 19 November 1996 version of this memo.  The packet
   headers of SAP messages are the same in V0 and V1 in that a V1 tool
   can parse a V0 announcement header but not vice-versa.  In SAPv0, the
   fields have the following values:

     o Version Number:  0

     o Message Type:  0 (Announcement)

     o Authentication Type:  0 (No Authentication)

     o Encryption Bit:  0 (No Encryption)

     o Compression Bit:  0 (No compression)

     o Message Id Hash:  0 (No Hash Specified)

     o Originating Source:  0 (No source specified, announcement has
       not been relayed)

B. Summary of differences between SAPv1 and SAPv2

   The packet headers of SAP messages are the same in V1 and V2 in that
   a V2 tool can parse a V1 announcement header but not necessarily
   vice-versa.

    o The A bit has been added to the SAP header, replacing one of the
      bits of the SAPv1 message type field.  If set to zero the
      announcement is of an IPv4 session, and the packet is backwards
      compatible with SAPv1.  If set to one the announcement is of an
      IPv6 session, and SAPv1 listeners (which do not support IPv6) will
      see this as an illegal message type (MT) field.

    o The second bit of the message type field in SAPv1 has been
      replaced by a reserved, must-be-zero, bit.  This bit was unused in
      SAPv1, so this change just codifies existing usage.

    o SAPv1 specified encryption of the payload.  SAPv2 includes the E
      bit in the SAP header to indicate that the payload is encrypted,
      but does not specify any details of the encryption.

    o SAPv1 allowed the message identifier hash and originating source
      fields to be set to zero, for backwards compatibility.  This is no
      longer legal.



Handley, et al.               Experimental                     [Page 14]

RFC 2974             Session Announcement Protocol          October 2000


    o SAPv1 specified gzip compression.  SAPv2 uses zlib (the only known
      implementation of SAP compression used zlib, and gzip compression
      was a mistake).

    o SAPv2 provides a more complete specification for authentication.

    o SAPv2 allows for non-SDP payloads to be transported.  SAPv1
      required that the payload was SDP.

    o SAPv1 included a timeout field for encrypted announcement, SAPv2
      does not (and relies of explicit deletion messages or implicit
      timeouts).

C. Acknowledgements

   SAP and SDP were originally based on the protocol used by the sd
   session directory from Van Jacobson at LBNL.  Version 1 of SAP was
   designed by Mark Handley as part of the European Commission MICE
   (Esprit 7602) and MERCI (Telematics 1007) projects.  Version 2
   includes authentication features developed by Edmund Whelan, Goli
   Montasser-Kohsari and Peter Kirstein as part of the European
   Commission ICE-TEL project (Telematics 1005), and support for IPv6
   developed by Maryann P. Maher and Colin Perkins.




























Handley, et al.               Experimental                     [Page 15]

RFC 2974             Session Announcement Protocol          October 2000


D. Authors' Addresses

   Mark Handley
   AT&T Center for Internet Research at ICSI,
   International Computer Science Institute,
   1947 Center Street, Suite 600,
   Berkeley, CA 94704, USA

   EMail: [e-mail]


   Colin Perkins
   USC Information Sciences Institute
   4350 N. Fairfax Drive, Suite 620
   Arlington, VA 22203, USA

   EMail: [e-mail]


   Edmund Whelan
   Department of Computer Science,
   University College London,
   Gower Street,
   London, WC1E 6BT, UK

   EMail: [e-mail]

























Handley, et al.               Experimental                     [Page 16]

RFC 2974             Session Announcement Protocol          October 2000


References

   [1] Bradner, S., "Key words for use in RFCs to indicate requirement
       levels", BCP 14, RFC 2119, March 1997.

   [2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP
       message format", RFC 2440, November 1998.

   [3] Deutsch, P. and J.-L. Gailly, "Zlib compressed data format
       specification version 3.3", RFC 1950, May 1996.

   [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, April 1998.

   [5] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone
       announcement protocol (MZAP)", RFC 2776, February 2000.

   [6] Housley, R., "Cryptographic message syntax", RFC 2630, June 1999.

   [7] Mayer, D., "Administratively scoped IP multicast", RFC 2365, July
       1998.






























Handley, et al.               Experimental                     [Page 17]

RFC 2974             Session Announcement Protocol          October 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Handley, et al.               Experimental                     [Page 18]