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

From: Kyle Rose <[email-masked]>
Date: Mon, 3 May 2021 10:27:49 -0400

On Thu, Apr 29, 2021 at 3:56 PM Randy Bush <[email-masked]> 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 ownership, rpki signing, ... are often in a very separate
> fiefdom from geo location folk.
>

I feel like this statement can be made in an implementation-neutral way,
like "Signing workflows will vary and are out of scope for this document."

> >  * Why does the geofeed appendix not accommodate multiple signatures
> >  for distinct address ranges? The requirement that a geofeed file not
> >  be RPKI-signed in order to be shared by multiple INETNUM objects
> >  could be relieved were multiple signatures allowed.
>
> do we really want to start work on RFC5485-bis?  but maybe russ has
> better thoughts on this than i.
>

If signatures were detached, it would be trivial to have multiple. But that
would complicate authentication for resources that are not immutable (e.g.,
inconsistent geofeed and signature files, something quite likely to happen
with cacheable artifacts). So I wouldn't recommend that approach anyway. I
guess my recommendation to simplify this would be twofold:

 * Mandate RPKI for routing information, including the geofeed data URLs
(i.e., the sequence of octets that represents a URL).
 * Mandate the use of https (and therefore web PKI) for geofeed data (i.e.,
all URLs must be https://...)

This eliminates the need for the complexity of RPKI signatures in geofeed
data while ultimately rooting that information in an RPKI trust anchor.
Kyle

---

From: Kyle Rose <[email-masked]>
Date: Mon, 3 May 2021 10:47:30 -0400

On Mon, May 3, 2021 at 10:40 AM Russ Housley <[email-masked]> 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'm obviously not aware of the potential operational complications of doing
so, as I don't work in this area. There may be good reasons why this is
impractical. The tradeoff, however, is a more complex client ecosystem,
which must accommodate two authentication methods instead of one.

Kyle

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 10:40:08 -0400

Kyle:

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

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

My point is that there is no chaining of trust.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 11:28:21 -0400

> On May 3, 2021, at 10:47 AM, Kyle Rose <[email-masked]> wrote:
> 
> On Mon, May 3, 2021 at 10:40 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 

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

---

From: Kyle Rose <[email-masked]>
Date: Mon, 3 May 2021 11:44:11 -0400

On Mon, May 3, 2021, 11:28 AM Russ Housley <[email-masked]> wrote:

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 3 May 2021 12:05:39 -0400

> On May 3, 2021, at 11:44 AM, Kyle Rose <[email-masked]> wrote:
> 
> On Mon, May 3, 2021, 11:28 AM Russ Housley <[email-masked] <mailto:[email-masked]>> 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.

Russ

---

From: Randy Bush <[email-masked]>
Date: Mon, 03 May 2021 10:09:54 -0700

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/

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 May 2021 15:11:30 -0700

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 <[email-masked]>
Subject: Re: [db-wg] New NWI for geofeed?
To: denis walker <[email-masked]>
Cc: Database WG <[email-masked]>
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 <[email-masked]> 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
> process itself, not the subsequent actual use of IP addresses after
> assignment.
> 
> The working group is asked to consider whether the RIPE Database can
> be used as a springboard for parties wishing to correlate geographical
> information with IP addresses by allowing structured references in the
> RIPE Database towards information outside the RIPE Database which
> potentially helps answer Geo IP Location queries
> 
> The IETF is currently discussing an update to RPSL to add a new
> attribute "geofeed: url". The url will reference a csv file containing
> location data. Some users have already started to make use of this
> feature via the "remarks: geofeed: url". It is never a good idea to
> try to overload structured data into the free format "remarks:"
> attribute. This has been done in the past, for example with abuse
> contact details before we introduced the "abuse-c:" attribute. There
> is no way to regulate what database users put into "remarks:"
> attributes. So even if the new "geofeed:" attribute is not agreed, the
> url data will still be included in the RIPE Database.
> 
> Currently there are 24,408 INETNUM and 516,354 INET6NUM objects
> containing a "geoloc" attribute in the database. These have 7,731
> distinct values in the INETNUMs and 1,045 distinct values in the
> INET6NUMs. There are about 150 objects in the RIPE Database with a
> "remarks: geoloc url" attribute.
>

---

From: Kyle Rose <[email-masked]>
Date: Wed, 5 May 2021 07:58:29 -0400

On Mon, May 3, 2021 at 12:05 PM Russ Housley <[email-masked]> wrote:

> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 May 2021 07:38:43 -0700

> 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

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 May 2021 07:49:11 -0700

> web pki is based on control of domain name space.  the two are quite

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

---

From: Kyle Rose <[email-masked]>
Date: Wed, 5 May 2021 10:50:55 -0400

>    draft-spaghetti-sidrops-rpki-rsc-03

Noted.

> web pki is based on control of domain name space.  the two are quite

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

---

From: Kyle Rose <[email-masked]>
Date: Wed, 5 May 2021 10:53:57 -0400

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

> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 May 2021 08:32:28 -0700

[ 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

---

From: Robert Kisteleki <[email-masked]>
Date: Thu, 6 May 2021 09:33:30 +0200

> covered by it for those concerned with real authenticity.

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

Robert

---

From: Warren Kumari <[email-masked]>
Date: Thu, 6 May 2021 15:05:11 -0400

[ 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

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra