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

Randy Bush <randy@psg.com> Mon, 29 April 2019 22:15 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33D51200EA; Mon, 29 Apr 2019 15:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUkA0XCKz2Un; Mon, 29 Apr 2019 15:15:09 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B4212031F; Mon, 29 Apr 2019 15:15:08 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1hLEYE-0008T1-Fh; Mon, 29 Apr 2019 22:15:06 +0000
Date: Mon, 29 Apr 2019 15:15:05 -0700
Message-ID: <m2ef5k8nme.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "\"Mirja Kühlewind via Datatracker\"" <noreply@ietf.org>
Cc: The IESG <iesg@ietf.org>, sidrops@ietf.org
In-Reply-To: <155654565583.15899.253597532069368895.idtracker@ietfa.amsl.com>
References: <155654565583.15899.253597532069368895.idtracker@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-2022-JP"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qGulOfrDPxXgMC9HLJWpXYeBOi4>
Subject: Re: [Sidrops] Mirja Kühlewind's Discuss on draft-ietf-sidrops-lta-use-cases-05: (with DISCUSS)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2019 22:15:11 -0000

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

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

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
>    happens if it’s not implemented?

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