`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 1 of 7
`
`EXHIBIT 15
`EXHIBIT 15
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 2 of 7
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 2 of 7
`
`Location-Independent Naming for Virtual
`Distributed Software Repositories*
`
`Shirley Browne! Jack Dongarra, Stan Green, Keith Moore
`Theresa Pepin, Tom Rowan, and Reed Wade
`University of Tennessee
`Eric Grosse
`AT&T Bell Laboratories
`
`Abstract
`
`A location-independent naming system for network re-
`sources has been designed to facilitate organization and de-
`scription of software components accessible through a vir-
`tual distributed repository. This naming system enables
`easy and efficient searching and retrieval, and it addresses
`many of the consistency, authenticity, and integrity issues
`involved with distributed software repositories by providing
`mechanismsfor grouping resources and for authenticity and
`integrity checking. This paper details the design of the nam-
`ing system, describes a prototype implementation of some of
`the capabilities, and describes how the system fits into the
`development of the National HPCC Software Exchange, a
`virtual software repository that has the goal of providing ac-
`cess to reusable software components for high-performance
`computing.
`
`1.
`
`Introduction
`
`Well-maintained software repositories are central to software
`reuse because they make high-quality software widely avail-
`able and easily accessible. One such repository is Netlib',
`a collection of high-quality publicly available mathematical
`software[6, 4]. Netlib,
`in operation since 1985, currently
`processes over 300,000 requests a day. Netlib is serving as a
`prototype for development of the National HPCC Software
`Exchange (NHSE)*, which has the goal of encompassingall
`High Performance Computing Consortium (HPCC)software
`repositories and of promoting reuse of software components
`developed by Grand Challenge and other scientific com-
`puting researchers [5]. Other network-accessible software
`*The work described in this paper is sponsored by NASA under
`Grant No. NAG 5-2736, by the National Science Foundation under
`Grant No. ASC-9103853, and by AT&T Bell Laboratories.
`107
`tAuthor to whom correspondence should be directed.
`Ayres Hall, Computer Science Department, University of Tennessee,
`Knoxville, TN 37996-1301, (615) 974-5886, browne@cs.utk.edu
`laccessible-
`from a World Wide Web
`browser
`http://www.netlib.org/
`? accessible at http://www.netlib.org/nse/
`
`at
`
`Permission to copy withoutfee all or part of this materialis
`granted provided that the copies are not madeordistributed for
`direct commercial advantage, the ACM copyright notice and the
`title of the publication and its date appear, and notice is given
`that copying is by permission of the Association of Computing
`Machinery.To copy otherwise,or to republish, requires
`a fee and/or specific permission.
`SSR '95, Seattle, WA,USA
`© 1995 ACM 0-89791-739-1/95/0004...$3.50
`
`repositories include ASSET’, CARDS‘, DSRS®, ELSA®, the
`GAMSVirtual Software Repository’, and STARS®. AS-
`SET, CARDS, DSRS, and ELSA are participating in an
`interoperability experiment that allows a user of any one of
`these repositories to access software exported from the other
`repositories.
`The software reuse marketplace is expanding in at least
`two dimensions. One dimension is the expansion from intra-
`organizational reuse to inter-organizational reuse. For ex-
`ample, various federal agencies have established their own
`internal software reuse programs. Several efforts are now
`underway to promote reuse of software across agencies.
`Similarly, companies are becoming interested in accessing
`software produced by academic and government research
`groups. Another dimension of expansion is from reuse within
`a particular application domain to interdisciplinary reuse.
`Reuse of software from other disciplines is being fostered,
`for example, by efforts to solve interdisciplinary Grand Chal-
`lenge problems. Solution of such problems will require col-
`laboration by scientists from different disciplines, as well as
`sharing of software produced by application and computer
`scientists.
`Another recent development that affects the software
`reuse marketplace is the growth of the World Wide Web
`(WWW), together with the ease with which individuals may
`make resources available on a WWW server. A contributor
`need only make the files composing an resource available
`on a file server and make available a descriptive HTMLfile
`containing pointers to the resourcefiles.
`Growth in the popularity of the Internet and the World
`Wide Web, as well as the wide availability of WWW
`client and server software, has accelerated the shift from
`centrally maintained software repositories to virtual, dis-
`tributed repositories. For example, the GAMS Repository,
`once a central repository,
`is now a virtual repository that
`catalogs software maintained by other repositories [2]. Sim-
`ilarly, the NHSEwill provide a uniform interface to a virtual
`HPCCsoftware repository that will be built on top of a dis-
`tributed set of discipline-oriented repositories[5], as shown —
`in Figure 1.
`The main advantage of distributing a repository is to
`
`3 Accessible at http://source.asset.com/
`4 Accessible at http://dealer.cards.com/
`5 Accessible at http://ssed1.ims.disa.mil/srp/dsrspage.html
`5 Accessible at
`http://rbse.mountain.net/ELSA/elsa_lob.html
`7 Accessible at http://gams.nist.gov/
`5 Accessible at
`http://www.stars.ballston.paramax.com/index.html
`
`179
`
`JNPR-FNIN2902900487891
`
`
`
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 3 of 7
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 3 of 7
`
`e The more decentralized and smaller the individual
`repositories become, the less practical it becomes for
`each individual repository to provide the full range of
`search and authentication services.
`
`
`
`Most of the above problems can be alleviated by im-
`plementing a location-independent naming system that in-
`cludes mechanisms for authenticity and integrity checking.
`We have designed a naming system that provides for two
`levels of naming. The binding between a lower-level name
`(called a LIFN) andfile contents is unchangeable and ver-
`ifiable. A lower-level name may be resolved to multiple,
`mirrored copies.
`In the case where it represents a set of
`files, the name may beresolved to a list of other names. A
`higher-level name {called a URN)is associated with a cat-
`aloging record that includes the lower-level nameas well as
`other descriptive information. This record may be crypto-
`graphically signed by the publisher so that users may verify
`the authenticity of a retrieved resource. At any given time,
`a higher-level name is associated with exactly one lower-
`level name, but this binding may change over time. Higher-
`level names allow for long-lived human-readable references,
`while lower-level names permit reliable caching and mirror-
`ing as well as permitting precise references when needed.
`Location-independent names will be the basis of transpar-
`ent mirroring. They will also provide a unique key to which
`third parties may attach value-added information such as
`additional cataloging information and quality assessments.
`This paper describes the design of our naming system. We
`The WWW mechanism ofspecifyingafile by its Uni-
`also describe our implementation of a prototype name-to-
`form Resource Locator (URL)is inadequate for ensur-
`location service and of a modified WWW client that does
`ing the consistency and currency of mirrored copies, as
`name resolution. A glossary of acronyms and terms used in
`a URLfor an independently mirrored copy of a soft-
`this paper is included as an appendix.
`ware package may point to an out-of-date copy and
`give no indication that it is not up-to-date. Further-
`more, mirror copies of a file cannot be located from a
`URLreference, since each copy has a different URL.
`
`Figure 1: Virtual Repository Architecture
`
`allow the software to be maintained by those in the best po-
`sition to keep it up-to-date. Also, copies of popular software
`packages may be mirrored by a numberofsites to increase
`availability (e.g., if one site is unreachable, the software may
`be retrieved from a different site) and to prevent bottlenecks.
`Despite the benefits, distributed maintenance and mir-
`roring of software poses the following challenges.
`
`e Maintaining the quality of software and of indexing
`information and presenting a uniform searching and
`browsing interface become much moredifficult.
`
`2 Related Work
`
`e Consistency between a set of files that are meant to
`be used together must be maintained. For example,
`the Netlib Software Repository provides dependency
`checking that allows the user to retrieve a top-level
`routine plus all routines in its dependency tree (ie.,
`those routines that are called directly or indirectly by
`the top-level routine). Another example is a graph-
`ical parallel programming environment that relies on
`an underlying parallel communications support pack-
`age. The problem becomes more complex when differ-
`ent pieces might be retrieved from different physical
`repositories.
`Ideally, the user should be able to have
`a consistent set retrieved automatically without hav-
`ing to scan documentation to verify that compatible
`pieces have been retrieved.
`
`e As the number of reuse libraries grows, users cannot
`be expected to access each of them separately using
`a different
`interface. Thus, scalable interoperability
`between separately managed repositories is needed.
`
`e In the environment of accessing a few well-established
`repositories that the user knows and trusts, a user
`is assured of the integrity and authenticity of a re-
`trieved file because these properties are provided by
`the administrative procedures of that repository. With
`a large number of less familiar repositories, however,
`it becomes necessary to establish interoperable trust
`mechanisms and to reduce the number of parties with
`whom the user must establish trust.
`
`The use of a public-key encryption technique for authenti-
`cating the source of a software component and for ensuring
`that the component has not been altered subsequent to its
`publication is proposed in [9]. Cryptographic information,in
`the form of a digital signature created by signing the hashed
`digest of the contents of a component, is included within
`the component’s unique identifier. The proposed method
`is intended to prevent not only changes by unauthorized
`parties, but also changes by the original author - i.e., the
`author is not permitted to modify a component without as-
`signing a new unique identifier. The method assumes that
`each author has been assigned aa globally unique Author
`ID, has chosen an asymmetric public/private key pair, and
`has publicized the public key to the community of poten-
`tial re-users. A newly chosen symmetric encryption key is
`used to encrypt the componentitself. Then the symmetric
`key, the hashed digest of the component, and the Author
`ID are concatenated and encrypted using the asymmetric
`private key, and the result is concatenated to the cleart-
`ext version of the Author ID to create the unique identifier
`for the component. The method does not address name-
`to-location resolution, other than to say that the encrypted
`component is madeavailable along with the unique identifier
`and any other cleartext information. The proposed unique
`identifier is similar to our LIFN, and encryption of the hash
`digest and Author ID is similar to our method of having
`the author cryptographically sign a catalogue record that
`includes the author name andthefile’s MD5 signature. Our
`method allows a choice of encryption algorithms, however,
`and allows the digital signature used for authentication to
`
`180
`
`JNPR-FNIN2902900487892
`
`
`
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 4 of 7
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 4 of 7
`
`3
`
`Publishing and Name Assignment
`
`be generated independently andat a different time from the
`cations rather than names, their use as references presents
`component’s identifier.
`at least two problems. One problem is that files get moved,
`Functional requirements for Uniform Resource Names
`changing ther URLs. Then pointers that contain the old
`(URNs) are proposed in [12] by the IETF Uniform Resource
`URLs becomestale. One can leave a forwarding address at
`Identification (URI) Working Group. Accordingto [12], the
`the old URL, but forwarding addresses are an awkward and
`function of a URN is to provide a globally unique, per-
`inelegant solution. Another problem with using URLs as
`references is that mirrored copies offiles cannot be located
`sistent identifier used for recognition of and for access to
`characteristics of a resource or to the resource itself. URN
`from a URLreference, since each copy has a different URL.
`assignment is delegated to naming authorities, the names
`It has been widely recognized that a solution to the
`of which are persistent and globally unique, and who may
`above problemsis to assign location-independent names to
`files and to provide a name-to-location service that, given
`assign names directly or delegate their authority to sub-
`a name, returns a list of locations for that name. A re-
`authorities. Global uniqueness of URNs is guaranteed by
`requiring each naming authority to guarantee uniqueness
`source provider who moves somefiles need only delete the
`within its portion of the URN namespace.
`It is left up to
`old name-to-location bindings and register the new bindings
`with the name-to-location service. Likewise, a site that mir-
`each naming authority to determine the conditions under
`which it will issue a URN (for example, whether or not to
`rors a copy ofafile need only register its location with the
`issue a new URN whenthe contents ofa file change). Some
`name-to-location service. Then a user attempting to retrieve
`test implementations of URNsare underway by members of
`the file corresponding to a location-indcpendent name may
`the URI Working Group at Georgia Tech and Bunyip Cor-
`query the name-to-location service for a list of alternative
`locations to be tried.
`poration ®. The Georgia Tech testbed uses the whois++
`Our work is similar to the IETF’s Uniform Resource
`protocol for URN to URCresolution. A URC, or Uniform
`Resource Characteristic, is a catalog record which includes
`Identifier Working Group's work on Uniform Resource
`Names (URNs) [12] and to CNRI’s work on unique docu-
`locations, or URLs, at which the resource may be accessed.
`ment identifiers for digital libraries [8]. However, neither of
`The URCserver supports searching by other attributes, in
`addition to URN lookup, via the whois++ protocol. A mod-
`these groups has addressed thereliability and consistency is-
`ified version of Mosaic that does URN to URC resolution is
`sues addressed by our two-level naming system. Our system
`available. A proxy server based on CERN httpd that does
`includes a lower-level name a called Location Independent
`File Name (LIFN) and a higher-level namecalled a Uniform
`cacheing by URNSsis also running at Georgia Tech.
`Resource Name (URN).
`As part of the Computer Science Technical Report
`(CSTR) project
`[8], which is developing an architecture
`An important question is whether the byte contents of
`for distributed digital documentlibraries, the Corporation
`the file referred to by a location-independent name should
`for National Research Initiatives (CNRI) is implementing a
`be fixed or be allowed to change.
`If the byte contents are
`name-to-location resolution service called the Handle Man-
`allowed to change, then a further question arises as to what
`agement System (HMS) '°. CNRI’s handleis a name for a
`should be the consistency requirements for alternative loca-
`digital object and is analogous to IETF’s URN. The HMSin-
`tions for the same name. Valid arguments for both cases
`cludes a Handle Generator that a naming authority may run
`can be madefor different situations. For example, for soft-
`and use to create globally unique handles, Handle Servers
`ware resources it is desirable to have an unambiguousrefer-
`that process update requests from naming authorities and
`ence to the fixed byte contents for the purpose of attaching
`query requests from clients to resolve handles, and a Handle
`a review or reporting experimental or performance results.
`Server Directory that maps a handle to the appropriate Han-
`Fixed contents also make it possible to compute a file di-
`dle Server. The distribution of handles to Handle Servers is
`gest that may be cryptographically signed by the author
`based on a hashing algorithm. An electronic mail interface
`of the resource, allowing verification of the integrity of a
`is used by handle administrators to add, delete, and modify
`retrieved file. On the other hand, it is desirable to have a
`handle entrics in the Handle Server database. Clients use
`reference to a software package that need not be changed ev-
`a UDP datagram interface to request location data associ-
`ery time a bug fix or minorrevision takes place, especially
`ated with a handle. A modified version of Mosaic that does
`if the cataloging information (e.g., title, author, abstract)
`handle resolution is available from CNRI. The types of lo-
`does not change. The cataloging information for a software
`package might contain a reference to a Web page describing
`cation information stored by Handle Servers include URL,
`and/or documenting the package. The author of the Web
`repository name, email address, and X.500 Distinguished
`Name. Use of a repository name by a client requires an-
`page would like to be able to update the page without. having
`other round of name-to-location resolution. CNRI’s proper-
`to change all the references to it. A non-software example
`ties record that describes the properties of a digital object
`where it would be desirable to allow contents to changeis
`is analogous to IETF’s URC. The properties record is not
`a namethat refers to a file containing the “current weather
`map”.
`stored by the HMS, but rather by an Information and Refer-
`Because both types of name are needed, we have imple-
`ence (IR) Server that is to be maintained by each repository.
`mented both. The type of namethatrefers to fixed byte con-.
`Each naming authority may also maintain an IR server con-
`taining a properties record for each digital object within its
`tents is called a Location Independent File Name, or LIFN.
`authority.
`Once a LIFN has been assigned to a particular sequence of
`bytes, that binding may not be changed. The type of name
`for which the contents to which it refers may changeis called
`a Uniform Resource Name, or URN.
`We divide the file access system into two levels. The
`upper level is where publishing, cataloging, and searching
`activities take place. These upper-level activities are con-
`cerned with the semantic, or intellectual, contents offiles.
`The lowerlevel is where distribution, mirroring, and caching
`
`Internet-accessible resources are currently referenced using
`Uniform Resource Locators (URLs). Because URLsarelo-
`
`°More information is available at http://www.gatech.edu/ilir/
`18
`10 More
`information
`available
`at
`http://www.cnri.reston.va.us/
`
`181
`
`JNPR-FNIN_2902900487893
`
`
`
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 5 of 7
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 5 of 7
`
`
`
`Figure 2: Publishing steps
`
`any other parties that mirror the resource, must register
`such locations with the appropriate name-to-location lookup
`services. Such name-to-location services are discussed in
`Section 4.
`Thus, publishing a resource involves the following steps,
`shownin Figure 2:
`
`1. creating the resource’s catalog record in the form of a
`URC,
`
`2. signing the catalog record with the publisher’s private
`key,
`
`3. making the resource files available on one or morefile
`servers,
`
`. registering the file locations with the LIFN server,
`
`NHoO. exporting relevant portions of the URC to search ser-
`
`activities occur. These lower-level activities are not con-
`cerned with the semantic contents of files, only with ensur-
`ing that files may be accessed efficiently and that the byte
`contents of files are not corrupted.
`The above arguments about the need for two types of
`name pertain to the upper level. At the lower level, there is
`a need for LIFNs, but not for URNs. Mirrorsites use LIFNs
`and their associated file digests to ensure that their copies of
`files have not been corrupted. A cache site needs to be able
`to tell a user or client program whether it holds a copy of
`a requested file, and for this purpose it can answer whether
`or not it holds a copy of a particular LIFN.
`The above considerations led us to implement LIFNsat
`the lower level of the file access system and URNsat the
`upper level, but to make LIFNs visible at the upper level
`as well. A publisher will be responsible for assigning both
`a URN and a LIFN to any resource for which cataloging
`information is provided. For otherfiles, only LIFNs need be
`provided. At any given time, a URN thatrefers to a file or a
`set of files is associated with exactly one LIFN. A URN may
`be associated with a set of different LIFNs over the URN’s
`lifetime, but we require that the set be in the form ofa linear
`sequence, with the sequence order given by increasing time.
`The LIFN and URN namespaces are subdivided among
`several publishers, also called naming authorities, who are
`responsible for ensuring the uniqueness of names assigned
`within their portions of the name spaces. A nameis formed
`by concatenating the registered naming authority identifier
`with a unique string assigned by the naming authority. The
`LIFN and URNare formatted as
`
`LIFN:<publisher id>:string
`URN: <publisher id>:string
`
`The publisher provides cataloging information for each
`URN it assigns. The catalog record includes information
`such as title, author, abstract, etc. A recommendedset of
`attributes for software assets is given by the Reuse Library
`Interoperability Group (RIG) Basic Interoperability Data
`Model [1]. In addition, the catalogue record for a URN in-
`cludes its currently associated LIFN, as well as an MD5 or
`similar fingerprint for that LIFN. This fingerprint is a 128-
`bit quantity resulting from applying the MD5 function to
`the contents of the file. The function is designed to make
`it computationally infeasible to find a different sequence of
`bytes that produces the same fingerprint
`[10]. To enable
`authentication, the entire description may be cryplograpli-
`cally signed, as discussed in Section 5, Portions of the cat-
`alog record may be exported to resource discovery servers,
`such as a Harvest Broker [3], which provide search services
`based on resource descriptions. The URN exported to the
`search service provides a unique long-lived key, so that de-
`scriptions may be unambiguously associated with a resource,
`and so that a resource turns up at most once in a list of
`search hits.
`For a name to be useful, there must be some means of
`resolving a nameto a location from which the resource can
`be retrieved or accessed. Thus,
`the publisher, as well as
`
`The publisher id portion of the name is used to lo-
`cate appropriate URN and LIFNservers for that publisher.
`Given a URN, a URNserver returns a Uniform Resource
`Citation (URC) for that URN that includes its currently
`associated LIFN, as well as other cataloging information.
`. registering the URC with the URNserver,
`Given a LIFN, a LIFN server returnsalist of locations for
`that LIFN. More information about accessing URCs and
`. Informing mirror sites of the new or updated file,
`files from their URNs and LIFNs may be found in Section
`4.
`
`vices,
`
`Steps 1 and 5 have been discussed above. Steps 2 is discussed
`in Section 5, and Steps 3, 4, and 5 are discussed im Section
`4,
`
`4 NameResolution and File Mirroring
`
`Resources -available from the virtual repository will be
`named by URNs and/or LIFNs,rather than by URLs. Thus,
`WWWclients will need a meansof resolving a URN or LIFN
`to one or more locations, expressed in the form of a URL,
`to be able to access the resource. Access to files is provided
`by conventional file servers, using protocols such as HTTP,
`Gopher, and FTP.
`For a non-file resource, such as a database service, a list
`of locations is associated directly with the URN for that
`resource. For a file resource, such as a file containing a
`piece of software, the relationship between the URN and
`the locations is indirect, via a LIFN — the URNis associated
`with a LIFN,and the LIFNis associated with a list of URLs.
`The LIFN-to-location mapping service is provided by
`a network of LIFN servers, collectively called the LIFN
`database. These servers process queries for locations of
`
`182
`
`JNPR-FNIN2902900487894
`
`
`
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 6 of 7
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 6 of 7
`
` Search request
`User! cnaonURNS)
`
`Client progr
`
`Figure 3: File access steps
`
`A file server can mirror a file by acquiring a copy ofit
`and posting an update to a LIFN serverforthe file’s naming
`authority.
`If a file server moves or deletes a file,
`then it
`would post that information as well.
`It
`is not necessary
`to keep all LIFN servers for a particular naming authority
`perfectly synchronized. Such synchronization would entail
`too much overhead.
`Instead, location updates are posted
`to a any LIFN server and propagated to other peer servers
`using a batch update protocol.
`Updates to the URN server are posted by the publisher
`and by others authorized by the publisher to update the cat-
`alog record for a given URN.In order to ensure a consistent
`linear history of updates to the catalog record for a URN
`(e.g., the sequence of LIFNs associated with that URN),
`replicated URN servers use a master-slave update protocol.
`One of the most important aspects of our use of LIFNs
`is that it assures the user of retrieving the most up-to-date
`copy of a file referenced by a URN, without the overhead
`of a replica control protocol between file servers mirroring
`that file, which in general will not all be under the control of
`the URN’s naming authority. This assurance is modulo the
`time required for the master-slave update protocol for the
`replicated URNservers, butif the user insists on contacting
`the master URN server, he is ensured of getting the most
`up-to-date copy.
`
`5 Authenticity, Integrity, and Consistency of Resources
`
`9}.el Recall from Section 3 that a publisher cryptographically
`
`LIFNs. They also accept updates from file servers contain-
`ing new locations for LIFNs, as well as requests to delete old
`LIFN-to-location mappings. A naming authority may run
`its own LIFN servers, or it may find another organization
`willing to provide the service on its behalf.
`The URNservice is similar to the LIFN service, except
`Authentication of a resource verifies that the resource was
`that it maps a nameeithertoalist of locations or to a URC
`published by its purported publisher. Verifying the integrity
`that includes a LIFN. For fault tolerance and availability,
`of a file ensures that the file has not been modified. Pro-
`the URNservice is also provided by a network of servers.
`visions for authenticity and integrity checking are necessary
`Mappings from naming authority identifiers to URN and
`for a software repository because there have been instances
`LIFN servers are stored in the the Domain Name System
`of software packages stored on a public repository that were
`(DNS) name space, so that a client program can deter-
`modified by intruders to introduce security holes which were
`mine which URN (LIFN) server to query for a particular
`then spread to other systems'!. Our authentication and in-
`URN (LIFN). Our current client uses an ordinary DNS
`tegrity mechanismsare similar to those described in [11] and
`lookup for IP address records. The publisher identifier is
`prepended to the string .LIFN.NETLIB.ORG (for a LIFN)
`or .URN.NETLIB.ORG (for a URN). The resulting string is
`treated as if it were the name of an Internet host, and DNS
`is queried to find the IP addresses of that host. For example,
`to find a LIFN server for the naming authority foo, theclient
`would look up the IP addresses for foo. LIFN.NETLIB.ORG.
`Several IP addresses may belisted for any one naming au-
`thority. Our client attempts to query each IP address until it
`finds one that can satisfy the LIFN or URN lookup request.
`Thus, the steps involved in resolving a URN so as to
`access a copy of thefile it names are as follows, as shown in
`Figure 3:
`
`signs the catalog record for a resource. In the case ofa file re-
`source, this record includes thefile’s LIFN and MD5 finger-
`print. Any client in possession of the publisher’s public key
`can verify the authenticity of the resource description. Pub-
`lishers are expected to widely advertise their public keys to
`makeit difficult for an attacker to substitute rogue keys. In
`addition, publishers may have their keys certified by trusted
`third parties to further establish their authenticity, as in
`
`11].Iasuming that the association between a LIFN anda file
`
`signature (e.g., the MD5 fingerprint) is known to be correct.
`(either because the signature is part of the LIFN or because
`of the description authentication described in the preceding
`paragraph), a client may perform an integrity check on a
`retrieved file by computing the signature for the file and
`comparing it with the one known tobe associated with the
`file’s purported LIFN. Recall from Section 4 that a LIFN -
`server returns a list of locations for a given LIFN but does
`not guarantee the correctness of those locations. A location
`may be incorrect if it no longer exists or if the contents of
`that location are wrong. In the former case, no file will be
`returned from that location. The latter condition may be
`detected by the client performing an integrity check.
`To ensure consistency within a group of related files, we
`allow a URNtorefer to a set offiles. There are at least two
`
`1. Use DNS to locate an appropriate URN server.
`
`2. Query the URNserver to retrieve the URC which con-
`tains the currently associated LIFN.
`
`3. Authenticate the URC if desired.
`
`4, Use DNSto locate an appropriate LIFN server.
`
`5. Query the LIFN serverto retrieve a list of locations.
`6. Choose a location from which to retrieve thefile.
`
`In practice, Steps 4 through 6 will often be replaced by using
`the LIFN to access a local cache server. Because the binding
`between a LIFN and the byte contents it points to is fixed,
`the cached copy is sure to be correct.
`
`11 For an example, see the CERT advisory at ftp://ftp.cert.org
`/pub/cert_advisories/CA-94:07.wuarchive.ftpd.trojan.horse
`
`183
`
`JNPR-FNIN_2902900487895
`
`
`
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 7 of 7
`Case 3:17-cv-05659-WHA Document 96-19 Filed 06/07/18 Page 7 of 7
`
`cases where this might occur. One case is where a resource
`consists of a numberofrelated files, for example the files
`making up a software package. Of course, such a set offiles
`could be made available instead as a single tar file.
`If a
`file can be used in more than one package, however, or if
`somefiles are also of use individually, it might be preferable
`to make thefiles available separately. Another case is when
`there are alternative versions ofa file — for example, multiple
`precisions of a Fortran routine, or multiple formats of an
`image.
`Thefirst case is handled by ordering the files making up
`the resource and considering the ordered list of LIFNs for
`these files to be the contents of another file which wecall
`the composite-parts-list for the resource. The composite-
`parts-list file itself has a LIFN, and it is this LIFN that is
`associated with the URN for the resource. The second case
`is handled in a similar manner, but the file containing the
`ordered list of LIFNsis called the alternative-parts-list
`for the resource. The parts-list may contain additional in-
`formation, such as how the alternative parts vary. After
`retrieving a parts-list, the client program will invoke a spe-
`cial module for handling it, similar to how current browsers
`invoke viewers for image or soundfiles. This module will
`assist the user in retrieving the componentfiles and saving
`or displaying them locally.
`
`6 Prototype Implementation
`
`The naming system is being implemented as part of the
`Bulk File Distribution (BFD) package. BFD is part of the
`implementation of the National HPCC Software Exchange
`(NHSE), which is being developed by the Center for Re
`search in Parallel] Computing (CRPC), a consortium of uni-
`versities and national laboratories formed to make high per-
`formance and parallel computing accessible to engineers and
`scientists. BFD URN and LIFNservers will