Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Thu, 05 January 2017 16:05 UTC

Return-Path: <ben@nostrum.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 17DEF129B9A; Thu, 5 Jan 2017 08:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 zKW879FcaqiY; Thu, 5 Jan 2017 08:05:29 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AF2129B5D; Thu, 5 Jan 2017 08:05:23 -0800 (PST)
Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v05G5Ms6005292 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Jan 2017 10:05:22 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39]
From: Ben Campbell <ben@nostrum.com>
To: Randy Bush <randy@psg.com>
Date: Thu, 05 Jan 2017 10:05:21 -0600
Message-ID: <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com>
In-Reply-To: <m260lul2f8.wl-randy@psg.com>
References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <m2d1g3mvo2.wl-randy@psg.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com> <m260lul2f8.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5319)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/4fNVjIIrZtiyznGZvlyBD8AHwWk>
Cc: The IESG <iesg@ietf.org>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)
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: Thu, 05 Jan 2017 16:05:30 -0000

On 4 Jan 2017, at 19:29, Randy Bush wrote:

> Sorry, I did not mean that stripping was suggested; the previous
>> phrase (non-normatively) recommends against stripping. My question 
>> is,
>> since the subject of the sentence is "signed paths" whether the "MUST
>> be signed" language means "MUST NOT strip the signature" (which I
>> suspect to be the case), or something else.
>
>
> how about
>
>    As the mildly stochastic timing of RPKI propagation may cause 
> version
>    skew across routers, an AS Path which does not validate at router 
> R0
>    might validate at R1.  Therefore, signed paths that are Not Valid 
> and
>    yet propagated (because they are chosen as best path) MUST NOT have
>    signatures stripped and MUST be signed if sent to external BGPsec
>    speakers.
>
> if not, use larger clue bat

It's likely I have this particular bat by the wrong end.

In the last sentence, does "MUST be signed" mean it must have a 
signature (which would seem to make "MUST NOT strip" and "MUST be 
signed" redundant), or does it mean the propagating router must add it's 
own signature in addition to the existing one(s)?

Ben.