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

[Warren Kumari]

[ 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  wrote:

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

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

[Robert Kisteleki]

On 2021-05-05 16:49, Randy Bush 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.

hence the hack to use the well-authenticated rpki to sign those data
covered by it for those concerned with real authenticity.

randy


(somewhat shameless plug) there is https://tools.ietf.org/html/rfc7909 
that could be of assistance here.


Robert

___
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

[Randy Bush]

[ 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

[Kyle Rose]

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

[Kyle Rose]

On Wed, May 5, 2021 at 10:38 AM Randy Bush  wrote:

> > 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.
>

Noted.

> > 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.
>

I still don't understand how this is relevant. I'm not asserting otherwise,
and never have been. Let me try again: what are you suggesting would be
basing its trust of geofeed IP ranges on the web PKI? Aren't the valid
ranges for an AS specified in the RPKI-protected routing data feed (where
RPKI is available)?
Kyle
___
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

[Randy Bush]

> 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

[Randy Bush]

> 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] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06

[Kyle Rose]

On Mon, May 3, 2021 at 12:05 PM Russ Housley  wrote:

> Explain how an attacker could get a client to accept a forged geofeed data
> file authenticated as I have suggested, because I'm not seeing it.
>
>
> We are not understanding each other.  The RPKI signature will prevent the
> relying party from accepting a modified file, regardless of the means used
> to fetch it.  For this reason, there is no need think about the interaction
> of the RPKI and the WebPKI.  No dependency is being created.
>

I believe I understand entirely what you're saying. And I do not disagree
with your conclusion. In the case of RPKI-signed geofeed data files, using
https is unnecessary for integrity because the RPKI trust chain is
authoritative for the response body and is sufficient to establish its
authenticity. The only reason I can think of to require https for
presumed-public geofeed data is if the mere fact of fetching it reveals
something about the behavior of individual end users; this is true if CPE
were to fetch the data, for instance, rather than the geo-authorization
logic at the provider. If so, I think it worthwhile to explain this in the
privacy considerations section.

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?
I.e., the hybrid case I alluded to, in which the routing data feed is
protected (along with the geofeed URL) but the geofeeds themselves are not
signed? 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.

Kyle
___
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

[Russ Housley]

> On May 3, 2021, at 11:44 AM, Kyle Rose  wrote:
> 
> On Mon, May 3, 2021, 11:28 AM Russ Housley  > wrote:
>> This is not quite right.  It is true that theWebPKI provide authentication 
>> and integrity when https:// is used, but this is not required.  If http:// 
>> were used, and the file was modified in transit by an attacker, the RPKI 
>> signature check would fail.
>> 
>> Yes. Which is why I'm suggesting that you mandate https.
> 
> I do not have a problem mandating the use of https:// for authentication and 
> integrity protection of the file.  I think that is shown in the examples.  I 
> am saying that doing so does not "chain" the trust models.
> 
> Explain how an attacker could get a client to accept a forged geofeed data 
> file authenticated as I have suggested, because I'm not seeing it.

We are not understanding each other.  The RPKI signature will prevent the 
relying party from accepting a modified file, regardless of the means used to 
fetch it.  For this reason, there is no need think about the interaction of the 
RPKI and the WebPKI.  No dependency is being created.

Russ

___
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

[Kyle Rose]

On Mon, May 3, 2021, 11:28 AM Russ Housley  wrote:

> This is not quite right.  It is true that theWebPKI provide authentication
>> and integrity when https:// is used, but this is not required.  If
>> http:// were used, and the file was modified in transit by an attacker,
>> the RPKI signature check would fail.
>>
>
> Yes. Which is why I'm suggesting that you mandate https.
>
>
> I do not have a problem mandating the use of https:// for authentication
> and integrity protection of the file.  I think that is shown in the
> examples.  I am saying that doing so does not "chain" the trust models.
>

Explain how an attacker could get a client to accept a forged geofeed data
file authenticated as I have suggested, because I'm not seeing it.

Kyle
___
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

[Russ Housley]

> On May 3, 2021, at 10:47 AM, Kyle Rose  wrote:
> 
> On Mon, May 3, 2021 at 10:40 AM Russ Housley  > wrote:
> 
>> 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.
> 
> This is not quite right.  It is true that theWebPKI provide authentication 
> and integrity when https:// is used, but this is not required.  If http:// 
> were used, and the file was modified in transit by an attacker, the RPKI 
> signature check would fail.
> 
> Yes. Which is why I'm suggesting that you mandate https.

I do not have a problem mandating the use of https:// for authentication and 
integrity protection of the file.  I think that is shown in the examples.  I am 
saying that doing so does not "chain" the trust models.

Russ

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg