diff --git a/draft-ietf-opsawg-9092-update.xml b/draft-ietf-opsawg-9092-update.xml index f48ab88..ddfbced 100644 --- a/draft-ietf-opsawg-9092-update.xml +++ b/draft-ietf-opsawg-9092-update.xml @@ -8,9 +8,9 @@ - + obsoletes="9092" version="2" > @@ -49,7 +49,7 @@ 1600 Amphitheatre Parkway Mountain View - CA + CA 94043 United States of America @@ -125,33 +125,33 @@ target="auth"/>. - This document obsoletes . Changes from - include the following: + This document obsoletes . Changes from + include the following:
    -
  • - RIPE has implemented the geofeed: attribute. -
    • -
  • - Allow, but discourage, an inetnum: to have both a geofeed - remarks: attribute and a geofeed: attribute. -
    • -
  • - Geofeed file only UTF-8 CSV. -
    • -
  • - Stress that authenticating geofeed data is optional. -
    • -
  • - IP Address Delegation extensions must not use "inherit". -
    • -
  • - If geofeed data are present, ignore geographic location - hints in other data. -
    • -
+
  • + RIPE has implemented the geofeed: attribute. +
    • +
  • + Allow, but discourage, an inetnum: to have both a geofeed + remarks: attribute and a geofeed: attribute. +
    • +
  • + Geofeed file only UTF-8 CSV. +
    • +
  • + Stress that authenticating geofeed data is optional. +
    • +
  • + IP Address Delegation extensions must not use "inherit". +
    • +
  • + If geofeed data are present, ignore geographic location + hints in other data. +
    • +     - +
    Requirements Language @@ -177,9 +177,9 @@ - Per , geofeed files consist of CSVs - (Comma Separated Values) in UTF-8 text format; not HTML, - richtext, or other formats. + Per , geofeed files consist of CSVs + (Comma Separated Values) in UTF-8 text format; not HTML, + richtext, or other formats. @@ -261,13 +261,13 @@ geofeed: https://example.com/geofeed ]]> - 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 . @@ -279,9 +279,9 @@ - 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. @@ -291,9 +291,9 @@ than one, the geofeed: attribute SHOULD be used. - For inetnum:s covering the same address range, or an inetnum: - with both remarks: and geofeed: attributes, a signed geofeed - file SHOULD be preferred over an unsigned file. + For inetnum:s covering the same address range, or an inetnum: + with both remarks: and geofeed: attributes, a signed geofeed + file SHOULD be preferred over an unsigned file. If a geofeed file describes multiple disjoint ranges of IP @@ -303,9 +303,9 @@ procedure in . - An unsigned, and only an unsigned, geofeed file MAY be - referenced by multiple inetnum:s and MAY contain prefixes from - more than one registry. + An unsigned, and only an unsigned, geofeed file MAY be + referenced by multiple inetnum:s and MAY contain prefixes from + more than one registry. When geofeed references are provided by multiple inetnum: @@ -333,15 +333,15 @@ Fetching Geofeed Data - This document is to provides a guideline for how interested - parties should fetch and read geofeed files. + This document is to provides a guideline for how interested + parties should fetch and read geofeed files. - Historically, before geofeed files, this was done in varied - ways, at the discretion of the implementer, often without - consistent authentication, where data were mostly imported from - email without formal authorisation or validation. + Historically, before geofeed files, this was done in varied + ways, at the discretion of the implementer, often without + consistent authentication, where data were mostly imported from + email without formal authorisation or validation. @@ -353,23 +353,23 @@ - When an inetnum: with a geofeed file reference is identified, - the file MUST be downloaded using HTTPS. + When an inetnum: with a geofeed file reference is identified, + the file MUST be downloaded using HTTPS. - When reading data from the geofeed file, one MUST ignore data - outside the referring inetnum: object's address range. This is - to avoid importing data about ranges not under the control of - the operator. If geofeed files are fetched, other location - information from the inetnum: MUST be ignored. + When reading data from the geofeed file, one MUST ignore data + outside the referring inetnum: object's address range. This is + to avoid importing data about ranges not under the control of + the operator. If geofeed files are fetched, other location + information from the inetnum: MUST be ignored. - Given an address range of interest, the most specific inetnum: - object with a geofeed reference MUST be used to fetch the - geofeed file. For example, if the fetching party finds - the following inetnum: objects: + Given an address range of interest, the most specific inetnum: + object with a geofeed reference MUST be used to fetch the + geofeed file. For example, if the fetching party finds + the following inetnum: objects: - and the file geofeed_1 contains geolocation data about - 192.0.2.0/29, this MUST be discarded because 192.0.2.0/24 is - within the more specific inetnum: covering the address range and - that inetnum: has a geofeed reference. + and the file geofeed_1 contains geolocation data about + 192.0.2.0/29, this MUST be discarded because 192.0.2.0/24 is + within the more specific inetnum: covering the address range and + that inetnum: has a geofeed reference. - If an inetnum: object has both remarks: with geofeed data and - also has a geofeed: attribute, the geofeed: attribute SHOULD be - used and the remarks: ignored. + If an inetnum: object has both remarks: with geofeed data and + also has a geofeed: attribute, the geofeed: attribute SHOULD be + used and the remarks: ignored. - Hints in inetnum:s such as country:, geoloc:, etc. tend to be - administrative, and not deployment specific. Consider large, - possibly global, providers with headquarters very far from most - of their deployments. Therefore, if geofeed data are specified, - either as a geofeed: attribute or in a geofeed remarks: - attribute, other geographic hints such as country:, geoloc:, DNS - geoloc RRsets, etc., for that address range MUST be ignored. + Hints in inetnum:s such as country:, geoloc:, etc. tend to be + administrative, and not deployment specific. Consider large, + possibly global, providers with headquarters very far from most + of their deployments. Therefore, if geofeed data are specified, + either as a geofeed: attribute or in a geofeed remarks: + attribute, other geographic hints such as country:, geoloc:, DNS + geoloc RRsets, etc., for that address range MUST be ignored. - There is open-source code to traverse the RPSL data across all - of the RIRs, collect all geofeed references, and process them - . It implements the steps above - and of all the Operational Considerations described in , including caching. It produces a single geofeed - file, merging all the geofeed files found. This open-source - code can be run daily by a cronjob, and the output file can be - directly used. + There is open-source code to traverse the RPSL data across all + of the RIRs, collect all geofeed references, and process them + . It implements the steps above + and of all the Operational Considerations described in , including caching. It produces a single geofeed + file, merging all the geofeed files found. This open-source + code can be run daily by a cronjob, and the output file can be + directly used.
    @@ -492,6 +492,13 @@ object's address range is included in the CMS SignedData certificates field. + + The CA MUST sign only one Geofeed with each generated private + key and MUST generate a new key pair for each new version of the + Geofeed. An associated EE certificate used in this fashion is + termed a "one-time-use" EE certificate (see Section 3 of + ). + Identifying the private key associated with the certificate and getting the department that controls the private key (which @@ -506,16 +513,16 @@ 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. - + + 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 @@ -536,7 +543,7 @@ certification path validation is unsuccessful, then validation MUST fail.
      2. - +
    2. Validating the CMS SignedData as specified in using the public key from @@ -563,20 +570,20 @@ target="RFC5652" format="default"/>. - An IP Address Delegation extension using "inherit" would - complicate processing. The implementation would have to build - the certification path from the end-entity to the trust anchor, - then validate the path from the trust anchor to the end-entity, - and then the parameter would have to be remembered when the - validated public key was used to validate a signature on a CMS - object. Having to remember things from certification path - validation for use with CMS object processing is too hard. And, - the certificates do not get that much bigger by repeating the - information. + An IP Address Delegation extension using "inherit" would + complicate processing. The implementation would have to build + the certification path from the end-entity to the trust anchor, + then validate the path from the trust anchor to the end-entity, + and then the parameter would have to be remembered when the + validated public key was used to validate a signature on a CMS + object. Having to remember things from certification path + validation for use with CMS object processing is too hard. And, + the certificates do not get that much bigger by repeating the + information. - Therefore an extension using "inherit" MUST NOT be used. This - is consistent with other RPKI signed objects. + Therefore an extension using "inherit" MUST NOT be used. This + is consistent with other RPKI signed objects. Identifying the private key associated with the certificate and @@ -670,12 +677,12 @@ - Harvesting and publishing aggregated geofeed data outside of - the RPSL model should be avoided as it can have the effect - that more specifics from one aggregatee could undesirably - affect the less specifics of a different aggregatee. The - validation model in Section handles this - issue within the RPSL model. + Harvesting and publishing aggregated geofeed data outside of + the RPSL model should be avoided as it can have the effect + that more specifics from one aggregatee could undesirably + affect the less specifics of a different aggregatee. The + validation model in Section handles this + issue within the RPSL model. Currently, geolocation providers have bulk WHOIS data access at @@ -731,13 +738,13 @@ Implementation Status - Currently, the geofeed: attribute in inetnum objects has - been implemented in the RIPE and APNIC databases. + Currently, the geofeed: attribute in inetnum objects has + been implemented in the RIPE and APNIC databases. Registrants in databases which do not yet support the geofeed: - attribute are using the remarks:, or equivalent, attribute. + attribute are using the remarks:, or equivalent, attribute. @@ -753,6 +760,11 @@ treated as "remarks". + + can be used to authenticate a + signed geofeed file. + +
      @@ -764,9 +776,9 @@ apply here as well. - The consumer of geofeed data SHOULD fetch and process the data - themselves. Importing datasets produced and/or processed by a - third-party places ill-advised trust in the third-party. + The consumer of geofeed data SHOULD fetch and process the data + themselves. Importing datasets produced and/or processed by a + third-party places ill-advised trust in the third-party. As mentioned in , some @@ -798,7 +810,7 @@
      IANA Considerations - There are no new actions needed by the IANA. + There are no new actions needed by the IANA.
      @@ -820,6 +832,7 @@ + @@ -837,8 +850,6 @@ - - Representation Of IP Routing Policies In The RIPE Database @@ -901,59 +912,67 @@ commit 5f557a4 + + + Example on how to use rpki-client to authenticate a signed Geofeed + + + + + -
      - Example - - This appendix provides an example that includes a trust anchor, a CA + + +
      + + This appendix provides an example, including a trust anchor, a CA certificate subordinate to the trust anchor, an end-entity certificate subordinate to the CA for signing the geofeed, and a - detached signature. - - - + detached signature. + + The trust anchor is represented by a self-signed certificate. As usual in the RPKI, the trust anchor has authority over all IPv4 - address blocks, all IPv6 address blocks, and all Autonomous System - (AS) numbers. - - + address blocks, all IPv6 address blocks, and all AS numbers. - +
      + + The CA certificate is issued by the trust anchor. This certificate grants authority over one IPv4 address block (192.0.2.0/24) and two AS numbers (64496 and 64497). - - - The end-entity certificate is issued by the CA. This certificate - grants signature authority for one IPv4 address block (192.0.2.0/24). - Signature authority for AS numbers is not needed for geofeed data - signatures, so AS numbers MUST NOT be included in the certificate. - - + + + The end-entity certificate is issued by the CA. This + certificate grants signature authority for one IPv4 address block + (192.0.2.0/24). Signature authority for AS numbers is not needed + for geofeed data signatures, so no AS numbers are included in the + end-entity certificate. + +
      - - The end-entity certificate is displayed below in detail. For - brevity, the other two certificates are not. - - - -To allow reproduction of the signature results, the end-entity -private key is provided. For brevity, the other two private -keys are not. - - -Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF) yields the -following detached CMS signature. - -
      +]]> -
      - Acknowledgments - - Thanks to for CMS and detached - signature clue, for the - first and substantial external review, and who was too shy to agree to - coauthorship. Additionally, we express our gratitude to early - implementors, including ; - ; ; , who also found an - ASN.1 'inherit' issue; and . - Also, thanks to the following geolocation providers who are - consuming geofeeds with this described solution: (ipdata.co), (ipinfo.io), and - (bigdatacloud.com). For an amazing number of helpful reviews, - we thank , , , (INTDIR), - , , (SECDIR), , , , (GENART), , , and . - -
      + + The end-entity certificate is displayed below in detail. For + brevity, the other two certificates are not. - - +
      + + + To allow reproduction of the signature results, the end-entity + private key is provided. For brevity, the other two private + keys are not. + +
      + + + Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF), + yields the following detached CMS signature. + +
      + +
      + + +