diff --git a/draft-ietf-opsawg-9092-update.xml b/draft-ietf-opsawg-9092-update.xml index f72cc00..12121d3 100644 --- a/draft-ietf-opsawg-9092-update.xml +++ b/draft-ietf-opsawg-9092-update.xml @@ -8,7 +8,7 @@ - @@ -17,7 +17,7 @@ Finding and Using Geofeed Data - IIJ & Arrcus + IIJ Research & Arrcus
5147 Crystal Springs @@ -224,7 +224,8 @@ modified and extensively enhanced in the Regional Internet Registry (RIR) community, mostly by RIPE . At the time of publishing this document, - change control effectively lies in the operator community. + change control of RPSL effectively lies in the operator + community. @@ -278,9 +279,8 @@ 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. + consumers looking at inetnum: objects to find geofeed URLs MUST + be able to consume both the remarks: and geofeed: forms. @@ -292,15 +292,17 @@ Any particular inetnum: object SHOULD have, at most, one geofeed reference, whether a remarks: or a proper geofeed: attribute - when it is implemented. A geofeed: attribute is preferred, of - course, if the RIR supports it. If there is more than one type - of attribute in the intetnum: object, the geofeed: attribute - SHOULD be used. + when it is implemented. As the remarks: form can not be + formally checked by the RIR, this can not be formally enforced. + A geofeed: attribute is preferred, of course, if the RIR + supports it. If there is more than one type of attribute in the + intetnum: object, the geofeed: attribute MUST 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, a signed geofeed + file MUST be preferred over an unsigned file. If none are + signed, or more than one is signed, the (signed) inetnum: with + the most recent last-modified: attribute MUST be preferred. If a geofeed file describes multiple disjoint ranges of IP @@ -315,17 +317,8 @@ more than one registry. - When geofeed references are provided by multiple inetnum: - objects that have identical address ranges, then the geofeed - reference on the inetnum: with the most recent last-modified: - 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. + When fetching, the most specific inetnum: object with a geofeed + reference MUST be used. It is significant that geofeed data may have finer granularity @@ -360,11 +353,17 @@ - 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 an unsigned 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. Note that signed files MUST only + contain prefixes within the referring inetnum:'s range as + mandated in . + + + + If geofeed files are fetched, other location information from + the inetnum: MUST be ignored. @@ -379,10 +378,10 @@ inetnum: 192.0.2.0/24 # example remarks: Geofeed https://example.com/geofeed_2 ]]> - Since geofeed_1 contains geolocation data about 192.0.2.0/29, - it is discarded because 192.0.2.0/24 is within the more - specific inetnum: covering the address range and that inetnum: - has a geofeed reference. + An application looking for geofeed data for 192.0.2.0/29, MUST + ignore data in geofeed_1 because 192.0.2.0/29 is within the + more specific 192.0.2.0/24 inetnum: covering that address range + and that inetnum: does have a geofeed reference. @@ -484,25 +483,34 @@ The address range of the signing certificate MUST cover all - prefixes in the signed geofeed file. The signing certificate - MUST NOT include the Autonomous System Identifier Delegation - certificate extension . + prefixes in the signed geofeed file. If not, the authenticator + is invalid. + + + The signing certificate MUST NOT include the Autonomous System + Identifier Delegation certificate extension . If it is present, the authenticator is + invalid. As with many other RPKI signed objects, the IP Address Delegation certificate extension MUST NOT use the "inherit" capability defined in Section 2.2.3.5 of . 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 - would be quite complex and error prone. And, the certificates - do not get that much bigger by repeating the information. + target="RFC3779"/>. If "inherit" is used, the authenticator is + invalid. + + + 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 would be quite + complex and error prone. And, the certificates do not get that + much bigger by repeating the information. @@ -773,7 +781,7 @@ 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. + third-party places significant trust in the third-party. As mentioned in , some