idnits 2.17.1 draft-ietf-mmusic-sap-v2-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 7) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 43 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 3 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 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 497 has weird spacing: '... Format speci...' == Line 727 has weird spacing: '...Handley and V...' == Line 731 has weird spacing: '...ncement proto...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (13 December 1999) is 8900 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) ** Obsolete normative reference: RFC 2440 (ref. '2') (Obsoleted by RFC 4880) ** Downref: Normative reference to an Informational RFC: RFC 1950 (ref. '3') ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1305 (ref. '8') (Obsoleted by RFC 5905) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 13 December 1999 3 Mark Handley 4 ACIRI 5 Colin Perkins 6 UCL 7 Edmund Whelan 8 UCL 10 Session Announcement Protocol 11 draft-ietf-mmusic-sap-v2-04.txt 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months and 23 may be updated, replaced, or obsoleted by other documents at any time. It 24 is inappropriate to use Internet-Drafts as reference material or to cite 25 them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a product of the Multiparty Multimedia Session Control 34 working group of the Internet Engineering Task Force. Comments are 35 solicited and should be addressed to the working group's mailing list at 36 confctrl@isi.edu and/or the authors. 38 Abstract 40 This document describes version 2 of the multicast session directory 41 announcement protocol, SAP, and the related issues affecting security 42 and scalability that should be taken into account by the implementors 43 of multicast session directory tools. 45 1 Introduction 47 In order to assist the advertisement of multicast multimedia conferences 48 and other multicast sessions, and to communicate the relevant session 49 setup information to prospective participants, a distributed session 50 directory may be used. An instance of such a session directory periodically 51 multicasts packets containing a description of the session, and these 52 advertisements are received by potential participants who can use the 53 session description to start the tools required to participate in the 54 session. 56 This memo describes the issues involved in the multicast announcement of 57 session description information and defines an announcement protocol to be 58 used by session directory clients. Sessions are described using the 59 session description protocol which is described in a companion memo [4]. 61 2 Terminology 63 A SAP announcer periodically multicasts an announcement packet to 64 a well known multicast address and port. The announcement is multicast 65 with the same scope as the session it is announcing, ensuring that 66 the recipients of the announcement can also be potential recipients 67 of the session the announcement describes (bandwidth and other such 68 constraints permitting). This is also important for the scalability 69 of the protocol, as it keeps local session announcements local. 71 A SAP listener learns of the multicast scopes it is within (for example, 72 using the Multicast-Scope Zone Announcement Protocol [5]) and listens on 73 the well known SAP address and port for those scopes. In this manner, it 74 will eventually learn of all the sessions being announced, allowing those 75 sessions to be joined. 77 The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', 78 `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this 79 document are to be interpreted as described in [1]. 81 3 Session Announcement 83 As noted previously, a SAP announcer periodically sends an announcement 84 packet to a well known multicast address and port. There is no rendezvous 85 mechanism - the SAP announcer is not aware of the presence or absence of 86 any SAP listeners - and no additional reliability is provided over the 87 standard best-effort UDP/IP semantics. 89 That announcement contains a session description and SHOULD contain 90 an authentication header. The session description MAY be encrypted 91 although this is NOT RECOMMENDED (see section 7). 93 A SAP announcement is multicast with the same scope as the session 94 it is announcing, ensuring that the recipients of the announcement 95 can also be potential recipients of the session being advertised. 96 There a number of possiblities: 98 IPv4 global scope sessions use multicast addresses in the range 99 224.2.128.0 - 224.2.255.255 with SAP announcements being sent 100 to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete 101 SAPv0 and MUST NOT be used). 103 IPv4 administrative scope sessions using administratively scoped 104 IP multicast as defined in [7]. The multicast address to be 105 used for announcements is the highest multicast address in the 106 relevant administrative scope zone. For example, if the scope 107 range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used 108 for SAP announcements. 110 IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE 111 where X is the 4-bit scope value. For example, an announcement for 112 a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, 113 should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE. 115 SAP announcements MUST be sent on port 9875 and SHOULD be sent with 116 an IP time-to-live of 255. 118 If a session uses addresses in multiple administrative scope ranges, 119 it is necessary for the announcer to send identical copies of the 120 announcement to each administrative scope range. It is up to the 121 listeners to parse such multiple announcements as the same session 122 (as identified by the SDP origin field, for example). The announcement 123 rate for each administrative scope range MUST be calculated separately, 124 as if the multiple announcements were separate. 126 Multiple announcers may announce a single session, as an aid to robustness 127 in the face of packet loss and failure of one or more announcers. The rate 128 at which each announcer repeats its announcement MUST be scaled back such 129 that the total announcement rate is equal to that which a single server 130 would choose. Announcements made in this manner MUST be identical. 132 If multiple announcements are being made for a session, then each 133 announcement MUST carry an authentication header signed by the same 134 key, or be treated as a completely separate announcement by listeners. 136 An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address 137 and on the SAP addresses for each IPv4 administrative scope zone 138 it is within. The discovery of administrative scope zones is outside 139 the scope of this memo, but it is assumed that each SAP listener 140 within a particular scope zone is aware of that scope zone. A SAP 141 listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses. 143 3.1 Announcement Interval 145 The time period between repetitions of an announcement is chosen 146 such that the total bandwidth used by all announcements on a single 147 SAP group remains below a preconfigured limit. If not otherwise 148 specified, the bandwidth limit SHOULD be assumed to be 4000 bits 149 per second. 151 Each announcer is expected to listen to other announcements in order to 152 determine the total number of sessions being announced on a particular 153 group. Sessions are uniquely identified by the combination of the message 154 identifier hash and originating source fields of the SAP header (note that 155 SAP v0 clients always set the message identifier hash to zero, and if such 156 an announcement is received the entire message MUST be compared to 157 determine uniqueness). 159 Announcements are made by periodic multicast to the group. The base 160 interval between announcements is derived from the number of announcements 161 being made in that group, the size of the announcement and the configured 162 bandwidth limit. The actual transmission time is derived from this base 163 interval as follows: 165 1. The announcer initialises the variable tp to be the last time 166 a particular announcement was transmitted (or the current time 167 if this is the first time this announcement is to be made). 169 2. Given a configured bandwidth limit in bits/second and an announcement 170 of ad_size bytes, the base announcement interval in seconds is 172 interval = max(300; (8*no_of_ads*ad_size)/limit) 174 3. An offset is calculated based on the base announcement interval 176 offset= rand(interval* 2/3)-(interval/3) 178 4. The next transmission time for an announcement derived as 180 tn =tp+ interval+ offset 182 The announcer then sets a timer to expire at tn and waits. At time 183 tn the announcer SHOULD recalculate the next transmission time. If 184 the new value of tn is before the current time, the announcement 185 is sent immediately. Otherwise the transmission is rescheduled for 186 the new tn. This reconsideration prevents transient packet bursts 187 on startup and when a network partition heals. 189 4 Session Deletion 191 Sessions may be deleted in one of several ways: 193 Explicit Timeout The session description payload contains timestamp 194 information which specifies a start and end time for the session. 195 If the current time is later than the end-time for the session, 196 then the session is deleted from the receiver's session cache. 197 If an announcement packet arrives with an end-time before the 198 current time, it is ignored. If the payload is encrypted, and 199 the receiver does not have the correct decryption key, the timeout 200 field in the header should be used as an explicit timeout. 202 Implicit Timeout A session announcement message should be received 203 periodically for each session description in a receiver's session 204 cache. The announcement period can be predicted by the receiver 205 from the set of sessions currently being announced. If a session 206 announcement message has not been received for ten times the 207 announcement period, or one hour, whichever is the greater, then 208 the session is deleted from the receiver's session cache. The 209 one hour minimum is to allow for transient network partitionings. 211 Explicit Deletion A session deletion packet is received specifying 212 the version of the session to be deleted. The deletion packets 213 should be ignored, unless they contain an authentication header 214 which authenticates correctly and matches that used to authenticate 215 the announcement which is being deleted. 217 5 Session Modification 219 A pre-announced session can be modified by simply announcing the modified 220 session description. In this case, the version hash in the SAP header MUST 221 be changed to indicate to receivers that the packet contents should be 222 parsed (or decrypted and parsed if it is encrypted). The session itself, 223 as distinct from the session announcement, is uniquely identified by the 224 payload and not by the message identifier hash in the header. 226 The same rules apply for session modification as for session deletion: 228 o Either the modified announcement must contain an authentication 229 header signed by the same key as the cached session announcement 230 it is modifying, or: 232 o The cached session announcement must not contain an authentication 233 header, and the session modification announcement must originate 234 from the same host as the session it is modifying. 236 If an announcement is received containing an authentication header 237 and the cached announcement did not contain an authentication header, 238 or it contained a different authentication header, then the modified 239 announcement MUST be treated as a new and different announcement, 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | V=1 |A|R|T|E|C| auth len | msg id hash | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 : originating source (32 or 128 bits) : 247 : : 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | optional authentication data | 250 : .... : 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | optional timeout | 253 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 254 | optional payload type | 255 + +-+- - - - - - - - - -+ 256 | |0| | 257 + - - - - - - - - - - - - - - - - - - - - +-+ | 258 | | 259 : payload : 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 1: Packet format 265 and displayed in addition to the un-authenticated announcement. The 266 same should happen if a modified packet without an authentication 267 header is received from a different source than the original announcement. 268 These rules prevent an announcement having an authentication header 269 added by a malicious user and then being deleted using that header, 270 and it also prevents a denial-of-service attack by someone putting 271 out a spoof announcement which, due to packet loss, reaches some 272 participants before the original announcement. Note that under such 273 circumstances, being able to authenticate the message originator is 274 the only way to discover which session is the correct session. 276 6 Packet Format 278 SAP data packets have the format described in figure 1. 280 V: Version Number. The version number field MUST be set to 1 (SAPv2 281 announcements which use only SAPv1 features are backwards compatible, 282 those which use new features can be detected by other means, 283 so the SAP version number doesn't need to change). 285 A: Address type. If the A bit is 0, the originating source field 286 contains a 32-bit IPv4 address. If the A bit is 1, the originating 287 source contains a 128-bit IPv6 address. 289 R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST 290 ignore the contents of this field. 292 T: Message Type. If the T field is set to 0 this is a session announcement 293 packet, if 1 this is a session deletion packet. 295 E: Encryption Bit. If the encryption bit is set to 1, the payload 296 of the SAP packet is encrypted and the timeout field MUST be 297 added to the packet header. If this bit is 0 the packet is 298 not encrypted and the timeout MUST NOT be present. See section 299 7 for details of the encryption process. 301 C: Compressed bit. If the compressed bit is set to 1, the payload 302 is compressed using the zlib compression algorithm [3]. If the 303 payload is to be compressed and encrypted, the compression MUST 304 be performed first. 306 Authentication Length. An 8 bit unsigned quantity giving the number 307 of 32 bit words following the main SAP header that contain 308 authentication data. If it is zero, no authentication header is 309 present. 311 Authentication data containing a digital signature of the packet, 312 with length as specified by the authentication length header 313 field. See section 8 for details of the authentication process. 315 Message Identifier Hash. A 16 bit quantity that, used in combination 316 with the originating source, provides a globally unique identifier 317 indicating the precise version of this announcement. The choice 318 of value for this field is not specified here, except that it 319 MUST be unique for each session announced by a particular SAP 320 announcer and it MUST be changed if the session description is 321 modified. 323 Earlier versions of SAP used a value of zero to mean that the 324 hash should be ignored and the payload should always be parsed. 325 This had the unfortunate side-effect that SAP announcers had 326 to study the payload data to determine how many unique sessions 327 were being advertised, making the calculation of the announcement 328 interval more complex that necessary. In order to decouple the 329 session announcement process from the contents of those announcements, 330 SAP announcers SHOULD NOT set the message identifier hash to zero. 332 SAP listeners MAY silently discard messages if the message identifier 333 hash is set to zero. 335 Originating Source. This gives the IP address of the original source 336 of the message. This is an IPv4 address if the A field is set 337 to zero, else it is an IPv6 address. The address is stored 338 in network byte order. 340 SAPv0 permitted the originating source to be zero if the message 341 identifier hash was also zero. This practise is no longer legal, 342 and SAP announcers SHOULD NOT set the originating source to zero. 344 SAP listeners MAY silently discard packets with the originating 345 source set to zero. 347 Timeout. When the session payload is encrypted the detailed timing 348 fields in the payload are not available to listeners which are 349 not trusted with the decryption key. Under such circumstances, 350 the header includes an additional 32-bit timestamp field stating 351 when the session should be timed out. 353 Note that the timeout field in the header is intended for use 354 only by those listeners which do not have the correct key to 355 decrypt the announcement. A SAP listener which is capable of 356 decrypting the announcement MUST determine when to timeout the 357 session based on the payload information. 359 The value is an unsigned quantity giving the NTP time [8] in 360 seconds at which time the session is timed out. It is in network 361 byte order. 363 The header is followed by an optional payload type field and the 364 payload data itself. If the E or C bits are set in the header both 365 the payload type and payload are encrypted and/or compressed. 366 The payload type field is a MIME content type specifier, describing 367 the format of the payload. This is a variable length ASCII text 368 string, followed by a single zero byte (ASCII NUL). The payload type 369 SHOULD be included in all packets. If the payload type is `application/sdp' 370 both the payload type and its terminating zero byte MAY be omitted, 371 although this is intended for backwards compatibility with SAP v1 372 listeners only. 374 The absence of a payload type field may be noted since the payload 375 section of such a packet will start with an SDP `v=0' field, which 376 is not a legal MIME content type specifier. 378 All implementations MUST support payloads of type `application/sdp' [4]. 379 Other formats MAY be supported although since there is no negotiation in 380 SAP an announcer which chooses to use a session description format other 381 than SDP cannot know that the listeners are able to understand the 382 announcement. A proliferation of payload types in announcements has the 383 potential to lead to severe interoperability problems, and for this reason, 384 the use of non-SDP payloads is NOT RECOMMENDED. If the packet is an 385 announcement packet, the payload contains a session description. 387 If the packet is a session deletion packet, the payload contains a session 388 deletion message. If the payload format is `application/sdp' the deletion 389 message is a single SDP line consisting of the origin field of the 390 announcement to be deleted. 392 It is desirable for the payload to be sufficiently small that SAP 393 packets do not get fragmented by the underlying network. Fragmentation 394 has a loss multiplier effect, which is known to significantly affect the 395 reliability of announcements. It is RECOMMENDED that SAP packets are 396 smaller than 1kByte in length, although if it is known that announcements 397 will use a network with a smaller MTU than this, then that SHOULD be used 398 as the maximum recommended packet size. 400 7 Encrypted Announcements 402 An announcement is received by all listeners in the scope to which 403 it is sent. If an announcement is encrypted, and many of the receivers 404 do not have the encryption key, there is a considerable waste of 405 bandwidth since those receivers cannot use the announcement they have 406 received. For this reason, the use of encrypted SAP announcements 407 is NOT RECOMMENDED on the global scope SAP group or on administrative 408 scope groups which may have many receivers which cannot decrypt those 409 announcements. 411 The opinion of the authors is that encrypted SAP is useful in special 412 cases only, and that the vast majority of scenarios where encrypted 413 SAP has been proposed may be better served by distributing session 414 details using another mechanism. There are, however, certain scenarios 415 where encrypted announcements may be useful. For this reason, the 416 encryption bit is included in the SAP header to allow experimentation 417 with encrypted announcements. 419 This memo does not specify details of the encryption algorithm to 420 be used or the means by which keys are generated and distributed. 421 An additional specification should define these, if it is desired 422 to use encrypted SAP. 424 Note that if an encrypted announcement is being announced via a proxy, 425 then there may be no way for the proxy to discover that the announcement 426 has been superseded, and so it may continue to relay the old announcement 427 in addition to the new announcement. SAP provides no mechanism to 428 chain modified encrypted announcements, so it is advisable to announce 429 the unmodified session as deleted for a short time after the modification 430 has occurred. This does not guarantee that all proxies have deleted 431 the session, and so receivers of encrypted sessions should be prepared 432 to discard old versions of session announcements that they may receive. 433 In most cases however, the only stateful proxy will be local to (and 434 known to) the sender, and an additional (local-area) protocol involving 435 a handshake for such session modifications can be used to avoid this 436 problem. 438 Session announcements that are encrypted with a symmetric algorithm 439 may allow a degree of privacy in the announcement of a session, but 440 it should be recognised that a user in possession of such a key can 441 pass it on to other users who should not be in possession of such 442 a key. Thus announcements to such a group of key holders cannot 443 be assumed to have come from an authorised key holder unless there 444 is an appropriate authentication header signed by an authorised key 445 holder. In addition the recipients of such encrypted announcements 446 cannot be assumed to only be authorised key holders. Such encrypted 447 announcements do not provide any real security unless all of the 448 authorised key holders are trusted to maintain security of such session 449 directory keys. This property is shared by the multicast session 450 tools themselves, where it is possible for an un-trustworthy member 451 of the session to pass on encryption keys to un-authorised users. 452 However it is likely that keys used for the session tools will be 453 more short lived than those used for session directories. 455 Similar considerations should apply when session announcements are 456 encrypted with an assymetric algorithm, but then it is possible to 457 restrict the possessor(s) of the private key, so that announcements 458 to a key-holder group can not be made, even if one of the untrusted 459 members of the group proves to be un-trustworthy. 461 8 Authenticated Announcements 463 The authentication header can be used for two purposes: 465 o Verification that changes to a session description or deletion 466 of a session are permitted. 468 o Authentication of the identity of the session creator. 470 In some circumstances only verification is possible because a certificate 471 signed by a mutually trusted person or authority is not available. 472 However, under such circumstances, the session originator may still 473 be authenticated to be the same as the session originator of previous 474 sessions claiming to be from the same person. This may or may not 475 be sufficient depending on the purpose of the session and the people 476 involved. 478 Clearly the key used for the authentication should not be trusted 479 to belong to the session originator unless it has been separately 480 authenticated by some other means, such as being certified by a trusted 481 third party. Such certificates are not normally included in an SAP 482 header because they take more space than can normally be afforded 483 in an SAP packet, and such verification must therefore take place 484 by some other mechanism. However, as certified public keys are normally 485 locally cached, authentication of a particular key only has to take 486 place once, rather than every time the session directory retransmits 487 the announcement. 489 SAP is not tied to any single authentication mechanism. Authentication 490 data in the header is self-describing, but the precise format depends 491 on the authentication mechanism in use. The generic format of the 492 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | V=1 |P| Auth | | 496 +-+-+-+-+-+-+-+-+ | 497 | Format specific authentication subheader | 498 : .................. : 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 2: Format of the authentication data in the SAP header 503 authentication data is given in figure 2. The structure of the format 504 specific authentication subheader, using both the PGP and the CMS 505 formats, is discussed in sections 8.1 and 8.2 respectively. 507 Version Number, V: The version number of the authentication format 508 specified by this memo is 1. 510 Padding Bit, P: If necessary the authentication data is padded 511 to be a multiple of 32 bits and the padding bit is set. In 512 this case the last byte of the authentication data contains the 513 number of padding bytes (including the last byte) that must be 514 discarded. 516 Authentication Type, Auth: The authentication type is a 4 bit encoded 517 field that denotes the authentication infrastructure the sender 518 expects the recipients to use to check the authenticity and integrity 519 of the information. This defines the format of the authentication 520 subheader and can take the values: 0 = PGP format, 1 = CMS 521 format. All other values are undefined and SHOULD be ignored. 523 If a SAP packet is to be compressed or encrypted, this MUST be done 524 before the authentication is added. 526 The digital signature in the authentication data MUST be calculated 527 over the entire packet, including the header. The authentication 528 length MUST be set to zero and the authentication data excluded when 529 calculating the digitial signature. 531 8.1 PGP Authentication 533 Implementations which support authentication MUST support this format. 535 A full description of the PGP protocol can be found in [2]. When 536 using PGP for SAP authentication the basic format specific authentication 537 subheader comprises a digital signature packet as described in [2]. 538 The signature type MUST be 0x01 which means the signature is that 539 of a canonical text document. 541 8.2 CMS Authentication 543 Support for this format is OPTIONAL. 545 A full description of the Cryptographic Message Syntax can be found 546 in [6]. The format specific authentication subheader will, in the 547 CMS case, have an ASN.1 ContentInfo type with the ContentType being 548 signedData. 550 Use is made of the option available in PKCS#7 to leave the content 551 itself blank as the content which is signed is already present in 552 the packet. Inclusion of it within the SignedData type would duplicate 553 this data and increase the packet length unnecessarily. In addition 554 this allows recipients with either no interest in the authentication, 555 or with no mechanism for checking it, to more easily skip the 556 authentication information. 558 There SHOULD be only one signerInfo and related fields corresponding 559 to the originator of the SAP announcement. The signingTime SHOUD 560 be present as a signedAttribute. However, due to the strict size 561 limitations on the size of SAP packets, certificates and CRLs SHOULD 562 NOT be included in the signedData structure. It is expected that 563 users of the protocol will have other methods for certificate and 564 CRL distribution. 566 9 Scalability and caching 568 SAP is intended to announce the existence of long-lived wide-area 569 multicast sessions. It is not an especially timely protocol: sessions 570 are announced by periodic multicast with a repeat rate on the order 571 of tens of minutes, and no enhanced reliability over UDP. This leads 572 to a long startup delay before a complete set of announcements is 573 heard by a listener. This delay is clearly undesirable for interactive 574 browsing of announced sessions. 576 In order to reduce the delays inherent in SAP, it is recommended 577 that proxy caches are deployed. A SAP proxy cache is expected to 578 listen to all SAP groups in its scope, and to maintain an up-to-date 579 list of all announced sessions along with the time each announcement 580 was last received. When a new SAP listeners starts, it should contact 581 its local proxy to download this information, which is then sufficient 582 for it to process future announcements directly, as if it has been 583 continually listening. 585 The protocol by which a SAP listener contacts its local proxy cache 586 is not specified here. 588 10 Security Considerations 590 SAP contains mechanisms for ensuring integrity of session announcements, 591 for authenticating the origin of an announcement and for encrypting 592 such announcements (sections 7 and 8). These mechanisms have not 593 yet been subject to suitable peer-review, and this memo should not 594 be considered authoritative in this area at this time. 596 As stated in section 5, if a session modification announcement is 597 received that contains a valid authentication header, but which is 598 not signed by the original creator of the session, then the session 599 must be treated as a new session in addition to the original session 600 with the same SDP origin information unless the originator of one 601 of the session descriptions can be authenticated using a certificate 602 signed by a trusted third party. If this were not done, there would 603 be a possible denial of service attack whereby a party listens for 604 new announcements, strips off the original authentication header, 605 modifies the session description, adds a new authentication header 606 and re-announces the session. If a rule was imposed that such spoof 607 announcements were ignored, then if packet loss or late starting 608 of a session directory instance caused the original announcement to 609 fail to arrive at a site, but the spoof announcement did so, this 610 would then prevent the original announcement from being accepted at 611 that site. 613 A similar denial-of-service attack is possible if a session announcement 614 receiver relies completely on the originating source and hash fields 615 to indicate change, and fails to parse the remainder of announcements 616 for which it has seen the origin/hash combination before. 617 A denial of service attack is possible from a malicious site close 618 to a legitimate site which is making a session announcement. This 619 can happen if the malicious site floods the legitimate site with 620 huge numbers of (illegal) low TTL announcements describing high TTL 621 sessions. This may reduce the session announcement rate of the legitimate 622 announcement to below a tenth of the rate expected at remote sites 623 and therefore cause the session to time out. Such an attack is likely 624 to be easily detectable, and we do not provide any mechanism here 625 to prevent it. 627 A Summary of differences between SAPv0 and SAPv1 629 For this purpose SAPv0 is defined as the protocol in use by version 630 2.2 of the session directory tool, sdr. SAPv1 is the protocol described 631 in the 19 November 1996 version of this memo (draft-ietf-mmusic-sap-00.txt). 632 The packet headers of SAP messages are the same in V0 and V1 in 633 that a V1 tool can parse a V0 announcement header but not vice-versa. 634 In SAPv0, the fields have the following values: 636 o Version Number: 0 638 o Message Type: 0 (Announcement) 640 o Authentication Type: 0 (No Authentication) 642 o Encryption Bit: 0 (No Encryption) 644 o Compression Bit: 0 (No compression) 646 o Message Id Hash: 0 (No Hash Specified) 648 o Originating Source: 0 (No source specified, announcement has 649 not been relayed) 651 B Summary of differences between SAPv1 and SAPv2 653 The packet headers of SAP messages are the same in V1 and V2 in 654 that a V2 tool can parse a V1 announcement header but not necessarily 655 vice-versa. 657 o The A bit has been added to the SAP header, replacing one of 658 the bits of the SAPv1 message type field. If set to zero the 659 announcement is of an IPv4 session, and the packet is backwards 660 compatible with SAPv1. If set to one the announcement is of 661 an IPv6 session, and SAPv1 clients (which do not support IPv6) 662 will see this as an illegal message type (MT) field. 664 o The second bit of the message type field in SAPv1 has been replaced 665 by a reserved, must-be-zero, bit. This bit was unused in SAPv1, 666 so this change just codifies existing usage. 668 o SAPv1 specified encryption of the payload. SAPv2 includes the 669 E bit in the SAP header to indicate that the payload is encrypted, 670 but does not specify any details of the encryption. 672 o SAPv1 allowed the message identifier hash and originating source 673 fields to be set to zero, for backwards compatibility. This 674 is no longer legal. 676 o SAPv1 specified gzip compression. SAPv2 uses zlib (the only 677 known implementation of SAP compression used zlib, and gzip 678 compression was a mistake). 680 o SAPv2 provides a more complete specification for authentication. 682 o SAPv2 allows for non-SDP payloads to be transported. SAPv1 required 683 that the payload was SDP. 685 C Acknowledgments 687 SAP and SDP were originally based on the protocol used by the sd 688 session directory from Van Jacobson at LBNL. Version 1 of SAP was 689 designed by Mark Handley as part of the European Commission MICE 690 (Esprit 7602) and MERCI (Telematics 1007) projects. Version 2 includes 691 authentication features developed by Edmund Whelan, Goli Montasser-Kohsari 692 and Peter Kirstein as part of the European Commission ICE-TEL project 693 (Telematics 1005), and support for IPv6 developed by Maryann P. Maher 694 and Colin Perkins. 696 D Authors' Addresses 698 Mark Handley 699 AT&T Center for Internet Research at ICSI, 700 International Computer Science Institute, 701 1947 Center Street, Suite 600, 702 Berkeley, CA 94704, USA 704 Colin Perkins 705 Department of Computer Science, 706 University College London, 707 Gower Street, 708 London, WC1E 6BT, UK 710 Edmund Whelan 711 Department of Computer Science, 712 University College London, 713 Gower Street, 714 London, WC1E 6BT, UK 716 References 718 [1] S. Bradner. Key words for use in RFCs to indicate requirement levels, 719 March 1997. RFC2119. 721 [2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message 722 format, November 1998. RFC2440. 724 [3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification 725 version 3.3, May 1996. RFC1950. 727 [4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April 728 1998. RFC2327. 730 [5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone 731 announcement protocol (MZAP), February 1999. Work in progress. 733 [6] R. Housley. Cryptographic message syntax. Work in progress, 734 April 1999. draft-ietf-smime-cms-13.txt. 736 [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. 738 [8] D. Mills. Network time protocol version 3, March 1992. RFC1305.