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
- [Sidrops] Mirja Kühlewind's Discuss on draft-ietf… Mirja Kühlewind via Datatracker
- Re: [Sidrops] Mirja Kühlewind's Discuss on draft-… Randy Bush