draft-ietf-mmusic-sap-v2-03.txt   draft-ietf-mmusic-sap-v2-04.txt 
INTERNET-DRAFT 21 October 1999 INTERNET-DRAFT 13 December 1999
Mark Handley Mark Handley
ACIRI ACIRI
Colin Perkins Colin Perkins
UCL UCL
Edmund Whelan Edmund Whelan
UCL UCL
Session Announcement Protocol Session Announcement Protocol
draft-ietf-mmusic-sap-v2-03.txt draft-ietf-mmusic-sap-v2-04.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with all
all provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task
Task Force (IETF), its areas, and its working groups. Note that Force (IETF), its areas, and its working groups. Note that other groups
other groups may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months and
and may be updated, replaced, or obsoleted by other documents at may be updated, replaced, or obsoleted by other documents at any time. It
any time. It is inappropriate to use Internet-Drafts as reference is inappropriate to use Internet-Drafts as reference material or to cite
material or to cite them other than as "work in progress." them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a product of the Multiparty Multimedia Session Control This document is a product of the Multiparty Multimedia Session Control
working group of the Internet Engineering Task Force. Comments are working group of the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing solicited and should be addressed to the working group's mailing list at
list at confctrl@isi.edu and/or the authors. confctrl@isi.edu and/or the authors.
Abstract Abstract
This document describes version 2 of the multicast session This document describes version 2 of the multicast session directory
directory announcement protocol, SAP, and the related issues announcement protocol, SAP, and the related issues affecting security
affecting security and scalability that should be taken and scalability that should be taken into account by the implementors
into account by the implementors of multicast session directory of multicast session directory tools.
tools.
1 Introduction 1 Introduction
In order to assist the advertisement of multicast multimedia conferences In order to assist the advertisement of multicast multimedia conferences
and other multicast sessions, and to communicate the relevant session and other multicast sessions, and to communicate the relevant session
setup information to prospective participants, a distributed session setup information to prospective participants, a distributed session
directory may be used. An instance of such a session directory periodically directory may be used. An instance of such a session directory periodically
multicasts packets containing a description of the session, and these multicasts packets containing a description of the session, and these
advertisements are received by potential participants who can use the advertisements are received by potential participants who can use the
session description to start the tools required to participate in the session description to start the tools required to participate in the
session. session.
This memo describes the issues involved in the multicast announcement of This memo describes the issues involved in the multicast announcement of
session description information and defines an announcement protocol to be session description information and defines an announcement protocol to be
used by session directory clients. Sessions are described using the used by session directory clients. Sessions are described using the
session description protocol which is described in a companion memo [4]. session description protocol which is described in a companion memo [4].
2 Terminology 2 Terminology
A SAP announcer periodically multicasts an announcement packet to a well A SAP announcer periodically multicasts an announcement packet to
known multicast address and port. The announcement is multicast with the a well known multicast address and port. The announcement is multicast
same scope as the session it is announcing, ensuring that the recipients of with the same scope as the session it is announcing, ensuring that
the announcement can also be potential recipients of the session the the recipients of the announcement can also be potential recipients
announcement describes (bandwidth and other such constraints permitting). of the session the announcement describes (bandwidth and other such
This is also important for the scalability of the protocol, as it keeps constraints permitting). This is also important for the scalability
local session announcements local. of the protocol, as it keeps local session announcements local.
A SAP listener learns of the multicast scopes it is within (for example, A SAP listener learns of the multicast scopes it is within (for example,
using the Multicast-Scope Zone Announcement Protocol [5]) and listens on 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 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 will eventually learn of all the sessions being announced, allowing those
sessions to be joined. sessions to be joined.
The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT',
`SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
3 Session Announcement 3 Session Announcement
As noted previously, a SAP announcer periodically sends an announcement As noted previously, a SAP announcer periodically sends an announcement
packet to a well known multicast address and port. There is no rendezvous 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 mechanism - the SAP announcer is not aware of the presence or absence of
any SAP listeners - and no additional reliability is provided over the any SAP listeners - and no additional reliability is provided over the
standard best-effort UDP/IP semantics. standard best-effort UDP/IP semantics.
That announcement contains a session description and SHOULD contain an That announcement contains a session description and SHOULD contain
authentication header. The session description MAY be encrypted although an authentication header. The session description MAY be encrypted
this is NOT RECOMMENDED (see section 7). although this is NOT RECOMMENDED (see section 7).
A SAP announcement is multicast with the same scope as the session A SAP announcement is multicast with the same scope as the session
it is announcing, ensuring that the recipients of the announcement it is announcing, ensuring that the recipients of the announcement
can also be potential recipients of the session being advertised. can also be potential recipients of the session being advertised.
There a number of possiblities: There a number of possiblities:
IPv4 global scope sessions use multicast addresses in the range IPv4 global scope sessions use multicast addresses in the range
224.2.128.0 - 224.2.255.255 with SAP announcements being sent 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 to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete
SAPv0 and MUST NOT be used). SAPv0 and MUST NOT be used).
skipping to change at page 3, line 27 skipping to change at page 3, line 27
for SAP announcements. for SAP announcements.
IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE 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 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, 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. should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE.
SAP announcements MUST be sent on port 9875 and SHOULD be sent with SAP announcements MUST be sent on port 9875 and SHOULD be sent with
an IP time-to-live of 255. an IP time-to-live of 255.
If a session uses addresses in multiple administrative scope ranges, it is If a session uses addresses in multiple administrative scope ranges,
necessary for the announcer to send identical copies of the announcement to it is necessary for the announcer to send identical copies of the
each administrative scope range. It is up to the listeners to parse such announcement to each administrative scope range. It is up to the
multiple announcements as the same session (as identified by the SDP origin listeners to parse such multiple announcements as the same session
field, for example). The announcement rate for each administrative scope (as identified by the SDP origin field, for example). The announcement
range MUST be calculated separately, as if the multiple announcements were rate for each administrative scope range MUST be calculated separately,
separate. as if the multiple announcements were separate.
Multiple announcers may announce a single session, as an aid to robustness 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 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 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 that the total announcement rate is equal to that which a single server
would choose. Announcements made in this manner MUST be identical. would choose. Announcements made in this manner MUST be identical.
If multiple announcements are being made for a session, then each If multiple announcements are being made for a session, then each
announcement MUST carry an authentication header signed by the same announcement MUST carry an authentication header signed by the same
key, or be treated as a completely separate announcement by listeners. key, or be treated as a completely separate announcement by listeners.
skipping to change at page 4, line 21 skipping to change at page 4, line 21
per second. per second.
Each announcer is expected to listen to other announcements in order to Each announcer is expected to listen to other announcements in order to
determine the total number of sessions being announced on a particular determine the total number of sessions being announced on a particular
group. Sessions are uniquely identified by the combination of the message group. Sessions are uniquely identified by the combination of the message
identifier hash and originating source fields of the SAP header (note that identifier hash and originating source fields of the SAP header (note that
SAP v0 clients always set the message identifier hash to zero, and if such SAP v0 clients always set the message identifier hash to zero, and if such
an announcement is received the entire message MUST be compared to an announcement is received the entire message MUST be compared to
determine uniqueness). determine uniqueness).
Announcements are made by periodic multicast to the group. The base Announcements are made by periodic multicast to the group. The base
interval between announcements is derived from the number of announcements interval between announcements is derived from the number of announcements
being made in that group, the size of the announcement and the configured being made in that group, the size of the announcement and the configured
bandwidth limit. The actual transmission time is derived from this base bandwidth limit. The actual transmission time is derived from this base
interval as follows: interval as follows:
1.The announcer initialises the variable tp to be the last time 1. The announcer initialises the variable tp to be the last time
a particular announcement was transmitted (or the current time a particular announcement was transmitted (or the current time
if this is the first time this announcement is to be made). if this is the first time this announcement is to be made).
2.Given a configured bandwidth limit in bits/second and an announcement 2. Given a configured bandwidth limit in bits/second and an announcement
of ad_size bytes, the base announcement interval in seconds is of ad_size bytes, the base announcement interval in seconds is
interval =max(300; (8*no_of_ads*ad_size)=limit) interval = max(300; (8*no_of_ads*ad_size)/limit)
3.An offset is calculated based on the base announcement interval 3. An offset is calculated based on the base announcement interval
offset= rand(interval* 2=3)-(interval=3) offset= rand(interval* 2/3)-(interval/3)
4.The next transmission time for an announcement derived as 4. The next transmission time for an announcement derived as
tn =tp+ interval+ offset tn =tp+ interval+ offset
The announcer then sets a timer to expire at tn and waits. When this timer The announcer then sets a timer to expire at tn and waits. At time
expires, the announcement is transmitted. tn the announcer SHOULD recalculate the next transmission time. If
the new value of tn is before the current time, the announcement
If, at some time tc <tn, the no_of_ads changes (eg: if a new announcer is sent immediately. Otherwise the transmission is rescheduled for
starts up, or an existing announcement is deleted), the announcer SHOULD the new tn. This reconsideration prevents transient packet bursts
recalculate the next transmission time. If the new value of tn is less on startup and when a network partition heals.
than tc the announcement is sent immediately. Otherwise the transmission
is rescheduled for the new tn.
4 Session Deletion 4 Session Deletion
Sessions may be deleted in one of several ways: Sessions may be deleted in one of several ways:
Explicit Timeout The session description payload contains timestamp Explicit Timeout The session description payload contains timestamp
information which specifies a start and end time for the session. information which specifies a start and end time for the session.
If the current time is later than the 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. then the session is deleted from the receiver's session cache.
If an announcement packet arrives with an end-time before the If an announcement packet arrives with an end-time before the
skipping to change at page 6, line 5 skipping to change at page 5, line 48
The same rules apply for session modification as for session deletion: The same rules apply for session modification as for session deletion:
o Either the modified announcement must contain an authentication o Either the modified announcement must contain an authentication
header signed by the same key as the cached session announcement header signed by the same key as the cached session announcement
it is modifying, or: it is modifying, or:
o The cached session announcement must not contain an authentication o The cached session announcement must not contain an authentication
header, and the session modification announcement must originate header, and the session modification announcement must originate
from the same host as the session it is modifying. 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,
0 1 2 3 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 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 | | V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: originating source (32 or 128 bits) : : originating source (32 or 128 bits) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data | | optional authentication data |
skipping to change at page 6, line 30 skipping to change at page 6, line 29
+ +-+- - - - - - - - - -+ + +-+- - - - - - - - - -+
| |0| | | |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ | + - - - - - - - - - - - - - - - - - - - - +-+ |
| | | |
: payload : : payload :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet format Figure 1: Packet format
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 and displayed in addition to the un-authenticated announcement. The
same should happen if a modified packet without an authentication same should happen if a modified packet without an authentication
header is received from a different source than the original announcement. header is received from a different source than the original announcement.
These rules prevent an announcement having an authentication header These rules prevent an announcement having an authentication header
added by a malicious user and then being deleted using that 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 and it also prevents a denial-of-service attack by someone putting
out a spoof announcement which, due to packet loss, reaches some out a spoof announcement which, due to packet loss, reaches some
participants before the original announcement. Note that under such participants before the original announcement. Note that under such
circumstances, being able to authenticate the message originator is circumstances, being able to authenticate the message originator is
the only way to discover which session is the correct session. the only way to discover which session is the correct session.
6 Packet Format 6 Packet Format
SAP data packets have the format described in figure 1. SAP data packets have the format described in figure 1.
V: Version Number. The version number field MUST be set to 1 (SAPv2 V: Version Number. The version number field MUST be set to 1 (SAPv2
announcements which use only SAPv1 features are backwards compatible, announcements which use only SAPv1 features are backwards compatible,
those which use new features can be detected by other means, those which use new features can be detected by other means,
so the SAP version number doesn't need to change). so the SAP version number doesn't need to change).
A: Address type. If the A bit is 0, the originating source field 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 contains a 32-bit IPv4 address. If the A bit is 1, the originating
source contains a 128-bit IPv6 address. source contains a 128-bit IPv6 address.
R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST
ignore the contents of this field. ignore the contents of this field.
T: Message Type. If the T field is set to 0 this is a session announcement 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. packet, if 1 this is a session deletion packet.
E: Encryption Bit. If the encryption bit is set to 1, the payload 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 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 added to the packet header. If this bit is 0 the packet is
not encrypted and the timeout MUST NOT be present. See section not encrypted and the timeout MUST NOT be present. See section
7 for details of the encryption process. 7 for details of the encryption process.
C: Compressed bit. If the compressed bit is set to 1, the payload C: Compressed bit. If the compressed bit is set to 1, the payload
is compressed using the zlib compression algorithm [3]. If the is compressed using the zlib compression algorithm [3]. If the
payload is to be compressed and encrypted, the compression MUST payload is to be compressed and encrypted, the compression MUST
be performed first. be performed first.
Authentication Length. An 8 bit unsigned quantity giving the number Authentication Length. An 8 bit unsigned quantity giving the number
of 32 bit words following the main SAP header that contain of 32 bit words following the main SAP header that contain
authentication data. If it is zero, no authentication header authentication data. If it is zero, no authentication header is
is present. present.
Authentication data containing a digital signature of the packet, Authentication data containing a digital signature of the packet,
with length as specified by the authentication length header with length as specified by the authentication length header
field. See section 8 for details of the authentication process. field. See section 8 for details of the authentication process.
Message Identifier Hash. A 16 bit quantity that, used in combination Message Identifier Hash. A 16 bit quantity that, used in combination
with the originating source, provides a globally unique identifier with the originating source, provides a globally unique identifier
indicating the precise version of this announcement. The choice indicating the precise version of this announcement. The choice
of value for this field is not specified here, except that it of value for this field is not specified here, except that it
MUST be unique for each session announced by a particular SAP MUST be unique for each session announced by a particular SAP
announcer and it MUST be changed if the session description is announcer and it MUST be changed if the session description is
modified. modified.
Earlier versions of SAP used a value of zero to mean that the Earlier versions of SAP used a value of zero to mean that the
hash should be ignored and the payload should always be parsed. hash should be ignored and the payload should always be parsed.
This had the unfortunate side-effect that SAP announcers had This had the unfortunate side-effect that SAP announcers had
to study the payload data to determine how many unique sessions to study the payload data to determine how many unique sessions
were being advertised, making the calculation of the announcement were being advertised, making the calculation of the announcement
interval more complex that necessary. In order to decouple the interval more complex that necessary. In order to decouple the
session announcement process from the contents of those announcements, session announcement process from the contents of those announcements,
SAP announcers SHOULD NOT set the message identifier hash to zero. SAP announcers SHOULD NOT set the message identifier hash to zero.
SAP listeners MAY silently discard messages if the message identifier SAP listeners MAY silently discard messages if the message identifier
hash is set to zero. hash is set to zero.
Originating Source. This gives the IP address of the original source 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 of the message. This is an IPv4 address if the A field is set
zero, else it is an IPv6 address. The address is stored in network to zero, else it is an IPv6 address. The address is stored
byte order. in network byte order.
SAPv0 permitted the originating source to be zero if the message SAPv0 permitted the originating source to be zero if the message
identifier hash was also zero. This practise is no longer legal, identifier hash was also zero. This practise is no longer legal,
and SAP announcers SHOULD NOT set the originating source to zero. and SAP announcers SHOULD NOT set the originating source to zero.
SAP listeners MAY silently discard packets with the originating
source set 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 Timeout. When the session payload is encrypted the detailed timing
fields in the payload are not available to listeners which are fields in the payload are not available to listeners which are
not trusted with the decryption key. Under such circumstances, not trusted with the decryption key. Under such circumstances,
the header includes an additional 32-bit timestamp field stating the header includes an additional 32-bit timestamp field stating
when the session should be timed out. when the session should be timed out.
Note that the timeout field in the header is intended for use Note that the timeout field in the header is intended for use
only by those listeners which do not have the correct key to only by those listeners which do not have the correct key to
decrypt the announcement. A SAP listener which is capable of decrypt the announcement. A SAP listener which is capable of
decrypting the announcement MUST determine when to timeout the decrypting the announcement MUST determine when to timeout the
session based on the payload information. session based on the payload information.
The value is an unsigned quantity giving the NTP time [8] in 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 seconds at which time the session is timed out. It is in network
byte order. byte order.
The header is followed by an optional payload type field and the 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 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 and payload are encrypted and/or compressed.
The payload type field is a MIME content type specifier, describing The payload type field is a MIME content type specifier, describing
the format of the payload. This is a variable length ASCII text the format of the payload. This is a variable length ASCII text
string, followed by a single zero byte (ASCII NUL). The payload type 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' 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, both the payload type and its terminating zero byte MAY be omitted,
although this is intended for backwards compatibility with SAP v1 although this is intended for backwards compatibility with SAP v1
listeners only. listeners only.
The absence of a payload type field may be noted since the payload 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 section of such a packet will start with an SDP `v=0' field, which
skipping to change at page 8, line 54 skipping to change at page 8, line 45
The absence of a payload type field may be noted since the payload 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 section of such a packet will start with an SDP `v=0' field, which
is not a legal MIME content type specifier. is not a legal MIME content type specifier.
All implementations MUST support payloads of type `application/sdp' [4]. All implementations MUST support payloads of type `application/sdp' [4].
Other formats MAY be supported although since there is no negotiation in Other formats MAY be supported although since there is no negotiation in
SAP an announcer which chooses to use a session description format other SAP an announcer which chooses to use a session description format other
than SDP cannot know that the listeners are able to understand the than SDP cannot know that the listeners are able to understand the
announcement. A proliferation of payload types in announcements has the announcement. A proliferation of payload types in announcements has the
potential to lead to severe interoperability problems, and for this reason, potential to lead to severe interoperability problems, and for this reason,
the use of non-SDP payloads is NOT RECOMMENDED. 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 an announcement packet, the payload contains a session
description.
If the packet is a session deletion packet, the payload contains If the packet is a session deletion packet, the payload contains a session
a session deletion message. If the payload format is `application/sdp' deletion message. If the payload format is `application/sdp' the deletion
the deletion message is a single SDP line consisting of the origin message is a single SDP line consisting of the origin field of the
field of the announcement to be deleted. announcement to be deleted.
It is desirable for the payload to be sufficiently small that SAP packets It is desirable for the payload to be sufficiently small that SAP
do not get fragmented by the underlying network. Fragmentation has a loss packets do not get fragmented by the underlying network. Fragmentation
multiplier effect, which is known to significantly affect the reliability has a loss multiplier effect, which is known to significantly affect the
of announcements. It is RECOMMENDED that SAP packets are smaller than reliability of announcements. It is RECOMMENDED that SAP packets are
1kByte in length, although if it is known that announcements will use a smaller than 1kByte in length, although if it is known that announcements
network with a smaller MTU than this, then that SHOULD be used as the will use a network with a smaller MTU than this, then that SHOULD be used
maximum recommended packet size. as the maximum recommended packet size.
7 Encrypted Announcements 7 Encrypted Announcements
An announcement is received by all listeners in the scope to which 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 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 do not have the encryption key, there is a considerable waste of
bandwidth since those receivers cannot use the announcement they have bandwidth since those receivers cannot use the announcement they have
received. For this reason, the use of encrypted SAP announcements received. For this reason, the use of encrypted SAP announcements
is NOT RECOMMENDED on the global scope SAP group or on administrative is NOT RECOMMENDED on the global scope SAP group or on administrative
scope groups which may have many receivers which cannot decrypt those scope groups which may have many receivers which cannot decrypt those
skipping to change at page 11, line 4 skipping to change at page 10, line 46
be sufficient depending on the purpose of the session and the people be sufficient depending on the purpose of the session and the people
involved. involved.
Clearly the key used for the authentication should not be trusted Clearly the key used for the authentication should not be trusted
to belong to the session originator unless it has been separately to belong to the session originator unless it has been separately
authenticated by some other means, such as being certified by a trusted authenticated by some other means, such as being certified by a trusted
third party. Such certificates are not normally included in an SAP third party. Such certificates are not normally included in an SAP
header because they take more space than can normally be afforded header because they take more space than can normally be afforded
in an SAP packet, and such verification must therefore take place in an SAP packet, and such verification must therefore take place
by some other mechanism. However, as certified public keys are normally 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
1 2 3 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 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 | | | V=1 |P| Auth | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Format specific authentication subheader | | Format specific authentication subheader |
: .................. : : .................. :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of the authentication data in the SAP header Figure 2: Format of the authentication data in the SAP header
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 authentication data is given in figure 2. The structure of the format
specific authentication subheader, using both the PGP and the CMS specific authentication subheader, using both the PGP and the CMS
formats, is discussed in sections 8.1 and 8.2 respectively. formats, is discussed in sections 8.1 and 8.2 respectively.
Version Number, V: The version number of the authentication format Version Number, V: The version number of the authentication format
specified by this memo is 1. specified by this memo is 1.
Padding Bit, P: If necessary the authentication data is padded Padding Bit, P: If necessary the authentication data is padded
to be a multiple of 32 bits and the padding bit is set. In 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 this case the last byte of the authentication data contains the
skipping to change at page 14, line 51 skipping to change at page 14, line 46
o SAPv1 specified encryption of the payload. SAPv2 includes the o SAPv1 specified encryption of the payload. SAPv2 includes the
E bit in the SAP header to indicate that the payload is encrypted, E bit in the SAP header to indicate that the payload is encrypted,
but does not specify any details of the encryption. but does not specify any details of the encryption.
o SAPv1 allowed the message identifier hash and originating source o SAPv1 allowed the message identifier hash and originating source
fields to be set to zero, for backwards compatibility. This fields to be set to zero, for backwards compatibility. This
is no longer legal. is no longer legal.
o SAPv1 specified gzip compression. SAPv2 uses zlib (the only o SAPv1 specified gzip compression. SAPv2 uses zlib (the only
known implementation of SAP compression used zlib, and gzip compression known implementation of SAP compression used zlib, and gzip
was a mistake). compression was a mistake).
o SAPv2 provides a more complete specification for authentication. o SAPv2 provides a more complete specification for authentication.
o SAPv2 allows for non-SDP payloads to be transported. SAPv1 required o SAPv2 allows for non-SDP payloads to be transported. SAPv1 required
that the payload was SDP. that the payload was SDP.
C Acknowledgments C Acknowledgments
SAP and SDP were originally based on the protocol used by the sd 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 session directory from Van Jacobson at LBNL. Version 1 of SAP was
skipping to change at page 15, line 41 skipping to change at page 15, line 41
Department of Computer Science, Department of Computer Science,
University College London, University College London,
Gower Street, Gower Street,
London, WC1E 6BT, UK London, WC1E 6BT, UK
References References
[1] S. Bradner. Key words for use in RFCs to indicate requirement levels, [1] S. Bradner. Key words for use in RFCs to indicate requirement levels,
March 1997. RFC2119. March 1997. RFC2119.
[2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message [2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message
format, November 1998. RFC2440. format, November 1998. RFC2440.
[3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification [3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification
version 3.3, May 1996. RFC1950. version 3.3, May 1996. RFC1950.
[4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April [4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April
1998. RFC2327. 1998. RFC2327.
[5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone announcement [5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone
protocol (MZAP), February 1999. Work in progress. announcement protocol (MZAP), February 1999. Work in progress.
[6] R. Housley. Cryptographic message syntax. Work in progress, April 1999. [6] R. Housley. Cryptographic message syntax. Work in progress,
draft-ietf-smime-cms-13.txt. April 1999. draft-ietf-smime-cms-13.txt.
[7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365.
[8] D. Mills. Network time protocol version 3, March 1992. RFC1305. [8] D. Mills. Network time protocol version 3, March 1992. RFC1305.
 End of changes. 51 change blocks. 
152 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/