home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mmusic-sap-00.txt < prev    next >
Text File  |  1996-11-27  |  32KB  |  788 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8. Internet Engineering Task Force                      MMUSIC WG
  9. INTERNET-DRAFT                               Mark Handley
  10. draft-ietf-mmusic-sap-00.txt                        ISI
  11.                                   19th Nov 1996
  12.  
  13.  
  14.            SAP: Session Announcement Protocol
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.  
  20. This document is an Internet-Draft.  Internet-Drafts are  working  docu-
  21. ments  of the Internet Engineering Task Force (IETF), its areas, and its
  22. working groups.     Note that other  groups  may  also  distribute     working
  23. documents as Internet-Drafts.
  24.  
  25. Internet-Drafts are draft documents valid for a maximum     of  six  months
  26. and  may  be  updated,    replaced, or obsoleted by other documents at any
  27. time.  It is inappropriate to use Internet-Drafts as reference    material
  28. or to cite them other than as ``work in progress.''
  29.  
  30. To learn the current status of    any  Internet-Draft,  please  check  the
  31. ``1id-abstracts.txt''  listing    contained  in the Internet-Drafts Shadow
  32. Directories   on   ftp.is.co.za      (Africa),   nic.nordu.net    (Europe),
  33. munnari.oz.au    (Pacific  Rim),     ds.internic.net  (US  East  Coast),  or
  34. ftp.isi.edu (US West Coast).
  35.  
  36. Distribution of this document is unlimited.
  37.  
  38.  
  39.                 Abstract
  40.  
  41.  
  42.      This document  describes  the  SAP     -  the     session  directory
  43.      announcement  protocol, and the related issues affecting secu-
  44.      rity and scalability that should be taken into account by    the
  45.      implementors  of  session    directory tools.  It is a companion
  46.      document to draft-ietf-mmusic-sdp.
  47.  
  48.  
  49. This document is a product of the Multiparty Multimedia Session     Control
  50. (MMUSIC) working group of the Internet Engineering Task Force.    Comments
  51. are solicited and should be addressed to  the  working    group's     mailing
  52. list at confctrl@isi.edu and/or the author.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Handley                                    [Page 1]
  59.  
  60. INTERNET-DRAFT                           18th Nov 1996
  61.  
  62.  
  63. 1.  Introduction
  64.  
  65. An mbone session directory is used to advertise multimedia  conferences,
  66. and  to communicate the session addresses (whether multicast or unicast)
  67. and conference-tool-specific information  necessary  for  participation.
  68. Such sessions are described using the Session Description Protocol (SDP)
  69. which is described in a companion draft.  This    document  describes  the
  70. issues    involved  in  the  multicast announcement of session description
  71. packets and defines a packet format to    be  used  by  session  directory
  72. clients.   SAP    v0  is currently implemented in Sdr and other compatible
  73. tools.    This document describes SAP v1, which contains some enhancements
  74. to the basic announcement model.  The differences between SAP v1 and SAP
  75. v0 are described in Appendix A.     Much of this document is concerned with
  76. security  considerations  -  these  security considerations have not yet
  77. been subject to suitable peer-review, and this document     should     not  be
  78. considered authoritative in this area.
  79.  
  80. 2.  Background
  81.  
  82. IP Multicast is an extension of internet routing that permits  efficient
  83. many-to-many  communication.  It is used extensively for multimedia con-
  84. ferencing.  Such multimedia sessions  usually  have  the  property  that
  85. tight  coordination  of session membership is not necessary; in order to
  86. receive a session, a user at a multicast-capable site only has    to  know
  87. the  correct  multicast     group address for the session and the transport
  88. ports the conferencing applications will use to receive     the  conference
  89. data streams.
  90.  
  91. In order to assist the advertisement of multicast sessions and    to  com-
  92. municate  the relevant session setup information to prospective partici-
  93. pants, a distributed session directory is used.     An instance of     such  a
  94. session     directory periodically multicasts packets containing a descrip-
  95. tion of a multimedia session, and these advertisements are  received  by
  96. potential  participants who can use the session description to start the
  97. tools required to participate  in  the    session.   The    companion  draft
  98. ``SDP:    Session     Description Protocol'' describes a payload format suit-
  99. able for such session descriptions.  This draft describes the  distribu-
  100. tion mechanism and packet format.
  101.  
  102.  
  103. 3.  The SAP Protocol
  104.  
  105. SAP is an announcement protocol for multicast conference  sessions.   An
  106. SAP  client  that announces a conference session periodically multicasts
  107. an announcement packet to a well known multicast address and port.   The
  108. announcement  is  multicast  with  the    same  scope (as defined by group
  109. address range or TTL) as the session it     is  announcing.   This     ensures
  110. that the recipients of the announcement can also be potential recipients
  111.  
  112.  
  113.  
  114. Handley                                    [Page 2]
  115.  
  116. INTERNET-DRAFT                           18th Nov 1996
  117.  
  118.  
  119. of the session the announcement describes (bandwidth and other such con-
  120. straints permitting).  This is also important for the scalability of the
  121. protocol, as it keeps local session announcements local.
  122.  
  123. The time period between one announcement and its repetition is dependent
  124. on two factors - the scope (TTL) of the session, and the number of other
  125. sessions currently being announced by other session  directory    clients.
  126. The  goal  is  to keep the total bandwidth being used below a predefined
  127. level for each scope.
  128.  
  129.  
  130. Session Announcement
  131.  
  132. A session to be announced is simply multicast to the  appropriate  well-
  133. known  multicast  address  and port. The announcement contains a session
  134. description and, optionally,  an  authentication  header.   The     session
  135. description may be encrypted.
  136.  
  137. Session Deletion
  138.  
  139. Sessions may be deleted in one of several ways:
  140.  
  141. Explicit Timeout
  142.     The session description contains timestamp information which  speci-
  143.     fies  a  start and end time for the session.  If the current time is
  144.     later than the end-time for the session, then the session is deleted
  145.     from  the  receiver's  session  cache.   If     an  announcement packet
  146.     arrives with an end-time before the current time, it is ignored.
  147.  
  148. Implicit Timeout
  149.     A session announcement message should be received  periodically  for
  150.     each  session  description    in  a  receiver's  session  cache.   The
  151.     announcement period can be predicted by the receiver from the set of
  152.     sessions  currently being announced.  If a session announcement mes-
  153.     sage has not been received for ten times the announcement period, or
  154.     half  an hour, whichever is the greater, then the session is deleted
  155.     from the receiver's session cache.    The  half  hour     minimum  is  to
  156.     allow for transient network partitionings.
  157.  
  158. Explicit Deletion
  159.     A session deletion packet is received specifying the version of  the
  160.     session to be deleted. If the cached session contains an authentica-
  161.     tion header, the session deletion packet must  contain  a  signature
  162.     signed  by    the same key.  If the cached session does not contain an
  163.     authentication header, but the deletion  packet  has  the  same  IP-
  164.     source  address (not the SAP-stated source address in the packet) as
  165.     that from which the session announcement was  originally  announced,
  166.     then  the  session    is deleted.    If neither of these conditions is
  167.  
  168.  
  169.  
  170. Handley                                    [Page 3]
  171.  
  172. INTERNET-DRAFT                           18th Nov 1996
  173.  
  174.  
  175.     not the case, then the session deletion  packet  is     ignored.   Note
  176.     that IP source addresses can be spoofed, and although the RPF filter
  177.     in most multicast routing algorithms will result in the  packet  not
  178.     being  delivered  in  some cases, this is insufficient protection in
  179.     many cases, and an authentication header should  be     used  for  such
  180.     situations.
  181.  
  182. Session Modification
  183.  
  184. A pre-announced session can be modified by simply announcing  the  modi-
  185. fied  session  description.   In  this case, the version hash in the SAP
  186. header should be changed to indicate to receivers that the  packet  con-
  187. tents  should  be  parsed  (or decrypted and parsed if it is encrypted).
  188. The session itself is uniquely identified by the SDP origin field in the
  189. payload, and not by the version hash in the SAP header.
  190.  
  191. The same rules apply for session modification as for session deletion:
  192.  
  193. +   Either the modified     announcement  must  contain  an  authentication
  194.     header  signed by the same key as the cached session announcement it
  195.     is modifying, or:
  196.  
  197. +   The cached session announcement must not contain  an  authentication
  198.     header,  and  the  session    modification announcement must originate
  199.     from the same host as the session it is modifying.
  200.  
  201. If an announcement is received containing a  authentication  header  and
  202. the  cached announcement did not contain an authentication header, or it
  203. contained  an  different  authentication  header,  then      the    modified
  204. announcement  must  be    treated as a new and different announcement, and
  205. displayed in addition to the un-authenticated  announcement.   The  same
  206. should    happen    if a modified packet without an authentication header is
  207. received from a different source than the original announcement.   These
  208. rules prevent an announcement having an authentication header added by a
  209. malicious user and then being deleted using that  header,  and    it  also
  210. prevents  a  denial-of-service    attack    by  someone  putting out a spoof
  211. announcement which, due to packet loss, reaches some participants before
  212. the  original  announcement.   Note that under such circumstances, being
  213. able to authenticate the message originator is the only way to    discover
  214. which session is the correct session.
  215.  
  216. 4.  Packet Format
  217.  
  218. Unencrypted SAP data packets are of the following format:
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Handley                                    [Page 4]
  227.  
  228. INTERNET-DRAFT                           18th Nov 1996
  229.  
  230.  
  231.  
  232.  
  233.  0             1             2             3
  234.  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
  235. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236. | V=1 | MT  |E|C|   auth len    |     msg id hash        |
  237. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238. |              orig source                |
  239. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  240. |         optional authentication header            |
  241. |                  ....                |
  242. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  243. |              text payload                |
  244. |                  ....                |
  245. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  246.  
  247.  
  248.  
  249. Encrypted SAP data packets contain additional fields
  250.  
  251.  
  252.  0             1             2             3
  253.  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
  254. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  255. | V=1 | MT  |E|C|   auth len    |     msg id hash        |
  256. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  257. |              orig source                |
  258. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  259. |         optional authentication header            |
  260. |                  ....                |
  261. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  262. |                  key id                |
  263. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  264. |                 timeout                |
  265. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  266. |P|               random field                |
  267. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  268. |              text payload                |
  269. |                  ....                |
  270. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  271.  
  272. Only fields from * onwards are encrypted.
  273.  
  274. V: Version Number
  275.  
  276. SAP version number = 1
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Handley                                    [Page 5]
  283.  
  284. INTERNET-DRAFT                           18th Nov 1996
  285.  
  286.  
  287. MT: Message Type
  288.  
  289. One of the following:
  290.  
  291. 0   Session description announcement packet.  The text payload is an SDP
  292.     session description, as described in draft-ietf-mmusic-sdp.
  293.  
  294. 1   Session description deletion packet.  The text payload is  a  single
  295.     SDP     line  consisting  of the origin field of the announcement to be
  296.     deleted.
  297.  
  298. E - Encryption Bit
  299.  
  300. If the encryption bit is set, the text payload    of  the     SAP  packet  is
  301. encrypted,  and     additional  fields  are  added     to  the packet: Key-ID,
  302. Timeout, P (padding) and Random.  The Key-ID and Timeout fields are  not
  303. encrypted, but the P and Random fields are encrypted along with the text
  304. payload.  Note the encryption algorithm is not specified in the packet -
  305. this  is  communicated to permitted receivers out-of-band along with the
  306. corresponding decryption key.
  307.  
  308.  
  309. C - Compressed bit
  310.  
  311. This bit indicates that     the  payload  was  compressed    using  the  gzip
  312. compression algorithm [3].
  313.  
  314. Authentication Length:
  315.  
  316. A 8 bit unsigned quantity giving the number of 32  bit    words  following
  317. the  main SAP header that contain authentication data (and padding bytes
  318. if present).  If it is zero, no authentication header is present.
  319.  
  320.  
  321. Authentication Header
  322.  
  323. This contains a digital signature (encrypted cryptographic hash) of  the
  324. text  payload  (including key-id, expiry timestamp, and encrypted random
  325. field and text payload if the payload is encrypted) from the end of  the
  326. authentication    header    onwards.   It  also contains the public key with
  327. which the authentication header can be checked, and information to iden-
  328. tify  the  encryption  algorithm  and mode used.  It can be used for two
  329. purposes:
  330.  
  331. +   Verification that changes to a session description or deletion of  a
  332.     session are permitted.
  333.  
  334. +   Authentication of the identity of the session creator.
  335.  
  336.  
  337.  
  338. Handley                                    [Page 6]
  339.  
  340. INTERNET-DRAFT                           18th Nov 1996
  341.  
  342.  
  343. In some circumstances only Verification is possible because  a    certifi-
  344. cate  signed by a mutually trusted person or authority is not available.
  345. However, under such circumstances, the session originator may  still  be
  346. authenticated  to be the same as the session originator of previous ses-
  347. sions claiming to be from the same person.  This may or may not be  suf-
  348. ficient depending on the purpose of the session and the people involved.
  349.  
  350. Clearly the key given in the authentication header should not be trusted
  351. to  belong  to    the  session  originator  unless  it has been separately
  352. authenticated by some other means, such as being certified by a     trusted
  353. third  party.    Such  certificates  are     not normally included in an SAP
  354. header because they take more space than can normally be afforded in  an
  355. SAP  packet,  and  such     verification  must therefore take place by some
  356. other mechanism.  However, as certified public keys are normally locally
  357. cached,     authentication of a particular key only has to take place once,
  358. rather than every time the session directory retransmits  the  announce-
  359. ment.
  360.  
  361. SAP is not tied to any single authentication mechanism.      Authentication
  362. Headers must be self-describing, but their precise format depends on the
  363. authentication mechanism (signature and encryption scheme) in  use,  and
  364. so is not defined here.
  365.  
  366.  
  367. Message Identifier Hash
  368.  
  369. A 16 bit quantity that, used in combination with the originating source,
  370. provides  a  globally  unique id identifying the precise version of this
  371. announcement.  The message id hash should be changed if any field of the
  372. session     description  is changed.  A value of zero means the hash should
  373. be ignored and the message should always be parsed.
  374.  
  375. Originating Source
  376.  
  377. This gives the IP address of the original source of the message.  It  is
  378. permissible  to     be  zero  if the message has not passed through a proxy
  379. relay and if the message id hash is also zero, though this  is    intended
  380. only for backwards compatibility with SAPv0 clients.
  381.  
  382. Key ID
  383.  
  384. The key identifier is a 32 bit network byte-order integer which is  used
  385. as a hint to identify which encryption key was used to encrypt a packet.
  386. Key id's should be randomly generated  when  a    new  encryption     key  is
  387. chosen    for  a group of users, and so they are not guaranteed to be glo-
  388. bally unique.  If a receiver has multiple keys with the same key-id,  to
  389. perform     decryption each key in turn must be used until one of them suc-
  390. cessfully decrypts the data.
  391.  
  392.  
  393.  
  394. Handley                                    [Page 7]
  395.  
  396. INTERNET-DRAFT                           18th Nov 1996
  397.  
  398.  
  399. Timeout
  400.  
  401. When the session payload is encrypted, and the    session     description  is
  402. being  relayed    or  announced via a proxy, the detailed timing fields in
  403. the SDP description are not available to the proxy as they are encrypted
  404. and  the  proxy is not trusted with the decryption key.     Under such cir-
  405. cumstances, SAP includes an additional 32-bit  timestamp  field     stating
  406. when  the session should be timed out.    This field is included after the
  407. authentication header, and the digital signature in  the  authentication
  408. header    encompasses  the timeout so that a session cannot be maliciously
  409. deleted by modifying its timeout in an announcing proxy.
  410.  
  411. The value is an unsigned quantity giving the NTP time [2] in seconds  at
  412. which time the session is timed out.  It is in network byte order.
  413.  
  414.  
  415. P: Encryption Padding
  416.  
  417. This bit indicates that the payload was padded prior to encryption.  The
  418. last byte of the decrypted payload indicates how many padding bytes were
  419. added.
  420.  
  421. Random
  422.  
  423. This field is only  present  when  the    payload     is  encrypted.      It  is
  424. encrypted  along with the payload, and is used to perform the randomiza-
  425. tion task normally performed by an initialization vector  in  algorithms
  426. such  as  cipher-block    chained DES.  This 31 bit field should contain a
  427. genuinely random number.  After decryption, this field is discarded.
  428.  
  429. 5.  Encrypted Announcements
  430.  
  431. Announcements may be encrypted using any encryption algorithm  or  mode.
  432. However,  the  use  of DES in cipher-block chaining (CBC) mode is recom-
  433. mended as the default case.  The choice of encryption algorithm and mode
  434. is conveyed to potential recipients along with the encryption key itself
  435. and a 32 bit key identifier which should be randomly chosen and is  used
  436. as a non-globally-unique identifier for the key.
  437.  
  438. In normal usage, a {decryption-key,keyid,algorithm,mode} tuple    will  be
  439. conveyed  in  advance  to  the    intended group recipients.  This process
  440. takes place out-of-band and is not described in this draft.  However, if
  441. keys  are  to be communicated as plain text, the use of MD5 as described
  442. in [4] is recommended to manipulate the key prior to use.
  443.  
  444. Session announcements may  then     be  made  to  the  appropriate     session
  445. announcement  address,    encrypted so that they can be decrypted with the
  446. group key.  The key-id is  carried  in    the  announcement  packets,  and
  447.  
  448.  
  449.  
  450. Handley                                    [Page 8]
  451.  
  452. INTERNET-DRAFT                           18th Nov 1996
  453.  
  454.  
  455. serves as an index into a sparse key-ring at each receiver.  As key-id's
  456. are allocated randomly, in some cases more than one  decryption-key  may
  457. be  identified by the same key id - this is expected to be a rare event,
  458. but may happen.     When more that one key is identified by a key-id,  each
  459. of the decryption keys in turn must be tried.
  460.  
  461. 5.1.  Encrypting Announcements
  462.  
  463. If the payload is to be     compressed,  this  is    performed  first  before
  464. encryption or padding.
  465.  
  466. When an announcement is to be encrypted, a 32-bit word is  prepended  to
  467. the  session  description  payload.   The  most     significant bit of this
  468. number (in network byte order) is set to zero if the session description
  469. does  not  require  padding for encryption, and set to one if padding is
  470. required for encryption, in which case the last byte of the padded  ses-
  471. sion  description contains the number of padding bytes added.  The least
  472. significant 31 bits of this 32 bit quantity should contain random data.
  473.  
  474. The padded and 32-bit pre-pended session description is     then  encrypted
  475. using  the  relevant  encryption algorithm, key and mode.  The encrypted
  476. payload is then sent with an extended SAP header which has the E bit set
  477. and contains the key id and timeout fields as described above.
  478.  
  479. 5.2.  Decrypting Announcements
  480.  
  481. Upon receiving a  new  announcement  with  the    encryption  bit     set,  a
  482. receiver should attempt to decrypt the announcement with each of its set
  483. of session  decryption    keys  that  has     the  key-id  appearing     in  the
  484. announcement.    If  it    succeeds,  then     the session is displayed to the
  485. user.  If it has no key that matches the announcement  key-id,    or  does
  486. not  succeed  with any key that does match, then the session is ignored.
  487. If one of more keys did match the key-id, but decryption failed with all
  488. of  these matching keys, then the version hash, original source and key-
  489. id are cached to avoid having to attempt to  decrypt  this  announcement
  490. every  time  it is received in future.    To avoid possible denial of ser-
  491. vice  attacks,    such  incoming    announcements  should  occasionally   be
  492. attempted  to  be  decrypted  on  a random basis as available processing
  493. power allows.  This cache can be  safely  timed     out  when  the     timeout
  494. specified in encrypted packets expires.
  495.  
  496. Note that if an encrypted announcement is being announced via  a  proxy,
  497. then there may be no way for the proxy to discover that the announcement
  498. has been superseded, and so it may continue to relay the  old  announce-
  499. ment  in addition to the new announcement.  SAP provides no mechanism to
  500. chain modified encrypted announcements, so it is advisable  to    announce
  501. the  unmodified     session as deleted for a short time after the modifica-
  502. tion has occurred.  This  does    not  guarantee    that  all  proxies  have
  503.  
  504.  
  505.  
  506. Handley                                    [Page 9]
  507.  
  508. INTERNET-DRAFT                           18th Nov 1996
  509.  
  510.  
  511. deleted     the  session,    and so receivers of encrypted sessions should be
  512. prepared to discard old versions of session announcements that they  may
  513. receive     (as  identified  by the SDP version field).  In most cases how-
  514. ever, the only stateful proxy will  be    local  to  (and     known    to)  the
  515. sender,     and  an  additional (local-area) protocol involving a handshake
  516. for such session modifications can be used to avoid this problem.
  517.  
  518.  
  519. 6.  SDP announcement by periodic multicast.
  520.  
  521. SAP announces  multicast  sessions  by    periodic  multicast  of     session
  522. descriptions  to  an  appropriate well known multicast address and port.
  523. The appropriate address is determined by the scope mechanisms  in  force
  524. at the sites of the intended participants.  IP multicast sessions can be
  525. either TTL-scoped or administratively scoped.    One  well-known     address
  526. and port is used for all TTL-scoped announcements, and additionally, one
  527. well-known address (within the corresponding scope  zone)  and    port  is
  528. used  for each administrative scope zone that an instance of the session
  529. directory is within. Thus an instance of the  session  directory  should
  530. listen    on multiple multicast addresses, but should normally only send a
  531. particular announcement to the single multicast address corresponding to
  532. the  scope of the session being described.  The discovery of administra-
  533. tive scope zones and the appropriate announcement address for each  zone
  534. are  outside  the  scope  of  this  draft,  but     it is assumed that each
  535. instance of the session directory within  a  particular     scope    zone  is
  536. aware of that scope zone, and of the corresponding announcement address,
  537. port, TTL, and session address allocation range.
  538.  
  539.  
  540. TTL Scoped Announcement
  541.  
  542. The well-known address is 224.2.127.254 and the UDP port is  9875.   The
  543. session     announcements    should be multicast with the same TTL with which
  544. the conference session will be multicast. If the different media  in  an
  545. announcement  are  given different TTLs, then multiple announcements are
  546. necessary to ensure that anyone     joining  the  conference  can    in  fact
  547. receive     data  for  each  media     started.   For     example,  if we have an
  548. announcement to make containing audio at TTL 127 and video  at    TTL  63,
  549. then  we  make    an  announcement  at TTL 63 containing both media, and a
  550. separate announcement at TTL 127 containing only the audio.  It is up to
  551. the  receiving session directory to parse both announcements as the same
  552. announcement (as identified by the SDP origin field) if it is within the
  553. appropriate  scope to get both announcements.  If multiple announcements
  554. are being made for the same session in this way, then each  announcement
  555. must  carry  an     authentication     header     signed     by  the same key, or be
  556. treated as a completely separate announcement.
  557.  
  558. The time period between one announcement and its repetition is dependent
  559.  
  560.  
  561.  
  562. Handley                                       [Page 10]
  563.  
  564. INTERNET-DRAFT                           18th Nov 1996
  565.  
  566.  
  567. on two factors - the scope (TTL) of the session, and the number of other
  568. sessions currently being announced by other session directory instances.
  569.  
  570. The recommended bandwidth limits for each TTL are:
  571.  
  572.         TTL    bandwidth
  573.         1-15     2Kbps
  574.         16-63     1Kbps
  575.         64-127     1Kbps
  576.         128-255 200bps
  577.  
  578. Session announcers in the same scope band can normally    be  expected  to
  579. hear  your announcements, and reduce their data rates accordingly.  Thus
  580. you should calculate the available bandwidth for  your    session's  scope
  581. band  by  dividing  the     appropriate  limit above by the number of other
  582. announcers in your scope band.    This gives you    your  bandwidth     alloca-
  583. tion,  which, given the size of your data packets, can be used to derive
  584. the base interval for announcements.
  585.  
  586. I.e., given a limit in bits/second (as above) and a  ad_size  in  bytes,
  587. the base announcement interval in seconds is:
  588.  
  589.      interval =MAX(300, (8*no_of_ads*ad_size)/limit)
  590.  
  591. For every interval between announcement packets     (i.e,    every  time  you
  592. send  a packet), you must add a random value (+/- 1/3 of the base inter-
  593. val) to the value used for  the     inter-announcement  period  to     prevent
  594. announcement  synchronisation.     It is also important to keep monitoring
  595. other announcements and adjust the base interval accordingly.
  596.  
  597. There is possibility to adjust the scope band limits depending    on  pro-
  598. perties of the sessions being announced, but this is left for future SAP
  599. drafts to specify.
  600.  
  601. Administrative Scoped Announcements
  602.  
  603. For each administrative scope  zone  in     force    at  a  particular  site,
  604. instances of the session directory running at that site need to know the
  605. following information:
  606.  
  607. +   The multicast address to be used for announcement.    The is    normally
  608.     the     highest  multicast address in the relevant administrative scope
  609.     zone.  For    example,  if  the   scope   range   is     239.16.32.0   -
  610.     239.16.33.255, then the convention is that 239.16.33.255 is used for
  611.     session announcements.
  612.  
  613. +   The UDP port to which announcements should be sent.
  614.  
  615.  
  616.  
  617.  
  618. Handley                                       [Page 11]
  619.  
  620. INTERNET-DRAFT                           18th Nov 1996
  621.  
  622.  
  623. +   The TTL announcements should be made with.     This  should  be  large
  624.     enough  to reach all sites in the admin scope zone, and will also be
  625.     the TTL used for sessions announced to be using this scope zone.
  626.  
  627. +   The address range to be used for sessions in this scope zone.   This
  628.     should  be    a  contiguous range, and currently should lie within the
  629.     range 239.0.0.0 to 239.255.255.255 (but this is defined by IANA, not
  630.     by this draft).
  631.  
  632. +   The total bandwidth to be used by the session directory for     session
  633.     announcements in this admin scope zone.  A recommended default value
  634.     for this is 500bps, but this may be inappropriate for some uses.
  635.  
  636. 7.  Security Considerations
  637.  
  638. SAP contains mechanisms for ensuring integrity of session announcements,
  639. for authenticating the origin of an announcement and for encrypting such
  640. announcements.    These mechanisms have not yet been subject  to    suitable
  641. peer-review, and this document should not be considered authoritative in
  642. this area at this time.
  643.  
  644. SAP contains mechanisms that are designed to prevent an announcement  by
  645. one  user  from     being    modified or deleted by another user, and also to
  646. provide limited privacy by use of encryption.
  647.  
  648. Session announcements that are encrypted with a symmetric algorithm  may
  649. allow  a  degree  of  privacy  in  the announcement of a session, but it
  650. should be recognised that a user in possession of such a key can pass it
  651. on  to    other users who should not be in possession of such a key.  Thus
  652. announcements to such a group of key holders cannot be assumed    to  have
  653. come  from  an    authorised  key     holder     unless     there is an appropriate
  654. authentication header signed by an authorised key holder.   In    addition
  655. the recipients of such encrypted announcements cannot be assumed to only
  656. be authorised key holders.  Such encrypted announcements do not     provide
  657. any  real  security unless all of the authorised key holders are trusted
  658. to maintain security of such session directory keys.  This  property  is
  659. shared    by  the multicast session tools themselves, where it is possible
  660. for an un-trustworthy member of the session to pass on    encryption  keys
  661. to  un-authorised  users.   However  it is likely that keys used for the
  662. session tools will be more short  lived     that  those  used  for     session
  663. directories.
  664.  
  665. Similar considerations    should    apply  when  session  announcements  are
  666. encrypted  with an assymetric algorithm, but then it is possible to res-
  667. trict the possessor(s) of the private key, so that  announcements  to  a
  668. key-holder  group  can not be made, even if one of the untrusted members
  669. of the group proves to be un-trustworthy.
  670.  
  671.  
  672.  
  673.  
  674. Handley                                       [Page 12]
  675.  
  676. INTERNET-DRAFT                           18th Nov 1996
  677.  
  678.  
  679. As stated above, if a session modification announcement is received that
  680. contains  a  valid authentication header, but which is not signed by the
  681. original creator of the session, then the session must be treated  as  a
  682. new session in addition to the original session with the same SDP origin
  683. information unless the originator of one of the session descriptions can
  684. be  authenticated  using  a certificate signed by a trusted third party.
  685. If this were not done, there would  be    a  possible  denial  of     service
  686. attack    whereby     a  party  listens for new announcements, strips off the
  687. original authentication header, modifies the session description, adds a
  688. new  authentication  header and re-announces the session.  If a rule was
  689. imposed that such spoof announcements were ignored, then if packet  loss
  690. or  late  starting  of    a session directory instance caused the original
  691. announcement to fail to arrive at a site, but the spoof announcement did
  692. so,  this  would  then    prevent     the  original    announcement  from being
  693. accepted at that site.
  694.  
  695. A similar denial-of-service attack is possible if a session announcement
  696. receiver  relies completely on the originating source and hash fields to
  697. indicate change, and fails to parse the remainder of  announcements  for
  698. which it has seen the origin/hash combination before.
  699.  
  700. A denial of service attack is possible from a malicious site close to  a
  701. legitimate site which is making a session announcement.     This can happen
  702. if the malicious site floods the legitimate site with  huge  numbers  of
  703. (illegal)  low TTL announcements describing high TTL sessions.    This may
  704. reduce the session announcement rate of the legitimate    announcement  to
  705. below  a  tenth of the rate expected at remote sites and therefore cause
  706. the session to time out.  Such an attack is likely to be easily     detect-
  707. able, and we do not provide any mechanism here to prevent it.
  708.  
  709.  
  710. Appendix A: Summary of differences between SAPv0 and SAPv1
  711.  
  712. For this purpose SAPv0 is defined as the protocol in use by version  2.2
  713. of  the     Sdr  session  description tool.  SAPv1 is the proposed protocol
  714. described in the document.  The packet headers of SAP messages    are  the
  715. same  in  V0 and V1 in that a V1 tool can parse a V0 announcement header
  716. but not vice-versa.
  717.  
  718. In SAPv0, the fields have the following values:
  719.  
  720. +   Version Number: 0
  721.  
  722. +   Message Type: 0 (Announcement)
  723.  
  724. +   Authentication Type: 0 (No Authentication)
  725.  
  726. +   Encryption Bit: 0 (No Encryption)
  727.  
  728.  
  729.  
  730. Handley                                       [Page 13]
  731.  
  732. INTERNET-DRAFT                           18th Nov 1996
  733.  
  734.  
  735. +   Compression Bit: 0 (No compression)
  736.  
  737. +   Message Id Hash: 0 (No Hash Specified)
  738.  
  739. +   Originating Source: 0 (No source  specified,  announcement    has  not
  740.     been relayed)
  741.  
  742.  
  743. Appendix B: Author's Address
  744.  
  745. Mark Handley
  746. Information Sciences Institute,
  747. University of Southern California,
  748. c/o MIT Laboratory for Computer Science,
  749. 545 Technology Square,
  750. Cambridge, MA 02139,
  751. United States
  752. electronic mail: mjh@isi.edu
  753.  
  754.  
  755.  
  756. Acknowledgments
  757.  
  758. SAP and SDP were originally based on the protocol used by the sd session
  759. directory  from     Van  Jacobson at LBNL.     The design of SAP was funded by
  760. the European Commission under the Esprit 7602 "MICE"  project,    and  the
  761. Telematics 1007 "MERCI" project.
  762.  
  763. References
  764.  
  765. [1] M.Handley,    V.  Jacobson,  ``SDP:  Session    Description  Protocol'',
  766. INTERNET-DRAFT, Nov 1996.
  767.  
  768. [2] D. Mills, ``Network Time Protocol version 2 specification and imple-
  769. mentation", RFC1119, 1st Sept 1989.
  770.  
  771. [3] P. Deutsch, ``GZIP file  format  specification  version  4.3'',  RFC
  772. 1952, May 1996.
  773.  
  774. [4] H. Schulzrinne, ``RTP Profile for Audio and Video  Conferences  with
  775. Minimal Control'', RFC 1890, January 1996
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Handley                                       [Page 14]
  787.  
  788.