Internet Engineering Task Force Charles Lynn Internet Draft BBN Technologies draft-clynn-bgp-x509-auth-01.txt October 1999 X.509 Extensions for Authorization of IP Addresses, AS Numbers, and Routers within an AS Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". The list of current Internet Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of current Internet Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document documents formats for three X.509 v3 Certificate extensions proposed for use with Secure BGP (S-BGP) draft-clynn-s- bgp-protocol-00.txt, and requests discussion and suggestions for improvements. Please send comments on this draft to CLynn@BBN.Com. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright (C) The Internet Society 1999. All Rights Reserved. Abstract This document defines three X.509 v3 Certificate Extensions. The first binds a list of IP Address blocks to the public key of the subject of a certificate. The second binds a list of Autonomous System Numbers to the public key of the subject of a certificate. The third binds a BGP Router Identifier and an Autonomous System Number to the public key of the subject of a certificate. Third parties, e.g., BGP routers, may use these certificates to verify that the holder of the private key corresponding to the public key in the certificate has been properly authorized to use resources specified in the certificate extension. Expires April 2000 CLynn [Page 1] Internet Draft X.509 Extensions for Authorization October 1999 Table of Contents Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2 Table of Figures . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. X.509 Certificate Extensions . . . . . . . . . . . . . . . . 4 2. PKI for IP Address Allocation . . . . . . . . . . . . . . . . 4 2.1. IP Address Block Certificate Extension . . . . . . . . . . . 6 2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Certification Path Verification . . . . . . . . . . . . . . 7 3. PKI for Assignment of ASes and Router Associations . . . . . . 8 3.1. Autonomous System Number Extension . . . . . . . . . . . . . 9 3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Certification Path Verification . . . . . . . . . . . . . 10 3.2. Router Authorization Certificate Extension . . . . . . . . . 10 3.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Certification Path Verification . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property Rights . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 14 Author's Addresse . . . . . . . . . . . . . . . . . . . . . . . . 14 Table of Figures Figure 1: IP Address Assignment PKI Hierarchy . . . . . . . . . 5 Figure 2: AS Number Assignment and Router PKI Hierarchy . . . . 8 Expires April 2000 CLynn [Page 2] Internet Draft X.509 Extensions for Authorization October 1999 1. Introduction Internet routing is based on a distributed system composed of many routers, grouped into management domains called Autonomous Systems (ASes). Routing information is exchanged between ASes in Border Gateway Protocol (BGP) [RFC1771, BGP4] UPDATE messages. BGP has proven to be highly vulnerable to a variety of attacks [Murphy], due to the lack of a scalable means of verifying the authenticity and legitimacy of BGP control traffic. Verification of the legitimacy of the control traffic requires that several conditions be met. Some of the conditions are: * The AS number of each peer in a BGP peering session has been authorized for use and to be a neighboring AS. * The peer that sends an UPDATE was authorized to act on behalf of its AS to advertise the routing information contained within the UPDATE to BGP peers in the recipient AS. * The AS that originates an UPDATE was authorized, by the owners of the address space corresponding to the set of reachable destinations, to advertise those destinations. * The owner of an address space corresponding to a reachable destination advertised in an UPDATE was authorized by its parent organization to own that address space. Checking these conditions requires a mechanism that can be used to verify: the ownership of IP Address Prefixes, the ownership of AS Numbers, and the authorization of a router to represent an AS. The mechanism must scale to the projected number of address prefixes, AS numbers, and inter-AS routers in the Internet. Due to the distributed nature of Internet routing, the entities that are checking the conditions will generally be unknown to the entities that own these resources, and thus any mechanism that requires a peer to peer security relationship between the entities will not meet the scaling requirements. Public Key Infrastructures (PKIs) have been designed to solve such problems. PKIs can be created, rooted at the Internet Corporation for Assigned Names and Numbers (ICANN, formerly IANA), that corresponds to the assignment delegation system for IP address prefixes and AS numbers that is currently used in the Internet. This document describes these PKIs and defines the X.509 Certificate Extensions that they use to convey the necessary authorizations. See [RFC2459] for a more complete description certificates, CRLs, and the PKIX X.509 profile. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, Expires April 2000 CLynn [Page 3] Internet Draft X.509 Extensions for Authorization October 1999 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 1.1. X.509 Certificate Extensions Version 3 of X.509 [X.509] provides an extensible mechanism to include application specific information in certificates. Each extension contains three elements: an OBJECT IDENTIFIER that is associated with the syntax of the application specific data, a BOOLEAN that indicates if the certificate user must reject the certificate if it does not properly process the extension, and the application specific data encoded in an OCTET STRING. The ASN.1 specification for an X.509 v3 Certificate Extension is: Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER , -- identifies extnValue syntax critical BOOLEAN DEFAULT FALSE , -- must reject if unknown extnValue OCTET STRING } -- application specific data 2. PKI for IP Address Allocation A certificate will be issued to each organization that is given ownership of a portion of the IP address space. This certificate is issued through a hierarchy of entities that, in the physical environment, is responsible for address allocation. The root of this hierarchy is ICANN, and includes at lower layers regional address space allocation authorities (e.g., APNIC, ARIN, RIPE), Internet Service Providers (ISPs), Down Stream Providers (DSPs), and subscribers owning IP address prefixes. Note, however, that address assignments do not have to be certified all the way to every subscriber. If a subscriber's address is allocated from that of a DSP or an ISP with which it is currently affiliated, then the certification process need only be effected as far as the DSP/ISP. The same applies to DSPs that receive their address space assignments from ISPs. This PKI reflects the assignment of address blocks to organizations by binding address blocks to a public key belonging to the organization to whom the addresses are being assigned. It has the possible drawback that this violates the "assumption" that for a typical X.509 certificate, the issuer is vouching for the identity of the subject. Instead, these certificates will be used for proving ownership of a block of addresses. In Figure 1 below, (a) ICANN is the root and issues certificates to the first tier of organizations (Org1_x). At present, Org1_x could be an Internet Expires April 2000 CLynn [Page 4] Internet Draft X.509 Extensions for Authorization October 1999 Registry, an ISP, an organization, etc. ICANN signs the tier 1 certificates using its private key. A certificate extension is used to specify a list of address families and address blocks. The alternate name in the certificate is the DNS name of the organization. (b) Org1_x then assigns sub-blocks of its address space to ISPs, DSPs, etc. In the diagram, for example, Org1_1 issues a certificate to each of Org2_1 through Org2_7 while Org1_N issues a certificate to Org2_8. Org1_x signs the certificate using the private key corresponding to the public key in the certificate it received in (a). The same certificate extension as in (a) is used to specify a list of address families and address blocks to be delegated to ISPs, DSP, etc. The alternate name in the certificate is the DNS name of the organization. (c) Org2_x then assigns sub-blocks of its address space to DSPs, customers, etc. In the diagram, Org2_1 issues a certificate to each of Org3_1 through Org3_4. Org2_x signs the certificate using the private key corresponding to the public key in the certificate it received in (b). The same certificate extension is used to specify a list of address families and address blocks to be delegated to organizations. The alternate name in the certificate is the DNS name of the organization. (d) And so on.... ICANN Addr block(s) | +----------------+---------+++---------+ | | ||| | Org1_1 Org1_2 ... Org1_N Addr block(s) Addr block(s) Addr block(s) | | +--------+++--------+ | | ||| | | Org2_1 ... Org2_7 Org2_8 Addr block(s) Addr block(s) Addr block(s) | +--------+++--------+ | ||| | Org3_1 ... Org3_4 Addr block(s) Addr block(s) Org1_x = a 1st tier organization, e.g., an Internet Registry Org2_x = a 2nd tier organization, e.g., an ISP or organization Org3_x = a 3rd tier organization, e.g., an organization or DSP Figure 1: IP Address Assignment PKI Hierarchy Expires April 2000 CLynn [Page 5] Internet Draft X.509 Extensions for Authorization October 1999 2.1. IP Address Block Certificate Extension X.509 v3 Certificate Extension with OID XXX is used to bind the subject organization and its public key to one or more address prefixes. This extension is CRITICAL since, for a given certificate, the certificate user must verify that all prefixes and address ranges present in the extension are subsets of those present in the certificate of the certificate authority that signed the given certificate. IPAddressRanges ::= SEQUENCE OF IPAddressRange IPAddressRange ::= SEQUENCE { addressFamily OCTET STRING, addressRanges IPAddresses } -- may be repeated IPAddresses ::= CHOICE { prefixList [0] OCTET STRING, addressRange [1] OCTET STRING } The type of address is specified by the addressFamily OCTET STRING. The values of the Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) are specified on the IANA web page http://www.iana.org under the "Address Family Numbers" item, or in [RFC1700]. The 16-bit AFI and 8-bit SAFI are encoded as three octets: two octets of AFI followed by a single octet of SAFI (see [RFC2283]). The addressRanges element may appear multiple times. Each instance is either a list of address prefixes, or an address range specified by minumum and maximum address. Both the prefixes and the minimum and maximum address in a range are encoded as specified in the "NLRI encoding" section of the BGP-4 protocol specification [RFC1771]: each prefix is encoded as a one-octet count of significant (left-most) bits (0 to 255) in the prefix, followed by as many address prefix octets as are required to hold that many bits. The value of any bits beyond those specified in the count octet MUST be zero. However the interpretation of the maximum address is that all bits beyond those specified in the count octet are 1s. Within the addressRange, the minimum and maximum addresses MUST have identical values for the count octet. The both the IPAddresses and the prefixes within the prefixList OCTET STRING MUST be jointly sorted in ascending order by IP address (not by the prefix length octet). Expires April 2000 CLynn [Page 6] Internet Draft X.509 Extensions for Authorization October 1999 2.2. Examples An extension that specifies net 10, i.e., 10/8 or addresses 10.0.0.0 through 10.255.255.255 would be (in hexadecimal): 30 len Extension 06 len XXX extnID OBJECT IDENTIFIER 01 01 FF critical BOOLEAN TRUE 04 0D extnValue OCTET STRING 30 0B IPAddressRanges 30 09 IPAddressRange 04 03 00 01 01 addressFamily -- IPv4 Unicast 80 02 08 0A prefixList -- 10/8 An extension specifying 10/8, 172.16/12, 192.168/16 and 5800::/8 would be: 30 len Extension 06 len XXX extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN -- TRUE 04 30 extnValue OCTET STRING } 30 1E IPAddressRanges 30 1C IPAddressRange 04 03 00 01 01 addressFamily -- IPv4 Unicast 80 08 08 0A prefixList -- 10/8 0C AC 10 -- 172.16/12 10 C0 A8 -- 192.168/16 30 09 IPAddressRange 04 03 00 02 01 addressFamily -- IPv6 Unicast 80 02 08 58 prefixList -- 5800::/8 An extension specifying 10.16.0.0 to 10.63.255.255 would be: 30 len Extension 06 len XXX extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN TRUE , 04 11 extnValue OCTET STRING } 30 0F IPAddressRanges 30 0D IPAddressRange 04 03 00 01 01 addressFamily -- IPv4 Unicast 81 06 0C 0A 10 addressRange -- min 10.16.12 0C 0A 30 -- max 10.48/12 2.3. Certification Path Verification During certification path verification of a certificate containing the IP Address Block Extension, additional processing is required. Each preceding certificate in the certification path must contain an IP Address Block Extension that contains all of the IP Address Block(s) in the certificate being verified, recursively, until a Expires April 2000 CLynn [Page 7] Internet Draft X.509 Extensions for Authorization October 1999 trusted certificate has been verified. 3. PKI for Assignment of ASes and Router Associations Two types of certificates will be used to support the authentication of ASes, BGP speakers and the relationship between speakers and ASes. As shown in Figure 2 below, these certificates bind together: (a) one or more a blocks of AS numbers and an organization's public key -- a registry issues these to organizations and signs them using its private key. The alternate name in the certificate is the DNS name of the organization. An extension contains the (list of) AS number(s). (b) an AS number and its public key -- An organization owning an AS number issues these and signs them using the private key corresponding to the public key in the certificate described in (a). The certificate extension containing the AS nubmer is the same as is used in (a). The alternate name in the certificate is the DNS name of the organization. ICANN list of AS#s | +++---------+---------+++ ||| | ||| ... Registry ... list of AS#s | +---------------+-------+++--------+ | | ||| | Org-1 Org-2 ... Org-N list of AS#s list of AS#s list of AS#s | +------------------+ | | +----+++---+ +-----+++-----+ | ||| | | ||| | AS-1 ... AS-N Rtr-1 ... Rtr-N AS# AS# AS-1 AS-N RtrId-1 RtrId-N Org-N = DNS Name of ISP/DSP/Organization N AS-N = DNS Name of Autonomous System N Rtr-N = DNS Name of router N RtrId-N = Router identifier (IP address) of router N Figure 2: AS Number Assignment and Router PKI Hierarchy Expires April 2000 CLynn [Page 8] Internet Draft X.509 Extensions for Authorization October 1999 (c) a router (DNS) name, a router id, an AS number, and the router's public key -- An organization owning the AS number of the AS of the router issues these and signs them using the private key corresponding to the public key in the certificate described in (a). Note that both the router id (an IP address) and the AS number are extensions in this certificate, and the binding of three items is a critical aspect of this certificate. The alternate name in the certificate is the DNS name of the router corresponding to the router id. 3.1. Autonomous System Number Extension X.509 v3 Certificate Extension with OID YYY is used to bind the subject organization and its public key to one or more Autonomous System Number ranges. An Autonomous System Number is currently an unsigned 16-bit unsigned quantity, but may be enlarged in the future, e.g., IDRP Routing Domain Identifiers are 32 bits. Each ASNumberRange specifies identifiers of a given signle length, which is specified in the itemSize element as a byte count. Items within an ASNumberRange MUST be sorted in increasing numerical order. This extension is CRITICAL since, for a given certificate, all Autonomous System number ranges present in the extension must be subsets of those present in the certificate of the certificate authority that signed the given certificate. Each range of Autonomous System Numbers is encoded as an OCTET STRING with the minimum value in the range preceeding the maximum value. If a single Autonomous System Number is being specified the maximum value is omitted from the OCTET STRING. ASNumberRanges ::= SEQUENCE OF ASNumberRange ASNumberRange ::= SEQUENCE { itemSize INTEGER, -- bytes per value ASNumbers OCTET STRING } -- min [max], may be repeated 3.1.1. Example An extension that specifies Autonomous System Numbers 3000 to 3999 would be (in hexadecimal): Expires April 2000 CLynn [Page 9] Internet Draft X.509 Extensions for Authorization October 1999 30 len Extension 06 len yyy extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN TRUE , 04 0D extnValue OCTET STRING } 30 0B ASNumberRanges 30 09 ASNumberRange 02 01 02 itemSize -- 2 04 04 0b b8 -- minimum 3000 0f 9f -- maximum 3999 An extension that specifies Autonomous System Numbers 10, 100, 1000 and Routing Domain Identifiers 100000 199999 would be (in hexadecimal): 30 len Extension 06 len yyy extnID OBJECT IDENTIFIER , 01 01 FF critical BOOLEAN TRUE , 04 22 extnValue OCTET STRING } 30 20 ASNumberRanges 30 0f ASNumberRange 02 01 02 itemSize -- 2 04 02 00 0a -- minimum 10 04 02 00 64 -- minimum 100 04 02 03 e8 -- minimum 1000 30 0d ASNumberRange 02 01 02 itemSize -- 4 04 08 00 01 86 a0 -- minimum 100000 00 03 0d 3f -- maximum 199999 3.1.2. Certification Path Verification During certification path verification of a certificate containing the Autonomous System Number Extension, additional processing is required. Each preceding certificate in the certification path must contain an Autonomous System Number Extension that contains all of the Autonomous System Number(s) in the certificate being verified, recursively, until a trusted certificate has been verified. 3.2. Router Authorization Certificate Extension X.509 v3 Certificate Extension with OID ZZZ is used to bind the subject router (specified, e.g., by a DNS name), its public key, its BGP Router Identifier (currently a 32-bit IPv4 address), and the number of the Autonomous System of which the router is an authorized BGP speaker. This extension is not CRITICAL. Currently, the owningASNumber OCTET STRING would have a length of two and the routerId OCTET STRING a length of four. Expires April 2000 CLynn [Page 10] Internet Draft X.509 Extensions for Authorization October 1999 RouterIdentifiers ::= SEQUENCE { owningASNumber OCTET STRING, routerId OCTET STRING } 3.2.1. Example An extension in the certificate for a router with BGP Router Identifier 10.0.0.1 in Autonomous System 3456 would be (in hexadecimal): 30 len Extension 06 len zzz extnID OBJECT IDENTIFIER , critical BOOLEAN DEFAULT FALSE , 04 0C extnValue OCTET STRING } 30 0A RouterIdentifiers 04 02 0d 80 owningASNumber 04 04 0A 00 00 01 routerId 3.2.2. Certification Path Verification During certification path verification of a certificate containing the Router Authorization Extension, additional processing is required. The issuer's certificate must contain an Autonomous System Number Extension that contains the owningASNumber in one of its ASNumberRange elements. 4. Security Considerations This specification is devoted to the format and encoding of three extensions for X.509 certificates. Since certificates are digitally signed, no additional integrity service is necessary. Certificates need not be kept secret, and unrestricted and anonymous access to certificates and CRLs has no security implications. However, security factors outside the scope of this specification will affect the assurance provided to certificate users. This section highlights critical issues that should be considered by implementors, administrators, and users. The procedures performed by CAs and RAs to validate the binding of the subject's identity and their public key greatly affects the assurance that should be placed in the certificate. Certificate users may wish to review the CA's certificate practice statement to determine what level of assurance, if any, may be associated with the identity of the subject of the certificate. The protection afforded private keys is a critical factor in maintaining security. Failure of organizations or routers to protect Expires April 2000 CLynn [Page 11] Internet Draft X.509 Extensions for Authorization October 1999 their private keys will permit an attacker to masquerade as them. The availability and freshness of revocation information will affect the degree of assurance that should be placed in a certificate. While certificates expire naturally, events may occur during its natural lifetime which negate the binding between the subject and either public key or the information in the extension. If revocation information is untimely or unavailable, the assurance associated with the bindings is clearly reduced. Similarly, implementations of the additional Certification Path Verification mechanisms described in sections 2.3, 3.1.2, and 3.3.2 that omit revocation checking provide less assurance than those that support it. Certification Path Verification depends on the certain knowledge of the public keys (and other information) about one or more trusted CAs. The decision to trust a CA is an important decision as it ultimately determines the trust afforded a certificate. The authenticated distribution of trusted CA public keys (usually in the form of a "self-signed" certificate) is a security critical out of band process that is beyond the scope of this specification. In addition, where a key compromise or CA failure occurs for a trusted CA, the user will need to modify the information provided to the Certification Path Verification routine. The quality of implementations that process certificates may also affect the degree of assurance provided. Certification Path Verification relies upon the integrity of the trusted CA information, and especially the integrity of the public keys associated with the trusted CAs. By substituting public keys for which an attacker has the private key, an attacker could trick the user into accepting false certificates. The binding between a key and resources specified in the certificate extension cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. 5. Acknowledgements Get your name here -- provide feedback 6. References [BGP4] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", , August 1998. [Murphy] S. Murphy, "BGP Security Analysis", draft-murphy-bgp- secr-03.txt, June 1998. Expires April 2000 CLynn [Page 12] Internet Draft X.509 Extensions for Authorization October 1999 [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. (see also http://www.iana.org/iana/assignments.html) [RFC1771] Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 00009, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC2283] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Extensions for BGP-4", February 1998 [RFC2459] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [X.509] ITU-T Recommendation X.509 (1997 E): "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", June 1997. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurance of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires April 2000 CLynn [Page 13] Internet Draft X.509 Extensions for Authorization October 1999 Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Author's Addresses Charles Lynn BBN Technologies 10 Moulton St. Cambridge, MA 02138 CLynn@BBN.Com Expires April 2000 CLynn [Page 14]