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 22:18 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 585D7129420; Thu, 5 Jan 2017 14:18:11 -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 xoJD-L025IPG; Thu, 5 Jan 2017 14:18:10 -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 47F6D129406; Thu, 5 Jan 2017 14:18:10 -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 v05MI96A044578 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Jan 2017 16:18:09 -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 16:18:08 -0600
Message-ID: <F476162B-2388-434F-9FEB-FFFCBED5B359@nostrum.com>
In-Reply-To: <m2k2a9f93d.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> <39D04FC6-BD42-4474-BEF5-9A3C370D7A1A@nostrum.com> <m2k2a9f93d.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/D6dxBNmAd7egW8tWszWnyKE4nyU>
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 22:18:11 -0000

On 5 Jan 2017, at 16:14, 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)?
>
> yes, it must preserve the signed path and add its own signature.

Thanks, that helps. Would it make the last sentence say something to the 
effect of "... and MUST additionally be signed by the propagating 
router."?

Ben.