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