Network Working Group C. Lynn Request for Comments: 3779 S. Kent Category: Standards Track K. Seo BBN Technologies June 2004
X.509 Extensions for IP Addresses and AS Identifiers
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. 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 Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions.
This document defines two X.509 v3 certificate extensions that authorize the transfer of the right-to-use for a set of IP addresses and autonomous system identifiers from IANA through the regional Internet registries (RIRs) to Internet service providers (ISPs) and user organizations. The first binds a list of IP address blocks, often represented as IP address prefixes, to the subject (private key holder) of a certificate. The second binds a list of autonomous system (AS) identifiers to the subject (private key holder) of a certificate. The issuer of the certificate is an entity (e.g., the IANA, a regional Internet registry, or an ISP) that has the authority to transfer custodianship of ("allocate") the set of IP address blocks and AS identifiers to the subject of the certificate. These certificates provide a scalable means of verifying the right-to-use for a set of IP address prefixes and AS identifiers. They may be used by routing protocols, such as Secure BGP [S-BGP], to verify legitimacy and correctness of routing information, or by Internet routing registries to verify data that they receive.
Sections 2 and 3 specify several rules about the encoding of the extensions defined in this specification that MUST be followed. These encoding rules serve the following purposes. First, they result in a unique encoding of the extension's value; two instances of an extension can be compared for equality octet-by-octet. Second, they achieve the minimal size encoding of the information. Third, they allow relying parties to use one-pass algorithms when performing certification path validation; in particular, the relying parties do not need to sort the information, or to implement extra code in the subset checking algorithms to handle several boundary cases (adjacent, overlapping, or subsumed ranges).
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC3280], "INTERNET PROTOCOL" [RFC791], "Internet Protocol Version 6 (IPv6) Addressing Architecture" [RFC3513], "INTERNET REGISTRY IP ALLOCATION GUIDELINES" [RFC2050], and related regional Internet registry address management policy documents. Some relevant terms include:
allocate - the transfer of custodianship of a resource to an intermediate organization (see [RFC2050]).
assign - the transfer of custodianship of a resource to an end organization (see [RFC2050]).
Lynn, et al. Standards Track [Page 3]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
Autonomous System (AS) - a set of routers under a single technical administration with a uniform policy, using one or more interior gateway protocols and metrics to determine how to route packets within the autonomous system, and using an exterior gateway protocol to determine how to route packets to other autonomous systems.
Autonomous System number - a 32-bit number that identifies an autonomous system.
delegate - transfer of custodianship (that is, the right-to-use) of an IP address block or AS identifier through issuance of a certificate to an entity.
initial octet - the first octet in the value of a DER encoded BIT STRING [X.690].
IP v4 address - a 32-bit identifier written as four decimal numbers, each in the range 0 to 255, separated by a ".". 10.5.0.5 is an example of an IPv4 address.
IP v6 address - a 128-bit identifier written as eight hexadecimal quantities, each in the range 0 to ffff, separated by a ":". 2001:0:200:3:0:0:0:1 is an example of an IPv6 address. One string of :0: fields may be replaced by "::", thus 2001:0:200:3::1 represents the same address as the immediately preceding example. (See [RFC3513]).
prefix - a bit string that consists of some number of initial bits of an address, written as an address followed by a "/", and the number of initial bits. 10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64 (or 2001:0:200:3::/64) are examples of prefixes. A prefix is often abbreviated by omitting the less-significant zero fields, but there should be enough fields to contain the indicated number of initial bits. 10.5/16 and 2001:0:200:3/64 are examples of abbreviated prefixes.
Regional Internet Registry (RIR) - any of the bodies recognized by IANA as the regional authorities for management of IP addresses and AS identifiers. At the time of writing, these include AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC.
right-to-use - for an IP address prefix, being authorized to specify the AS that may originate advertisements of the prefix throughout the Internet. For an autonomous system identifier, being authorized to operate a network(s) that identifies itself to other network operators using that autonomous system identifier.
Lynn, et al. Standards Track [Page 4]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
subsequent octets - the second through last octets in the value of a DER encoded BIT STRING [X.690].
trust anchor - a certificate that is to be trusted when performing certification path validation (see [RFC3280]).
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, and MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
IP address space is currently managed by a hierarchy nominally rooted at IANA, but managed by the RIRs. IANA allocates IP address space to the RIRs, who in turn allocate IP address space to Internet service providers (ISPs), who may allocate IP address space to down stream providers, customers, etc. The RIRs also may assign IP address space to organizations who are end entities, i.e., organizations who will not be reassigning any of their space to other organizations. (See [RFC2050] and related RIR policy documents for the guidelines on the allocation and assignment process).
The IP address delegation extension is intended to enable verification of the proper delegation of IP address blocks, i.e., of the authorization of an entity to use or sub-allocate IP address space. Accordingly, it makes sense to take advantage of the inherent authoritativeness of the existing administrative framework for allocating IP address space. As described in Section 1 above, this will be achieved by issuing certificates carrying the extension described in this section. An example of one use of the information in this extension is an entity using it to verify the authorization of an organization to originate a BGP UPDATE advertising a path to a particular IP address block; see, e.g., [RFC1771], [S-BGP].
There are two families of IP addresses: IPv4 and IPv6.
An IPv4 address is a 32-bit quantity that is written as four decimal numbers, each in the range 0 through 255, separated by a dot ("."). 10.5.0.5 is an example of an IPv4 address.
Lynn, et al. Standards Track [Page 5]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
An IPv6 address is a 128-bit quantity that is written as eight hexadecimal numbers, each in the range 0 through ffff, separated by a semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 address. IPv6 addresses frequently have adjacent fields whose value is 0. One such group of 0 fields may be abbreviated by two semicolons ("::"). The previous example may thus be represented by 2001:0:200:3::1.
An address prefix is a set of 2^k continuous addresses whose most- significant bits are identical. For example, the set of 512 IPv4 addresses from 10.5.0.0 through 10.5.1.255 all have the same 23 most-significant bits. The set of addresses is written by appending a slash ("/") and the number of constant bits to the lowest address in the set. The prefix for the example set is 10.5.0.0/23, and contains 2^(32-23) = 2^9 addresses. The set of IPv6 addresses 2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff (2^89 addresses) is represented by 2001:0:200:0:0:0:0:0/39 or equivalently 2001:0:200::/39. A prefix may be abbreviated by omitting the least-significant zero fields, but there should be enough fields to contain the indicated number of constant bits. The abbreviated forms of the example IPv4 prefix is 10.5.0/23, and of the example IPv6 prefix is 2001:0:200/39.
An IP address or prefix is encoded in the IP address delegation extension as a DER-encoded ASN.1 BIT STRING containing the constant most-significant bits. Recall [X.690] that the DER encoding of a BIT STRING consists of the BIT STRING type (0x03), followed by (an encoding of) the number of value octets, followed by the value. The value consists of an "initial octet" that specifies the number of unused bits in the last value octet, followed by the "subsequent octets" that contain the octets of the bit string. (For IP addresses, the encoding of the length will be just the length.)
In the case of a single address, all the bits are constant, so the bit string for an IPv4 address contains 32 bits. The subsequent octets in the DER-encoding of the address 10.5.0.4 are 0x0a 0x05 0x00 0x04. Since all the bits in the last octet are used, the initial octet is 0x00. The octets in the DER-encoded BIT STRING is thus:
Type Len Unused Bits ... 0x03 0x05 0x00 0x0a 0x05 0x00 0x04
Similarly, the DER-encoding of the prefix 10.5.0/23 is:
Type Len Unused Bits ... 0x03 0x04 0x01 0x0a 0x05 0x00
Lynn, et al. Standards Track [Page 6]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
In this case, the three subsequent octets contain 24 bits, but the prefix only uses 23, so there is one unused bit in the last octet, thus the initial octet is 1 (the DER require that all unused bits MUST be set to zero-bits).
The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:
While any contiguous range of IP addresses can be represented by a set of contiguous prefixes, a more concise representation is achieved by encoding the range as a SEQUENCE containing the lowest address and the highest address, where each address is encoded as a BIT STRING. Within the SEQUENCE, the bit string representing the lowest address in the range is formed by removing all the least-significant zero- bits from the address, and the bit string representing the highest address in the range is formed by removing all the least-significant one-bits. The DER BIT STRING encoding requires that all the unused bits in the last octet MUST be set to zero-bits. Note that a prefix can always be expressed as a range, but a range cannot always be expressed as a prefix.
The range of addresses represented by the prefix 10.5.0/23 is 10.5.0.0 through 10.5.1.255. The lowest address ends in sixteen zero-bits that are removed. The DER-encoding of the resulting sixteen-bit string is:
Type Len Unused Bits ... 0x03 0x03 0x00 0x0a 0x05
The highest address ends in nine one-bits that are removed. The DER- encoding of the resulting twenty-three-bit string is:
Type Len Unused Bits ... 0x03 0x04 0x01 0x0a 0x05 0x00
Lynn, et al. Standards Track [Page 7]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
The prefix 2001:0:200/39 can be encoded as a range where the DER- encoding of the lowest address (2001:0:200::) is:
Type Len Unused Bits ... 0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which, after removal of the ninety least-significant one-bits leaves a thirty-eight bit string, is encoded as:
Type Len Unused Bits ... 0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
The special case of all IP address blocks, i.e., a prefix of all zero-bits -- "0/0", MUST be encoded per the DER with a length octet of one, an initial octet of zero, and no subsequent octets:
Type Len Unused Bits ... 0x03 0x01 0x00
Note that for IP addresses the number of trailing zero-bits is significant. For example, the DER-encoding of 10.64/12:
Type Len Unused Bits ... 0x03 0x03 0x04 0x0a 0x40
is different than the DER-encoding of 10.64.0/20:
Type Len Unused Bits ... 0x03 0x04 0x04 0x0a 0x40 0x00
This extension SHOULD be CRITICAL. The intended use of this extension is to connote a right-to-use for the block(s) of IP addresses identified in the extension. A CA marks the extension as CRITICAL to convey the notion that a relying party MUST understand the semantics of the extension to make use of the certificate for the purpose it was issued. Newly created applications that use certificates containing this extension are expected to recognize the extension.
The addressFamily element is an OCTET STRING containing a two-octet Address Family Identifier (AFI), in network byte order, optionally followed by a one-octet Subsequent Address Family Identifier (SAFI). AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI], respectively.
If no authorization is being granted for a particular AFI and optional SAFI, then there MUST NOT be an IPAddressFamily member for that AFI/SAFI in the IPAddrBlocks SEQUENCE.
There MUST be only one IPAddressFamily SEQUENCE per unique combination of AFI and SAFI. Each SEQUENCE MUST be ordered by ascending addressFamily values (treating the octets as unsigned quantities). An addressFamily without a SAFI MUST precede one that contains an SAFI. When both IPv4 and IPv6 addresses are specified, the IPv4 addresses MUST precede the IPv6 addresses (since the IPv4 AFI of 0001 is less than the IPv6 AFI of 0002).
2.2.3.4. Element ipAddressChoice and Type IPAddressChoice
The ipAddressChoice element is of type IPAddressChoice. The IPAddressChoice type is a CHOICE of either an inherit or addressesOrRanges element.
If the IPAddressChoice CHOICE contains the inherit element, then the set of authorized IP addresses for the specified AFI and optional SAFI is taken from the issuer's certificate, or from the issuer's issuer's certificate, recursively, until a certificate containing an IPAddressChoice containing an addressesOrRanges element is located.
The addressesOrRanges element is a SEQUENCE OF IPAddressOrRange types. The addressPrefix and addressRange elements MUST be sorted using the binary representation of:
<lowest IP address in range> | <prefix length>
where "|" represents concatenation. Note that the octets in this representation (a.b.c.d | length for IPv4 or s:t:u:v:w:x:y:z | length for IPv6) are not the octets that are in the DER-encoded BIT STRING value. For example, given two addressPrefix:
Lynn, et al. Standards Track [Page 10]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
IP addr | length DER encoding ---------------- ------------------------ Type Len Unused Bits... 10.32.0.0 | 12 03 03 04 0a 20 10.64.0.0 | 16 03 03 00 0a 40
the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16 since 32 is less than 64; whereas if one were to sort by the DER BIT STRINGs, the order would be reversed as the unused bits octet would sort in the opposite order. Any pair of IPAddressOrRange choices in an extension MUST NOT overlap each other. Any contiguous address prefixes or ranges MUST be combined into a single range or, whenever possible, a single prefix.
The IPAddressOrRange type is a CHOICE of either an addressPrefix (an IP prefix or address) or an addressRange (an IP address range) element.
This specification requires that any range of addresses that can be encoded as a prefix MUST be encoded using an IPAddress element (a BIT STRING), and any range that cannot be encoded as a prefix MUST be encoded using an IPAddressRange (a SEQUENCE containing two BIT STRINGs). The following pseudo code illustrates how to select the encoding of a given range of addresses.
LET N = the number of matching most-significant bits in the lowest and highest addresses of the range IF all the remaining bits in the lowest address are zero-bits AND all the remaining bits in the highest address are one-bits THEN the range MUST be encoded as an N-bit IPAddress ELSE the range MUST be encoded as an IPAddressRange
The addressPrefix element is an IPAddress type. The IPAddress type defines a range of IP addresses in which the most-significant (left- most) N bits of the address remain constant, while the remaining bits (32 - N bits for IPv4, or 128 - N bits for IPv6) may be either zero or one. For example, the IPv4 prefix 10.64/12 corresponds to the addresses 10.64.0.0 to 10.79.255.255, while 10.64/11 corresponds to 10.64.0.0 to 10.95.255.255. The IPv6 prefix 2001:0:2/48 represents addresses 2001:0:2:: to 2001:0:2:ffff:ffff:ffff:ffff:ffff.
An IP address prefix is encoded as a BIT STRING. The DER encoding of a BIT STRING uses the initial octet of the string to specify how many of the least-significant bits of the last subsequent octet are
Lynn, et al. Standards Track [Page 11]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
unused. The DER encoding specifies that these unused bits MUST be set to zero-bits.
Example: 128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000 to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111 bit string to encode = 1000 Type Len Unused Bits ... Encoding = 0x03 0x02 0x04 0x80
2.2.3.9. Element addressRange and Type IPAddressRange
The addressRange element is of type IPAddressRange. The IPAddressRange type consists of a SEQUENCE containing a minimum (element min) and maximum (element max) IP address. Each IP address is encoded as a BIT STRING. The semantic interpretation of the minimum address in an IPAddressRange is that all the unspecified bits (for the full length of the IP address) are zero-bits. The semantic interpretation of the maximum address is that all the unspecified bits are one-bits. The BIT STRING for the minimum address results from removing all the least-significant zero-bits from the minimum address. The BIT STRING for the maximum address results from removing all the least-significant one-bits from the maximum address.
Example: 129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000 to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111 minimum bit string = 1000 0001.01 maximum bit string = 1000 Encoding = SEQUENCE { Type Len Unused Bits ... min 0x03 0x03 0x06 0x81 0x40 max 0x03 0x02 0x04 0x80 }
To simplify the comparison of IP address blocks when performing certification path validation, a maximum IP address MUST contain at least one bit whose value is 1, i.e., the subsequent octets may not be omitted nor all zero.
2.3. IP Address Delegation Extension Certification Path Validation
Certification path validation of a certificate containing the IP address delegation extension requires additional processing. As each certificate in a path is validated, the IP addresses in the IP address delegation extension of that certificate MUST be subsumed by IP addresses in the IP address delegation extension in the issuer's certificate. Validation MUST fail when this is not the case. A
Lynn, et al. Standards Track [Page 12]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
certificate that is a trust anchor for certification path validation of certificates containing the IP address delegation extension, as well as all certificates along the path, MUST each contain the IP address delegation extension. The initial set of allowed address ranges is taken from the trust anchor certificate.
3. Autonomous System Identifier Delegation Extension
This extension conveys the allocation of autonomous system (AS) identifiers to an entity by binding those AS identifiers to a public key belonging to the entity.
AS identifier delegation is currently managed by a hierarchy nominally rooted at IANA, but managed by the RIRs. IANA allocates AS identifiers to the RIRs, who in turn assign AS identifiers to organizations who are end entities, i.e., will not be re-allocating any of their AS identifiers to other organizations. The AS identifier delegation extension is intended to enable verification of the proper delegation of AS identifiers, i.e., of the authorization of an entity to use these AS identifiers. Accordingly, it makes sense to take advantage of the inherent authoritativeness of the existing administrative framework for management of AS identifiers. As described in Section 1 above, this will be achieved by issuing certificates carrying the extension described in this section. An example of one use of the information in this extension is an entity using it to verify the authorization of an organization to manage the AS identified by an AS identifier in the extension. The use of this extension to represent assignment of AS identifiers is not intended to alter the procedures by which AS identifiers are managed, or when an AS should be used c.f., [RFC1930].
This extension SHOULD be CRITICAL. The intended use of this extension is to connote a right-to-use for the AS identifiers in the extension. A CA marks the extension as CRITICAL to convey the notion that a relying party must understand the semantics of the extension to make use of the certificate for the purpose it was issued. Newly created applications that use certificates containing this extension are expected to recognize the extension.
The ASIdentifiers type is a SEQUENCE containing one or more forms of autonomous system identifiers -- AS numbers (in the asnum element) or routing domain identifiers (in the rdi element). When the ASIdentifiers type contains multiple forms of identifiers, the asnum entry MUST precede the rdi entry. AS numbers are used by BGP, and routing domain identifiers are specified in the IDRP [RFC1142].
3.2.3.2. Elements asnum, rdi, and Type ASIdentifierChoice
The asnum and rdi elements are both of type ASIdentifierChoice. The ASIdentifierChoice type is a CHOICE of either the inherit or asIdsOrRanges element.
Lynn, et al. Standards Track [Page 14]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
If the ASIdentifierChoice choice contains the inherit element, then the set of authorized AS identifiers is taken from the issuer's certificate, or from the issuer's issuer's certificate, recursively, until a certificate containing an ASIdentifierChoice containing an asIdsOrRanges element is located. If no authorization is being granted for a particular form of AS identifier, then there MUST NOT be a corresponding asnum/rdi member in the ASIdentifiers sequence.
The asIdsOrRanges element is a SEQUENCE of ASIdOrRange types. Any pair of items in the asIdsOrRanges SEQUENCE MUST NOT overlap. Any contiguous series of AS identifiers MUST be combined into a single range whenever possible. The AS identifiers in the asIdsOrRanges element MUST be sorted by increasing numeric value.
The min and max elements have type ASId. The min element is used to specify the value of the minimum AS identifier in the range, and the max element specifies the value of the maximum AS identifier in the range.
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
3.3. Autonomous System Identifier Delegation Extension Certification Path Validation
Certification path validation of a certificate containing the autonomous system identifier delegation extension requires additional processing. As each certificate in a path is validated, the AS identifiers in the autonomous system identifier delegation extension of that certificate MUST be subsumed by the AS identifiers in the autonomous system identifier delegation extension in the issuer's certificate. Validation MUST fail when this is not the case. A certificate that is a trust anchor for certification path validation of certificates containing the autonomous system identifier delegation extension, as well as all certificates along the path, MUST each contain the autonomous system identifier delegation extension. The initial set of allowed AS identifiers is taken from the trust anchor certificate.
This specification describes two X.509 extensions. Since X.509 certificates are digitally signed, no additional integrity service is necessary. Certificates with these extensions need not be kept secret, and unrestricted and anonymous access to these certificates 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.
These extensions represent authorization information, i.e., a right- to-use for IP addresses or AS identifiers. They were developed to support a secure version of BGP [S-BGP], but may be employed in other contexts. In the secure BGP context, certificates containing these extensions function as capabilities: the certificate asserts that the holder of the private key (the Subject) is authorized to use the IP addresses or AS identifiers represented in the extension(s). As a result of this capability model, the Subject field is largely irrelevant for security purposes, contrary to common PKI conventions.
The authors would like to acknowledge the contributions to this specification by Charles Gardiner, Russ Housley, James Manger, and Jim Schaad.
Lynn, et al. Standards Track [Page 16]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
Appendix A -- ASN.1 Module
This normative appendix describes the IP address and AS identifiers extensions used by conforming PKI components in ASN.1 syntax.
IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- Copyright (C) The Internet Society (2004). This -- -- version of this ASN.1 module is part of RFC 3779; -- -- see the RFC itself for full legal notices. --
-- EXPORTS ALL --
IMPORTS
-- PKIX specific OIDs and arcs -- id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) };
ASIdentifierChoice ::= CHOICE { inherit NULL, -- inherit from issuer -- asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE { id ASId, range ASRange }
ASRange ::= SEQUENCE { min ASId, max ASId }
ASId ::= INTEGER
END
Appendix B -- Examples of IP Address Delegation Extensions
A critical X.509 v3 certificate extension that specifies: IPv4 unicast address prefixes 1) 10.0.32/20 i.e., 10.0.32.0 to 10.0.47.255 2) 10.0.64/24 i.e., 10.0.64.0 to 10.0.64.255 3) 10.1/16 i.e., 10.1.0.0 to 10.1.255.255 4) 10.2.48/20 i.e., 10.2.48.0 to 10.2.63.255 5) 10.2.64/24 i.e., 10.2.64.0 to 10.2.64.255 6) 10.3/16 i.e., 10.3.0.0 to 10.3.255.255, and 7) inherits all IPv6 addresses from the issuer's certificate would be (in hexadecimal):
This example illustrates how the prefixes and ranges are sorted.
+ Prefix 1 MUST precede prefix 2, even though the number of unused bits (4) in prefix 1 is larger than the number of unused bits (0) in prefix 2.
+ Prefix 2 MUST precede prefix 3 even though the number of octets (4) in the BIT STRING encoding of prefix 2 is larger than the number of octets (3) in the BIT STRING encoding of prefix 3.
+ Prefixes 4 and 5 are adjacent (representing the range of addresses from 10.2.48.0 to 10.2.64.255), so MUST be combined into a range (since the range cannot be encoded by a single prefix).
+ Note that the six trailing zero bits in the max element of the range are significant to the semantic interpretation of the value (as all unused bits are interpreted to be 1's, not 0's). The four trailing zero bits in the min element are not significant and MUST be removed (thus the (4) unused bits in the encoding of the min element). (DER encoding requires that any unused bits in the last subsequent octet MUST be set to zero.)
Lynn, et al. Standards Track [Page 19]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
+ The range formed by prefixes 4 and 5 MUST precede prefix 6 even though the SEQUENCE tag for a range (30) is larger than the tag for the BIT STRING (03) used to encode prefix 6.
+ The IPv4 information MUST precede the IPv6 information since the address family identifier for IPv4 (0001) is less than the identifier for IPv6 (0002).
An extension specifying the IPv6 prefix 2001:0:2/48 and the IPv4 prefixes 10/8 and 172.16/12, and which inherits all IPv4 multicast addresses from the issuer's certificate would be (in hexadecimal):
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
Appendix C -- Example of an AS Identifier Delegation Extension
An extension that specifies AS numbers 135, 3000 to 3999, and 5001, and which inherits all routing domain identifiers from the issuer's certificate would be (in hexadecimal):
This appendix discusses issues arising from a proposal to use attribute certificates (ACs, as specified in [RFC3281]) to convey, from the Regional Internet Registries (RIRs) to the end-user organizations, the "right-to-use" for IP address blocks or AS identifiers.
The two resources, AS identifiers and IP address blocks, are currently managed differently. All organizations with the right-to- use for an AS identifier receive the authorization directly from an RIR. Organizations with a right-to-use for an IP address block receive the authorization either directly from an RIR, or indirectly, e.g., from a down stream service provider, who might receive its
Lynn, et al. Standards Track [Page 21]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
authorization from an Internet service provider, who in turn gets its authorization from a RIR. Note that AS identifiers might be sub- allocated in the future, so the mechanisms used should not rely upon a three level hierarchy.
In section 1 of RFC 3281, two reasons are given for why the use of ACs might be preferable to the use of public key certificates (PKCs) with extensions that convey the authorization information:
"Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source."
"For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes."
In the case of the IP address and AS identifier authorizations, these reasons do not apply. First, the public key certificates are issued exclusively for authorization, so the certificate lifetime corresponds exactly to the authorization lifetime, which is often tied to a contractual relationship between the issuer and entity receiving the authorization. The Subject and Issuer names are only used for chaining during certification path validation, and the names need not correspond to any physical entity. The Subject name in the PKCs may actually be randomly assigned by the issuing CA, allowing the resource holder limited anonymity. Second, the certificate hierarchy is constructed so that the certificate issuer is authoritative for the authorization information.
Thus the two points in the first cited paragraph above are not true in the case of AS number and IP address block allocations. The point of the second cited paragraph is also not applicable as the resources are not being bound to an identity but to the holder of the private key corresponding to the public key in the PKC.
Lynn, et al. Standards Track [Page 22]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
RFC 3281 specifies several requirements that a conformant Attribute Certificate must meet. In relation to S-BGP, the more-significant requirements are:
1 from section 1: "this specification does NOT RECOMMEND the use of AC chains. Other (future) specifications may address the use of AC chains."
Allocation from IANA to RIRs to ISPs to DSPs and assignment to end organizations would require the use of chains, at least for IP address blocks. A description of how the superior's AC should be located and how it should be processed would have to be provided. Readers of this document are encouraged to propose ways the chaining might be avoided.
2 from section 4.2.9: "section 4.3 defines the extensions that MAY be used with this profile, and whether or not they may be marked critical. If any other critical extension is used, the AC does not conform to this profile. However, if any other non-critical extension is used, the AC does conform to this profile."
This means that the delegation extensions defined in this specification, which are critical, could not be simply placed into an AC. They could be used if not marked critical, but the intended use requires that the extensions be critical so that the certificates containing them cannot be used as identity certificates by an unsuspecting application.
3 from section 4.5: "an AC issuer, MUST NOT also be a PKC issuer. That is, an AC issuer cannot be a CA as well."
This means that for each AC issuer there would need to be a separate CA to issue the PKC that contains the public key of the AC holder. The AC issuer cannot issue the PKC of the holder, and the PKC issuer cannot sign the AC. Thus, each entity in the PKI would need to operate an AC issuer in addition to its CA. There would be twice as many certificate issuers and CRLs to process to support Attribute certificates than are needed if PKCs are used. The possibility of mis-alignment also arises when there are two issuers issuing certificates for a single purpose.
The AC model of RFC 3281 implies that the AC holder presents the AC to the AC verifier when the holder wants to substantiate an attribute or authorization. The intended usage for the extensions defined herein does not have a direct interaction between an AC verifier (a NOC) and the AC issuers (all RIRs and NOCs). Given a
Lynn, et al. Standards Track [Page 23]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
signature on a claimed right-to-use object, the "AC verifier" can locate the AC holder's PKC, but there is no direct way to locate the Subject's AC(s).
4 from section 5: "4. The AC issuer MUST be directly trusted as an AC issuer (by configuration or otherwise)."
This is not true in the case of a right-to-use for an IP address block, which is allocated through a hierarchy. Certification path validation of the AC will require chaining up through the delegation hierarchy. Having to configure each relying party (NOC) to "trust" every other NOC does not scale, and such "trust" has resulted in failures that the proposed security mechanisms are designed to prevent. A single PKI with a trusted root is used, not thousands of individually trusted per-ISP AC issuers.
The amount of work that would be required to properly validate an AC is larger than for the mechanism that places the certificate extensions defined in this document in the PKCs. There would be twice as many certificates to be validated, in addition to the ACs. There could be a considerable increase in the management burden required to support ACs.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
Informational References
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program Protocol Specification", RFC 791, September 1981.
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC 1142, February 1990.
[RFC1771] Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway Protocol (S-BGP)," IEEE JSAC Special Issue on Network Security, April 2000.
Lynn, et al. Standards Track [Page 25]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
Authors' Address
Charles Lynn BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Phone: +1 (617) 873-3367 EMail: CLynn@BBN.Com
Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Phone: +1 (617) 873-3988 EMail: Kent@BBN.Com
Karen Seo BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Phone: +1 (617) 873-3152 EMail: KSeo@BBN.Com
Lynn, et al. Standards Track [Page 26]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.