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

Randy Bush <randy@psg.com> Thu, 05 January 2017 01:29 UTC

Return-Path: <randy@psg.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 D5E331294C9; Wed, 4 Jan 2017 17:29:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, 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 NgGGRm_8c-ng; Wed, 4 Jan 2017 17:29:34 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C96321294C8; Wed, 4 Jan 2017 17:29:34 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cOws0-0005cy-VR; Thu, 05 Jan 2017 01:29:33 +0000
Date: Thu, 05 Jan 2017 10:29:31 +0900
Message-ID: <m260lul2f8.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "Ben Campbell" <ben@nostrum.com>
In-Reply-To: <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com>
References: <148348795694.28027.8646303758093237302.idtracker@ietfa.amsl.com> <m2d1g3mvo2.wl-randy@psg.com> <661F8C18-7B04-4E88-A97A-BBA8314C3FD4@nostrum.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/TJn4MO9GxBK2y5qkuNJEQ4LT43o>
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 01:29:36 -0000

>>> -4, first paragraph: I found "either" followed by "and/or" a bit
>>> confusing. I suggest simply dropping the word "either".
>> 
>>    As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers
>>    are either capable of generating their own public/private
>>    key-pairs and having their certificates signed and published in
>>    the RPKI by the RPKI CA system, and/or are given public/private
>>    key-pairs by the operator.
>> 
>> but the router(s) might not be capable of generating key-pairs.  they
>> might, they might not, the op may generate or not, or both.  an
>> absurd corner case might be that a router with two ASs has the as0
>> key stuffed by the as0 noc, and the as1 key is generated on device
>> because that is the as1 policy.
> 
> I merely meant that "either" seemed odd for non-exclusive options. I
> take your argument to mean that the options really are non-exclusive.

ok, i will drop the either.

>>> -4, last paragraph: "a prudent operator will..." sounds like it
>>> might be worthy of a SHOULD.
>> 
>> given the previous, how about lower case should
> 
> That would not seem to change anything :-) My point was that the
> language seemed stated in a way that _might_ justify a 2119
> keyword.

ok, upcased SHOULD

>>> -7, paragraph 6: This seems to say that signed paths MUST be
>>> signed. Does the "MUST be signed if sent to external BGP speakers"
>>> mean that the existing signature must not be stripped (as stated
>>> more weakly in the previous sentence), or does it mean the sender
>>> must re-sign the path?
>> 
>>    Because of possible RPKI version skew, 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) should have their signatures left intact and
>>    MUST be signed if sent to external BGPsec speakers.
>> 
>> i am not seeing where bgpsec stripping was suggested; in fact, the
>> opposite.  if router r0 receives a signed path and intends to pass
>> that signed path to the next listener, r0 must sign the path.  i am
>> at a loss to understand your question.  clue bat please.
> 
> 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

> As I mentioned in response to Alvaro's comment: Maybe section 2 should
> cite the protocol rather than the overview?

done

randy