Internet Engineering Task Force				       MMUSIC WG
Internet Draft						Maryann	P. Maher
draft-ietf-mmusic-sap-v2-00.txt					     ISI
16 November 1998                                                      Mark Handley
                                                             ACIRI
                                                     Colin Perkins
Expires: May 30, 1998
                                                               UCL
                                                     Edmund Whelan
                                                               UCL

                       Session Announcement Protocol: Version 2 Protocol
                      draft-ietf-mmusic-sap-v2-01.txt

                            Status of this Memo memo

This document is an Internet	Draft. Internet	Drafts Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its	Areas, areas, and its Working Groups. working groups.  Note that other groups
may also distribute working documents as	Internet Drafts.

   Internet Drafts Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
   months. Internet Drafts months and
may be updated, replaced, or obsoleted by other documents at any time.  It
is not appropriate inappropriate to use Internet
   Drafts Internet-Drafts as reference material or to cite
them other than as a	"working
   draft" or "work in progress."

   To view the entire

The list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au	(Pacific Rim),
   ftp.ietf.org	(US East Coast), or ftp.isi.edu	(US West Coast).

Abstract

   This	document describes modifications and enhancements to SAP, the
   session directory announcement protocol, for	support	of IPv6
   conferencing	environments. Along with support for IPv6, a couple new
   features are	also introduced.  This document	compliments [SAP], which
   fully describes SAP in the context of IPv4. Readers are assumed to can be
   familiar with [SAP].

   Note: At this time, this document presents an initial set of	ideas
   aimed solely accessed at starting discussion within the working group. We
   await the RFC publication of	[SAP] before finalizing	any protocol
   specifications.
http://www.ietf.org/shadow.html.

This document is a product of the Multiparty Multimedia Session Control (MMUSIC)
working group of the Internet Engineering Task Force.  Comments are
solicited and should be addressed to the working group's mailing list at
confctrl@isi.edu and/or the author.

   1.  Overview authors.

                                 Abstract

    This document describes a new version 2 of SAP, the multicast session directory
    announcement protocol, for support SAP, and the related issues affecting security
    and scalability that should be taken into account by the implementors
    of IPv6 conferencing environments.
   SAP is a protocol used for handling multicast session directory tools.

1  Introduction

In order to assist the advertisement of multicast multimedia conferences
and other multicast sessions, and unicast to communicate the relevant session
   description

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 potential participants who 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 encapsulating packet format announcement protocol
to be used by session directory clients. As currently defined, only IPv4
   session announcements  Sessions are supported mainly due to described
using the fact that an
   IPv4	address	field session description protocol which is contained described in the a companion
memo [4].

2  Terminology

A SAP announcer periodically multicasts an announcement packet header.  This docu-
   ment	describes the modifications to SAP for supporting IPv6 session
   announcements and introduces	some additional	new features. The two
   new features	described in this document are:

      1)
a MIME	Content-Type specifier, well known multicast address and

      2) a URL scheme port.  The announcement is multicast
with the same scope as the session it is announcing, ensuring that
the recipients of the announcement can also be potential recipients
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 8).

A SAP announcement is multicast with the same scope as the session
it is announcing, ensuring that the recipients of the announcement

can also be potential recipients of the session being advertised.
There are four possiblities:

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).

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.

Directory sessions are announced on an  address which is itself announced
    by a SAP announcement.  See section 6 for details for directory
    sessions.

SAP announcements MUST be sent on port 9875 and SHOULD be sent with
an IP time-to-live of 255.

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.
Support for directory sessions is OPTIONAL.

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.  If these
fields are non-zero they form a unique identifier for the announcement, if
they are zero then the entire message MUST be compared to determine
uniqueness.

Thus you should calculate the available bandwidth for your session's scope
by dividing the bandwidth limit by the number of other sessions being
announced in your scope.  This gives you your bandwidth allocation, which,
given the size of your data packets, can be used to derive the base
interval for announcements.  That is, given a limit in bits/second (as
above) and a ad_size in bytes, the base announcement interval in seconds is

         interval = MAX(300; (8* no_of_ads* ad_size)/limit)

For every interval between announcement packets (i.e, every time you send a
packet), you must add a random value (+/- 1/3 of the base interval) to the
value used for the inter-announcement period to prevent announcement
synchronisation.  It is also important to keep monitoring other
announcements and adjust the base interval accordingly.

4  Session Deletion

Sessions may be deleted in one of several ways:

Explicit Timeout The session description payload contains timestamp
    information which specifies a start and end time for the session.
    If the current time is later than the end-time for the session,
    then the session is deleted from the receiver's session cache.
    If an announcement packet arrives with an end-time before the
    current time, it is ignored.  If the payload is encrypted, and
    the receiver does not have the correct decryption key, the timeout
    field in the header should be used as an explicit timeout.

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 version of the session to be deleted.  The deletion packets
    should be ignored, unless they contain an authentication header
    which authenticates correctly and matches that used to authenticate
    the announcement which is being deleted.

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.

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.

v=0
o=cperkins 2890844526 2890842807 IN IP4 126.16.64.4
s=Sample directory session
m=directory 9875 SAP application/sdp
c=IN IP4 224.2.127.12/255
t=2873397496 2873404696

        Figure 1:  Example SDP for a directory session

6  Directory Sessions

It is possible to announce sessions which describe other directories.
Such directory sessions should each announce a single directory.  Receivers
MUST ignore announcements which describe multiple directories.  Receivers
SHOULD ignore non-authenticated directory sessions.

Directory sessions may be described in SDP using the media type `directory'
with transport `SAP' (see figure 1 for example).  Directory sessions
SHOULD be announced with TTL 255 and SHOULD use port 9875.  Any SAP
announcer may announce sessions in an announced SAP group, there
is no explicit access control.

If the announcement of a directory is deleted, announcers of sessions
within that directory MUST stop announcing those sessions provided
the deletion packet authenticates with the same key as the original
announcement of the directory session.  If the deletion packet is
not authenticated, or is authenticated with a different key, then
it SHOULD be ignored.

If the announcement of a directory times out, announcers of sessions
within that directory SHOULD stop announcing those sessions.

If the announcement of the directory is modified to use a different
address announcers of sessions within that directory MUST move their
announcement to the new directory, provided the modification packet
authenticates with the same key as the original announcement of the
directory session.  If the modification packet is not authenticated,
or is authenticated with a different key, then it SHOULD be ignored.

7  Packet Format

SAP data packets have the format described in figure 2.

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).

 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 header              |
:                              ....                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        optional timeout                       |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
|                      optional payload type                    |
+                                         +-+- - - - - - - - - -+
|                                         |0|                   |
+ - - - - - - - - - - - - - - - - - - - - +-+                   |
|                                                               |
:                            payload                            :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2: Packet format

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 and the timeout field MUST be
    added to the packet header.  If this bit is 0 the packet is
    not encrypted and the timeout MUST NOT be present.  See section
    8 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 Header containing a digital signature of the packet,
    with length as specified by the authentication length header
    field.  See section 9 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.

    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.

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.

Timeout. When the session payload is encrypted the detailed timing
    fields in the payload are not available to listeners which are
    not trusted with the decryption key.  Under such circumstances,
    the header includes an additional 32-bit timestamp field stating
    when the session should be timed out.

    Note that the timeout field in the header is intended for use
    only by those listeners which do not have the correct key to
    decrypt the announcement.  A SAP listener which is capable of
    decrypting the announcement MUST determine when to timeout the
    session based on the payload information.

    The value is an unsigned quantity giving the NTP time [8] in
    seconds at which time the session is timed out.  It is in network
    byte order.

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 optionally 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 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.

8  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 recognised 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 assumed to have come from an authorised key holder unless there
is an appropriate authentication header signed by an authorised key
holder.  In addition the recipients of such encrypted announcements
cannot be assumed to only be authorised key holders.  Such encrypted
announcements do not provide any real security unless all of the
authorised 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 referencing SAP announcements.

   Note: At this time, this document presents an initial set un-trustworthy member
of	ideas
   aimed solely	at starting discussion within the working group. We
   await session to pass on encryption keys to un-authorised 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 assymetric algorithm, but then it is possible to
restrict the RFC publication possessor(s) of	[SAP] before finalizing	any protocol
   specifications.

   2.  Modifications the private key, so that announcements
to a key-holder group can not be made, even if one of the SAP	Packet Format

   Current SAPv1 data packets are untrusted
members of the following format:

    0 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  | MT  |E|C|   auth len                                               |	    msg	id hash
+-+-+-+-+-+-+-+-+                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			  originating source              Format  specific authentication subheader        |
:                        ..................                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |		    optional

        Figure 3:  Format of the authentication header		   |
   |				 ....				   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			   optional timeout			   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			 optional random field			   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			      text payload			   |
   |				 ....				   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9  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 order 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 support 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.

Clearly the key used in the authentication header 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 clients retransmits
the announcement.

SAP is not tied to any single authentication mechanism.  Authentication
headers are self-describing, but their precise format depends on the
authentication mechanism in use.  The generic format of the Authentication
Header is given in IPv6 environments, figure 3.  The structure of the SAP packet format must be modified Format Specific
Authentication Subheader, using both the PGP and the CMS formats,
is discussed in sections 9.1 and 9.2 respectively.

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

Padding Bit, P:  If necessary the data in the authentication header
    is padded to contain be a 128-bit IPv6
   source address instead multiple of 32 bits and the 32-bit	IPv4 address.

   Therefore, SAP v2 data packets are padding bit  is
    set.  In this case the last byte of the following format:

    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| MT|E|C|   auth len	   |	    msg	id hash		   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |								   |
   |			  originating source			   |
   |				 ....				   |
   |								   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |		    optional authentication header		   |
   |				 ....				   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			   optional timeout			   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |		       optional	random field			   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |			    text payload			   |
   |				 ....				   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note:
    contains the version number in of padding bytes (including the packet header has NOT changed.

   A	   Address type: 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 = IPv4, PGP format, 1 = IPv6 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 A bit authentication is 0, added.

The digital signature in the orig source contains a 32-bit	IPv4 address. If authentication header MUST be calculated
over the A bit is	1, entire packet, including the orig source contains a 128-bit IPv6 address.

   3.  Scoping SAP Announcements header.  The authentication
length MUST be set to zero and the authentication header field excluded
when calculating the digitial signature.

9.1 PGP Authentication

Implementations which support authentication MUST support this format.
A full description of the PGP protocol can be found in [2].  When
using PGP for SAP client	that announces authentication the basic format specific authentication
subheader comprises a conference session periodically multi-
   casts an announcement digital signature packet	to a well known	multicast address and
   port. as described in [2].
The well known IPv6 SAP address signature type MUST be 0x01 which means the signature is FF0X:0:0:0:0:0:2:7FFE,
   where X that
of a canonical text document.

9.2 CMS Authentication

Support for this format is OPTIONAL.

A full description of the 4-bit	scope value. The following scope values	are
   currently defined Cryptographic Message Syntax can be found
in	IPv6:

	   Value  Scope			 Recommended Bandwidth Limit
	  ------ -----------		-----------------------------
	    0x1	  Node-local		      n/a
	    0x2	  Link-local		      20 Kbps
	    0x5	  Site-local		      10 Kbps
	    0x8	  Organization-local	      1	Kbps
	    0xE	  Global		      200 bps [6].  The announcement is multicast format specific authentication subheader will, in the
CMS case, have an ASN.1 ContentInfo type with the same scope ContentType being
signedData.

Use is made of the option available in PKCS#7 to leave the content
itself blank as the session it content which is announcing, ensuring that signed is already present in
the recipients packet.  Inclusion of it within the announcement can
   also	be potential 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 session being advertised.  Having SAP announcement.  The signingTime SHOUD
be present as a scope field within signedAttribute.  However, due to the address itself removes strict size
limitations on the need 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.

10 Scalability and caching

SAP is intended to carve out
   scope ranges	within announce the existence of long-lived wide-area
multicast address space or scope addresses
   according 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 corresponding	TTL.  Therefore, unlike 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 IPv4, TTL-
   scoped 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 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	do not exist in	IPv6 environments. directly, as if it has been
continually listening.

The	scope
   value to be used in the well-know protocol by which a SAP address listener contacts its local proxy cache
is simply the same used
   in the multicast address assigned not specified here.

11 Security  Considerations

SAP contains mechanisms for ensuring integrity of session announcements,
for authenticating the session.

   For example, origin of an announcement and for encrypting
such announcements (sections 8 and 9).  These mechanisms have not
yet been subject to suitable peer-review, and this memo should not
be considered authoritative in this area at this time.

As stated in section 5, if a link-local session assigned modification announcement is
received that contains a valid authentication header, but which is
not signed by the
   multicast address original creator of	FF02:0:0:0:0:0:1234:5678, should the session, then the session
must be advertised
   on SAP address FF02:0:0:0:0:0:2:7FFE. (Note:	Issues related to IPv6
   multicast address allocation	are being addressed treated as a new session in addition to the MALLOC work-
   ing group.)

   In original session
with the table	above, recommended bandwidth limits are	given for ses-
   sions within same SDP origin information unless the defined scopes. The	total bandwidth	to be used for
   SAP announcements should be one-fourth originator of one
of the session bandwidth,
   though descriptions can be authenticated using a certificate
signed by a trusted third party.  If this may were not done, there would
be inappropriate for	some uses.

   4.  SAP Payload

   In previous versions a possible denial of SAP,	the payload was	required to be service attack whereby a session
   description in party listens for
new announcements, strips off the SDP format [RFC2327]. With original authentication header,
modifies the introduction of new session description formats,	such as	SMIL [SMIL], it	is believed that description, adds a new authentication header

and re-announces the session.  If a rule was imposed that	restriction is no longer appropriate. SAP v2 therefore allows
   for other content such spoof
announcements were ignored, then if packet loss or late starting
of a session directory instance caused the original announcement to	be carried. That content should	begin with
fail to arrive at a
   MIME	Content-Type specifier.

	   Content-Type: application/sdp

	   v=0
	   o=...

   If site, but the content type is "application/sdp" spoof announcement did so, this
would then prevent the	MIME header may	be omit-
   ted,	for backwards compatibility with SAP v1	applications. If any
   other content original announcement from being accepted at
that site.

A similar denial-of-service attack is carried possible if a session announcement
receiver relies completely on the originating source and hash fields
to indicate change, and fails to parse the	MIME header MUST be present.

   5.  SAP URL scheme

   In certain cases, remainder of announcements
for which it has seen the origin/hash combination before.
A denial of service attack is desirable possible from a malicious site close
to	reference a SAP	announcement.
   For example,	if it legitimate site which is desired that making a	new participant	join an	existing session yet it is not known announcement.  This
can happen if that participant is within the scope malicious site floods the legitimate site with
huge numbers of (illegal) low TTL announcements describing high TTL
sessions.  This may reduce the session announcement then an explicit	reference to rate of the legitimate
announcement
   will	enable them to determine if it can be received.	Providing below a tenth of the rate expected at remote sites
and therefore cause the session description contained within	that announcement merely allows
   them to join time out.  Such an attack is likely
to be easily detectable, and we do not provide any mechanism here
to prevent it.

A  Summary of differences between SAPv0 and SAPv1

For this purpose SAPv0 is defined as the session, when they then notice that protocol in use by version
2.2 of the media
   streams session directory tool, sdr.  SAPv1 is the protocol described
in the 19 November 1996 version of this memo (draft-ietf-mmusic-sap-00.txt).
The packet headers of SAP messages are not visible.  Moreover, the addresses contained same in V0 and V1 in a ses-
   sion	description for	one scope may not be valid outside
that	scope
   zone.

   We therefore	define a URL scheme for	SAP announcements. 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	combina-
   tion packet headers of msg-id-hash SAP messages are the same in V1 and originating-source fields V2 in	the SAP
that a V2 tool can parse a V1 announcement header
   is sufficient but not necessarily
vice-versa.

  o The A bit has been added to identify a particular announcement.

   sap:msg-id@orig-source

   TBD:	What is the effect SAP header, replacing one of 10.x.x.x assignments on this?

   6.  Compatibility

   SAPv2 announcement are backwards compatible with
    the bits of the SAPv1 provided that message type field.  If set to zero the
    announcement is of an IPv4	sessions are announced, session, and that the payload packet is	SDP backwards
    compatible with the
   content-type	omitted.

   If IPv6 announcements are made, they	will be	discarded by SAPv1 tools
   since they represent	illegal	MT values in that protocol. SAPv1.  If set to one the Content-Type header announcement is present of
    an IPv6 session, and SAPv1 clients (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, payload.  SAPv2 includes the announce-
   ment	is invalid
    E bit in SAPv1. Those tools require the SAP header to indicate that SDP is used, hence 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 a backwards compatibility.  This
    is no longer legal.

  o SAPv1 announcement	MUST start with	"v=".

   7.  Security	Considerations specified gzip compression.  SAPv2 uses zlib (the only
    known implementation of SAP contains	mechanisms compression used zlib, and gzip compression
    was a mistake).

  o SAPv2 provides a more complete specification for ensuring	integrity of session announce-
   ments, authentication.

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

  o SAPv2 makes the concept of an announcement and for
   encrypting such announcements. The strengths directory session explicit.

C  Acknowledgments

SAP and limitations	of these
   mechanisms are described in SDP were originally based on the 'Security Considerations' section protocol used by the sd
session directory from Van Jacobson at LBNL. Version 1 of
   [SAP]. Those	considerations apply to	this document SAP was
designed by Mark Handley as well.

   8.  Acknowledgements

REFERENCES

   [SAP] Handley, M.J.,	Session	Announcement Protocol, draft-ietf-
       mmusic-sap-01.txt, work in progress.

   [ADDARCH] Hinden, R., part of the European Commission MICE
(Esprit 7602) and S.	Deering, "IP MERCI (Telematics 1007) projects.  Version 6 Addressing Archi-
       tecture", RFC 2373, July	1998.

   [IPV6] Deering, S., 2 includes
authentication features developed by Edmund Whelan, Goli Montasser-Kohsari
and R. Hinden, Editors, "Internet Protocol, Ver-
       sion 6 (IPv6) Specification", RFC 1883, December	1995.

   [MASGN] Hinden, R., Peter Kirstein as part of the European Commission ICE-TEL project
(Telematics 1005), and S. Deering, "IPv6 Multicast Address Assign-
       ments", RFC 2375, July 1998.

   [RFC2119] Bradner, S., "Key words support for use in	RFCs to	Indicate
       Requirement Levels", BCP	14, RFC	2119, March 1997.

   [SMIL]

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

Author's Address IPv6 developed by Maryann P. Maher <maher@isi.edu>
   USC/ISI
   4350	N. Fairfax Drive,
and Colin Perkins.  The idea of using SAP to announce other SAP sessions
is due to Ross Finlayson.

D  Authors' Addresses

Mark Handley <mjh@aciri.org>
AT&T Center for Internet Research at ICSI,
International Computer Science Institute,
1947 Center Street, Suite	620
   Arlington VA	22203 600,
Berkeley, CA 94704, USA

Colin Perkins <c.perkins@cs.ucl.ac.uk>
Department of Computer Science Science,
University College London London,
Gower Street
   London Street,
London, WC1E 6BT 6BT, UK

Edmund Whelan <e.whelan@cs.ucl.ac.uk>
Department of Computer Science,
University College London,
Gower Street,
London, WC1E 6BT, UK

References

[1] S. Bradner. Key words for use in RFCs to indicate requirement levels,
    March 1997. RFC2119.

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

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

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

[5] M. Handley,  D. Thaler, and R. Kermode. Multicast-scope zone
    announcement  protocol (MZAP)(, February 1999. Work in progress.

[6] R. Housley.  Cryptographic message syntax.  Work in progress, April
    1999.  draft-ietf-smime-cms-13.txt.

[7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365.

[8] D. Mills. Network time protocol version 3, March 1992.  RFC1305.

===============================================================================