RFC 3779
X.509 Extensions for IP Addresses and AS Identifiers
RFC 3779 🎀
Title: X.509 Extensions for IP Addresses and AS Identifiers ✨
Authors: C. Lynn, S. Kent, and K. Seo, all from BBN Technologies 💜
Stream: Network Working Group 🌸
Category: Standards Track 🦋
Date: June 2004 📅
Obsoletes / Updates: The header doesn't list any RFCs this one obsoletes or updates. It's a fresh start 💅
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice ⭐
Copyright (C) The Internet Society (2004).
Abstract 🔥
Okay so this document defines two X.509 v3 certificate extensions 👑. The first one binds a list of IP address blocks (or prefixes) to the subject of a certificate. The second one binds a list of autonomous system identifiers to the subject of a certificate. Both can be used to convey that the subject is authorized to use the IP addresses and autonomous system identifiers listed in the extensions. It's giving authorization paperwork, but make it cryptographic 🔐✨
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. IP Address Delegation Extension. . . . . . . . . . . . . . . . 5
2.1. Context. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Encoding of an IP Address or Prefix. . . . . . . 5
2.1.2. Encoding of a Range of IP Addresses. . . . . . . 7
2.2. Specification. . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Criticality. . . . . . . . . . . . . . . . . . . 9
2.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.1. Type IPAddrBlocks. . . . . . . . . . . 9
2.2.3.2. Type IPAddressFamily . . . . . . . . . 9
2.2.3.3. Element addressFamily. . . . . . . . . 10
2.2.3.4. Element ipAddressChoice and Type
IPAddressChoice. . . . . . . . . . . . 10
2.2.3.5. Element inherit. . . . . . . . . . . . 10
2.2.3.6. Element addressesOrRanges. . . . . . . 10
2.2.3.7. Type IPAddressOrRange. . . . . . . . . 11
2.2.3.8. Element addressPrefix and Type
IPAddress. . . . . . . . . . . . . . . 11
2.2.3.9. Element addressRange and Type
IPAddressRange . . . . . . . . . . . . 12
2.3. IP Address Delegation Extension Certification Path
Validation . . . . . . . . . . . . . . . . . . . . . . . 12
3. Autonomous System Identifier Delegation Extension. . . . . . . 13
3.1. Context . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Specification. . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Criticality. . . . . . . . . . . . . . . . . . . 14
3.2.3. Syntax . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1. Type ASIdentifiers . . . . . . . . . . 14
3.2.3.2. Elements asnum, rdi, and Type
ASIdentifierChoice . . . . . . . . . . 14
3.2.3.3. Element inherit. . . . . . . . . . . . 15
3.2.3.4. Element asIdsOrRanges. . . . . . . . . 15
3.2.3.5. Type ASIdOrRange . . . . . . . . . . . 15
3.2.3.6. Element id . . . . . . . . . . . . . . 15
3.2.3.7. Element range. . . . . . . . . . . . . 15
3.2.3.8. Type ASRange . . . . . . . . . . . . . 15
3.2.3.9. Elements min and max . . . . . . . . . 15
3.2.3.10. Type ASId. . . . . . . . . . . . . . . 15
3.3. Autonomous System Identifier Delegation Extension
Certification Path Validation. . . . . . . . . . . . . . . . 16
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A -- ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17
Appendix B -- Examples of IP Address Delegation Extensions . . . . 18
Appendix C -- Example of an AS Identifier Delegation Extension . . 21
Appendix D -- Use of X.509 Attribute Certificates. . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Normative References . . . . . . . . . . . . . . . . . . . . . . . 24
Informative References . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 271. Introduction 🌸
Bestie, 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. The transfer goes from IANA, through the regional Internet registries (RIRs), to Internet service providers (ISPs) and user organizations 🌍. The first extension binds a list of IP address blocks, often written as IP address prefixes, to the subject (the private key holder) of a certificate. The second binds a list of autonomous system (AS) identifiers to the subject (the private key holder) of a certificate 🔑. The issuer is an entity (for example, IANA, a regional Internet registry, or an ISP) that has the authority to transfer custodianship of ("allocate") those IP address blocks and AS identifiers to the subject. These certificates give you a scalable way to verify the right-to-use for a set of IP address prefixes and AS identifiers 🧚. Routing protocols such as Secure BGP [S-BGP] can use them to check that routing information is legitimate and correct, and Internet routing registries can use them to verify the data they receive 💖.
Sections 2 and 3 specify several rules about the encoding of the extensions defined here, and those rules MUST be followed 🚨. Why do they matter? Three big reasons 👑. First, they give each extension's value one unique encoding, so two instances of an extension can be compared for equality octet-by-octet. Second, they reach the minimal size encoding of the information. Third, they let relying parties use one-pass algorithms during certification path validation. Basically, relying parties don't have to sort the information, or write extra code in the subset checking algorithms to handle several boundary cases (adjacent, overlapping, or subsumed ranges) 🥹✨
1.1. Terminology 🧚
It's assumed you already know the terms and concepts 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 the related regional Internet registry address management policy documents. Here are some of the key terms 📖:
- 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]).
- Autonomous System (AS) - a set of routers under a single technical administration with a uniform policy. It uses one or more interior gateway protocols and metrics to decide how to route packets inside the autonomous system, and an exterior gateway protocol to decide 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, done by issuing 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.5is 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:1is an example of an IPv6 address. One string of:0:fields may be replaced by "::", so2001:0:200:3::1represents the same address as the example right before it (see [RFC3513]) 🦋. - prefix - a bit string made 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/16and2001:0:200:3:0:0:0:0/64(or2001:0:200:3::/64) are examples of prefixes. A prefix is often abbreviated by leaving off the less-significant zero fields, but there should be enough fields left to hold the indicated number of initial bits.10.5/16and2001:0:200:3/64are examples of abbreviated prefixes 🍓. - Regional Internet Registry (RIR) - any of the bodies IANA recognizes as the regional authorities for managing IP addresses and AS identifiers. When this was written, these included 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 👑.
- 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] 💅.
2. IP Address Delegation Extension 🦋
This extension conveys the allocation of IP addresses to an entity by binding those addresses to a public key that belongs to that entity 🔑✨
2.1. Context ✨
okay so the IP address space is basically run by a hierarchy that's nominally rooted at IANA, but the RIRs are the ones actually managing it 🌍 IANA hands out address space to the RIRs, the RIRs hand it to ISPs, and ISPs can pass pieces down to downstream providers, customers, and so on. RIRs can also assign space to organizations that are end entities, meaning orgs that won't be reassigning any of their space to anyone else 💼 (check [RFC2050] and the related RIR policy docs for the rules on allocation and assignment, bestie).
The IP address delegation extension exists so you can verify that an IP address block was properly delegated, basically proving an entity is authorized to use or sub-allocate that space 🫶 Since the existing admin framework is already the authoritative source for who gets what, it makes total sense to lean on it. As mentioned in Section 1 above, this happens by issuing certificates that carry the extension described in this section 📜 One iconic use is an entity checking whether an organization is allowed to originate a BGP UPDATE advertising a path to a particular IP address block, see e.g. [RFC1771], [S-BGP] 🦋
2.1.1. Encoding of an IP Address or Prefix
Okay the first thing to know is there are two families of IP addresses: IPv4 and IPv6 🎀
An IPv4 address is a 32-bit quantity written as four decimal numbers, each from 0 through 255, separated by a dot ("."). 10.5.0.5 is an example of an IPv4 address 🌸
An IPv6 address is a 128-bit quantity written as eight hexadecimal numbers, each from 0 through ffff, separated by a semicolon (":"). 2001:0:200:3:0:0:0:1 is an example of an IPv6 address ✨ IPv6 addresses are often full of adjacent fields that are 0, and one group of those 0 fields can be shortened to two semicolons ("::") 💅 So the previous example can be written as 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 share the same 23 most-significant bits. You write the set by adding a slash ("/") and the number of constant bits to the lowest address in the set. So the prefix for that example is 10.5.0.0/23, and it holds 2^(32-23) = 2^9 addresses 💜 The set of IPv6 addresses from 2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff (2^89 addresses) is written as 2001:0:200:0:0:0:0:0/39, or equivalently 2001:0:200::/39 🌈 You can abbreviate a prefix by dropping the least-significant zero fields, but there should be enough fields left to hold the indicated number of constant bits 🙈 So the abbreviated IPv4 example is 10.5.0/23, and the abbreviated IPv6 example is 2001:0:200/39 🫶
An IP address or prefix goes into the IP address delegation extension as a DER-encoded ASN.1 BIT STRING that holds the constant most-significant bits 📦 Recall from [X.690] that the DER encoding of a BIT STRING is the BIT STRING type (0x03), then the number of value octets (encoded as a length), then the value itself. The value starts with an "initial octet" that says how many unused bits are in the last value octet, followed by the "subsequent octets" that hold the bit string's octets. (For IP addresses, the length encoding is just the length 🧁)
For a single address, every bit is constant, so the bit string for an IPv4 address has 32 bits 💖 The subsequent octets in the DER-encoding of 10.5.0.4 are 0x0a 0x05 0x00 0x04. Since every bit in the last octet is used, the initial octet is 0x00. So the DER-encoded BIT STRING octets look like this:
Type Len Unused Bits ...
0x03 0x05 0x00 0x0a 0x05 0x00 0x04Similarly, the DER-encoding of the prefix 10.5.0/23 is:
Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00Here the three subsequent octets hold 24 bits, but the prefix only uses 23 of them, so there's one unused bit in the last octet and the initial octet is 1 (the DER requires 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:
Type Len Unused Bits ...
0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01and the DER-encoding of the prefix 2001:0:200/39, which has one unused bit in its last octet, is:
Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x022.1.2. Encoding of a Range of IP Addresses
Any contiguous range of IP addresses can be represented as a set of contiguous prefixes, BUT a more concise way exists 💅 You can encode the range as a SEQUENCE holding the lowest address and the highest address, where each address is a BIT STRING. Inside the SEQUENCE, the bit string for the lowest address is made by removing all the least-significant zero-bits from it. The bit string for the highest address is made 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 🌸 Also note that a prefix can always be expressed as a range, but a range can't always be expressed as a prefix 🧚
The range for the prefix 10.5.0/23 is 10.5.0.0 through 10.5.1.255. The lowest address ends in sixteen zero-bits, which get removed. The DER-encoding of the resulting sixteen-bit string is:
Type Len Unused Bits ...
0x03 0x03 0x00 0x0a 0x05The highest address ends in nine one-bits, which get removed. The DER-encoding of the resulting twenty-three-bit string is:
Type Len Unused Bits ...
0x03 0x04 0x01 0x0a 0x05 0x00The prefix 2001:0:200/39 can be encoded as a range. The DER-encoding of its lowest address (2001:0:200::) is:
Type Len Unused Bits ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which, after removing 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 0x00The 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 0x00Quick heads up, for IP addresses the number of trailing zero-bits really matters 👀 For example, the DER-encoding of 10.64/12:
Type Len Unused Bits ...
0x03 0x03 0x04 0x0a 0x40is different from the DER-encoding of 10.64.0/20:
Type Len Unused Bits ...
0x03 0x04 0x04 0x0a 0x40 0x002.2. Specification 🎀
2.2.1. OID
The OID for this extension is id-pe-ipAddrBlocks 🦋
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }where [RFC3280] defines:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }2.2.2. Criticality
This extension SHOULD be CRITICAL 🔥 The whole point of this extension is to signal a right-to-use for the block(s) of IP addresses it names. A CA marks the extension as CRITICAL to get across that a relying party MUST understand what the extension means before it can use the certificate for the purpose it was issued for 💅 Newly created applications that use certificates with this extension are expected to recognize it 🫶
2.2.3. Syntax
Here's the ASN.1 for the whole thing 🧚
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING2.2.3.1. Type IPAddrBlocks
The IPAddrBlocks type is a SEQUENCE OF IPAddressFamily types 🌸
2.2.3.2. Type IPAddressFamily
The IPAddressFamily type is a SEQUENCE containing an addressFamily element and an ipAddressChoice element 💖
2.2.3.3. Element addressFamily
The addressFamily element is an OCTET STRING holding 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 a 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 element or an addressesOrRanges element 🦋
2.2.3.5. Element inherit
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 with an addressesOrRanges element is found 🔍
2.2.3.6. Element addressesOrRanges
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 values:
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 40the prefix 10.32.0.0/12 MUST come before the prefix 10.64.0.0/16, since 32 is less than 64. Whereas if you sorted by the DER BIT STRINGs, the order would flip, because the unused bits octet sorts 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 💜
2.2.3.7. Type IPAddressOrRange ✨
okay so IPAddressOrRange is a CHOICE 💅 of either an addressPrefix (an IP prefix or address) or an addressRange (an IP address range) element.
this spec is super strict about it 🙈 any range that can be encoded as a prefix MUST be encoded using an IPAddress element (a BIT STRING), and any range that can't be a prefix MUST be encoded using an IPAddressRange (a SEQUENCE containing two BIT STRINGs). here's the pseudo code for picking the right encoding 🎀
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 IPAddressRange2.2.3.8. Element addressPrefix and Type IPAddress 🦋
the addressPrefix element is an IPAddress type ✨ and an IPAddress describes a range where the leftmost N bits stay constant, while the remaining bits (32 - N bits for IPv4, or 128 - N bits for IPv6) can be either zero or one. for example, the IPv4 prefix 10.64/12 covers 10.64.0.0 to 10.79.255.255, while 10.64/11 covers 10.64.0.0 to 10.95.255.255. and the IPv6 prefix 2001:0:2/48 represents 2001:0:2:: to 2001:0:2:ffff:ffff:ffff:ffff:ffff. iconic 😭
an IP address prefix gets encoded as a BIT STRING. the DER encoding of a BIT STRING uses the first octet of the string to say how many of the least-significant bits of the last octet are unused. the DER encoding also says those 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 0x802.2.3.9. Element addressRange and Type IPAddressRange 🍓
the addressRange element is of type IPAddressRange. an IPAddressRange is a SEQUENCE with a minimum (element min) and a maximum (element max) IP address, and each address is encoded as a BIT STRING. so for the minimum address, the meaning is that all the unspecified bits (for the full length of the IP address) are zero-bits 🤍 and for the maximum address, all the unspecified bits are one-bits 💜. the BIT STRING for the minimum address comes from removing all the least-significant zero-bits from it, and the BIT STRING for the maximum address comes from removing all the least-significant one-bits from it. bestie this part is a lot but it's giving puzzle energy 🧩
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 keep comparing IP address blocks easy during 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. so no leaving the end off or making it all zeros, periodt 💅
2.3. IP Address Delegation Extension Certification Path Validation 🔗
certification path validation of a certificate with the IP address delegation extension needs some extra processing ✨ as each certificate in a path gets validated, the IP addresses in that certificate's IP address delegation extension MUST be subsumed by the IP addresses in the IP address delegation extension of the issuer's certificate. if that isn't the case, validation MUST fail 🙅♀️ a certificate that is a trust anchor for validating certificates with the IP address delegation extension, plus all the certificates along the path, MUST each contain the IP address delegation extension. the starting set of allowed address ranges comes 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 that belongs to the entity 🔑
3.1. Context 🌈
okay so AS identifier delegation is currently managed by a hierarchy nominally rooted at IANA, but the RIRs actually run it 🏛️ IANA allocates AS identifiers to the RIRs, who then assign them to organizations that are end entities, i.e., organizations that will not be re-allocating any of their AS identifiers to other organizations. the AS identifier delegation extension is meant to make it possible to verify that AS identifiers were delegated properly, i.e., that an entity is actually authorized to use them 🫶 so it makes total sense to lean on the inherent authoritativeness of the existing admin system for managing AS identifiers. as described in Section 1 above, this gets done by issuing certificates that carry the extension described in this section ✨ one example use: an entity can use the extension to verify that an organization is authorized to manage the AS identified by an AS identifier in the extension. and using this extension to represent assignment of AS identifiers isn't meant to change how AS identifiers are managed, or when an AS should be used c.f., [RFC1930] 🙈 no drama, just verification.
3.2. Specification 💖
3.2.1. OID 🎀
the OID for this extension is id-pe-autonomousSysIds.
The OID for this extension is id-pe-autonomousSysIds.
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
where [RFC3280] defines:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }3.2.2. Criticality 🚨
this extension SHOULD be CRITICAL. the whole point of it is to signal a right-to-use for the AS identifiers in the extension 🔐 a CA marks it as CRITICAL to say that a relying party must understand what the extension means before using the certificate for the purpose it was issued for 🙌 and newly created applications that use certificates with this extension are expected to recognize it. literally the main character of the cert 👑
3.2.3. Syntax 🧩
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER3.2.3.1. Type ASIdentifiers 🦋
the ASIdentifiers type is a SEQUENCE holding one or more forms of autonomous system identifiers: AS numbers (in the asnum element) or routing domain identifiers (in the rdi element) 💅 when it has multiple forms, 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. and the ASIdentifierChoice type is a CHOICE of either the inherit element or the asIdsOrRanges element 🎀
3.2.3.3. Element inherit 🍓
if the ASIdentifierChoice choice contains the inherit element, then the set of authorized AS identifiers comes from the issuer's certificate, or from the issuer's issuer's certificate, and so on recursively, until it finds a certificate with an ASIdentifierChoice that contains an asIdsOrRanges element 🔁 and 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 🙅♀️
3.2.3.4. Element asIdsOrRanges 💜
the asIdsOrRanges element is a SEQUENCE of ASIdOrRange types ✨ any pair of items in that SEQUENCE MUST NOT overlap 🚫 any contiguous series of AS identifiers MUST be combined into a single range whenever possible 🧁 and the AS identifiers in the asIdsOrRanges element MUST be sorted by increasing numeric value 📈 neat and tidy, iykyk.
3.2.3.5. Type ASIdOrRange 🫧
the ASIdOrRange type is a CHOICE of either a single integer (ASId) or a single sequence (ASRange) 💅
3.2.3.6. Element id 🌷
the id element has type ASId 💖
3.2.3.7. Element range 🎈
the range element has type ASRange 🦄
3.2.3.8. Type ASRange 🍭
the ASRange type is a SEQUENCE made of a min and a max element, and it's used to specify a range of AS identifier values 🧚
3.2.3.9. Elements min and max 🌈
the min and max elements have type ASId. the min element specifies 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 🎯
3.2.3.10. Type ASId 💎
the ASId type is an INTEGER. that's it, that's the whole type 😭
3.3. Autonomous System Identifier Delegation Extension Certification Path Validation 🔍
certification path validation of a certificate with the autonomous system identifier delegation extension needs extra processing 🛠️ as each certificate in a path gets validated, the AS identifiers in that certificate's autonomous system identifier delegation extension MUST be subsumed by the AS identifiers in the autonomous system identifier delegation extension of the issuer's certificate. if that's not the case, validation MUST fail 🙅♀️ a certificate that is a trust anchor for validating certificates with the autonomous system identifier delegation extension, plus all the certificates along the path, MUST each contain the autonomous system identifier delegation extension. the starting set of allowed AS identifiers comes from the trust anchor certificate 👑
4. Security Considerations 🔐
this specification describes two X.509 extensions. since X.509 certificates are digitally signed, no extra integrity service is needed 🙌 certificates with these extensions don't need to be kept secret, and unrestricted, anonymous access to these certificates has no security implications 🫶
⚠️ but security factors outside the scope of this specification will affect how much assurance certificate users actually get. this section highlights the critical issues that implementors, administrators, and users need to consider 👀
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 they can be used in other contexts too 🌐 in the secure BGP context, certificates with these extensions work 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) 🔑 because of this capability model, the Subject field is largely irrelevant for security purposes, which is kinda the opposite of common PKI conventions 🙈 plot twist 💀
5. Acknowledgments 🙏✨
Okay, big thank-you time 💖 The authors wanna shout out Charles Gardiner, Russ Housley, James Manger, and Jim Schaad for helping make this spec happen. They're absolute legends 👑
Appendix A -- ASN.1 Module 📜
This one's normative, so it's the official source of truth for the IP address and AS identifier extensions in ASN.1 syntax 💅 Here's the whole module, copied exactly:
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) };
-- IP Address Delegation Extension OID --
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
-- IP Address Delegation Extension Syntax --
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & opt SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
-- Autonomous System Identifier Delegation Extension OID --
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
-- Autonomous System Identifier Delegation Extension Syntax --
ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] ASIdentifierChoice OPTIONAL }
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
ENDAppendix B -- Examples of IP Address Delegation Extensions 🌸
Picture a critical X.509 v3 certificate extension that specifies this lineup of IPv4 unicast address prefixes, plus inherits all IPv6 addresses from the issuer's certificate:
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 certificateIt would look like this in hex 🧚
30 46 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 37 extnValue {
30 35 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 24 addressesOrRanges {
IPAddressOrRange
03 04 04 0a0020 addressPrefix 10.0.32/20
IPAddressOrRange
03 04 00 0a0040 addressPrefix 10.0.64/24
IPAddressOrRange
03 03 00 0a01 addressPrefix 10.1/16
IPAddressOrRange
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} -- addressRange
IPAddressOrRange
03 03 00 0a03 addressPrefix 10.3/16
} -- addressesOrRanges
} -- IPAddressFamily
30 06 IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- ExtensionThis example shows how the prefixes and ranges get sorted 👀 The rules are:
- 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 they 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.)
- 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).
Next up, an extension specifying the IPv6 prefix 2001:0:2/48 and the IPv4 prefixes 10/8 and 172.16/12, which also inherits all IPv4 multicast addresses from the issuer's certificate. In hex, that's:
30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 b010 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- ExtensionAppendix C -- Example of an AS Identifier Delegation Extension 🦋
Here's an extension that specifies AS numbers 135, 3000 to 3999, and 5001, and which inherits all routing domain identifiers from the issuer's certificate. In hexadecimal, it would be:
30 2b Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1c extnValue {
30 1a ASIdentifiers {
a0 14 asnum
ASIdentifierChoice
30 12 asIdsOrRanges {
ASIdOrRange
02 02 0087 ASId
ASIdOrRange
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
ASIdOrRange
02 02 1389 ASId
} -- asIdsOrRanges
} -- asnum
a1 02 rdi {
ASIdentifierChoice
05 00 inherit from issuer
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- ExtensionAppendix D -- Use of X.509 Attribute Certificates ✨
Okay bestie, this appendix is all about a proposal 🦋 to use attribute certificates (ACs, as specified in [RFC3281]) to hand out the "right-to-use" for IP address blocks or AS identifiers, going from the Regional Internet Registries (RIRs) down to the end-user organizations. 💅
Here's the tea. AS identifiers and IP address blocks are managed differently 🙈. Every organization with a right-to-use for an AS identifier gets that authorization directly from an RIR. IP address block folks can get it directly from an RIR too, or indirectly, like from a downstream service provider, who might get it from an Internet service provider, who in turn gets it from an RIR. Also, AS identifiers might get sub-allocated in the future, so the mechanisms used should not rely upon a three level hierarchy. Plan for more layers, bestie 🧚
In section 1 of RFC 3281, two reasons are given for why ACs might be nicer than public key certificates (PKCs) with extensions that carry the authorization info:
"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."
Okay but here's where it gets interesting 🔥. For IP address and AS identifier authorizations, those reasons just don't apply. First, the public key certificates are issued exclusively for authorization, so the certificate lifetime lines up exactly with the authorization lifetime, which is often tied to a contractual relationship between the issuer and the entity receiving the authorization. The Subject and Issuer names are only used for chaining during certification path validation, and those names don't need to match any physical entity. The Subject name might even be randomly assigned by the issuing CA, which gives the resource holder limited anonymity 🫶. Second, the certificate hierarchy is built so that the certificate issuer is authoritative for the authorization information.
So the two points in the first cited paragraph are not true for AS number and IP address block allocations. The point of the second cited paragraph doesn't apply either, because the resources aren't being bound to an identity. They're bound to the holder of the private key that matches the public key in the PKC. ✨
RFC 3281 has several requirements that a conformant Attribute Certificate must meet. For S-BGP, these are the more-significant ones 👑:
- 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 need chains, at least for IP address blocks. You'd have to describe how the superior's AC should be located and how it should be processed. Readers are encouraged to propose ways the chaining might be avoided 💖.
- 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 the delegation extensions defined in this specification, which are critical, couldn't just be dropped into an AC. They could be used if not marked critical, but the intended use requires them to be critical, so the certificates carrying them can't be used as identity certificates by an unsuspecting application 🙈.
- 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 each AC issuer would need a separate CA to issue the PKC that contains the public key of the AC holder. The AC issuer can't issue the holder's PKC, and the PKC issuer can't sign the AC. So every entity in the PKI would need to run an AC issuer in addition to its CA. That's twice as many certificate issuers and CRLs to process to support attribute certificates compared with using PKCs alone 😭. Two issuers issuing certificates for a single purpose also opens the door to mis-alignment. The AC model of RFC 3281 has the AC holder present the AC to the AC verifier when the holder wants to substantiate an attribute or authorization. The intended usage for the extensions defined here has no direct interaction between an AC verifier (a NOC) and the AC issuers (all RIRs and NOCs). Given a signature on a claimed right-to-use object, the "AC verifier" can locate the AC holder's PKC, but there's no direct way to find the Subject's AC(s) 🌸.
- From section 5: "4. The AC issuer MUST be directly trusted as an AC issuer (by configuration or otherwise)." This isn't true for a right-to-use for an IP address block, because those are allocated through a hierarchy. Certification path validation of the AC would require chaining up through the delegation hierarchy. Having to configure each relying party (NOC) to "trust" every other NOC doesn't scale, and that kind of "trust" has caused failures the proposed security mechanisms are designed to prevent 💀. A single PKI with one trusted root is used, not thousands of individually trusted per-ISP AC issuers 👑. Properly validating an AC takes more work than the mechanism that puts the certificate extensions defined in this document into the PKCs. There would be twice as many certificates to validate, on top of the ACs themselves, and the management burden to support ACs could go up a lot 😩.
References
Normative References
- [IANA-AFI]
http://www.iana.org/assignments/address-family-numbers. - [IANA-SAFI]
http://www.iana.org/assignments/safi-namespace. - [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.
- [X.690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)".
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.
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.ComFull 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. It also doesn't 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. 💜
📦 where this page comes from
- ietf: rfc3779 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms