idnits 2.17.1 draft-ietf-mmusic-sap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 243 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 179 instances of lines with control characters in the document. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...fts are worki...' == Line 12 has weird spacing: '...ments of the ...' == Line 13 has weird spacing: '...t other group...' == Line 17 has weird spacing: '...and may be ...' == Line 21 has weird spacing: '... please check...' == (238 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 1996) is 10023 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 628, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1119 (ref. '2') (Obsoleted by RFC 1305) ** Downref: Normative reference to an Informational RFC: RFC 1952 (ref. '3') ** Obsolete normative reference: RFC 1890 (ref. '4') (Obsoleted by RFC 3551) Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 INTERNET-DRAFT Mark Handley 4 draft-ietf-mmusic-sap-00.txt ISI 5 19th Nov 1996 7 SAP: Session Announcement Protocol 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 This document describes the SAP - the session directory 32 announcement protocol, and the related issues affecting secu- 33 rity and scalability that should be taken into account by the 34 implementors of session directory tools. It is a companion 35 document to draft-ietf-mmusic-sdp. 37 This document is a product of the Multiparty Multimedia Session Control 38 (MMUSIC) working group of the Internet Engineering Task Force. Comments 39 are solicited and should be addressed to the working group's mailing 40 list at confctrl@isi.edu and/or the author. 42 1. Introduction 44 An mbone session directory is used to advertise multimedia conferences, 45 and to communicate the session addresses (whether multicast or unicast) 46 and conference-tool-specific information necessary for participation. 47 Such sessions are described using the Session Description Protocol (SDP) 48 which is described in a companion draft. This document describes the 49 issues involved in the multicast announcement of session description 50 packets and defines a packet format to be used by session directory 51 clients. SAP v0 is currently implemented in Sdr and other compatible 52 tools. This document describes SAP v1, which contains some enhancements 53 to the basic announcement model. The differences between SAP v1 and SAP 54 v0 are described in Appendix A. Much of this document is concerned with 55 security considerations - these security considerations have not yet 56 been subject to suitable peer-review, and this document should not be 57 considered authoritative in this area. 59 2. Background 61 IP Multicast is an extension of internet routing that permits efficient 62 many-to-many communication. It is used extensively for multimedia con- 63 ferencing. Such multimedia sessions usually have the property that 64 tight coordination of session membership is not necessary; in order to 65 receive a session, a user at a multicast-capable site only has to know 66 the correct multicast group address for the session and the transport 67 ports the conferencing applications will use to receive the conference 68 data streams. 70 In order to assist the advertisement of multicast sessions and to com- 71 municate the relevant session setup information to prospective partici- 72 pants, a distributed session directory is used. An instance of such a 73 session directory periodically multicasts packets containing a descrip- 74 tion of a multimedia session, and these advertisements are received by 75 potential participants who can use the session description to start the 76 tools required to participate in the session. The companion draft 77 ``SDP: Session Description Protocol'' describes a payload format suit- 78 able for such session descriptions. This draft describes the distribu- 79 tion mechanism and packet format. 81 3. The SAP Protocol 83 SAP is an announcement protocol for multicast conference sessions. An 84 SAP client that announces a conference session periodically multicasts 85 an announcement packet to a well known multicast address and port. The 86 announcement is multicast with the same scope (as defined by group 87 address range or TTL) as the session it is announcing. This ensures 88 that the recipients of the announcement can also be potential recipients 89 of the session the announcement describes (bandwidth and other such con- 90 straints permitting). This is also important for the scalability of the 91 protocol, as it keeps local session announcements local. 93 The time period between one announcement and its repetition is dependent 94 on two factors - the scope (TTL) of the session, and the number of other 95 sessions currently being announced by other session directory clients. 96 The goal is to keep the total bandwidth being used below a predefined 97 level for each scope. 99 Session Announcement 101 A session to be announced is simply multicast to the appropriate well- 102 known multicast address and port. The announcement contains a session 103 description and, optionally, an authentication header. The session 104 description may be encrypted. 106 Session Deletion 108 Sessions may be deleted in one of several ways: 110 Explicit Timeout 111 The session description contains timestamp information which speci- 112 fies a start and end time for the session. If the current time is 113 later than the end-time for the session, then the session is deleted 114 from the receiver's session cache. If an announcement packet 115 arrives with an end-time before the current time, it is ignored. 117 Implicit Timeout 118 A session announcement message should be received periodically for 119 each session description in a receiver's session cache. The 120 announcement period can be predicted by the receiver from the set of 121 sessions currently being announced. If a session announcement mes- 122 sage has not been received for ten times the announcement period, or 123 half an hour, whichever is the greater, then the session is deleted 124 from the receiver's session cache. The half hour minimum is to 125 allow for transient network partitionings. 127 Explicit Deletion 128 A session deletion packet is received specifying the version of the 129 session to be deleted. If the cached session contains an authentica- 130 tion header, the session deletion packet must contain a signature 131 signed by the same key. If the cached session does not contain an 132 authentication header, but the deletion packet has the same IP- 133 source address (not the SAP-stated source address in the packet) as 134 that from which the session announcement was originally announced, 135 then the session is deleted. If neither of these conditions is 136 not the case, then the session deletion packet is ignored. Note 137 that IP source addresses can be spoofed, and although the RPF filter 138 in most multicast routing algorithms will result in the packet not 139 being delivered in some cases, this is insufficient protection in 140 many cases, and an authentication header should be used for such 141 situations. 143 Session Modification 145 A pre-announced session can be modified by simply announcing the modi- 146 fied session description. In this case, the version hash in the SAP 147 header should be changed to indicate to receivers that the packet con- 148 tents should be parsed (or decrypted and parsed if it is encrypted). 149 The session itself is uniquely identified by the SDP origin field in the 150 payload, and not by the version hash in the SAP header. 152 The same rules apply for session modification as for session deletion: 154 + Either the modified announcement must contain an authentication 155 header signed by the same key as the cached session announcement it 156 is modifying, or: 158 + The cached session announcement must not contain an authentication 159 header, and the session modification announcement must originate 160 from the same host as the session it is modifying. 162 If an announcement is received containing a authentication header and 163 the cached announcement did not contain an authentication header, or it 164 contained an different authentication header, then the modified 165 announcement must be treated as a new and different announcement, and 166 displayed in addition to the un-authenticated announcement. The same 167 should happen if a modified packet without an authentication header is 168 received from a different source than the original announcement. These 169 rules prevent an announcement having an authentication header added by a 170 malicious user and then being deleted using that header, and it also 171 prevents a denial-of-service attack by someone putting out a spoof 172 announcement which, due to packet loss, reaches some participants before 173 the original announcement. Note that under such circumstances, being 174 able to authenticate the message originator is the only way to discover 175 which session is the correct session. 177 4. Packet Format 179 Unencrypted SAP data packets are of the following format: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | V=1 | MT |E|C| auth len | msg id hash | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | orig source | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | optional authentication header | 189 | .... | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | text payload | 192 | .... | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Encrypted SAP data packets contain additional fields 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | V=1 | MT |E|C| auth len | msg id hash | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | orig source | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | optional authentication header | 205 | .... | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | key id | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | timeout | 210 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 211 |P| random field | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | text payload | 214 | .... | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Only fields from * onwards are encrypted. 219 V: Version Number 221 SAP version number = 1 222 MT: Message Type 224 One of the following: 226 0 Session description announcement packet. The text payload is an SDP 227 session description, as described in draft-ietf-mmusic-sdp. 229 1 Session description deletion packet. The text payload is a single 230 SDP line consisting of the origin field of the announcement to be 231 deleted. 233 E - Encryption Bit 235 If the encryption bit is set, the text payload of the SAP packet is 236 encrypted, and additional fields are added to the packet: Key-ID, 237 Timeout, P (padding) and Random. The Key-ID and Timeout fields are not 238 encrypted, but the P and Random fields are encrypted along with the text 239 payload. Note the encryption algorithm is not specified in the packet - 240 this is communicated to permitted receivers out-of-band along with the 241 corresponding decryption key. 243 C - Compressed bit 245 This bit indicates that the payload was compressed using the gzip 246 compression algorithm [3]. 248 Authentication Length: 250 A 8 bit unsigned quantity giving the number of 32 bit words following 251 the main SAP header that contain authentication data (and padding bytes 252 if present). If it is zero, no authentication header is present. 254 Authentication Header 256 This contains a digital signature (encrypted cryptographic hash) of the 257 text payload (including key-id, expiry timestamp, and encrypted random 258 field and text payload if the payload is encrypted) from the end of the 259 authentication header onwards. It also contains the public key with 260 which the authentication header can be checked, and information to iden- 261 tify the encryption algorithm and mode used. It can be used for two 262 purposes: 264 + Verification that changes to a session description or deletion of a 265 session are permitted. 267 + Authentication of the identity of the session creator. 269 In some circumstances only Verification is possible because a certifi- 270 cate signed by a mutually trusted person or authority is not available. 271 However, under such circumstances, the session originator may still be 272 authenticated to be the same as the session originator of previous ses- 273 sions claiming to be from the same person. This may or may not be suf- 274 ficient depending on the purpose of the session and the people involved. 276 Clearly the key given in the authentication header should not be trusted 277 to belong to the session originator unless it has been separately 278 authenticated by some other means, such as being certified by a trusted 279 third party. Such certificates are not normally included in an SAP 280 header because they take more space than can normally be afforded in an 281 SAP packet, and such verification must therefore take place by some 282 other mechanism. However, as certified public keys are normally locally 283 cached, authentication of a particular key only has to take place once, 284 rather than every time the session directory retransmits the announce- 285 ment. 287 SAP is not tied to any single authentication mechanism. Authentication 288 Headers must be self-describing, but their precise format depends on the 289 authentication mechanism (signature and encryption scheme) in use, and 290 so is not defined here. 292 Message Identifier Hash 294 A 16 bit quantity that, used in combination with the originating source, 295 provides a globally unique id identifying the precise version of this 296 announcement. The message id hash should be changed if any field of the 297 session description is changed. A value of zero means the hash should 298 be ignored and the message should always be parsed. 300 Originating Source 302 This gives the IP address of the original source of the message. It is 303 permissible to be zero if the message has not passed through a proxy 304 relay and if the message id hash is also zero, though this is intended 305 only for backwards compatibility with SAPv0 clients. 307 Key ID 309 The key identifier is a 32 bit network byte-order integer which is used 310 as a hint to identify which encryption key was used to encrypt a packet. 311 Key id's should be randomly generated when a new encryption key is 312 chosen for a group of users, and so they are not guaranteed to be glo- 313 bally unique. If a receiver has multiple keys with the same key-id, to 314 perform decryption each key in turn must be used until one of them suc- 315 cessfully decrypts the data. 317 Timeout 319 When the session payload is encrypted, and the session description is 320 being relayed or announced via a proxy, the detailed timing fields in 321 the SDP description are not available to the proxy as they are encrypted 322 and the proxy is not trusted with the decryption key. Under such cir- 323 cumstances, SAP includes an additional 32-bit timestamp field stating 324 when the session should be timed out. This field is included after the 325 authentication header, and the digital signature in the authentication 326 header encompasses the timeout so that a session cannot be maliciously 327 deleted by modifying its timeout in an announcing proxy. 329 The value is an unsigned quantity giving the NTP time [2] in seconds at 330 which time the session is timed out. It is in network byte order. 332 P: Encryption Padding 334 This bit indicates that the payload was padded prior to encryption. The 335 last byte of the decrypted payload indicates how many padding bytes were 336 added. 338 Random 340 This field is only present when the payload is encrypted. It is 341 encrypted along with the payload, and is used to perform the randomiza- 342 tion task normally performed by an initialization vector in algorithms 343 such as cipher-block chained DES. This 31 bit field should contain a 344 genuinely random number. After decryption, this field is discarded. 346 5. Encrypted Announcements 348 Announcements may be encrypted using any encryption algorithm or mode. 349 However, the use of DES in cipher-block chaining (CBC) mode is recom- 350 mended as the default case. The choice of encryption algorithm and mode 351 is conveyed to potential recipients along with the encryption key itself 352 and a 32 bit key identifier which should be randomly chosen and is used 353 as a non-globally-unique identifier for the key. 355 In normal usage, a {decryption-key,keyid,algorithm,mode} tuple will be 356 conveyed in advance to the intended group recipients. This process 357 takes place out-of-band and is not described in this draft. However, if 358 keys are to be communicated as plain text, the use of MD5 as described 359 in [4] is recommended to manipulate the key prior to use. 361 Session announcements may then be made to the appropriate session 362 announcement address, encrypted so that they can be decrypted with the 363 group key. The key-id is carried in the announcement packets, and 364 serves as an index into a sparse key-ring at each receiver. As key-id's 365 are allocated randomly, in some cases more than one decryption-key may 366 be identified by the same key id - this is expected to be a rare event, 367 but may happen. When more that one key is identified by a key-id, each 368 of the decryption keys in turn must be tried. 370 5.1. Encrypting Announcements 372 If the payload is to be compressed, this is performed first before 373 encryption or padding. 375 When an announcement is to be encrypted, a 32-bit word is prepended to 376 the session description payload. The most significant bit of this 377 number (in network byte order) is set to zero if the session description 378 does not require padding for encryption, and set to one if padding is 379 required for encryption, in which case the last byte of the padded ses- 380 sion description contains the number of padding bytes added. The least 381 significant 31 bits of this 32 bit quantity should contain random data. 383 The padded and 32-bit pre-pended session description is then encrypted 384 using the relevant encryption algorithm, key and mode. The encrypted 385 payload is then sent with an extended SAP header which has the E bit set 386 and contains the key id and timeout fields as described above. 388 5.2. Decrypting Announcements 390 Upon receiving a new announcement with the encryption bit set, a 391 receiver should attempt to decrypt the announcement with each of its set 392 of session decryption keys that has the key-id appearing in the 393 announcement. If it succeeds, then the session is displayed to the 394 user. If it has no key that matches the announcement key-id, or does 395 not succeed with any key that does match, then the session is ignored. 396 If one of more keys did match the key-id, but decryption failed with all 397 of these matching keys, then the version hash, original source and key- 398 id are cached to avoid having to attempt to decrypt this announcement 399 every time it is received in future. To avoid possible denial of ser- 400 vice attacks, such incoming announcements should occasionally be 401 attempted to be decrypted on a random basis as available processing 402 power allows. This cache can be safely timed out when the timeout 403 specified in encrypted packets expires. 405 Note that if an encrypted announcement is being announced via a proxy, 406 then there may be no way for the proxy to discover that the announcement 407 has been superseded, and so it may continue to relay the old announce- 408 ment in addition to the new announcement. SAP provides no mechanism to 409 chain modified encrypted announcements, so it is advisable to announce 410 the unmodified session as deleted for a short time after the modifica- 411 tion has occurred. This does not guarantee that all proxies have 412 deleted the session, and so receivers of encrypted sessions should be 413 prepared to discard old versions of session announcements that they may 414 receive (as identified by the SDP version field). In most cases how- 415 ever, the only stateful proxy will be local to (and known to) the 416 sender, and an additional (local-area) protocol involving a handshake 417 for such session modifications can be used to avoid this problem. 419 6. SDP announcement by periodic multicast. 421 SAP announces multicast sessions by periodic multicast of session 422 descriptions to an appropriate well known multicast address and port. 423 The appropriate address is determined by the scope mechanisms in force 424 at the sites of the intended participants. IP multicast sessions can be 425 either TTL-scoped or administratively scoped. One well-known address 426 and port is used for all TTL-scoped announcements, and additionally, one 427 well-known address (within the corresponding scope zone) and port is 428 used for each administrative scope zone that an instance of the session 429 directory is within. Thus an instance of the session directory should 430 listen on multiple multicast addresses, but should normally only send a 431 particular announcement to the single multicast address corresponding to 432 the scope of the session being described. The discovery of administra- 433 tive scope zones and the appropriate announcement address for each zone 434 are outside the scope of this draft, but it is assumed that each 435 instance of the session directory within a particular scope zone is 436 aware of that scope zone, and of the corresponding announcement address, 437 port, TTL, and session address allocation range. 439 TTL Scoped Announcement 441 The well-known address is 224.2.127.254 and the UDP port is 9875. The 442 session announcements should be multicast with the same TTL with which 443 the conference session will be multicast. If the different media in an 444 announcement are given different TTLs, then multiple announcements are 445 necessary to ensure that anyone joining the conference can in fact 446 receive data for each media started. For example, if we have an 447 announcement to make containing audio at TTL 127 and video at TTL 63, 448 then we make an announcement at TTL 63 containing both media, and a 449 separate announcement at TTL 127 containing only the audio. It is up to 450 the receiving session directory to parse both announcements as the same 451 announcement (as identified by the SDP origin field) if it is within the 452 appropriate scope to get both announcements. If multiple announcements 453 are being made for the same session in this way, then each announcement 454 must carry an authentication header signed by the same key, or be 455 treated as a completely separate announcement. 457 The time period between one announcement and its repetition is dependent 458 on two factors - the scope (TTL) of the session, and the number of other 459 sessions currently being announced by other session directory instances. 461 The recommended bandwidth limits for each TTL are: 463 TTL bandwidth 464 1-15 2Kbps 465 16-63 1Kbps 466 64-127 1Kbps 467 128-255 200bps 469 Session announcers in the same scope band can normally be expected to 470 hear your announcements, and reduce their data rates accordingly. Thus 471 you should calculate the available bandwidth for your session's scope 472 band by dividing the appropriate limit above by the number of other 473 announcers in your scope band. This gives you your bandwidth alloca- 474 tion, which, given the size of your data packets, can be used to derive 475 the base interval for announcements. 477 I.e., given a limit in bits/second (as above) and a ad_size in bytes, 478 the base announcement interval in seconds is: 480 interval =MAX(300, (8*no_of_ads*ad_size)/limit) 482 For every interval between announcement packets (i.e, every time you 483 send a packet), you must add a random value (+/- 1/3 of the base inter- 484 val) to the value used for the inter-announcement period to prevent 485 announcement synchronisation. It is also important to keep monitoring 486 other announcements and adjust the base interval accordingly. 488 There is possibility to adjust the scope band limits depending on pro- 489 perties of the sessions being announced, but this is left for future SAP 490 drafts to specify. 492 Administrative Scoped Announcements 494 For each administrative scope zone in force at a particular site, 495 instances of the session directory running at that site need to know the 496 following information: 498 + The multicast address to be used for announcement. The is normally 499 the highest multicast address in the relevant administrative scope 500 zone. For example, if the scope range is 239.16.32.0 - 501 239.16.33.255, then the convention is that 239.16.33.255 is used for 502 session announcements. 504 + The UDP port to which announcements should be sent. 506 + The TTL announcements should be made with. This should be large 507 enough to reach all sites in the admin scope zone, and will also be 508 the TTL used for sessions announced to be using this scope zone. 510 + The address range to be used for sessions in this scope zone. This 511 should be a contiguous range, and currently should lie within the 512 range 239.0.0.0 to 239.255.255.255 (but this is defined by IANA, not 513 by this draft). 515 + The total bandwidth to be used by the session directory for session 516 announcements in this admin scope zone. A recommended default value 517 for this is 500bps, but this may be inappropriate for some uses. 519 7. Security Considerations 521 SAP contains mechanisms for ensuring integrity of session announcements, 522 for authenticating the origin of an announcement and for encrypting such 523 announcements. These mechanisms have not yet been subject to suitable 524 peer-review, and this document should not be considered authoritative in 525 this area at this time. 527 SAP contains mechanisms that are designed to prevent an announcement by 528 one user from being modified or deleted by another user, and also to 529 provide limited privacy by use of encryption. 531 Session announcements that are encrypted with a symmetric algorithm may 532 allow a degree of privacy in the announcement of a session, but it 533 should be recognised that a user in possession of such a key can pass it 534 on to other users who should not be in possession of such a key. Thus 535 announcements to such a group of key holders cannot be assumed to have 536 come from an authorised key holder unless there is an appropriate 537 authentication header signed by an authorised key holder. In addition 538 the recipients of such encrypted announcements cannot be assumed to only 539 be authorised key holders. Such encrypted announcements do not provide 540 any real security unless all of the authorised key holders are trusted 541 to maintain security of such session directory keys. This property is 542 shared by the multicast session tools themselves, where it is possible 543 for an un-trustworthy member of the session to pass on encryption keys 544 to un-authorised users. However it is likely that keys used for the 545 session tools will be more short lived that those used for session 546 directories. 548 Similar considerations should apply when session announcements are 549 encrypted with an assymetric algorithm, but then it is possible to res- 550 trict the possessor(s) of the private key, so that announcements to a 551 key-holder group can not be made, even if one of the untrusted members 552 of the group proves to be un-trustworthy. 554 As stated above, if a session modification announcement is received that 555 contains a valid authentication header, but which is not signed by the 556 original creator of the session, then the session must be treated as a 557 new session in addition to the original session with the same SDP origin 558 information unless the originator of one of the session descriptions can 559 be authenticated using a certificate signed by a trusted third party. 560 If this were not done, there would be a possible denial of service 561 attack whereby a party listens for new announcements, strips off the 562 original authentication header, modifies the session description, adds a 563 new authentication header and re-announces the session. If a rule was 564 imposed that such spoof announcements were ignored, then if packet loss 565 or late starting of a session directory instance caused the original 566 announcement to fail to arrive at a site, but the spoof announcement did 567 so, this would then prevent the original announcement from being 568 accepted at that site. 570 A similar denial-of-service attack is possible if a session announcement 571 receiver relies completely on the originating source and hash fields to 572 indicate change, and fails to parse the remainder of announcements for 573 which it has seen the origin/hash combination before. 575 A denial of service attack is possible from a malicious site close to a 576 legitimate site which is making a session announcement. This can happen 577 if the malicious site floods the legitimate site with huge numbers of 578 (illegal) low TTL announcements describing high TTL sessions. This may 579 reduce the session announcement rate of the legitimate announcement to 580 below a tenth of the rate expected at remote sites and therefore cause 581 the session to time out. Such an attack is likely to be easily detect- 582 able, and we do not provide any mechanism here to prevent it. 584 Appendix A: Summary of differences between SAPv0 and SAPv1 586 For this purpose SAPv0 is defined as the protocol in use by version 2.2 587 of the Sdr session description tool. SAPv1 is the proposed protocol 588 described in the document. The packet headers of SAP messages are the 589 same in V0 and V1 in that a V1 tool can parse a V0 announcement header 590 but not vice-versa. 592 In SAPv0, the fields have the following values: 594 + Version Number: 0 596 + Message Type: 0 (Announcement) 598 + Authentication Type: 0 (No Authentication) 600 + Encryption Bit: 0 (No Encryption) 601 + Compression Bit: 0 (No compression) 603 + Message Id Hash: 0 (No Hash Specified) 605 + Originating Source: 0 (No source specified, announcement has not 606 been relayed) 608 Appendix B: Author's Address 610 Mark Handley 611 Information Sciences Institute, 612 University of Southern California, 613 c/o MIT Laboratory for Computer Science, 614 545 Technology Square, 615 Cambridge, MA 02139, 616 United States 617 electronic mail: mjh@isi.edu 619 Acknowledgments 621 SAP and SDP were originally based on the protocol used by the sd session 622 directory from Van Jacobson at LBNL. The design of SAP was funded by 623 the European Commission under the Esprit 7602 "MICE" project, and the 624 Telematics 1007 "MERCI" project. 626 References 628 [1] M.Handley, V. Jacobson, ``SDP: Session Description Protocol'', 629 INTERNET-DRAFT, Nov 1996. 631 [2] D. Mills, ``Network Time Protocol version 2 specification and imple- 632 mentation", RFC1119, 1st Sept 1989. 634 [3] P. Deutsch, ``GZIP file format specification version 4.3'', RFC 635 1952, May 1996. 637 [4] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with 638 Minimal Control'', RFC 1890, January 1996