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] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
On Thu, Apr 29, 2021 at 3:56 PM Randy Bush wrote: > > 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. :) > My point is simply that you should aim to submit the document in a form as close as possible to immediately publishable. Language that you and I and everyone else knows a priori is unsuitable for publication should get changed before submission. No reason to add busywork to the RFC editor's queue. > > 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. > I've simply observed it as a best practice to compartmentalize that kind of analysis in a place that readers expect, rather than sprinkling it throughout normative parts of the document. > > 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. Understood. I'm not suggesting the web PKI be used to authenticate IP address space ownership. I'm suggesting that the following chain would be sufficient: * RPKI authenticates the routing information, which includes the IP address space and the https URLs for each geofeed file. * Web PKI authenticates the data served at that URL. * Client verifies that the IP ranges in the geofeed data are contained within the (RPKI-authenticated) routing information. I.e., you are chaining trust from the RPKI explicitly to the (https) URL, and implicitly to the data served from that URL. The web PKI is used only to ensure that the data is not modified in transit. It is not used to authorize IP address space ownership: regardless of the PKI used to authenticate the geofeed data, the client still needs to cross-check the IP ranges in the geofeed data against the ownership in the RPKI-authenticated routing information. > it is only used to authenticate a *pointer* to the geofeed file. On the contrary, the pointer (i.e., the octet sequence making up the URL) is authenticated by RPKI in all cases. You're basically saying "Trust the data returned by the server at this URL." Which is a closed authentication chain if that URL is https by virtue of the corollary "Trust the web PKI to authenticate this server." > 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:). Thanks for illustrating why the security area reviews all documents prior to publication, and why the security directorate exists: because protocol security properties are often subtle and not reducible to a checklist. > > * 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. > I did a bit of digging, and it looks like RPKI does have revocation at the certificate level, so there is at least a (potentially costly) path to doing this. > > * 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
