Subject: [Sidrops] Mirja Kühlewind's Discuss on draft-ietf-sidrops-lta-use-cases-05: (with DISCUSS)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 29 Apr 2019 06:47:35 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-sidrops-lta-use-cases-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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?

---

From: Randy Bush <[email-masked]>
Date: Mon, 29 Apr 2019 15:15:05 -0700

> 1) I’m not sure I really understand the following use case..?

> "Alice is responsible for the trusted routing for a large

think alice being (us|china|uk|justabouteverybody) blocking/redirecting
sites which are socially or politically unacceptable in their country.
this year's excuses are terrorism and child porn, though religious
bigotry is close behind.

> Also is “re-routing to acceptable content” actually a use case we want
> to endorse in an RFC?

good question.  governments do this all the time whether we like it or
not.  as the technology to do this is likely the same as for carol's
case (the 'dutch court attack'), whether to publish the use case is
above my pay grade.  pretending the use case does not exist may cause
reviewers to invoke a large flightless bird.

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

clearly wording could be improved.  my guess is the author meant that
the result must be able to be validated as if the changed data were part
of the validatable global pki while including the local context, perhaps
with the addition of trust anchors or some other magic.

>  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

see for example rfc 8416, Simplified Local Internet Number Resource
Management with the RPKI, for which this draft was originally to be a
gating rfc.

the problem there is that slurm is a nice syntax for a recipe to meet
some goals of lta-use-cases, but why the heck should i trust carol's
slurm recipe when she (or some intermediate party) sends it to me?  how
do i know it really came from carol and not a monkey in the middle?  i
doubt global ops will agree on a global back-door set of trust anchors.

if it is not implemented, the receiver is taking a major risk trusting
tree patches passed around within their organization (alice), let alone
more global contexts (carol).  suddenly what was a databse based on
object security could be patching in objects based on transport security
or no security at all.

randy