hi kyle:
thanks a million for the review. we have a suply chain problem getting
solid reviews these days.
> 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. :)
> 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.
> 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. it is
only used to authenticate a *pointer* to the geofeed file. 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:). And the us of TLS will ensure that the file
comes from the intended source and it comes without modification.
for example, was i to put my geofeed file in gobble docs, the web pki
would be gobble's cert chain, not mine, the IP space owner.
one can optionally authenticate the geofeed data themselves by using the
rpki to sign over them. and, unlike the web pki, the rpki does provide
authority over IP address space ownership.
so these two pki uses are quite distinct and serve very different
purposes.
to aid the reader, i have hacked in
The URL's use of the web PKI can not provide authentication of IP
address space ownership. It is only used to authenticate a pointer
to the geofeed file and transport integrity of the data. In
contrast, the RPKI can be used to authenticate IP space ownership;
see optional authentication in Section 4.
> I'm trying to suss out the requirements that led to this design, and
> so far it is not clear to me why two mechanisms are necessary or
> desirable given the complexity this implies for clients. ISTM that if
> a requirement is made that the geofeed data file MUST be served via
> https, and RPKI authenticates the URL, then the web PKI would provide
> a sufficient trust anchor for the geofeed data itself without any
> additional RPKI signature. Alternatively, if the assumption is that
> RPKI is the more appropriate PKI for protecting this information, then
> why leverage the web PKI at all?
see above
> * 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.
> * 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.
> Is the assumption that all RPKI changes imply a manual workflow?
no. one hopes it will become more and more automated as time passes.
we hope the manual workflow will go away. weekly would be a fantastic
improvement over the multi-month or forever gap we have now. every week
there is a plea on nanog "my customer in gzork is blocked by fooTV who
seems to think thay're in gzplatz and won't let them watch sesame
street."
the two informative references, draft-ietf-sidrops-rpki-rta and
draft-spaghetti-sidrops-rpki-rsc, should give you a feeling to where
this can go, devops willing.
> * Is it actually the case that "the data change very infrequently"?
> Is there no legitimate use case for rapidly changing geofeed
> information, e.g., for overlay networks providing IP mobility? 'At
> most weekly' seems arbitrary. This also has implications for the
> choice of PKI, if manual workflows are indeed required for RPKI
> signing.
hmmmm. on the one hand, UpTightInternetTV really just wants to know
geoloc of cable customers; and today this takes weeks, months, or never.
on the other hand, i can see ietf folk wondering about extensibility and
future uses. on the third hand, do we really want to wrap ourselves
around the axle of geolocating LEO satellites?
but the bit you quote is in advice to the entity *fetching* geofeed
data. if they are trying to geolocate LEO satellites which wish to
be geolocated with high time resolution, they should use the cache
headers. Note that it does say
Section 3.4 suggests use of the [RFC7234] HTTP Expires Caching
Header to signal when geofeed data should be refetched. As the data
change very infrequently, in the absence of such an HTTP Header
signal, collectors MUST NOT fetch more frequently than weekly.
the ops style hack we would use is to change the
collectors MUST NOT fetch more frequently
to
collectors SHOULD NOT fetch more frequently
> * 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.
unless told otherwise, i'll hold -07 for a few more reviews.
again, thanks.
randy
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
