Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)
Matthias Waehlisch <m.waehlisch@fu-berlin.de> Thu, 23 June 2016 18:00 UTC
Return-Path: <m.waehlisch@fu-berlin.de>
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 B549412D508; Thu, 23 Jun 2016 11:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 FVGsx2dceblf; Thu, 23 Jun 2016 11:00:45 -0700 (PDT)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE08712D125; Thu, 23 Jun 2016 11:00:44 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from <m.waehlisch@fu-berlin.de>) id <1bG8vi-001WdW-0w>; Thu, 23 Jun 2016 20:00:42 +0200
Received: from x5ce7e2b8.dyn.telefonica.de ([92.231.226.184] helo=mw-PC.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1:AES256-SHA:256) (envelope-from <m.waehlisch@fu-berlin.de>) id <1bG8vh-002dBY-Lm>; Thu, 23 Jun 2016 20:00:41 +0200
Date: Thu, 23 Jun 2016 19:59:15 +0200
From: Matthias Waehlisch <m.waehlisch@fu-berlin.de>
To: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <alpine.WNT.2.00.1606161633470.6316@mw-PC>
Message-ID: <alpine.WNT.2.00.1606231957190.6316@mw-PC>
References: <yj9owpm8agia.wl%morrowc@ops-netman.net> <61339176-792E-4000-BBBD-D17D4962E249@tislabs.com> <E5A2A64E-429D-4E77-80EE-BA57B20AEBC8@tislabs.com> <alpine.WNT.2.00.1606161633470.6316@mw-PC>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
X-X-Sender: waehl@mail.zedat.fu-berlin.de
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="631769442-14006-1466704756=:6316"
X-Originating-IP: 92.231.226.184
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/S8YOXXEnGCJaSkw55UFT2aJdqMQ>
Cc: sidr chairs <sidr-chairs@ietf.org>, sidr <sidr@ietf.org>
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2016-06-14 (June 14 2016)
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, 23 Jun 2016 18:00:48 -0000
Hi Randy, one more: Can you please replace "Invalid" by "Not Valid", because this is the notation defined in draft-ietf-sidr-bgpsec-protocol-17. Thanks matthias On Thu, 16 Jun 2016, Matthias Waehlisch wrote: > Hi, > > I read v09. No objections only minor comments: > > line 102: BGPsec need*s* *to* be spoken only > > line 104: s/by small edge routers/by resource constrained edge routers/ > > line 119: *see* [RFC4271] > > line 159: s/..../etc./ > > lines 200-206 seem redudant to lines 208-213 > > line 202 s/smallish/resource constrained/ > > line 215: I don't know where the 84% comes from, I suppose it's just a > more or less arbitrary illustration of "vast majority". I would remove > the number. > > line 234: I would be more explicit: "How this is used in routing is up > to the operator's local policy, similar to origin validation [RFC6811]." > > lines 243-250: This paragraph confused me. What about: > > Operators should be aware that controlling Invalid announcements by > local preference might be delusive. Local preference affects only routes > to the same set of destinations. Consider having a Valid announcement > from neighbor V for prefix 10.0.0.0/16 and an Invalid announcement for > 10.0.66.0/24 from neighbor I. If the local policy on a router is > configured to accept Invalid announcements, then both routes will be > installed, no matter of the value of local preference. > > (Btw, I suppose that routes to .666 will be discarded anyway ;) > > line 252: It sounds that only edge routers are allowed to speak BGPsec. > I would weaken and say "Validation of signed paths is usually deployed > at the eBGP edge." > > line 292: s/BGPSEC_Path/BGPsec_Path/ > > lines 288-295: The paragraph seems to mix transparent operation and the > question of validation. What about: > > A route server is usually 'transparent'. To operate transparently in an > environment in which the route server connects BGPsec-enabled peers, the > route server needs to run BGPsec as well. This implies that the route > server creates signatures per client including its own AS in the > BGPsec_Path and the target ASes. However, increasing the AS hop count > reduces the likelihood of best path selection. See 2.2.2 of > [I-D.ietf-idr-ix-bgp-route-server]. To overcome this problem, the route > server uses pCount of zero to not increase the effective AS hop count. > > Furthermore, a BGPsec-aware route server needs to validate the incoming > BGPsec_Path but should not drop invalids. In case the client speaks > BGPsec the route server should just forward updates to clients which > then validate . In case the client does not speak BGPsec, the route > server reconstructs the AS_PATH and may signal the validation outcome > using communities. > > line 300: s/Routers should default to this knob disallowing pCount 0./Routers should disallow pCount 0 by default./ > > line 346: I would rephrase: "Operators should deploy servers that > provide time service, such as [RFC5905], to client routers." > > > > Cheers > matthias > > On Wed, 15 Jun 2016, Sandra Murphy wrote: > > > It is a short document. The sentences are not complicated. It reads quickly. > > > > There’s been little/no wg comment on this, certainly no controversy, over the lifetime of the draft. > > > > But still. > > > > Please. Pretty please. Pretty please with sugar on top. Pretty please with a cherry on top. > > > > Could we get some feedback that this document is ready for publication? > > > > —Sandy, speaking as one of the wg co-chairs > > > > > > On Jun 8, 2016, at 10:19 PM, Sandra Murphy <sandy@tislabs.com> wrote: > > > > > No responses at all. > > > > > > Come on folks. It’s a short document, like Chris says. > > > > > > You should be able to read and comment without much trouble. > > > > > > —Sandy, speaking as one of the wg co-chairs > > > > > > On Jun 1, 2016, at 2:52 PM, Chris Morrow <morrowc@ops-netman.net> wrote: > > > > > >> > > >> Howdy WG folks, > > >> Please take this note as the start of the 2wk WGLC period for: > > >> <https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-07> > > >> > > >> Abstract: > > >> "Deployment of the BGPsec architecture and protocols has many > > >> operational considerations. This document attempts to collect and > > >> present the most critical and universal. It is expected to evolve as > > >> BGPsec is formalized and initially deployed." > > >> > > >> This is a relatively short document, 8 pages, full of wonder and > > >> excitement! I hope that the wg members have read it (it's been through > > >> 8+ revisions) and that they will re-read it quickly, provide comments > > >> as appropriate and ideas on preparedness for publication or not. > > >> > > >> > > >> Thanks for you time and attention to this matter, > > >> > > >> -Chris > > >> co-chair-persona > > >> > > >> _______________________________________________ > > >> sidr mailing list > > >> sidr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sidr > > > > > > > > > > -- Dr. Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:m.waehlisch@fu-berlin.de .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.haw-hamburg.de .. http://www.link-lab.net
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Christopher Morrow
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Matthias Waehlisch
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Randy Bush
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Randy Bush
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Matthias Waehlisch
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Matthias Waehlisch
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Randy Bush
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Sean Turner
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Aris Lambrianidis
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Sandra Murphy
- [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - ENDS: 2… Chris Morrow
- Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-ops - END… Sandra Murphy