Skip to main content

Last Call Review of draft-ietf-opsawg-finding-geofeeds-06
review-ietf-opsawg-finding-geofeeds-06-secdir-lc-rose-2021-04-29-00

Request Review of draft-ietf-opsawg-finding-geofeeds
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-05-04
Requested 2021-04-20
Authors Randy Bush , Massimo Candela , Warren "Ace" Kumari , Russ Housley
I-D last updated 2021-04-29
Completed reviews Intdir Last Call review of -08 by Jean-Michel Combes (diff)
Rtgdir Last Call review of -02 by Matthew Bocci (diff)
Secdir Last Call review of -06 by Kyle Rose (diff)
Genart Last Call review of -06 by Paul Kyzivat (diff)
Intdir Telechat review of -10 by Wassim Haddad (diff)
Assignment Reviewer Kyle Rose
State Completed
Request Last Call review on draft-ietf-opsawg-finding-geofeeds by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/DdjJ1lMFJSMfOGTkJUsZv6R7TrM
Reviewed revision 06 (document currently at 17)
Result Has issues
Completed 2021-04-29
review-ietf-opsawg-finding-geofeeds-06-secdir-lc-rose-2021-04-29-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document Has Issues.

== Nits

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"

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.

== Unclear requirements

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.

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?

Moreover, even if the flexibility offered by two mechanisms is found to be
desirable, there is no explicit recommendation that an LIR use one mechanism
exclusively for a given geofeed.

== Security gaps

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

== Other questions

 * Is it always the case that RPKI private keys are protected by HSM, or is
 that simply a best practice? Is the assumption that all RPKI changes imply a
 manual workflow?

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

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