From ae2a50bcd8f2c716268ba3dd21ea3994709e3c26 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Mon, 5 Dec 2022 13:27:41 -0800 Subject: [PATCH] russ's one paragraph hack --- draft-ymbk-9092update.xml | 345 +++++++++++++++++++++----------------- 1 file changed, 187 insertions(+), 158 deletions(-) diff --git a/draft-ymbk-9092update.xml b/draft-ymbk-9092update.xml index 10c5452..ed4e1c7 100644 --- a/draft-ymbk-9092update.xml +++ b/draft-ymbk-9092update.xml @@ -13,7 +13,7 @@ - Finding and Using Geofeed Data + A Minor Update to Finding and Using Geofeed Data @@ -140,29 +140,30 @@
Geofeed Files - Geofeed files are described in . They - provide a facility for an IP address resource "owner" to - associate those IP addresses to geographic locales. + Geofeed files are described in . They provide a facility for an IP address + resource "owner" to associate those IP addresses to geographic + locales. - Content providers and other parties who wish to locate an IP address - to a geographic locale need to find the relevant geofeed data. In - , this document specifies how - to find the relevant geofeed - file given an IP address. + Content providers and other parties who wish to locate an IP + address to a geographic locale need to find the relevant geofeed + data. In , this + document specifies how to find the relevant geofeed file given an IP address. Geofeed data for large providers with significant horizontal scale and high granularity can be quite large. The size of a file can be even larger if an unsigned geofeed file combines - data for many prefixes, if dual IPv4/IPv6 spaces are represented, - etc. + data for many prefixes, if dual IPv4/IPv6 spaces are + represented, etc. Geofeed data do have privacy considerations (see ); this process makes bulk access - to those data easier. + target="privacy" format="default"/>); this process makes bulk + access to those data easier. This document also suggests an optional signature to strongly @@ -172,34 +173,38 @@
inetnum: Class - - The original RPSL specifications starting with , , and a trail of - subsequent documents were written by the RIPE community. The IETF - standardized RPSL in and . Since then, it has been modified and - extensively enhanced in the Regional Internet Registry (RIR) - community, mostly by RIPE . Currently, - change control effectively lies in the operator community. + The original RPSL specifications starting with , , and a trail of subsequent documents were + written by the RIPE community. The IETF standardized RPSL in + and . Since then, it has been + modified and extensively enhanced in the Regional Internet + Registry (RIR) community, mostly by RIPE . Currently, change control effectively lies + in the operator community. - The RPSL, and and used by the - Regional Internet Registries (RIRs), specify the inetnum: - database class. Each of these objects describes an IP address - range and its attributes. The inetnum: objects form a hierarchy - ordered on the address space. + The RPSL, and and + used by the Regional + Internet Registries (RIRs), specify the inetnum: database class. + Each of these objects describes an IP address range and its + attributes. The inetnum: objects form a hierarchy ordered on + the address space. Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document - defines the syntax of a Geofeed remarks: attribute, which contains an - HTTPS URL of a geofeed file. The format of the inetnum: geofeed - remarks: attribute MUST be as in this example, - "remarks: Geofeed ", where the token "Geofeed " MUST be - case sensitive, followed by a URL that will vary, but it - MUST refer only to a single geofeed file. + defines the syntax of a Geofeed remarks: attribute, which + contains an HTTPS URL of a geofeed file. The format of the + inetnum: geofeed remarks: attribute MUST be as in + this example, "remarks: Geofeed ", where the token "Geofeed " + MUST be case sensitive, followed by a URL that + will vary, but it MUST refer only to a single + geofeed file. - While we leave global agreement of RPSL modification to the relevant - parties, we specify that a proper geofeed: attribute in the inetnum: - class MUST be "geofeed:" and MUST be - followed by a single URL that will vary, but it MUST - refer only to a single geofeed file. + While we leave global agreement of RPSL modification to the + relevant parties, we specify that a proper geofeed: attribute in + the inetnum: class MUST be "geofeed:" and + MUST be followed by a single URL that will vary, + but it MUST refer only to a single geofeed file. - Registries MAY, for the interim, provide a mix of the remarks: - attribute form and the geofeed: attribute form. + Registries MAY, for the interim, provide a mix of + the remarks: attribute form and the geofeed: attribute form. - The URL uses HTTPS, so the WebPKI provides authentication, integrity, - and confidentiality for the fetched geofeed file. However, the WebPKI - can not provide authentication of IP address space assignment. In - contrast, the RPKI (see ) can - be used to authenticate IP space assignment; see optional - authentication in . + The URL uses HTTPS, so the WebPKI provides authentication, + integrity, and confidentiality for the fetched geofeed file. + However, the WebPKI can not provide authentication of IP address + space assignment. In contrast, the RPKI (see ) can be used to authenticate + IP space assignment; see optional authentication in . - Until all producers of inetnum: objects, i.e., the RIRs, state that they - have migrated to supporting a geofeed: attribute, consumers - looking at inetnum: objects to find geofeed URLs MUST be able to - consume both the remarks: and geofeed: forms. + Until all producers of inetnum: objects, i.e., the RIRs, state + that they have migrated to supporting a geofeed: attribute, + consumers looking at inetnum: objects to find geofeed URLs + MUST be able to consume both the remarks: and + geofeed: forms. - The migration not only implies that the RIRs support the geofeed: - attribute, but that all registrants have migrated any inetnum: objects - from remarks: to geofeed: attributes. - + The migration not only implies that the RIRs support the + geofeed: attribute, but that all registrants have migrated any + inetnum: objects from remarks: to geofeed: attributes. + - Any particular inetnum: object MUST have, at most, one geofeed - reference, whether a remarks: or a proper geofeed: attribute - when it is implemented. If there is more than one, all are - ignored. + Any particular inetnum: object MUST have, at + most, one geofeed reference, whether a remarks: or a proper + geofeed: attribute when it is implemented. If there is more + than one, all are ignored. If a geofeed CSV file describes multiple disjoint ranges of IP @@ -263,11 +270,11 @@ attribute SHOULD be preferred. - As inetnum: objects form a hierarchy, geofeed references SHOULD - be at the lowest applicable inetnum: object covering the - relevant address ranges in the referenced geofeed file. When - fetching, the most specific inetnum: object with a geofeed - reference MUST be used. + As inetnum: objects form a hierarchy, geofeed references + SHOULD be at the lowest applicable inetnum: + object covering the relevant address ranges in the referenced + geofeed file. When fetching, the most specific inetnum: object + with a geofeed reference MUST be used. It is significant that geofeed data may have finer granularity @@ -276,12 +283,13 @@ which P has been subdivided into one or more longer prefixes. - Currently, the registry data published by ARIN are not the same RPSL as - that of the other registries (see for a survey of the WHOIS Tower of Babel); - therefore, when fetching from ARIN via FTP , WHOIS , - the Registration Data Access Protocol (RDAP) , WHOIS , the Registration Data + Access Protocol (RDAP) , etc., the "NetRange" attribute/key MUST be treated as "inetnum", and the "Comment" attribute MUST be treated as "remarks". @@ -293,128 +301,143 @@ The question arises whether a particular geofeed data set is valid, i.e., is - authorized by the "owner" of the IP address space and is authoritative - in some sense. The inetnum: that points to the geofeed file provides some assurance. - Unfortunately, the RPSL in many repositories is weakly authenticated - at best. An approach where RPSL was signed per would be good, except it would have to be deployed - by all RPSL registries, and there is a fair number of them. + authorized by the "owner" of the IP address space and is + authoritative in some sense. The inetnum: that points to the + geofeed file provides + some assurance. Unfortunately, the RPSL in many repositories is + weakly authenticated at best. An approach where RPSL was signed + per would be good, + except it would have to be deployed by all RPSL registries, and + there is a fair number of them. - A single optional authenticator MAY be appended to a - geofeed file. It is a - digest of the main body of the file signed by the private key of the - relevant RPKI certificate for a covering address range. One needs a - format that bundles the relevant RPKI certificate with the signature - of the geofeed text. + A single optional authenticator MAY be appended + to a geofeed file. It + is a digest of the main body of the file signed by the private + key of the relevant RPKI certificate for a covering address + range. One needs a format that bundles the relevant RPKI + certificate with the signature of the geofeed text. - The canonicalization procedure converts the data from their internal - character representation to the UTF-8 character encoding, and the <CRLF> sequence - MUST be used to denote the end of a line of text. A - blank line is represented solely by the <CRLF> sequence. For - robustness, any non-printable characters MUST NOT be - changed by canonicalization. Trailing blank lines MUST - NOT appear at the end of the file. That is, the file must not - end with multiple consecutive <CRLF> sequences. Any end-of-file - marker used by an operating system is not considered to be part of the - file content. When present, such end-of-file markers MUST - NOT be processed by the digital signature algorithm. + The canonicalization procedure converts the data from their + internal character representation to the UTF-8 character encoding, and the + <CRLF> sequence MUST be used to denote the + end of a line of text. A blank line is represented solely by + the <CRLF> sequence. For robustness, any non-printable + characters MUST NOT be changed by + canonicalization. Trailing blank lines MUST NOT + appear at the end of the file. That is, the file must not end + with multiple consecutive <CRLF> sequences. Any + end-of-file marker used by an operating system is not considered + to be part of the file content. When present, such end-of-file + markers MUST NOT be processed by the digital + signature algorithm. Should the authenticator be syntactically incorrect per the above, the authenticator is invalid. - Borrowing detached signatures from , after file canonicalization, the Cryptographic - Message Syntax (CMS) would - be used to create a detached DER-encoded signature that is then padded - BASE64 encoded (as per ) and line wrapped to 72 or fewer - characters. The same digest algorithm MUST be used for - calculating the message digest on content being signed, which is the - geofeed file, and for calculating the message digest on the SignerInfo - SignedAttributes . The - message digest algorithm identifier MUST appear in both - the SignedData DigestAlgorithmIdentifiers and the SignerInfo - DigestAlgorithmIdentifier . + format="default"/>, after file canonicalization, the + Cryptographic Message Syntax (CMS) would be used to create a detached + DER-encoded signature that is then padded BASE64 encoded (as per + ) and line wrapped to 72 or fewer characters. + The same digest algorithm MUST be used for + calculating the message digest on content being signed, which is + the geofeed file, and for calculating the message digest on the + SignerInfo SignedAttributes . The message digest algorithm identifier + MUST appear in both the SignedData + DigestAlgorithmIdentifiers and the SignerInfo + DigestAlgorithmIdentifier . - The address range of the signing certificate MUST cover all - prefixes in the geofeed file it signs. + The address range of the signing certificate MUST + cover all prefixes in the geofeed file it signs. An address range A "covers" address range B if the range of B is - identical to or a subset of A. "Address range" is used here because - inetnum: objects and RPKI certificates need not align on Classless - Inter-Domain Routing (CIDR) prefix - boundaries, while those of the CSV lines in a geofeed file do. + identical to or a subset of A. "Address range" is used here + because inetnum: objects and RPKI certificates need not align on + Classless Inter-Domain Routing (CIDR) + prefix boundaries, while those of the CSV lines in a geofeed + file do. - As the signer specifies the covered RPKI resources relevant to the - signature, the RPKI certificate covering the inetnum: object's address - range is included in the CMS - SignedData certificates field. + As the signer specifies the covered RPKI resources relevant to + the signature, the RPKI certificate covering the inetnum: + object's address range is included in the CMS SignedData certificates field. Identifying the private key associated with the certificate and - getting the department that controls the private key (which might be - trapped in a Hardware Security Module (HSM)) to sign the CMS blob is - left as an exercise for the implementor. On the other hand, verifying - the signature requires no complexity; the certificate, which can be - validated in the public RPKI, has the needed public key. + getting the department that controls the private key (which + might be trapped in a Hardware Security Module (HSM)) to sign + the CMS blob is left as an exercise for the implementor. On the + other hand, verifying the signature requires no complexity; the + certificate, which can be validated in the public RPKI, has the + needed public key. The trust anchors for the RIRs are expected to already be available to the party performing signature validation. Validation of the CMS signature on the geofeed file involves:
  1. - Obtaining the signer's certificate from the CMS SignedData - CertificateSet . The certificate - SubjectKeyIdentifier extension - MUST match the SubjectKeyIdentifier in the CMS SignerInfo - SignerIdentifier . If the key - identifiers do not match, then validation MUST fail. - - Validation of the signer's certificate MUST ensure - that it is part of the current manifest and that the resources are covered by - the RPKI certificate. - - -
    2. - -
  2. - Constructing the certification path for the signer's certificate. - All of the needed certificates are expected to be readily - available in the RPKI repository. The certification path MUST - be valid according to the validation algorithm in and the additional checks specified in - associated with the IP Address - Delegation certificate extension and the Autonomous System - Identifier Delegation certificate extension. If certification - path validation is unsuccessful, then validation MUST fail. + + Obtaining the signer's certificate from the CMS SignedData + CertificateSet . The + certificate SubjectKeyIdentifier extension MUST match + the SubjectKeyIdentifier in the CMS SignerInfo + SignerIdentifier . + If the key identifiers do not match, then validation + MUST fail. + + Validation of the signer's certificate MUST + ensure that it is part of the current manifest and that the resources are covered + by the RPKI certificate. +
    3. +
  3. - Validating the CMS SignedData as specified in using the public key from the validated - signer's certificate. If the signature validation is - unsuccessful, then validation MUST fail. + Constructing the certification path for the signer's + certificate. All of the needed certificates are expected to + be readily available in the RPKI repository. The + certification path MUST be valid according to + the validation algorithm in and the additional checks specified in + associated with the + IP Address Delegation certificate extension and the Autonomous + System Identifier Delegation certificate extension. If + certification path validation is unsuccessful, then validation + MUST fail. +
    4. + +
  4. + Validating the CMS SignedData as specified in using the public key from + the validated signer's certificate. If the signature + validation is unsuccessful, then validation + MUST fail.
  5. Verifying that the IP Address Delegation certificate extension - covers all of the address ranges of - the geofeed file. If all of the address ranges are not - covered, then validation MUST fail. + covers all of the + address ranges of the geofeed file. If all of the address + ranges are not covered, then validation MUST + fail.
    6. -
- All of these steps MUST be successful to consider the geofeed - file signature as valid. + All of these steps MUST be successful to consider + the geofeed file signature as valid. As the signer specifies the covered RPKI resources relevant to the @@ -422,12 +445,18 @@ range is included in the CMS SignedData certificates field . + + As an IP Address Delegation extension using "inherit" would + complicate processing, it MUST NOT be used. This + is consistent with other RPKI signed objects. + Identifying the private key associated with the certificate and - getting the department with the Hardware Security Module (HSM) to sign - the CMS blob is left as an exercise for the implementor. On the other - hand, verifying the signature requires no complexity; the certificate, - which can be validated in the public RPKI, has the needed public key. + getting the department with the Hardware Security Module (HSM) + to sign the CMS blob is left as an exercise for the implementor. + On the other hand, verifying the signature requires no + complexity; the certificate, which can be validated in the + public RPKI, has the needed public key. The appendix MUST be hidden as a series of "#" comments at the