Use Cases for Localized Versions of the RPKI
draft-ietf-sidrops-lta-use-cases-06

Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Alissa Cooper Discuss

Discuss (2019-05-01)
I do not believe we should publish this document with the term "socially acceptable data," because it endorses others' determinations of what is socially acceptable in a blanket fashion. I would recommend "other resources."
Comment (2019-05-01)
I support the DISCUSS ballots of Roman and Mirja and Benjamin's first three DISCUSS points.

Roman Danyliw Discuss

Discuss (2019-05-01)
I had a few questions about use case #3.

(1) I want to discuss what I see as a dissonance between use case #3 (Section 4, “Alice is responsible for the trusted routing for a large organization …”) and the Security Considerations.  It appears that use case #3 is explicitly describing an on-path attack per RFC3552.  Is use case #3 a use case or an attack against RPKI?

There seems to me to be an analog between use case #3 and the TLS/web MitM discussions where the consensus was not to standardize these features despite their existence.  In what way do you see RPKI as different?

(2) Thanks for the additional background in in [1].  More to clarity along the lines of Mirja’s DISCUSS, I’m trying to unpack the use case #3 text in Section 4.  

Original Text: “Alice is responsible for the trusted routing for a large organization, commercial or geo-political, in which management requests to redirect their competitors' prefixes to socially acceptable data.”

If Alice is “(us|china|uk|justabouteverybody)” per [1], who is the “management” in the context of a government? Furthermore, “competitor’s” is confusing to me because it seems odd to characterize the networks of objectionable content as competitors to other governments.  I would have read this text as “Alice is a network operator who has been directed to inspect and redirect select prefixes to …”.  

[1] https://mailarchive.ietf.org/arch/msg/sidrops/qGulOfrDPxXgMC9HLJWpXYeBOi4
Comment (2019-05-01)
A few editorial nits:

(1) Section 3.  Editorial Nit.

s/There are critical uses of the RPKI where a local administrative and/or routing domain, e.g. an end-user site, a particular ISP or content provider, an organization, a geo-political region, ... may wish to have a specialized view of the RPK./

There are critical uses of the RPKI where a local administrative and/or routing domain (e.g., an end-user site, a particular ISP or content provider, an organization, a geo-political region) may wish to have a specialized view of the RPK./

(2) Section 4.  Editorial Nit.
s/(LIR, PI holder, …)/(e.g., LIR, PI holder)/

Benjamin Kaduk Discuss

Discuss (2019-05-01)
I have strong misgivings about publishing this document in its current
form.  The review comment on its predecessor in sidr, "it is written like
af able, not an RFC" really sticks with me, and while the style plays a
role in my misgivings, I think there are some substantive concerns in play
as well.

I agree with Roman that there is strong qualitative overlap with situations
like TLS MiTM, akin to a violation of the end-to-end principle.  I also
agree with Mirja that "re-routing to acceptable content" is questionable,
and smacks of endorsing censorship.  (And yes, I know that one person's
censorship is another's parental controls.)

My main concern, though, seems to be that this document presents a narrow
slice of a broad issue, and does not lay clear the technical facts of the
broader situation.  Specifically, it lays out some examples where some
parties may believe that it is desired to inject additional local
information into a local view of the RPKI (or, roughly equivalently, to
suppress such information).  There are important details about what the two
"local"s mean, who is authorized to impose such additional information,
etc., but I think it is possible to write a useful document that does not
reach a clearn answer on any of those questions.  To be useful, though, we
need to consider the consequences of having the capability to perform such
local injection.  There is new attack surface that must be protected from
network attack, and a need for permissions/consent (contractual or
otherwise) for the systems that are affected by the local view of the RPKI
to trust the party/parties that are injecting the local view.  Furthermore,
there is a sizeable chance that the technical solutions to resolve these
use cases will be technically unconstrained, allowing for the "local view"
to fully override any and all of the RPKI, so the risk of granting such
consent is potentially quite sizeable.

I'm also a little concerned about the level of review that this document
received; the responsible AD had to send it back to the WG once due to lack
of evidence for consensus
(https://mailarchive.ietf.org/arch/msg/sidrops/5IBDpQZdsqJeYrxIsSI37c8QxRw),
and I did not see a great deal of additional feedback after that.  (Perhaps
I was looking in the wrong place?)
Comment (2019-05-01)
Abstract

The phrasing "needs to" is very strong and implies that there is an
absolute judgment that can be made as to the validity of the operation,
when my impression is that the topic remains rather controversial.  The
wording "will want to" used in the Introduction seems to be more accurate.
(The word "critical" in "critical circumstances", present in both Abstract
and Introduction, is also prone to criticisms of hyperbolism.)

Section 1

   This document attempts to lay out a few of those use cases.  It is
   not intended to be authoritative, complete, or to become a standard.
   It is informative laying out a few critical examples to help frame
   the issues.

I appreciate that this document does not intend to be authoritative or
complete.  But to say that it is "help[ing] frame the issues" borders on
irresponsible -- it presents *a* framing in which these use cases are cast
favorably, but (per the Discuss point) does not include in that framing
some significant points that cause the use cases to be cast less favorably.

Section 4

   Carol, a resource holder (Local Internet Registry (LIR), Provider
   Independent address space (PI) holder, ...), operates outside of the
   country in which her Regional Internet Registry (RIR) is based.

Is "legal jurisdiction" more on topic than "country", for the purposes of
this example?

   Someone convinces the RIR's local court to force the RIR to remove or
   modify some or all of Carol's certificates, ROAs, etc. or the
   resources they represent, and the operational community wants to
   retain the ability to route to Carol's network(s).  [...]

It seems unlikely to me that this is a matter on which the operational
community would achieve full consensus.  Perhaps "a subset of" is
appropriate?

   Alice is responsible for the trusted routing for a large
   organization, commercial or geo-political, in which management
   requests routing engineering to redirect their competitors' prefixes
   to socially acceptable data.  [...]

Both "competitors' prefixes" and "socially acceptable" have been mentioned
already as potentially problematic phrasing, IIRC, but I will mention them
again.  (Also, I don't really understand what "geo-political
organization" is intended to mean, but maybe that's just as well.)

Section 5

   One wants to reproduce only as much of the Global RPKI as needed.
   Replicating more than is needed would amplify tracking and
   maintenance.

The text would probably benefit from a bit more about what is being tracked
and by whom.  (I assume it is not users being tracked by a surveilance
state, though I can't quite exclude that possibility given just the text
at hand.)

   One can not reissue down from the root trust anchor at the IANA or
   from the RIRs' certificates because one does not have the private
   keys required.  So one has to create a new trust anchor which, for
   ease of use, will contain the new/modified certificates and ROAs as
   well as the unmodified remainder of the Global RPKI.

I'm not really sure what sense "trust anchor" is being used in, here.
It does not seem to match up with the one described in Section 2.4 of RFC
6480, for example.

   Because Alice, Bob, and Carol want to be able to archive, reproduce,
   and send to other operators the data necessary to reproduce their
   modified view of the global RPKI, there will need to be a formally
   defined set of data which is input to a well-defined process to take
   an existing Global RPKI tree and produce the desired modified re-
   anchored tree.

This feels very incompletely described.  (Yes, I know, "not intended to be
complete".  But there's a level of incompleteness that seems to not be
worth publishing, and we may be close to it.)

I also don't have a great sense of whether there's supposed to be a single
"re-anchored tree" or a forest of trees, and whether the full global RPKI
tree is a subtree of this re-anchored tree, or a replacement/copied version
is present therein.

   Simplified Local Internet Number Resource Management with the RPKI
   (SLURM), [RFC8416], addresses many, but not all, of these issues and
   approaches.  This document was originally a gating requirements
   document for SLURM and other approaches.

The phrasing of this last sentence feels very unusual to me for an archival
document.

Section 6

"patching of trust" seems like a phrase without a clear meaning.  Though, a
large part of that is probably because "trust" itself is so hard to nail
down...

   Modification 'recipes' may lack authentication.  E.g., if
   modifications to the tree are passed around a la SLURM files, see
   [RFC8416], what was object security becomes, at best, transport
   security, or authentication by other trust domains such as PGP.

Expounding on this with a couple more sentences would probably be worth the
effort.

(Mirja Kühlewind) Discuss

Discuss (2019-04-29 for -05)
1) I’m not sure I really understand the following use case..? Also is “re-routing to acceptable content” actually a use case we want to endorse in an RFC?
"Alice is responsible for the trusted routing for a large
   organization, commercial or geo-political, in which management
   requests routing engineering to redirect their competitors' prefixes
   to socially acceptable data. 

 2) This sentence in the security considerations section uses normative language without having the respective disclaimer in the document:
“Hence they MUST be implemented to assure the
   local constraint.”
However, I also don’t understand what such a normative statement is supposed to say. I’m not sure if local trust actors are the only solution to the stated use case/problems; if that’s what the sentence tries to say, I disagree, however, in any case it doesn’t seem to make sense to use normative wording here.

 3) Also, this sentence in the security consideration section, needs probably more explanation: 
   “Authentication of modification 'recipes' will be needed.”
   What is “will be needed” supposed to mean? How can this be achieved? What happens if it’s not implemented?

Warren Kumari Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Suresh Krishnan) No Objection

Barry Leiba No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2019-04-29 for -05)
Thanks for the work on this document. I have two minor editorial suggestions.

---------------------------------------------------------------------------

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - RPKI
 - LIR
 - PI
 - RIR
 - CA

---------------------------------------------------------------------------

ID Nits reports:

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords.

     RFC 2119 keyword, line 177: '...eds.  Hence they MUST be implemented t...'

Please consider adding the boilerplate specified in RFC 8174.

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-05-02)
Thank you for writing this short document. I liked your 'suggested reading' section ;-)

Text is sometimes a little too casual though such as in section 4 "not to condone borrowing" ;-)

Magnus Westerlund No Objection

Martin Duke No Record

Erik Kline No Record

Murray Kucherawy No Record

Robert Wilton No Record