Internet Engineering Task Force Brian Weis, Editor INTERNET-DRAFT Cisco Systems draft-weis-sobgp-certificates-03.txt Expires: July, 2005 February, 2005 Secure Origin BGP (soBGP) Certificates Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the format of digital certificates that are used by the Secure Origin BGP (soBGP) extensions to BGP, as well as acceptable use of those certificates. Included are certificates providing authentication, authorization, and policy distribution. Weis Expires July, 2005 [Page 1] Secure Origin BGP (soBGP) Certificates February, 2005 Table of Contents 1.0 Introduction......................................................3 1.1 Key Words.......................................................3 1.2 Terminology.....................................................3 2.0 Overview..........................................................4 2.1 Digital Signature Algorithms....................................6 3.0 Authentication Certificate (Entitycert)...........................6 3.1 Format..........................................................7 3.2 Creation........................................................7 3.3 Distribution....................................................9 3.4 Validation......................................................9 3.5 Revocation and Expiration......................................12 4.0 Authorization and Policy Certificates............................12 4.1 Authorization Certificates (Authcert)..........................12 4.2 Prefix Policy Certificates (PrefixPolicycert)..................16 4.3 AS Policy Certificates (ASPolicycert)..........................19 4.4 Common Processing..............................................21 5.0 Authorization and Policy Certificate Attributes..................21 5.1 Certificate Header (HDR).......................................21 5.2 The Originating Autonomous System (ORIG-AS)....................22 5.3 Authorized Autonomous System (AUTH-AS).........................22 5.4 The Serial Number (SN).........................................23 5.5 Originating AS Entitycert URL (ORIG-EC-URL)....................23 5.6 Originating AS ASPolicycert URL (ORIG-AP-URL)..................23 5.7 The Address Prefix (PREFIX)....................................24 5.8 Signature (SIG)................................................25 5.9 Authorization Certificate (AUTHCERT)...........................26 5.10 Prefix Policies (P-POLICY)....................................26 5.11 Attached Transit Autonomous Systems (TRANSIT).................27 5.12 Attached Non-transit Autonomous Systems (NON-TRANSIT).........28 5.13 Revoked Entity Certificate List (EC-CRL)......................29 5.14 Authorization Certificate Validity List (AC-VALID)............30 5.15 Prefix Policy Certificate Validity List (PPC-VALID)...........31 6.0 Security Considerations..........................................31 6.1 Entitycerts....................................................31 6.2 Authcerts......................................................32 6.3 PrefixPolicycerts..............................................32 6.4 ASPolicycerts..................................................33 6.5 Entitycert Uniform Resource Locators...........................33 7.0 IANA Considerations..............................................33 7.1 soBGP Certificate Attribute Values.............................33 7.2 Signature Type.................................................33 7.3 Policies Type..................................................34 7.4 Validity Ranges................................................34 8.0 Acknowledgments..................................................34 9.0 References.......................................................35 Weis Expires July, 2005 [Page 2] Secure Origin BGP (soBGP) Certificates February, 2005 9.1 Normative References...........................................35 Appendix A. Example Certificates.....................................36 A.1. Entitycert....................................................36 A.2. Authcert......................................................39 Editor's Address.....................................................40 Full Copyright Statement.............................................40 1.0 Introduction There is a great deal of concern over the security of routing systems within the Internet. This is particularly true in relation to the Border Gateway Protocol [BGP], the protocol used to provide routing information between Autonomous Systems (ASes). Secure Origin BGP (soBGP) provides a method that ASes can use to determine the correctness of BGP messages received by their BGP routers. It also provides a method for ASes to detect implausible routes reported in a BGP Update AS_PATH, and acts as an aid in detecting misconfigured routers advertising incorrect routes. Secure Origin BGP does not define changes to BGP Updates. Rather, it provides authorization and path policy "out-of-band" from the BGP Updates. An AS compares the information claimed in BGP Updates to the soBGP policy, and makes judgments to the fitness of the claim. Secure Origin BGP distributes authorization and policy as digitally signed objects, which can be distributed in many ways. To aid interoperability, extensions have been defined in [SOBGP-BGP] that support distribution of the digitally signed soBGP objects within BGP itself. The Secure Origin BGP architecture is discussed in [SOBGP-ARCH]. That document describes the operation of soBGP, and various deployment models. Extensions to RADIUS to support soBGP in some of those deployment modelsare defined in [SOBGP-RADIUS]. This document defines the format of the digitally signed objects used by soBGP, as well as the operations to be performed on those objects. Furthermore, a trust model under which the soBGP digitally signed objects can be arranged is described. 1.1 Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Terminology This document frequently uses the following terms: AS Policy Certificate (ASPolicycert) A digital certificate that asserts routing policy for an Autonomous System. Weis Expires July, 2005 [Page 3] Secure Origin BGP (soBGP) Certificates February, 2005 Authorization Certificates (Authcerts) A digital certificate that asserts that an Autonomous System is authorized to advertise a particular prefix. Entity Institutional participants within soBGP. These include Regional Internet Registry (RIR) authorities, Local Internet Registry (LIR) authorities, Internet Service Providers (ISPs), Certificate Authorities (CAs), and other organizations participating in soBGP. Most Entities participate in the routing system. An soBGP Entity must have an Autonomous System (AS) number assigned to it as a unique identity, even if it does not source routes within the routing system. Entity Certificate (Entitycert) An X.509 certificate that asserts a mapping between an Autonomous System identifier and a public key. Prefix Policy Certificate (Prefixpolicycert) A digital certificate mapping usage policy to one or more prefixes. Regional Internet Registry (RIR) An entity recognized by IANA and tasked with managing IP address space within a wide geographical area. RIRs allocate address space to Local Internet Registries and other entities. Local Internet Registry (LIR) An entity that allocates address space to the users of the network services that it provides. 2.0 Overview Secure Origin BGP refers to participants within the routing system as entities. Entities may have one or more roles within soBGP. They may act as a trusted signer of digital certificate, an authorizer of address blocks, and/or as a route originator. Each entity must have an Autonomous System (AS) number, issued from an authorized entity (e.g., Regional Internet Registry), to participate in soBGP. The AS number is the primary method of identification with soBGP. All entities are known by their AS number, even those that may not ordinarily advertise routes (e.g., a Certificate Authority). Secure Origin BGP provides a method of verifying that an AS is authorized to advertise certain prefixes. The authorization to advertise prefixes or a given address space is validated through Authorization Certificates (Authcerts). Authcerts are digitally signed objects issued by entities (e.g., ISPs) that provide proof of prefix allocation . Weis Expires July, 2005 [Page 4] Secure Origin BGP (soBGP) Certificates February, 2005 An AS given an Authcert (e.g., an ISP customer) may assign local policy to be used with the prefixes listed in the Authcert. The AS does this by issuing another type of digitally signed object, called a Prefix Policy Certificate (PrefixPolicycert). Policies specific to an Autonomous System are provided through AS Policy Certificates (ASPolicycerts). This policy enables another entity to develop a database of plausible paths through the routing system, and aids in detecting impossible and fraudulent paths. It also provides a means for the AS to distribute Certificate Revocation Lists for Entitycerts that it has signed, and Validation Lists that describe which authorization and policy certificates are valid for the AS. Authcerts, PrefixPolicycerts, and ASPolicycerts are verified using public keys embedded in Entity Certificates (Entitycerts). Entitycerts are X.509 certificates as specified by [RFC3280]. Figure 1 illustrates the relationship between soBGP certificates associated with a single AS (AS 2). An arrow in this figure indicates a signature operation. The public key contained in the certificate at the tail of the arrow is used to verify the validity of the certificate at the head of the arrow. +-----+------+ | AS 1 | +-------| Entitycert | / +------------+ / | + | | | v v +-------+--+ +-----+------+ +------------------+ | AS 2 | | AS 2 | | AS 2 | | Authcert | | Entitycert |-------> | PrefixPolicycert | +----------+ +------------+ +------------------+ | | +------------------+ | | AS 2 | +---------> | ASPolicycert | +------------------+ Figure 1. Relationship between soBGP certificates associated with a single Entity (AS 2) Weis Expires July, 2005 [Page 5] Secure Origin BGP (soBGP) Certificates February, 2005 In Figure 1, AS 1 allocates a prefix to AS 2. AS 1 also issues an Authcert to AS 2 proving that AS 2 may legitimately use that prefix. In this example, AS 1 also acts as an Entitycert issuer for AS 2. AS 2 then creates two policy certificates: one specifying particular policy for the authorized prefix, and one specifying particular policy for the AS. Each of the soBGP certificates is discussed in detail in subsequent sections of this document. 2.1 Digital Signature Algorithms The RSA Public Key Algorithm [RSA] is a widely deployed public key algorithm commonly used for digital signatures. Compared to other public key algorithms, signature verification is efficient. This property is useful considering the large number of signature verifications that will be done on soBGP certificates. The RSA Algorithm is commonly supported in hardware, and is not encumbered by any known intellectual property claims. All soBGP implementations MUST support a digital signature of a SHA1 digest encrypted with the RSA algorithm. An implementation MAY support other signature methods, but any AS using alternate signature methods run the risk of their signatures not being universally verifiable. 3.0 Authentication Certificate (Entitycert) Entitycerts provide authentication, providing a binding of an identity (i.e., autonomous system number) to a public key. The authenticity of the binding is verified with a digital signature, where the public key of the certificate issuer has been previously accepted by an receiver as valid. Issuer public keys can either be manually configured, or are verified through the use of another issuer's trusted public key Entitycerts are used to verify, through a trust model, the existence of an entity within the routing system, and the value of that entity's public key for use in the routing system. Various trust models are possible, but a "web of trust" trust model is preferred because it lends itself to incremental deployment. For more discussion a web of trust, see Section 3.4.1. Each entity within the routing system participating in soBGP MUST generate a public/private key pair. The public key portion of this pair is then signed, verifying that anyone using this public key is actually the entity in question. This signature may be provided by various other trusted parties within the routing system, including (but not limited to): - The authority that issued the autonomous system number. Weis Expires July, 2005 [Page 6] Secure Origin BGP (soBGP) Certificates February, 2005 - An external commercial authority that provides digital certificates for other commercial transactions. - Any other trusted party within the domain of Internet routing, such as a well known Service Provider. - Self-signed if the entity is well known within the routing system. A public key is used to verify the validity of other messages transmitted by this entity within the routing system. The public key, along with other verifying information, is formatted into an Entitycert, as described in the next section. 3.1 Format An Entitycert MUST be formatted as an X.509 certificate, as defined in [RFC3280]. The Entitycert MUST be generated with a signature of type sha1withRSAEncryption [RFC3279]. The primary identity in soBGP is the autonomous system number. Because of this, each entity that issues Entitycerts MUST be assigned an AS number, even if they do not originate routes into the internetwork. In accordance with Section 4.2.1.7 of [RFC3280], issuers MUST verify all parts of the subject alternative name, including the AS number, before issuing the certificate. An Entitycert MUST have a subjectAltname critical extension, which MUST contain the AS number of the subject as an otherName choice. The AS number is encoded with the OID defined in Section 3.2.1 of [RFC3779]. An Entitycert MUST have an issuerAltname critical extension, which MUST contain the AS number of the issuer as an otherName choice. The AS number is encoded with the OID defined in Section 3.2.1 of [RFC3779]. The X.509 Issuer and Subject distinguished names are not used by soBGP. In accordance with Section 4.2.1.7 of [RFC3280], when subjectAltName is required, the Subject field MAY be empty. 3.2 Creation An Entitycert is usually created with the following steps: - The entity requesting an Entitycert generates a signature key pair - The entity forwards its identity (including its AS number) and the public key to an Entitycert issuer using the certificate registration mechanism supported by the issuer. - The issuing autonomous system verifies that the identity of the receiving autonomous system, generates an Entitycert including that identity, and signs it with its own private key. Weis Expires July, 2005 [Page 7] Secure Origin BGP (soBGP) Certificates February, 2005 - The issuing autonomous system returns the Entitycert to the receiving autonomous system. When an Entitycert is created, care should be taken as to whether the Entitycert is authorized to become a CA for other entities. If the signer authorizes the Entity to become a Certificate Authority for other entities, then the following X.509v3 Certificate Extensions MUST be included in an Entitycert: . Key Usage: The keyCertSign and cRLSign bits MUST be set. The digitalSignature bit MUST be set, so that the public key in the certificate may also be used for validating other soBGP certificates. [Section 4.2.1.3, RFC3280] . Basic Constraints: The cA Boolean MUST be set, and pathLenConstraint MAY be set in order to restrict the length of the certification path below this certificate. [Section 4.2.1.10, RFC3280] If the signer does NOT authorize the Entity to become a Certificate Authority for other entities, then the following X.509v3 Certificate Extensions MUST be included in an Entitycert: . Key Usage: The keyCertSign and cRLSign bits MUST NOT be set. The digitalSignature bit MUST be set, so that the public key in the certificate may also be used for validating other soBGP certificates. [Section 4.2.1.3, RFC3280] . Basic Constraints: The cA Boolean MUST NOT be set. [Section 4.2.1.10, RFC3280] 3.2.1 Certificate Uniqueness Digital certificates are created as uniquely named objects, which allows them to be uniquely identified. For the purposes of soBGP, the pair of CertificateSerialNumber and AS number in the IssuerAltName values uniquely identifies Entity Certificates. Note that although RFC 3280 contains an X.509v3 IssuerName, it is not used within soBGP. 3.2.2 Certificate Encoding Entitycerts distributed in [SOBGP-BGP] use their native DER [X.690] form. If Entitycerts are manually distributed (e.g., through electronic mail) they may need to be base64 encoded as described in Section 4.3 of [RFC1421]. 3.2.3 Multiplicity of Entitycerts An autonomous system MAY enroll with more than one issuer, which results in multiple valid Entitycerts for that AS. An AS holding certificates from different well-known issuing entities within the routing system may result in a greater number of other autonomous systems accepting their public key. Or, it may simply result in Weis Expires July, 2005 [Page 8] Secure Origin BGP (soBGP) Certificates February, 2005 other autonomous systems accepting their public key faster, which increases BGP convergence times. If an entity detects that an autonomous system has valid Entitycerts from different issuers, the entity SHOULD treat the various Entitycerts as independent. Revocation from one issuer does not necessarily imply that Entitycerts from other issuers are invalid. An issuer may revoke a certificate for reasons other than private key compromise or loss. If an issuer revokes an entity certificate and states key compromise as the reason for revocation, a receiving entity SHOULD also treat this state as specific to the issuer. Note that if the state of one issuer were instead considered transitive, the erroneous revocation of a single issuer would result in a denial of service attack on the victim autonomous system. In the face of inconsistent state from different issuers, a receiver MAY choose to trust one issuer over another. For example, a receiver may choose to prefer the result of an issuer they directly trust to an issuer that was verified further away in the "web of trust". 3.3 Distribution Entitycerts may be distributed using any number of methods, for example: - maintained in a directory maintained by the issuing autonomous system, - distributed via some out of band mechanism, and/or - distributed within BGP using extensions defined in [SOBGP-BGP]. To ensure interoperability, the receiving autonomous system SHOULD distribute its Entitycert within BGP. 3.4 Validation Validation rules for Entitycerts MUST follow those described in [RFC3280]. Any device receiving an Entitycert can verify it by validating the signature on the certificate, along with the verifying information. Validation of the certificate may include checking a CRL (see Section 3.5). If a Certificate Revocation List (CRL) is available for that issuer, it MUST be consulted to verify that this certificate has not been revoked. Local policy will determine whether or not a CRL must be available in order to complete validation of the certificate. Once validation is complete, the public key contained in this certificate may be used to verify messages purportedly sent by this entity. Weis Expires July, 2005 [Page 9] Secure Origin BGP (soBGP) Certificates February, 2005 3.4.1 Web of Trust An soBGP entity uses the "web of trust" paradigm for purposes of Entitycert validation, where the entity learns the validity of public keys over time. An entity follows the following procedure for validating Entitycerts in the web of trust. - A small number of Entitycerts are manually configured and copied to a device's local configuration. These are implicitly trusted as being previously verified and authenticated. - When the entity receives a new Entitycert, it checks to see if it has the public key of the issuing autonomous system in its configuration. If so, it attempts to validate the Entitycert, using the previously known public key, and any revocation material that is available from the issuer. - If the new Entitycert proves valid, it is added to the device's local configuration and may be used to validate subsequently received Entitycerts. - If the new Entitycert cannot be validated because the issuer's public key is not yet available, local policy dictates as to whether or not the certificate is held awaiting the issuer's certificate. Figure 2 shows an example web of trust. In this example, Entitycerts for AS 1 and AS 5 would be manually copied to the local configuration on the box. Other Entitycerts would be validated using the usual PKI path validation techniques. As in Figure 1, an arrow in this figure indicates a signature operation. The public key contained in the certificate at the tail of the arrow is used to verify the validity of the certificate at the head of the arrow. Weis Expires July, 2005 [Page 10] Secure Origin BGP (soBGP) Certificates February, 2005 +------------+ +------------+ | AS 1 | | AS 5 | | Entitycert | | Entitycert | +-----+------+ +---+----+---+ | / \ | / \ | + + | | | V V V +------------+ +------------+ +------------+ | AS 2 | | AS 6 | | AS 7 | | Entitycert | | Entitycert | | Entitycert | +---+----+---+ +------------+ +-----+------+ / \ | / \ V + + +------------+ | | | AS 8 | V V | Entitycert | +------------+ +------------+ +-----+------+ | AS 3 | | AS 4 | | | Entitycert | | Entitycert | V +------------+ +------------+ +------------+ | AS 9 | | Entitycert | +------------+ Figure 2. Example Web of Trust An autonomous system may define local policy to restrict the scope of the web of trust. However it should be noted that any local policy restricting the web of trust reduces the value of soBGP authorization and path validation. One type of local policy would be to accept only a certain "depth" of Entitycert issuers. For example, consider if AS 6 in Figure 2 only accepted two levels of issuers. AS 6 would only trust ASes 1,2,5,6 and 7 to issue Entitycerts. It would never validate the Entitycert from ASes 3, 4, 8, and 9. 3.4.2 Self-signed Entitycerts Entitycerts MAY be self-signed, but SHOULD only be accepted from autonomous systems when a method exists of validating that the self- signed certificate is genuine. Distribution out-of-band using a trusted delivery procedure would be one method. An autonomous system MUST have local policy describing the circumstances under which they will access self-signed certificates. Typical users of a self-signed Entitycert would be: - A commercial authority in the business of providing digital certificates for many types of commercial transactions - An Entitycert issuer that is at the top of a hierarchy of issuers Weis Expires July, 2005 [Page 11] Secure Origin BGP (soBGP) Certificates February, 2005 - A well-known trusted party within the domain of Internet routing 3.5 Revocation and Expiration As described in [RFC3280], any entity issuing an Entitycert may later need to revoke it. The entity MAY use any available methods for propagating that revocation list, but SHOULD send it as part of an AS Policy Certificate (distributed using [SOBGP-BGP]). This allows autonomous systems that cannot route to the issuing autonomous system to verify that the Entitycert has not been revoked. If an Entitycert is discarded due to revocation, the Authcert and Policy databases should be examined. Any Authcerts and Policy certificates that were validated using the discarded certificate should be removed from the database. X.509 certificates contain expiration dates. Any device validating Entitycerts MUST have a time of day clock that is set to real time in order to properly deal with expired certificates If an Entitycert is discarded due to expiration, Authcerts or Policy certificates validated using the discarded certificate remain valid if another valid Entitycert for the AS can be found containing the same public key. 4.0 Authorization and Policy Certificates soBGP defines a set of certificates that make authorization and local policy claims regarding prefixes, and local policy claims regarding Autonomous Systems. These certificates are not defined to be in a X.509 format. Rather, they are defined in a more compact Type/Length/Value (TLV) format that can be easily transferred through BGP [SOBGP-BGP]. The certificates share a common set of attributes, which are defined in later section of this document. The following sections describe which attributes are relevant to the various certificate types, as well as the processing semantics for each certificate type. Each certificates is formatted as a header block followed by a set of Type/Length/Value attributes. All TLVs described in the following sections are REQUIRED to be present in an Authcert unless they are declared optional. 4.1 Authorization Certificates (Authcert) Authcerts prove the right of an entity to advertise particular prefixes. They are generated in a hierarchical manner following the order of address space allocation (i.e., from RIR, to LIR or ISP, to customer), and are distributed along with the address space Weis Expires July, 2005 [Page 12] Secure Origin BGP (soBGP) Certificates February, 2005 allocation. Receivers use the Authcert to validate announcements received in BGP UPDATE messages. The authorization certificate binds one or more prefix blocks to a particular autonomous system. It is typically provided by an entity issuing a prefix block to an autonomous system, and is digitally signed by the issuing autonomous system. The Authcert can be thought of as an "Attribute Certificate" in the spirit of RFC 3281, although it does not follow the syntax of that document. The authenticity of Authcerts is verified with a digital signature provided by the issuing autonomous system. Authcerts do not contain public keys. Rather, they bind an address space to a particular identity (i.e., Autonomous System). Including more than one prefix block in an Authcert can reduce the number of Authcerts necessary. However, note that an Authcert is bundled with policy as part of Prefix Policy Certificate (discussed later in this document). If more than one prefix block is included in the Authcert, then that policy will apply to all of the prefix blocks. Multiple entities (i.e., AS numbers) may be authorized to advertise a prefix block. This is necessary when an organization without an AS number is multi-homed. See Section 5.3 of [SOBGP-ARCH] for more details. 4.1.1 Format Figure 3 describes the format and order of an Authcert. Optional attributes are represented within brackets. An asterisk following an attribute indicates that more than one of the attribute may be present. HDR, ORIG-AS, AUTH-AS*, SN, PREFIX*, [ORIG-EC-URL], [ORIG-AP-URL], SIG Figure 3. Authcert Format The ORIG-AS describes the entity that created the certificate. It serves the same purpose as the issuerName and issuerAltName in an X.509v3 certificate. The AUTH-AS describes the subject entity to which the prefix has been allocated. This serves as the subjectName and subjectAltName in an X.509v3 certificate. The SN attribute provides a unique serial number for this certificate. It serves the same purpose as an X.509v3 serialNumber. The PREFIX attribute describes an address block that has been assigned to the AS numbers declared in the AUTH-AS attributes. Weis Expires July, 2005 [Page 13] Secure Origin BGP (soBGP) Certificates February, 2005 The ORIG-EC-URL attribute contains a URL to an Entitycert containing the public key that signed this certificate. The ORIG-AC-URL attribute contains a URL to the most recent ASPolicycert, which allows a receiver to verify that this Authcert is still considered valid by the originating AS. The SIG attribute contains a digital signature created by the originating AS. 4.1.2 Creation An Authcert is usually created by the authorizing Autonomous System with the following steps: - Allocate a prefix block to the receiving autonomous system. - Build an Authcert by adding TLVs containing the authorizing AS number, the receiving (authorized) AS number, the prefix block, a unique sequence number, and any other information (e.g., URL pointing to the Entitycert that signed this Authcert.). The Signature TLV is also included, except for the signature bytes. - Sign the Authcert by hashing and encrypting the Authcert bytes. Append the signature to the Signature TLV to complete the Authcert. 4.1.3 Distribution Authcerts are distributed as part of a Prefix Policy Certificate, so that an Autonomous System can reliably match distribution policy to the prefix block. 4.1.4 Validation The Authcert is validated using the following steps. - Identify the Entitycert that signed the Authcert. The correct Entitycert is uniquely identified with the Entity Certificate Issuer Autonomous System and Entity Certificate Serial Number contained in the Signature TLV. The Entity Certificate Issuer Autonomous System is compared with the AS number in the Entitycert IssuerAltName field. The Entity Certificate Serial Number is compared with the Entitycert CertificateSerialNumber. - Obtain the Entitycert that signed the Authcert, and validate it. The Entitycert may be in a local cache (e.g., already received via BGP extensions), retrieved using the URL in the Authcert, or through other means. If an entity does not have the validating public key it MUST NOT assume the Authcert is valid. - Verify that the autonomous system identifier in SubjectAltName of the Entitycert matches the Authorizing AS TLV value of the Authcert. - If an Authorization Certificate Validity List is available, validate that the issuer of the Entitycert has not invalidated the Authcert. Validity lists may be distributed in the signers ASPolicycert, or a pointer to the list may be distributed in the Weis Expires July, 2005 [Page 14] Secure Origin BGP (soBGP) Certificates February, 2005 Authcert in an Originating AS ASPolicycert URL . If no Authorization Certificate Validity List is available, an entity MAY accept the certificate. However if a validity list is received later, the entity MUST check the validity of all certificates that had been previously accepted. - Hash the Authcert bytes, excluding the signature itself. - Extract the signature from the Authcert. - Extract the public key from the Entitycert, and use it to decrypt the signature. - Verify that the computed hash matches the decrypted hash. If the hashes do not match, the Authcert MUST be discarded. - Verify that the Originating AS was authorized to distribute the prefix to the subject AS. This is done by comparing the address space allocated to the Originating AS to the prefix that the Originating AS included in this Authcert. IF the Originating AS was authorized to allocate the prefix in this Authcert, then the Authcert is accepted as valid. 4.1.4.1 Self-signed Authcerts Self-signed Authcerts are dangerous, because a responsible third party does not assign the authorization contained within the Authcert. Trusting an autonomous system to declare authorization of its own address space negates the ability of any third party to verify suitability of the authorization. However, the autonomous systems at the highest level of prefix allocation (e.g. Regional Internet Registries (RIRs) or Local Internet Registries (LIRs)) may not be able to find a responsible third party to sign their Authcerts. In this case, self-signed Authcerts may be unavoidable. Authcerts MAY be self-signed, but MUST only be accepted from autonomous systems that have been locally configured as explicitly authorized to do so. For example, a device may be configured to accept Authcerts for the RIR autonomous systems. 4.1.5 Revocation An entity issuing an Authcert MUST keep an Authcert revocation list. The entity MAY use any form for propagating that revocation list. Because BGP routers do not necessarily have synchronized clocks, Authcerts do not carry expiration times, and thus do not expire. Revocation is only method of invalidating an Authcert. Revocation information may be represented as a "validation list". A validation list includes lists of both valid and invalid (i.e., revoked) certificates. Any number not appearing in the list MUST be considered invalid. Validation list may be more efficient than a pure revocation list for Authcerts in the case where a large number of serial numbers have been revoked by an issuer. Weis Expires July, 2005 [Page 15] Secure Origin BGP (soBGP) Certificates February, 2005 An autonomous system MUST include an Authcert validation list in their AS Policy Certificate (distributed using [SOBGP-BGP]). This allows autonomous systems that cannot route to the issuing autonomous system to verify that the Entitycert has not been revoked. 4.2 Prefix Policy Certificates (PrefixPolicycert) The PrefixPolicycert carries policy information sourced from route originators. It provides a specific set of policy regarding one or more prefix blocks. The owner of the prefix block creates it. There is only one valid PrefixPolicycert for each prefix block at any given time. PrefixPolicycerts are verified with a digital signature provided by the autonomous system generating the policy. It does not contain a public key. Rather, it binds a particular policy to a particular identity (i.e., autonomous system). 5.2.1 Format Figure 4 describes the format and order of a PrefixPolicycert. Optional attributes are represented within brackets. An asterisk following an attribute indicates that more than one of the attributes may be present. HDR, ORIG-AS, SN, AUTHCERT*, P-POLICY, [ORIG-EC-URL], [ORIG-AP-URL], SIG Figure 4. PrefixPolicycert Format The ORIG-AS describes the entity that created the certificate. It serves the same purpose as the issuerName and issuerAltName in an X.509v3 certificate. The SN attribute provides a unique serial number for this certificate. It serves the same purpose as an X.509v3 serialNumber. The AUTHCERT attribute designates an Authorization Certificate that is subject to the policies indicated in this certificate. If multiple AUTHCERT attributes are present, they are all subject to the same policy. The P-POLICY attribute contains specific policy that the originator is requesting other entities to honor regarding the prefixes contained in the AUTHCERT attributes. The ORIG-EC-URL attribute contains a URL to an Entitycert containing the public key that signed this certificate. The ORIG-AC-URL Weis Expires July, 2005 [Page 16] Secure Origin BGP (soBGP) Certificates February, 2005 attribute contains a URL to the most recent ASpolicycerts, which allows a receiver to verify that this is PrefixPolicycert is still considered valid by the originating AS. The SIG attribute contains a digital signature created by the originating AS. 4.2.2 Creation An PrefixPolicycert is created by an autonomous system for prefix blocks that it owns. An autonomous system creates it with the following steps: - Build an PrefixPolicycert by adding TLVs containing its own AS number, a unique sequence number, policy related to one or more prefix blocks, and the Authcert or Authcerts defining the prefix blocks to which this policy applies. The Signature TLV is also included, except for the signature bytes. - Sign the Authcert by hashing and encrypting the PrefixPolicycert bytes. Append the signature to the Signature TLV to complete the PrefixPolicycert. 4.2.3 Distribution PrefixPolicycerts may be distributed using any number of methods, for example: - maintained in a directory maintained by the issuing autonomous system, - distributed via some out of band mechanism, or - distributed within BGP using extensions defined in [SOBGP-BGP]. To ensure interoperability, an autonomous system SHOULD distribute its PrefixPolicycerts within BGP. 4.2.4 Validation The Authcert included in the Authcert TLV MUST be validated as correct before the Policy TLV can be accepted. Thus, the Authcert should be extracted from the PrefixPolicycert and validated before the PrefixPolicycert is validated. The PrefixPolicycert is validated using the following steps. - Identify the Entitycert that signed the PrefixPolicycert. The correct Entitycert is uniquely identified with the Entity Certificate Issuer Autonomous System and Entity Certificate Serial Number contained in the Signature TLV. The Entity Certificate Issuer Autonomous System is compared with the AS number in the Entitycert IssuerAltName field. The Entity Certificate Serial Number is compared with the Entitycert CertificateSerialNumber. Weis Expires July, 2005 [Page 17] Secure Origin BGP (soBGP) Certificates February, 2005 - Obtain the Entitycert that signed the PrefixPolicycert, and validate it. The Entitycert may be in a local cache (e.g., already received via BGP extensions), retrieved using the URL in the Authcert, or through other means. If an entity does not have the validating public key it MUST NOT assume the PrefixPolicycert is valid. - Verify that the autonomous system identifier in SubjectAltName of the Entitycert matches the Originating Autonomous System TLV value of the PrefixPolicycert. - If an Prefix Policy Certificate Validity List is available, validate that the issuer of the Entitycert has not invalidated the Authcert. Validity lists may be distributed in the signers ASPolicycert, or a pointer to the list may be distributed in the Authcert in an Originating AS ASPolicycert URL. If no Prefix Policy Certificate Validity List is available, an entity MAY accept the certificate. However if a validity list is received later, the entity MUST check the validity of all certificates that had been previously accepted. - Hash the PrefixPolicycert bytes, excluding the signature itself. - Extract the signature from the PrefixPolicycert. - Extract the public key from the Entitycert, and use it to decrypt the signature. - Validate that the computed hash matches the decrypted hash. If the hashes do not match, the PrefixPolicycert MUST be discarded. Once a PrefixPolicycert has been validated, any PrefixPolicycert that matches the following criteria MUST be discarded: - has a lower serial number from the same originating AS, and - includes an Authcert with the same prefix block 4.2.5 Revocation Any entity issuing an PrefixPolicycert MUST keep a revocation list. The entity MAY use any form for propagating that revocation list. Because BGP routers do not necessarily have synchronized clocks, PrefixPolicycert do not carry expiration times, and thus do not expire. Revocation is only method of invalidating a PrefixPolicycert. Revocation information may be represented as a "validation list". A validation list includes lists of both valid and invalid (i.e., revoked) certificates. Any number not appearing in the list MUST be considered invalid. Validation list may be more efficient than a pure revocation list for PrefixPolicycerts in the case where a large number of serial numbers have been revoked by an issuer. An autonomous system SHOULD include an PrefixPolicycert validation list in their AS Policy Certificate (distributed using [SOBGP-BGP]). This allows autonomous systems that cannot route to the issuing autonomous system to verify that the Entitycert has not been revoked. Weis Expires July, 2005 [Page 18] Secure Origin BGP (soBGP) Certificates February, 2005 4.3 AS Policy Certificates (ASPolicycert) The ASPolicycert provides a specific set of policy relating to an autonomous system. An administrative entity within the autonomous system creates it. There is only one valid ASPolicycert for each autonomous system at any given time. ASPolicycerts are verified with a digital signature from the autonomous system generating the policy. It does not contain a public key. Rather, it binds a particular policy to a particular identity (i.e., autonomous system). 4.3.1 Format Figure 5 describes the format and order of a PrefixPolicycert. Optional attributes are represented within brackets. An asterisk following an attribute indicates that more than one of the attributes may be present. HDR, ORIG-AS, SN, TRANSIT, NON-TRANSIT, [EC-CRL], AC-VALID, PPC-VALID, [ORIG-EC-URL],[ORIG-AP-URL], SIG Figure 5. ASpolicycert Format The ORIG-AS describes the entity that created the certificate. It serves the same purpose as the issuerName and issuerAltName in an X.509v3 certificate. The SN attribute provides a unique serial number for this certificate. It serves the same purpose as an X.509v3 serialNumber. The TRANSIT attribute declares which entities are transit peers, through which the originating AS may route packets. The NON-TRANSIT attribute declares which entities are also peers, but through which the originating AS will not route packets. The EC-CRL attribute contains an X.509 CRL declaring which Entitycerts created by the originating AS have been revoked. The AC-VALID and PPC-VALID attributes contain validity lists describing what Authcerts and PrefixPolicycerts created by the originating AS are valid. Validity lists are more descriptive than CRLs. See Section 4.1.5 for the rationale of using Validity Lists rather than CRLs. The ORIG-EC-URL attribute contains a URL to an Entitycert containing the public key that signed this certificate. The ORIG-AC-URL attribute contains a URL to the most recent ASpolicycerts, which allows a receiver to verify that this is an Authcert still considered valid by the originating AS. Weis Expires July, 2005 [Page 19] Secure Origin BGP (soBGP) Certificates February, 2005 The SIG attribute contains a digital signature created by the originating AS. 4.3.2 Creation An ASPolicycert is created by an autonomous system in order to relay its own policy. An autonomous system creates it with the following steps: - Build an ASPolicycert by adding TLVs containing its own AS number, a unique sequence number, and policy related to the autonomous system. The Signature TLV is also included, except for the signature bytes. - Sign the Authcert by hashing and encrypting the ASPolicycert bytes. Append the signature to the Signature TLV to complete the ASPolicycert. 4.3.3 Distribution ASPolicycert may be distributed using any number of methods, for example: - maintained in a directory maintained by the issuing autonomous system, - distributed via some out of band mechanism, or - distributed within BGP using extensions defined in [SOBGP-BGP]. To ensure interoperability, an autonomous system SHOULD distribute its ASPolicycert within BGP. 4.3.4 Validation The ASPolicycert is validated using the following steps. - Identify the Entitycert that signed the ASPolicycert. The correct Entitycert is uniquely identified with the Entity Certificate Issuer Autonomous System and Entity Certificate Serial Number contained in the Signature TLV. The Entity Certificate Issuer Autonomous System is compared with the AS number in the Entitycert IssuerAltName field. The Entity Certificate Serial Number is compared with the Entitycert CertificateSerialNumber. - Obtain the Entitycert that signed the ASPolicycert, and validate it. The Entitycert may be in a local cache (already received via BGP extensions), retrieved using the URL in the Authcert, or through other means. If an entity does not have the validating public key it MUST NOT assume the ASPolicycert is valid. - Verify that the autonomous system identifier in SubjectAltName of the Entitycert matches the Originating Autonomous System TLV value of the ASPolicycert. - Hash the ASPolicycert bytes, excluding the signature itself. - Extract the signature from the ASPolicycert. - Extract the public key from the Entitycert, and use it to decrypt the signature. Weis Expires July, 2005 [Page 20] Secure Origin BGP (soBGP) Certificates February, 2005 - Validate that the computed hash matches the decrypted hash. If the hashes do not match, the ASPolicycert MUST be discarded. Once an ASPolicycert has been validated, any ASPolicycert with a lower serial number from the same originating AS MUST be discarded. 4.3.5 Revocation Each ASPolicycert issued by an autonomous system overrides any previously issued ASPolicycerts from this autonomous system. Therefore, revocation is not required. If present, a receiver has the opportunity of using the Most Recent AS Policy Certificate URL in the ASPolicycert to verify that they have the most recent policy certificate. 4.4 Common Processing The following sections describe processing that is common to each of the soBGP TLV-based certificates. 4.4.1 Certificate Uniqueness Digital certificates are created as uniquely named objects, which allows them to be uniquely identified. The pair of Authorized Originator and certificate Serial Number TLV values uniquely identifies each certificate. 4.4.2 Certificate Encoding The soBGP TLV-based certificates are distributed through BGP [SOBGP- BGP] in the TLV form. However if they are manually distributed (e.g., through electronic mail) they may need to be base64 encoded as described in Section 4.3 of [RFC1421]. 5.0 Authorization and Policy Certificate Attributes 5.1 Certificate Header (HDR) Each soBGP certificate begins with a header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | Cert. Marker | Type Id | Length | +---------------+---------------+-------------------------------+ The header fields are defined as follows: o Certificate Marker: "162(0xa2), identifying this as an soBGP certificate. Weis Expires July, 2005 [Page 21] Secure Origin BGP (soBGP) Certificates February, 2005 o Type ID: Identifier denoting the soBGP certificate type. Type ID Value -------- ----- AuthCert 1 (0x01) PrefixPolicycert 2 (0x02) ASPolicycert 3 (0x03) o Length: Set to the number of bytes in the certificate, including the header. 5.2 The Originating Autonomous System (ORIG-AS) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Originating Autonomous System | +---------------------------------------------------------------+ o TLV type: 1 (0x0001) o Length: Set to 4. o Originating Autonomous System: (4 octets), the autonomous system which originated this certificate. AS numbers containing only two octets should be placed in the least significant octets of this four-octet field (the two rightmost octets), the upper two rightmost bits set to zeros. Each soBGP certificate MUST include an originating Autonomous System number. This attribute declares which identity has created the certificate. 5.3 Authorized Autonomous System (AUTH-AS) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Autonomous System | +---------------------------------------------------------------+ o TLV type: 2 (0x0002) o Length: Set to 4. o AS: (4 octets), the autonomous system of an entity authorized to advertise prefixes within this block. AS numbers containing only two octets should be placed in the least significant octets of this four-octet field (the two rightmost octets). Weis Expires July, 2005 [Page 22] Secure Origin BGP (soBGP) Certificates February, 2005 Multiple authorized originator TLVs may be included in the Authcert. 5.4 The Serial Number (SN) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Serial Number | +---------------------------------------------------------------+ o TLV type: 3 (0x0003) o Length: Denotes the length of the URL in octets. o Serial Number: (An unsigned integer taken from a number space maintained by the Authorizing AS indicating the serial number of this certificate. This attribute MUST be present in each TLV-based soBGP certificate. The Originating Autonomous System MUST manage the number space of each certificate type as a monotonically increasing value so that a relative ordering of certificates is maintained. 5.5 Originating AS Entitycert URL (ORIG-EC-URL) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | URL | +---------------- o TLV type: 4 (0x0004) o Length: Denotes the length of the URL in octets. o URL: A uniform resource locator indicating a location where the Originating Autonomous System Entitycert can be found. This attribute allows a receiver to validate that it has the most current Entitycert for the originator. This mitigates an attack where an adversary has been able to stop the propagation of new Entitycerts. A conforming implementation is REQUIRED to support this attribute. A receiving device MAY choose to ignore the URL TLV. 5.6 Originating AS ASPolicycert URL (ORIG-AP-URL) Weis Expires July, 2005 [Page 23] Secure Origin BGP (soBGP) Certificates February, 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | URL | +---------------- o TLV type: 5 (0x0005) o Length: Denotes the length of the URL in octets. o URL: A uniform resource locator indicating a location where the Originating Autonomous System ASPolicycert can be found. This attribute allows a receiver to validate that it has the most current policy for the originator. In particular, it allows a receiver to obtain the most recent Validation Lists generated by the Originating Autonomous System. Having the most recent Validation Lists allows a receiver to validate that the Authcerts and Prefixpolicycerts that they hold for that AS have not been replaced. This validation mitigates an attack where an adversary has been able to stop the propagation of ASPolicycerts. A conforming implementation is REQUIRED to support this attribute. A receiving device MAY choose to ignore the URL TLV. 5.7 The Address Prefix (PREFIX) The address prefix TLV defines prefixes which the authorized AS (or ASes) are allowed to advertise. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+---------------+---------------+ | Address Family Identifier | RESERVED | Subsequent AFI| +-------------------------------+---------------+---------------+ | NLRI Data | +---------------- o TLV Type: 6 (0x0006) o Length (2 octets), set to 4 + the length of the NLRI Data. o Address Family Identifier: This field carries the identity of the Network Layer protocol associated with the Network Address that follows. Presently defined values for this field are assigned by IANA [IANA-AFN]). o RESERVED: Set to 0. Weis Expires July, 2005 [Page 24] Secure Origin BGP (soBGP) Certificates February, 2005 o Subsequent AFI: This field provides additional information about the type of the Network Layer Reachability Information carried in the attribute. Values for this field are defined in Section 5 of [RFC2858]. o NLRI Data: An address prefix as described in Section 4 of [RFC2858]. 5.8 Signature (SIG) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Signature Type | Number of Issuers | +-------------------------------+-------------------------------+ | Entity Certificate Issuer Autonomous System | +-------------------------------+-------------------------------+ | Entity Certificate Serial Number | +-------------------------------+-------------------------------+ | ... | +---------------------------------------------------------------+ | Signature | +------------------ o TLV type: 7 (0x0007) o Length: (2 octets), unsigned integer denoting the length of the payload bytes which follow. o Signature Type: (2 octets), unsigned integer denoting the type of signature (the algorithm used to build this signature). Each possible signing algorithm is assigned an integer from this field. Signature type 1 is defined as an RSA encryption of a SHA1 digest using PKCS#1.5 padding. o Number of Issuers (2 octets): The number of Entitycert references included in the signature payload. If more than one Entitycert reference follows, all Entitycerts MUST contain the same public key for the same authorizing autonomous system. o Entity Certificate Issuer Autonomous System: (4 octets), the autonomous system of the entity that provided the Entitycert to the Authorizing AS. AS numbers containing only two octets should be placed in the least significant octets of this four- octet field (the two rightmost octets). o Entity Certificate Serial Number: (4 octets), the Entitycert serial number containing the public key of the Authorizing AS. o Signature: The signature itself. Weis Expires July, 2005 [Page 25] Secure Origin BGP (soBGP) Certificates February, 2005 The signature is calculated by hashing the bytes of the certificate, beginning with the certificate header and ending at the byte just before the signature. The hashed data includes the Signature payload fields just prior to the signature field in the Signature payload. The hash is then encrypted using the private key of the authorizing entity.. 5.9 Authorization Certificate (AUTHCERT) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Authorization Certificate | +---------------- o TLV type: 8 (0x0008) o Length: Set to the length of the Authorization Certificate. o Authorization Certificate. . This attribute allows a PrefixPolicycert to bind particular policy to the prefix block contained in an Authorization Certificate. One or more Authcert TLVs MUST be included in the PrefixPolicycert. 5.10 Prefix Policies (P-POLICY) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Options | SubTVs +-------------------------------+-------------- o TLV type: 9 (0x0009) o Length: Set to the sum of the Options size (2) and the length of the SubTVs. o Options: (2 octets), a bit field describing various policies which should be applied to prefixes . o SubTVs: (variable length), zero or more fields, the length of which is determined by the type, as described below. This attribute is included in a PrefixPolicycert to bind particular policy to the prefixes contained in an Authcert. Weis Expires July, 2005 [Page 26] Secure Origin BGP (soBGP) Certificates February, 2005 5.10.1 Option bits The options bit field describes policies that should be applied to the address prefix described in the TLV. These options are: o Bit 0: Path Check. If this bit is set, the receiver should not accept any prefix for which the path cannot be verified as described in the section Verifying the Path, below. o Bit 1: Second Hop Check. If this bit is set, the receiver should not accept any prefix for which the second entry in the AS PATH cannot be verified as described in the section Verifying the Second Hop, below. o Bits 2-15: Reserved for future use. 5.10.2 SubTVs The Authcert Policy subTVs provide optional policy information for the block of addresses included in the Authcert indicated; each subTV is of a fixed length, as determined by its type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+------------------------------+ | TV Type | Data.... +-------------------------------+------------------------- o TV Type: (2 octets), An unsigned integer indicating the type of subTV Types defined within this specification are: - Type 1: Must Include AS, 4 octets of data, an AS which must be included in the AS path of any prefix falling within this block of addresses. - Type 2: OR Include AS, 4 octets of data, at least one of the included OR Include AS' must be included in the AS path of any prefix falling within this block of addresses. - Type 3: MUST NOT INCLUDE AS, 4 octets of data, an AS which must not be included in the AS path of any prefix falling within this block of addresses - Type 4: Maximum Prefix Length, 1 octet of data, the maximum length of any prefix allowed within this block of prefixes. 5.11 Attached Transit Autonomous Systems (TRANSIT) Weis Expires July, 2005 [Page 27] Secure Origin BGP (soBGP) Certificates February, 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+---------------+---------------+ | Address Family Identifier | RESERVED | Subsequent AFI | +-------------------------------+---------------+---------------+ | Autonomous Systems | +----------------- o TLV type: 4 (0x0004) o Length: Set to 4 + 4 octets for each autonomous system in the list. o Address Family Identifier: This field carries the identity a the Network Layer protocol. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section). o RESERVED: Set to 0. o Subsequent AFI: This field provides additional information about the type of the Network Layer protocol. o Autonomous Systems: List of autonomous systems which are connected to the originating autonomous system through some form of peering arrangement and which may transit traffic from the origin AS. Each AS number takes four octets. AS number values containing only two octets should be placed in the least significant octets of this four-octet field (the two rightmost octets). One or more Attached Transit AS TLVs may be included in the ASPolicycert . Each type 4 TLV indicates an AS which is connected to the AS which originates this ASPolicycert through a BGP peering relationship. 5.12 Attached Non-transit Autonomous Systems (NON-TRANSIT) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+---------------+---------------+ | Address Family Identifier | RESERVED | Subsequent AFI| +-------------------------------+---------------+---------------+ | Autonomous Systems | +------------------ o TLV type: 5 (0x0005) Weis Expires July, 2005 [Page 28] Secure Origin BGP (soBGP) Certificates February, 2005 o Length: Set to 4 + 4 octets for each autonomous system in the list. o Address Family Identifier: This field carries the identity a the Network Layer protocol. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section). o RESERVED: Set to 0. o Subsequent AFI: This field provides additional information about the type of the Network Layer protocol. o Autonomous Systems: List of autonomous systems which are connected to the originating autonomous system through some form of peering arrangement and which may not transit traffic from the origin AS. Each AS number takes four octets. AS number values containing only two octets should be placed in the least significant octets of this four-octet field (the two rightmost octets). One or more Attached Non-Transit AS TLVs may be included in the ASPolicycert. Each type 5 TLV indicates an AS which is connected to the AS which originates this ASPolicycert through a BGP peering relationship. 5.13 Revoked Entity Certificate List (EC-CRL) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Entity Certificate Revocation List +---------------- o TLV type: 6 (0x0006) o Length: (2 octets), length of TLV data (the list of revoked Entity Certificates) in octets o Entity Certificate Revocation List: A revocation list created by the autonomous system, which includes a list of revoked Entity Certificates issued by this autonomous system. The format of the revocation list MUST be as defined in [RFC3280]. A single Revoked Entity Certificate List TLV MAY be included in an ASPolicycert, or it may be omitted. When an Entity Certificate Revocation List is received, all currently held Entitycerts from this issuer MUST be checked against the CRL. Entitycerts found to be invalid MUST be deleted. Weis Expires July, 2005 [Page 29] Secure Origin BGP (soBGP) Certificates February, 2005 5.14 Authorization Certificate Validity List (AC-VALID) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Validity Ranges +---------------- o TLV type: 7 (0x0007) o Length: (2 octets), length of TLV data (the list of revoked Authorization Certificates) in octets o Validity Ranges: A list of validity subTVs defining which serial numbers are valid and invalid. Validity ranges are interpreted in order until a match is found. For more information on validity lists, see Section 4.1.5. A single TLV of this type MAY be included in an ASPolicycert, or it may be omitted. When an Authorization Certificate Validity List is received, all currently held Authcerts from this issuer MUST be checked against the validity list. Authcerts found to be invalid MUST be deleted. 5.14.1 Validity Ranges 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | subTV Type | Size of Range | +-------------------------------+-------------------------------+ | Lowest Authorization Serial Number | +---------------------------------------------------------------+ o subTV type: (2 octets). SubTV type Value ---------- ----- VALID 0 INVALID 1 o Size of Range: (2 octets). Number of contiguous serial numbers defining a range. o Lowest Authorization Serial Number (4 octets). The lowest value in the range. Weis Expires July, 2005 [Page 30] Secure Origin BGP (soBGP) Certificates February, 2005 5.15 Prefix Policy Certificate Validity List (PPC-VALID) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ | TLV Type | Length | +-------------------------------+-------------------------------+ | Validity Ranges +---------------- o TLV type: 8 (0x0008) o Length: (2 octets), length of TLV data (the list of revoked Authorization Certificates) in octets o Validity Ranges: A list of validity subTVs (as defined in the previous section) defining which PrefixPolicycert serial numbers are valid and invalid. Validity ranges are interpreted in order until a match is found. A single TLV of this type MAY be included in an ASPolicycert, or it may be omitted. When an Prefix Policy Validity List is received, all currently held PrefixPolicycerts from this issuer MUST be checked against the validity list. PrefixPolicycerts found to be invalid MUST be deleted. 6.0 Security Considerations This document describes the format of authentication, authorization, and policy certificates used to with [SOBGP-BGP]. Each certificate type is digitally signed, and therefore requires no external protection to ensure its integrity. There are no restrictions on how they may be distributed. Revocation schemes are defined for all certificate types. The following sections describe the security considerations of each of those objects. 6.1 Entitycerts Entitycerts provide authentication, providing a binding of an identity (i.e., autonomous system number) to a public key. The authenticity of the binding is verified with a digital signature, where the public key of the certificate issuer has been previously accepted as valid. Issuer public keys can either be manually configured, or are verified through the use of another issuer's trusted public key in a "web of trust" built by the receiver. Certificate issuers MUST maintain certificate revocation lists (CRLs). Entities verifying Entitycerts SHOULD reference the certificate revocation lists whenever possible. (Mandating the Weis Expires July, 2005 [Page 31] Secure Origin BGP (soBGP) Certificates February, 2005 consultation of a CRL as part of the verification process is not possible, because the CRL may not be available at the time verification is performed. For example, if the issuer maintains the CRL on a directory server to which routing is not yet setup.) Issuers SHOULD distribute their CRLs within their AS Policy Certificates to increase the likelihood of a receiver having the CRL available. Self-signed Entitycerts may be necessary in order to start a chain of trust. However self-signed Entitycerts MUST be manually validated as accurate before the enclosed public key is used, else the "web of trust" breaks down. 6.2 Authcerts Authcerts provide authorization, where the issuer of a prefix block certifies that it has given that prefix block to a specific autonomous system. Receivers use the Authcert to validate announcements received in BGP UPDATE messages. The authenticity of Authcerts is verified with a digital signature, where the public key of the certificate issuer is distributed in an Entitycert. Before a receiver can verify the Authcert, they MUST first check that the verifying Entitycert is authentic. The Authcert issuer MUST keep an Authcert validation list describing which certificates are valid, and which are invalid. The receivers of an Authcert SHOULD consult the Authcert validation list to ensure that the authorization has not been revoked. Autonomous systems may need to authorize their own use of prefix blocks if the autonomous system that issued their prefix blocks does not issue them an Authcert. However, such self-signed Authcerts are dangerous, since unrestricted use of self-signed Authcerts defeats the goal of authorization. Thus an entity MUST accept self-signed Authcerts only from autonomous systems that have been explicitly configured as trusted to claim authorization without the confirmation of a third party. 6.3 PrefixPolicycerts PrefixPolicycerts bind policy generated by an autonomous system for prefix blocks that they advertise. This policy is bound to a particular Authcert, which verifies that they are authorized to advertise those prefix blocks. PrefixPolicycerts are verified with a digital signature, where the public key of the certificate issuer is distributed in an Entitycert. Before a receiver can verify the PrefixPolicycert, they MUST first verify that the verifying Entitycert is authentic. Weis Expires July, 2005 [Page 32] Secure Origin BGP (soBGP) Certificates February, 2005 6.4 ASPolicycerts ASPolicycerts contain policy generated by an autonomous system, and contain policy about the autonomous system itself. The policy includes its neighbor autonomous systems, which can be used by other entities to validate valid inter-connections. The policy can also include revocation and validation lists (Authcert, PrefixPolicycert). ASPolicycerts are verified with a digital signature, where the public key of the certificate issuer is distributed in an Entitycert. Before a receiver can verify the ASPolicycerts, they MUST first verify that the verifying Entitycert is authentic. 6.5 Entitycert Uniform Resource Locators Authcerts, PrefixPolicycerts, and ASPolicycerts may contain a URL that references the Entitycert used to validate it. Care should be taken in evaluating the URL since it is not yet known to be valid and could be used to propagate a denial of service attack. 7.0 IANA Considerations This document defines three certificate types, each of which contains a series of TLVs. IANA is expected to maintain a registry of all the values defined, according to the following sections. 7.1 soBGP Certificate Attribute Values The following Type values in soBGP certificate TLVs are to be defines as follows: o Type values 1 through 4, 14 and 65535 are assigned in this document. o Type values 5 through 13 and 15 through 16575 MUST be assigned using the "IETF Consensus" policy defined in RFC 2434 [RFC2434]. o Type values 16576 through 32895 SHOULD be assigned using the "Specification Required" policy defined in RFC 2434 [RFC2434]. o Type values 32896 through 65534 are for "Private Use" as defined in RFC 2434 [RFC2434]. 7.2 Signature Type The Signature TLV Signature Type field: o Type values 1 is assigned in this document. Weis Expires July, 2005 [Page 33] Secure Origin BGP (soBGP) Certificates February, 2005 o Type values 2 through 16575 MUST be assigned using the "IETF Consensus" policy defined in RFC 2434 [RFC2434]. o Type values 16576 through 32895 SHOULD be assigned using the "Specification Required" policy defined in RFC 2434 [RFC2434]. o Type values 32896 through 65534 are for "Private Use" as defined in RFC 2434 [RFC2434]. 7.3 Policies Type The Policies Type has two name spaces: Options flags and SubTVs. The Options Field: o Bits 0 and 1 are assigned in this document. o Bits 2 thru 7 MUST be assigned using the "IETF Consensus" policy defined in RFC 2434 [RFC2434]. o Bits 8 thru 15 are for "Private Use" as defined in RFC 2434 [RFC2434]. The subTV TV Type field: o TV Type values 1 through 3 are assigned in this document. o TV Type values 4 through 16575 MUST be assigned using the "IETF Consensus" policy defined in RFC 2434 [RFC2434]. o TV Type values 16576 through 32895 SHOULD be assigned using the "Specification Required" policy defined in RFC 2434 [RFC2434]. o TV Type values 32896 through 65534 are for "Private Use" as defined in RFC 2434 [RFC2434]. 7.4 Validity Ranges o Type values 1 through 2 are assigned in this document. o Type values 3 through 16575 MUST be assigned using the "IETF Consensus" policy defined in RFC 2434 [RFC2434]. o Type values 16576 through 32895 SHOULD be assigned using the "Specification Required" policy defined in RFC 2434 [RFC2434]. o Type values 32896 through 65534 are for "Private Use" as defined in RFC 2434 [RFC2434]. 8.0 Acknowledgments Weis Expires July, 2005 [Page 34] Secure Origin BGP (soBGP) Certificates February, 2005 A large number of people contributed to or provided valuable feedback on this document; we've tried to include all of them here (in no particular order), but might have missed a few: James Ng, Russ White, Alvaro Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes, Max Pritikin, Chris Lonvick, Tim Gage, Scott Fanning, Barry Friedman, Jim Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum, Ed Lewis, Bora Akyol, and Jonathan Natale. 9.0 References 9.1 Normative References [IANA-AFN] http://www.iana.org/assignments/address-family-numbers [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T., and H. Alvestrand,, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [RFC2858] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [RFC3279] Polk, T., et. al., " Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC3280] Housley, R., et. al., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 3280, April 2002. [RFC3779] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn- 03.txt, RFC 3779, June 2004. [SOBGP-ARCH] White, R. (editor), "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", draft-white-sobgp- architecture-01.txt, Work in Progress, February 11, 2005. [SOBGP-BGP] Ng, J. (editor), "Extensions to BGP to Support Secure Origin BGP (soBGP)", draft-ng-sobgp-extensions-02.txt, Work in Progress, April 2004. [SOBGP-RADIUS] Lonvick, C., "RADIUS Attributes for soBGP Support", draft-lonvick-sobgp-radius-04.txt, Work in Progress, February 13, 2004. [X.690] International Telecommunication Union, "ITU-T Recommendation X.660 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997. Weis Expires July, 2005 [Page 35] Secure Origin BGP (soBGP) Certificates February, 2005 9.2 Informative References [RFC3281] Farrell, S., and R. Housley, " An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002. [RFC3552] E. Rescorla, et. al., "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003. Appendix A. Example Certificates This section contains several examples of soBGP certificates. The first example is an Entitycert, followed by an Authcert. A.1. Entitycert This section contains an annotated hex dump of an 862 byte Entitycert. In this example, AS 100 is a large ISP that has created a self-signed certificate. Because it is self-signed, AS 100 has placed its own identity in both the subjectAltName and issuerAltName. AS 100 can now act as a Certificate Server for its customers. This certificate was processed using Peter Gutman's dumpasn1 utility (invoked with -ail flags) to generate the output. The source for the dumpasn1 utility is available at http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c. 0 870: SEQUENCE { 4 590: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 9: INTEGER 00 98 3A 42 D0 83 4C 30 55 24 13: SEQUENCE { 26 9: OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) : (PKCS #1) 37 0: NULL : } 39 62: SEQUENCE { 41 11: SET { 43 9: SEQUENCE { 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) : (X.520 id-at (2 5 4)) 50 2: PrintableString 'US' : } : } 54 19: SET { 56 17: SEQUENCE { 58 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8) : (X.520 id-at (2 5 4)) 63 10: PrintableString 'California' : } : } 75 26: SET { Weis Expires July, 2005 [Page 36] Secure Origin BGP (soBGP) Certificates February, 2005 77 24: SEQUENCE { 79 3: OBJECT IDENTIFIER organizationName (2 5 4 10) : (X.520 id-at (2 5 4)) 84 17: PrintableString 'Sample Tier 1 ISP' : } : } : } 103 30: SEQUENCE { 105 13: UTCTime 18/02/2005 07:10:18 GMT 120 13: UTCTime 18/02/2006 07:10:18 GMT : } 135 62: SEQUENCE { 137 11: SET { 139 9: SEQUENCE { 141 3: OBJECT IDENTIFIER countryName (2 5 4 6) : (X.520 id-at (2 5 4)) 146 2: PrintableString 'US' : } : } 150 19: SET { 152 17: SEQUENCE { 154 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8) : (X.520 id-at (2 5 4)) 159 10: PrintableString 'California' : } : } 171 26: SET { 173 24: SEQUENCE { 175 3: OBJECT IDENTIFIER organizationName (2 5 4 10) : (X.520 id-at (2 5 4)) 180 17: PrintableString 'Sample Tier 1 ISP' : } : } : } 199 290: SEQUENCE { 203 13: SEQUENCE { 205 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) : (PKCS #1) 216 0: NULL : } 218 271: BIT STRING, encapsulates { 223 266: SEQUENCE { 227 257: INTEGER : 00 BD 51 5E D0 01 BD CC A1 46 49 A3 F8 FC 81 07 : 60 68 A3 E1 9E E4 38 4D CC 8E D5 B0 C8 FC 27 4F : 1D 63 8B 69 61 61 45 53 63 95 85 29 5B 9D 33 F5 : E2 22 CF 3E CA A4 64 3F B9 01 44 B6 09 9C 6E 75 : BF 9E E1 D5 67 23 AC 2C C9 99 A5 A6 CB DA 0A CE : 4F 60 93 E9 FF 1F 56 26 B2 3D 53 2A AE B2 F1 9D : 9F 4A DF AB 60 01 2D 5A 30 A2 BA D4 1E 98 34 47 : 35 3E A2 F9 36 19 8C BE 86 22 3A F1 EB 9F D0 90 : 86 6D 3B F4 0A 51 56 3D 5B 95 A6 43 C6 9B 04 E3 : 0B 66 C3 82 F8 17 A8 54 57 E0 0D A9 58 17 E9 1A : EA 7E FA E6 1B 6B 8A 2A E1 2D 5B 2A 24 3B D0 1D Weis Expires July, 2005 [Page 37] Secure Origin BGP (soBGP) Certificates February, 2005 : 87 5B BF B9 CF 48 42 04 57 A9 E1 64 6C 0A 6E 00 : A4 1C A6 EA B2 F9 39 F8 76 48 4B 3C F0 AA 14 A1 : 1D 44 83 76 F7 BC 8F A5 0D A9 76 A4 8F 00 3C BC : 1B 7D AC EE 94 BD D4 A9 AE 2C 99 3C D2 4F 71 E1 : A8 32 CF A9 27 90 F7 18 A9 D5 23 83 09 73 47 FE : 55 488 3: INTEGER 65537 : } : } : } 493 103: [3] { 495 101: SEQUENCE { 497 29: SEQUENCE { 499 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) : (X.509 id-ce (2 5 29)) 504 22: OCTET STRING, encapsulates { 506 20: OCTET STRING : FC 2B 62 B0 F0 20 80 BB 66 2F D3 B9 59 8B 0F E7 : 9E 2C BC C4 : } : } 528 12: SEQUENCE { 530 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) : (X.509 id-ce (2 5 29)) 535 5: OCTET STRING, encapsulates { 537 3: SEQUENCE { 539 1: BOOLEAN TRUE : } : } : } 542 26: SEQUENCE { 544 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) : (X.509 id-ce (2 5 29)) 549 19: OCTET STRING, encapsulates { 551 17: SEQUENCE { 553 15: [0] { 555 8: OBJECT IDENTIFIER : bgp-autonomousSysNum (1 3 6 1 5 5 7 1 8) : (PKIX private extension) 565 3: [0] { 567 1: INTEGER 100 : } : } : } : } : } 570 26: SEQUENCE { 572 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) : (X.509 id-ce (2 5 29)) 577 19: OCTET STRING, encapsulates { 579 17: SEQUENCE { 581 15: [0] { 583 8: OBJECT IDENTIFIER : bgp-autonomousSysNum (1 3 6 1 5 5 7 1 8) Weis Expires July, 2005 [Page 38] Secure Origin BGP (soBGP) Certificates February, 2005 : (PKIX private extension) 593 3: [0] { 595 1: INTEGER 100 : } : } : } : } : } : } : } : } 598 13: SEQUENCE { 600 9: OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) : (PKCS #1) 611 0: NULL : } 613 257: BIT STRING : 43 6A 45 03 E4 B7 FD 6B 57 9F 75 A5 F4 1F 63 73 : 6C 27 33 2B 05 9B 16 17 D0 3B 1C 71 9C C0 34 EF : 49 64 D2 31 50 0C 65 FF 75 92 D4 A9 6A 88 FD 97 : 3A ED 84 A2 47 49 B9 06 B4 0F 72 D4 56 DA 56 94 : D1 5B 0E AD C2 61 FE 67 CB 44 05 55 3E BC D4 3F : C6 8E 32 EF F5 00 17 8C CB 31 37 1C C0 F3 EA E8 : BD 81 8B D2 B6 AB 64 A2 49 C3 10 AE 50 35 35 BD : E9 5D 53 87 98 13 91 DC 7B 03 ED FB 87 BF F3 D1 : 98 18 B4 A5 56 F5 D3 5D 97 7D F1 C0 FC 8A 77 3C : 1F 6B 50 06 59 2C 4A 93 A2 C0 57 E7 A3 33 2B DC : 98 41 E0 90 4E 29 5A 15 60 6A 72 D7 A0 87 14 3A : AB CE D9 69 C7 67 0C 89 DA 27 00 2E FC 6D F4 E0 : 10 B1 1B 3C DA CA 6D AF 88 23 0B 02 52 4C BD 22 : 12 BA 77 8B B6 40 CB C2 FE F8 32 6D CC B3 2F 6D : FF 0D E4 55 E8 2C A6 EC 66 12 86 D5 6B 3D F8 95 : 1F E3 0A AB B0 33 35 AB 79 0B 79 BF 8E D4 FA 7D : } A.2. Authcert This section contains an annotated hex dump of a 183 byte Authcert. In this example, AS 101 has authorized AS 200 to use the prefix 12.1/16. This certificate was processed using a special purpose utility to generate the output. 0 183 : HEADER : CERTIFICATE MARKER 162 : TYPE_ID 1 4 8 : ATTRIBUTE TYPE 1 (Originating Autonomous System) : AS NUMBER 101 12 8 : ATTRIBUTE TYPE 2 (Authorized Autonomous System) : AS NUMBER 200 20 8 : ATTRIBUTE TYPE 3 (Serial Number) Weis Expires July, 2005 [Page 39] Secure Origin BGP (soBGP) Certificates February, 2005 : SERIAL NUMBER 43 28 11 : ATTRIBUTE TYPE 6 (Address Prefix) : AFI 1 SAFI 1 : PREFIX 12.1/16 39 144 : ATTRIBUTE TYPE 7 (Signature) : SIGNATURE TYPE 1 : ISSUERS : ISSUER AS 101 : ENTITYCERT SERIAL NUMBER 17 : SIGNATURE : 29 0A 72 67 92 33 C7 62 62 AD 36 4A 45 D6 F2 F5 : D1 1E 31 31 22 7F 7B 79 9F E7 99 02 2F F5 1F 06 : 64 3C 22 C9 C9 FB EB 3B D7 86 CC DB 56 32 1C 7E : 86 A6 CD 0A 09 50 E2 AD 5A D9 66 39 EE 3D 27 10 : 14 C3 BA 04 29 0C D0 95 26 08 D9 E6 AF E9 0C 33 : D8 D6 BD D6 83 0E C2 2B A4 A5 B4 89 8C CA BC A2 : BB A4 40 87 AF 50 02 53 2C FD 9A 83 78 64 DE DB : D4 BC 91 5C AB E9 7D BF 17 84 C9 34 A5 6D 3D 0D Editor's Address Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-1706, USA (408) 526-4796 bew@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Weis Expires July, 2005 [Page 40]