draft-ietf-mmusic-sap-v2-05.txt | draft-ietf-mmusic-sap-v2-06.txt | |||
---|---|---|---|---|
INTERNET-DRAFT 21 February 2000 | INTERNET-DRAFT 6 March 2000 | |||
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-05.txt | draft-ietf-mmusic-sap-v2-06.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 provisions of Section 10 of RFC2026. | all 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 Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet-Drafts. | other groups may also distribute working documents as Internet-Drafts. | |||
skipping to change at page 2, line 6 ¶ | skipping to change at page 2, line 6 ¶ | |||
affecting security and scalability that should be taken | affecting security and scalability that should be taken | |||
into account by implementors. | into account by implementors. | |||
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 other session directories such that | |||
session description to start the tools required to participate in the | potential remote participants can use the session description to start | |||
session. | the tools required to participate in the session. | |||
This memo describes the issues involved in the multicast announcement of | This memo describes the issues involved in the multicast announcement | |||
session description information and defines an announcement protocol to be | of session description information and defines an announcement protocol | |||
used. Sessions are described using the session description protocol which | to be used. Sessions are described using the session description | |||
is described in a companion memo [4]. | 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 a well | |||
known multicast address and port. The announcement is multicast with the | known multicast address and port. The announcement is multicast with the | |||
same scope as the session it is announcing, ensuring that the recipients of | same scope as the session it is announcing, ensuring that the recipients of | |||
the announcement can also be potential recipients of the session the | the announcement are within the scope of the session the announcement | |||
announcement describes (bandwidth and other such constraints permitting). | describes (bandwidth and other such constraints permitting). This is also | |||
This is also important for the scalability of the protocol, as it keeps | important for the scalability of the protocol, as it keeps local session | |||
local session announcements local. | 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]. | |||
skipping to change at page 2, line 49 ¶ | skipping to change at page 2, line 49 ¶ | |||
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 | That announcement contains a session description and SHOULD contain | |||
an authentication header. The session description MAY be encrypted | an authentication header. The session description MAY be encrypted | |||
although 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. | are within the scope of the session the announcement describes. | |||
There a number of possiblities: | There are 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). | |||
IPv4 administrative scope sessions using administratively scoped | IPv4 administrative scope sessions using administratively scoped | |||
IP multicast as defined in [7]. The multicast address to be | IP multicast as defined in [7]. The multicast address to be | |||
used for announcements is the highest multicast address in the | used for announcements is the highest multicast address in the | |||
relevant administrative scope zone. For example, if the scope | 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 | range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used | |||
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 | 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, | 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. | should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE. | |||
Ensuring that a description is not used by a potential participant | ||||
outside the session scope is not addressed in this memo. | ||||
SAP announcements MUST be sent on port 9875 and SHOULD be sent with | SAP announcements MUST be sent on port 9875 and SHOULD be sent with | |||
an IP time-to-live of 255 (the use of TTL scoping for multicast is | an IP time-to-live of 255 (the use of TTL scoping for multicast is | |||
discouraged [7]). | discouraged [7]). | |||
If a session uses addresses in multiple administrative scope ranges, | If a session uses addresses in multiple administrative scope ranges, | |||
it is necessary for the announcer to send identical copies of the | it is necessary for the announcer to send identical copies of the | |||
announcement to each administrative scope range. It is up to the | announcement to each administrative scope range. It is up to the | |||
listeners to parse such multiple announcements as the same session | listeners to parse such multiple announcements as the same session | |||
(as identified by the SDP origin field, for example). The announcement | (as identified by the SDP origin field, for example). The announcement | |||
rate for each administrative scope range MUST be calculated separately, | rate for each administrative scope range MUST be calculated separately, | |||
skipping to change at page 4, line 8 ¶ | skipping to change at page 4, line 13 ¶ | |||
SHOULD also listen to the IPv6 SAP addresses. | SHOULD also listen to the IPv6 SAP addresses. | |||
3.1 Announcement Interval | 3.1 Announcement Interval | |||
The time period between repetitions of an announcement is chosen | The time period between repetitions of an announcement is chosen | |||
such that the total bandwidth used by all announcements on a single | such that the total bandwidth used by all announcements on a single | |||
SAP group remains below a preconfigured limit. If not otherwise | SAP group remains below a preconfigured limit. If not otherwise | |||
specified, the bandwidth limit SHOULD be assumed to be 4000 bits | specified, the bandwidth limit SHOULD be assumed to be 4000 bits | |||
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 | |||
determine the total number of sessions being announced on a particular | to 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 | |||
identifier hash and originating source fields of the SAP header (note that | message identifier hash and originating source fields of the SAP | |||
SAP v0 announcers always set the message identifier hash to zero, and if | header (note that SAP v0 announcers always set the message identifier | |||
such an announcement is received the entire message MUST be compared to | hash to zero, and if such an announcement is received the entire | |||
determine uniqueness). | message MUST be compared to 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 | |||
interval as follows: | base 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. At time | The announcer then sets a timer to expire at tn and waits. At time | |||
tn the announcer SHOULD recalculate the next transmission time. If | tn the announcer SHOULD recalculate the next transmission time. If | |||
the new value of tn is before the current time, the announcement | the new value of tn is before the current time, the announcement | |||
is sent immediately. Otherwise the transmission is rescheduled for | is sent immediately. Otherwise the transmission is rescheduled for | |||
the new tn. This reconsideration prevents transient packet bursts | the new tn. This reconsideration prevents transient packet bursts | |||
on startup and when a network partition heals. | on startup and when a network partition heals. | |||
4 Session Deletion | 4 Session Deletion | |||
skipping to change at page 5, line 46 ¶ | skipping to change at page 6, line 4 ¶ | |||
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 | If an announcement is received containing an authentication header | |||
and the cached announcement did not contain an authentication header, | and the cached announcement did not contain an authentication header, | |||
or it contained a different authentication header, then the modified | or it contained a different authentication header, then the modified | |||
announcement MUST be treated as a new and different announcement, | 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 | ||||
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 | ||||
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 27 ¶ | skipping to change at page 6, line 28 ¶ | |||
+ +-+- - - - - - - - - -+ | + +-+- - - - - - - - - -+ | |||
| |0| | | | |0| | | |||
+ - - - - - - - - - - - - - - - - - - - - +-+ | | + - - - - - - - - - - - - - - - - - - - - +-+ | | |||
| | | | | | |||
: payload : | : payload : | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Packet format | Figure 1: Packet format | |||
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 | 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. If this bit is 0 the packet | of the SAP packet is encrypted. If this bit is 0 the packet | |||
is not encrypted. See section 7 for details of the encryption | is not encrypted. See section 7 for details of the encryption | |||
process. | 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 is | authentication data. If it is zero, no authentication header | |||
present. | is 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 (and a session deletion message SHOULD be sent for the | |||
old version of the session). | ||||
Earlier versions of SAP used a value of zero to mean that the | 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 | SAP announcers SHOULD NOT set the message identifier hash to zero. | |||
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 | 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 | to zero, else it is an IPv6 address. The address is stored | |||
in network 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 | |||
skipping to change at page 7, line 58 ¶ | skipping to change at page 8, line 12 ¶ | |||
SAP listeners MAY silently discard packets with the originating | SAP listeners MAY silently discard packets with the originating | |||
source set to zero. | source set to zero. | |||
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 | The payload type field is a MIME content type specifier, describing the | |||
format of the payload. This is a variable length ASCII text string, | 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 | followed by a single zero byte (ASCII NUL). The payload type SHOULD be | |||
included in all packets. If the payload type is `application/sdp' | included in all packets. If the payload type is `application/sdp' both the | |||
both the payload type and its terminating zero byte MAY be omitted, | payload type and its terminating zero byte MAY be omitted, although this is | |||
although this is intended for backwards compatibility with SAP v1 | 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 | |||
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' | |||
Other formats MAY be supported although since there is no negotiation in | [4]. Other formats MAY be supported although since there is no negotiation | |||
SAP an announcer which chooses to use a session description format other | in SAP an announcer which chooses to use a session description format | |||
than SDP cannot know that the listeners are able to understand the | other than SDP cannot know that the listeners are able to understand | |||
announcement. A proliferation of payload types in announcements has the | the announcement. A proliferation of payload types in announcements | |||
potential to lead to severe interoperability problems, and for this reason, | has the potential to lead to severe interoperability problems, and | |||
the use of non-SDP payloads is NOT RECOMMENDED. | for this reason, the use of non-SDP payloads is NOT RECOMMENDED. | |||
If the packet is an announcement packet, the payload contains a session | If the packet is an announcement packet, the payload contains a session | |||
description. | description. | |||
If the packet is a session deletion packet, the payload contains a session | If the packet is a session deletion packet, the payload contains | |||
deletion message. If the payload format is `application/sdp' the deletion | a session deletion message. If the payload format is `application/sdp' | |||
message is a single SDP line consisting of the origin field of the | the deletion message is a single SDP line consisting of the origin | |||
announcement to be deleted. | field of the 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 packets | |||
do not get fragmented by the underlying network. Fragmentation has a loss | do not get fragmented by the underlying network. Fragmentation has a loss | |||
multiplier effect, which is known to significantly affect the reliability | multiplier effect, which is known to significantly affect the reliability | |||
of announcements. It is RECOMMENDED that SAP packets are smaller than | of announcements. It is RECOMMENDED that SAP packets are smaller than | |||
1kByte in length, although if it is known that announcements will use a | 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 | network with a smaller MTU than this, then that SHOULD be used as the | |||
maximum recommended packet size. | maximum recommended packet size. | |||
7 Encrypted Announcements | 7 Encrypted Announcements | |||
skipping to change at page 9, line 10 ¶ | skipping to change at page 9, line 18 ¶ | |||
details using another mechanism. There are, however, certain scenarios | details using another mechanism. There are, however, certain scenarios | |||
where encrypted announcements may be useful. For this reason, the | where encrypted announcements may be useful. For this reason, the | |||
encryption bit is included in the SAP header to allow experimentation | encryption bit is included in the SAP header to allow experimentation | |||
with encrypted announcements. | with encrypted announcements. | |||
This memo does not specify details of the encryption algorithm to | This memo does not specify details of the encryption algorithm to | |||
be used or the means by which keys are generated and distributed. | be used or the means by which keys are generated and distributed. | |||
An additional specification should define these, if it is desired | An additional specification should define these, if it is desired | |||
to use encrypted SAP. | to use encrypted SAP. | |||
Note that if an encrypted announcement is being announced via a proxy, then | Note that if an encrypted announcement is being announced via a proxy, | |||
there may be no way for the proxy to discover that the announcement has | then there may be no way for the proxy to discover that the announcement | |||
been superseded, and so it may continue to relay the old announcement in | has been superseded, and so it may continue to relay the old announcement | |||
addition to the new announcement. SAP provides no mechanism to chain | in addition to the new announcement. SAP provides no mechanism to | |||
modified encrypted announcements, so it is advisable to announce the | chain modified encrypted announcements, so it is advisable to announce | |||
unmodified session as deleted for a short time after the modification has | the unmodified session as deleted for a short time after the modification | |||
occurred. This does not guarantee that all proxies have deleted the | has occurred. This does not guarantee that all proxies have deleted | |||
session, and so receivers of encrypted sessions should be prepared to | the session, and so receivers of encrypted sessions should be prepared | |||
discard old versions of session announcements that they may receive. In | to discard old versions of session announcements that they may receive. | |||
most cases however, the only stateful proxy will be local to (and known to) | In most cases however, the only stateful proxy will be local to (and | |||
the sender, and an additional (local-area) protocol involving a handshake | known to) the sender, and an additional (local-area) protocol involving | |||
for such session modifications can be used to avoid this problem. | a handshake for such session modifications can be used to avoid this | |||
problem. | ||||
Session announcements that are encrypted with a symmetric algorithm | Session announcements that are encrypted with a symmetric algorithm | |||
may allow a degree of privacy in the announcement of a session, but | 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 | 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 | 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 | a key. Thus announcements to such a group of key holders cannot | |||
be assumed to have come from an authorised key holder unless there | be assumed to have come from an authorised key holder unless there | |||
is an appropriate authentication header signed by an authorised key | is an appropriate authentication header signed by an authorised key | |||
holder. In addition the recipients of such encrypted announcements | holder. In addition the recipients of such encrypted announcements | |||
cannot be assumed to only be authorised key holders. Such encrypted | cannot be assumed to only be authorised key holders. Such encrypted | |||
skipping to change at page 9, line 46 ¶ | skipping to change at page 10, line 5 ¶ | |||
of the session to pass on encryption keys to un-authorised users. | of the session to pass on encryption keys to un-authorised users. | |||
However it is likely that keys used for the session tools will be | However it is likely that keys used for the session tools will be | |||
more short lived than those used for session directories. | more short lived than those used for session directories. | |||
Similar considerations should apply when session announcements are | Similar considerations should apply when session announcements are | |||
encrypted with an asymmetric algorithm, but then it is possible to | encrypted with an asymmetric algorithm, but then it is possible to | |||
restrict the possessor(s) of the private key, so that announcements | restrict the possessor(s) of the private key, so that announcements | |||
to a key-holder group can not be made, even if one of the untrusted | to a key-holder group can not be made, even if one of the untrusted | |||
members of the group proves to be un-trustworthy. | members of the group proves to be un-trustworthy. | |||
8 Authenticated Announcements | ||||
The authentication header can be used for two purposes: | ||||
o Verification that changes to a session description or deletion | ||||
of a session are permitted. | ||||
o Authentication of the identity of the session creator. | ||||
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 | |||
8 Authenticated Announcements | ||||
The authentication header can be used for two purposes: | ||||
o Verification that changes to a session description or deletion | ||||
of a session are permitted. | ||||
o Authentication of the identity of the session creator. | ||||
In some circumstances only verification is possible because a certificate | In some circumstances only verification is possible because a certificate | |||
signed by a mutually trusted person or authority is not available. | signed by a mutually trusted person or authority is not available. | |||
However, under such circumstances, the session originator may still be | However, under such circumstances, the session originator may still | |||
authenticated to be the same as the session originator of previous sessions | be authenticated to be the same as the session originator of previous | |||
claiming to be from the same person. This may or may not be sufficient | sessions claiming to be from the same person. This may or may not | |||
depending on the purpose of the session and the people involved. | be sufficient depending on the purpose of the session and the people | |||
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 | locally cached, authentication of a particular key only has to take | |||
place once, rather than every time the session directory retransmits | place once, rather than every time the session directory retransmits | |||
the announcement. | the announcement. | |||
SAP is not tied to any single authentication mechanism. Authentication | SAP is not tied to any single authentication mechanism. Authentication | |||
data in the header is self-describing, but the precise format depends | data in the header is self-describing, but the precise format depends | |||
on the authentication mechanism in use. The generic format of the | 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. Additional | |||
formats may be added in future. | ||||
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 | |||
number of padding bytes (including the last byte) that must be | number of padding bytes (including the last byte) that must be | |||
discarded. | discarded. | |||
skipping to change at page 11, line 18 ¶ | skipping to change at page 11, line 29 ¶ | |||
before the authentication is added. | before the authentication is added. | |||
The digital signature in the authentication data MUST be calculated | The digital signature in the authentication data MUST be calculated | |||
over the entire packet, including the header. The authentication | over the entire packet, including the header. The authentication | |||
length MUST be set to zero and the authentication data excluded when | length MUST be set to zero and the authentication data excluded when | |||
calculating the digital signature. | calculating the digital signature. | |||
It is to be expected that sessions may be announced by a number of | It is to be expected that sessions may be announced by a number of | |||
different mechanisms, not only SAP. For example, a session description | different mechanisms, not only SAP. For example, a session description | |||
may placed on a web page, sent by email or conveyed in a session | may placed on a web page, sent by email or conveyed in a session | |||
initiation protocol. To ease interoperability with these other mechanisms, | initiation protocol. To ease interoperability with these other | |||
application level security is employed, rather than using IPsec authentication | mechanisms, application level security is employed, rather than | |||
headers. | using IPsec authentication headers. | |||
8.1 PGP Authentication | 8.1 PGP Authentication | |||
Implementations which support authentication MUST support this format. A | A full description of the PGP protocol can be found in [2]. When using PGP | |||
full description of the PGP protocol can be found in [2]. When using PGP | ||||
for SAP authentication the basic format specific authentication subheader | for SAP authentication the basic format specific authentication subheader | |||
comprises a digital signature packet as described in [2]. The signature | comprises a digital signature packet as described in [2]. The signature | |||
type MUST be 0x01 which means the signature is that of a canonical text | type MUST be 0x01 which means the signature is that of a canonical text | |||
document. | document. | |||
8.2 CMS Authentication | 8.2 CMS Authentication | |||
Support for this format is OPTIONAL. | ||||
A full description of the Cryptographic Message Syntax can be found | A full description of the Cryptographic Message Syntax can be found | |||
in [6]. The format specific authentication subheader will, in the | in [6]. The format specific authentication subheader will, in the | |||
CMS case, have an ASN.1 ContentInfo type with the ContentType being | CMS case, have an ASN.1 ContentInfo type with the ContentType being | |||
signedData. | signedData. | |||
Use is made of the option available in PKCS#7 to leave the content itself | Use is made of the option available in PKCS#7 to leave the content | |||
blank as the content which is signed is already present in the packet. | itself blank as the content which is signed is already present in | |||
Inclusion of it within the SignedData type would duplicate this data and | the packet. Inclusion of it within the SignedData type would duplicate | |||
increase the packet length unnecessarily. In addition this allows | this data and increase the packet length unnecessarily. In addition | |||
recipients with either no interest in the authentication, or with no | this allows recipients with either no interest in the authentication, | |||
mechanism for checking it, to more easily skip the authentication | or with no mechanism for checking it, to more easily skip the authentication | |||
information. | information. | |||
There SHOULD be only one signerInfo and related fields corresponding | There SHOULD be only one signerInfo and related fields corresponding | |||
to the originator of the SAP announcement. The signingTime SHOULD | to the originator of the SAP announcement. The signingTime SHOULD | |||
be present as a signedAttribute. However, due to the strict size | be present as a signedAttribute. However, due to the strict size | |||
limitations on the size of SAP packets, certificates and CRLs SHOULD | limitations on the size of SAP packets, certificates and CRLs SHOULD | |||
NOT be included in the signedData structure. It is expected that | NOT be included in the signedData structure. It is expected that | |||
users of the protocol will have other methods for certificate and | users of the protocol will have other methods for certificate and | |||
CRL distribution. | CRL distribution. | |||
skipping to change at page 13, line 6 ¶ | skipping to change at page 13, line 13 ¶ | |||
new announcements, strips off the original authentication header, | new announcements, strips off the original authentication header, | |||
modifies the session description, adds a new authentication header | modifies the session description, adds a new authentication header | |||
and re-announces the session. If a rule was imposed that such spoof | and re-announces the session. If a rule was imposed that such spoof | |||
announcements were ignored, then if packet loss or late starting | announcements were ignored, then if packet loss or late starting | |||
of a session directory instance caused the original announcement to | of a session directory instance caused the original announcement to | |||
fail to arrive at a site, but the spoof announcement did so, this | fail to arrive at a site, but the spoof announcement did so, this | |||
would then prevent the original announcement from being accepted at | would then prevent the original announcement from being accepted at | |||
that site. | that site. | |||
A similar denial-of-service attack is possible if a session announcement | A similar denial-of-service attack is possible if a session announcement | |||
receiver relies completely on the originating source and hash fields | receiver relies completely on the originating source and hash fields to | |||
to indicate change, and fails to parse the remainder of announcements | indicate change, and fails to parse the remainder of announcements for | |||
for which it has seen the origin/hash combination before. | which it has seen the origin/hash combination before. | |||
A denial of service attack is possible from a malicious site close | A denial of service attack is possible from a malicious site close | |||
to a legitimate site which is making a session announcement. This | to a legitimate site which is making a session announcement. This | |||
can happen if the malicious site floods the legitimate site with | can happen if the malicious site floods the legitimate site with | |||
huge numbers of (illegal) low TTL announcements describing high TTL | huge numbers of (illegal) low TTL announcements describing high TTL | |||
sessions. This may reduce the session announcement rate of the legitimate | sessions. This may reduce the session announcement rate of the legitimate | |||
announcement to below a tenth of the rate expected at remote sites | announcement to below a tenth of the rate expected at remote sites | |||
and therefore cause the session to time out. Such an attack is likely | and therefore cause the session to time out. Such an attack is likely | |||
to be easily detectable, and we do not provide any mechanism here | to be easily detectable, and we do not provide any mechanism here | |||
to prevent it. | to prevent it. | |||
skipping to change at page 15, line 34 ¶ | skipping to change at page 15, line 34 ¶ | |||
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 | [5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone | |||
announcement protocol (MZAP), February 2000, RFC2776. | announcement protocol (MZAP), February 2000. RFC2776. | |||
[6] R. Housley. Cryptographic message syntax, June 1999. RFC2630. | [6] R. Housley. Cryptographic message syntax, June 1999. RFC2630. | |||
[7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. | [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. | |||
End of changes. 35 change blocks. | ||||
105 lines changed or deleted | 110 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/ |