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

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)/

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

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

Taking over Alissa's DICSUSS, as a reminder to check this when a new revision becomes available:

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

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?