Re: [sidr] two stranded docuemnts - stake time

Chris Morrow <> Sun, 24 July 2016 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FA8312D56D for <>; Sun, 24 Jul 2016 10:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.188
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iQV7aov_lND0 for <>; Sun, 24 Jul 2016 10:24:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 938B712D556 for <>; Sun, 24 Jul 2016 10:24:49 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DAB240918; Sun, 24 Jul 2016 17:24:46 +0000 (UTC)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (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: <>
From: Chris Morrow <>
To: Stephen Kent <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
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: <>
Cc: Chris Morrow <>, sidr <>
Subject: Re: [sidr] two stranded docuemnts - stake time
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Jul 2016 17:24:52 -0000

At Fri, 22 Jul 2016 11:48:30 -0400,
Stephen Kent <> 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)>]