Re: [sidr] two stranded docuemnts - stake time
Chris Morrow <morrowc@ops-netman.net> Sun, 24 July 2016 17:24 UTC
Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA8312D56D for <sidr@ietfa.amsl.com>; Sun, 24 Jul 2016 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 iQV7aov_lND0 for <sidr@ietfa.amsl.com>; Sun, 24 Jul 2016 10:24:50 -0700 (PDT)
Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938B712D556 for <sidr@ietf.org>; Sun, 24 Jul 2016 10:24:49 -0700 (PDT)
Received: from mail.ops-netman.net (unknown [208.76.12.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 6DAB240918; Sun, 24 Jul 2016 17:24:46 +0000 (UTC)
Received: from morrowc-glaptop4.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 322338812DF; Sun, 24 Jul 2016 17:24:46 +0000 (UTC)
Date: Sun, 24 Jul 2016 18:24:45 +0100
Message-ID: <yj9oshuz3q5e.wl%morrowc@ops-netman.net>
From: Chris Morrow <morrowc@ops-netman.net>
To: Stephen Kent <kent@bbn.com>
In-Reply-To: <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com>
References: <yj9oinvzi8gj.wl%morrowc@ops-netman.net> <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <yj9ofur2iqgd.wl%morrowc@ops-netman.net> <m28twudtww.wl%randy@psg.com> <CAL9jLab9Zaz1UjJfjJNmjU3FcMkF+mSYKLj7VGKEydK0FKOjJg@mail.gmail.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO)
Organization: Operations Network Management, Ltd.
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/sidr/_SKAGSL8Ztgt3hk88PPikO0MwJc>
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr <sidr@ietf.org>
Subject: Re: [sidr] two stranded docuemnts - stake time
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2016 17:24:52 -0000
At Fri, 22 Jul 2016 11:48:30 -0400, Stephen Kent <kent@bbn.com> wrote: > > [1 <text/plain; utf-8 (8bit)>] > Chris, > > Here is my message to the SIDR list from 6/16: > great, thanks! > > I read the latest version of this document and have a few comments, > some of which I have made before, to no avail ;-). > > I still find the wording of the three examples in Section 4 to be > unnecessarily informal. I’ve provided suggested text for previous > versions of this document that probably is still applicable, since > the examples do not seem to have changed much. It seems preferable > to describe the first motivating case without reference to a > specific RIR. (Including a parenthetical note about the historical > precedent of a Dutch court order involving RIPE is relevant and > might be included.) There is language in the adverse actions > document that could be used here to be more formal, less folksy. > Since adverse actions is now a Wg document, one might even cite > sections of it to support the examples. In the second example, the > term “borrowed” is not defined. I think I know what is implied, and > it seems inappropriate to possibly condone advertisement of address > space allocated to another party, just because that party is not > advertising the space to the global Internet. Why not just stick > with private address space in this example? The third example is a > six-line, run-on sentence, so it’s not easy for a reader to be > certain what the example really implies. > > The Notes section (5) seems to offer an analysis of requirement for > potential solutions to address the use cases. Maybe a better section > title is warranted. > > David’s SLURM document describes a mechanism that seems to address > the local, customized view requirements described in Section 4. > (David says that it addresses the second and maybe third uses cases, > but I think he was modest in his assertion.) SLURM could support the > first use case, if the community decided on a mechanism to > distribute SLURM files in response to a CA being compelled to modify > RPKI data. (It would be easy to ad a digital signature to the files, > to provide authentication and integrity, but the there’s the little > issue of key management and a suitable trust model …) The design > accommodates merging of multiple SLURM files, meeting that > requirement as stated in this section. Note that SLURM does not > require modifying ROAs or GB records. It is a post-processing > mechanism using “local” configuration data that overrides the global > data acquired from the RPKI. This suggests that some of the comments > in Section 5 are not accurate, e.g., ones that allude to the > problems posed by not having keys to sign ROAs, etc. Although there > is a need to achieve the effect of modifying, creating and/or > replacing ROAs and GB records, that effect does not have to involve > signatures on the affected data, as suggested in the first and third > paragraphs of Section 5. > > Typos: > > … to be a formally formally defined set … (repeated word) > > … 'recipes' should be mergable (mergeable?) > > The Security Considerations text seems unduly negative. The approach > being proposed here is not violating global security, because the > results are intended to be local. How about the following wording: > > The use cases described in Section 4, and the notes for suggested > solution approaches in Section 5, are not intended to undermine the > security provided by the RPKI. Rather they identify potential > obstacles to widespread adoption of the RPKI, and suggest changes > that would enable network operators to generate custom “views” of > the RPKI for use on a local basis. Providing the ability to create > local RPKI views does not adversely affect global routing security. > > [2 <text/html; utf-8 (8bit)>] >
- Re: [sidr] two stranded docuemnts - stake time Chris Morrow
- Re: [sidr] two stranded docuemnts - stake time David Mandelberg
- Re: [sidr] two stranded docuemnts - stake time Stephen Kent
- Re: [sidr] two stranded docuemnts - stake time Declan Ma
- Re: [sidr] two stranded docuemnts - stake time Tim Bruijnzeels
- Re: [sidr] two stranded docuemnts - stake time Christopher Morrow
- Re: [sidr] two stranded docuemnts - stake time Randy Bush
- Re: [sidr] two stranded docuemnts - stake time Chris Morrow
- Re: [sidr] two stranded docuemnts - stake time Stephen Kent
- Re: [sidr] two stranded docuemnts - stake time Sandra Murphy
- Re: [sidr] two stranded docuemnts - stake time Sandra Murphy
- Re: [sidr] two stranded docuemnts - stake time Randy Bush
- Re: [sidr] two stranded docuemnts - stake time Stephen Kent
- Re: [sidr] two stranded docuemnts - stake time Tim Bruijnzeels
- [sidr] two stranded docuemnts - stake time Chris Morrow
- Re: [sidr] two stranded docuemnts - stake time Stephen Kent
- Re: [sidr] two stranded docuemnts - stake time Declan Ma
- Re: [sidr] two stranded docuemnts - stake time Tim Bruijnzeels
- Re: [sidr] two stranded docuemnts - stake time Tim Bruijnzeels