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/ |