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.

Table of Contents

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


1.    Introduction and Background

1.1.   Introduction

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.

1.2.   The work planned under the 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.

1.3.   Deviations from our Initial Plans, and Organisation of this Report

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.

2.    QoS work on Two Channels to CAIRN

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.

3.    Secured Conference Tools

3.1.   The Previous work on Secured Conferencing Tools

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.

3.2.   Secured SDR and Upgrades of the Tools to be IPv6 Capable

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.

3.3.   The Use of the Secured Conference Store

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..


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.


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.

4.    Network Components

4.1.   Introduction

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.

4.2.   SIP

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.

4.3.   Multicast WEBCAST

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.

4.4.   Servers

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.

4.5.   Universal Transcoding Gateway

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.

5.    Virtual Private Networks

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.

6.    Use of Resources

6.1.   Staffing

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

6.2.   Travel

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