Finding and Using Geofeed Data
draft-ietf-opsawg-finding-geofeeds-17
Yes
(Robert Wilton)
No Objection
(Alvaro Retana)
Recuse
Note: This ballot was opened for revision 07 and is now closed.
Erik Kline
No Objection
Comment
(2021-05-14 for -08)
Sent
[[ comments ]] [ general ] * Please see the INT-DIR comments (https://datatracker.ietf.org/doc/ review-ietf-opsawg-finding-geofeeds-08-intdir-lc-combes-2021-05-14/) if you have not already.
Francesca Palombini
(was Discuss)
No Objection
Comment
(2021-05-20 for -12)
Sent
Thanks for addressing my DISCUSS and answering my question. Thank you for the work on this document, and thank you to the shepherd for a very well-written and in-depth shepherd write up: it was very informative and very appreciated. Francesca
John Scudder
No Objection
Comment
(2021-05-19 for -10)
Sent
Thanks for this document, it looks useful. I have some comments and questions below. 0. I’d like to thank George Michaelson for a thorough and helpful, not to say exemplary, shepherd’s report. 1. Section 3: Ideally, RPSL would be augmented to define a new RPSL geofeed: attribute in the inetnum: class. Until such time, this document I, too, am curious as to why this ideal solution isn’t considered achievable. I’m also a little confused by the way you seem to be arguing with yourself in this section. First you tell me that change control for RPSL is vested in the operator community (by implication, not the IETF). A few paragraphs later you say: 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 which Is it up to them? Or is it up to you? I don’t get it. I mean, I’m fine with what you’ve specced, but when you fence it off with disclaimers that say RPSL modification isn’t up to you, it leaves me confused. Perhaps your point is that the IETF gets to specify the geofeed: attribute, but only the RIRs get to decide when they will start using it? This is generally true of everything the IETF does, of course, but OK. But if that’s what you mean, it really wasn’t clear to me from reading the text. By the way, I bet you should expand “RIR“ on first use. 2. Section 3: Until all producers of inetnum:s, i.e. the RIRs, state that they have migrated to supporting a geofeed: attribute, consumers looking at inetnum:s to find geofeed URLs MUST be able to consume both the remarks: and geofeed: forms. This not only implies that the RIRs support the geofeed: attribute, but that all registrants have migrated any inetnum:s from remarks: use to geofeed:s. The referent of “this” in the last sentence isn’t clear. Maybe you mean “migrated”? Rewriting as ‘“Migrated” not only implies…’ would clarify, if so. 3. Section 3: 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. This makes me think the geofeed: attribute will never, ever be adopted, because you’ve just created a flag day requirement. Why not permit both the remarks: and geofeed: versions to enable transition? Presumably you'd need some tie-break rule in case they're pointing different places, but that doesn't seem like a deal-breaker. 4. Section 5: If and only if the geofeed file is not signed per Section 4, then multiple inetnum: objects MAY refer to the same geofeed file, and the consumer MUST use only geofeed lines where the prefix is covered by the address range of the inetnum: object they have followed. Presumably this only works with unsigned geofeeds because you’re implicitly requiring that the geofeed file be signed only once. Is there any particular driver for this sign-only-once requirement? On a cursory review of §4, I don’t see anything that would make multiple signatures impracticable. I note that §3 says If a geofeed CSV file describes multiple disjoint ranges of IP address space, there are likely to be geofeed references from multiple inetnum: objects. While the text in §5 doesn’t actually give the lie to this quote (since I can read it as “if an unsigned geofeed CSV file…”) it does seem like the document is pulling in two different directions. At the very least, if there is a requirement that only a single signature be present in a geofeed file, can you say that explicitly in §4? 5. Section 5: An entity fetching geofeed data using these mechanisms MUST NOT do frequent real-time look-ups to prevent load on RPSL and geofeed servers. [RFC8805] Section 3.4 suggests use of the [RFC7234] HTTP Nit: I think you need a comma between “look-ups” and “to”. Or re-word as “To prevent undue load on RPSL and geofeed servers, an entity fetching geofeed data using these mechanisms MUST NOT do frequent real-time look-ups.” (I also added “undue” because of course every transaction induces SOME load.) 6. General Comment: While I notice some reviewers have expressed discomfort with the occasional lighthearted use of language (“fetching with tweezers”, etc), I found that it made the document more fun to read without hindering clarity in the slightest. In short, it made it a better spec. Thank you.
Murray Kucherawy
(was Discuss)
No Objection
Comment
(2021-05-21 for -14)
Sent
Thanks for resolving my DISCUSS position. Nice job on the shepherd writeup.
Roman Danyliw
(was Discuss)
No Objection
Comment
(2021-05-20 for -12)
Sent
(Updated ballot) Thank you to Kyle Rose for the SECDIR review. Thank you for addressing my DISCUSS and various COMMENTs. ====== ** Section 4. Per “the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field”, can a more specific statement be made highlight which certificate field in providing the IP information. Propose: OLD ... the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field NEW ... the RPKI certificate covering the inetnum: object's address range is included in the IP Address Delegation certificate extension [RFC3779] field. See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/ for follow-up discussion on this. ** Section 4. Per the format of the signature appended to the geofeed file: # RPKI Signature: 192.0.2.0/24 # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu ... # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk= # End Signature: 192.0.2.0/24 -- The does the label “192.0.2.0/24” relate to the rest of the geofeed file and the inetnum: value? ** Appendix A. The end-user certificate has a sbgp-ipAddBlock field which is “IPv4: inherit IPv6: inherit”. However, the parent CA is encoding an IPv4 only range so it seems misplaced that there is a IPv6 reference there. See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/ for follow-up discussion on this.
Éric Vyncke
No Objection
Comment
(2021-05-19 for -10)
Sent
Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. Thank you to George Michaelson for his shepherd's write-up (including the WG consensus). Nice to have acknowledged him. Thank you Jean-Michel Combes for the INT-DIR Last Call review at: https://datatracker.ietf.org/doc/review-ietf-opsawg-finding-geofeeds-08-intdir-lc-combes-2021-05-14/ The telechat INT-DIR review by Wassim Haddad also seconds a good opinion of this document. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 3 -- Having a standards track document relying on a 'remarks:' attribute looks really weird. Should it rather be informational ? NB: I understand that changing the RPSL syntax is mostly mission impossible. Should the case when both "remarks: Geofeed" and "geofeed" are present but differ be mentioned ? -- Section 4 -- What happens if the public key of the certificate is changed? Should the cert serial number be part of the signature? Or at least mention the obvious that the signature must be re-executed when the cert if changed (e.g., in section 5). -- Section 5 -- Is there any reason why the doc shepherd is not acknowledged ? == NITS == I find the use of the colon in "inetnum:" quite annoying and confusing. The use of quotes in the last § of section 3 is easier to read and parse -- Section 3 -- Do the examples really need to be in IPv4 ? ;-) -- Section 4 -- The use of "department" in "getting the department with the Hardware Security Module" is difficult to understand by non-English native readers (at least for me as I had to re-read it twice and guess the meaning).
Warren Kumari
Recuse
Comment
(2021-05-11 for -07)
Not sent
... the lengths I will go to to avoid reviewing and balloting...
Robert Wilton Former IESG member
Yes
Yes
(for -07)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -10)
Not sent
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2021-05-25)
Sent for earlier
thanks for addressing my discuss and comment points!
Lars Eggert Former IESG member
No Objection
No Objection
(2021-05-12 for -08)
Sent
Section 4, paragraph 4, comment: > <CRLF> sequence. Other nonprintable characters, such as backspace, > are not expected. For robustness, any nonprintable characters MUST "are not expected" - but what if they are *encountered*? Section 5, paragraph 3, comment: > The geofeed files SHOULD be published over and fetched using https > [RFC8446]. Section 2 has a "MUST" for https, so this could become a MUST as well? ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 5, nit: - An optional, utterly awesome but slightly complex, means for - - + An optional, utterly awesome but slightly complex means for Section 2, paragraph 2, nit: - geographic locale(s). - - - + geographic locales. Section 2, paragraph 3, nit: - Section 3 this document specifies how to find the relevant [RFC8805] - geofeed file given an IP address. + Section 3, this document specifies how to find the relevant [RFC8805] + + + geofeed file, given an IP address. + + Section 2, paragraph 5, nit: - Geofeed data do have privacy considerations, see Section 6 + Geofeed data do have privacy considerations, see Section 6. + + Section 2, paragraph 6, nit: - This document also suggests optional signature, which authenticates - - + This document also suggests optional signatures, which authenticate + + Section 3, paragraph 3, nit: - defines the syntax of a Geofeed remarks: attribute which contains an - ^ ^ ^^^ + defines the syntax of a geofeed remarks: attribute that contains an + ^ ^ ^^ Section 3, paragraph 7, nit: - The URL's use of the web PKI can not provide authentication of IP - - + The URL's use of the web PKI cannot provide authentication of IP Section 3, paragraph 8, nit: - Until all producers of inetnum:s, i.e. the RIRs, state that they have - migrated to supporting a geofeed: attribute, consumers looking at - -- + Until all producers of inetnum:s, i.e., the RIRs, state that they have + + + migrated to supporting geofeed: attributes, consumers looking at + + Section 3, paragraph 8, nit: - migrated any inetnum:s from remarks: use to geofeed:s. - ---- + migrated any inetnum:s from remarks: to geofeed:s. Section 3, paragraph 9, nit: - 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 are more than one, all MUST be ignored. + ^^^ ^^^^^^ Section 3, paragraph 11, nit: - As inetnum: objects form a hierarchy, Geofeed references SHOULD be at - ^ + As inetnum: objects form a hierarchy, geofeed references SHOULD be at + ^ Section 3, paragraph 12, nit: - which have identical address ranges, then the geofeed reference on - ^ ^^^ + that have identical address ranges, then the geofeed reference on + ^ ^^ Section 3, paragraph 13, nit: - the inetnum: which refers to them. I.e. an INETNUM object for a - ^^ ^ ^^^^^^^ + the inetnum: which refers to them. For example, an inetnum object for a + ^^^^ ^^^^^^^ ^^^^^^^ Section 3, paragraph 14, nit: - as the other registries; therefore, when fetching from ARIN via FTP + as for the other registries; therefore, when fetching from ARIN via FTP + ++++ Section 4, paragraph 2, nit: - The question arises of whether a particular [RFC8805] geofeed data - --- - set is valid, i.e. authorized by the 'owner' of the IP address space - and is authoritative in some sense. The inetnum: which points to the - ^ ^^^ - [RFC8805] geofeed file provides some assurance. Unfortunately the + The question arises whether a particular [RFC8805] 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 + ^ ^^ + [RFC8805] geofeed file provides some assurance. Unfortunately, the + + Section 4, paragraph 6, nit: - identical to or a subset of A. 'Address range' is used here because + identical to or a subset of A. 'Address range' is used here, because + + Section 4, paragraph 9, nit: - sign the CMS blob is left as an exercise for the implementor. On the + sign the CMS blob, is left as an exercise for the implementor. On the + + Section 5, paragraph 2, nit: - inetnum: objects. They also provide means of [sub-]assigning IP - ^ ^ + inetnum: objects. They also provide means of (sub-)assigning IP + ^ ^ Section 5, paragraph 3, nit: - The geofeed files SHOULD be published over and fetched using https - - ^^ + The geofeed files SHOULD be published via and fetched using https + ^^ Section 5, paragraph 7, nit: - users without such authorization the same result can be achieved with + users without such authorization, the same result can be achieved with + + Section 5, paragraph 8, nit: - frequent real-time look-ups to prevent load on RPSL and geofeed + frequent real-time look-ups, to prevent load on RPSL and geofeed + + Section 6, paragraph 2, nit: - described in this document the operator should be aware of this + described in this document, the operator should be aware of this + + Section 3, paragraph 3, nit: > , where the token "Geofeed" is case sensitive, followed by a URL which will > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 3, paragraph 9, nit: > one geofeed reference, whether a remarks: or a proper geofeed: attribute, w > ^^^^^^^^^ The plural noun "remarks" cannot be used with the article "a". Did you mean "a remark" or "remarks"? Section 3, paragraph 13, nit: > as been sub- divided into one or more longer prefixes. Currently, the regist > ^^^^^^^^^^^ Use only "longer" (without 'more') when you use the comparative. Section 4, paragraph 2, nit: > An approach where RPSL was signed a la [RFC7909] would be good, except it w > ^^^^ 'a la' is an imported foreign expression, which originally has a diacritic. Consider using "à la" "S", paragraph 1, nit: > geofeed file, one MUST ignore data outside of the referring inetnum: object's > ^^^^^^^^^^ This phrase is redundant. Consider using "outside". Section 7, paragraph 2, nit: > urces to cross-validate the data. All of the Security Considerations of [RFC > ^^^^^^^^^^ Consider using "all the". Section 9, paragraph 2, nit: > ded running code, and Kevin Pack. Also to geolocation providers that are con > ^^^^ Did you forget a comma after a conjunctive/linking adverb?
Martin Duke Former IESG member
No Objection
No Objection
(2021-05-14 for -08)
Sent
"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." If the ideal solution is to produce a standards track document that creates a new RPSL attribute, I don't understand why the Working Group didn't simply do that, instead of messing with the remarks and then coming up with a transition plan for moving from this design to the future one.