[ Top-post ] Hi there all,
I must admit that I've managed to lose the plot here -- I've read, and reread the threads, and am confused/think people may be talking past each other (or that I'm just not understanding...) I'm trying to understand what the actual issue / confusion is; perhaps a concrete example will help. One of the IETF meeting network ranges is 31.130.224.0/20. This network moves to wherever the IETF meeting is, and so we publish a geofeeds format file: $ whois 31.130.224.0 % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.ripe.net inetnum: 31.0.0.0 - 31.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2010-05 source: IANA # whois.ripe.net inetnum: 31.130.224.0 - 31.130.239.255 netname: ietf-meeting-network descr: IETF Meeting Network country: CH org: ORG-IS136-RIPE admin-c: IED11-RIPE tech-c: IETF-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-by: IETF-MNT mnt-by: netnod-mnt mnt-routes: ietf-mnt mnt-domains: ietf-mnt created: 2011-05-10T10:10:10Z last-modified: 2020-11-16T17:48:30Z source: RIPE # Filtered remarks: Geofeed https://noc.ietf.org/geo/google.csv sponsoring-org: ORG-NIE1-RIPE ... The geofeed file is served from the machine called 'noc.ietf.org', which happens to be hosted in a rack in Dallas, using some unrelated IP space provided by Randy (198.180.152.0/24). When the IETF meeting finishes, one of the NOC people logs in and updates the content of the file to list the next meeting location (so that the geo-providers will update their locations). Note that whoever does this likely doesn't have easy access to the RPKI keys - it's quite common for different sets of people to be publishing/updating the geo info than the routing security people. Geolocation providers can get the IRR information, and follow the URL to grab the file. Note that the URL is hosted on completely different IP space, and the cert is whatever the cert for that machine happens to be. This could be hosted on any name/any address/etc. We specify HTTPS (instead of HTTP) because it's best practice, not because of any sort of correlation, etc. I'm unclear if I'm missing something, or if people are talking past each other, or what. W On Wed, May 5, 2021 at 10:54 AM Kyle Rose <kr...@krose.org> wrote: > On Wed, May 5, 2021 at 10:49 AM Randy Bush <ra...@psg.com> wrote: > >> > 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. >> > > Okay, now we're getting somewhere. Do you say this because RPKI is not > employed universally, or because the inetnum: objects are somehow not > covered by RPKI? > > >> hence the hack to use the well-authenticated rpki to sign those data >> covered by it for those concerned with real authenticity. >> > > How does a client know that an IP range specified in the geodata feed is > valid under a given RPKI signature? I.e., that the given AS has authority > over that IP range? > > Kyle > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
