GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2974

Network Working Group M. Handley Request for Comments: 2974 ACIRI Category: Experimental C. Perkins

                                                               USC/ISI
                                                             E. Whelan
                                                                   UCL
                                                          October 2000
                   Session Announcement Protocol

Status of this Memo

 This memo defines an Experimental Protocol for the Internet
 community.  It does not specify an Internet standard of any kind.
 Discussion and suggestions for improvement are requested.
 Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

 This document describes version 2 of the multicast session directory
 announcement protocol, Session Announcement Protocol (SAP), and the
 related issues affecting security and scalability that should be
 taken into account by implementors.

1 Introduction

 In order to assist the advertisement of multicast multimedia
 conferences and other multicast sessions, and to communicate the
 relevant session setup information to prospective participants, a
 distributed session directory may be used.  An instance of such a
 session directory periodically multicasts packets containing a
 description of the session, and these advertisements are received by
 other session directories such that potential remote participants can
 use the session description to start the tools required to
 participate in the session.
 This memo describes the issues involved in the multicast announcement
 of session description information and defines an announcement
 protocol to be used.  Sessions are described using the session
 description protocol which is described in a companion memo [4].

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

2 Terminology

 A SAP announcer periodically multicasts an announcement packet to a
 well known multicast address and port.  The announcement is multicast
 with the same scope as the session it is announcing, ensuring that
 the recipients of the announcement are within the scope of the
 session the announcement describes (bandwidth and other such
 constraints permitting).  This is also important for the scalability
 of the protocol, as it keeps local session announcements local.
 A SAP listener learns of the multicast scopes it is within (for
 example, using the Multicast-Scope Zone Announcement Protocol [5])
 and listens on the well known SAP address and port for those scopes.
 In this manner, it will eventually learn of all the sessions being
 announced, allowing those sessions to be joined.
 The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',
 `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this
 document are to be interpreted as described in [1].

3 Session Announcement

 As noted previously, a SAP announcer periodically sends an
 announcement packet to a well known multicast address and port.
 There is no rendezvous mechanism - the SAP announcer is not aware of
 the presence or absence of any SAP listeners - and no additional
 reliability is provided over the standard best-effort UDP/IP
 semantics.
 That announcement contains a session description and SHOULD contain
 an authentication header.  The session description MAY be encrypted
 although this is NOT RECOMMENDED (see section 7).
 A SAP announcement is multicast with the same scope as the session it
 is announcing, ensuring that the recipients of the announcement are
 within the scope of the session the announcement describes. There are
 a number of possibilities:
 IPv4 global scope sessions use multicast addresses in the range
    224.2.128.0 - 224.2.255.255 with SAP announcements being sent to
    224.2.127.254 (note that 224.2.127.255 is used by the obsolete
    SAPv0 and MUST NOT be used).

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

 IPv4 administrative scope sessions using administratively scoped IP
    multicast as defined in [7].  The multicast address to be used for
    announcements is the highest multicast address in the relevant
    administrative scope zone.  For example, if the scope range is
    239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP
    announcements.
 IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE
    where X is the 4-bit scope value.  For example, an announcement
    for a link-local session assigned the address
    FF02:0:0:0:0:0:1234:5678, should be advertised on SAP address
    FF02:0:0:0:0:0:2:7FFE.
 Ensuring that a description is not used by a potential participant
 outside the session scope is not addressed in this memo.
 SAP announcements MUST be sent on port 9875 and SHOULD be sent with
 an IP time-to-live of 255 (the use of TTL scoping for multicast is
 discouraged [7]).
 If a session uses addresses in multiple administrative scope ranges,
 it is necessary for the announcer to send identical copies of the
 announcement to each administrative scope range.  It is up to the
 listeners to parse such multiple announcements as the same session
 (as identified by the SDP origin field, for example).  The
 announcement rate for each administrative scope range MUST be
 calculated separately, as if the multiple announcements were
 separate.
 Multiple announcers may announce a single session, as an aid to
 robustness in the face of packet loss and failure of one or more
 announcers.  The rate at which each announcer repeats its
 announcement MUST be scaled back such that the total announcement
 rate is equal to that which a single server would choose.
 Announcements made in this manner MUST be identical.
 If multiple announcements are being made for a session, then each
 announcement MUST carry an authentication header signed by the same
 key, or be treated as a completely separate announcement by
 listeners.
 An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP
 address and on the SAP addresses for each IPv4 administrative scope
 zone it is within.  The discovery of administrative scope zones is
 outside the scope of this memo, but it is assumed that each SAP
 listener within a particular scope zone is aware of that scope zone.
 A SAP listener which supports IPv6 SHOULD also listen to the IPv6 SAP
 addresses.

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

3.1 Announcement Interval

 The time period between repetitions of an announcement is chosen such
 that the total bandwidth used by all announcements on a single SAP
 group remains below a preconfigured limit.  If not otherwise
 specified, the bandwidth limit SHOULD be assumed to be 4000 bits per
 second.
 Each announcer is expected to listen to other announcements in order
 to determine the total number of sessions being announced on a
 particular group.  Sessions are uniquely identified by the
 combination of the message identifier hash and originating source
 fields of the SAP header (note that SAP v0 announcers always set the
 message identifier hash to zero, and if such an announcement is
 received the entire message MUST be compared to determine
 uniqueness).
 Announcements are made by periodic multicast to the group.  The base
 interval between announcements is derived from the number of
 announcements being made in that group, the size of the announcement
 and the configured bandwidth limit.  The actual transmission time is
 derived from this base interval as follows:
    1. The announcer initializes the variable tp to be the last time a
       particular announcement was transmitted (or the current time if
       this is the first time this announcement is to be made).
    2. Given a configured bandwidth limit in bits/second and an
       announcement of ad_size bytes, the base announcement interval
       in seconds is
              interval =max(300; (8*no_of_ads*ad_size)/limit)
    3. An offset is calculated based on the base announcement interval
              offset= rand(interval* 2/3)-(interval/3)
    4. The next transmission time for an announcement derived as
              tn =tp+ interval+ offset
 The announcer then sets a timer to expire at tn and waits.  At time
 tn the announcer SHOULD recalculate the next transmission time.  If
 the new value of tn is before the current time, the announcement is
 sent immediately.  Otherwise the transmission is rescheduled for the
 new tn.  This reconsideration prevents transient packet bursts on
 startup and when a network partition heals.

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

4 Session Deletion

 Sessions may be deleted in one of several ways:
 Explicit Timeout The session description payload may contain
    timestamp information specifying the start- and end-times of the
    session.  If the current time is later than the end-time of the
    session, then the session SHOULD be deleted from the receiver's
    session cache.
 Implicit Timeout A session announcement message should be received
    periodically for each session description in a receiver's session
    cache.  The announcement period can be predicted by the receiver
    from the set of sessions currently being announced.  If a session
    announcement message has not been received for ten times the
    announcement period, or one hour, whichever is the greater, then
    the session is deleted from the receiver's session cache.  The one
    hour minimum is to allow for transient network partitionings.
 Explicit Deletion A session deletion packet is received specifying
    the session to be deleted.  Session deletion packets SHOULD have a
    valid authentication header, matching that used to authenticate
    previous announcement packets.  If this authentication is missing,
    the deletion message SHOULD be ignored.

5 Session Modification

 A pre-announced session can be modified by simply announcing the
 modified session description.  In this case, the version hash in the
 SAP header MUST be changed to indicate to receivers that the packet
 contents should be parsed (or decrypted and parsed if it is
 encrypted).  The session itself, as distinct from the session
 announcement, is uniquely identified by the payload and not by the
 message identifier hash in the header.
 The same rules apply for session modification as for session
 deletion:
  o Either the modified announcement must contain an authentication
    header signed by the same key as the cached session announcement
    it is modifying, or:
  o The cached session announcement must not contain an authentication
    header, and the session modification announcement must originate
    from the same host as the session it is modifying.

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

 If an announcement is received containing an authentication header
 and the cached announcement did not contain an authentication header,
 or it contained a different authentication header, then the modified
 announcement MUST be treated as a new and different announcement, and
 displayed in addition to the un-authenticated announcement.  The same
 should happen if a modified packet without an authentication header
 is received from a different source than the original announcement.
 These rules prevent an announcement having an authentication header
 added by a malicious user and then being deleted using that header,
 and it also prevents a denial-of-service attack by someone putting
 out a spoof announcement which, due to packet loss, reaches some
 participants before the original announcement.  Note that under such
 circumstances, being able to authenticate the message originator is
 the only way to discover which session is the correct session.
  0                   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 |A|R|T|E|C|   auth len    |         msg id hash           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 :                originating source (32 or 128 bits)            :
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    optional authentication data               |
 :                              ....                             :
 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 |                      optional payload type                    |
 +                                         +-+- - - - - - - - - -+
 |                                         |0|                   |
 + - - - - - - - - - - - - - - - - - - - - +-+                   |
 |                                                               |
 :                            payload                            :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 1: Packet format

6 Packet Format

 SAP data packets have the format described in figure 1.
 V: Version Number. The version number field MUST be set to 1 (SAPv2
    announcements which use only SAPv1 features are backwards
    compatible, those which use new features can be detected by other
    means, so the SAP version number doesn't need to change).

Handley, et al. Experimental [Page 6] 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

 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: mjh@aciri.org
 Colin Perkins
 USC Information Sciences Institute
 4350 N. Fairfax Drive, Suite 620
 Arlington, VA 22203, USA
 EMail: csp@isi.edu
 Edmund Whelan
 Department of Computer Science,
 University College London,
 Gower Street,
 London, WC1E 6BT, UK
 EMail: e.whelan@cs.ucl.ac.uk

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2974.txt · Last modified: 2000/10/09 17:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki