Re: [sidr] two stranded docuemnts - stake time
Stephen Kent <kent@bbn.com> Fri, 22 July 2016 15:48 UTC
Return-Path: <kent@bbn.com>
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 DE28512D830 for <sidr@ietfa.amsl.com>; Fri, 22 Jul 2016 08:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 N2rbD-48E-F2 for <sidr@ietfa.amsl.com>; Fri, 22 Jul 2016 08:48:38 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9EE126D74 for <sidr@ietf.org>; Fri, 22 Jul 2016 08:48:37 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:45331 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1bQcgg-000Afa-SW; Fri, 22 Jul 2016 11:48:31 -0400
To: Christopher Morrow <morrowc.lists@gmail.com>, Randy Bush <randy@psg.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>
From: Stephen Kent <kent@bbn.com>
Message-ID: <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com>
Date: Fri, 22 Jul 2016 11:48:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAL9jLab9Zaz1UjJfjJNmjU3FcMkF+mSYKLj7VGKEydK0FKOjJg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------78AE76FB0E018A26C978767D"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/t4Yh_VQ_2y8Mh6XX7ohg6x_tjQU>
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: Fri, 22 Jul 2016 15:48:41 -0000
Chris, Here is my message to the SIDR list from 6/16: 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.
- 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