1 2 3 4 5 6 7Network Working Group M. Handley 8Request for Comments: 2974 ACIRI 9Category: Experimental C. Perkins 10 USC/ISI 11 E. Whelan 12 UCL 13 October 2000 14 15 16 Session Announcement Protocol 17 18Status of this Memo 19 20 This memo defines an Experimental Protocol for the Internet 21 community. It does not specify an Internet standard of any kind. 22 Discussion and suggestions for improvement are requested. 23 Distribution of this memo is unlimited. 24 25Copyright Notice 26 27 Copyright (C) The Internet Society (2000). All Rights Reserved. 28 29Abstract 30 31 This document describes version 2 of the multicast session directory 32 announcement protocol, Session Announcement Protocol (SAP), and the 33 related issues affecting security and scalability that should be 34 taken into account by implementors. 35 361 Introduction 37 38 In order to assist the advertisement of multicast multimedia 39 conferences and other multicast sessions, and to communicate the 40 relevant session setup information to prospective participants, a 41 distributed session directory may be used. An instance of such a 42 session directory periodically multicasts packets containing a 43 description of the session, and these advertisements are received by 44 other session directories such that potential remote participants can 45 use the session description to start the tools required to 46 participate in the session. 47 48 This memo describes the issues involved in the multicast announcement 49 of session description information and defines an announcement 50 protocol to be used. Sessions are described using the session 51 description protocol which is described in a companion memo [4]. 52 53 54 55 56 57 58Handley, et al. Experimental [Page 1] 59 60RFC 2974 Session Announcement Protocol October 2000 61 62 632 Terminology 64 65 A SAP announcer periodically multicasts an announcement packet to a 66 well known multicast address and port. The announcement is multicast 67 with the same scope as the session it is announcing, ensuring that 68 the recipients of the announcement are within the scope of the 69 session the announcement describes (bandwidth and other such 70 constraints permitting). This is also important for the scalability 71 of the protocol, as it keeps local session announcements local. 72 73 A SAP listener learns of the multicast scopes it is within (for 74 example, using the Multicast-Scope Zone Announcement Protocol [5]) 75 and listens on the well known SAP address and port for those scopes. 76 In this manner, it will eventually learn of all the sessions being 77 announced, allowing those sessions to be joined. 78 79 The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', 80 `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this 81 document are to be interpreted as described in [1]. 82 833 Session Announcement 84 85 As noted previously, a SAP announcer periodically sends an 86 announcement packet to a well known multicast address and port. 87 There is no rendezvous mechanism - the SAP announcer is not aware of 88 the presence or absence of any SAP listeners - and no additional 89 reliability is provided over the standard best-effort UDP/IP 90 semantics. 91 92 That announcement contains a session description and SHOULD contain 93 an authentication header. The session description MAY be encrypted 94 although this is NOT RECOMMENDED (see section 7). 95 96 A SAP announcement is multicast with the same scope as the session it 97 is announcing, ensuring that the recipients of the announcement are 98 within the scope of the session the announcement describes. There are 99 a number of possibilities: 100 101 IPv4 global scope sessions use multicast addresses in the range 102 224.2.128.0 - 224.2.255.255 with SAP announcements being sent to 103 224.2.127.254 (note that 224.2.127.255 is used by the obsolete 104 SAPv0 and MUST NOT be used). 105 106 107 108 109 110 111 112 113 114Handley, et al. Experimental [Page 2] 115 116RFC 2974 Session Announcement Protocol October 2000 117 118 119 IPv4 administrative scope sessions using administratively scoped IP 120 multicast as defined in [7]. The multicast address to be used for 121 announcements is the highest multicast address in the relevant 122 administrative scope zone. For example, if the scope range is 123 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP 124 announcements. 125 126 IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE 127 where X is the 4-bit scope value. For example, an announcement 128 for a link-local session assigned the address 129 FF02:0:0:0:0:0:1234:5678, should be advertised on SAP address 130 FF02:0:0:0:0:0:2:7FFE. 131 132 Ensuring that a description is not used by a potential participant 133 outside the session scope is not addressed in this memo. 134 135 SAP announcements MUST be sent on port 9875 and SHOULD be sent with 136 an IP time-to-live of 255 (the use of TTL scoping for multicast is 137 discouraged [7]). 138 139 If a session uses addresses in multiple administrative scope ranges, 140 it is necessary for the announcer to send identical copies of the 141 announcement to each administrative scope range. It is up to the 142 listeners to parse such multiple announcements as the same session 143 (as identified by the SDP origin field, for example). The 144 announcement rate for each administrative scope range MUST be 145 calculated separately, as if the multiple announcements were 146 separate. 147 148 Multiple announcers may announce a single session, as an aid to 149 robustness in the face of packet loss and failure of one or more 150 announcers. The rate at which each announcer repeats its 151 announcement MUST be scaled back such that the total announcement 152 rate is equal to that which a single server would choose. 153 Announcements made in this manner MUST be identical. 154 155 If multiple announcements are being made for a session, then each 156 announcement MUST carry an authentication header signed by the same 157 key, or be treated as a completely separate announcement by 158 listeners. 159 160 An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP 161 address and on the SAP addresses for each IPv4 administrative scope 162 zone it is within. The discovery of administrative scope zones is 163 outside the scope of this memo, but it is assumed that each SAP 164 listener within a particular scope zone is aware of that scope zone. 165 A SAP listener which supports IPv6 SHOULD also listen to the IPv6 SAP 166 addresses. 167 168 169 170Handley, et al. Experimental [Page 3] 171 172RFC 2974 Session Announcement Protocol October 2000 173 174 1753.1 Announcement Interval 176 177 The time period between repetitions of an announcement is chosen such 178 that the total bandwidth used by all announcements on a single SAP 179 group remains below a preconfigured limit. If not otherwise 180 specified, the bandwidth limit SHOULD be assumed to be 4000 bits per 181 second. 182 183 Each announcer is expected to listen to other announcements in order 184 to determine the total number of sessions being announced on a 185 particular group. Sessions are uniquely identified by the 186 combination of the message identifier hash and originating source 187 fields of the SAP header (note that SAP v0 announcers always set the 188 message identifier hash to zero, and if such an announcement is 189 received the entire message MUST be compared to determine 190 uniqueness). 191 192 Announcements are made by periodic multicast to the group. The base 193 interval between announcements is derived from the number of 194 announcements being made in that group, the size of the announcement 195 and the configured bandwidth limit. The actual transmission time is 196 derived from this base interval as follows: 197 198 1. The announcer initializes the variable tp to be the last time a 199 particular announcement was transmitted (or the current time if 200 this is the first time this announcement is to be made). 201 202 2. Given a configured bandwidth limit in bits/second and an 203 announcement of ad_size bytes, the base announcement interval 204 in seconds is 205 206 interval =max(300; (8*no_of_ads*ad_size)/limit) 207 208 3. An offset is calculated based on the base announcement interval 209 210 offset= rand(interval* 2/3)-(interval/3) 211 212 4. The next transmission time for an announcement derived as 213 214 tn =tp+ interval+ offset 215 216 The announcer then sets a timer to expire at tn and waits. At time 217 tn the announcer SHOULD recalculate the next transmission time. If 218 the new value of tn is before the current time, the announcement is 219 sent immediately. Otherwise the transmission is rescheduled for the 220 new tn. This reconsideration prevents transient packet bursts on 221 startup and when a network partition heals. 222 223 224 225 226Handley, et al. Experimental [Page 4] 227 228RFC 2974 Session Announcement Protocol October 2000 229 230 2314 Session Deletion 232 233 Sessions may be deleted in one of several ways: 234 235 Explicit Timeout The session description payload may contain 236 timestamp information specifying the start- and end-times of the 237 session. If the current time is later than the end-time of the 238 session, then the session SHOULD be deleted from the receiver's 239 session cache. 240 241 Implicit Timeout A session announcement message should be received 242 periodically for each session description in a receiver's session 243 cache. The announcement period can be predicted by the receiver 244 from the set of sessions currently being announced. If a session 245 announcement message has not been received for ten times the 246 announcement period, or one hour, whichever is the greater, then 247 the session is deleted from the receiver's session cache. The one 248 hour minimum is to allow for transient network partitionings. 249 250 Explicit Deletion A session deletion packet is received specifying 251 the session to be deleted. Session deletion packets SHOULD have a 252 valid authentication header, matching that used to authenticate 253 previous announcement packets. If this authentication is missing, 254 the deletion message SHOULD be ignored. 255 2565 Session Modification 257 258 A pre-announced session can be modified by simply announcing the 259 modified session description. In this case, the version hash in the 260 SAP header MUST be changed to indicate to receivers that the packet 261 contents should be parsed (or decrypted and parsed if it is 262 encrypted). The session itself, as distinct from the session 263 announcement, is uniquely identified by the payload and not by the 264 message identifier hash in the header. 265 266 The same rules apply for session modification as for session 267 deletion: 268 269 o Either the modified announcement must contain an authentication 270 header signed by the same key as the cached session announcement 271 it is modifying, or: 272 273 o The cached session announcement must not contain an authentication 274 header, and the session modification announcement must originate 275 from the same host as the session it is modifying. 276 277 278 279 280 281 282Handley, et al. Experimental [Page 5] 283 284RFC 2974 Session Announcement Protocol October 2000 285 286 287 If an announcement is received containing an authentication header 288 and the cached announcement did not contain an authentication header, 289 or it contained a different authentication header, then the modified 290 announcement MUST be treated as a new and different announcement, and 291 displayed in addition to the un-authenticated announcement. The same 292 should happen if a modified packet without an authentication header 293 is received from a different source than the original announcement. 294 295 These rules prevent an announcement having an authentication header 296 added by a malicious user and then being deleted using that header, 297 and it also prevents a denial-of-service attack by someone putting 298 out a spoof announcement which, due to packet loss, reaches some 299 participants before the original announcement. Note that under such 300 circumstances, being able to authenticate the message originator is 301 the only way to discover which session is the correct session. 302 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | V=1 |A|R|T|E|C| auth len | msg id hash | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 : originating source (32 or 128 bits) : 310 : : 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | optional authentication data | 313 : .... : 314 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 315 | optional payload type | 316 + +-+- - - - - - - - - -+ 317 | |0| | 318 + - - - - - - - - - - - - - - - - - - - - +-+ | 319 | | 320 : payload : 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 324 Figure 1: Packet format 325 3266 Packet Format 327 328 SAP data packets have the format described in figure 1. 329 330 V: Version Number. The version number field MUST be set to 1 (SAPv2 331 announcements which use only SAPv1 features are backwards 332 compatible, those which use new features can be detected by other 333 means, so the SAP version number doesn't need to change). 334 335 336 337 338Handley, et al. Experimental [Page 6] 339 340RFC 2974 Session Announcement Protocol October 2000 341 342 343 A: Address type. If the A bit is 0, the originating source field 344 contains a 32-bit IPv4 address. If the A bit is 1, the 345 originating source contains a 128-bit IPv6 address. 346 347 R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST 348 ignore the contents of this field. 349 350 T: Message Type. If the T field is set to 0 this is a session 351 announcement packet, if 1 this is a session deletion packet. 352 353 E: Encryption Bit. If the encryption bit is set to 1, the payload of 354 the SAP packet is encrypted. If this bit is 0 the packet is not 355 encrypted. See section 7 for details of the encryption process. 356 357 C: Compressed bit. If the compressed bit is set to 1, the payload is 358 compressed using the zlib compression algorithm [3]. If the 359 payload is to be compressed and encrypted, the compression MUST be 360 performed first. 361 362 Authentication Length. An 8 bit unsigned quantity giving the number 363 of 32 bit words following the main SAP header that contain 364 authentication data. If it is zero, no authentication header is 365 present. 366 367 Authentication data containing a digital signature of the packet, 368 with length as specified by the authentication length header 369 field. See section 8 for details of the authentication process. 370 371 Message Identifier Hash. A 16 bit quantity that, used in combination 372 with the originating source, provides a globally unique identifier 373 indicating the precise version of this announcement. The choice 374 of value for this field is not specified here, except that it MUST 375 be unique for each session announced by a particular SAP announcer 376 and it MUST be changed if the session description is modified (and 377 a session deletion message SHOULD be sent for the old version of 378 the session). 379 380 Earlier versions of SAP used a value of zero to mean that the hash 381 should be ignored and the payload should always be parsed. This 382 had the unfortunate side-effect that SAP announcers had to study 383 the payload data to determine how many unique sessions were being 384 advertised, making the calculation of the announcement interval 385 more complex that necessary. In order to decouple the session 386 announcement process from the contents of those announcements, SAP 387 announcers SHOULD NOT set the message identifier hash to zero. 388 389 SAP listeners MAY silently discard messages if the message 390 identifier hash is set to zero. 391 392 393 394Handley, et al. Experimental [Page 7] 395 396RFC 2974 Session Announcement Protocol October 2000 397 398 399 Originating Source. This gives the IP address of the original source 400 of the message. This is an IPv4 address if the A field is set to 401 zero, else it is an IPv6 address. The address is stored in 402 network byte order. 403 404 SAPv0 permitted the originating source to be zero if the message 405 identifier hash was also zero. This practise is no longer legal, 406 and SAP announcers SHOULD NOT set the originating source to zero. 407 SAP listeners MAY silently discard packets with the originating 408 source set to zero. 409 410 The header is followed by an optional payload type field and the 411 payload data itself. If the E or C bits are set in the header both 412 the payload type and payload are encrypted and/or compressed. 413 414 The payload type field is a MIME content type specifier, describing 415 the format of the payload. This is a variable length ASCII text 416 string, followed by a single zero byte (ASCII NUL). The payload type 417 SHOULD be included in all packets. If the payload type is 418 `application/sdp' both the payload type and its terminating zero byte 419 MAY be omitted, although this is intended for backwards compatibility 420 with SAP v1 listeners only. 421 422 The absence of a payload type field may be noted since the payload 423 section of such a packet will start with an SDP `v=0' field, which is 424 not a legal MIME content type specifier. 425 426 All implementations MUST support payloads of type `application/sdp' 427 [4]. Other formats MAY be supported although since there is no 428 negotiation in SAP an announcer which chooses to use a session 429 description format other than SDP cannot know that the listeners are 430 able to understand the announcement. A proliferation of payload 431 types in announcements has the potential to lead to severe 432 interoperability problems, and for this reason, the use of non-SDP 433 payloads is NOT RECOMMENDED. 434 435 If the packet is an announcement packet, the payload contains a 436 session description. 437 438 If the packet is a session deletion packet, the payload contains a 439 session deletion message. If the payload format is `application/sdp' 440 the deletion message is a single SDP line consisting of the origin 441 field of the announcement to be deleted. 442 443 It is desirable for the payload to be sufficiently small that SAP 444 packets do not get fragmented by the underlying network. 445 Fragmentation has a loss multiplier effect, which is known to 446 significantly affect the reliability of announcements. It is 447 448 449 450Handley, et al. Experimental [Page 8] 451 452RFC 2974 Session Announcement Protocol October 2000 453 454 455 RECOMMENDED that SAP packets are smaller than 1kByte in length, 456 although if it is known that announcements will use a network with a 457 smaller MTU than this, then that SHOULD be used as the maximum 458 recommended packet size. 459 4607 Encrypted Announcements 461 462 An announcement is received by all listeners in the scope to which it 463 is sent. If an announcement is encrypted, and many of the receivers 464 do not have the encryption key, there is a considerable waste of 465 bandwidth since those receivers cannot use the announcement they have 466 received. For this reason, the use of encrypted SAP announcements is 467 NOT RECOMMENDED on the global scope SAP group or on administrative 468 scope groups which may have many receivers which cannot decrypt those 469 announcements. 470 471 The opinion of the authors is that encrypted SAP is useful in special 472 cases only, and that the vast majority of scenarios where encrypted 473 SAP has been proposed may be better served by distributing session 474 details using another mechanism. There are, however, certain 475 scenarios where encrypted announcements may be useful. For this 476 reason, the encryption bit is included in the SAP header to allow 477 experimentation with encrypted announcements. 478 479 This memo does not specify details of the encryption algorithm to be 480 used or the means by which keys are generated and distributed. An 481 additional specification should define these, if it is desired to use 482 encrypted SAP. 483 484 Note that if an encrypted announcement is being announced via a 485 proxy, then there may be no way for the proxy to discover that the 486 announcement has been superseded, and so it may continue to relay the 487 old announcement in addition to the new announcement. SAP provides 488 no mechanism to chain modified encrypted announcements, so it is 489 advisable to announce the unmodified session as deleted for a short 490 time after the modification has occurred. This does not guarantee 491 that all proxies have deleted the session, and so receivers of 492 encrypted sessions should be prepared to discard old versions of 493 session announcements that they may receive. In most cases however, 494 the only stateful proxy will be local to (and known to) the sender, 495 and an additional (local-area) protocol involving a handshake for 496 such session modifications can be used to avoid this problem. 497 498 Session announcements that are encrypted with a symmetric algorithm 499 may allow a degree of privacy in the announcement of a session, but 500 it should be recognized that a user in possession of such a key can 501 pass it on to other users who should not be in possession of such a 502 key. Thus announcements to such a group of key holders cannot be 503 504 505 506Handley, et al. Experimental [Page 9] 507 508RFC 2974 Session Announcement Protocol October 2000 509 510 511 assumed to have come from an authorized key holder unless there is an 512 appropriate authentication header signed by an authorized key holder. 513 In addition the recipients of such encrypted announcements cannot be 514 assumed to only be authorized key holders. Such encrypted 515 announcements do not provide any real security unless all of the 516 authorized key holders are trusted to maintain security of such 517 session directory keys. This property is shared by the multicast 518 session tools themselves, where it is possible for an un-trustworthy 519 member of the session to pass on encryption keys to un-authorized 520 users. However it is likely that keys used for the session tools 521 will be more short lived than those used for session directories. 522 523 Similar considerations should apply when session announcements are 524 encrypted with an asymmetric algorithm, but then it is possible to 525 restrict the possessor(s) of the private key, so that announcements 526 to a key-holder group can not be made, even if one of the untrusted 527 members of the group proves to be un-trustworthy. 528 529 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | V=1 |P| Auth | | 533 +-+-+-+-+-+-+-+-+ | 534 | Format specific authentication subheader | 535 : .................. : 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 538 Figure 2: Format of the authentication data in the SAP header 539 5408 Authenticated Announcements 541 542 The authentication header can be used for two purposes: 543 544 o Verification that changes to a session description or deletion of 545 a session are permitted. 546 547 o Authentication of the identity of the session creator. 548 549 In some circumstances only verification is possible because a 550 certificate signed by a mutually trusted person or authority is not 551 available. However, under such circumstances, the session originator 552 may still be authenticated to be the same as the session originator 553 of previous sessions claiming to be from the same person. This may 554 or may not be sufficient depending on the purpose of the session and 555 the people involved. 556 557 558 559 560 561 562Handley, et al. Experimental [Page 10] 563 564RFC 2974 Session Announcement Protocol October 2000 565 566 567 Clearly the key used for the authentication should not be trusted to 568 belong to the session originator unless it has been separately 569 authenticated by some other means, such as being certified by a 570 trusted third party. Such certificates are not normally included in 571 an SAP header because they take more space than can normally be 572 afforded in an SAP packet, and such verification must therefore take 573 place by some other mechanism. However, as certified public keys are 574 normally locally cached, authentication of a particular key only has 575 to take place once, rather than every time the session directory 576 retransmits the announcement. 577 578 SAP is not tied to any single authentication mechanism. 579 Authentication data in the header is self-describing, but the precise 580 format depends on the authentication mechanism in use. The generic 581 format of the authentication data is given in figure 2. The 582 structure of the format specific authentication subheader, using both 583 the PGP and the CMS formats, is discussed in sections 8.1 and 8.2 584 respectively. Additional formats may be added in future. 585 586 Version Number, V: The version number of the authentication format 587 specified by this memo is 1. 588 589 Padding Bit, P: If necessary the authentication data is padded to be 590 a multiple of 32 bits and the padding bit is set. In this case 591 the last byte of the authentication data contains the number of 592 padding bytes (including the last byte) that must be discarded. 593 594 Authentication Type, Auth: The authentication type is a 4 bit 595 encoded field that denotes the authentication infrastructure the 596 sender expects the recipients to use to check the authenticity and 597 integrity of the information. This defines the format of the 598 authentication subheader and can take the values: 0 = PGP format, 599 1 = CMS format. All other values are undefined and SHOULD be 600 ignored. 601 602 If a SAP packet is to be compressed or encrypted, this MUST be done 603 before the authentication is added. 604 605 The digital signature in the authentication data MUST be calculated 606 over the entire packet, including the header. The authentication 607 length MUST be set to zero and the authentication data excluded when 608 calculating the digital signature. 609 610 It is to be expected that sessions may be announced by a number of 611 different mechanisms, not only SAP. For example, a session 612 description may placed on a web page, sent by email or conveyed in a 613 614 615 616 617 618Handley, et al. Experimental [Page 11] 619 620RFC 2974 Session Announcement Protocol October 2000 621 622 623 session initiation protocol. To ease interoperability with these 624 other mechanisms, application level security is employed, rather than 625 using IPsec authentication headers. 626 6278.1 PGP Authentication 628 629 A full description of the PGP protocol can be found in [2]. When 630 using PGP for SAP authentication the basic format specific 631 authentication subheader comprises a digital signature packet as 632 described in [2]. The signature type MUST be 0x01 which means the 633 signature is that of a canonical text document. 634 6358.2 CMS Authentication 636 637 A full description of the Cryptographic Message Syntax can be found 638 in [6]. The format specific authentication subheader will, in the 639 CMS case, have an ASN.1 ContentInfo type with the ContentType being 640 signedData. 641 642 Use is made of the option available in PKCS#7 to leave the content 643 itself blank as the content which is signed is already present in the 644 packet. Inclusion of it within the SignedData type would duplicate 645 this data and increase the packet length unnecessarily. In addition 646 this allows recipients with either no interest in the authentication, 647 or with no mechanism for checking it, to more easily skip the 648 authentication information. 649 650 There SHOULD be only one signerInfo and related fields corresponding 651 to the originator of the SAP announcement. The signingTime SHOULD be 652 present as a signedAttribute. However, due to the strict size 653 limitations on the size of SAP packets, certificates and CRLs SHOULD 654 NOT be included in the signedData structure. It is expected that 655 users of the protocol will have other methods for certificate and CRL 656 distribution. 657 6589 Scalability and caching 659 660 SAP is intended to announce the existence of long-lived wide-area 661 multicast sessions. It is not an especially timely protocol: 662 sessions are announced by periodic multicast with a repeat rate on 663 the order of tens of minutes, and no enhanced reliability over UDP. 664 This leads to a long startup delay before a complete set of 665 announcements is heard by a listener. This delay is clearly 666 undesirable for interactive browsing of announced sessions. 667 668 In order to reduce the delays inherent in SAP, it is recommended that 669 proxy caches are deployed. A SAP proxy cache is expected to listen 670 to all SAP groups in its scope, and to maintain an up-to-date list of 671 672 673 674Handley, et al. Experimental [Page 12] 675 676RFC 2974 Session Announcement Protocol October 2000 677 678 679 all announced sessions along with the time each announcement was last 680 received. When a new SAP listeners starts, it should contact its 681 local proxy to download this information, which is then sufficient 682 for it to process future announcements directly, as if it has been 683 continually listening. 684 685 The protocol by which a SAP listener contacts its local proxy cache 686 is not specified here. 687 68810 Security Considerations 689 690 SAP contains mechanisms for ensuring integrity of session 691 announcements, for authenticating the origin of an announcement and 692 for encrypting such announcements (sections 7 and 8). 693 694 As stated in section 5, if a session modification announcement is 695 received that contains a valid authentication header, but which is 696 not signed by the original creator of the session, then the session 697 must be treated as a new session in addition to the original session 698 with the same SDP origin information unless the originator of one of 699 the session descriptions can be authenticated using a certificate 700 signed by a trusted third party. If this were not done, there would 701 be a possible denial of service attack whereby a party listens for 702 new announcements, strips off the original authentication header, 703 modifies the session description, adds a new authentication header 704 and re-announces the session. If a rule was imposed that such spoof 705 announcements were ignored, then if packet loss or late starting of a 706 session directory instance caused the original announcement to fail 707 to arrive at a site, but the spoof announcement did so, this would 708 then prevent the original announcement from being accepted at that 709 site. 710 711 A similar denial-of-service attack is possible if a session 712 announcement receiver relies completely on the originating source and 713 hash fields to indicate change, and fails to parse the remainder of 714 announcements for which it has seen the origin/hash combination 715 before. 716 717 A denial of service attack is possible from a malicious site close to 718 a legitimate site which is making a session announcement. This can 719 happen if the malicious site floods the legitimate site with huge 720 numbers of (illegal) low TTL announcements describing high TTL 721 sessions. This may reduce the session announcement rate of the 722 legitimate announcement to below a tenth of the rate expected at 723 remote sites and therefore cause the session to time out. Such an 724 attack is likely to be easily detectable, and we do not provide any 725 mechanism here to prevent it. 726 727 728 729 730Handley, et al. Experimental [Page 13] 731 732RFC 2974 Session Announcement Protocol October 2000 733 734 735A. Summary of differences between SAPv0 and SAPv1 736 737 For this purpose SAPv0 is defined as the protocol in use by version 738 2.2 of the session directory tool, sdr. SAPv1 is the protocol 739 described in the 19 November 1996 version of this memo. The packet 740 headers of SAP messages are the same in V0 and V1 in that a V1 tool 741 can parse a V0 announcement header but not vice-versa. In SAPv0, the 742 fields have the following values: 743 744 o Version Number: 0 745 746 o Message Type: 0 (Announcement) 747 748 o Authentication Type: 0 (No Authentication) 749 750 o Encryption Bit: 0 (No Encryption) 751 752 o Compression Bit: 0 (No compression) 753 754 o Message Id Hash: 0 (No Hash Specified) 755 756 o Originating Source: 0 (No source specified, announcement has 757 not been relayed) 758 759B. Summary of differences between SAPv1 and SAPv2 760 761 The packet headers of SAP messages are the same in V1 and V2 in that 762 a V2 tool can parse a V1 announcement header but not necessarily 763 vice-versa. 764 765 o The A bit has been added to the SAP header, replacing one of the 766 bits of the SAPv1 message type field. If set to zero the 767 announcement is of an IPv4 session, and the packet is backwards 768 compatible with SAPv1. If set to one the announcement is of an 769 IPv6 session, and SAPv1 listeners (which do not support IPv6) will 770 see this as an illegal message type (MT) field. 771 772 o The second bit of the message type field in SAPv1 has been 773 replaced by a reserved, must-be-zero, bit. This bit was unused in 774 SAPv1, so this change just codifies existing usage. 775 776 o SAPv1 specified encryption of the payload. SAPv2 includes the E 777 bit in the SAP header to indicate that the payload is encrypted, 778 but does not specify any details of the encryption. 779 780 o SAPv1 allowed the message identifier hash and originating source 781 fields to be set to zero, for backwards compatibility. This is no 782 longer legal. 783 784 785 786Handley, et al. Experimental [Page 14] 787 788RFC 2974 Session Announcement Protocol October 2000 789 790 791 o SAPv1 specified gzip compression. SAPv2 uses zlib (the only known 792 implementation of SAP compression used zlib, and gzip compression 793 was a mistake). 794 795 o SAPv2 provides a more complete specification for authentication. 796 797 o SAPv2 allows for non-SDP payloads to be transported. SAPv1 798 required that the payload was SDP. 799 800 o SAPv1 included a timeout field for encrypted announcement, SAPv2 801 does not (and relies of explicit deletion messages or implicit 802 timeouts). 803 804C. Acknowledgements 805 806 SAP and SDP were originally based on the protocol used by the sd 807 session directory from Van Jacobson at LBNL. Version 1 of SAP was 808 designed by Mark Handley as part of the European Commission MICE 809 (Esprit 7602) and MERCI (Telematics 1007) projects. Version 2 810 includes authentication features developed by Edmund Whelan, Goli 811 Montasser-Kohsari and Peter Kirstein as part of the European 812 Commission ICE-TEL project (Telematics 1005), and support for IPv6 813 developed by Maryann P. Maher and Colin Perkins. 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842Handley, et al. Experimental [Page 15] 843 844RFC 2974 Session Announcement Protocol October 2000 845 846 847D. Authors' Addresses 848 849 Mark Handley 850 AT&T Center for Internet Research at ICSI, 851 International Computer Science Institute, 852 1947 Center Street, Suite 600, 853 Berkeley, CA 94704, USA 854 855 EMail: mjh@aciri.org 856 857 858 Colin Perkins 859 USC Information Sciences Institute 860 4350 N. Fairfax Drive, Suite 620 861 Arlington, VA 22203, USA 862 863 EMail: csp@isi.edu 864 865 866 Edmund Whelan 867 Department of Computer Science, 868 University College London, 869 Gower Street, 870 London, WC1E 6BT, UK 871 872 EMail: e.whelan@cs.ucl.ac.uk 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898Handley, et al. Experimental [Page 16] 899 900RFC 2974 Session Announcement Protocol October 2000 901 902 903References 904 905 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 906 levels", BCP 14, RFC 2119, March 1997. 907 908 [2] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer. "OpenPGP 909 message format", RFC 2440, November 1998. 910 911 [3] Deutsch, P. and J.-L. Gailly, "Zlib compressed data format 912 specification version 3.3", RFC 1950, May 1996. 913 914 [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", 915 RFC 2327, April 1998. 916 917 [5] Handley, M., Thaler, D. and R. Kermode, "Multicast-scope zone 918 announcement protocol (MZAP)", RFC 2776, February 2000. 919 920 [6] Housley, R., "Cryptographic message syntax", RFC 2630, June 1999. 921 922 [7] Mayer, D., "Administratively scoped IP multicast", RFC 2365, July 923 1998. 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954Handley, et al. Experimental [Page 17] 955 956RFC 2974 Session Announcement Protocol October 2000 957 958 959Full Copyright Statement 960 961 Copyright (C) The Internet Society (2000). All Rights Reserved. 962 963 This document and translations of it may be copied and furnished to 964 others, and derivative works that comment on or otherwise explain it 965 or assist in its implementation may be prepared, copied, published 966 and distributed, in whole or in part, without restriction of any 967 kind, provided that the above copyright notice and this paragraph are 968 included on all such copies and derivative works. However, this 969 document itself may not be modified in any way, such as by removing 970 the copyright notice or references to the Internet Society or other 971 Internet organizations, except as needed for the purpose of 972 developing Internet standards in which case the procedures for 973 copyrights defined in the Internet Standards process must be 974 followed, or as required to translate it into languages other than 975 English. 976 977 The limited permissions granted above are perpetual and will not be 978 revoked by the Internet Society or its successors or assigns. 979 980 This document and the information contained herein is provided on an 981 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 982 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 983 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 984 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 985 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 986 987Acknowledgement 988 989 Funding for the RFC Editor function is currently provided by the 990 Internet Society. 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010Handley, et al. Experimental [Page 18] 1011 1012