idnits 2.17.1 draft-ietf-mmusic-sap-v2-01.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 8) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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 58 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 == 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 114 has weird spacing: '...d on an addre...' == Line 493 has weird spacing: '... Format speci...' == Line 538 has weird spacing: '...ing bit is...' == Line 760 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.) -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1305 (ref. '8') (Obsoleted by RFC 5905) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 3 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-01.txt 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months and 21 may be updated, replaced, or obsoleted by other documents at any time. It 22 is inappropriate to use Internet-Drafts as reference material or to cite 23 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 directory 39 announcement protocol, SAP, and the related issues affecting security 40 and scalability that should be taken into account by the implementors 41 of multicast session directory tools. 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 potential participants who can use 51 the session description to start the tools required to participate 52 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 by session directory clients. Sessions are described 57 using the session description protocol which is described in a companion 58 memo [4]. 60 2 Terminology 62 A SAP announcer periodically multicasts an announcement packet to 63 a well known multicast address and port. The announcement is multicast 64 with the same scope as the session it is announcing, ensuring that 65 the recipients of the announcement can also be potential recipients 66 of the session the announcement describes (bandwidth and other such 67 constraints permitting). This is also important for the scalability 68 of the protocol, as it keeps local session announcements local. 70 A SAP listener learns of the multicast scopes it is within (for example, 71 using the Multicast-Scope Zone Announcement Protocol [5]) and listens 72 on the well known SAP address and port for those scopes. In this 73 manner, it will eventually learn of all the sessions being announced, 74 allowing those sessions to be joined. 76 The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', 77 `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this 78 document are to be interpreted as described in [1]. 80 3 Session Announcement 82 As noted previously, a SAP announcer periodically sends an announcement 83 packet to a well known multicast address and port. There is no rendezvous 84 mechanism - the SAP announcer is not aware of the presence or absence of 85 any SAP listeners - and no additional reliability is provided over the 86 standard best-effort UDP/IP semantics. 88 That announcement contains a session description and SHOULD contain 89 an authentication header. The session description MAY be encrypted 90 although this is NOT RECOMMENDED (see section 8). 92 A SAP announcement is multicast with the same scope as the session 93 it is announcing, ensuring that the recipients of the announcement 94 can also be potential recipients of the session being advertised. 95 There are four possiblities: 97 IPv4 global scope sessions use multicast addresses in the range 98 224.2.128.0 - 224.2.255.255 with SAP announcements being sent 99 to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete 100 SAPv0 and MUST NOT be used). 102 IPv4 administrative scope sessions using administratively scoped 103 IP multicast as defined in [7]. The multicast address to be 104 used for announcements is the highest multicast address in the 105 relevant administrative scope zone. For example, if the scope 106 range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used 107 for SAP announcements. 109 IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE 110 where X is the 4-bit scope value. For example, an announcement 111 for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, 112 should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE. 114 Directory sessions are announced on an address which is itself announced 115 by a SAP announcement. See section 6 for details for directory 116 sessions. 118 SAP announcements MUST be sent on port 9875 and SHOULD be sent with 119 an IP time-to-live of 255. 121 If a session uses addresses in multiple administrative scope ranges, it is 122 necessary for the announcer to send identical copies of the announcement to 123 each administrative scope range. It is up to the listeners to parse such 124 multiple announcements as the same session (as identified by the SDP origin 125 field, for example). The announcement rate for each administrative scope 126 range MUST be calculated separately, as if the multiple announcements were 127 separate. 129 Multiple announcers may announce a single session, as an aid to robustness 130 in the face of packet loss and failure of one or more announcers. The rate 131 at which each announcer repeats its announcement MUST be scaled back such 132 that the total announcement rate is equal to that which a single server 133 would choose. Announcements made in this manner MUST be identical. 135 If multiple announcements are being made for a session, then each 136 announcement MUST carry an authentication header signed by the same 137 key, or be treated as a completely separate announcement by listeners. 139 An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address 140 and on the SAP addresses for each IPv4 administrative scope zone 141 it is within. The discovery of administrative scope zones is outside 142 the scope of this memo, but it is assumed that each SAP listener 143 within a particular scope zone is aware of that scope zone. A SAP 144 listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses. 145 Support for directory sessions is OPTIONAL. 147 The time period between repetitions of an announcement is chosen such that 148 the total bandwidth used by all announcements on a single SAP group remains 149 below a preconfigured limit. If not otherwise specified, the bandwidth 150 limit SHOULD be assumed to be 4000 bits per second. 152 Each announcer is expected to listen to other announcements in order to 153 determine the total number of sessions being announced on a particular 154 group. Sessions are uniquely identified by the combination of the message 155 identifier hash and originating source fields of the SAP header. If these 156 fields are non-zero they form a unique identifier for the announcement, if 157 they are zero then the entire message MUST be compared to determine 158 uniqueness. 160 Thus you should calculate the available bandwidth for your session's scope 161 by dividing the bandwidth limit by the number of other sessions being 162 announced in your scope. This gives you your bandwidth allocation, which, 163 given the size of your data packets, can be used to derive the base 164 interval for announcements. That is, given a limit in bits/second (as 165 above) and a ad_size in bytes, the base announcement interval in seconds is 167 interval = MAX(300; (8* no_of_ads* ad_size)/limit) 169 For every interval between announcement packets (i.e, every time you send a 170 packet), you must add a random value (+/- 1/3 of the base interval) to the 171 value used for the inter-announcement period to prevent announcement 172 synchronisation. It is also important to keep monitoring other 173 announcements and adjust the base interval accordingly. 175 4 Session Deletion 177 Sessions may be deleted in one of several ways: 179 Explicit Timeout The session description payload contains timestamp 180 information which specifies a start and end time for the session. 181 If the current time is later than the end-time for the session, 182 then the session is deleted from the receiver's session cache. 183 If an announcement packet arrives with an end-time before the 184 current time, it is ignored. If the payload is encrypted, and 185 the receiver does not have the correct decryption key, the timeout 186 field in the header should be used as an explicit timeout. 188 Implicit Timeout A session announcement message should be received 189 periodically for each session description in a receiver's session 190 cache. The announcement period can be predicted by the receiver 191 from the set of sessions currently being announced. If a session 192 announcement message has not been received for ten times the 193 announcement period, or one hour, whichever is the greater, then 194 the session is deleted from the receiver's session cache. The 195 one hour minimum is to allow for transient network partitionings. 197 Explicit Deletion A session deletion packet is received specifying 198 the version of the session to be deleted. The deletion packets 199 should be ignored, unless they contain an authentication header 200 which authenticates correctly and matches that used to authenticate 201 the announcement which is being deleted. 203 5 Session Modification 205 A pre-announced session can be modified by simply announcing the modified 206 session description. In this case, the version hash in the SAP header MUST 207 be changed to indicate to receivers that the packet contents should be 208 parsed (or decrypted and parsed if it is encrypted). The session itself, 209 as distinct from the session announcement, is uniquely identified by the 210 payload and not by the message identifier hash in the header. 212 The same rules apply for session modification as for session deletion: 214 o Either the modified announcement must contain an authentication 215 header signed by the same key as the cached session announcement 216 it is modifying, or: 218 o The cached session announcement must not contain an authentication 219 header, and the session modification announcement must originate 220 from the same host as the session it is modifying. 222 If an announcement is received containing an authentication header 223 and the cached announcement did not contain an authentication header, 224 or it contained a different authentication header, then the modified 225 announcement MUST be treated as a new and different announcement, 226 and displayed in addition to the un-authenticated announcement. The 227 same should happen if a modified packet without an authentication 228 header is received from a different source than the original announcement. 229 These rules prevent an announcement having an authentication header 230 added by a malicious user and then being deleted using that header, 231 and it also prevents a denial-of-service attack by someone putting 232 out a spoof announcement which, due to packet loss, reaches some 233 participants before the original announcement. Note that under such 234 circumstances, being able to authenticate the message originator is 235 the only way to discover which session is the correct session. 237 v=0 238 o=cperkins 2890844526 2890842807 IN IP4 126.16.64.4 239 s=Sample directory session 240 m=directory 9875 SAP application/sdp 241 c=IN IP4 224.2.127.12/255 242 t=2873397496 2873404696 244 Figure 1: Example SDP for a directory session 246 6 Directory Sessions 248 It is possible to announce sessions which describe other directories. 249 Such directory sessions should each announce a single directory. Receivers 250 MUST ignore announcements which describe multiple directories. Receivers 251 SHOULD ignore non-authenticated directory sessions. 253 Directory sessions may be described in SDP using the media type `directory' 254 with transport `SAP' (see figure 1 for example). Directory sessions 255 SHOULD be announced with TTL 255 and SHOULD use port 9875. Any SAP 256 announcer may announce sessions in an announced SAP group, there 257 is no explicit access control. 259 If the announcement of a directory is deleted, announcers of sessions 260 within that directory MUST stop announcing those sessions provided 261 the deletion packet authenticates with the same key as the original 262 announcement of the directory session. If the deletion packet is 263 not authenticated, or is authenticated with a different key, then 264 it SHOULD be ignored. 266 If the announcement of a directory times out, announcers of sessions 267 within that directory SHOULD stop announcing those sessions. 269 If the announcement of the directory is modified to use a different 270 address announcers of sessions within that directory MUST move their 271 announcement to the new directory, provided the modification packet 272 authenticates with the same key as the original announcement of the 273 directory session. If the modification packet is not authenticated, 274 or is authenticated with a different key, then it SHOULD be ignored. 276 7 Packet Format 278 SAP data packets have the format described in figure 2. 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 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | V=1 |A|R|T|E|C| auth len | msg id hash | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 : originating source (32 or 128 bits) : 292 : : 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | optional authentication header | 295 : .... : 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | optional timeout | 298 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 299 | optional payload type | 300 + +-+- - - - - - - - - -+ 301 | |0| | 302 + - - - - - - - - - - - - - - - - - - - - +-+ | 303 | | 304 : payload : 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 2: Packet format 310 A: Address type. If the A bit is 0, the originating source field 311 contains a 32-bit IPv4 address. If the A bit is 1, the originating 312 source contains a 128-bit IPv6 address. 314 R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST 315 ignore the contents of this field. 317 T: Message Type. If the T field is set to 0 this is a session 318 announcement packet, if 1 this is a session deletion packet. 320 E: Encryption Bit. If the encryption bit is set to 1, the payload 321 of the SAP packet is encrypted and the timeout field MUST be 322 added to the packet header. If this bit is 0 the packet is 323 not encrypted and the timeout MUST NOT be present. See section 324 8 for details of the encryption process. 326 C: Compressed bit. If the compressed bit is set to 1, the payload 327 is compressed using the zlib compression algorithm [3]. If the 328 payload is to be compressed and encrypted, the compression MUST 329 be performed first. 331 Authentication Length. An 8 bit unsigned quantity giving the number 332 of 32 bit words following the main SAP header that contain 333 authentication data. If it is zero, no authentication header 334 is present. 336 Authentication Header containing a digital signature of the packet, 337 with length as specified by the authentication length header 338 field. See section 9 for details of the authentication process. 340 Message Identifier Hash. A 16 bit quantity that, used in combination 341 with the originating source, provides a globally unique identifier 342 indicating the precise version of this announcement. The choice 343 of value for this field is not specified here, except that it 344 MUST be unique for each session announced by a particular SAP 345 announcer and it MUST be changed if the session description is 346 modified. 348 Earlier versions of SAP used a value of zero to mean that the 349 hash should be ignored and the payload should always be parsed. 350 This had the unfortunate side-effect that SAP announcers had 351 to study the payload data to determine how many unique sessions 352 were being advertised, making the calculation of the announcement 353 interval more complex that necessary. In order to decouple the 354 session announcement process from the contents of those announcements, 355 SAP announcers SHOULD NOT set the message identifier hash to zero. 357 SAP listeners MAY silently discard messages if the message identifier 358 hash is set to zero. 360 Originating Source. This gives the IP address of the original source 361 of the message. This is an IPv4 address if the A field is set 362 to zero, else it is an IPv6 address. The address is stored 363 in network byte order. 365 SAPv0 permitted the originating source to be zero if the message 366 identifier hash was also zero. This practise is no longer legal, 367 and SAP announcers SHOULD NOT set the originating source to zero. 368 SAP listeners MAY silently discard packets with the originating 369 source set to zero. 371 Timeout. When the session payload is encrypted the detailed timing 372 fields in the payload are not available to listeners which are 373 not trusted with the decryption key. Under such circumstances, 374 the header includes an additional 32-bit timestamp field stating 375 when the session should be timed out. 377 Note that the timeout field in the header is intended for use 378 only by those listeners which do not have the correct key to 379 decrypt the announcement. A SAP listener which is capable of 380 decrypting the announcement MUST determine when to timeout the 381 session based on the payload information. 383 The value is an unsigned quantity giving the NTP time [8] in 384 seconds at which time the session is timed out. It is in network 385 byte order. 387 The header is followed by an optional payload type field and the 388 payload data itself. If the E or C bits are set in the header both 389 the payload type and payload are optionally encrypted and/or compressed. 391 The payload type field is a MIME content type specifier, describing 392 the format of the payload. This is a variable length ASCII text 393 string, followed by a single zero byte (ASCII NUL). The payload type 394 SHOULD be included in all packets. If the payload type is `application/sdp' 395 both the payload type and its terminating zero byte MAY be omitted, 396 although this is intended for backwards compatibility with SAP v1 397 listeners only. 399 The absence of a payload type field may be noted since the payload 400 section of such a packet will start with an SDP `v=0' field, which 401 is not a legal MIME content type specifier. 403 All implementations MUST support payloads of type `application/sdp' 404 [4]. Other formats MAY be supported although since there is no negotiation 405 in SAP an announcer which chooses to use a session description format 406 other than SDP cannot know that the listeners are able to understand 407 the announcement. A proliferation of payload types in announcements 408 has the potential to lead to severe interoperability problems, and 409 for this reason, the use of non-SDP payloads is NOT RECOMMENDED. 411 If the packet is an announcement packet, the payload contains a session 412 description. 414 If the packet is a session deletion packet, the payload contains 415 a session deletion message. If the payload format is `application/sdp' 416 the deletion message is a single SDP line consisting of the origin 417 field of the announcement to be deleted. 419 It is desirable for the payload to be sufficiently small that SAP packets 420 do not get fragmented by the underlying network. Fragmentation has a loss 421 multiplier effect, which is known to significantly affect the reliability 422 of announcements. It is RECOMMENDED that SAP packets are smaller than 423 1kByte in length, although if it is known that announcements will use a 424 network with a smaller MTU than this, then that SHOULD be used as the 425 maximum recommended packet size. 427 8 Encrypted Announcements 429 An announcement is received by all listeners in the scope to which 430 it is sent. If an announcement is encrypted, and many of the receivers 431 do not have the encryption key, there is a considerable waste of 432 bandwidth since those receivers cannot use the announcement they have 433 received. For this reason, the use of encrypted SAP announcements 434 is NOT RECOMMENDED on the global scope SAP group or on administrative 435 scope groups which may have many receivers which cannot decrypt those 436 announcements. 438 The opinion of the authors is that encrypted SAP is useful in special 439 cases only, and that the vast majority of scenarios where encrypted 440 SAP has been proposed may be better served by distributing session 441 details using another mechanism. There are, however, certain scenarios 442 where encrypted announcements may be useful. For this reason, the 443 encryption bit is included in the SAP header to allow experimentation 444 with encrypted announcements. 446 This memo does not specify details of the encryption algorithm to 447 be used or the means by which keys are generated and distributed. 448 An additional specification should define these, if it is desired 449 to use encrypted SAP. 451 Note that if an encrypted announcement is being announced via a proxy, 452 then there may be no way for the proxy to discover that the announcement 453 has been superseded, and so it may continue to relay the old announcement 454 in addition to the new announcement. SAP provides no mechanism to 455 chain modified encrypted announcements, so it is advisable to announce 456 the unmodified session as deleted for a short time after the modification 457 has occurred. This does not guarantee that all proxies have deleted 458 the session, and so receivers of encrypted sessions should be prepared 459 to discard old versions of session announcements that they may receive. 460 In most cases however, the only stateful proxy will be local to (and 461 known to) the sender, and an additional (local-area) protocol involving 462 a handshake for such session modifications can be used to avoid this 463 problem. 465 Session announcements that are encrypted with a symmetric algorithm 466 may allow a degree of privacy in the announcement of a session, but 467 it should be recognised that a user in possession of such a key can 468 pass it on to other users who should not be in possession of such 469 a key. Thus announcements to such a group of key holders cannot 470 be assumed to have come from an authorised key holder unless there 471 is an appropriate authentication header signed by an authorised key 472 holder. In addition the recipients of such encrypted announcements 473 cannot be assumed to only be authorised key holders. Such encrypted 474 announcements do not provide any real security unless all of the 475 authorised key holders are trusted to maintain security of such session 476 directory keys. This property is shared by the multicast session 477 tools themselves, where it is possible for an un-trustworthy member 478 of the session to pass on encryption keys to un-authorised users. 479 However it is likely that keys used for the session tools will be 480 more short lived than those used for session directories. 482 Similar considerations should apply when session announcements are 483 encrypted with an assymetric algorithm, but then it is possible to 484 restrict the possessor(s) of the private key, so that announcements 485 to a key-holder group can not be made, even if one of the untrusted 486 members of the group proves to be un-trustworthy. 488 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | V=1 |P| Auth | | 492 +-+-+-+-+-+-+-+-+ | 493 | Format specific authentication subheader | 494 : .................. : 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 3: Format of the authentication header 499 9 Authenticated Announcements 501 The authentication header can be used for two purposes: 503 o Verification that changes to a session description or deletion 504 of a session are permitted. 506 o Authentication of the identity of the session creator. 508 In some circumstances only verification is possible because a certificate 509 signed by a mutually trusted person or authority is not available. 510 However, under such circumstances, the session originator may still 511 be authenticated to be the same as the session originator of previous 512 sessions claiming to be from the same person. This may or may not 513 be sufficient depending on the purpose of the session and the people 514 involved. 516 Clearly the key used in the authentication header should not be trusted 517 to belong to the session originator unless it has been separately 518 authenticated by some other means, such as being certified by a trusted 519 third party. Such certificates are not normally included in an SAP 520 header because they take more space than can normally be afforded 521 in an SAP packet, and such verification must therefore take place 522 by some other mechanism. However, as certified public keys are normally 523 locally cached, authentication of a particular key only has to take 524 place once, rather than every time the session directory retransmits 525 the announcement. 527 SAP is not tied to any single authentication mechanism. Authentication 528 headers are self-describing, but their precise format depends on the 529 authentication mechanism in use. The generic format of the Authentication 530 Header is given in figure 3. The structure of the Format Specific 531 Authentication Subheader, using both the PGP and the CMS formats, 532 is discussed in sections 9.1 and 9.2 respectively. 534 Version Number, V: The version number of the authentication header 535 specified by this memo is 1. 537 Padding Bit, P: If necessary the data in the authentication header 538 is padded to be a multiple of 32 bits and the padding bit is 539 set. In this case the last byte of the authentication header 540 contains the number of padding bytes (including the last byte) 541 that must be discarded. 543 Authentication Type, Auth: The authentication type is a 4 bit encoded 544 field that denotes the authentication infrastructure the sender 545 expects the recipients to use to check the authenticity and integrity 546 of the information. This defines the format of the authentication 547 subheader and can take the values: 0 = PGP format, 1 = CMS 548 format. All other values are undefined and SHOULD be ignored. 550 If a SAP packet is to be compressed or encrypted, this MUST be done 551 before the authentication is added. 553 The digital signature in the authentication header MUST be calculated 554 over the entire packet, including the header. The authentication 555 length MUST be set to zero and the authentication header field excluded 556 when calculating the digitial signature. 558 9.1 PGP Authentication 560 Implementations which support authentication MUST support this format. 561 A full description of the PGP protocol can be found in [2]. When 562 using PGP for SAP authentication the basic format specific authentication 563 subheader comprises a digital signature packet as described in [2]. 564 The signature type MUST be 0x01 which means the signature is that 565 of a canonical text document. 567 9.2 CMS Authentication 569 Support for this format is OPTIONAL. 571 A full description of the Cryptographic Message Syntax can be found 572 in [6]. The format specific authentication subheader will, in the 573 CMS case, have an ASN.1 ContentInfo type with the ContentType being 574 signedData. 576 Use is made of the option available in PKCS#7 to leave the content 577 itself blank as the content which is signed is already present in 578 the packet. Inclusion of it within the SignedData type would duplicate 579 this data and increase the packet length unnecessarily. In addition 580 this allows recipients with either no interest in the authentication, 581 or with no mechanism for checking it, to more easily skip the authentication 582 information. 584 There SHOULD be only one signerInfo and related fields corresponding 585 to the originator of the SAP announcement. The signingTime SHOUD 586 be present as a signedAttribute. However, due to the strict size 587 limitations on the size of SAP packets, certificates and CRLs SHOULD 588 NOT be included in the signedData structure. It is expected that 589 users of the protocol will have other methods for certificate and 590 CRL distribution. 592 10 Scalability and caching 594 SAP is intended to announce the existence of long-lived wide-area 595 multicast sessions. It is not an especially timely protocol: sessions 596 are announced by periodic multicast with a repeat rate on the order 597 of tens of minutes, and no enhanced reliability over UDP. This leads 598 to a long startup delay before a complete set of announcements is 599 heard by a listener. This delay is clearly undesirable for interactive 600 browsing of announced sessions. 602 In order to reduce the delays inherent in SAP, it is recommended 603 that proxy caches are deployed. A SAP proxy cache is expected to 604 listen to all SAP groups in its scope, and to maintain an up-to-date 605 list of all announced sessions along with the time each announcement 606 was last received. When a new SAP listeners starts, it should contact 607 its local proxy to download this information, which is then sufficient 608 for it to process future announcements directly, as if it has been 609 continually listening. 611 The protocol by which a SAP listener contacts its local proxy cache 612 is not specified here. 614 11 Security Considerations 616 SAP contains mechanisms for ensuring integrity of session announcements, 617 for authenticating the origin of an announcement and for encrypting 618 such announcements (sections 8 and 9). These mechanisms have not 619 yet been subject to suitable peer-review, and this memo should not 620 be considered authoritative in this area at this time. 622 As stated in section 5, if a session modification announcement is 623 received that contains a valid authentication header, but which is 624 not signed by the original creator of the session, then the session 625 must be treated as a new session in addition to the original session 626 with the same SDP origin information unless the originator of one 627 of the session descriptions can be authenticated using a certificate 628 signed by a trusted third party. If this were not done, there would 629 be a possible denial of service attack whereby a party listens for 630 new announcements, strips off the original authentication header, 631 modifies the session description, adds a new authentication header 632 and re-announces the session. If a rule was imposed that such spoof 633 announcements were ignored, then if packet loss or late starting 634 of a session directory instance caused the original announcement to 635 fail to arrive at a site, but the spoof announcement did so, this 636 would then prevent the original announcement from being accepted at 637 that site. 639 A similar denial-of-service attack is possible if a session announcement 640 receiver relies completely on the originating source and hash fields 641 to indicate change, and fails to parse the remainder of announcements 642 for which it has seen the origin/hash combination before. 643 A denial of service attack is possible from a malicious site close 644 to a legitimate site which is making a session announcement. This 645 can happen if the malicious site floods the legitimate site with 646 huge numbers of (illegal) low TTL announcements describing high TTL 647 sessions. This may reduce the session announcement rate of the legitimate 648 announcement to below a tenth of the rate expected at remote sites 649 and therefore cause the session to time out. Such an attack is likely 650 to be easily detectable, and we do not provide any mechanism here 651 to prevent it. 653 A Summary of differences between SAPv0 and SAPv1 655 For this purpose SAPv0 is defined as the protocol in use by version 656 2.2 of the session directory tool, sdr. SAPv1 is the protocol described 657 in the 19 November 1996 version of this memo (draft-ietf-mmusic-sap-00.txt). 658 The packet headers of SAP messages are the same in V0 and V1 in 659 that a V1 tool can parse a V0 announcement header but not vice-versa. 660 In SAPv0, the fields have the following values: 662 o Version Number: 0 664 o Message Type: 0 (Announcement) 666 o Authentication Type: 0 (No Authentication) 668 o Encryption Bit: 0 (No Encryption) 670 o Compression Bit: 0 (No compression) 672 o Message Id Hash: 0 (No Hash Specified) 674 o Originating Source: 0 (No source specified, announcement has 675 not been relayed) 677 B Summary of differences between SAPv1 and SAPv2 679 The packet headers of SAP messages are the same in V1 and V2 in 680 that a V2 tool can parse a V1 announcement header but not necessarily 681 vice-versa. 683 o The A bit has been added to the SAP header, replacing one of 684 the bits of the SAPv1 message type field. If set to zero the 685 announcement is of an IPv4 session, and the packet is backwards 686 compatible with SAPv1. If set to one the announcement is of 687 an IPv6 session, and SAPv1 clients (which do not support IPv6) 688 will see this as an illegal message type (MT) field. 690 o The second bit of the message type field in SAPv1 has been replaced 691 by a reserved, must-be-zero, bit. This bit was unused in SAPv1, 692 so this change just codifies existing usage. 694 o SAPv1 specified encryption of the payload. SAPv2 includes the 695 E bit in the SAP header to indicate that the payload is encrypted, 696 but does not specify any details of the encryption. 698 o SAPv1 allowed the message identifier hash and originating source 699 fields to be set to zero, for backwards compatibility. This 700 is no longer legal. 702 o SAPv1 specified gzip compression. SAPv2 uses zlib (the only 703 known implementation of SAP compression used zlib, and gzip compression 704 was a mistake). 706 o SAPv2 provides a more complete specification for authentication. 708 o SAPv2 allows for non-SDP payloads to be transported. SAPv1 required 709 that the payload was SDP. 711 o SAPv2 makes the concept of directory session explicit. 713 C Acknowledgments 715 SAP and SDP were originally based on the protocol used by the sd 716 session directory from Van Jacobson at LBNL. Version 1 of SAP was 717 designed by Mark Handley as part of the European Commission MICE 718 (Esprit 7602) and MERCI (Telematics 1007) projects. Version 2 includes 719 authentication features developed by Edmund Whelan, Goli Montasser-Kohsari 720 and Peter Kirstein as part of the European Commission ICE-TEL project 721 (Telematics 1005), and support for IPv6 developed by Maryann P. Maher 722 and Colin Perkins. The idea of using SAP to announce other SAP sessions 723 is due to Ross Finlayson. 725 D Authors' Addresses 727 Mark Handley 728 AT&T Center for Internet Research at ICSI, 729 International Computer Science Institute, 730 1947 Center Street, Suite 600, 731 Berkeley, CA 94704, USA 733 Colin Perkins 734 Department of Computer Science, 735 University College London, 736 Gower Street, 737 London, WC1E 6BT, UK 739 Edmund Whelan 740 Department of Computer Science, 741 University College London, 742 Gower Street, 743 London, WC1E 6BT, UK 745 References 747 [1] S. Bradner. Key words for use in RFCs to indicate requirement levels, 748 March 1997. RFC2119. 750 [2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message 751 format, November 1998. RFC2440. 753 [3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification 754 version 3.3, May 1996. RFC1950. 756 [4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April 757 1998. RFC2327. 759 [5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone 760 announcement protocol (MZAP)(, February 1999. Work in progress. 762 [6] R. Housley. Cryptographic message syntax. Work in progress, April 763 1999. draft-ietf-smime-cms-13.txt. 765 [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. 767 [8] D. Mills. Network time protocol version 3, March 1992. RFC1305. 769 ===============================================================================