DARPA SCAMPI
Project Year 1 Technical Report
Jon Crowcroft
and Peter Kirstein
Department of Computer Science, University College London
July 1999 – July 2000
This is the first year report for the DARPA Scampi
Project, funded from July 15 1999.
Most of the work has been in the completion of
secure conferencing tools with application-level security. This has included
upgrading to IPv6, and the incorporation of a new tool for secure announcements
based on a Web store with use of group technology to restrict access. There has
been considerable preparatory work in a number of areas which will bear fruit I
in the second year: putting up and study of IPSEC in various modes; porting to
Java versions of basic components such as the Universal Transcoding Gateway,
the Multimedia Recorder and Reliable Multicast components. There have also been
preliminary tests of two Virtual Private Network technologies; this will
eventually include the Xbone technology of ISI, and incorporate a number of the
sites of the International Collaboration Board. Finally, the report describes
our progress in all these areas, and indicates our intentions for the final
year of the project.
Abstract........... 1
1. Introduction and Background 2
1.1. Introduction 2
1.2. The
work planned under the Project 2
1.3. Deviations
from our Initial Plans, and Organisation of this Report... 3
2. QoS work on Two Channels to CAIRN.............. 3
3. Secured Conference Tools 4
3.1. The
Previous work on Secured Conferencing Tools 4
3.2. Secured
SDR and Upgrades of the Tools to be IPv6 Capable 4
3.3. The
Use of the Secured Conference Store 4
4. Network Components.... 7
4.1. Introduction 7
4.2. SIP... 7
4.3. Multicast
WEBCAST 7
4.4. Servers 7
4.5. Universal
Transcoding Gateway....... 8
5. Virtual Private Networks 8
6. Use of Resources........ 8
6.1. Staffing 8
6.2. Travel 8
References....... 9
We had a previous report D079 Supporting Internet Multicast
Multimedia, which lasted from January 17, 1996 – July 16, 1999 UCL. We
requested two extensions to this project – one to the end of 1998, and one for
a further two years to the end of 2000. In the event, the first, no-cost,
extension was granted, and a final report on the project was written [kirst1].
The second extension was considered, and approved in principle. In the event,
partly because of a change in the project officers at ITO, the second extension
was not approved before the end of the project. For this reason, a new contact
was negotiated, which started on July 17, 1999 and terminates on September 30,
2001 [kirst2]. The new project, now called SCAMPI, was partially finishing off
aspects of the original proposal, and partly starting new work which were a
logical extension of the original project.
This
report is the first annual report on the work done under the SCAMPI Project.
In [kirst2], we stated that we would do the following:
·
Set
up a testbed with two links between UCL and the CAIRN; one will be the current
CAIRN link, the other via ULCC/UUNET that runs only native IPv6. On the UCL
side, LEARNET will be connected in. We then investigate mechanism for QoS with
two high-bandwidth islands connected by a pair of lower-speed connections -
with full QoS in place on the links.
·
Provide
full implementation of the Session Initiation Protocol (SIP) - including its
security extensions. This will require some re-work of the media tools, to allow
use of an underlying IPSEC infrastructure. Most of the current IPSEC
implementations do not support addressing of multicast groups; this deficiency
will have to be addressed. We will incorporate also those encryption algorithms
that are recommended in the IETF community.
·
Deploy
a security infrastructure, so that group key pairs, or even the whole Session
Descriptions, are stored in a Secure Web store with access controlled by group
membership; in addition, Certificates containing the Public Keys of any
potential participants will be kept in Secure DNS servers. Such a mechanism
will be more in tune with the security deployment. In the original proposal,
the group key pairs were kept in a secure DNS; holding confidential information
in a Secure DNS is now contrary to the declared policy on DNSs.
·
Provide
secure multicast WEBCAST facilities to provide authenticated and encrypted
pre-distribution of presentation material. This work requires the originator to
set up security associations, to ensure that the appropriate privileges should
be granted. Here we expect to use the normal ISAKMP/Oakley exchanges.
·
Provide
access control and confidentiality on the UCL media-on-demand server, to add
stored material into conferences. This will require both the use of IPSEC with
multicast, and the incorporation of the normal ISAKMP/Oakley exchanges to
authorise the storage.
·
Ensure
the UCL Universal Transcoding Gateway can process encrypted media streams in a
trusted gateway - using standard Internet security procedures. We believe this
will require an IPSEC transcoding stage in the Relay. The control of such
stages will require the use of IPSEC with multicast, and the incorporation of
the normal ISAKMP/Oakley exchanges to authorise the control of the Relay and
the decryption/re-encryption stage in the Relay. This gateway will also be used
for connecting in mobile and other devices.
·
Investigate
the use of RTSP and/or SIP, with appropriate security extensions, to control
the media server and gateway described above.
·
Deploy
secure conferencing over CAIRN with full security infrastructure, all the above
features, and both SIP and SAP. This will use as much as possible of the normal
IPSEC based security; application-level security will be used only when we can
think of no way of performing the functions at a network level.
·
Investigate
the functionality required to provide a Secured Virtual Private Network between
the members of the ICB. This will include working through how to deal with the
differing security policies of the ICB-member networks. While UCL will be one
of the parties to this Coalition System, an important role will to act as a
facilitator to the other partners - in the provision of secured applications,
infrastructure, and practical assistance. Our participation in the above-mentioned
CAIRN will ensure that this will provide an additional collaborator in the VPN.
While we have largely followed the plan envisaged, there
have been some deviations. The deviations have occurred because facilities
expected were not available, the work intended no longer made sense, or because
we thought it preferable to do some of the work items in a different order
because of some external events..
Any of the applications that required IPSEC have been
delayed. We now have IPSEC for Solaris, Microsoft Windows, NetBSD and FreeBSD;
the latter two come from the KAME [kame] releases. Most of these have only
become available during the last quarter, and some still have not been delivered
with encryption. Moreover, the current implementations require privileged
access to the IPSEC stack to enter any keying material; this is impractical
from our user applications. We are resolving how to do it before we use any
IPSEC in the tools or servers in anger. This has delayed this aspect of
activities to year 2.
There have been some problems with the QoS work on two
channels, because we only have one available. The reasons for this, and our
activities, are discussed in Section 2. The work with secured conference tools
has continued well; it is largely completed without IPSEC, and is considered in
Section 3. The work on secured SIP, multicast WEBCAST, servers and UTG is
on-track; the work during this year has been mainly to complete the non-secured
versions in a form suitable both for IPv6 and security; it is considered in
Section 4. The VPN work is proceeding albeit slowly; it is discussed in Section
5. Use of Resources is considered in Section 6.
In
our original proposal, we stated that
the two-channel aspect of this work depended on our obtaining a new channel to
CAIRN based on UUNET and DARPA, and maintaining our current one. The new
channel was to have the international portion provided by UUNET, but DARPA was
to provide the termination between Palo Alto and the nearest CARIN node in
Berkeley. In the event, while the link was ordered, the US Government
procurement agent did not follow up its progress, and it has never arrived.
Moreover, the DARPA share of funding for the previous link to Goddard MSFC was
terminated in late ’98 (this link was co-funded with NASA up to that date).
NASA thereupon stated that the main purpose of the link they were supporting
would be for bilateral tests with UCL. NASA permitted the link to be connected
to CAIRN for specific experiments and videoconferences, but this was not the
normal case. The co-ordination of the through-routing has proved an
administrative nightmare; the arrangements for the re-routing had to be carried
out manually, and many times it did not occur. However, early in 2000, the UK
academic network, SuperJANET, established peering with Abilene on Internet-2.
There had been an agreement between DARPA and Internet-2 that CAIRN sites on
existing networks could peer with the latter, and that any usage for DARPA
purposes would not count as transit traffic. For this reason, we have been able
to establish a link between UCL and a node at ISI via SuperJANET and Abilene.
This link took some time to establish, but is now available.
We carried out extensive QoS experiments over LEARNET between Essex U and UCL in late 1999. These included layered audio codecs and video-on-demand; they included also correlation between user satisfaction and QoS (as measured by deliberate errors and manipulations of priorities in weighted fair queuing). The results were provided in some detail in [gevros], [sasse]. We expect to complete these measurements before the end of 2000, by using at least the new Internet-2 path to CAIRN, and possibly also the NASA path as a second channel.
The
UCL work during the first three years of the project went a long way towards
providing versions of the conference tools for Video (VIC), Audio (RAT), shared
editing (NTE) and session announcement (SDR). While VIC and RAT were based on
the earlier tools from Van Jacobson and McCanne at LBL, they were substantially
modified at UCL. [kirst1], which was presented at DISCEX 2000, provides many
background references to that work. The
tools could be secured by DES encryption, and the encryption keys included in
the Session Description of the conference [Han1]. The main problem was how to
distribute information about private conferences only to parties authorised to
participate.
The
principal way that information about multicast conferences was distributed was
by Session Announcement (SAP) or Session Invitation (SIP). During the previous
project, we modified an earlier tool from Van Jacobson (SD), and provided
SDR We then worked through the MMUSIC
group of the IETF to standardise security procedures for SDR. By the end of the
previous project, the authentication aspects of SAP had been standardised; we
were unable to get agreement on standardisation for confidentiality for
announcements. Nevertheless, we developed a version of SDR, which used public
key cryptography to sign announcements; this was according to [Hand2]. We
developed also an implementation which did symmetric encryption, with the
symmetric key itself distributed by the use of an asymmetric Group Encryption
Key (GEK). The GEK was distributed securely, e.g. by PGP or S-MIME, to the
authorised participants. This mechanism was described in [kirst3], and an
implementation provided; the latest version is SDR v2.7e. All the UCL software
is available from the UCL web site [perk1].
During the current period, the tools RAT, VIC and NTE were made IPv6 capable, when linked with the relevant IPv6 stacks. This required some re-writing, to ensure that there was no explicit use of ipv4 addresses in the code. The tools listed in the developers’ versions on the UCL Web page have this capability. The latest version of SDR, v2.9, has been modified to be IPv6 capable (based on some ISI work) – but has had the security routines commented out. This is because we have not considered it worthwhile to put in the effort to fully upgrade the secured version to include IPv6. Since secured SAP was not standardised, we feel that version of SDR would have limited use. Instead we have developed an alternative mechanism which provides security, and has been extended easily to IPv6.
We
have provided a web-based system for the storage and access of information in a
way that can be secure. Currently, the system can is used to store and access
session details for multicast conferences. Users can join the sessions easily
via their web browser (using our SPAR Java applet to start the media tools in
secure mode). While we have designed the system to allow participation in
secured conferences, its use is not restricted to this case.
Groups of users can be created for access control to the information and group managers can add/remove users, create/delete sessions, change session keys. Users only have access to the information for the groups to which they belong.
Server access
The web server uses HTTP-S for the transport, so the browser-server dialogue is encrypted over the network. Currently, this uses a UCL self-signed certificate. Since this is "unknown" to browsers, it is untrusted so needs to be accepted by the user initially. The URL is https://www-secure.cs.ucl.ac.uk/ and the main page frame has clickable options (e.g. to register, manage groups, show sessions etc.) Users first need to register on the server by creating a user-profile. Currently this is a simple form to provide name/organisation/e-mail-key details and set a user-id and password for future authentication and access to the server. Currently, no authentication checks are made on who can register, and only basic checks are made on the user data supplied. Browser-supplied user certificates can also be used as
an alternative to usernames/passwords to access the store. Currently, the server will accept user certificates signed by the UCL Trustfactory, or Verisign Class0 certificates
Registered users can create/manage "groups" and assign members (other registered users) who may access them. A group manager can also create secure conference sessions by submitting a form giving the details (title/media used/expiry time/scope etc.)
Registered users can also access "pages" for the groups to which they belong, and retrieve the information in the list of sessions and join active conferences. Such conferences can be joined in several ways:
· manually - the user needs to start the conference media tools on their host with the addressing/attribute details shown
· automatically by using a small platform specific "helper" program and MIME-type (which needs special configuration on the browser). This method is obsolete but can be used if a Java-capable browser is not available.
· automaticaly using the SPAR Java Applet - which is platform independent and needs no browser configuration. This is the preferred/recommended way but currently only Netscape's Communicator and Microsoft's Internet Explorer 4/5 are supported.
Note: for creating and joining sessions defined on the server, PGP keys are not needed or used..
Browsers
Any
web browser that supports HTTP-S can access the secure server. Joining
conferences using the SPAR Java Applet requires either Netscape's Communicator
or Microsoft's Internet Explorer 4/5. Users of other browsers should use one of
the alternative methods of starting the MBone tools.
Conferences
The server maintains a database of conference sessions (created using user-supplied details plus a random set of multicast addresses, ports and encryption keys). The server picks multicast address from our "glop" range although other scope ranges could be used. The addresses are random but unique across all active sessions defined. The ports are random (even numbered) but unique for each media defined for the session. The session encryption keys are random alphabetic strings - they can be changed at any time (e.g. when a group manager removes a user). The server automatically removes a session after the expiry time (as set when created). When a user joins a session, a server script generates an HTML page referencing the SPAR Java applet and encodes the session details as SDP data (passed in the HTML as a parameter to the applet). The applet is run by the browser and parses the SDP to execute the media tools on the host with the correct addresses/ports/keys required for the session.
Sdp PARser (SPAR)
Java Applet
Simplistically, the Java applet parses the SDP, extracts essential parameters and then starts the tools with the parameters on the client machine. The SDP content is embedded within the HTML as a parameter to the applet. The advantage of using HTTP-S to communicate the SDP content between client and server is that the SDP content (with encryption keys) will also be secure.
For obvious security reasons standard Java applets do not have permissions to access local resources and thus cannot execute software on the client machine. To overcome this, both Netscape Communicator and Microsoft Internet Explorer 4 allow applets to be digitally signed with a private key associated to a RSA object-signing certificate. If the user accepts the certificate, therefore trusting the applet, then the browser allows the applet access permissions outside the Java security sandbox. Communicator and Internet Explorer implement different methods and technologies for digitally signing and distributing objects:
Communicator requires Java applets to be
signed using Netscape's Netscape Object Signing software. The certificate and Java code are then
packaged using the JAR file structure. Signed Java applets need to explicitly
request permission to access local resources, such as executing software using
the Netscapes Capabilities API extensions. The request causes Communicator to
prompt the user, asking them to either accept or deny the relevant permission.
The dialog box also contains the certificate as verification of the source and
authenticity of the code.
Internet Explorer requires Java applets to be
signed using Microsoft's Authenticode software and packaged using a CAB file
structure. A signed Java applet also has to request permission to access local
resources by using Microsoft's Com API extensions. However unlike Communicator,
the specific request doesn't prompt any user action. Instead the user is asked
to accept the applets' certificate when the applet is encountered by the
browser and by doing so grants universal access to local system resources.
More
information regarding the applet can be found on the SPAR web page:
http://www-mice.cs.ucl.ac.uk/multimedia/software/spar/
IPv6 Capability
The Server is running the Apache Web software [apache1], which is IPv6 capable. The tools are already IPv6 capable, if started with IPv6 addresses. The whole system is, therefore, IPv6 capable whenever the browser is so capable. At present this only applies with the Microsoft Explorer IE4 or IE5.
Integration with SDR
We
have incorporated a SAP listener with the Conference Store. This actually runs
SDR, and allows announcements to be stored in a portion of the store. This acts
as an announcement proxy. So far this has been configured only with the latest
insecure version of SDR, so that only public announcements can be so stored. We
are not yet sure whether it is worth extending this to the secured
announcements, since we do not really want to pursue that avenue in any case.
Extensions/Future work
The Server We expect to extend the
server function to store arbitrary data, possibly unrelated to conferences. For
example we plan to provide a secure certificate repository/depository, and to
hold documents that require secure controlled access.
User-certificate
authentication The current certificates are not signed by a CA trusted by the Server.
If it were so trusted, proof of identity at registration could be accepted. We
expect to provide some mechanism for using both roles and user names with such
certificates, and to make provision for Certificate Revocation Lists.
Server replication To avoid the single point
of failure, the server will be replicated so that alternative/backup/secondary
servers can be accessed. This will be simple to do if the secondary servers
have read-only copies of the information (e.g. updated daily/hourly), but more
involved if users can update information on any server.
SPAR & Alternative Browsers Browser's that do not support signed applets but do have a "plug-in" architecture could use SUN's Java Plug-in to view the applet. The Plug-in requires the applet to be signed and packaged using Netscape's Object Signing software but it does not implement Netscape's Capabilities API. Since the API is not supported by the Plug-in, any certificate accepted by the user, would grant universal access to local system resources.
Other Extensions The server and SPAR Java Applet will be extended to process further media options/attributes; we now process most of the SDP, and support different media via configuration plug-ins passed along with the SDP by the server]
Currently
we process only:
·
the
session title and description
·
the
multicast address, port, TTL and encryption key for each media
·
audio,
video, whiteboard and text media types
Different methods of choosing/obtaining multicast addresses will be supported eventually. We expect to study the integration and trade-off between this type of system and use of SAP and SIP.
Most of the components in this section are in a similar
state. We have had versions of them from previous work, and intend to put them
in a secured form in the second year of SCAMPI. However, they have needed to be
put into a better form for this purpose, and the work has been co-ordinated
with another DARPA-funded project RADIOACTIVE [kirst4]. It has been necessary
to rewrite many of the components so that they are pure Java, and can be put
into a form of Proxylets which can be used in Active Services – since all these
components are used in that role; this rewriting is largely complete. An
additional problem is that we have wanted all this work to be both IPv6 enabled
and use IPSEC where possible. The IPSEC modules have only recently become
available. The IPv6-enabled Java will become available only towards the end of 2000
As a consequence, the securing will take place in the final year of SCAMPI.
In the project plan, we expected to provide secured SIP
by now. In practice, there was a version of SIP in the SDR of Section 3.2.
However, this was based on earlier standards, and the whole protocol has
assumed very considerable importance.
We have decided to base our work on an implementation from Bremen U [ott1],
which is being done in another project in which we both participate. This
implementation will be available at in October 2000; we will start our work on
the secured version only when this implementation becomes available.
An important component for this is the implementation of
a reliable multicast. This has been implemented [vicis], and implementation of the Proxylet is well advanced [kirst4]. Its
secured implementation is expected during the second year.
The MMCR server has been rewritten in pure Java. We have
shown how it can be combined with distributed caches to provide much better
recordings {lam1]; these are then combined into a single high quality recording
which can be stored centrally. In the same way, the recordings can be
distributed for introduction into multicast, to combat network problems. This
component It is also being made into a Proxylet under RADIOACACTIVE – in fact
as different proxylets for a proxy cache recorder, and a player [kirst4]. The
securing of this proxylet will be co-ordinated under SCAMPI, with its proxylet
development under RADIOACTIVE.
This component, which was based on Amir’s work at
Berkeley [amir], has had to be largely re-written in Java [kirst4]. It will be
developed first as a transcoding gateway proxylet in RADIOACTIVE, but the
security aspects will be completed here.
Under
the aegis of the International Collaboration Board (ICB), one part of the
SCAMPI project has been to participate with other members in the development of
a Virtual Private Network (VPN) connecting the relevant sites. The prime mover
in this work has been the Canadian Department of National Defence (DND), who
has tasked NIRNS in Ottawa to work on the project. NIRNS has provided a number
of working papers [spag1 – spag4]. They also carried out some VPN tests with
N3CA towards the end of 1999. We have been helped by both Cisco and Entrust to
prepare for additional experimentation with NIRNS.
For the creation of VPNs, we
needed the IPSEC software. For the first half of 2000, we were unable to
obtain this version of the software, which was needed to interwork with Entrust
and use certificates.
We configured, therefore, an IPSEC tunnel manually for a VPN between NIRNS and
UCL. We have eventually obtained 12.06T on
our Cisco 2611, though this does not yet support IPv6. We have installed also the Entrust-v5 system,
including its Connect software. This allows us to load certificates in an
automated way into our routers from an Entrust database. We have set up a
three-network VPN inside UCL, and have extended it to NIRNS in Ottawa. We are
now in a postition extend the activity to the other ICB sites. We have close
contact with Cisco in this matter and hope to extend to upgrade to IPv6 before
the end of 2000.
We have been working also with Touch of ISI, and have installed his Xbone software at UCL [touc]. We participated in a demonstration of Xbone, when the Director of DARPA visited ISI in May 2000. We expect to combine the Xbone work both with the VPN activity under the ICB auspices, and with the Active Networks activity carried out under RADIOACTIVE.
The
staffing of the project started fairly slowly, because of the delay in agreeing
the original proposal. However, one graduate student started early on some of
the components work, and the work on secure conferencing tools has proceed
well. The persons associated with the project have been:
The UCL staff associated
with the RADIOACTIVE project has been:
·
Jon
Crowcroft - Co-PI
·
Panos
Gevros – The QoS work of Section 2
·
Kris
Hasler – Implementing the secure conference store (SPAR), and updating the
secured SDR
·
Peter
Kirstein - Co-PI
·
Piers
O'Hanlon – Investigating the variants of IPSEC at our disposal
·
Colin
Perkins – Maintaining the encryption portions of the Mbone tools
·
Ed
Whelan – Developing the security infrastructure, and working with the VPNs
During the last year, funds from SCAMPI have helped defray expenses for attendance at IETF, security and ICB Meetings. It would normally have defrayed expenses at DARPA PI meetings, but our attendance at these have been charged to RADIOACTIVE to date.
[amir] E.Amir, S.McCanne and R.Katz, ``An active service framework and its
application to real-time multimedia transcoding'', ACM SIGCOMM Computer
Communication Review, Oct 98.
[apache] URL:
expert.cc.purdue.edu/apache.html
[crow1] Crowcroft, J and PT Kirstein:" IPng - State of the Art",
Infowin, EC, Brussels, 1999
[crow2] J Crowcroft et al:
“Mechanisms for Supporting and Utilising Multicast Multimedia, Proposal to
DARPA for an extension to D079”, Department of Computer Science, University
College London, June 1999
[crow3]
J Crowcroft et al: “DARPA Radioactive Project Year 1 Technical Report”, Department of Computer Science, University
College London, July 2000.
[gevr1] Gevros, P, F Risso and PT Kirstein: "Analysis
of a method for differential TCP service", Proc. 4th Global Internet
Symp., Rio de Janiero, 1999.
[Han1] M Handley et al:
“SDP: Session Description Protocol”, RFC 2327, Apr. 1998.
[Han2] M Handley et al.:
SAP: Session Announcement Protocol, IETF draft, Jun. 1999.
[kame]
ftp://ftp.kame.net/pub/kame/
[kirs1] Kirstein, PT: "Research on
Networks versus Networks for Research: the Need for International Internet
Testbeds, ACM Sigcomm99, 1999
[kirs2] Kirstein, PT, E Whelan and I Brown:
"A Secure Multicast Conferencing", DISCEX 2000, pp 54-63, IEEE
Computer Society, 2000.
[kirs3] Kirstein, PT, E Whelan and I Brown:
"Secure Multimedia Conferencing", " A Secure Multicast
Conferencing Architecture", Proc. 4th Int. Distributed Conf., Madrid,
1999.
[kirst4] D079 Supporting Internet Multicast Multimedia,
Final Report, 24/04/99, Jon Crowcroft and Peter Kirstein, Department of
Computer Science, University College London, 1999.
[kirst5] “DARPA Radioactive Project Year 1”
Technical Report”, http://www.cs.ucl.ac.uk/research/radioactive/
[lam1] Lambrinos, PT Kirstein and V
Hardman: "Improving the Quality of Recorded Mbone Sessions using a
Distributed Model", Proc. 6th Workshop on Interactive Distributed
Multimedia Systems, Toulouse, 377-383, 1999
[mcc2] S.McCanne, V.Jacobson and
M.Vetterli, ``Receiver-driven Layered
Multicast'', SIGCOMM `96, August 96.
[nirns1] International Collaboration Board VPN Pilot Project Examination of IPSec VPN Technologies, September 1999
[ott1] J Ott et al: “The Gateways, Relays, Session
Announcement and Management facilities in Software Release II”, MECCANO
Deliverable 6.2/7.2, Department of Computer Science, University College London, July 2000.
[perk1] http://www-mice.cs.ucl.ac.uk/multimedia/software/index
[rlc] Receiver Driven Layered Congestion Control (a.ka.
rlc)
ftp://cs.ucl.ac.uk/darpa/infocom98.ps.gz and ftp://cs.ucl.ac.uk//darpa/rlc-dps.ps.gz
[sasse] A Sasse et al:
“HIGHVIEW project: Final Report, Department of Computer Science, University
College London, Dcember 1999.
[spag1] J Spagnolo,
“International Collaboration Board VPN Pilot Project – Preliminary plan”,
NIRNS, September 1999.
[spag2] J Spagnolo,
“International Collaboration Board VPN Pilot Project - Cisco/IPSec Router Testing”, September 1999
[spag3] J Spagnolo, “Entrust
International Field Trials, Experience With S/MIME”, NIRNS, March 2000
[touc] J Touch et al:
"The X-Bone" , Third Global Internet Mini-Conference in conjunction
with Globecom '98, Sydney, Australia Nov. 8-12, 1998.
[vicis] L.Rizzo and L.Vicisano, ``A Reliable Multicast data Distribution
Protocol based on software FEC techniques'', The Fourth IEEE Workshop on the
Architecture and Implementation of High Performance Communications Systems (HPCS
'97), June `97