rfc2974.txt

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


RFC 2974             Session Announcement Protocol          October 2000


   A: Address type. If the A bit is 0, the originating source field
      contains a 32-bit IPv4 address.  If the A bit is 1, the
      originating source contains a 128-bit IPv6 address.

   R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST
      ignore the contents of this field.

   T: Message Type. If the T field is set to 0 this is a session
      announcement packet, if 1 this is a session deletion packet.

   E: Encryption Bit. If the encryption bit is set to 1, the payload of
      the SAP packet is encrypted.  If this bit is 0 the packet is not
      encrypted.  See section 7 for details of the encryption process.

   C: Compressed bit. If the compressed bit is set to 1, the payload is
      compressed using the zlib compression algorithm [3].  If the
      payload is to be compressed and encrypted, the compression MUST be
      performed first.

   Authentication Length. An 8 bit unsigned quantity giving the number
      of 32 bit words following the main SAP header that contain
      authentication data.  If it is zero, no authentication header is
      present.

   Authentication data containing a digital signature of the packet,
      with length as specified by the authentication length header
      field.  See section 8 for details of the authentication process.

   Message Identifier Hash. A 16 bit quantity that, used in combination
      with the originating source, provides a globally unique identifier
      indicating the precise version of this announcement.  The choice
      of value for this field is not specified here, except that it MUST
      be unique for each session announced by a particular SAP announcer
      and it MUST be changed if the session description is modified (and
      a session deletion message SHOULD be sent for the old version of
      the session).

      Earlier versions of SAP used a value of zero to mean that the hash
      should be ignored and the payload should always be parsed.  This
      had the unfortunate side-effect that SAP announcers had to study
      the payload data to determine how many unique sessions were being
      advertised, making the calculation of the announcement interval
      more complex that necessary.  In order to decouple the session
      announcement process from the contents of those announcements, SAP
      announcers SHOULD NOT set the message identifier hash to zero.

      SAP listeners MAY silently discard messages if the message
      identifier hash is set to zero.



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


   Originating Source. This gives the IP address of the original source
      of the message.  This is an IPv4 address if the A field is set to
      zero, else it is an IPv6 address.  The address is stored in
      network byte order.

      SAPv0 permitted the originating source to be zero if the message
      identifier hash was also zero.  This practise is no longer legal,
      and SAP announcers SHOULD NOT set the originating source to zero.
      SAP listeners MAY silently discard packets with the originating
      source set to zero.

   The header is followed by an optional payload type field and the
   payload data itself.  If the E or C bits are set in the header both
   the payload type and payload are encrypted and/or compressed.

   The payload type field is a MIME content type specifier, describing
   the format of the payload.  This is a variable length ASCII text
   string, followed by a single zero byte (ASCII NUL).  The payload type
   SHOULD be included in all packets.  If the payload type is
   `application/sdp' both the payload type and its terminating zero byte
   MAY be omitted, although this is intended for backwards compatibility
   with SAP v1 listeners only.

   The absence of a payload type field may be noted since the payload
   section of such a packet will start with an SDP `v=0' field, which is
   not a legal MIME content type specifier.

   All implementations MUST support payloads of type `application/sdp'
   [4].  Other formats MAY be supported although since there is no
   negotiation in SAP an announcer which chooses to use a session
   description format other than SDP cannot know that the listeners are
   able to understand the announcement.  A proliferation of payload
   types in announcements has the potential to lead to severe
   interoperability problems, and for this reason, the use of non-SDP
   payloads is NOT RECOMMENDED.

   If the packet is an announcement packet, the payload contains a
   session description.

   If the packet is a session deletion packet, the payload contains a
   session deletion message.  If the payload format is `application/sdp'
   the deletion message is a single SDP line consisting of the origin
   field of the announcement to be deleted.

   It is desirable for the payload to be sufficiently small that SAP
   packets do not get fragmented by the underlying network.
   Fragmentation has a loss multiplier effect, which is known to
   significantly affect the reliability of announcements.  It is



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


   RECOMMENDED that SAP packets are smaller than 1kByte in length,
   although if it is known that announcements will use a network with a
   smaller MTU than this, then that SHOULD be used as the maximum
   recommended packet size.

7  Encrypted Announcements

   An announcement is received by all listeners in the scope to which it
   is sent.  If an announcement is encrypted, and many of the receivers
   do not have the encryption key, there is a considerable waste of
   bandwidth since those receivers cannot use the announcement they have
   received.  For this reason, the use of encrypted SAP announcements is
   NOT RECOMMENDED on the global scope SAP group or on administrative
   scope groups which may have many receivers which cannot decrypt those
   announcements.

   The opinion of the authors is that encrypted SAP is useful in special
   cases only, and that the vast majority of scenarios where encrypted
   SAP has been proposed may be better served by distributing session
   details using another mechanism.  There are, however, certain
   scenarios where encrypted announcements may be useful.  For this
   reason, the encryption bit is included in the SAP header to allow
   experimentation with encrypted announcements.

   This memo does not specify details of the encryption algorithm to be
   used or the means by which keys are generated and distributed.  An
   additional specification should define these, if it is desired to use
   encrypted SAP.

   Note that if an encrypted announcement is being announced via a
   proxy, then there may be no way for the proxy to discover that the
   announcement has been superseded, and so it may continue to relay the
   old announcement in addition to the new announcement.  SAP provides
   no mechanism to chain modified encrypted announcements, so it is
   advisable to announce the unmodified session as deleted for a short
   time after the modification has occurred.  This does not guarantee
   that all proxies have deleted the session, and so receivers of
   encrypted sessions should be prepared to discard old versions of
   session announcements that they may receive.  In most cases however,
   the only stateful proxy will be local to (and known to) the sender,
   and an additional (local-area) protocol involving a handshake for
   such session modifications can be used to avoid this problem.

   Session announcements that are encrypted with a symmetric algorithm
   may allow a degree of privacy in the announcement of a session, but
   it should be recognized that a user in possession of such a key can
   pass it on to other users who should not be in possession of such a
   key.  Thus announcements to such a group of key holders cannot be



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


   assumed to have come from an authorized key holder unless there is an
   appropriate authentication header signed by an authorized key holder.
   In addition the recipients of such encrypted announcements cannot be
   assumed to only be authorized key holders.  Such encrypted
   announcements do not provide any real security unless all of the
   authorized key holders are trusted to maintain security of such
   session directory keys.  This property is shared by the multicast
   session tools themselves, where it is possible for an un-trustworthy
   member of the session to pass on encryption keys to un-authorized
   users.  However it is likely that keys used for the session tools
   will be more short lived than those used for session directories.

   Similar considerations should apply when session announcements are
   encrypted with an asymmetric algorithm, but then it is possible to
   restrict the possessor(s) of the private key, so that announcements
   to a key-holder group can not be made, even if one of the untrusted
   members of the group proves to be un-trustworthy.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V=1 |P| Auth  |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |              Format  specific authentication subheader        |
   :                        ..................                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2:  Format of the authentication data in the SAP header

8  Authenticated Announcements

   The authentication header can be used for two purposes:

    o Verification that changes to a session description or deletion of
      a session are permitted.

    o Authentication of the identity of the session creator.

   In some circumstances only verification is possible because a
   certificate signed by a mutually trusted person or authority is not
   available.  However, under such circumstances, the session originator
   may still be authenticated to be the same as the session originator
   of previous sessions claiming to be from the same person.  This may
   or may not be sufficient depending on the purpose of the session and
   the people involved.






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


   Clearly the key used for the authentication should not be trusted to
   belong to the session originator unless it has been separately
   authenticated by some other means, such as being certified by a
   trusted third party.  Such certificates are not normally included in
   an SAP header because they take more space than can normally be
   afforded in an SAP packet, and such verification must therefore take
   place by some other mechanism.  However, as certified public keys are
   normally locally cached, authentication of a particular key only has
   to take place once, rather than every time the session directory
   retransmits the announcement.

   SAP is not tied to any single authentication mechanism.
   Authentication data in the header is self-describing, but the precise
   format depends on the authentication mechanism in use.  The generic
   format of the authentication data is given in figure 2.  The
   structure of the format specific authentication subheader, using both
   the PGP and the CMS formats, is discussed in sections 8.1 and 8.2
   respectively.  Additional formats may be added in future.

   Version Number, V:  The version number of the authentication format
      specified by this memo is 1.

   Padding Bit, P:  If necessary the authentication data is padded to be
      a multiple of 32 bits and the padding bit is set.  In this case
      the last byte of the authentication data contains the number of
      padding bytes (including the last byte) that must be discarded.

   Authentication Type, Auth: The authentication type is a  4 bit
      encoded field that denotes the authentication infrastructure the
      sender expects the recipients to use to check the authenticity and
      integrity of the information.  This defines the format of the
      authentication subheader and can take the values:  0 = PGP format,
      1 = CMS format.  All other values are undefined and SHOULD be
      ignored.

   If a SAP packet is to be compressed or encrypted, this MUST be done
   before the authentication is added.

   The digital signature in the authentication data MUST be calculated
   over the entire packet, including the header.  The authentication
   length MUST be set to zero and the authentication data excluded when
   calculating the digital signature.

   It is to be expected that sessions may be announced by a number of
   different mechanisms, not only SAP.  For example, a session
   description may placed on a web page, sent by email or conveyed in a





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


   session initiation protocol.  To ease interoperability with these
   other mechanisms, application level security is employed, rather than
   using IPsec authentication headers.

8.1 PGP Authentication

   A full description of the PGP protocol can be found in [2].  When
   using PGP for SAP authentication the basic format specific
   authentication subheader comprises a digital signature packet as
   described in [2].  The signature type MUST be 0x01 which means the
   signature is that of a canonical text document.

8.2 CMS Authentication

   A full description of the Cryptographic Message Syntax can be found
   in [6].  The format specific authentication subheader will, in the
   CMS case, have an ASN.1 ContentInfo type with the ContentType being
   signedData.

   Use is made of the option available in PKCS#7 to leave the content
   itself blank as the content which is signed is already present in the
   packet.  Inclusion of it within the SignedData type would duplicate
   this data and increase the packet length unnecessarily.  In addition
   this allows recipients with either no interest in the authentication,
   or with no mechanism for checking it, to more easily skip the
   authentication information.

   There SHOULD be only one signerInfo and related fields corresponding
   to the originator of the SAP announcement.  The signingTime SHOULD be
   present as a signedAttribute.  However, due to the strict size
   limitations on the size of SAP packets, certificates and CRLs SHOULD
   NOT be included in the signedData structure.  It is expected that
   users of the protocol will have other methods for certificate and CRL
   distribution.

9  Scalability and caching

   SAP is intended to announce the existence of long-lived wide-area
   multicast sessions.  It is not an especially timely protocol:
   sessions are announced by periodic multicast with a repeat rate on
   the order of tens of minutes, and no enhanced reliability over UDP.
   This leads to a long startup delay before a complete set of
   announcements is heard by a listener.  This delay is clearly
   undesirable for interactive browsing of announced sessions.

   In order to reduce the delays inherent in SAP, it is recommended that
   proxy caches are deployed.  A SAP proxy cache is expected to listen
   to all SAP groups in its scope, and to maintain an up-to-date list of



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