Re: [Last-Call] [secdir] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06

[Warren Kumari <warren@xxxxxxxxxx>]

[ 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 <krose@xxxxxxxxx> wrote:

On Wed, May 5, 2021 at 10:49 AM Randy Bush <randy@xxxxxxx> 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

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call