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

[Warren Kumari <[e-mail]>]

[ 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 <[e-mail]> wrote:

> On Wed, May 5, 2021 at 10:49 AM Randy Bush <[e-mail]> 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