Re: [Sidrops] AD review of draft-ietf-sidrops-bgpsec-rollover

Warren Kumari <warren@kumari.net> Tue, 03 October 2017 22:33 UTC

Return-Path: <warren@kumari.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129B3134523 for <sidrops@ietfa.amsl.com>; Tue, 3 Oct 2017 15:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 j6ZseLKSc6G3 for <sidrops@ietfa.amsl.com>; Tue, 3 Oct 2017 15:33:28 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 F005D13421C for <sidrops@ietf.org>; Tue, 3 Oct 2017 15:33:27 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id b189so15527482wmd.4 for <sidrops@ietf.org>; Tue, 03 Oct 2017 15:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vzcseBxKoxeYPOrdMA6KTw/g/PjGGF9W/asm5VgC1Sc=; b=SdDZYffyanoAu08/BoCKiZ8LtuBPt5kougUb/0+Jko7Z6TJXP4Nb7+bJ1CwU5ffvMY PjjJMyX5wxvFdHhwUAxXmSSGqlas+PHjWOLFyYLKxqG0JkI+LG82iLxXdQXMvm7QFZSa NpeOA4523MX6TQUAlGS19s/UTG1BlvsPDStdehSMkn9UUYl/AKqgbxI9Z7YFaMj+cjaU c3i9j49xCOuFcvfphIJQPo3fx1rrUcRib4XYkHEpc9ofHsB1jO1q1iglhZgQ2Isz+y+N OLOr+R5qb3QR67e2F8780QtyZG4uCztL9k/1YTiGIuoSl982Bcc/5NNKbJMRcMA8L0Qu Vo5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vzcseBxKoxeYPOrdMA6KTw/g/PjGGF9W/asm5VgC1Sc=; b=TnNOHg0vWdtn7iEBC/ZC/kVBtFaANvz6vHX08oYdQ/CNzpdarrMIl3sUEsNgLKB15/ rdJTrCFT1yt5LrY8qqjwxwHYsLSgC62OHLB86vCZtvmauVGYs1j2WeBNBBFcQ6BixmyL txsLxCwwy/ixcR0BS9oKA694nWYbRt0M59g2l/N0YUoH1oSBSr4FTaqOVyZW7Ye4SPfn 7LF2ciI3y+opnURMK9/GLMTP9rV4qh46Ft/LRf97bREcjKn2RmJd2MYiXOhujJilANBf ixAyewg3YIV73tH53Yz3434ImszzX90kgi6ab49LHUsym1wqK38YK+0Cc6FvYiBP8jmX cNQA==
X-Gm-Message-State: AMCzsaURL7G6Fvci3GHqABPf4P8t4yfRqBuJ5lG3Jx2O+sguGQKT3msK VFEiIpn3wMC0r3W3dSMexdlVL41LqJx5jkMR+pFxzA==
X-Google-Smtp-Source: AOwi7QBtenY1FljNfzCTqx2FbY0bCY2VdJ+RQaZ0eDtIfRXcha0mdLtO5QJXGdgUZp/9l3W0KDW7xfBp421Dx/3f804=
X-Received: by 10.28.26.138 with SMTP id a132mr5735048wma.124.1507070006327; Tue, 03 Oct 2017 15:33:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.188.8 with HTTP; Tue, 3 Oct 2017 15:32:45 -0700 (PDT)
In-Reply-To: <4D3EF6F4-50E5-449B-ACDB-0EC9DBB1CCA3@cisco.com>
References: <CAHw9_iKACx39CX0N5sfaGnH8gfG0CNWSBOwSb+f1vVtpNR2U9w@mail.gmail.com> <4D3EF6F4-50E5-449B-ACDB-0EC9DBB1CCA3@cisco.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 03 Oct 2017 15:32:45 -0700
Message-ID: <CAHw9_iJSt0Sb0AOG8QkX45=x1jhXw=AzLOsmbDXNz77ZjtCq2g@mail.gmail.com>
To: "Brian Weis (bew)" <bew@cisco.com>
Cc: "draft-ietf-sidrops-bgpsec-rollover@ietf.org" <draft-ietf-sidrops-bgpsec-rollover@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Qz_emNN_UlGjw3bBcHRNr8lfyb8>
Subject: Re: [Sidrops] AD review of draft-ietf-sidrops-bgpsec-rollover
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Oct 2017 22:33:30 -0000

Excellent.

Thank you, I kicked off LC.
W

On Tue, Oct 3, 2017 at 3:09 PM, Brian Weis (bew) <bew@cisco.com> wrote:
> Hi Warren,
>
> Thanks for your careful review.
>
> On Oct 3, 2017, at 9:44 AM, Warren Kumari <warren@kumari.net> wrote:
>
> Hello,
>
> Thank you to the editors and WG for your efforts on
> this document, it's a well written and easy to understand
> draft.  I do have a few comments that I’d like addressed
> before I start IETF LC — addressing these now will avoid
> issues later in the process.
>
>
> Questions:
> 1: Section 2.  Introduction
> "This document provides general recommendations for that process.
> Certificate Practice Statements (CPS) documents MAY reference these
> recommendations."
>
> I do not understand the use of a 2119 MAY here -- can it be made
> lowercase instead? I really don't understand what it is trying to
> accomplish.
>
>
> Hmmmm, since the subject of the MAY is not this document (i.e., is the CPS),
> then use of requirements language does seem improper. We’ve changed
> this to lower case as suggested.
>
>
> 2: 3.1.  A proposed process for BGPsec router key rollover
> "If there is no staging period, routing information may be lost."
> I do not have any better text to suggest, but I don't really think
> that routing information gets "lost" - when the session is fixed, the
> information still gets through -- perhaps "routing may be disrupted”?
>
>
> Yes, “routing may be disrupted” was the intent. We’ve replaced this phrase
> with
> "routing may be disrupted due to the inability of a BGPsec router to
> validate
> BGPsec updates signed with a new private key"
>
> My comments are mostly editorial nits.
> 1: There are some IDNITs -- a number of the drafts are now RFCs:
> == Outdated reference: draft-ietf-sidr-bgpsec-ops has been published as RFC
>     8207
>
> == Outdated reference: draft-ietf-sidr-bgpsec-protocol has been published
>     as RFC 8205
>
> == Outdated reference: draft-ietf-sidr-rpki-rtr-rfc6810-bis has been
>     published as RFC 8210
>
>
> Ack … these RFCs were published after our -01 was published.
>
> 2: Section 3.  Key rollover in BGPsec
>   "An BGPsec router certificate SHOULD be replaced ..."
> s/An/A/
>
> 2: Section 3.  Key rollover in BGPsec
> "Protection against withdrawel supporession and replay attacks"
> -- typos in "withdrawel" and "supporession"
>
> 3: Section 3.1.  A proposed process for BGPsec router key rollover
> "However, If an administrator"
> s/If/if/
>
> 4: Section 6.  Security Considerations
> "When certificates containing a new public key are provisioning ahead"
> s/provisioning/provisioned/
>
>
> All fixed.
>
>
> Please let me know once these are addressed, so I can start LC.
>
>
> Done. <https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rollover-02/>.
>
> Thanks!
> Brian
>
>
> Thanks again,
> W
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
>
>
> --
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: +1 408 526 4796
> Email: bew@cisco.com
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf