Subject: Session Announcement Protocol Draft Draft

From: Mark Handley <[email-masked]>
Date: Mon, 17 Jun 96 22:53:09 +0100

In the last couple of months many people have asked me for details of
SDAP (now called SAP) and how sdr works.  I've delayed, partly because
there are too many issues that are still in flux, and partly because I
haven't found enough time to write much down, for which I apologise!

The following draft is not yet submitted as an internet draft - the
security issues in particular need qualified peer-review.  There is
some argument as to whether SAP should include an authentication
header, or whether this should be left to the IPSEC AH.  Personally I
believe the SAP authentication header performs a different task from
the IPSEC AH, but I would like to hear other people's views on this.

I have not implemented from this draft yet - sdr merely performs SAPv0
as described.  The local area (LA-SDAP) issues I discussed in previous
IETF's are ommited from this draft because they're still too
experimental - it only deals with the wide-area announcements.

As postscript version (which might be easier to read) is available
from http://www.cs.ucl.ac.uk/staff/M.Handley/sap.00.2.ps.gz

Mark

--------

Internet Engineering Task Force					  MMUSIC WG
INTERNET-DRAFT						       Mark Handley
draft-ietf-mmusic-sap-00.ps						UCL
							      3rd June 1996

       SAP: Session Announcement Protocol (Version 1) [draft 0.2]

Status of this Memo

This  document	is an Internet-Draft.  Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas,	and  its
working	groups.	 Note that other groups	may also distribute working doc-
uments as Internet-Drafts.

Internet-Drafts	are draft documents valid for a	maximum	 of  six  months
and  may  be  updated,	replaced, or obsoleted by other	documents at any
time.  It is inappropriate to use Internet-Drafts as reference	material
or to cite them	other than as ``work in	progress.''

To  learn  the	current	 status	 of any	Internet-Draft,	please check the
``1id-abstracts.txt'' listing contained	in  the	 Internet-Drafts  Shadow
Directories    on   ftp.is.co.za   (Africa),   nic.nordu.net   (Europe),
munnari.oz.au  (Pacific	 Rim),	ds.internic.net	 (US  East  Coast),   or
ftp.isi.edu (US	West Coast).

Distribution of	this document is unlimited.

				Abstract

     This  document  describes	the  SAP  -  the  session directory
     announcement protocol, and	the related issues affecting  secu-
     rity  and scalability that	should be taken	into account by	the
     implementors of session directory tools.  It  is  a  companion
     document to draft-ietf-mmusic-sdp.

This  document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task	Force.	Comments
are  solicited	and  should  be	addressed to the working group's mailing
list at	[email-masked] and/or	the author.

1.  Introduction

An mbone session directory is used to advertise	multimedia  conferences,
and  to	communicate the	session	addresses (whether multicast or	unicast)
and conference-tool-specific information  necessary  for  participation.
Such sessions are described using the Session Description Protocol (SDP)
which is described in a	companion draft.  This	document  describes  the

Handley								[Page 1]

INTERNET-DRAFT						  ??th June 1996

issues	involved  in  the  multicast announcement of session description
packets	and defines a packet format to	be  used  by  session  directory
clients.   SAP	v0  is currently implemented in	Sdr and	other compatible
tools.	This document describes	SAP v1,	which contains some enhancements
to the basic announcement model.  The differences between SAP v1 and SAP
v0 are described in Appendix A.	 Much of this document is concerned with
security  considerations  -  these  security considerations have not yet
been subject to	suitable peer-review, and this document	 should	 not  be
considered authoritative in this area.

2.  Background

IP  Multicast is an extension of internet routing that permits efficient
many-to-many communication.  It	is used	extensively for	multimedia  con-
ferencing.   Such  multimedia  sessions	 usually  have the property that
tight coordination of session membership is not	necessary; in  order  to
receive	 a  session, a user at a multicast-capable site	only has to know
the correct multicast group address for	the session  and  the  transport
ports  the  conferencing applications will use to receive the conference
data streams.

In order to assist the advertisement of	multicast sessions and to commu-
nicate	the  relevant  session setup information to prospective	partici-
pants, a distributed session directory is used.	 An instance of	 such  a
session	 directory periodically	multicasts packets containing a	descrip-
tion of	a multimedia session, and these	advertisements are  received  by
potential  participants	who can	use the	session	description to start the
tools required to participate  in  the	session.   The	companion  draft
``SDP:	Session	 Description Protocol''	describes a payload format suit-
able for such session descriptions.  This draft	describes the  distribu-
tion mechanism and packet format.

3.  The	SAP Protocol

SAP  is	 an announcement protocol for multicast	conference sessions.  An
SAP client that	announces a conference session	periodically  multicasts
an  announcement packet	to a well known	multicast address and port.  The
announcement is	multicast with the  same  scope	 (as  defined  by  group
address	 range	or  TTL)  as the session it is announcing.  This ensures
that the recipients of the announcement	can also be potential recipients
of the session the announcement	describes (bandwidth and other such con-
straints permitting).  This is also important for the scalability of the
protocol, as it	keeps local session announcements local.

The time period	between	one announcement and its repetition is dependent
on two factors - the scope (TTL) of the	session, and the number	of other
sessions  currently  being announced by	other session directory	clients.
The goal is to keep the	total bandwidth	being used  below  a  predefined
level for each scope.

Handley								[Page 2]

INTERNET-DRAFT						  ??th June 1996

Session	Announcement

A  session  to be announced is simply multicast	to the appropriate well-
known multicast	address	and port.  The announcement contains  a	 session
description  and,  optionally,	an  authentication  header.  The session
description may	be encrypted.

Session	Deletion

Sessions may be	deleted	in one of several ways:

Explicit Timeout
    The	session	description contains timestamp information which  speci-
    fies  a  start and end time	for the	session.  If the current time is
    later than the end-time for	the session, then the session is deleted
    from  the  receiver's  session  cache.   If	 an  announcement packet
    arrives with an end-time before the	current	time, it is ignored.

Implicit Timeout
    A session announcement message should be received  periodically  for
    each  session  description	in  a  receiver's  session  cache.   The
    announcement period	can be predicted by the	receiver from the set of
    sessions  currently	being announced.  If a session announcement mes-
    sage has not been received for ten times the announcement period, or
    half  an hour, whichever is	the greater, then the session is deleted
    from the receiver's	session	cache.	The  half  hour	 minimum  is  to
    allow for transient	network	partitionings.

Explicit Deletion
    A  session deletion	packet is received specifying the version of the
    session to be deleted.  If the cached session contains an  authenti-
    cation  header, the	session	deletion packet	must contain a signature
    signed by the same key.  If	the cached session does	not  contain  an
    authentication  header,  but  the  deletion	 packet	has the	same IP-
    source address (not	the SAP-stated source address in the packet)  as
    that  from	which the session announcement was originally announced,
    then the session is	deleted.    If neither of  these  conditions  is
    not	 the  case,  then  the session deletion	packet is ignored.  Note
    that IP source addresses can be spoofed, and although the RPF filter
    in	most  multicast	routing	algorithms will	result in the packet not
    being delivered in some cases, this	is  insufficient  protection  in
    many  cases,  and  an  authentication header should	be used	for such
    situations.

Session	Modification

A pre-announced	session	can be modified	by simply announcing  the  modi-
fied  session  description.   In  this case, the version hash in the SAP
header should be changed to indicate to	receivers that the  packet  con-
tents  should  be  parsed  (or decrypted and parsed if it is encrypted).
The session itself is uniquely identified by the SDP origin field in the
payload, and not by the	version	hash in	the SAP	header.

The same rules apply for session modification as for session deletion:

Handley								[Page 3]

INTERNET-DRAFT						  ??th June 1996

o   Either  the	 modified  announcement	 must  contain an authentication
    header signed by the same key as the cached	session	announcement  it
    is modifying, or:

o   The	 cached	 session announcement must not contain an authentication
    header, and	the session  modification  announcement	 must  originate
    from the same host as the session it is modifying.

If  an	announcement  is received containing a authentication header and
the cached announcement	did not	contain	an authentication header, or  it
contained   an	 different  authentication  header,  then  the	modified
announcement must be treated as	a new and  different  announcement,  and
displayed  in  addition	 to the	un-authenticated announcement.	The same
should happen if a modified packet without an authentication  header  is
received  from a different source than the original announcement.  These
rules prevent an announcement having an	authentication header added by a
malicious  user	 and  then  being deleted using	that header, and it also
prevents a denial-of-service attack  by	 someone  putting  out	a  spoof
announcement which, due	to packet loss,	reaches	some participants before
the original announcement.  Note that under  such  circumstances,  being
able  to authenticate the message originator is	the only way to	discover
which session is the correct session.

4.  Encrypted Announcements

Upon receiving a  new  announcement  with  the	encryption  bit	 set,  a
receiver should	attempt	to decrypt the announcement with each of its set
of session decryption keys.  If	it succeeds, then the  session	is  dis-
played	to the user.  If it does not succeed with any key, then	the ses-
sion is	ignored, but the version hash and original source are cached  to
avoid  having  to  attempt  to	decrypt	 this  announcement  in	 future.
(there's a denial of service attack on this cache unless we do a compar-
ison  of  he  enture session that needs	some more thought...) This cache
can be safely timed out	when the timeout specified in encrypted	 packets
expires.

Note  that  if an encrypted announcement is being announced via	a proxy,
then there may be no way for the proxy to discover that	the announcement
has  been  superseded,	and  so	 it  may  continue  to	announce the old
announcement in	addition to the	new announcement.  SAP provides	no mech-
anism  to  chain modified encrypted announcements, so it is necessary to
announce the unmodified	session	as deleted for some time after the modi-
fication  has  occurred.   This	does not guarantee that	all proxies have
deleted	the session, and so receivers of encrypted  sessions  should  be
prepared  to discard old versions of session announcements that	they may
receive	(as identified by the SDP version field).  In  most  cases  how-
ever,  the  only  stateful  proxy  will	 be  local to (and known to) the
sender,	and an additional (local-area) protocol	 involving  a  handshake
for such session modifications can be used to avoid this problem.

Handley								[Page 4]

INTERNET-DRAFT						  ??th June 1996

5.  Packet Format

SAP data packets are of	the following format:

 0		     1			 2		     3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |	MT  |E|P|   auth len	|	 msg id	hash		|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			  orig source				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		 optional authentication header			|
|			      ....				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		       optional	timeout				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|		    optional random field			|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			  text payload				|
|			      ....				|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V: Version Number

SAP version number = 1

MT: Message Type

One of the following:

0   Session description	announcement packet.  The text payload is an SDP
    session description, as described in draft-ietf-mmusic-sdp.

1   Session description	deletion packet.  The text payload is  a  single
    SDP	 line  consisting  of the origin field of the announcement to be
    deleted.

2   Multicast  address	test.	The  text  payload  contains  a	 session
    description	 in a format such as SDP containing addresses to be used
    in a  session.   The  session  is  being  test-announced  to  elicit
    responses  of  sessions  whose  multicast address may clash	with the
    test message.  Address test	messages  should  not  be  displayed  by
    clients.  Responses	to address-test	messages are described below.

E - Encryption Bit

If  the	 encryption  bit  is  set, the text payload of the SAP packet is
encrypted, and two additional fields are added to  the	packet:	 Timeout
and Random.  The Timeout field is not encrypted, but the Random	field is
encrypted along	with the text payload.	Note the encryption algorithm is

Handley								[Page 5]

INTERNET-DRAFT						  ??th June 1996

not  specified	in  the	 packet	 -  this  is  communicated  to permitted
receivers out-of-band along with the corresponding decryption key.

P - Padding Bit

If the data in the Authentication Header is not	a multiple of 32 bits in
length,	 it  is	padded to a multiple of	32 bits, the Padding bit is set,
and the	last byte of the authentication	header contains	 the  number  of
padding	 bytes (including the last byte) that must be discarded	from the
authentication header field.

Authentication Length:

A 8 bit	unsigned quantity giving the number of 32  bit	words  following
the  main SAP header that contain authentication data (and padding bytes
if present).  If it is zero, no	authentication header is present.

Authentication Header

This contains a	digital	signature (encrypted cryptographic hash) of  the
text  payload  (or expiry timestamp, and encrypted random field	and text
payload	if the payload is encrypted).  It also contains	the  public  key
with  which the	authentication header can be checked, and information to
identify the encryption	algorithm and mode used.  It can be used for two
purposes:

o   Verification  that changes to a session description	or deletion of a
    session are	permitted.

o   Authentication of the identity of the session creator.

In some	circumstances only Verification	is possible because  a	certifi-
cate  signed by	a mutually trusted person or authority is not available.
However, under such circumstances, the session originator may  still  be
authenticated  to be the same as the session originator	of previous ses-
sions claiming to be from the same person.  This may or	may not	be  suf-
ficient	depending on the purpose of the	session	and the	people involved.

Clearly	the key	given in the authentication header should not be trusted
to  belong  to	the  session  originator  unless  it has been separately
authenticated by some other means, such	as being certified by a	 trusted
third  party.	Such  certificates  are	 not normally included in an SAP
header because they take more space than can normally be afforded in  an
SAP  packet,  and  such	 verification  must therefore take place by some
other mechanism.  However, as certified	public keys are	normally locally
cached,	 authentication	of a particular	key only has to	take place once,
rather than every time the session directory retransmits  the  announce-
ment.

SAP  is	not tied to any	single authentication mechanism.  Authentication
Headers	must be	self-describing, but their precise format depends on the
authentication	mechanism  (signature and encryption scheme) in	use, and

Handley								[Page 6]

INTERNET-DRAFT						  ??th June 1996

so is not defined here.

Message	Identifier Hash

A 16 bit quantity that,	in combination with the	originating source, pro-
vides  a  globally  unique  id	identifying  the precise version of this
announcement.  The message id hash should be changed if	any field of the
session	 description  is changed.  A value of zero means the hash should
be ignored and the message should always be parsed.

Originating Source

This gives the IP address of the original source of the	message.  It  is
permissible  to	 be  zero  if the message has not passed through a proxy
relay and if the message id hash is also zero, though this  is	intended
only for backwards compatibility with SAPv0 clients.

Timeout

When  the  session  payload is encrypted, and the session description is
being relayed or announced via a proxy,	the detailed  timing  fields  in
the SDP	description are	not available to the proxy as they are encrypted
and the	proxy is not trusted with the decryption key.  Under  such  cir-
cumstances,  SAP  includes  an additional 32-bit timestamp field stating
when the session should	be timed out.  This field is included after  the
authentication	header,	 and the digital signature in the authentication
header encompasses the timeout so that a session cannot	 be  maliciously
deleted	by modifying its timeout in an announcing proxy.

The  value  is	an  unsigned quantity giving the NTP time [2] in seconds
that the session times out.

Random

This field is only  present  when  the	payload	 is  encrypted.	  It  is
encrypted  along with the payload, and is used to perform the randomisa-
tion task normally performed by	an initialisation vector  in  algorithms
such  as  cipher-block	chained	DES.  This 32 bit field	should contain a
genuinely random number.  After	decryption, this field is discarded.

6.  SDP	announcement by	periodic multicast.

SAP announces  multicast  sessions  by	periodic  multicast  of	 session
descriptions  to  an  appropriate well known multicast address and port.
The appropriate	address	is determined by the scope mechanisms  in  force
at the sites of	the intended participants.  IP multicast sessions can be
either TTL-scoped or administratively scoped.	One  well-known	 address
and port is used for all TTL-scoped announcements, and additionally, one
well-known address (within the corresponding scope  zone)  and	port  is
used  for each administrative scope zone that an instance of the session
directory is within.  Thus an instance of the session  directory  should

Handley								[Page 7]

INTERNET-DRAFT						  ??th June 1996

listen	on multiple multicast addresses, but should normally only send a
particular announcement	to the single multicast	address	corresponding to
the  scope of the session being	described.  The	discovery of administra-
tive scope zones and the appropriate announcement address for each  zone
are  outside  the  scope  of  this  draft,  but	 it is assumed that each
instance of the	session	directory within  a  particular	 scope	zone  is
aware of that scope zone, and of the corresponding announcement	address,
port, TTL, and session address allocation range.

TTL Scoped Announcement

The well-known address is 224.2.127.254	and the	UDP port is  9875.   The
session	 announcements	should be multicast with the same TTL with which
the conference session will be multicast. If the different media  in  an
announcement  are  given different TTLs, then multiple announcements are
necessary to ensure that anyone	 joining  the  conference  can	in  fact
receive	 data  for  each  media	 started.   For	 example,  if we have an
announcement to	make containing	audio at TTL 127 and video  at	TTL  63,
then we	make an	announcement at	TTL 63 containing both media, and a sep-
arate announcement at TTL 127 containing only the audio.  It  is  up  to
the  receiving session directory to parse both announcements as	the same
announcement if	it is within the appropriate scope to get both announce-
ments.	If multiple announcements are being made for the same session in
this way, then each announcement must  carry  an  authentication  header
signed by the same key,	or be treated as a completely separate announce-
ment.

The time period	between	one announcement and its repetition is dependent
on two factors - the scope (TTL) or the	session, and the number	of other
sessions currently being announced by other sd clients.

The recommended	bandwidth limits for each TTL are:

	  TTL	  bandwidth
	  1-15	  10Kbps
	  16-63	   2Kbps
	  64-127   1Kbps
	  128-255 200bps

Session	announcers in the same scope band can normally	be  expected  to
hear  your announcements, and reduce their data	rates accordingly.  Thus
you should calculate the available bandwidth for  your	session's  scope
band  by  dividing  the	 appropriate  limit above by the number	of other
announcers in your scope band.	This gives you	your  bandwidth	 alloca-
tion,  which, given the	size of	your data packets, can be used to derive
the base interval for announcements.

I.e., given a limit in bps (as above) and a ad_size in bytes,  the  base
announcement interval in seconds is:

      interval =(8*no_of_ads*ad_size)/limit

For  each  interval  between announcement packets, you must add	a random

Handley								[Page 8]

INTERNET-DRAFT						  ??th June 1996

value (+/- 1/3 of the base interval) to	the value used	for  the  inter-
announcement period to prevent announcement synchronisation.  It is also
important to keep monitoring other announcements  and  adjust  the  base
interval accordingly.

There  is possibility to adjust	the scope band limits depending	on prop-
erties of the sessions being announced,	but this is left for future  SAP
drafts to specify.

Administrative Scoped Announcements

For  each  administrative  scope  zone	in  force  at a	particular site,
instances of the session directory running at that site	need to	know the
following information:

o   The	 multicast address to be used for announcement.	 The is	normally
    the	highest	multicast address in the relevant  administrative  scope
    zone.    For   example,   if   the	scope  range  is  239.16.32.0  -
    239.16.33.255, then	the convention is that 239.16.33.255 is	used for
    session announcements.

o   The	UDP port announcements should be sent to.

o   The	 TTL  announcements  should  be	made with.  This should	be large
    enough to reach all	sites in the admin scope zone, and will	also  be
    the	TTL used for sessions announced	to be using this scope zone.

o   The	 address range to be used for sessions in this scope zone.  This
    should be a	contiguous range, and currently	should	lie  within  the
    range 239.0.0.0 to 239.255.255.255 (but this is defined by IANA, not
    by this draft).

o   The	total bandwidth	to be used by the session directory for	 session
    announcements in this admin	scope zone.  A recommended default value
    for	this is	500bps,	but this may be	inappropriate for some uses.

7.  Security Considerations

SAP contains mechanisms	for ensuring integrity of session announcements,
for authenticating the origin of an announcement and for encrypting such
announcements.	These mechanisms have not yet been subject  to	suitable
peer-review, and this document should not be considered	authoritative in
this area at this time.

SAP contains mechanisms	that are designed to prevent an	announcement  by
one  user  from	 being	modified or deleted by another user, and also to
provide	limited	privacy	by use of encryption.

Session	announcements that are encrypted with a	symmetric algorithm  may
allow  a  degree  of  privacy  in  the announcement of a session, but it
should be recognised that a user in possession of such a key can pass it
on  to	other users who	should not be in possession of such a key.  Thus
announcements to such a	group of key holders cannot be assumed	to  have
come  from  an	authorised  key	 holder	 unless	 there is an appropriate

Handley								[Page 9]

INTERNET-DRAFT						  ??th June 1996

authentication header signed by	an authorised key holder.   In	addition
the recipients of such encrypted announcements cannot be assumed to only
be authorised key holders.  Such encrypted announcements do not	 provide
any  real  security unless all of the authorised key holders are trusted
to maintain security of	such session directory keys.  This  property  is
shared	by  the	multicast session tools	themselves, where it is	possible
for an un-trustworthy member of	the session to pass on	encryption  keys
to  un-authorised  users.   However  it	is likely that keys used for the
session	tools will be more short  lived	 that  those  used  for	 session
directories.

Similar	 considerations	 should	 apply	when  session  announcements are
encrypted with an assymetric algorithm,	 but  then  it	is  possible  to
restrict the possessor(s) of the private key, so that announcements to a
key-holder group can not be made, even if one of the  untrusted	 members
of the group proves to be un-trustworthy.

As stated above, if a session modification announcement	is received that
contains a valid authentication	header,	but which is not signed	 by  the
original  creator  of the session, then	the session must be treated as a
new session in addition	to the original	session	with the same SDP origin
information unless the originator of one of the	session	descriptions can
be authenticated using a certificate signed by a  trusted  third  party.
If  this  were	not  done,  there  would be a possible denial of service
attack whereby a party listens for new	announcements,	strips	off  the
original authentication	header,	modifies the session description, adds a
new authentication header and re-announces the session.	 If a  rule  was
imposed	 that such spoof announcements were ignored, then if packet loss
or late	starting of a session directory	 instance  caused  the	original
announcement to	fail to	arrive at a site, but the spoof	announcement did
so, this  would	 then  prevent	the  original  announcement  from  being
accepted at that site.

A similar denial-of-service attack is possible if a session announcement
receiver relies	completely on the originating source and hash fields  to
indicate  change,  and fails to	parse the remainder of announcements for
which it has seen the announcement the origin/hash combination before.

A denial of service attack is possible from a malicious	site close to  a
legitimate site	which is making	a session announcement.	 This can happen
if the malicious site floods the legitimate site with  huge  numbers  of
(illegal)  low ttl announcements describing high ttl sessions.	This may
reduce the session announcement.  rate of the legitimate announcement to
below  a  tenth	of the rate expected at	remote sites and therefore cause
the session to time  out.   Such  an  attack  is  likely  to  be  easily
detectable, and	we do not provide any mechanism	here to	prevent	it.

Appendix A: Summary of differences between SAPv0 and SAPv1

For  this purpose SAPv0	is defined as the protocol in use by version 2.2
of the Sdr session description tool.  SAPv1  is	 the  proposed	protocol
described  in  the document.  The packet headers of SAP	messages are the
same in	V0 and V1 in that a V1 tool can	parse a	V0  announcement  header

Handley							       [Page 10]

INTERNET-DRAFT						  ??th June 1996

but not	vice-versa.

In SAPv0, the fields have the following	values:

o   Version Number: 0

o   Message Type: 0 (Announcement)

o   Authentication Type: 0 (No Authentication)

o   Message Id Hash: 0 (No Hash	Specified)

o   Originating	 Source:  0  (No  source specified, announcement has not
    been relayed)

Appendix B: Author's Address

Mark Handley
Department of Computer Science
University College London
London WC1E 6BT
United Kingdom
electronic mail: [email-masked]

Acknowledgments

SAP and	SDP were originally based on the protocol used by the sd session
directory  from	 Van  Jacobson at LBNL.	 The design of SAP was funded by
the European Commission	under the Esprit 7602 "MICE"  project,	and  the
Telematics 1007	"MERCI"	project.

References

[1]  M.Handley,	 V.  Jacobson,	``SDP:	Session	 Description Protocol'',
INTERNET-DRAFT,	June 1996.

[2] D. Mills, ``Network	Time Protocol version 2	specification and imple-
mentation", RFC1119, 1st Sept 1989.

Handley							       [Page 11]