One document matched: draft-clynn-bgp-x509-auth-01.txt
Differences from draft-clynn-bgp-x509-auth-00.txt
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)",
<draft-ietf-idr-bgp4-08.txt>, 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]
| PAFTECH AB 2003-2026 | 2026-04-23 05:51:10 |