[OPSAWG]Re: NetConfEval: Can LLMs Facilitate Network Configuration?
> https://scholar.google.com/scholar_url?url=https://dejankosticgithub.github.io/documents/publications/netconfeval-conext24.pdf=en=X=7785844682567625222=DLI-Zr27FsuNy9YPtfamqA8=AFWwaebA2r_Fw4okI0irTPrMsu7W=scholaralrt=LiEm55wJ:3177637049449935640:AFWwaeY5VE3Htr-mPxtni0xheb_1==2=rel worth a read, maybe without all the tracking https://dejankosticgithub.github.io/documents/publications/netconfeval-conext24.pdf randy ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
Re: [OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-9092-update-11: (with COMMENT)
paul you may, or may not, like -11. we tried to clarify some things a bit better, randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-9092-update-10: (with COMMENT)
>>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. >> >> Is there a reason that the second SHOULD, to prefer the geofeed: >> attribute isn’t a MUST? Otherwise, there isn’t deterministic behavior >> on which attribute will be used and geofeed: won’t necessarily be >> preferred. > > i think we have been over this one before, but i can not remember the > rationale. unless i hear otherwise from co-authors or general public, > i am happy to change the second to MUST. > > note that below i suggest also making the first SHOULD a MUST to make > life a bit simpler. i do not remember why we wussed out on this. sigh. a shy co-author reminded me privately that, to make it illegal to have both a remarks: geofeed reference and a geofeed: attribute would mandate that RIRs look *inside* all remarks: attributes. as a compiler writer in a long ago previous life, i really do not like looking inside comments. >> ** Section 3 >>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. >> >> Is the net result of this guidance that when encountering a both types >> of attributes, and despite preferring the geofeed, an implementation >> still needs to download both and see which one is signed? > > this runs into trouble with the previous, especially if it becomes > > If there is more than one type of attribute in the intetnum: object, > the geofeed: attribute MUST be used. > >> Effectively: >> >> If there is more than one type of attribute in the intetnum: object, >> the geofeed: attribute SHOULD be used unless the remarks: is signed? > > or vice versa, of course if we leave the two SHOULDs, though sloppy, it provides pretty direct instruction to the fetching application without getting us into operational knots. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
>>> The consumer of geofeed data SHOULD fetch and process the data >>> themselves. Importing datasets produced and/or processed by a third- >>> party places significant trust in the third-party. >> >> this is in sec cons already. you want it moved up or duplicated? i >> kinda like it where it is, but am flexible. > > I was not suggesting a new placement, just the edit to the last line. sorry. sure. > I propose adding that to the bottom of the paragraph that starts: > >If and only if the geofeed file is not signed per Section 5, ... > > By doing that, it does not conflict with the requirement in Section 5 > that the address range of the signing certificate cover all prefixes > in the signed geofeed file. 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 Section 5. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
> Suggested edits: > >The address range of the signing certificate MUST cover all 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 [RFC3779]. 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 [RFC3779]. If "inherit" is used, the >authenticator is invalid. sure >The consumer of geofeed data SHOULD fetch and process the data >themselves. Importing datasets produced and/or processed by a third- >party places significant trust in the third-party. this is in sec cons already. you want it moved up or duplicated? i kinda like it where it is, but am flexible. > I think is is probably better to drop the following from Section 6: > >When using data from a geofeed file, one MUST ignore data outside the >referring inetnum: object's inetnum: attribute address range. this is meant for an unsigned file. e.g. multiple diverse inetnum:s refer to the single geofeed file https://rg.net/geofeed. it allows an operator not signing to maintain one file. all geofeeds are not signed for a number of reasons o rpki data may not exist for some, cf. decades of difficulty getting rpki allowed by all RIRs. plus, you do not really want to tie the two operational processes together. o geofeed data are not critical. they just hints to geoloc obsessed content providers randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-9092-update-10: (with COMMENT)
thanks roman, > ** Section 3. Editorial. Consider this clarification. > OLD >At the time of publishing this document, change control effectively >lies in the operator community. > > NEW > At the time of publishing this document, change control of RPSL effectively > lies in the operator community. yup. paul w tripped over it. > ** Section 3. > >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. > > Is there a reason that the second SHOULD, to prefer the geofeed: > attribute isn’t a MUST? Otherwise, there isn’t deterministic behavior > on which attribute will be used and geofeed: won’t necessarily be > preferred. i think we have been over this one before, but i can not remember the rationale. unless i hear otherwise from co-authors or general public, i am happy to change the second to MUST. note that below i suggest also making the first SHOULD a MUST to make life a bit simpler. i do not remember why we wussed out on this. > ** Section 3 >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. > > Is the net result of this guidance that when encountering a both types > of attributes, and despite preferring the geofeed, an implementation > still needs to download both and see which one is signed? this runs into trouble with the previous, especially if it becomes If there is more than one type of attribute in the intetnum: object, the geofeed: attribute MUST be used. > Effectively: > > If there is more than one type of attribute in the intetnum: object, > the geofeed: attribute SHOULD be used unless the remarks: is signed? or vice versa, of course personally, i would cut the gordian knot and simply not allow both remarks: and geofeed: in an inetnum: object. but i note that the bit from section 3 you quote also talks about multiple inetnums: over the same address range. > ** Section 4. > >To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP >[RFC0959] services SHOULD be used for large-scale access to gather >inetnum:s with geofeed references. This uses efficient bulk access >instead of fetching via brute-force search through the IP space. > > This guidance was in RFC9092 (July 2021). Has anything changed in the > ecosystem that would allow the use of at least SFTP? not that i am aware, but i could be wrong. this is a facility provided by the RIRs. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
thanks for review, paul > #1 document track > > The document is Standards Track, and so are the docs is > Obsoletes/Updates ([RFC2725] and [RFC4012]), but the document also > claims "change control effectively lies in the operator community". > Normally, that would mean the IETF publishes this as Informational. > But of course that would raise the issue that an Informational would > Obsolete a Standards Track document. Some discussion on this would be > good. please differentiate between change control of the document, and of RPSL. the ietf abandoned RPSL decades ago. > #2 Transport Security > > There are quite a few sentences scattered through the document about > transport security that are not aligned, see: > > The URL uses HTTPS, so the WebPKI provides authentication > > So is HTTPS mandatory? I guess not since (see below) FTP is allowed as > URL too. please differentiate between - fetching a geofeed file pointed to by an inetnum: https url, and - fetching the rirs's published archive of all inetnums: and other rpsl objects >the RIR's FTP [RFC0959] services SHOULD be used that is bulk fetching the rpsl, not the geofeed > More seriously, can we avoid SHOULDing the FTP protocol? > Are these resources not made available over HTTP? one at a time with tweezers. don't do that. > Note the paragraph above it says: "Historically, [...] often without > consistent authentication". I wouldn't call that "Historically" if you > are are promoting FTP and allow "unsigned" files. again, please differentiate between the bulk fetch of the rpsl via ftp and the fetch of individual geofeed files via https. > The geofeed files MUST be published via and fetched using HTTPS > [RFC9110]. > > Uhm. So what about FTP now? again, please differentiate between the bulk fetch of the rpsl via ftp and the fetch of individual geofeed files via https. > The Security Considerations could bundle all the talk about HTTPS and > FTP and put in one clear clause here, mentioning that due to lack of > universal signing, it is sadly super important to have transport > security protection (eg HTTPS, not FTP) again, the differentiateion between the rpsl data and the geofeed files is critical. > #3 Signature and white space requirements are a bit troubling > #4 Misc. Security comments more on these later, when russ has had a chance to comment > -- > COMMENT: > -- > > 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. > > This reads a bit odd, a 192.0.2.0/29 comes out of nowhere. I guess you > meant to say "a client looking for geofeed data for 192.0.2.0/29" ? how about 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. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] John Scudder's Yes on draft-ietf-opsawg-9092-update-10: (with COMMENT)
> The nit: > > 192.0.2.0/12 (in Section 3) isn’t what I consider a well-formed prefix, since > the third octet has a set bit but isn’t under the mask. I would’ve said > 192.0.0.0/12. (Or better still 192.0/12, but that form seems to be > disfavored.) nit? looks like a full grown bug to me. /12 seems excessive to make the point. how about the full example becoming: inetnum: 192.0.0.0/22 # example remarks: Geofeed https://example.com/geofeed_1 inetnum: 192.0.2.0/24 # example remarks: Geofeed https://example.com/geofeed_2 If geofeed_1 contains geolocation data about 192.0.2.0/29, it is ignored because 192.0.2.0/24 is within the more specific 192.0.2.0/24 inetnum: covering the address range and has a geofeed reference. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Erik Kline's Yes on draft-ietf-opsawg-9092-update-10: (with COMMENT)
thanks erik, > * "... processing is too hard." > > Perhaps there's a better wording that might be found here. "imposes > significant computational complexity" or something? how about processing would be quite complex and error prone randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-9092-update-09
> Q1: There are a few places where the document says "Currently". I'd > prefer to instead say something like "At the time of publishing this > document". I do realize this issue already exists in RFC 9092. sure. thanks. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-9092-update-09
tim: > (1) The following paragraph appears twice in the document (looks like just a > copy/paste error when moving stuff around): > > "Identifying the private key associated with the certificate and >getting the department that controls the private key (which might be >stored in a Hardware Security Module (HSM)) to generate the CMS >signature is left as an exercise for the implementor. On the other >hand, verifying the signature has no similar complexity; the >certificate, which is validated in the public RPKI, contains the >needed public key." someone caught this the other day, and it has already been fixed in my emacs buffer. good catch anyway; full credit. > (2) Section 6, paragraph 5: is this intended to be a RFC 2119 "MAY"? If so, > capitalize. If not, avoid the word. took me a moment. i think it is para 6, this one, yes? It is good key hygiene to use a given key for only one purpose. To dedicate a signing private key for signing a geofeed file, an RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for the purpose shown in Appendix A. that 'may' should probably be 2119ed. russ, opinion? aside: i hope that 2119 gives meaning to the CAPITALIZED forms, and does not remove the uncapitalized forms from the american/english language. again, thanks for the review. they're hard to get. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-9092-update-08
> Please push -09, and I’ll push to the IETF LC. done randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-9092-update-08
hi rob, thanks for review. appreciated. > (1) p 4, sec 3. inetnum: Class > >Any particular inetnum: object SHOULD have, at most, one geofeed >reference, whether a remarks: or a proper geofeed: attribute when it >is implemented. If there is more than one, the geofeed: attribute >SHOULD be used. > > I don't find this text as clear as it could be. Given the > recommendation is to have a single geofeed reference, then I think > that it would be helpful to provide guidance as to what format that > geofeed reference should take. I.e., I presume that the geofeed > reference SHOULD also use the geofeed: attribute format if the RIR > supports it or the remarks attribute otherwise? 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. > (2) p 9, sec 6. Operational Considerations > >The geofeed files MUST be published via and fetched using HTTPS >[RFC9110]. > > Also note you have a similiar RFC 2119 statement in section 4, and I > wonder whether it would be clearer to only have the formal requirement > listed in one place and referenced from the other place? sure. removed the one in §4 > (3) p 9, sec 6. Operational Considerations > >The geofeed files MUST be published via and fetched using HTTPS >[RFC9110]. > > It is interesting that the geofeed files MUST be fetched using HTTPS, > but earlier the RIR's FTP SHOULD be used to gather the geofeed > references. Presumably if the RIR data was available via HTTPS that > could also be used? this refers to RIRs providing *bulk* ftp, i.e. get the whole shebang in one slurp. can not do that for the geofeed files that are referenced. xref GEOFEED-FINDER does provide bulk retrieval of the geofeed files. > (4) p 11, sec 9. Security Considerations > >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. > > This feels like quite a strong statement to make, and I wonder whether > it won't be better to just point out the risks of using a third-party > and then allow the reader to decide whether to accept that risk? that is why it is SHOULD not MUST, tempting though a MUST may be. there is a general problem of lack of understanding of trust boundaries in a lot of these ops data. if you do not mind, i think we would leave it in. > (5) p 7, sec 5. Authenticating Geofeed Data (Optional) > >Identifying the private key associated with the certificate and >getting the department that controls the private key (which might be >stored in a Hardware Security Module (HSM)) to generate the CMS >signature is left as an exercise for the implementor. On the other >hand, verifying the signature has no similar complexity; the >certificate, which is validated in the public RPKI, contains the >needed public key. The RPKI trust anchors for the RIRs are expected >to already be available to the party performing signature validation. >Validation of the CMS signature over the geofeed file involves: > > involves: => "involves the following steps:", or you need to change > back Obtain ... => Obtaining ..., etc. sharp eye there. i went with obtaining; gerundification :) want me to push this as a -09, or let it mellow? again, thanks. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update
>> i just pushed -08 with what i believe to be all fixes from comments on >> -07. it may be time to push the button on this one. > Actually, Joe did that on 2023-11-29, and it is sitting in Rob > Wilton's AD queue… doh. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update
i just pushed -08 with what i believe to be all fixes from comments on -07. it may be time to push the button on this one. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Opsdir last call review of draft-ietf-opsawg-9092-update-06
hi > 1. Abbreviations > Severl abbreviations in the newly added text is better to be expanded > on the first use, including Certification Authority (CA), EE > (end-entity), Certificate Revocation List (CRL) and Autonomous System > (AS). done, i hope > 2. Content seems repetitive > Section 3: > Any particular inetnum: object SHOULD have, at most, one geofeed >reference, whether a remarks: or a proper geofeed: attribute when it >is implemented. If there is more than one, the geofeed: attribute >SHOULD be used. uh, in what way? if the first should is ignored, the second is useful. > Section 4: > 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 ahhh. redundant with that. gotcha. i think we'll keep the first. thanks a lot for the review! randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Intdir last call review of draft-ietf-opsawg-9092-update-06
hi > Reviewer: Sheng Jiang > Review result: Ready with Nits > > Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) > Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) fixed. thank you! > Downref: Normative reference to an Informational RFC: RFC 8805 been to this movie before. russ has already shared the popcorn. thanks for the review. much appreciated randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update
thanks, med. all in emacs buffer for -07. this is wglc. would appreciate more constructive reviews. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update
how about rewording to remove second must so we don't need to argue over it? :) OLD: 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. NEW: 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. [ credit russ ] randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update
hi med, thanks a million for the time reviewing > * Abstract: add "This document obsoletes RFC 9092. sure; in my emacs buffer for -07. aside: is this sort of doc tracking in abstracts a fashion? > * Abstract: s/datafiles/data files doh. thanks. > * The changes vs 9092 lists "Geofeed file only UTF-8 CSV", but the > NEW abstract removes the CSV mentions that were called out in > the abstract of RFC9092. I would revert to the OLD wording in > 9092. my, admittedly poor, memory is that this happened because some other reviewer pushed in the other direction. but i think this would be a good change and is in my emacs buffer for -07. unless i hear otherwise, good change > * I would delete "Stress that authenticating geofeed data is >optional." as it was clear enough in 9092 that part is optional: > " An optional utterly awesome but slightly complex means for >authenticating geofeed data" this was put in very intentionally. we got a fair bit of ops reluctance to implement because folk whined that the authentication was too high a hill to climb. to quote a proponent "This is probably the main push back I get from people procrastinating [about] adoption." so, unless you feel strongly, i suggest no harm in the redundancy of leaving it in. > * Inappropriate use of normative language in an example in Section > 4: s/ this MUST be discarded because 192.0.2.0/24 is within the > more/ this must be discarded because 192.0.2.0/24 is within the > more uh, discarding is not optional, but rather an 'absolute requirement' [2119]. are we off here? if you feel strongly, whack me again. > * Not sure I would keep the last para starting with "There is > open-source code to traverse ..." in Section 4. This is can be > moved to an appendix of to Section 8. hmmm. this is not describing an implementation (sec 8) of geofeed objects, but a *use* of them. it's a bit of a selling point, ease of use. i am open to argument either way. clue bat please. again, deep thanks for reviewing. good reviews are not easy to get these days. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-05.txt
> authors pushed latest revision of $ubject. would very much like some > wg members, or anyone actually. to have a look and comment before we > decide if it is time to ask for wglc. well, that elicited only one poke (thanks ggm) :( chairs, think a wglc will elicit more? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-05.txt
authors pushed latest revision of $ubject. would very much like some wg members, or anyone actually. to have a look and comment before we decide if it is time to ask for wglc. thavanceanks randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-04.txt
> Small nit: the “Error: Spurious zero bits in bitstring.” line in the > dumpasn1 output in Appendix A can be removed, to avoid confusing the > reader. I suspect that particular error message is a bug in dumpasn1 > rather than in the encoding example. thanks. fixed. not worth a new push unless chairs think otherwise. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-02.txt
> I will work on items 1-4 for the next version. thanks. and thanks job for the careful eyeballs randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
>>> Ah, ok. For both RSC and RTA distinct properties are listed such as >>> "applicable in long run", "usable", "complex code"; if no comparison is >>> intended I'd just remove the two paragraphs about RTA & RSC. >> >> we seem to be at cross-purposes here. the point was not comparison at >> all. never has been. the point is two illustrations of signing. > > Yes, indeed both RTA and RSC can be used to sign arbitrary digital objects > through reference of their respective SHA256 message digest. But that > applies to any and all digital objects. :) > > Given that the Geofeed specification includes a build-for-purpose > methodology (which has running code), are references to other illustrations > of signing maybe somewhat of distraction? analohgously for your bag on the side of rpki-client? :)/2 randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
> target="https://sobornost.net/~job/using_geofeed_authenticators.txt;> > > Example on how to use rpki-client to authenticate a signed > Geofeed > > > > thanks >>> In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to >>> each other in a subjective manner about perceived complexity. >> >> a *comparison* was not intended, and i don't see it there. > > Ah, ok. For both RSC and RTA distinct properties are listed such as > "applicable in long run", "usable", "complex code"; if no comparison is > intended I'd just remove the two paragraphs about RTA & RSC. we seem to be at cross-purposes here. the point was not comparison at all. never has been. the point is two illustrations of signing. > 1/ the new EE certificate uses an 'inherit' element in its RFC3779 >extension, but section 5 disallows the use of 'inherit' in EEs. sigh. russ? > 2/ given that the example EE was refreshed in -01, the example >Base64-encoded CMS signature (page 24) also must be refreshed. russ? > 3/ might be good to suggest the use of one-time-use EE certs, perhaps: > >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 [RFC6487]). MUST is not "suggest." perhaps SHOULD? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
ok, i am trying to make some time for this. thanks for the review!
> In section 8 'Implementation Status', a reference could be added to
> https://www.rpki-client.org/. I extended this RPKI validator
> implementation to have the ability to cryptographically verify a given
> RPKI-signed Geofeed authenticator. Yay, running code!
cool. but may we please have a cite to how to use this for "Finding and
Using Geofeed Data?"
> In section 5 it is unclear why RPKI-RTA and RFC 9323 are compared to
> each other in a subjective manner about perceived complexity.
a *comparison* was not intended, and i don't see it there.
> If anything, RFC9323 probably is simpler to implement (compared to
> RPKI-RTA), because of RFC9323's similarity to other pre-existing RPKI
> profiles. Both specifications facilitate RPKI signatures over a bare
> SHA256 digest, but RFC9323 also allows the signer to optionally
> include a filename (which could be a reference to the Geofeed file at
> hand). Multiple implementations exist. RPKI-RTA however appears to be
> an abandonded project, probably because the RTA proposal deviated
> significantly from RFC 6488, this deviation increases the burden on
> implementers because less previous implementation work can be
> leveraged.
>
> Suggestion: remove the RPKI-RTA reference, or perhaps just remove both
> RFC9323 and RPKI-RTA references, as the Geofeed specification itself
> already outlines a workable RPKI-based authenticator.
h. these were intended as cites to usable protocol and code to
implement signing and verifying the authenticated files; a bit more
direct, but analogous to your suggestion to cite rpki-client code.
so maybe the cites are useful but not deeply necessary. otoh, moving to
Implementation Status seems inappropriate, as it's not really
implementation or status. h. let's see what other authors think.
> It would be helpful if the specification provides clarity to
> implementers by mandating that the Autonomous System Identifier
> Delegation certificate extension MUST be absent. ASNs are not used in
> Geofeed data, and thus such an extension would serve no purpose on the
> Geofeed EE certificate. Other RPKI profile specifications nowadays are
> very specific about which of the RFC 3779 extensions are expected to be
> present or absent.
how about
The address range of the signing certificate MUST cover all
prefixes on the geofeed file it signs. The certificate MUST NOT
include the Autonomous System Identifier Delegation certificate
extension [RFC3779].
and, for good measure
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 example EE certificate in Appendix A erroneously contains a
> superfluous Subject Information Access AccessDescription pointing
> towards a RRDP server. RRDP SIA ADs are only expected to appear on CA
> certificates, not on EE certs. See
> https://www.rfc-editor.org/errata/eid7239 for more information.
so remove
SEQUENCE {
OBJECT IDENTIFIER subjectInfoAccess
(1 3 6 1 5 5 7 1 11)
OCTET STRING, encapsulates {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 13'
[6]
'https://rrdp.example.net/notification.xml'
}
}
}
}
> I've prepared newly generated certificates which the authors could
> consider using: https://git.rg.net/randy/draft-9092update/pulls/1/files
> I also took the liberty to include a missing CRL, and update the example
> from IPv4 to IPv6 :-)
way too much hacking for my taste without adding clarity. e.g. how does
an ipv6 sales pitch add clarity for the implementor or user? let's see
what other authors think.
or, to put it another way, what *minimal* change would add significant
clarity? in this wg, we're not paid by the word :)
again, thanks for review.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
> please resubmit this draft as draft-ietf-opsawg-9092-update-00 > replacing draft-ymbk-opsawg-9092-update. Do not make any other > changes to the document text. done. thanks. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] POLL FOR IPR: draft-ymbk-opsawg-9092-update
No, I'm not aware of any IPR that applies to this draft randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01
> Absent implementation of the geofeed: attribute in a particular IRR > database > > if so, it was intentional. perhaps s/IRR/Whois/? > > JMC: Yep. I see what you’re saying now. I was reading as RIR. I > think IRR is fine, but perhaps it should be expanded like you do RIR > earlier. sure > > My biggest gripe in the diff is that your “Implementation Status” > > section has normative language, which seemed odd to me. > > that MAY is from 9092. but i take your point and downcased it. > > JMC: Thanks. There are two MUSTs there, too around how to interpret > ARIN data. darn. missed them in the xml cloud. i suspect these recommendations for dealing with arin data belong in a whole new section massimo has suggested, explicit instructions on fetching geofeed data. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01
> I’ve read the original draft and the diff mentioned below. thanks. reviews are hard to find these days. > I think you’ve misspelled RIR as IRR in the diff. do you mean Absent implementation of the geofeed: attribute in a particular IRR database if so, it was intentional. perhaps s/IRR/Whois/? > My biggest gripe in the diff is that your “Implementation Status” > section has normative language, which seemed odd to me. that MAY is from 9092. but i take your point and downcased it. i would push, but massimo has dumped a big proposed change on us and we're pretending to think about it. thanks again for the review. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01
hi med, >>> (4) Note sure we can mandate by spec how the data can be >>> "consumed". I'm afraid the NEW sentence in the Sec Cons>> isn't >>> useful. I would at least avoid the use of normative language >>> there. >> >> you mean >> >> 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. >> >> are you saying this is not a security consideration, with which i >> am inclined to disagree? it's an attack vector; i could >> indirectly cause you not to get your MTV. or you just don't like >> the SHOULD? > > [Med] The point here is that the NEW SHOULD is too specific about how > a consumer access the content, while it does not guarantee that the > data is not altered (absent integrity/verification checks). Also, it > is OK to access the data via trusted parties that extract and present > the data with all due checks/verification in place. > > BTW, please note that you already have: > >All the security >considerations of [RFC8805] apply here as well. > > And RFC8805 says the following: > >For consumers, feed retrieval processes may receive input from >potentially hostile sources (e.g., in the event of hijacked traffic). >As such, proper input validation and defense measures MUST be taken >(see the discussion in Section 3.1). i am still waiting to hear from co-authors. but ... i think this is trying to address an actual current problem. folk are alleging to provide aggregated data with no formal statement of the methods to ensure provenance, integrity, or authenticity of those data. so i am gonna stall on this one. >>> (3) Section 3 >>> >>> CURRENT: >>> "Currently, this has been..." >>> >>> It is good to report what is implemented, but I don't think we need >>> to have them frozen in the spec. Please see RFC7942. >> >> easy for me to hack, but i would like to hear from co-authors >> before doing so. some motivation for this update is the socio- >> politics of the RIRs and getting them to move forward. >> >> or are you perhaps suggesting an Implementation Status Section per >> 7942? > > [Med] Yes. ok. done. it is not always easy to pick what to move. so further discussion solicited. > [Med] https://author-tools.ietf.org/iddiff thanks! i am a poor ietf tools archaeologist. unfortunately, i am old enough to not like massive bits in an email. so i have stashed a proposed diff at https://archive.psg.com/draft-ymbk-9092update.diff.html thanks again for spending time on this. much appreciated. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01
hi med, yay! much thanks for the review. > (1) As a complement to the discussion in the first para of the > Introduction, I would add a note that the source address does not > necessary point to the user. You may add a pointer to > https://datatracker.ietf.org/doc/html/rfc6269#autoid-14 when issues > with geolocation are discussed. Providers of Internet content and other services may wish to customize those services based on the geographic location of the user of the service. This is often done using the source IP address used to contact the service, which may not point to a user, see [RFC6269], Section 14 in particular. [ are you just fishing for a cite :) ] > (2) Section 1 > > CURRENT: >An optional utterly awesome but slightly complex means for >authenticating geofeed data is also defined. > > You may add a pointer to Section 4 for better clarity. thanks An optional utterly awesome but slightly complex means for authenticating geofeed data is also defined in Section 4. > (3) Section 3 > > CURRENT: > "Currently, this has been..." > > It is good to report what is implemented, but I don't think we need to > have them frozen in the spec. Please see RFC7942. easy for me to hack, but i would like to hear from co-authors before doing so. some motivation for this update is the socio-politics of the RIRs and getting them to move forward. or are you perhaps suggesting an Implementation Status Section per 7942? this makes some sense to me; though we do seem to be adding more special sections to our cultural expectations. co-authors please think about this. i know massimo, for one, has been working the ground fight on this. > (4) Note sure we can mandate by spec how the data can be > "consumed". I'm afraid the NEW sentence in the Sec Cons isn't > useful. I would at least avoid the use of normative language > there. you mean 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. are you saying this is not a security consideration, with which i am inclined to disagree? it's an attack vector; i could indirectly cause you not to get your MTV. or you just don't like the SHOULD? again, i would like to hear from co-authors. > (5) RFC9092 is not normative, as this is obsoleted by this one. oups. thanks. > (6) I would maintain the OLD title and delete "A Minor Update to" this makes sense to me. i have hacked it, but would love to hear from co-authors. i would send a proposed diff to you, except i no longer know how to find the differ on the wonderfully improved web site. again, thanks randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] draft-ymbk-opsawg-9092-update-01
we have pushed draft-ymbk-opsawg-9092-update-01, see https://datatracker.ietf.org/doc/draft-ymbk-opsawg-9092-update/ and asked to have a few minutes for it on the agenda next month. as the document says Changes from [RFC9092] include the following: * It is no longer assumed that a geofeed file is a CSV, comma separated value list. * RIPE has implemented the geofeed: attribute. * Allow, but discourage, an inetnum: to have both a geofeed remarks: attribute and a geofeed: attribute. * 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. your read and review would be appreciated. randy, for the usual suspects ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Call for presentation//FW: IETF 117 Preliminary Agenda
-01 was just published. the authors believe it is ready for adoption by the opsawg. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS+ SSH Enhancements Document
> - The TACACS+ authentication is extended to allow the TACACS+ client > to request the public keys from the TACACS+ server, to ease ssh-key > management delivered signed by the private key for proof of posession, yes? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-dahm-tacacs-tls13
definitely adopt, please randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-dahm-opsawg-tacacs-security-00.txt
> As an contributor, I rather like the simpler TLS encap over T+ > approach described in the tls13 draft. I’d personally not > over-engineer something that isn’t immediately required. T+ has been > around for a while and is heavily used. I don’t know that we need to > spend time adding extensibility. yep. and tls is fairly well established and widely implemented. we used to say "don't reinvent tcp." now it is "don't reinvent tls." randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Qlog] adopting draft-gharris-opsawg-pcap and draft-tuexen-opsawg-pcapng
> Given how systemd is prone to considerable change, I'd think it would be > best to leave that out. please. and for many other reasons randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] TACACS++, please...
>> Just FYI, there are 459 people on the OpsAWG list; this means we have >> almost 500 witnesses to what I'm going to interpret as "We'll have this >> done in a few days/weeks" :-) i hereby witness your extremely overly optimistic intentional misinterpretation :) randy --- ra...@psg.com `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com` signatures are back, thanks to dmarc header butchery ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
will push 16 randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
>>> If we're going with "[#RPKI Signature] address range MUST match [inetnum: >>> followed to get here]", then there are probably a couple places that still >>> talk about "covered by" that should catch up. >> >> don't find any >> >> what i did find is that i forgot to remove >> >> The address range of the signing certificate MUST cover all >> -prefixes in the geofeed file it signs; and therefore must be >> -covered by the range of the inetnum:. >> +prefixes in the geofeed file it signs. > > ok. > > It looks like the thing in the diff that stuck out at me is actually for > the unsigned case, and "covered by" is (AFAICT) the right semantics for > that situation. if it still itches, could i get a direct pointer? > Having slept it over, I think the "IP address range [of "# RPKI > Signature:"/"# End Signature"] must match the inetnum: URL followed to get > to the file" is a good choice and helps identify the intended semantics > (though, of course, is not itself covered by the signature). consider yourself lucky to have missed the dozen messages where we went down this rathole. > I think we still need to update the example to show how to represent a > non-CIDR range, though. (I think, from the previous discussion, we > wanted the "RPKI Signature" line to have a starting address and the > "End Signature" line to have an ending address, but could be > misremembering.) uh, i think it would be # RPKI Signature: 192.0.2.0 - 192.0.2.255 # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu ... # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk= # End Signature: 192.0.2.0 - 192.0.2.255 change made in my emacs buffer > P.S. I am impressed by the (apparent) automation to re-generate the > certificate (and example) at the time of building the document! no comment randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
mornin' folk, thanks, rob. to be honest, i did not track process. > When you get a chance, please can you check whether -15 is sufficient > to clear your discuss. I think that is the last step to progressing > this doc. shout if you need anything from my side. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
> If we're going with "[#RPKI Signature] address range MUST match [inetnum: > followed to get here]", then there are probably a couple places that still > talk about "covered by" that should catch up. don't find any what i did find is that i forgot to remove The address range of the signing certificate MUST cover all -prefixes in the geofeed file it signs; and therefore must be -covered by the range of the inetnum:. +prefixes in the geofeed file it signs. > We may also need to look more closely at the bits after "# RPKI > Signature". The example uses a CIDR range, but IIRC inetnum: ranges > are not limited to CIDR blocks, which would mean we need a story for > how to handle non-CIDR blocks. ranges are well-defined in rpki, inetnum:, etc. 8805 entries must be cidr. that an inetnum: or rpki cert range must cover geofeed file prefixes seems pretty clear. but i have tweaked wording a bit. i can push my emacs buffer to id repo, but will wait a bit for other comments. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
i have a vague hope -14, just published, addresses all currently expressed concerns. but i am under my quota for wrongness for the day. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
> Rob should probably weigh in on how much review such a change would need. once i have the next rev out, we should look at the diff to -09 or so. i suspect that giving the wg a week to whine would not be inappropriate. but such decisions are above my pay grade. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
>>> Publishing this document on the stanards-track does make one wonder >>> whether RFC 8805 should be adopted at least into the IETF stream and >>> possibly to the standards-track as well... >> >> and it could use a bit of work in the process. can you say "let's open >> a can of worms?" but yes, geofeed has seriously 8805 deployment, and it >> is showing cracks. > > The analogies to DMARC do kind of write themselves... i nominate dnssec as the poster child here. first version was not deployable at all. > (We do have plenty of examples of shiny cryptographic schemes that remain > mostly unused, but I will refrain from naming names...) and some that should have been unused >>> Maybe I'm just confused about what "covered by he range of the inetnum:" >>> means, but I only see (at least so far) requirements that the signing >>> cert cover all addresses in the file, and that we fetch from the >>> most-specific inetnum: object with a geofeed reference. Can't I still >>> sign with a cert that covers a broader range of addresses than the >>> intenum: object used to fetch? >> >> i am trying to think of two examples [ yes, certs and inetnum:s may >> express ranges as well as cidr blocks ] >> >> two inetnums: >>1.2.3.0 - 1.2.3.7 >>1.2.3.6 - 1.2.3.13 >> and a cert for 1.2.3.0 - 1.2.3.13 >> >> and conversely >> >> two certs: >>1.2.3.0 - 1.2.3.7 >>1.2.3.6 - 1.2.3.13 >> and an inetnum: for 1.2.3.0 - 1.2.3.13 > > IIUC you'd need to subdivide the inetnums in order for the signatures to > work? [ excuse i am running on 36 hours no sleep ] currently we say The address range of the signing certificate MUST cover all prefixes in the geofeed file it signs; and therefore must be covered by the range of the inetnum:. i.e. a cert for 1.2.3.0/24 can not sign either example. i don't think that second restrictive clause is a logical conclusion from the first. i suggest that, for simplicity and a redundancy check, the wrapper MUST be # RPKI Signature: A # # End Signature: B where A-B MUST be the range of the inetnum: pointing to the file and that the signing cert MUST cover A-Z, though could be wider. i will work the text > nit: comma before "abusing" to aid readability. ack randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
so The canonicalization procedure converts the data from its internal character representation to the UTF-8 [RFC3629] character encoding, and the sequence MUST be used to denote the end of a line of text. A blank line is represented solely by the sequence. Other non-printable characters, such as backspace, are not expected. ? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
ok, let me try to cover what russ has not. good reviews are much appreciated [ in the cs academic social circle, there has been comment that, though reviews can be a pita, they are substantial revwiews. one gets useful feedback. in man other fields, one gets one or two sentences saying useless and even rude things. the ietf review cycle, once one gets to last call (yes, that is a problem), is even more thorough and constructive. ] > We are careful to note that: > >The bracketing "# RPKI Signature:" and "# End Signature:" MUST be >present exactly as shown. > > How do we construct the bits (CIDR block?) that come after the quoted > strings? Do they only matter for matching start/end, or are we supposed > to check them in the validation procedure? how about The bracketing "# RPKI Signature:" and "# End Signature:" MUST be present following the model as shown. The IP address range MUST match that of the signer's certificate. and the cert is already in the validation > Thanks to Kyle Rose for the secdir review, and all who participated in > the subsequent discussion. indeed > Publishing this document on the stanards-track does make one wonder > whether RFC 8805 should be adopted at least into the IETF stream and > possibly to the standards-track as well... and it could use a bit of work in the process. can you say "let's open a can of worms?" but yes, geofeed has seriously 8805 deployment, and it is showing cracks. > Section 1 > >This document specifies how to augment the Routing Policy >Specification Language (RPSL) [RFC2622] inetnum: class to refer > > Interestingly, I don't see "inetnum" at all in RFC 2622 (but the > treatment in RFC 2725 is helpful to some extent). Should we be > referencing 2725 (or something else) in addition to 2622? grumph! i though i had fixed this. clearly i had not. > Section 3 > >The URL's use of the web PKI can not provide authentication of IP >address space ownership. It is only used to authenticate a pointer >to the geofeed file, [...] > > I'm a little confused by the use of the phrase "authenticate a pointer > to the geofeed file". My understanding is that the "pointer to the > geofeed file" is the URL itself, i.e., it is a pointer from the RPSL > stanza to the geofeed file, and that dereferencing the URL retrieves the > geofeed file itself (i.e., not a pointer). In particular, the URL (and > any Web PKI usage therein) does not do anything to authenticate the RPLS > stanza in which the URL appears. IIUC, it would be okay to just drop > that bit and say "It is only used to authenticate the domain name in the > URL, and provide confidentiality and integrity for the geofeed file in > transit". Am I missing something? no. my current edit buffer has 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 Resource Public Key Infrastructure (RPKI, see [RFC6481]) can be used to authenticate IP space assignment; see optional authentication in Section 4. >If a geofeed CSV file describes multiple disjoint ranges of IP >address space, there are likely to be geofeed references from >multiple inetnum: objects. > > We might note that such files with geofeed references from multiple > inetnum: objects are not compatible with our signing procedure (right?) > and thus vaguely discouraged. i am not sure i would discourage the use, as i suspect the rpki authentication will mostly remain unused. If a geofeed CSV file describes multiple disjoint ranges of IP address space, there are likely to be geofeed references from multiple inetnum: objects. Files with geofeed references from multiple inetnum: objects are not compatible with the signing procedure in Section 4. > Maybe I'm just confused about what "covered by he range of the inetnum:" > means, but I only see (at least so far) requirements that the signing > cert cover all addresses in the file, and that we fetch from the > most-specific inetnum: object with a geofeed reference. Can't I still > sign with a cert that covers a broader range of addresses than the > intenum: object used to fetch? i am trying to think of two examples [ yes, certs and inetnum:s may express ranges as well as cidr blocks ] two inetnums: 1.2.3.0 - 1.2.3.7 1.2.3.6 - 1.2.3.13 and a cert for 1.2.3.0 - 1.2.3.13 and conversely two certs: 1.2.3.0 - 1.2.3.7 1.2.3.6 - 1.2.3.13 and an inetnum: for 1.2.3.0 - 1.2.3.13 and i m starting to think i am rat-holing on complexlow-payoff corner cases, a disease i rather dislike. the current state is simple and clear. are there seriously useful cases it does not cover? i will keep thinking. and listening, of course. >Identifying the private key associated with the certificate, and >getting the department
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
>> ever see the cat herding video? > https://urldefense.com/v3/__https://archive.psg.com/cat-herders.mov__;!!NEt6yMaO-gk!UwP65THoPAKtaE74N5YFw9MSNO17zkgu96E4xctycM7-Iu1KDATEZf22uke20g$ > > Does not render. Oh well, I’ve seen cat videos before, I’ll use my > imagination. i suspect your corporate nannyware put some strange rubbish after the ".mov" but you can also try https://archive.psg.com/catherding.mpg >>> 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. >> >> no. this is per inetnum: object, not per registry. see beginning of >> para. perhaps i should add an example of an inetnum: object. > > I know what an inetnum: is (although it’s a fair point that maybe not > everybody does). In thinking about it a little more, yes “flag day” > was too strong, however I think there’s still potentially a problem, > depending on what entity has the issues. > > If it’s only the RIR (“server”) side that lags, then presumably > clients will be built to consume both geofeed: and inetnum: from day > one. In that case cutover is easy: once the RIR implements geofeed:, > you cut over to it in all the inetnum:s that RIR serves, done. it's even simpler. the whois server would support both flavors of attribute in an inetnum:, remarks: and geofeed:. (note that it MUST support the remark: form.) it is the individual inetnum: objects registered by ISPs that cut over one by one at their leisure. an isp with 42 inetnum: objects could cut them over one at a time on wednesday afternoons. > On the other hand, if there are clients (now, or ever) that implement > only inetnum:, then I do think we’re in for an eternity of supporting > both. i think you mean if there are clients that do not support the geofeed: attribute form in inetnum:s. yup, then they are not going to get the urls from inetnum:s which have moved to the new form. such is forward migration. >>> 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. >> >> the geofeed lines would then need to be sorted, clumped, ... seems a >> bit complex for not much win. due to the administrative structure and >> process, inetnum: objects tend to the same granularity as RPKI objects. >> so having the geofeed files follow seems natural. > > OK. My fear was that there might already be substantial investment in > geofeed:s that cover multiple objects, and resistance to shredding > them down to individual object-level feeds. But maybe there isn’t and > won’t be. in parallel, i am thinking of the implications of a question in this space from ben. i think the comparitive granularity of inetnum:s and the corresponding rpki data is important but unknown. my head hurts. i want to keep thinking about this space. > I took a look and it looks good. I have one new nit, in §4, because of > course I do: > >The bracketing "# RPKI Signature:" and "# End Signature:" MUST be >present exactly as shown. > > A pedant might say “exactly as shown” means verbatim "# End Signature: > 192.0.2.0/24” the quote marks were insufficiently explicit? > it may be worth being even clearer. It would be possible to write it > out in excruciating detail of course, but possibly replacing “exactly > as shown” with something like “following the model shown” might be > enough. (I say “ish” because I wonder if “192.0.2/24”, the way > right-thinking people write prefixes, would also be OK, or if it’s not > “exactly as shown” enough.) i'll try it. but the previous complaint there was that the text was insufficiently prescriptive. > I was sad to see the tweezers left on the cutting room floor but I > understand why. for you, i would throw them back. but the strength of the current "brute force" phrasing appeals. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
> Responding to Part 1 of your DISCUSS and a few of your comments. My
> co-authors will address the other parts, including the NITS.
turning attention to this now. i was in the RIPE meetings getting this
through their sausage machine.
> OLD:
>
>1. Obtain the signer's certificate from an RPKI Repository. The
>certificate SubjectKeyIdentifier extension [RFC5280] MUST match
>the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier
>[RFC5286]. If the key identifiers do not match, then validation
>MUST fail.
>
> NEW:
>
>1. Obtain the signer's certificate from the CMS SignedData CertificateSet
> [RFC5652]. The certificate SubjectKeyIdentifier extension [RFC5280]
>MUST match the SubjectKeyIdentifier in the CMS SignerInfo
> SignerIdentifier
>[RFC5652]. If the key identifiers do not match, then validation
>MUST fail.
done
> [snip]
>
>>
>> Section 3
>>
>> The URL's use of the web PKI can not provide authentication of IP
>> address space ownership. It is only used to authenticate a pointer
>> to the geofeed file, [...]
>>
>> I'm a little confused by the use of the phrase "authenticate a pointer
>> to the geofeed file". My understanding is that the "pointer to the
>> geofeed file" is the URL itself, i.e., it is a pointer from the RPSL
>> stanza to the geofeed file, and that dereferencing the URL retrieves the
>> geofeed file itself (i.e., not a pointer). In particular, the URL (and
>> any Web PKI usage therein) does not do anything to authenticate the RPLS
>> stanza in which the URL appears. IIUC, it would be okay to just drop
>> that bit and say "It is only used to authenticate the domain name in the
>> URL, and provide confidentiality and integrity for the geofeed file in
>> transit". Am I missing something?
>
> I think it would be more accurate to say that the WebPKI provides
> authentication and integrity of the geofeed file that is fetched. However,
> as I said in response to Roman's ballot comments, the ultimate integrity
> check is the signature that is validated with the RPKI certificate.
the current text is close to this. please indicate any tweaks that
would improve it
The URL's use of the web PKI can not provide authentication of IP
address space ownership. It is only used to authenticate a pointer
to the geofeed file, authenticate the domain name in the URL, and
provide confidentiality and integrity for the geofeed file in
transit. In contrast, the Resource Public Key Infrastructure (RPKI,
see [RFC6481]) can be used to authenticate IP space ownership; see
optional authentication in Section 4.
> OLD:
>
>One needs a format that bundles the relevant RPKI
>certificate with the signature and the digest of the geofeed text.
>
> NEW:
>
>One needs a format that bundles the relevant RPKI
>certificate with the signature of the geofeed text.
easy
> OLD:
>
>Borrowing detached signatures from [RFC5485], after file
>canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
>would be used to create a detached DER encoded signature which is
>then padded BASE64 encoded (as per [RFC4648]) and line wrapped to 72
>or fewer characters.
>
> NEW:
>
>Borrowing detached signatures from [RFC5485], after file
>canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652]
>would be used to create a detached DER encoded signature which is
>then padded BASE64 encoded (as per [RFC4648]) 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 calculating the message digest on the SignerInfo
>SignedAttributes [RFC8933]. The message digest algorithm identifier
>MUST appear in both the SigenedData DigestAlgorithmIdentifiers and
>the SignerInfo DigestAlgorithmIdentifier [RFC5652].
ok
>> text. Trailing space characters MUST NOT appear on a line of text.
>> That is, the space or tab characters must not be followed by the
>>sequence. [...]
>>
>> Is the restriction on Unicode characters of category "space separator"
>> ("space characters") or the two listed characters? (Why just those two,
>> and not form feed as well?)
>
> Looking at the ABNF in RFC 8805, It does not look like there should be
> any trailing whitespace, this was more for consistency with RFC 5485.
perhaps a clearer phrasing would be
Trailing space characters MUST NOT appear on a line of text. That
is, space or tab characters must not immediately preceed a
sequence.
> OLD:
>
>4. Verify that the IP Address Delegation certificate extension
>[RFC3779] covers the address range of the geofeed file. If the
>address range is not covered, then validation MUST fail.
>
> NEW:
>
>4. Verify that the IP Address Delegation certificate extension
>[RFC3779] covers all of
Re: [OPSAWG] Murray Kucherawy's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
> I may have missed something, but why does Section 5 advocate for use > of HTTPS to fetch geofeed files in the second paragraph, and then FTP > in the seventh? the former is for getting one file through direct reference. the latter is bulk transfer of the totality of the repository's data through bulk query. > In Section 5, "https" should be "HTTPS" since you're describing a > protocol and not a URI scheme (or if you meant to do the latter, > please say so). sure randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
my apologies. -11 had too many typos. immediately pushed -12 randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] John Scudder's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
thanks john. appreciated. > 0. I’d like to thank George Michaelson for a thorough and helpful, not > to say exemplary, shepherd’s report. it's odd. the acks have thanked ggm twice, once for shepherding, and folk seem to miss it. > 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? really, if the ripe community adopts it. and progress is good there. ever see the cat herding video? https://archive.psg.com/cat-herders.mov > By the way, I bet you should expand “RIR“ on first use. ack. but aren't the darned RIRs expansive enough? :) > 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. sure > 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. no. this is per inetnum: object, not per registry. see beginning of para. perhaps i should add an example of an inetnum: object. inetnum:147.28.0.0 - 147.28.15.255 netname:RGNET-RSCH-147-0 country:EE org:ORG-RO47-RIPE admin-c:RB45695-RIPE tech-c: RB45695-RIPE abuse-c:AR52766-RIPE status: LEGACY notify: r...@rg.net mnt-by: MAINT-RGNET mnt-by: RIPE-NCC-LEGACY-MNT remarks:Geofeed https://rg.net/geofeed created:2020-10-20T23:45:00Z last-modified: 2020-11-12T13:16:12Z source: RIPE except i bet it would take hours to use proper example formalities for everything. > Why not permit both the remarks: and geofeed: versions to enable > transition? because then, as you point out, it is three paragraphs if they disagree. > 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. the grofeed lines would then need to be sorted, clumped, ... seems a bit complex for not much win. due to the administrative structure and process, inetnum: objects tend to the same granularity as RPKI objects. so having the geofeed files follow seems natural. i figure that, if signing actually is used, and folk whine, we can beg russ to do a bis. > 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? sure. > 5. Section 5: > >An entity
Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-finding-geofeeds-10: (with COMMENT)
> -- 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. note that it also specifies the "Geofeed:" attribute > Should the case when both "remarks: Geofeed" and "geofeed" are present but > differ be mentioned ? you want more/other than 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. > -- 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). added If the geofeed file is signed, and the signer's certificate changes, the signature in the geofeed file MUST be updated. > -- Section 5 -- > Is there any reason why the doc shepherd is not acknowledged ? in what way was this insufficient? The authors also thank George Michaelson, the document shepherd, ... > I find the use of the colon in "inetnum:" quite annoying and > confusing. so say we all. but it seems to be the convention in the RPSL docs. > The use of quotes in the last § of section 3 is easier to read and > parse i think we're in RDAP land at that point. perhaps massimo and/pr ggm, who are more clued in that space could comment. > -- Section 3 -- > Do the examples really need to be in IPv4 ? ;-) i am old > -- 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). prefer "part of the company?" randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-finding-geofeeds-08: (with COMMENT)
i did push -10 with that addition per discussion. it gets pretty gritty when the political and operational uglies raise their heads. sorry. and thanks. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-finding-geofeeds-08: (with COMMENT)
< rant > > "While the IETF published one of the specifying documents for RPS > [RFC], effective change control for RPSL today lies with the RIPE > community [ref]. However, it is in scope to use the Remarks: field..." i wish. ripe has the energy and the momentum. ripe does a lot of the docs. ripe has running code. and ripe is where this is moving forward in the sense of documentation and open code. otoh, most rirs are moving on hacking geofeed: attributes. massimo tracks far better than i. but the rirs are immature siblings who pretend to get along when grownups are watching, but fight dirty in the back seat of the car. do not judge their words; but their actions. arin does not even have a remarks: attribute, as you can see in the draft. and if you wonder if this is a disservice to the members, note that arin membership, last time i asked, represents less than 20% of the address holders in their region. so, ripe is indeed where it is happening. but saying that ripe has change control of the rpsl specification in the ietf sense is a dream. how about The original RPSL specifications starting with [RIPE81], [RIPE181], and a trail of subsequent documents were done by the RIPE community. The IETF standardardized RPSL in [RFC2622] and [RFC4012]. Since then, it has been modified and extensively enhanced in the RIR community, mostly by RIPE, [RIPE-DB]. Currently, change contol effectively lies in the operator community. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Intdir last call review of draft-ietf-opsawg-finding-geofeeds-08
> This abstract is too short for me ... > Potential new text (don’t hesitate to modify it): > A network operator can publish a mapping of IP address prefixes to > simplified geolocation information, colloquially termed a "geolocation > feed" or “geofeed”. This document describes solutions to add geofeed > data inside RPSL based database. except it doesn't. all it does is add a pointer from two classes of rpsl objects to actual geofeed data. but, yes, the abstract might have more text. e.g. the paragraph from the intro This document specifies how to augment the Routing Policy Specification Language (RPSL) [RFC4012] inetnum: class to refer specifically to geofeed data CSV files, and how to prudently use them. i generally do not like abstract == intro, but will hack it. This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data CSV files, and describes an optional scheme to use the Routing Public Key Intrastructure to authenticate the geofeed data CSV files. > BTW, have you an IETF reference regarding the inetnum: class? > Because, the term “inetnum” is neither inside RFC2622 nor RFC4012. for me, C-s finds inetnum in 2622 and inet6num in 4012 but i'll take this as a request to put the 2622 cite back. thanks. > 3. inetnum: Class > > > >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 >attribute MUST be as in this example, "remarks: Geofeed ", where the >token "Geofeed" is case sensitive, followed by a URL which will vary, > > > s/the token "Geofeed" is case sensitive/ the token "Geofeed" MUST be case > sensitive s/followed by a URL/and MUST be followed by a URL 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 which will vary, but MUST refer only to a single [RFC8805] geofeed file. >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. > > > IMHO, the MUST should not be associated to service users but to the > RIRs. it is the consumer who must deal with variance between RIRs, and even between objects in an RIR. i do not think you want to get into the space of telling RIRs what they MUST do. they make the ICANN look friendly. > Until all registrants, for a specific RIR, have migrated any inetnum: > from remarks: use to geofeed: use, this RIR MUST support both the > remarks: and geofeed: forms. support in what way? i suspect what you may intend is that an RIR may publish a mix of the remarks: form and the geofeed: form. i am certainly not going to say that they MUST. but i tossed this in Registries MAY, for the interim, provide a mix of the remarks: attribute form and the geofeed: attribute form. >Currently, the registry data published by ARIN is not the same RPSL >as the other registries; therefore, when fetching from ARIN via FTP > > > Maybe add RFC7485 as reference? > do i have to do it without snark? :) Currently, the registry data published by ARIN is not the same RPSL as that of the other registries (see [RFC7485] for a survery of the whois Tower of Babel); therefore, when fetching from ARIN via FTP >The geofeed files SHOULD be published over and fetched using https >[RFC8446]. > > > s/[RFC8446]/[RFC2818] > yup randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Martin Duke's No Objection on draft-ietf-opsawg-finding-geofeeds-08: (with COMMENT)
> "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. the word "ideally" was meant to signal "not gonna happen." RPSL as in use today varies radically from the RPS as documented by the ietf, and varies between RIRs and between software sets. the last ietf attempt to codify RPSLng was a disaster; when i first became an AD i was told to shut the wg down asap and did so. today, the main thread of RPSL definition is in the RIPE community and the RIPE/NCC implementation. this is in the process of adopting the geofeed: attribute in the INETNUM class. i believe the irrd open source implementation is also following. that's as good as it is likely to get. sorry. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] draft-ietf-opsawg-finding-geofeeds-07
please check -07. i think we got all directorate review comments. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Last-Call] [secdir] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
[ excuse typos; minor hand surgery ] > Aren't the valid ranges for an AS specified in the RPKI-protected > routing data feed (where RPKI is available)? not really, on a number of dimensions first, have a look at draft-ietf-sidrops-rpki-has-no-identity i suggest we not drag ASs into this; they are orthogonal to address space ownership. e.g. someone owns a /24, but creates a ROA to authorize AS42, their upstream, to actually originate the prefix. i.e. ASs do not 'own' address space, the RPKI enables, through ROAs, for address space owners to authorize ASs to announce a (possibly improper) subset of the owner's address space. and inetnum:s are quite disjoint from ASs. heck, i have loaned 198.133.206.0/24 to be used by a north macedonian exchange point (not joking). also, neither the RPSL nor the RPKI invert to enumerate the address space announced by an AS. operators and researchers use the current bgp tables from routers, route views, or ripe/ris if we want today's map. > How does a client know that an IP range specified in the geodata feed > is valid under a given RPKI signature? the rpki is formally authoritative for ip space ownership. in a sense, the rpki was created to rigorously fill the gap left by the lack of authenticity of RPSL. the signature in the geofeed file can be 3779 validated to the trust anchor of the RIR (it should be to the IANA, but the RIRs are at war with the IANA). and the IANA is the ultimate authority for address space, and through it the RIRs. > I.e., that the given AS has authority over that IP range? again, let's not drag ASs in here. they are not ip space owners. the complexity of this space is embarrassing. sorry. i hope this helps. willing to chat on zoom or whatever. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Last-Call] [secdir] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
> the web pki is not associated with ip address space control/ownership. > web pki is based on control of domain name space. the two are quite > unrelated. note that the rpsl, the inetnum: objects, are not well secured and authenticated. this is a bit embarrassing. and, in some regions, the lack of authentication is notorious. hence the hack to use the well-authenticated rpki to sign those data covered by it for those concerned with real authenticity. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Last-Call] [secdir] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
> Pivoting for a second, are you intending to support the case in which > a provider has adopted RPKI but has no intention of signing these > files? unfortunately, this will be common for a while. methods for signing with keys from the rpki are baroque at the moment, with two documents draft-ietf-sidrops-rpki-rta-00 draft-spaghetti-sidrops-rpki-rsc-03 proposing means. > If so, then web PKI integrity (i.e., being able to trust that the data > at the https geofeed URL is controlled by the same entity that > controls the routing data) is still required to prevent forgery. the draft does require tls for the temporary remarks: based url. it will be fixed to do so for the geofeed: url. the web pki is not associated with ip address space control/ownership. web pki is based on control of domain name space. the two are quite unrelated. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
kyle, was it you who was wondering about the ops community process and progress getting this draft implemented? as part of the RIPE process, the RIPE/NCC, who has to actually implement this stuff, issues an impact report. i thought it might be informative. randy From: Edward Shryane via db-wg Subject: Re: [db-wg] New NWI for geofeed? To: denis walker Cc: Database WG Date: Tue, 4 May 2021 22:35:56 +0200 Hello Denis, Colleagues, Following is the impact analysis for the implementation of the "geofeed:" attribute in the RIPE database, based on the problem statement below and the draft RFC: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds I will ask our Legal team to conduct a full impact analysis of the implementation plan. Please reply with corrections or suggestions. Regards Ed Shryane RIPE NCC Impact Analysis for Implementing the "geofeed:" Attribute "geoloc:" Attribute -- Implementing the "geofeed:" attribute does not affect the "geoloc:" attribute. No decision has been taken on the future of the "geoloc:" attribute, a review can be done at a later date. "remarks:" Attribute --- Existing "remarks:" attributes in INETNUM or INET6NUM object types containing a "geofeed: url" value will not be automatically converted to a "geofeed:" attribute. The implementation will validate that an INETNUM or INET6NUM object may contain at most a single geofeed reference, either a "remarks:" attribute *or* a "geofeed:" attribute. More than one will result in an error on update. Any "remarks:" attributes in other object types will not be validated for geofeed references. "geofeed:" Attribute --- The "geofeed:" attribute will be added to the INETNUM and INET6NUM object types. It will be an optional, singly occurring attribute. The attribute value must consist only of a well-formed URL. Any other content in the attribute value will result in a syntax error. "geofeed:" URL - The URL in the "geofeed:" attribute will be validated that it is well-formed (i.e. syntactically correct). The URL must use the ASCII character set only (in the RIPE database, non-Latin-1 characters will be substituted with a '?' character). Non-ASCII characters in the URL host name must be converted to ASCII using Punycode in advance (before updating the RIPE database). Non-ASCII characters in the URL path must be converted using Percent-encoding in advance. Only the HTTPS protocol is supported in the URL, otherwise an error is returned. The reachability of the URL will not be checked. The content of the URL will not be validated. Database dump and Split files -- The "geofeed:" attribute will be included in the nightly database dump and split files. NRTM The "geofeed:" attribute will be included in INETNUM and INET6NUM objects in the NRTM stream. Whois Queries - The "geofeed:" attribute will appear by default in (filtered) INETNUM and INET6NUM objects in Whois query responses, no additional query flag will be needed. RDAP - The "geofeed:" attribute will not appear in RDAP responses. A separate RDAP profile will be needed to extend the response format to include geofeed. This can be implemented at a later date. Documentation --- The RIPE database documentation will be updated, including the inet(6)num object templates and attribute description (with a reference to the IETF draft document). Other RIRs - There is currently no coordinated plan to implement "geofeed:" across regions. Other RIRs may implement "geofeed:" at a later date. Legal Review --- An initial review by the RIPE NCC Legal team found that geofeed data may qualify as personal data, and before introducing the "geofeed:" attribute a full impact analysis of its implementation would have to be conducted by the RIPE NCC. - > On 12 Apr 2021, at 17:59, denis walker via db-wg wrote: > > Colleagues > > ** corrected version getting the attribute names right ** > > The chairs agree that there is a consensus to set up an NWI to create > the "geofeed:" attribute in the RIPE Database. We therefore ask the > RIPE NCC to set up "NWI-13 Create a "geofeed:" attribute in the RIPE > Database" Using the 'Problem statement' below. After the RIPE NCC > completes it's impact analysis we can finalise the 'Solution > definition'. The RIPE NCC can address any of the questions raised in > this discussion that they feel are relevant to the basic creation of > this attribute. > > cheers > denis > co-chair DB-WG > > > Problem statement > > Associating an approximate physical location with an IP address has > proven to be a challenge to solve within the current constraints of > the RIPE Database. Over the years the community has chosen to consider > addresses in the RIPE Database to relate to entities in the assignment >
Re: [OPSAWG] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
just a quickie. i will try to get to the other stuff after $dayjobs assumptions that the rpki and the inetnum: are congruent in ip address space are quite unsafe, sad to say. the granularity of the rpki is not that of the inetnum: space. for a tragic example, among other things, in the arin (noam) region, most address space can not get rpki data for artificial political reasons[0]. and in a sane region, emea, if i am an LIR and get a /32 from ripe, and get an rpki cert for it; i can delegate a /56 to a customer with an inetnum: and sadly they tend not to get rpki certs, but have geoloc. geofeed adoption is being driven by social pressure, customers want their mtv and are loud about it. rpki adoption is driven by operator gossip, not money. these conditions will continue for years, though not as long as ipv6 take-up. the draft is deployable on today's internet with today's administrative and technical infrastructure. in fact, it is deployed and working. more later randy [0] - https://scholarship.law.upenn.edu/faculty_scholarship/2035/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
hi kyle: thanks a million for the review. we have a suply chain problem getting solid reviews these days. > The nits include a need for a thorough editorial pass prior to submission to > the RFC editor. For example: > > * The abstract should probably give the uninformed reader a bit more > information about the overall geofeed ecosystem. * "utterly awesome", "or > whatever", "It would be polite" aha! the style directorate. we'll see how far it gets. maybe even rfced still has a twinkle in their eye. :) > I would also move the privacy discussion from section 2 "Geofeed > Files" to a privacy considerations section, as that is where those > concerned will look for that information. aha. a privacy section is a new fashion of which i was unaware. done. thanks. > This document appears to propose overlapping mechanisms for > establishment of trust in geofeed data. As far as I can tell, geofeed > data may be authenticated both by: > > * RPKI private key signature of a digest of a canonicalized form of the > geofeed data file. * Web PKI via https URL for geofeed data file. not exactly. the web pki has no authority over IP address space ownership. it is only used to authenticate a *pointer* to the geofeed file. and the S in https is just because we know folk will whine if the S is not there; it's ietf fashion, similar to not working over ipv6 (or privacy consideration sections:). And the us of TLS will ensure that the file comes from the intended source and it comes without modification. for example, was i to put my geofeed file in gobble docs, the web pki would be gobble's cert chain, not mine, the IP space owner. one can optionally authenticate the geofeed data themselves by using the rpki to sign over them. and, unlike the web pki, the rpki does provide authority over IP address space ownership. so these two pki uses are quite distinct and serve very different purposes. to aid the reader, i have hacked in The URL's use of the web PKI can not provide authentication of IP address space ownership. It is only used to authenticate a pointer to the geofeed file and transport integrity of the data. In contrast, the RPKI can be used to authenticate IP space ownership; see optional authentication in Section 4. > I'm trying to suss out the requirements that led to this design, and > so far it is not clear to me why two mechanisms are necessary or > desirable given the complexity this implies for clients. ISTM that if > a requirement is made that the geofeed data file MUST be served via > https, and RPKI authenticates the URL, then the web PKI would provide > a sufficient trust anchor for the geofeed data itself without any > additional RPKI signature. Alternatively, if the assumption is that > RPKI is the more appropriate PKI for protecting this information, then > why leverage the web PKI at all? see above > * There appears to be no way to revoke previously-signed geofeed data > except via rotation of the RPKI key pair. Using the web PKI and https > is a countermeasure here by preventing impersonation of the geofeed > host, but it's unclear what utility RPKI provides if web PKI is > required to guarantee geofeed freshness. Metadata imposing a expiry > on geofeed data authenticated by RPKI would serve the same function, > at the cost of requiring the data to be refreshed regularly. validation of the signing certificate needs to ensure that it is part of the current manifest and that the resources are covered by the RPKI certificate. this handles revocation. but, if you want to go down the "how does revocation work in the rpki" rabbit hole, you have to drink the 3779 validation koolaid, and that of the "up-down" protocol, and have a look at manifests. not that i am recommending going down this rabbit hole. > * Is it always the case that RPKI private keys are protected by HSM, > or is that simply a best practice? not at all. but, imiho, we should stay neutral on that. the example 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. was merely a cultural reference to the silos in a large LIR where address space ownership, rpki signing, ... are often in a very separate fiefdom from geo location folk. > Is the assumption that all RPKI changes imply a manual workflow? no. one hopes it will become more and more automated as time passes. we hope the manual workflow will go away. weekly would be a fantastic improvement over the multi-month or forever gap we have now. every week there is a plea on nanog "my customer in gzork is blocked by fooTV who seems to think thay're in gzplatz and won't let them watch sesame street." the two informative references, draft-ietf-sidrops-rpki-rta and draft-spaghetti-sidrops-rpki-rsc, should give you a feeling to where this can go, devops willing. > * Is it actually
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
>> Unless is modified to formally define > [RW] > > My comment was less about what gets written in the documents, and more > about how this update would actually be done in practice. E.g., > updating 8805 to indicate a new section would presumably break any > existing clients expecting to fetch a regular CSV file via the > "geofeed: or "remaks: geofeed" attributes? > > I.e., it seems that either 8805 would have to be updated in backwards > compatible way, and it looks like adding such an appendix wouldn't be > backwards compatible (c.f., RFC 8805 section 7), or all clients would > have to be updated before the publishing format is changed, or it > would need new geofeed attribute names to publish the different > versions of the geofeed data at the same time. > > How wedded are you to that text? Perhaps it would be simpler to just > delete the "Until [RFC8805] is updated to formally define such an > appendix" text and just say that the signature is always predicated by > '#' comments? sorry for not understanding your point. there is no backward compatible way forward for 8805. so i have hacked as you suggest The appendix MUST be 'hidden' as a series of "#" comments at the end of the geofeed file. The following is a cryptographically incorrect, albeit simple example. A correct and full example is in . randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
mornin rob, new diff attached > So, solely for my understanding, if 8805 was updated in an > incompatible way then it would not be 8805. it would not be a geofeed file. so the kiddies then can have fun with a complete do-over and write their own finding-blarffles draft. > This makes me question whether this comment in section 4 is > valid/correct: "Until [RFC8805] is updated to formally define such an > appendix". My understanding is that this couldn't be done without > either breaking clients, or requiring new attribute names? point, how about Unless is modified to formally define >>> 4. I think that INETNUM should be a normative reference, but I also >>> question whether it is going to be a sufficiently stable reference? >>> Hence, I was wondering whether it wouldn't be helpful to describe the >>> essence of the INETNUM hierarchy here to avoid a need for a normative >>> reference. >> >> this is why 2275 and 4012 are normative and the refs to ripe docs are >> informative. > > RFC 2275 doesn't explain the hierarchy of INETNUM entries yup. which is why the informative INETNUM refs were left. > I think that you need to add a couple of sentences to explain the > hierarchy so that you don't need the normative references to RIPE. The Routing Policy Specification Language (RPSL), used by the Regional Internet Registries (RIRs) specifies inetnum: database objects. Each of these objects describes an IP address range and its attributes. The inetnum: objects form a hierarchy ordered on the address space. > I'm happy for you to try and get "utterly awesome (i.e., practical but > slightly complex)" through instead, but if you get push back then > you're on your own ;-) some day i can tell you of jari pushing me to write the AplusP document and then not backing me when the anti-nat vigilantes attacked. >>> I think that it would aid clarity, at a minimum, if it always at least >>> referred to as the "proper geofeed: attribute", but it may better to >>> just refer to it as the "proper geofeed attribute", i.e., to avoid >>> binding the name used in this document to the proposed long term name? >> >> let's see how this goes. the irr folk working on this do not seem to >> be getting creative, at least along this dimension. > > Are they getting creative along other dimensions? Who controls this > definition, and are they okay with the IETF constraining the > definition this way? I.e., is it possible to get the "irr folk" to > agree that they are happy with what is being proposed here? they are. the ripe community is still old school cooperative. of course they have to blah blah about it for a few months; but the end will be what we need. and then the other rirs, excepting arin of course, will follow. warren, massimo, and i are part of the ripe community. not to worry. >> The address range of the signing certificate MUST cover all >> prefixes in the geofeed file it signs; and therefore must be >> covered by the range of the inetnum:. > > This looks plausible to me, but don't have the expertise to know. I > assume that one of the authors will speak up if this is not right. russ has not whacked me. yet. > No need. I don't think that iff is well known enough i think this says a sad bit about computer science and the ietf randy <<< text/html; charset=UTF-8; name="Diff draft-ietf-opsawg-finding-geofeeds-04.txt - draft-ietf-opsawg-finding-geofeeds.txt.html": Unrecognized >>> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
> This I-D already defines a new content type: id-ct-geofeedCSVwithCRLF. clearly without enough words :) > OLD: > >Borrowing detached signatures from [RFC5485], after text file >canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS) >[RFC5652] would be used to create a detached DER encoded signature >which is then BASE64 encoded and line wrapped to 72 or fewer >characters. > > NEW: > >The canonicalization procedure converts the data from its internal >character representation to the UTF-8 [RFC3629] character encoding, >and the sequence MUST be used to denote the end of a >line of text. Trailing space characters MUST NOT appear on a line of >text. That is, the space or tab characters must not be followed by >the sequence. Thus, a blank line is represented solely by >the sequence. Other nonprintable characters, such as >backspace, are not expected. For robustness, any nonprintable >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 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. > >Borrowing detached signatures from [RFC5485], after file >canonicalization, the Cryptographic Message Syntax (CMS) >[RFC5652] would be used to create a detached DER encoded signature >which is then BASE64 encoded and line wrapped to 72 or fewer >characters. done thanks! randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
>>> 3. The definition of canonicalization refers to section 2.2 of RFC >>> 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8. Is >>> this disparity an issue? >> >> russ, how do you want to handle? > > This is really about line endings, but it would probably be best to > assign a content type for UTF8 Test with CRLF. yuchh. send text, if you would please. >> This document also suggests optional data for geofeed files to >>> provide stronger authenticity to the data. >>> >>> Would "optional signature data" be clearer than just "optional data"? >> >> ok. russ? maybe 'authenticating'? > > How about: ... optional signature, which authenticates the data when > present. This document also suggests optional signature, which authenticates the data when present, for geofeed files to provide stronger authenticity to the data. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
hi rob et alia, first, thanks a milion for a real review. really appreciated. > 1. Specifically, I think that it would be useful for this document to > offer more clarity as to whether the "remarks: Geofeed" tag > specifically ties the content of the URL to a document in RFC 8805 > format, or whether other formats may be found at that URL in future, > noting that RFC 8805 section 7 suggests that a future format may be > defined, and end of section 4 of this document also suggests that RFC > 8805 may be updated. If multiple formats, how does the client tell > the difference. see diff. a lot of 8805 refs sprinkled in before the word 'geofeed file' > 2. I wasn't quite sure whether the mechanism for authenticating > geofeed data really belonged in this document (e.g., because it > applies to all possible forms of geofeed data), or whether it would it > is specific to the CSV format described in RFC 8805, and that an > update to that document would contain the canonical reference. ibid > 3. The definition of canonicalization refers to section 2.2 of RFC > 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8. Is > this disparity an issue? russ, how do you want to handle? > 4. I think that INETNUM should be a normative reference, but I also > question whether it is going to be a sufficiently stable reference? > Hence, I was wondering whether it wouldn't be helpful to describe the > essence of the INETNUM hierarchy here to avoid a need for a normative > reference. this is why 2275 and 4012 are normative and the refs to ripe docs are informative. >An optional, but utterly awesome, means for authenticating geofeed >data is also defined. > > I'm guessing that this might be Warren's prose, but it perhaps might > be worth refining 'utterly awesome' to 'practical'? my memory could be off, but i think it was i mocking warren. i can make the change. sense of humor declines in the ietf. > 2. Geofeed Files > >The size of a file can be even larger if an unsigned geofeed file >combines data for many prefixes, as may be likely if the location >data are maintained by a different department than address >management, dual IPv4/IPv6 spaces are represented, etc. > > I'm not disputing this, but I wasn't sure why having different > departments would increase the side of data. yucchy. removed. >This document also suggests optional data for geofeed files to >provide stronger authenticity to the data. > > Would "optional signature data" be clearer than just "optional data"? ok. russ? maybe 'authenticating'? > 3. inetnum: Class > >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. > > Is there any possibility that the proper geofeed attribute won't be > standardized as "geofeed:"? I.e., this document refers to this > attribute as "geofeed:", but the way that it is written it would end > up being very confusing if the "proper geofeed: attribute" was > standardized as "geo-feed:" by referred to as "geofeed:" by this > document. i do not think this problem to be likely. they seem not to be wiggling; and we are codifying the attribute name in this document. > I think that it would aid clarity, at a minimum, if it always at least > referred to as the "proper geofeed: attribute", but it may better to > just refer to it as the "proper geofeed attribute", i.e., to avoid > binding the name used in this document to the proposed long term name? let's see how this goes. the irr folk working on this do not seem to be getting creative, at least along this dimension. >Any particular inetnum: object MUST have at most one geofeed >reference, whether a remarks: or a proper geofeed: attribute when one >is defined. > > Although the draft does not allow a record to contain it, is it worth > specifying what a client should do if it receives a record with both > "remark: Geofeed" and the proper geofeed attribute? E.g., should a > client choose to use one in preference to the other? hacked to say then ignore all >Currently, the registry data published by ARIN is not the same RPSL >as the other registries; therefore, when fetching from ARIN via FTP >[RFC0959], whois [RFC3912], RDAP [RFC7482], or whatever, the >"NetRange" attribute/key must be treated as "inetnum" and the >"Comment" attribute must be treated as "remarks". > > Is there a reason why these are musts are not MUSTs? because it is arin. unpredictable. but i'll upcase. > Otherwise, could change from "must be treated" to "is treated" to > avoid potential ambiguity. imiho, 2119 adds syntax and accompanying semantics; and should not be taken to invalidate the american language. >inetnum: objects form a hierarchy, see [INETNUM] Section 4.2.4.1, >Hierarchy of INETNUM Objects.
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
i have reverted the doc in my emacs buffer. -03 stands randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> But if a lookup process was interested in finding a geofeed for an IP > address within B, would it have any reason or automated means to > backtrack and lookup knowledge of the signed geofeed for A? Do > inetnum lookups return all superprefix inetnums as well? (asking for > a friend) whoops! ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Document Shepherd write-up for draft-ietf-opsawg-finding-geofeeds
> please push the 03. I think it is very likely to close all the low-level Nits. done randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Document Shepherd write-up for draft-ietf-opsawg-finding-geofeeds
thanks ggm for a stunningly thorough shepherd's report. i have an -03 revsion in an emacs buffer addressing your comments which i will publish when you, the wg chairs, or ... tell me to do so. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
-02 was published. but, due to a merge miscommunication, it left off a couple of acknowledgments. it also misspelled Acknowledgments :) i'll not push -03 until after comments of substance are incorproated, assuming no one objects. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> There were some comments that will lead to document changes commenters, please check -02 and thanks all randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
hi job, as ggm said, really appreciate your showing the tech can be done. openssl is conservative, which has good and bad effects. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> Well, "whatever", but I liked the paragraph we had arrived at. ok, ok. i could not stand the whining and put it back :) it's just that i really prefer words to communicate something. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> The signature was produced through proprietary means, but for the > purpose of validating the signature & interopability testing that > shouldn't matter... right? unless you are a security person and lived through trojans such as dual-ec. extension of kerckhoffs's principle. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> Authenticating the Geofeed data > === > > The uncommented section of the file conforms to RFC 8805: > > $ head -1 geofeed.csv | tee geofeed_tbs > 2001:67c:208c::/48,NL,NL-NH,Amsterdam > > The commented out section of the geofeed.csv file contains a base64 > encoded detached CMS signature (DER) using the 'id-ct-geofeedCSVwithCRLF' > content type, a sha256 message digest, and can be verified against a > public CA. The CA can be reached through the RIPE NCC RPKI Trust Anchor > and has 2001:67c:208c::/48 as subordinate resource. > > Extract DER encoded signature: > > $ cat geofeed.csv | sed '1,2d;$d' | base64 -d > signature.der > > Extract the EE certificate (in PEM format) from the CMS envelope: > > $ openssl cms -verify -noverify -in signature.der -inform DER \ > -certsout ee.pem 2>/dev/zero > > Inspect the EE certificate to see which authority signed it: > > $ openssl x509 -in ee.pem -noout -ext sbgp-ipAddrBlock,authorityInfoAccess > sbgp-ipAddrBlock: critical > IPv6: > 2001:67c:208c::/48 > > Authority Information Access: > CA Issuers - > URI:rsync://rpki.ripe.net/repository/DEFAULT/LMq8Kl3LkWGqticaaLl6IAGSsJ4.cer > > A validated RPKI cache on the local filesystem can be constructed using > a utility like OpenBSD's rpki-client (https://www.rpki-client.org). Copy > the CA certificate from the validated cache, and convert it to PEM format: > > $ openssl x509 \ > -in > /var/cache/rpki-client/rpki.ripe.net/repository/DEFAULT/LMq8Kl3LkWGqticaaLl6IAGSsJ4.cer > \ > -inform DER -out ca.pem > > Finally, verify the signature over the Geofeed content against the > authority: > > $ openssl cms -verify -content geofeed_tbs \ > -in signature.der -inform DER -CAfile ca.pem > 2001:67c:208c::/48,NL,NL-NH,Amsterdam > Verification successful > > Conclusion > == > > I believe with the above I've independently implemented all aspects of > draft-ietf-opsawg-finding-geofeeds in one way or another, demonstrating > the described procedures are correct, verifyable, and somewhat > understandable. > > The prefix I used is a real-world example, allowing others to inspect > the referenced inet6num RPSL object, the associated Geofeed file, > including the authentication aspect. Appendix A was very helpful. folk trying to verify this are whining about some missing code randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> 1. I believe it may be more correct to refer to RFC 4012 rather than > 2622 (as inet6num support is declared in this draft) thanks! > 2. paragraph 4, first block, I think it should say "there IS a fair > number of them." > 3. paragraph 5 "The geofeed files SHOULD be published over and fetched > using https". maybe the word https should be capitalized HTTPS? can you cite where i would get good answers to such stuff? the rfced usually cleans them up. > 4. paragraph 6 "If an inetnum: for a wide prefix (e.g. a / 16) points > to an RPKI-signed geofeed file, a customer or attacker could publish a > unsigned". maybe s/a unsigned/an unsigned/ ? yet again > 5. oh, speaking of Iff, I would prefer if and only if, extended. will you not hate me if i leave it and let rfc have one more reason to whack me? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
>> 8805 was, of course, an Independent Stream production. So I carry as much >> responsibility as anyone else for the lack of privacy discussion. But, more >> significantly, I am entirely responsible for not having noted section 4 of >> RFC 8805 when I wrote my email - oops. > > Yeah, I was pretty sure we had written something. =) > > https://www.rfc-editor.org/rfc/rfc8805.html#name-privacy-considerations and i am guilty of not rereading 8805 may i suggest that finding-geofeeds merely say All the privacy considerations of RFC8804 Section 4 apply to this document. saves a lot of words thereby reducing the rfc editor fee. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> So perhaps modifying your paragraph to... > > RFC8805 geofeed data may reveal the approximate location of an IP > address, which might in turn reveal the approximate location of an > individual user. As noted in section 4 of RFC8805, publishers of > geolocation feeds are advised to have fully considered any and all > privacy implications of the disclosure. Further, operators who publish > geolocation information are strongly encouraged to inform affected > users/customers of this fact and of the potential privacy-related > consequences and trade-offs. In publishing pointers to geofeed files > as described in this document the operator should be aware of these > privacy concerns and be cautious. done. thanks. best to ignore the games of flavors of rfcs. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
hey adrian, > Is it too late to ask for some privacy considerations to be added to > this document? it is never too late to ask for privacy. as usual, the problem is how to provide it :) > My initial thought was that the authors would point me to 8805, but a > quick look there doesn’t show any mention of privacy. which is unfortunate. the authors have sworn under oath that they considered it. e.g. they told me that this is why postal codes are not in 8805 geofeed files. they described places such as those isles to the west of europe (on which i think you live) postal codes can locate an individual or extremely small group. > My concern here is that the end-user’s geographic locale is being > exposed to the service provider without the agreement of the end-user, > and without the end-user even knowing that it is happening. i think we all share the concern that an end-user's locale might be revealed. and i suspect at least you and i pretty much agree on the core issues. but ... tl;dr: that is an 8805 problem, water under someone else's bridge unnecessary and pedantic details: o in pretty much all cases i know, the user's locale is known by their service provider. the issue would seem to be the provider's revealing the user's locale to the public, which includes other providers. o my understanding is that 8805 was developed specifically to provide a mechanism for the user's provider to publish the user's locale to other providers, with the major goal being content customization. o whether we believe that content should be customized by locale, while an interesting discussion, is probably best held in another locale. o luckily, the folk who want to customize content by locale seem happy with fairly low resolution. o though clearly agencies such as law enforcement and my mother, would love one's precise locale at all times; i do not think they were the intended customer for 8805, and they are definitely not the intended customer for this draft. > I know that this information has great value for a number of aspects > of service provision (not least geographic licensing), and I am not > opposed to its availability. I do object, however, to the concept that > a user’s locale is generally available. A user should have the option > of not revealing their locale (in the knowledge that this may exclude > them from accessing some services). let's remember that even 8805 does not directly reveal the location of users. it reveals low resolution location of ip address spaces. but of course we know ip addresses can be attributed to users. > Now, I doubt that this document is the right place to fix these > privacy concerns. But it might be a good place to add a short > paragraph on the privacy issues raised by using geo feeds. to paraphrase the immortal words of vince perriello, send text :) but, as a first idea, how about something such as this in the Geofeed Files section? RFC8805 geofeed data may reveal the approximate location of an IP address, which might in turn reveal the approximate location of an individual user. Unfortunately, RFC8805 provides no privacy guidance on avoiding or ameliorating possible damage due to this exposure of the user. In publishing pointers to geofeed files as described in this document the operator should be aware of this exposure in geofeed data and be cautious. sad to say, i can not think of more useful guidance than caution. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> I have requested additional directorate reviews for this work so we > have a good amount of eyes on it. thank you! randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
i am not aware of ipr randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Conslusion//RE: CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds
thanks someone should remind me to publish when The I-D submission tool will be reopened after 2020-11-14 23:59 +07 (IETF-meeting local time). randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds
> I'm lost as to why you don't just do the appropriate IANA action to > register "geofeed". Well, okay I looked it up, and maybe it's a > challenge. > > RFC2622 section 10.2 says: >New attributes can be added to any class. To ensure full >compatibility, new attributes should not contradict the semantics of >the objects they are attached to. Any tool that uses the IRR should >be designed so that it ignores attributes that it doesn't understand. >Most existing tools adhere to this design principle. > > And neither RFC2622 nor RFC4012 have an IANA Considerations. > > I'm not sure what this means in the end, but it seems that your > document can just define geofeed: and Update RFC2622. Maybe some AD > will want you to create a registry, but cross that bridge when you get > to it. > > Maybe Warren will comment. > > The Remark: hack reminds me of COBOL or JCL, and I gotta wonder if > it's necessary. Are the ARIN and/or RIPE and... databases really so > ossified that you need this hack? welcome to the realities of network operations, five registries who have social issues, an ietf rps wg that was moribund, ... if you really care, i perhaps someone with more social skills than i can explain it all to meet your interest. but trust me, the remarks: finesse is needed, and the doc and massimo's hack [geofeed-finder], are set to handle a transition should it happen. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds
> When I read that, I assumed that such an attribute would be out of > scope of this document and that would be a target of future work to > happen in RIPE (perhaps?). yep > If this draft is intended to ALSO propose that, I would clearly > describe the intended geofeed: attribute with examples and any > additional links to work in RIPE. how about 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 MUST be as in this example, "remarks: Geofeed " followed by a URL which will vary. inetnum: 192.0.2.0/24 # example remarks: Geofeed https://example.com/geofeed.csv While we leave global agreement of RPSL modification to the relevant parties, we suggest that a proper geofeed: attribute in the inetnum: class be simply "geofeed: " followed by a URL which will vary. inetnum: 192.0.2.0/24 # example geofeed: https://example.com/geofeed.csv Any particular inetnum: object MAY have, at most, one geofeed reference, whether a remark: or a proper geofeed: attribute when one is defined. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds
> Just the snark :-). >>> I do think the “awesome” authentication bit might need to come out >>> before ultimate publication, though. >> just the snark, or are you saying the whole auth? we can negotiate btw, the draft is intended to document and prefer a new geofeed: attribute, not just the interim remarks: hack. e.g. 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. would you suggest stronger wording? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds
> I do think the “awesome” authentication bit might need to come out > before ultimate publication, though. just the snark, or are you saying the whole auth? randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Feedback on draft-ymbk-opsawg-finding-geofeeds-03
> I'd like to provide some feedback on > draft-ymbk-opsawg-finding-geofeeds-03 in relation to RDAP. The current > draft makes reference in passing to RDAP, and the remarks: RPSL > attribute will fit into the RFC7483 Section 5.4 IP network object > class, however the proposed geofeed: attribute has no such mapping in > RDAP. > > I would like to suggest that this draft amend RFC7483 to add "geofeed" > as a possible member of the IP network object, with the same format > and to be treated the same as the RPSL attribute. we intentionally do not attempt to change RPSL or RDAP; though we do suggest how to change RPSL and could do the same for RDAP. we felt it would best be left to those who own those protocols to maintain them. of course we could be wrong in this. let's discuss when we push -04 and it is a wg document. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Fwd: New Version Notification for draft-ymbk-opsawg-finding-geofeeds-03.txt
a bit more rationale arin and lacnic have different attribute names mention whois and rdap transports mention rfc7909 have proper oid advise throttling, and specify fetches no more frequently than weekly --- A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-03.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-opsawg-finding-geofeeds Revision: 03 Title: Finding and Using Geofeed Data Document date: 2020-09-15 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-03.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds Htmlized: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-03 Abstract: This document describes how to find and authenticate geofeed data. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Error discovered during AUTH48 processing of draft-ietf-opsawg-tacacs
> Original: >As this information is not always subject to verification, it is >recommended that this field is in policy evaluation. > > We are planning on replacing it with: > Updated: >As this information is not always subject to verification, it MUST NOT be >used in policy evaluation.: puhleeze ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Finding and Using Geofeed Data
> But “UTC” is more canonical than UCT. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Finding and Using Geofeed Data
> FWIW, we tried to have some HTTP header discussion in 8805: > https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information An entity fetching geofeed data using these mechanisms MUST NOT do frequent real-time look-ups to prevent load on RPSL and geofeed servers. Section 3.4 suggests use of the HTTP Expires Cacheing Header to signal when geofeed data should be refetched. As the data change very infrequently, in the absense of such an HTTP Header signal, collectors MUST NOT fetch more frequently than weekly. It would be wise not to fetch at magic times such as midnight UCT, the first of the month, etc., because too many others are likely to do the same. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Finding and Using Geofeed Data
> I just reviewed rev -02. Other than noticing two ’s’ in “objects” > in section 5, I didn’t notice any other issues. thanks for taking a pass. objectss corrected, plus a other thinks erik kline pointed out. we'll push -03 when there have been changes of substance. > One thing that did stick out to me, though (and I don’t know how to > solve it) is when you talk about update frequency in section 5. Okay, > don’t do frequent polls and don’t poll at midnight. However, in the > case of something like the IETF conference network, how would > consumers know that this GeoFeed data _is_ likely to change and at a > certain periodicity? The GeoFeed format doesn’t have any parsable way > to reflect that. I don’t know if RPSL does. Perhaps the remark: > could offer some clue as to when one might want to come and retaste? i have recently become overly sensitive to this. i have turned off rrdp on my rpki CAs because of a DDoS by abusive pollers. and i may be driven to just turn off rpki entirely. i see at least three pieces to the problem o what is a reasonable frequency? imiho, things change very infrequently. the ietf meeting network should be happy with a weekly poll. but, as ggm might say, there is a discussion to be had here. o could there be a signal on the server side, e.g. an expiry or suggested poll frequency in the geofeeds file or in the pointer in the rpsl? for example, massimo is looking at html tags. o given the rpki DDoS, will implementors even follow guidelines in an RFC? if we assume not, then we probably should also specify a damping mechanism on the service side. there is a reason rpsl servers are strongly damped. welcome to the tragedy of the commons. folk might have other thoughts. again, thanks for reading! randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Finding and Using Geofeed Data
>> Identifying the private key associated with the certificate, and >> getting the department with the HSM to sign the CMS blob is left as >> an exercise for the implementor. > > This cynical comment jumped out at me. > It seems that you don't have a lot of confidence that the key will be > easily used. actually, i am hoping that ggm et alia will revive draft-michaelson-rpki-rta until then, i am personally not all that concerned about signing. as folk start to actually follow this path (and massimo is keeping a list of those who are), after a while folk may care enough about authenticity to go through the effort of signing geofeeds. but we felt it incumbent on us to specify how to do so. > As I understand it, you are not creating the geofeed: attribute, but > instead shoving a URL into a "remark". one thing at a time. the ietf gave up on specifying rpsl a couple of decades ago. a first task i was given as a new ops area director was to shoot the rps wg. so we are not attempting to modify rpsl, though we do suggest how it might be done. > I don't see an IANA Considerations in RFC2622... so many you have to > Updates? let's you and them fight :) > I gather from my quick reading that the geofeed data should be signed > by the same RPKI key, and that such keys are rather high value. > Should they be signing geofeed data? got any other congruent authoritative keys? > I understand RFC8805 to be a simple CSV format. > One thought I have is to just stuff that into the "remark" directly. scale issues. as i just said on nanog for some flat fan out last kilometer providers that could be the inetnum: object from hell. there are global providers which segment large prefixes over diverse areas. etc. i doubt the rpsl providers would like multi-megabyte inetnum:s. rpsl providers already throttle in defense. > I think that each inetnum:/inet6num: entry will be unique per prefix. > Maybe the geography is not 1:1, particularly with larger IPv6 > allocations. it isn't even for ipv4 > But, if the HTTP(S) indirection via URL requires a signature from the > same key as the RPSL signature there is no such thing as an rpsl signature. and i sure as bleep ain't gonna propose one. > then why not just put a SHA256 hash into the remark, eliminating the > need to find the private key? That way, the same person with access > signs both? because, as the draft tries to politely say Unfortunately the RPSL in many repositories is weakly authenticated at best. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Finding and Using Geofeed Data
thanks for review! proposed diff attached. > If the comments change, the signature changes? yep. otherwise vast complexity lurks. but is there a text change you want? i may be naïve expecting that "a digest of the main body of the file" is sufficient. > [a] the source of the geofeed claims is authoritative to make said > claims for the contained prefixes, and iff you trust the rpki crypto chain > [b] the correctness of the claims themselves (i.e. that the location of > 2001:db8::/32 really is "Shire, Middle Earth"). above my pay grade do you have suggested text? > The text from section 4 provides a suggestion: perhaps replace > "authenticate" with "verify the authority of", or some such > formulation? h. hacked a bit. > [ section 1 ] > > * Probably the intro should hint at the authentication awesomeness contained > within. I think, actually, the last paragraph of section 2 can just be > relocated to the end of this section and it will flow well. ok > [[ nits ]] thanks! randy <<< text/html; charset=UTF-8; name="Diff draft-ymbk-opsawg-finding-geofeeds.txt - draft-ymbk-opsawg-finding-geofeeds.txt.html": Unrecognized >>> ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
