From christopher.morrow@gmail.com Fri Sep 2 19:56:26 2011 Return-Path: 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 5242B21F8801 for ; Fri, 2 Sep 2011 19:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcqo9r9uXHkV for ; Fri, 2 Sep 2011 19:56:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5D3421F8556 for ; Fri, 2 Sep 2011 19:56:25 -0700 (PDT) Received: by iakc1 with SMTP id c1so4626218iak.31 for ; Fri, 02 Sep 2011 19:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=u1yOKTs8MkLIAWo+iU74ApBWW9VocX8AZxTduP8rQn0=; b=ERH9ltn9FHxLm6BSG0kDZOLK3A3kWXeJQrszrO2/v+lIH5Rm8bDVkD8zBvtFZeoRuM a3fd6e0Ak+RnajlXZwmBiDby8GRYjKeBSNyo+I/g8BGX8mNksxOuVIiC9R5H5JQVLS0E 9hJn5vv5y8KVGR1JL/z6WMLb8ys7frztQo15g= MIME-Version: 1.0 Received: by 10.231.29.93 with SMTP id p29mr3090023ibc.93.1315018681631; Fri, 02 Sep 2011 19:58:01 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.162.73 with HTTP; Fri, 2 Sep 2011 19:58:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Sep 2011 22:58:01 -0400 X-Google-Sender-Auth: fPB6nwkdMowkUtjamCRlkysUQ5o Message-ID: From: Christopher Morrow To: Sandra Murphy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WG LC for draft-ietf-sidr-ghostbusters-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 02:56:26 -0000 Oopsy, Sandy asked that someone (and pointed at me) call some sort of consensus on this doc and move it along (or punt it to the authors for more work). It seems there were a few folks willing to read the doc (and comment), some further work was done and we have a version 8 now: Diffs between 05 and 08 show mostly english fixups and some wording cleanups. Given that the folks who spoke up did so positively, let's call this done and move this along to the IESG for review/etc. -chris On Wed, Jul 13, 2011 at 7:35 PM, Sandra Murphy w= rote: > > The chairs have received a request from the authors for a WG Last Call fo= r > "The RPKI Ghostbusters Record", draft-ietf-sidr-ghostbusters-06. > > The document and the draft version history are available at: > http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ghostbusters > > The Last Call will end Wed, 3 Aug 2011 (AOE). =A0This is three weeks inst= ead > of the usual two, because the IETF week will occupy people's time and > attention. > > As usual, please address all comments to the WG mailing list, and please = be > clear in your comments to this last call if you are supporting the > document's submission to the IESG or if you are opposed. If you are oppos= ed, > please indicate why. > > --Sandy, speaking as wg chair, with wg chair snood on > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Sun Sep 4 01:46:08 2011 Return-Path: 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 3F17121F8834; Sun, 4 Sep 2011 01:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 456LuuC5NNdg; Sun, 4 Sep 2011 01:46:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05D421F87D9; Sun, 4 Sep 2011 01:46:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110904084607.740.61578.idtracker@ietfa.amsl.com> Date: Sun, 04 Sep 2011 01:46:07 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 08:46:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-09.txt Pages : 8 Date : 2011-09-04 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-09.txt From rjs@rob.sh Wed Sep 7 05:03:37 2011 Return-Path: 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 5864A21F8BFE for ; Wed, 7 Sep 2011 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouyNb-is3NCV for ; Wed, 7 Sep 2011 05:03:28 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 35A1F21F8BA4 for ; Wed, 7 Sep 2011 05:03:28 -0700 (PDT) Received: from [195.10.56.30] (helo=[212.137.15.246]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1R1GrD-0005bo-P3; Wed, 07 Sep 2011 13:03:55 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> Date: Wed, 7 Sep 2011 13:05:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> To: sidr wg list X-Mailer: Apple Mail (2.1084) Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 12:03:37 -0000 On 11 Aug 2011, at 22:40, George, Wesley wrote: > Danny said, > "Periodic updates of the entire routing table *with much larger and = more updates* seems undesirable at best to me, particularly to 'reduce = the vulnerability window for replay attacks' to 'days'." > --------------------------------------------------------- > I think that this is a small part of a much larger issue that has been = bugging me since our meeting in Quebec City. > After looking at Sriram's estimates around the necessary amount of = memory, etc for the different algorithms, I'm bothered by what is being = asked of the routing system in support of BGPSec. >=20 Hi All, Wes' point here is really important I think, and it's a bit of a shame = it hasn't got more focus. I stood up and mentioned scaling in Prague, = then found myself making a very similar point again in Qu=E9bec. As with = Wes, I would prefer that this is not interpreted as a criticism of the = goals of bgpsec, but rather is an operational perspective on the = assumptions that are made for deployment of the protocols being = developed in sidr. The root assumption that we seem to be taking as read throughout such = discussions is that at the point where routing infrastructure is = expected to support the computational load that is demanded of it by = bgpsec, there will have been sufficient growth in both the computational = and memory resources that are available to these systems. Whilst I = appreciate that cryptographic validation of the validity of a route can = be performed on the edge system(s), I think there are two very key = concerns here. - Historically, do we see Internet routing systems matching the rate of = general computational resource availability? My view on this is that we = do not - there are plenty of edge systems out there that are relatively = modern (and capable of routing tens of gigabits of traffic) that do not = have a control-plane that is as powerful as some of the software devices = that existed prior to it - as such, this means either this was a lower = priority to deliver (which may well be true), or that it was not = practical to do so. With increasing demands on control-plane resources = of IP systems (be they Internet edge or otherwise) - there is surely = some query as to whether having a large amount of memory or crypto = offload hardware will be a priority over other features. The question = Wes raised as to whether we, as a working-group, are happy with the = assumption that this is the case, is very valid. It would seem to me = that we are being somewhat prescriptive with prioritising what hardware = vendors' solutions should look like, and what operator's scaling = approaches will look like - without necessarily explicitly discussing = why this is reasonable to do so. - Are the assumptions that we are making regarding how those autonomous = systems delivering an "Internet" product set are architected valid? = There is some assumption (AIUI, please feel free to correct me) that we = are looking at networks where we have explicit edge devices which can = scale to meet the validation workload that we're putting on it. This = would seem (again, to me) to be based around assumption that there are a = relatively high number of less-dense edge devices. I would be interested = whether it's the feeling of the WG that my reading of what we're = assuming is correct - and if so, whether the WG feels that we can be = prescriptive like this for how one should architect an Internet network. I'm again very supportive of what problems bgpsec is trying to solve - = and do not want to put a dampener on any of the excellent efforts that = have gone into it - but think that we cannot wholly abstract ourselves = away from the actual deployability of the solutions that are being = developed. After all, we will not solve the problems that the WG is = chartered to solve if the fruits of the labours herein are not actually = deployed. I am not sure of exactly how we progress discussing the scalability of = the solution - but with Sriram's analysis, is it possible to discuss = within this forum, and perhaps others concerned with the general scaling = of IP routing elements, why the scaling considerations/assumptions of = bgpsec are valid, and where a departure is made from the longer term = view of scalability that is presented in existing IETF documents. Thanks for reading this - and your consideration! r. From jakob.heitz@ericsson.com Wed Sep 7 06:11:00 2011 Return-Path: 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 B93CE21F8C58 for ; Wed, 7 Sep 2011 06:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.289 X-Spam-Level: X-Spam-Status: No, score=-5.289 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pffKwWZI+UR3 for ; Wed, 7 Sep 2011 06:10:59 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9172921F8C55 for ; Wed, 7 Sep 2011 06:10:59 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p87DCjrv020163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Sep 2011 08:12:46 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 7 Sep 2011 09:12:44 -0400 From: Jakob Heitz To: Rob Shakir Date: Wed, 7 Sep 2011 09:12:41 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxtX9RRciuxpYOPRTmM125yD16/7A== Message-ID: <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> In-Reply-To: <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 13:11:00 -0000 V2hpbGUgYSByb3V0ZXIgdGhhdCBwZXJmb3JtcyBCR1BTRUMgbWF5IG5vdCBiZSBtb3JlIGV4cGVu c2l2ZSBpbiA1IHllYXJzIHRoYW4gb25lIHRoYXQgZG9lcyBub3QgdG9kYXksIHRoYXQgaXMgbm90 IHJlbGV2YW50LiBBIHJvdXRlciB0aGF0IHBlcmZvcm1zIEJHUFNFQyBpbiA1IHllYXJzIHdpbGwg bW9zdCBkZWZpbml0ZWx5IGNvc3QgbW9yZSB0byBwcm9kdWNlIGFzIHdlbGwgYXMgY29zdCBtb3Jl IHRvIHJ1biB0aGFuIGEgcm91dGVyIHRoYXQgZG9lcyBub3QgcGVyZm9ybSBCR1BTRUMgaW4gNSB5 ZWFycy4NCg0KU28sIGEgcXVlc3Rpb24gZm9yIHlvdSBSb2IuIFdpbGwgeW91ciBjdXN0b21lcnMg cGF5IHRoZSBwcmVtaXVtIGZvciBCR1Agc2VjdXJpdHk/DQoNCi0tDQpKYWtvYiBIZWl0ei4NCg0K DQpPbiBTZXAgNywgMjAxMSwgYXQgNTowNSBBTSwgIlJvYiBTaGFraXIiIDxyanNAcm9iLnNoPiB3 cm90ZToNCg0KPiBPbiAxMSBBdWcgMjAxMSwgYXQgMjI6NDAsIEdlb3JnZSwgV2VzbGV5IHdyb3Rl Og0KPiANCj4+IERhbm55IHNhaWQsDQo+PiAiUGVyaW9kaWMgdXBkYXRlcyBvZiB0aGUgZW50aXJl IHJvdXRpbmcgdGFibGUgKndpdGggbXVjaCBsYXJnZXIgYW5kIG1vcmUgdXBkYXRlcyogc2VlbXMg dW5kZXNpcmFibGUgYXQgYmVzdCB0byBtZSwgcGFydGljdWxhcmx5IHRvICdyZWR1Y2UgdGhlIHZ1 bG5lcmFiaWxpdHkgd2luZG93IGZvciByZXBsYXkgYXR0YWNrcycgdG8gJ2RheXMnLiINCj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4gSSB0aGluayB0aGF0IHRoaXMgaXMgYSBzbWFsbCBwYXJ0IG9mIGEgbXVjaCBsYXJnZXIgaXNz dWUgdGhhdCBoYXMgYmVlbiBidWdnaW5nIG1lIHNpbmNlIG91ciBtZWV0aW5nIGluIFF1ZWJlYyBD aXR5Lg0KPj4gQWZ0ZXIgbG9va2luZyBhdCBTcmlyYW0ncyBlc3RpbWF0ZXMgYXJvdW5kIHRoZSBu ZWNlc3NhcnkgYW1vdW50IG9mIG1lbW9yeSwgZXRjIGZvciB0aGUgZGlmZmVyZW50IGFsZ29yaXRo bXMsIEknbSBib3RoZXJlZCBieSB3aGF0IGlzIGJlaW5nIGFza2VkIG9mIHRoZSByb3V0aW5nIHN5 c3RlbSBpbiBzdXBwb3J0IG9mIEJHUFNlYy4NCj4+IA0KPiANCj4gSGkgQWxsLA0KPiANCj4gV2Vz JyBwb2ludCBoZXJlIGlzIHJlYWxseSBpbXBvcnRhbnQgSSB0aGluaywgYW5kIGl0J3MgYSBiaXQg b2YgYSBzaGFtZSBpdCBoYXNuJ3QgZ290IG1vcmUgZm9jdXMuIEkgc3Rvb2QgdXAgYW5kIG1lbnRp b25lZCBzY2FsaW5nIGluIFByYWd1ZSwgdGhlbiBmb3VuZCBteXNlbGYgbWFraW5nIGEgdmVyeSBz aW1pbGFyIHBvaW50IGFnYWluIGluIFF1qKZiZWMuIEFzIHdpdGggV2VzLCBJIHdvdWxkIHByZWZl ciB0aGF0IHRoaXMgaXMgbm90IGludGVycHJldGVkIGFzIGEgY3JpdGljaXNtIG9mIHRoZSBnb2Fs cyBvZiBiZ3BzZWMsIGJ1dCByYXRoZXIgaXMgYW4gb3BlcmF0aW9uYWwgcGVyc3BlY3RpdmUgb24g dGhlIGFzc3VtcHRpb25zIHRoYXQgYXJlIG1hZGUgZm9yIGRlcGxveW1lbnQgb2YgdGhlIHByb3Rv Y29scyBiZWluZyBkZXZlbG9wZWQgaW4gc2lkci4NCj4gDQo+IFRoZSByb290IGFzc3VtcHRpb24g dGhhdCB3ZSBzZWVtIHRvIGJlIHRha2luZyBhcyByZWFkIHRocm91Z2hvdXQgc3VjaCBkaXNjdXNz aW9ucyBpcyB0aGF0IGF0IHRoZSBwb2ludCB3aGVyZSByb3V0aW5nIGluZnJhc3RydWN0dXJlIGlz IGV4cGVjdGVkIHRvIHN1cHBvcnQgdGhlIGNvbXB1dGF0aW9uYWwgbG9hZCB0aGF0IGlzIGRlbWFu ZGVkIG9mIGl0IGJ5IGJncHNlYywgdGhlcmUgd2lsbCBoYXZlIGJlZW4gc3VmZmljaWVudCBncm93 dGggaW4gYm90aCB0aGUgY29tcHV0YXRpb25hbCBhbmQgbWVtb3J5IHJlc291cmNlcyB0aGF0IGFy ZSBhdmFpbGFibGUgdG8gdGhlc2Ugc3lzdGVtcy4gV2hpbHN0IEkgYXBwcmVjaWF0ZSB0aGF0IGNy eXB0b2dyYXBoaWMgdmFsaWRhdGlvbiBvZiB0aGUgdmFsaWRpdHkgb2YgYSByb3V0ZSBjYW4gYmUg cGVyZm9ybWVkIG9uIHRoZSBlZGdlIHN5c3RlbShzKSwgSSB0aGluayB0aGVyZSBhcmUgdHdvIHZl cnkga2V5IGNvbmNlcm5zIGhlcmUuDQo+IA0KPiAtIEhpc3RvcmljYWxseSwgZG8gd2Ugc2VlIElu dGVybmV0IHJvdXRpbmcgc3lzdGVtcyBtYXRjaGluZyB0aGUgcmF0ZSBvZiBnZW5lcmFsIGNvbXB1 dGF0aW9uYWwgcmVzb3VyY2UgYXZhaWxhYmlsaXR5PyBNeSB2aWV3IG9uIHRoaXMgaXMgdGhhdCB3 ZSBkbyBub3QgLSB0aGVyZSBhcmUgcGxlbnR5IG9mIGVkZ2Ugc3lzdGVtcyBvdXQgdGhlcmUgdGhh dCBhcmUgcmVsYXRpdmVseSBtb2Rlcm4gKGFuZCBjYXBhYmxlIG9mIHJvdXRpbmcgdGVucyBvZiBn aWdhYml0cyBvZiB0cmFmZmljKSB0aGF0IGRvIG5vdCBoYXZlIGEgY29udHJvbC1wbGFuZSB0aGF0 IGlzIGFzIHBvd2VyZnVsIGFzIHNvbWUgb2YgdGhlIHNvZnR3YXJlIGRldmljZXMgdGhhdCBleGlz dGVkIHByaW9yIHRvIGl0IC0gYXMgc3VjaCwgdGhpcyBtZWFucyBlaXRoZXIgdGhpcyB3YXMgYSBs b3dlciBwcmlvcml0eSB0byBkZWxpdmVyICh3aGljaCBtYXkgd2VsbCBiZSB0cnVlKSwgb3IgdGhh dCBpdCB3YXMgbm90IHByYWN0aWNhbCB0byBkbyBzby4gV2l0aCBpbmNyZWFzaW5nIGRlbWFuZHMg b24gY29udHJvbC1wbGFuZSByZXNvdXJjZXMgb2YgSVAgc3lzdGVtcyAoYmUgdGhleSBJbnRlcm5l dCBlZGdlIG9yIG90aGVyd2lzZSkgLSB0aGVyZSBpcyBzdXJlbHkgc29tZSBxdWVyeSBhcyB0byB3 aGV0aGVyIGhhdmluZyBhIGxhcmdlIGFtb3VudCBvZiBtZW1vcnkgb3IgY3J5cHRvIG9mZmxvYWQg aGFyZHdhcmUgd2lsbCBiZSBhIHByaW9yaXR5IG92ZXIgb3RoZXIgZmVhdHVyZXMuIFRoZSBxdWVz dGlvbiBXZXMgcmFpc2VkIGFzIHRvIHdoZXRoZXIgd2UsIGFzIGEgd29ya2luZy1ncm91cCwgYXJl IGhhcHB5IHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCB0aGlzIGlzIHRoZSBjYXNlLCBpcyB2ZXJ5 IHZhbGlkLiBJdCB3b3VsZCBzZWVtIHRvIG1lIHRoYXQgd2UgYXJlIGJlaW5nIHNvbWV3aGF0IHBy ZXNjcmlwdGl2ZSB3aXRoIHByaW9yaXRpc2luZyB3aGF0IGhhcmR3YXJlIHZlbmRvcnMnIHNvbHV0 aW9ucyBzaG91bGQgbG9vayBsaWtlLCBhbmQgd2hhdCBvcGVyYXRvcidzIHNjYWxpbmcgYXBwcm9h Y2hlcyB3aWxsIGxvb2sgbGlrZSAtIHdpdGhvdXQgbmVjZXNzYXJpbHkgZXhwbGljaXRseSBkaXNj dXNzaW5nIHdoeSB0aGlzIGlzIHJlYXNvbmFibGUgdG8gZG8gc28uDQo+IA0KPiAtIEFyZSB0aGUg YXNzdW1wdGlvbnMgdGhhdCB3ZSBhcmUgbWFraW5nIHJlZ2FyZGluZyBob3cgdGhvc2UgYXV0b25v bW91cyBzeXN0ZW1zIGRlbGl2ZXJpbmcgYW4gIkludGVybmV0IiBwcm9kdWN0IHNldCBhcmUgYXJj aGl0ZWN0ZWQgdmFsaWQ/IFRoZXJlIGlzIHNvbWUgYXNzdW1wdGlvbiAoQUlVSSwgcGxlYXNlIGZl ZWwgZnJlZSB0byBjb3JyZWN0IG1lKSB0aGF0IHdlIGFyZSBsb29raW5nIGF0IG5ldHdvcmtzIHdo ZXJlIHdlIGhhdmUgZXhwbGljaXQgZWRnZSBkZXZpY2VzIHdoaWNoIGNhbiBzY2FsZSB0byBtZWV0 IHRoZSB2YWxpZGF0aW9uIHdvcmtsb2FkIHRoYXQgd2UncmUgcHV0dGluZyBvbiBpdC4gVGhpcyB3 b3VsZCBzZWVtIChhZ2FpbiwgdG8gbWUpIHRvIGJlIGJhc2VkIGFyb3VuZCBhc3N1bXB0aW9uIHRo YXQgdGhlcmUgYXJlIGEgcmVsYXRpdmVseSBoaWdoIG51bWJlciBvZiBsZXNzLWRlbnNlIGVkZ2Ug ZGV2aWNlcy4gSSB3b3VsZCBiZSBpbnRlcmVzdGVkIHdoZXRoZXIgaXQncyB0aGUgZmVlbGluZyBv ZiB0aGUgV0cgdGhhdCBteSByZWFkaW5nIG9mIHdoYXQgd2UncmUgYXNzdW1pbmcgaXMgY29ycmVj dCAtIGFuZCBpZiBzbywgd2hldGhlciB0aGUgV0cgZmVlbHMgdGhhdCB3ZSBjYW4gYmUgcHJlc2Ny aXB0aXZlIGxpa2UgdGhpcyBmb3IgaG93IG9uZSBzaG91bGQgYXJjaGl0ZWN0IGFuIEludGVybmV0 IG5ldHdvcmsuDQo+IA0KPiBJJ20gYWdhaW4gdmVyeSBzdXBwb3J0aXZlIG9mIHdoYXQgcHJvYmxl bXMgYmdwc2VjIGlzIHRyeWluZyB0byBzb2x2ZSAtIGFuZCBkbyBub3Qgd2FudCB0byBwdXQgYSBk YW1wZW5lciBvbiBhbnkgb2YgdGhlIGV4Y2VsbGVudCBlZmZvcnRzIHRoYXQgaGF2ZSBnb25lIGlu dG8gaXQgLSBidXQgdGhpbmsgdGhhdCB3ZSBjYW5ub3Qgd2hvbGx5IGFic3RyYWN0IG91cnNlbHZl cyBhd2F5IGZyb20gdGhlIGFjdHVhbCBkZXBsb3lhYmlsaXR5IG9mIHRoZSBzb2x1dGlvbnMgdGhh dCBhcmUgYmVpbmcgZGV2ZWxvcGVkLiBBZnRlciBhbGwsIHdlIHdpbGwgbm90IHNvbHZlIHRoZSBw cm9ibGVtcyB0aGF0IHRoZSBXRyBpcyBjaGFydGVyZWQgdG8gc29sdmUgaWYgdGhlIGZydWl0cyBv ZiB0aGUgbGFib3VycyBoZXJlaW4gYXJlIG5vdCBhY3R1YWxseSBkZXBsb3llZC4NCj4gDQo+IEkg YW0gbm90IHN1cmUgb2YgZXhhY3RseSBob3cgd2UgcHJvZ3Jlc3MgZGlzY3Vzc2luZyB0aGUgc2Nh bGFiaWxpdHkgb2YgdGhlIHNvbHV0aW9uIC0gYnV0IHdpdGggU3JpcmFtJ3MgYW5hbHlzaXMsIGlz IGl0IHBvc3NpYmxlIHRvIGRpc2N1c3Mgd2l0aGluIHRoaXMgZm9ydW0sIGFuZCBwZXJoYXBzIG90 aGVycyBjb25jZXJuZWQgd2l0aCB0aGUgZ2VuZXJhbCBzY2FsaW5nIG9mIElQIHJvdXRpbmcgZWxl bWVudHMsIHdoeSB0aGUgc2NhbGluZyBjb25zaWRlcmF0aW9ucy9hc3N1bXB0aW9ucyBvZiBiZ3Bz ZWMgYXJlIHZhbGlkLCBhbmQgd2hlcmUgYSBkZXBhcnR1cmUgaXMgbWFkZSBmcm9tIHRoZSBsb25n ZXIgdGVybSB2aWV3IG9mIHNjYWxhYmlsaXR5IHRoYXQgaXMgcHJlc2VudGVkIGluIGV4aXN0aW5n IElFVEYgZG9jdW1lbnRzLg0KPiANCj4gVGhhbmtzIGZvciByZWFkaW5nIHRoaXMgLSBhbmQgeW91 ciBjb25zaWRlcmF0aW9uIQ0KPiByLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpZHIgbWFpbGluZyBsaXN0 DQo+IHNpZHJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaWRyDQo= From randy@psg.com Wed Sep 7 06:35:18 2011 Return-Path: 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 C4FB121F8C04 for ; Wed, 7 Sep 2011 06:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzLbMtIgqNr8 for ; Wed, 7 Sep 2011 06:35:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 641AC21F8BB1 for ; Wed, 7 Sep 2011 06:35:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1IJI-000BNT-TL; Wed, 07 Sep 2011 13:37:01 +0000 Date: Wed, 07 Sep 2011 15:36:58 +0200 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 13:35:18 -0000 lots of great opinions, but are there actually any measurements or models? randy From rjs@rob.sh Wed Sep 7 07:46:26 2011 Return-Path: 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 C419D21F8A71 for ; Wed, 7 Sep 2011 07:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW-AIlI+wFIv for ; Wed, 7 Sep 2011 07:46:23 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 275E621F84F6 for ; Wed, 7 Sep 2011 07:46:23 -0700 (PDT) Received: from [195.10.56.30] (helo=[212.137.15.246]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1R1JOt-0006DP-Og; Wed, 07 Sep 2011 15:46:51 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> Date: Wed, 7 Sep 2011 15:48:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> To: Jakob Heitz X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 14:46:26 -0000 On 7 Sep 2011, at 14:12, Jakob Heitz wrote: > While a router that performs BGPSEC may not be more expensive in 5 = years than one that does not today, that is not relevant. A router that = performs BGPSEC in 5 years will most definitely cost more to produce as = well as cost more to run than a router that does not perform BGPSEC in 5 = years. >=20 > So, a question for you Rob. Will your customers pay the premium for = BGP security? Hi Jakob, This is of course an interesting question - which comes down to the = question of whether the threats that are being addressed by bgpsec are = common-place. I definitely have customers that would pay a premium to = mitigate this as a DoS vector, or malicious interception mechanism, but = equally, have customers who would not, based on their current = experience. =46rom what I have seen of the demand for origin validation at the = current time, I would say that my personal opinion (and no dataset to = support this, sorry) is that any willingness to pay a premium will grow = relatively slowly. As such, this makes the point about trying to ensure = that we have a deployable protocol that attempts to represent the = smallest step change it can in terms of computational requirements more = important to me - since this will mean that it is easier to begin = deploying, and meeting the demand. Kind regards, r.= From wesley.george@twcable.com Wed Sep 7 08:07:36 2011 Return-Path: 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 9771521F8B2D for ; Wed, 7 Sep 2011 08:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWHr35VXR5qH for ; Wed, 7 Sep 2011 08:07:36 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id CADA121F8ADE for ; Wed, 7 Sep 2011 08:07:31 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,492,1309752000"; d="scan'208";a="255984502" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Sep 2011 11:08:06 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 7 Sep 2011 11:09:19 -0400 From: "George, Wesley" To: Jakob Heitz , Rob Shakir Date: Wed, 7 Sep 2011 11:09:18 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxtX9RRciuxpYOPRTmM125yD16/7AACn23Q Message-ID: <34E4F50CAFA10349A41E0756550084FB0DF09612@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> In-Reply-To: <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:07:36 -0000 -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Jak= ob Heitz Sent: Wednesday, September 07, 2011 9:13 AM Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) So, a question for you Rob. Will your customers pay the premium for BGP sec= urity? WEG] This question is a good one, as it makes the difference between a cape= x driver with no projected bottom-line improvement and a potential revenue = stream. We've seen the "unfunded mandate" movie before. It's one of the rea= sons that IPv6 deployment took so long - "yeah we have to spend $xxM to upgrade the network and our systems to suppo= rt IPv6." "Ok, how much extra can we charge for that?" "Um...yeah, about that... but if we don't have it soon, our customers will = leave us and we might run out of IP addresses..." "I haven't had any customers ask me for it...when is soon?" "Maybe 12-18 months?" "Ok, let's do it next year then." (lather, rinse, repeat for several years) My guess is that the union of who is willing to pay for it and what they're= willing to pay likely won't cover the SP's costs to implement it. Generall= y security is one of those things that either is critical, cost-no-object o= r is seen as optional if the threat of impact is low enough compared with t= he cost of avoidance/prevention. I think that the threat risk BGPSec is add= ressing is seen as pretty low by the vast majority of small to medium enter= prises if they've never been hit by it. Heck, we've recently seen some very= large companies get burned for not having properly invested in security in= areas where the threat model was a bit more obviously risky (Sony)... The sales pitch for BGPSec, especially in an incremental deployment model w= ill have a lot of bearing on that perceived level of risk and our collectiv= e ability to mitigate it. If we're successful, maybe it becomes a sustainab= le investment. However, it's risky to assume that this will cover the added= cost burden completely. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From ietfc@btconnect.com Wed Sep 7 09:28:23 2011 Return-Path: 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 B4FD621F8B84 for ; Wed, 7 Sep 2011 09:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+QFj4YW4S3N for ; Wed, 7 Sep 2011 09:28:23 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id C628721F8B70 for ; Wed, 7 Sep 2011 09:28:22 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2bthomr09.btconnect.com with SMTP id EIP35085; Wed, 07 Sep 2011 17:30:07 +0100 (BST) Message-ID: <004401cc6d72$78cb7200$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Rob Shakir" , "Jakob Heitz" References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org><87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net><331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com><34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com><7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh><5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> Date: Wed, 7 Sep 2011 17:26:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4E679C0F.003E, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.7.152714:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4E679C10.01DD,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 16:28:23 -0000 ----- Original Message ----- From: "Rob Shakir" To: "Jakob Heitz" Cc: "sidr wg list" Sent: Wednesday, September 07, 2011 4:48 PM > > On 7 Sep 2011, at 14:12, Jakob Heitz wrote: > > > While a router that performs BGPSEC may not be more expensive in 5 years than one that does not today, that is not relevant. A router that performs BGPSEC in 5 years will most definitely cost more to produce as well as cost more to run than a router that does not perform BGPSEC in 5 years. > > > > So, a question for you Rob. Will your customers pay the premium for BGP security? > > Hi Jakob, > > This is of course an interesting question - which comes down to the question of whether the threats that are being addressed by bgpsec are common-place. I definitely have customers that would pay a premium to mitigate this as a DoS vector, or malicious interception mechanism, but equally, have customers who would not, based on their current experience. > > From what I have seen of the demand for origin validation at the current time, I would say that my personal opinion (and no dataset to support this, sorry) is that any willingness to pay a premium will grow relatively slowly. As such, this makes the point about trying to ensure that we have a deployable protocol that attempts to represent the smallest step change it can in terms of computational requirements more important to me - since this will mean that it is easier to begin deploying, and meeting the demand. > My own experience of promoting security (and for that matter resilience) is that very few organisations are willing to spend until after disaster strikes. And when that happens, anyone without a solution ready is in trouble, so the onus on us is to have specified a viable solution, the implementation of which is as cheap as possible but no cheaper. Then, when the evil empires turn to Internet routing, as opposed to, say, e-mail, at least we can say that we did our part to prevent it. Promoting new functionality that turns straightaway into more revenue is the easy part and it is rare for security to come in that category. Tom Petch > Kind regards, > r. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From wesley.george@twcable.com Wed Sep 7 11:55:33 2011 Return-Path: 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 5F3C021F8CDF for ; Wed, 7 Sep 2011 11:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXh9RbTNEfRU for ; Wed, 7 Sep 2011 11:55:32 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id B978521F8CDC for ; Wed, 7 Sep 2011 11:55:32 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,493,1309752000"; d="scan'208";a="270830614" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Sep 2011 14:55:03 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 7 Sep 2011 14:57:22 -0400 From: "George, Wesley" To: Randy Bush , Jakob Heitz Date: Wed, 7 Sep 2011 14:57:21 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxtYzyHBnyJQC9FTH+zb2RjrWNOEQAAVXWA Message-ID: <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 18:55:33 -0000 -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Wednesday, September 07, 2011 9:37 AM Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) lots of great opinions, but are there actually any measurements or models? WEG] Please be more specific. What other models and measurements than the o= ne already provided by NIST are you asking for? That model already tells me= that BGPSec will significantly change the routing table scaling curve from= today, with some variation on the steepness of the change possible based o= n variables and optimization. Your non-response to the concern about whethe= r the situation articulated by 4984, & 6227 has changed in some material wa= y as to make it no longer an issue for BGPSec is telling. Let's keep turnin= g up the heat and hope that the frog doesn't notice until it's too late... My guess from your response above is that you're looking for some anecdotal= evidence of equipment lifetimes in real networks to support Rob's assertio= n that 5 years may not be a realistic event horizon, so I'll take a stab at= that. There are plenty of 15-year old routing platforms still in service, despite= YFV's best efforts to make them obsolete. Only recently has a combination of End of Support and a need for new featur= es and higher density driven the oldest of the hardware (GSR E0, 1, 2, 4/4+= , 10720, the 7200 and 7500 in Ciscoland) out of the network. Some of that s= tuff dated back to the early 2000s and was just removed in the last 12-24 m= onths. Most accounting still assumes at least a 7-year depreciation cycle, = and that seems somewhere between appropriate and optimistic, given that a l= ot of the gear was closer to 8 or even 10 years old at retirement. On the route processor side, which is probably most pertinent to this discu= ssion, upgrades were almost exclusively driven by the memory requirements o= f the routing table + the code footprint. RPs are either purchased with max= supported memory so that they don't have to be touched again, (because tou= ches are expensive) or they are upgraded periodically because the max has b= een increased. So the next replacement-level upgrade happens when the curre= nt max (4Gig in the last round of upgrades) isn't enough, which will take a= while with just organic DFZ routing growth. My recollection was about a 6 = year total replacement cycle. However, in hard-core bellhead beancounter ci= rcles, the concept of needing to invest in upgrades to a routing platform b= eyond adding raw port capacity every few years is totally foreign, because = they have DMS-250 and DCS systems that have been in the network since Moses= gave them the owner's manual on stone tablets and are still generating rev= enue with only occasional replacement parts. Something like BGPSec makes th= e discussion with the finance people all the more fun, because now we're ha= ving to justify spending significantly more on gear that does not directly = translate to additional revenue port capacity, vs justifying "must do x to = keep the network from falling over." In zero-margin "race to the bottom" networks, that's not trivial. Thanks, Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Donald.Smith@CenturyLink.com Wed Sep 7 13:18:02 2011 Return-Path: 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 2182821F8B4F for ; Wed, 7 Sep 2011 13:18:02 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vjrTFUMAUGj for ; Wed, 7 Sep 2011 13:18:01 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB721F8B4E for ; Wed, 7 Sep 2011 13:18:01 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p87KJjgr008004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 15:19:45 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 26A2B1E0060; Wed, 7 Sep 2011 14:19:40 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 0251A1E005B; Wed, 7 Sep 2011 14:19:39 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p87KJdvY027501; Wed, 7 Sep 2011 15:19:39 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (qtdenexhtm22.ad.qintra.com [151.119.91.231]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p87KJdJJ027491 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 7 Sep 2011 15:19:39 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 7 Sep 2011 14:19:37 -0600 From: "Smith, Donald" To: "'Jakob Heitz'" , "'Rob Shakir'" Date: Wed, 7 Sep 2011 14:19:35 -0600 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxtX9RRciuxpYOPRTmM125yD16/7AAOrrjg Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> In-Reply-To: <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'sidr wg list' Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 20:18:02 -0000 I would guess you would get a very low take rate on "secure bgp" even if yo= u gave it away (no premium). It would be interesting to see how many customers implemented MD5 for bgp p= eering sessions when it became freely available. It wasn't very widely deployed the last time I heard. It got a ton of push back on the NANOG list when I recommended it. Ignorance is Bliss. "Bliss (Basic Language for Implementation of System Sof= tware) was a systems programming language originally for the PDP-10 and DECsystem-20 wri= tten at CMU." Kevin Oberman RTD Donald.Smith@CenturyLink.com > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Jakob Heitz > Sent: Wednesday, September 07, 2011 7:13 AM > To: Rob Shakir > Cc: sidr wg list > Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > > While a router that performs BGPSEC may not be more expensive in 5 > years than one that does not today, that is not relevant. A router that > performs BGPSEC in 5 years will most definitely cost more to produce as > well as cost more to run than a router that does not perform BGPSEC in > 5 years. > > So, a question for you Rob. Will your customers pay the premium for BGP > security? > > -- > Jakob Heitz. > > > On Sep 7, 2011, at 5:05 AM, "Rob Shakir" wrote: > > > On 11 Aug 2011, at 22:40, George, Wesley wrote: > > > >> Danny said, > >> "Periodic updates of the entire routing table *with much larger and > more updates* seems undesirable at best to me, particularly to 'reduce > the vulnerability window for replay attacks' to 'days'." > >> --------------------------------------------------------- > >> I think that this is a small part of a much larger issue that has > been bugging me since our meeting in Quebec City. > >> After looking at Sriram's estimates around the necessary amount of > memory, etc for the different algorithms, I'm bothered by what is being > asked of the routing system in support of BGPSec. > >> > > > > Hi All, > > > > Wes' point here is really important I think, and it's a bit of a > shame it hasn't got more focus. I stood up and mentioned scaling in > Prague, then found myself making a very similar point again in Qu=E9bec. > As with Wes, I would prefer that this is not interpreted as a criticism > of the goals of bgpsec, but rather is an operational perspective on the > assumptions that are made for deployment of the protocols being > developed in sidr. > > > > The root assumption that we seem to be taking as read throughout such > discussions is that at the point where routing infrastructure is > expected to support the computational load that is demanded of it by > bgpsec, there will have been sufficient growth in both the > computational and memory resources that are available to these systems. > Whilst I appreciate that cryptographic validation of the validity of a > route can be performed on the edge system(s), I think there are two > very key concerns here. > > > > - Historically, do we see Internet routing systems matching the rate > of general computational resource availability? My view on this is that > we do not - there are plenty of edge systems out there that are > relatively modern (and capable of routing tens of gigabits of traffic) > that do not have a control-plane that is as powerful as some of the > software devices that existed prior to it - as such, this means either > this was a lower priority to deliver (which may well be true), or that > it was not practical to do so. With increasing demands on control-plane > resources of IP systems (be they Internet edge or otherwise) - there is > surely some query as to whether having a large amount of memory or > crypto offload hardware will be a priority over other features. The > question Wes raised as to whether we, as a working-group, are happy > with the assumption that this is the case, is very valid. It would seem > to me that we are being somewhat prescriptive with prioritising what > hardware vendors' solutions should look like, and what operator's > scaling approaches will look like - without necessarily explicitly > discussing why this is reasonable to do so. > > > > - Are the assumptions that we are making regarding how those > autonomous systems delivering an "Internet" product set are architected > valid? There is some assumption (AIUI, please feel free to correct me) > that we are looking at networks where we have explicit edge devices > which can scale to meet the validation workload that we're putting on > it. This would seem (again, to me) to be based around assumption that > there are a relatively high number of less-dense edge devices. I would > be interested whether it's the feeling of the WG that my reading of > what we're assuming is correct - and if so, whether the WG feels that > we can be prescriptive like this for how one should architect an > Internet network. > > > > I'm again very supportive of what problems bgpsec is trying to solve > - and do not want to put a dampener on any of the excellent efforts > that have gone into it - but think that we cannot wholly abstract > ourselves away from the actual deployability of the solutions that are > being developed. After all, we will not solve the problems that the WG > is chartered to solve if the fruits of the labours herein are not > actually deployed. > > > > I am not sure of exactly how we progress discussing the scalability > of the solution - but with Sriram's analysis, is it possible to discuss > within this forum, and perhaps others concerned with the general > scaling of IP routing elements, why the scaling > considerations/assumptions of bgpsec are valid, and where a departure > is made from the longer term view of scalability that is presented in > existing IETF documents. > > > > Thanks for reading this - and your consideration! > > r. > > > > > > > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From robert@raszuk.net Wed Sep 7 13:42:21 2011 Return-Path: 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 0B40C21F8B6E for ; Wed, 7 Sep 2011 13:42:21 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWFQg6eaWd0K for ; Wed, 7 Sep 2011 13:42:20 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 4715621F8B5F for ; Wed, 7 Sep 2011 13:42:20 -0700 (PDT) Received: (qmail 15816 invoked by uid 399); 7 Sep 2011 20:44:07 -0000 Received: from unknown (HELO ?216.69.69.180?) (216.69.69.180) by mail37.opentransfer.com with SMTP; 7 Sep 2011 20:44:07 -0000 Message-ID: <4E67D797.70105@raszuk.net> Date: Wed, 07 Sep 2011 22:44:07 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 20:42:21 -0000 Hi, Securing BGP really means transitioning from 100% distributed control of today's BGPv4 based Internet to new layer of Internet control to be build for BGPSec (for that matter for BGP Origin Validation too). IMHO scaling aspects are serious, but are not the most serious reg discussion of acceptance of not for this new layer of control. And that is not something one can address by dedicated crypto engine processing or better PR CPU. It would be IMHO very interesting to see more discussions in the community on the fundamental aspects of risks such new layer of control may bring or cause to the Internet as we know it today. Rgs, R. From kotikalapudi.sriram@nist.gov Wed Sep 7 14:50:01 2011 Return-Path: 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 8CA8721F8B26 for ; Wed, 7 Sep 2011 14:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLVAjn+RXyp4 for ; Wed, 7 Sep 2011 14:50:01 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id E584F21F855D for ; Wed, 7 Sep 2011 14:50:00 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Wed, 7 Sep 2011 17:51:35 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 7 Sep 2011 17:51:15 -0400 From: "Sriram, Kotikalapudi" To: "George, Wesley" , sidr wg list Date: Wed, 7 Sep 2011 17:51:45 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxXlRYzx19OWW9WR+qLPmTOJN+B3gAtymVABVV7wuA= Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 21:50:01 -0000 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of George, Wesley > Sent: Thursday, August 11, 2011 5:41 PM > -- snip -- > > As far as where this leaves BGPSec, I don't know. Perhaps a solution comes in the form of > some of us starting to champion the necessary work to move one or more of the better ideas > from RRG into implementation so that the underlying scaling problem is being addressed in > parallel. It should be quite possible to incorporate improvements to route security into > whatever must already be done to improve scale, and even if not, these are two things that > both share a barrier to deployment, especially incrementally, and would certainly benefit > from being designed and deployed in concert instead of in separate silos. > > Thanks > Wes George Wes, Sorry for the belated response -- I was away in India on vacation :) We had some discussion earlier on this list about BGPSEC in conjunction with an RRG scalability solution (e.g., LISP). (You might have seen these posts back in May, but just in case.) http://www.ietf.org/mail-archive/web/sidr/current/msg02836.html http://www.ietf.org/mail-archive/web/sidr/current/msg02837.html http://www.ietf.org/mail-archive/web/sidr/current/msg02847.html These posts relate only to the above noted comment from you (but not directly to a different question you've raised w.r.t. the concerns in 4984/6227). Sriram From shane@castlepoint.net Wed Sep 7 18:34:23 2011 Return-Path: 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 43EDF21F8888 for ; Wed, 7 Sep 2011 18:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FqKG35m5CeB for ; Wed, 7 Sep 2011 18:34:22 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 78ACB21F886D for ; Wed, 7 Sep 2011 18:34:22 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 1B87D26806D; Wed, 7 Sep 2011 19:36:13 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 07 Sep 2011 19:36:12 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=64576; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> Date: Wed, 7 Sep 2011 19:35:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <43D6CC7E-68B8-4E77-9FE9-37E9920F2380@castlepoint.net> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 01:34:23 -0000 Wes, Excellent points, which I agree with. One additional point below. On Sep 7, 2011, at 12:57 PM, George, Wesley wrote: > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, September 07, 2011 9:37 AM > Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) >=20 > lots of great opinions, but are there actually any measurements or > models? >=20 > WEG] Please be more specific. What other models and measurements than = the one already provided by NIST are you asking for? That model already = tells me that BGPSec will significantly change the routing table scaling = curve from today, with some variation on the steepness of the change = possible based on variables and optimization. Your non-response to the = concern about whether the situation articulated by 4984, & 6227 has = changed in some material way as to make it no longer an issue for BGPSec = is telling. Let's keep turning up the heat and hope that the frog = doesn't notice until it's too late... >=20 > My guess from your response above is that you're looking for some = anecdotal evidence of equipment lifetimes in real networks to support = Rob's assertion that 5 years may not be a realistic event horizon, so = I'll take a stab at that. >=20 > There are plenty of 15-year old routing platforms still in service, = despite YFV's best efforts to make them obsolete. > Only recently has a combination of End of Support and a need for new = features and higher density driven the oldest of the hardware (GSR E0, = 1, 2, 4/4+, 10720, the 7200 and 7500 in Ciscoland) out of the network. = Some of that stuff dated back to the early 2000s and was just removed in = the last 12-24 months. Most accounting still assumes at least a 7-year = depreciation cycle, and that seems somewhere between appropriate and = optimistic, given that a lot of the gear was closer to 8 or even 10 = years old at retirement. > On the route processor side, which is probably most pertinent to this = discussion, upgrades were almost exclusively driven by the memory = requirements of the routing table + the code footprint. RPs are either = purchased with max supported memory so that they don't have to be = touched again, (because touches are expensive) or they are upgraded = periodically because the max has been increased. So the next = replacement-level upgrade happens when the current max (4Gig in the last = round of upgrades) isn't enough, which will take a while with just = organic DFZ routing growth. Let's also not forget that all routing platforms deployed in the field = /ARE NOT/ created "equal" with respect to the _potential_ for just = Routing Engine upgrades, just to gain more CPU and/or DRAM. = Specifically, I'm referring to Router HW architectures where the Routing = Engine is co-resident on the same physical LC, (sometimes the RE is a = daughtercard, other times it is not), on a centralized Switch Fabric = Module. Up until now, the upgrade strategy to get faster CPU or more = DRAM, from the vendors who have shipped these platforms, is to replace = the entire LC (that means: CPU, DRAM (RE) _and_ the SFM) ... even if the = chassis/system did not require the additional forwarding capacity = offered by the new SFM. Or, worse, sometimes said fabric upgrades cause = "legacy" LC's to no longer be supported!!! -- hello whole chassis = upgrade ... Of course, this could change for future generations of = platforms, but it doesn't solve for what's already deployed and = continues to be deployed, today, in the field. -shane > My recollection was about a 6 year total replacement cycle. However, = in hard-core bellhead beancounter circles, the concept of needing to = invest in upgrades to a routing platform beyond adding raw port capacity = every few years is totally foreign, because they have DMS-250 and DCS = systems that have been in the network since Moses gave them the owner's = manual on stone tablets and are still generating revenue with only=20 > occasional replacement parts. Something like BGPSec makes the = discussion with the finance people all the more fun, because now we're = having to justify spending significantly more on gear that does not = directly translate to additional revenue port capacity, vs justifying = "must do x to keep the network from falling over." > In zero-margin "race to the bottom" networks, that's not trivial. >=20 > Thanks, >=20 > Wes >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Wed Sep 7 19:40:24 2011 Return-Path: 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 5582121F8C71 for ; Wed, 7 Sep 2011 19:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJtvNZbLreDk for ; Wed, 7 Sep 2011 19:40:23 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8A7C21F8C6F for ; Wed, 7 Sep 2011 19:40:23 -0700 (PDT) Received: by gyd12 with SMTP id 12so286613gyd.31 for ; Wed, 07 Sep 2011 19:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7VeKqBKX1VpK/bNU/82/FoBghq4D8ngjcTYf+BQTC3A=; b=V7hJ9tlSFFQEOPpEW7Hn/EhaLrpWeirSpNY0m84fOmAV8O5k6vR+BEEiDX/uV/rMak 9UdZgyKRVMcODVIrFKN7dxaii8HgXlGTu6g/CikdLSLyz3OKgpujoZ4P9y1ynBcBU5Rr sYKZXZCEHTygUtUmO3HR0B3T4Mli5zfJQSfuM= MIME-Version: 1.0 Received: by 10.231.0.80 with SMTP id 16mr89940iba.93.1315449734291; Wed, 07 Sep 2011 19:42:14 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.162.73 with HTTP; Wed, 7 Sep 2011 19:42:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Sep 2011 22:42:14 -0400 X-Google-Sender-Auth: b-RlrwMhhbNrOcXWzBhpqWe-D-c Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 02:40:24 -0000 We seem to have sat on this a bit and cogitated... are we prepared to call -02 'good enough to progress' and ask for WGLC?? -Chris On Wed, Jun 22, 2011 at 5:14 AM, Terry Manderson wrote: > The second ROA (ROA 2) below would of course be address=A010.1.0.0/20 > maxlength =A020. > Apologies for the cut/paste error. > Cheers > Terry > On 22/06/2011, at 11:37 AM, "Terry Manderson" > wrote: > > a single ROA with: > =A0=A0=A0=A0=A0+----------------------------------------------+ > =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| > =A0=A0=A0=A0=A0+----------------------------------------------+ > =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0=A0= =A016 =A0=A0=A0=A0=A0=A0=A0=A0| > =A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0|----------------------------= -------+ > =A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0| 10.1.0.0/20 =A0=A0=A0=A0=A0= =A0| =A0=A0=A020 =A0=A0=A0=A0=A0=A0=A0=A0| > =A0=A0=A0=A0=A0+----------------------------------------------+ > > versus 2 ROAs that contain > > =A0=A0=A0=A0=A0ROA 1 > =A0=A0=A0=A0=A0+----------------------------------------------+ > =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| > =A0=A0=A0=A0=A0+----------------------------------------------+ > =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0=A0= =A016 =A0=A0=A0=A0=A0=A0=A0=A0| > =A0=A0=A0=A0=A0+----------------------------------------------+ > > =A0=A0=A0=A0=A0ROA 2 > =A0=A0=A0=A0=A0+----------------------------------------------+ > =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| > =A0=A0=A0=A0=A0+----------------------------------------------+ > =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0=A0= =A016 =A0=A0=A0=A0=A0=A0=A0=A0| > =A0=A0=A0=A0=A0+----------------------------------------------+ > > Cheers > Terry > > On 22/06/11 11:25 AM, "internet-drafts@ietf.org" > wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Secure Inter-Domain Routing > > Working Group of the IETF. > > =A0=A0=A0=A0=A0=A0=A0Title =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: Use Cases and = Interpretation of RPKI Objects for > > Issuers and Relying Parties > > =A0=A0=A0=A0=A0=A0=A0Author(s) =A0=A0=A0=A0=A0=A0: Terry Manderson > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Kotikalapudi Sriram > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Russ White > > =A0=A0=A0=A0=A0=A0=A0Filename =A0=A0=A0=A0=A0=A0=A0: draft-ietf-sidr-usec= ases-02.txt > > =A0=A0=A0=A0=A0=A0=A0Pages =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 30 > > =A0=A0=A0=A0=A0=A0=A0Date =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2011-06-21 > > =A0=A0This document provides use cases, directions, and interpretations f= or > > =A0=A0organizations and relying parties when creating or encountering RPK= I > > =A0=A0object scenarios in the public RPKI in relation to the Internet > > =A0=A0routing system. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From terry.manderson@icann.org Wed Sep 7 21:15:15 2011 Return-Path: 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 8E24B21F8B5F for ; Wed, 7 Sep 2011 21:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LRcj0Y2k97S for ; Wed, 7 Sep 2011 21:15:14 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id E203521F8B2B for ; Wed, 7 Sep 2011 21:15:14 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 7 Sep 2011 21:17:05 -0700 From: Terry Manderson To: Christopher Morrow Date: Wed, 7 Sep 2011 21:17:03 -0700 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt Thread-Index: Acxt0Pc5QnSejnoqSLmY82/ZxYPT1wADTIVO Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 04:15:15 -0000 Chris, I have seen no further feedback on the document - we (the authors) believe it is move on, can we please request a WGLC? Cheers Terry On 8/09/11 12:42 PM, "Christopher Morrow" wrote: > We seem to have sat on this a bit and cogitated... are we prepared to > call -02 'good enough to progress' and ask for WGLC?? >=20 > -Chris >=20 > On Wed, Jun 22, 2011 at 5:14 AM, Terry Manderson > wrote: >> The second ROA (ROA 2) below would of course be address=A010.1.0.0/20 >> maxlength =A020. >> Apologies for the cut/paste error. >> Cheers >> Terry >> On 22/06/2011, at 11:37 AM, "Terry Manderson" >> wrote: >>=20 >> a single ROA with: >> =A0=A0=A0=A0=A0+----------------------------------------------+ >> =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| >> =A0=A0=A0=A0=A0+----------------------------------------------+ >> =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0=A0= =A016 =A0=A0=A0=A0=A0=A0=A0=A0| >> =A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0|---------------------------= --------+ >> =A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0| 10.1.0.0/20 =A0=A0=A0=A0= =A0=A0| =A0=A0=A020 =A0=A0=A0=A0=A0=A0=A0=A0| >> =A0=A0=A0=A0=A0+----------------------------------------------+ >>=20 >> versus 2 ROAs that contain >>=20 >> =A0=A0=A0=A0=A0ROA 1 >> =A0=A0=A0=A0=A0+----------------------------------------------+ >> =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| >> =A0=A0=A0=A0=A0+----------------------------------------------+ >> =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0=A0= =A016 =A0=A0=A0=A0=A0=A0=A0=A0| >> =A0=A0=A0=A0=A0+----------------------------------------------+ >>=20 >> =A0=A0=A0=A0=A0ROA 2 >> =A0=A0=A0=A0=A0+----------------------------------------------+ >> =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| >> =A0=A0=A0=A0=A0+----------------------------------------------+ >> =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0=A0= =A016 =A0=A0=A0=A0=A0=A0=A0=A0| >> =A0=A0=A0=A0=A0+----------------------------------------------+ >>=20 >> Cheers >> Terry >>=20 >> On 22/06/11 11:25 AM, "internet-drafts@ietf.org" >> wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>=20 >> directories. This draft is a work item of the Secure Inter-Domain Routin= g >>=20 >> Working Group of the IETF. >>=20 >> =A0=A0=A0=A0=A0=A0=A0Title =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: Use Cases and= Interpretation of RPKI Objects for >>=20 >> Issuers and Relying Parties >>=20 >> =A0=A0=A0=A0=A0=A0=A0Author(s) =A0=A0=A0=A0=A0=A0: Terry Manderson >>=20 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Kotikalapudi Sriram >>=20 >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Russ White >>=20 >> =A0=A0=A0=A0=A0=A0=A0Filename =A0=A0=A0=A0=A0=A0=A0: draft-ietf-sidr-use= cases-02.txt >>=20 >> =A0=A0=A0=A0=A0=A0=A0Pages =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 30 >>=20 >> =A0=A0=A0=A0=A0=A0=A0Date =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2011-06-21 >>=20 >> =A0=A0This document provides use cases, directions, and interpretations = for >>=20 >> =A0=A0organizations and relying parties when creating or encountering RP= KI >>=20 >> =A0=A0object scenarios in the public RPKI in relation to the Internet >>=20 >> =A0=A0routing system. >>=20 >>=20 >> A URL for this Internet-Draft is: >>=20 >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >>=20 >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >>=20 >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt >>=20 >> _______________________________________________ >>=20 >> sidr mailing list >>=20 >> sidr@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >>=20 From christopher.morrow@gmail.com Wed Sep 7 21:41:06 2011 Return-Path: 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 DBFF521F852C for ; Wed, 7 Sep 2011 21:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c53-DFp+O7TA for ; Wed, 7 Sep 2011 21:41:05 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9445821F8B54 for ; Wed, 7 Sep 2011 21:41:05 -0700 (PDT) Received: by gxk9 with SMTP id 9so632417gxk.40 for ; Wed, 07 Sep 2011 21:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BqbrnLy2rP163eRm+AuVhVtsdq742vk350hRVxsU+5U=; b=h8pgtL6KVlacBBW2HSG5AYTYYWXHeDiAVXueG+OhfRBpHW1BzVPwsMyN9O9f6QGvLU Cx5tJbAk5NYiI52zojzWQGVOZ8/Mtb052Y2l1fJuDFxwHSpDi8wD0O/RBhgd+azTiDsW 43XOMySgcuA4VrB9/idEUxyj3ozClAUUlOs80= MIME-Version: 1.0 Received: by 10.231.5.42 with SMTP id 42mr166782ibt.80.1315456976419; Wed, 07 Sep 2011 21:42:56 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.162.73 with HTTP; Wed, 7 Sep 2011 21:42:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Sep 2011 00:42:56 -0400 X-Google-Sender-Auth: wGYWj7F1F-lOG-rt0OFM7ywudv0 Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 04:41:07 -0000 On Thu, Sep 8, 2011 at 12:17 AM, Terry Manderson wrote: > Chris, > > I have seen no further feedback on the document - we (the authors) believ= e > it is move on, can we please request a WGLC? that sounds like a good plan to me... > > Cheers > Terry > > On 8/09/11 12:42 PM, "Christopher Morrow" wrote= : > >> We seem to have sat on this a bit and cogitated... are we prepared to >> call -02 'good enough to progress' and ask for WGLC?? >> >> -Chris >> >> On Wed, Jun 22, 2011 at 5:14 AM, Terry Manderson >> wrote: >>> The second ROA (ROA 2) below would of course be address=A010.1.0.0/20 >>> maxlength =A020. >>> Apologies for the cut/paste error. >>> Cheers >>> Terry >>> On 22/06/2011, at 11:37 AM, "Terry Manderson" >>> wrote: >>> >>> a single ROA with: >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0= =A0=A016 =A0=A0=A0=A0=A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0|--------------------------= ---------+ >>> =A0=A0=A0=A0=A0| =A0=A0=A0=A0=A0=A0=A0=A0=A0| 10.1.0.0/20 =A0=A0=A0=A0= =A0=A0| =A0=A0=A020 =A0=A0=A0=A0=A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> >>> versus 2 ROAs that contain >>> >>> =A0=A0=A0=A0=A0ROA 1 >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0= =A0=A016 =A0=A0=A0=A0=A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> >>> =A0=A0=A0=A0=A0ROA 2 >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> =A0=A0=A0=A0=A0| asID =A0=A0=A0=A0| address =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0| maxLength =A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> =A0=A0=A0=A0=A0| 64496 =A0=A0=A0| 10.1.0.0/16 =A0=A0=A0=A0=A0=A0| =A0= =A0=A016 =A0=A0=A0=A0=A0=A0=A0=A0| >>> =A0=A0=A0=A0=A0+----------------------------------------------+ >>> >>> Cheers >>> Terry >>> >>> On 22/06/11 11:25 AM, "internet-drafts@ietf.org" >>> wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> >>> directories. This draft is a work item of the Secure Inter-Domain Routi= ng >>> >>> Working Group of the IETF. >>> >>> =A0=A0=A0=A0=A0=A0=A0Title =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: Use Cases an= d Interpretation of RPKI Objects for >>> >>> Issuers and Relying Parties >>> >>> =A0=A0=A0=A0=A0=A0=A0Author(s) =A0=A0=A0=A0=A0=A0: Terry Manderson >>> >>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0Kotikalapudi Sriram >>> >>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0Russ White >>> >>> =A0=A0=A0=A0=A0=A0=A0Filename =A0=A0=A0=A0=A0=A0=A0: draft-ietf-sidr-us= ecases-02.txt >>> >>> =A0=A0=A0=A0=A0=A0=A0Pages =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 30 >>> >>> =A0=A0=A0=A0=A0=A0=A0Date =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2011-06-21 >>> >>> =A0=A0This document provides use cases, directions, and interpretations= for >>> >>> =A0=A0organizations and relying parties when creating or encountering R= PKI >>> >>> =A0=A0object scenarios in the public RPKI in relation to the Internet >>> >>> =A0=A0routing system. >>> >>> >>> A URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-usecases-02.txt >>> >>> _______________________________________________ >>> >>> sidr mailing list >>> >>> sidr@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/sidr >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> >>> > > From christopher.morrow@gmail.com Wed Sep 7 21:46:17 2011 Return-Path: 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 2DF0521F8B36; Wed, 7 Sep 2011 21:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbBe+OARV4YE; Wed, 7 Sep 2011 21:46:16 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74DAF21F8B30; Wed, 7 Sep 2011 21:46:16 -0700 (PDT) Received: by ywe9 with SMTP id 9so352389ywe.31 for ; Wed, 07 Sep 2011 21:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=+JT4N6Iie4ni5lshC7w3iRD6Odoct76sqGEkbELiy1g=; b=P5XoQuvvOtFT5y3DAffpwU4vrMbMQWhzr0+G+vlQD6fq+fMY20orieYsk9eGuMpwx3 yAXPu3KAG4TFVxBKo3+1no8/kYnTavC++TpEfHZqNPa6m47zRqiZykSdu8srZTBKP5/6 Sig15S64J2g+ldrIoVBvKJzW6wTl+a1nGT2Oo= MIME-Version: 1.0 Received: by 10.42.148.133 with SMTP id r5mr91938icv.220.1315457285543; Wed, 07 Sep 2011 21:48:05 -0700 (PDT) Received: by 10.231.162.73 with HTTP; Wed, 7 Sep 2011 21:48:05 -0700 (PDT) Date: Thu, 8 Sep 2011 00:48:05 -0400 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 04:46:17 -0000 Hello work-group-readers, The authors did some significant work on this doc, it seems to have settled into a groove, could we get some input on where this stands? This is a WGLC for the document which should end: 09/22/2011 (Sept 22, 2011 for those with the other flavor of clocks). document link: The abstract: "This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI in relation to the Internet routing system." Please have a final read/comment and let's move things along. Thanks! -Chris From randy@psg.com Wed Sep 7 23:40:48 2011 Return-Path: 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 10F6B21F8C64; Wed, 7 Sep 2011 23:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEhk02RNIN90; Wed, 7 Sep 2011 23:40:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A278221F8C40; Wed, 7 Sep 2011 23:40:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1YJq-000ErM-45; Thu, 08 Sep 2011 06:42:38 +0000 Date: Thu, 08 Sep 2011 08:42:36 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 06:40:48 -0000 i do not think this document is at all ready for publication. someone with time and energy to clean up the wording needs to spend a half day with the poor thing. --- 1.2 i believe that redefining AS and ASN are ill-advised. just refer elsewhere. we readlly do not want to go there. e.g. there are a lot of ASs which are not under a single administrative control. if you insist on defining it, i would probably s/route/as-path/ Aggregate Route makes an assumption that 'more general' and 'specific' are well definined. maybe try something like shorter and longer netmask, or greater or smaller prefix mask length. 'Covering Aggregate' uses 'cover' in its definition, which makes it pretty useless. 'Multi-homed prefix' is 'originated via'. is it transited via/through or originated by/from? ... 3.1. Single Announcement An organization (Org A with ASN 64496) has been allocated the prefix 192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496 such that relying parties interpret the route as intended. look at rfc 5737 IPv4 Address Blocks Reserved for Documentation i could go on and on. essentially this document is sloppy and needs to be seriously cleaned up. randy From terry.manderson@icann.org Thu Sep 8 02:47:13 2011 Return-Path: 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 1F5BA21F8B02; Thu, 8 Sep 2011 02:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjrbpRkM1LcV; Thu, 8 Sep 2011 02:47:12 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id AA3C021F8B01; Thu, 8 Sep 2011 02:47:12 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 8 Sep 2011 02:49:04 -0700 From: Terry Manderson To: Randy Bush , Christopher Morrow Date: Thu, 8 Sep 2011 02:49:02 -0700 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt Thread-Index: Acxt8pEEh32QMWogQbWbpvZgNrsXigAGfjtL Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 09:47:13 -0000 Hi Randy, It strikes me that this is the first time you have read this draft despite the several calls to the WG to do so. That's not bad exactly... just unexpected. On 8/09/11 4:42 PM, "Randy Bush" wrote: > i do not think this document is at all ready for publication. someone > with time and energy to clean up the wording needs to spend a half day > with the poor thing. I'm less interested in your abrupt critique and certainly much more interested in constructive reviews of which you started below and then gave up.. >=20 > --- >=20 > 1.2 i believe that redefining AS and ASN are ill-advised. just refer > elsewhere. we readlly do not want to go there. e.g. there are a lot of > ASs which are not under a single administrative control. >=20 > if you insist on defining it, i would probably s/route/as-path/ >=20 > Aggregate Route makes an assumption that 'more general' and 'specific' > are well definined. maybe try something like shorter and longer > netmask, or greater or smaller prefix mask length. >=20 > 'Covering Aggregate' uses 'cover' in its definition, which makes it > pretty useless. >=20 > 'Multi-homed prefix' is 'originated via'. is it transited via/through > or originated by/from? >=20 > ... >=20 > 3.1. Single Announcement >=20 > An organization (Org A with ASN 64496) has been allocated the prefix > 192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496 > such that relying parties interpret the route as intended. >=20 > look at rfc 5737 IPv4 Address Blocks Reserved for Documentation >From time to time authors choose to use non rfc5737 address blocks as the examples can't often be adequately described or remain uniform with the documentation prefixes. >=20 > i could go on and on. Please do.. send to me off list if you choose. Cheers Terry From randy@psg.com Thu Sep 8 02:57:27 2011 Return-Path: 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 EDDA421F8B35; Thu, 8 Sep 2011 02:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukoWqoT0L5-P; Thu, 8 Sep 2011 02:57:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 865BD21F8B08; Thu, 8 Sep 2011 02:57:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1bO5-000FPn-Pn; Thu, 08 Sep 2011 09:59:14 +0000 Date: Thu, 08 Sep 2011 11:59:02 +0200 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Christopher Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 09:57:28 -0000 hi terry, > It strikes me that this is the first time you have read this draft despite > the several calls to the WG to do so. this version, yes. read a year or so ago, and it was structurally so off my map that i did not do more than scan. > That's not bad exactly... just unexpected. in one sense, it's what wglc is all about. and this is just not high on my radar. > I'm less interested in your abrupt critique and certainly much more > interested in constructive reviews of which you started below and then > gave up.. apologies, but the multiple hours needed would not come up on my priority stack for a long while. i would hope the authors would know how to be more precise. as i said privately to the chairs ... that docco is *really* sloppy. i am kinda wondering why no one else has raised the rather amazing editorial issues. no one bothered to read it? i admit that i have not read it for a year or so. please view my comments as just that. i do not formally object to the doc being passed to the iesg. imiho, they probably deserve it. :) randy From warren@kumari.net Thu Sep 8 07:03:32 2011 Return-Path: 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 B093221F8B7D; Thu, 8 Sep 2011 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC8ptoR+3SOX; Thu, 8 Sep 2011 07:03:32 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0721F8B71; Thu, 8 Sep 2011 07:03:31 -0700 (PDT) Received: from 1513bhost57.starwoodbroadband.com (unknown [38.104.58.218]) by vimes.kumari.net (Postfix) with ESMTPSA id 787B41B40115; Thu, 8 Sep 2011 10:05:23 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Thu, 8 Sep 2011 10:05:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <318A63EA-6290-4D1E-B236-4F4621E0C2CB@kumari.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org" , Christopher Morrow , "sidr-chairs@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 14:03:32 -0000 On Sep 8, 2011, at 5:59 AM, Randy Bush wrote: > hi terry, >=20 >> It strikes me that this is the first time you have read this draft = despite >> the several calls to the WG to do so. >=20 > this version, yes. read a year or so ago, and it was structurally so > off my map that i did not do more than scan. >=20 >> That's not bad exactly... just unexpected. >=20 > in one sense, it's what wglc is all about. and this is just not high = on > my radar. >=20 >> I'm less interested in your abrupt critique and certainly much more >> interested in constructive reviews of which you started below and = then >> gave up.. >=20 > apologies, but the multiple hours needed would not come up on my > priority stack for a long while. i would hope the authors would know > how to be more precise. >=20 > as i said privately to the chairs >=20 > ... that docco is *really* sloppy. i am kinda wondering why no one > else has raised the rather amazing editorial issues. no one > bothered to read it? I'll happily admit to not having responded to the WGLC because I didn't = read the document=85 I have placed it on my ToRead pile, but it will take some time to = propagate up the stack=85 W > i admit that i have not read it for a year or > so. >=20 > please view my comments as just that. i do not formally object to > the doc being passed to the iesg. imiho, they probably deserve > it. :) >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From Sandra.Murphy@cobham.com Thu Sep 8 07:41:23 2011 Return-Path: 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 3A3D421F8498; Thu, 8 Sep 2011 07:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_RELAY=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxL5Bi4mDXVT; Thu, 8 Sep 2011 07:41:21 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 80AAD21F84D2; Thu, 8 Sep 2011 07:41:20 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p88Ego7A000735; Thu, 8 Sep 2011 09:42:50 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p88EgoVf002647; Thu, 8 Sep 2011 09:42:50 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([70.63.228.130]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 10:42:49 -0400 Date: Thu, 8 Sep 2011 10:42:58 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Terry Manderson In-Reply-To: Message-ID: References: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Sep 2011 14:42:49.0847 (UTC) FILETIME=[94F77870:01CC6E35] Cc: Christopher Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 14:41:23 -0000 But in your presentation at the wg meeting you noted that few in the room had read it, with a wry comment that a last call might be necessary to make that happen. (I agree that it seems to be the modus operandi, here and IETF wide.) So it looks to me like your prediction came through. This is an individual comment. --Sandy, regular ol' member On Thu, 8 Sep 2011, Terry Manderson wrote: > Hi Randy, > > It strikes me that this is the first time you have read this draft despite > the several calls to the WG to do so. That's not bad exactly... just > unexpected. > > > On 8/09/11 4:42 PM, "Randy Bush" wrote: > >> i do not think this document is at all ready for publication. someone >> with time and energy to clean up the wording needs to spend a half day >> with the poor thing. > > I'm less interested in your abrupt critique and certainly much more > interested in constructive reviews of which you started below and then gave > up.. > >> >> --- >> >> 1.2 i believe that redefining AS and ASN are ill-advised. just refer >> elsewhere. we readlly do not want to go there. e.g. there are a lot of >> ASs which are not under a single administrative control. >> >> if you insist on defining it, i would probably s/route/as-path/ >> >> Aggregate Route makes an assumption that 'more general' and 'specific' >> are well definined. maybe try something like shorter and longer >> netmask, or greater or smaller prefix mask length. >> >> 'Covering Aggregate' uses 'cover' in its definition, which makes it >> pretty useless. >> >> 'Multi-homed prefix' is 'originated via'. is it transited via/through >> or originated by/from? >> >> ... >> >> 3.1. Single Announcement >> >> An organization (Org A with ASN 64496) has been allocated the prefix >> 192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496 >> such that relying parties interpret the route as intended. >> >> look at rfc 5737 IPv4 Address Blocks Reserved for Documentation > > From time to time authors choose to use non rfc5737 address blocks as the > examples can't often be adequately described or remain uniform with the > documentation prefixes. > >> >> i could go on and on. > > Please do.. send to me off list if you choose. > > Cheers > Terry > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kotikalapudi.sriram@nist.gov Thu Sep 8 08:05:02 2011 Return-Path: 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 6479521F899F; Thu, 8 Sep 2011 08:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMT3tqsB6ogd; Thu, 8 Sep 2011 08:05:02 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id CC37721F891D; Thu, 8 Sep 2011 08:05:01 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Thu, 8 Sep 2011 11:07:36 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 8 Sep 2011 11:06:16 -0400 From: "Sriram, Kotikalapudi" To: Sandra Murphy , Terry Manderson Date: Thu, 8 Sep 2011 11:06:15 -0400 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt Thread-Index: AcxuNZSMmXUcyVhYRciL4sIvlK/CCQAAUHOj Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: Christopher Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 15:05:02 -0000 Steve Kent had reviewed and extensively commented on the document about a year ago. His comments were all incorporated and substantially benefited the document. Thanks once again to Steve. In addition, as I recall we had earlier received comments from Danny, Curtis and Sam. But, yes, we need more readers. Thanks to Warren and any others who have it in their stack and plan to get to it before the WGLC deadline! All your reviews and comments will be much appreciated. Sriram ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Sandra Murphy [Sandra.Murphy@sparta.com] Sent: Thursday, September 08, 2011 10:42 AM To: Terry Manderson Cc: Christopher Morrow; sidr-chairs@ietf.org; sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt But in your presentation at the wg meeting you noted that few in the room had read it, with a wry comment that a last call might be necessary to make that happen. (I agree that it seems to be the modus operandi, here and IETF wide.) So it looks to me like your prediction came through. This is an individual comment. --Sandy, regular ol' member From ietfc@btconnect.com Thu Sep 8 10:07:58 2011 Return-Path: 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 1AA0721F85B8 for ; Thu, 8 Sep 2011 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj5q1UCxpL1a for ; Thu, 8 Sep 2011 10:07:57 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB221F85A4 for ; Thu, 8 Sep 2011 10:07:56 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr06.btconnect.com with SMTP id EMP09494; Thu, 08 Sep 2011 18:09:36 +0100 (BST) Message-ID: <002701cc6e41$2669cfa0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Smith, Donald" , "'Jakob Heitz'" , "'Rob Shakir'" References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org><87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net><331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com><34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com><7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh><5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> Date: Thu, 8 Sep 2011 18:04:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E68F69F.0009, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.8.154515:17:7.586, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4E68F6D0.01AE,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: 'sidr wg list' Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 17:07:58 -0000 ----- Original Message ----- From: "Smith, Donald" To: "'Jakob Heitz'" ; "'Rob Shakir'" Cc: "'sidr wg list'" Sent: Wednesday, September 07, 2011 10:19 PM I would guess you would get a very low take rate on "secure bgp" even if you gave it away (no premium). It would be interesting to see how many customers implemented MD5 for bgp peering sessions when it became freely available. None, when first I became involved in BGP but then, 18 months later, it was widely deployed as a result of a 'disaster' of the kind I alluded to in my previous post. I never did hear directly what happened, and it may be an European affair that did not impact America. I think that I learnt most about it via the RIPE Routing group but it was several years ago, and my memory of it is now quite vague. But it was a good example of nothing being done with the available technology until the disaster happened, and then it was all hands to the pumps. Tom Petch It wasn't very widely deployed the last time I heard. It got a ton of push back on the NANOG list when I recommended it. Ignorance is Bliss. "Bliss (Basic Language for Implementation of System Software) was a systems programming language originally for the PDP-10 and DECsystem-20 written at CMU." Kevin Oberman RTD Donald.Smith@CenturyLink.com > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Jakob Heitz > Sent: Wednesday, September 07, 2011 7:13 AM > To: Rob Shakir > Cc: sidr wg list > Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > > While a router that performs BGPSEC may not be more expensive in 5 > years than one that does not today, that is not relevant. A router that > performs BGPSEC in 5 years will most definitely cost more to produce as > well as cost more to run than a router that does not perform BGPSEC in > 5 years. > > So, a question for you Rob. Will your customers pay the premium for BGP > security? > > -- > Jakob Heitz. > > > On Sep 7, 2011, at 5:05 AM, "Rob Shakir" wrote: > > > On 11 Aug 2011, at 22:40, George, Wesley wrote: > > > >> Danny said, > >> "Periodic updates of the entire routing table *with much larger and > more updates* seems undesirable at best to me, particularly to 'reduce > the vulnerability window for replay attacks' to 'days'." > >> --------------------------------------------------------- > >> I think that this is a small part of a much larger issue that has > been bugging me since our meeting in Quebec City. > >> After looking at Sriram's estimates around the necessary amount of > memory, etc for the different algorithms, I'm bothered by what is being > asked of the routing system in support of BGPSec. > >> > > > > Hi All, > > > > Wes' point here is really important I think, and it's a bit of a > shame it hasn't got more focus. I stood up and mentioned scaling in > Prague, then found myself making a very similar point again in Québec. > As with Wes, I would prefer that this is not interpreted as a criticism > of the goals of bgpsec, but rather is an operational perspective on the > assumptions that are made for deployment of the protocols being > developed in sidr. > > > > The root assumption that we seem to be taking as read throughout such > discussions is that at the point where routing infrastructure is > expected to support the computational load that is demanded of it by > bgpsec, there will have been sufficient growth in both the > computational and memory resources that are available to these systems. > Whilst I appreciate that cryptographic validation of the validity of a > route can be performed on the edge system(s), I think there are two > very key concerns here. > > > > - Historically, do we see Internet routing systems matching the rate > of general computational resource availability? My view on this is that > we do not - there are plenty of edge systems out there that are > relatively modern (and capable of routing tens of gigabits of traffic) > that do not have a control-plane that is as powerful as some of the > software devices that existed prior to it - as such, this means either > this was a lower priority to deliver (which may well be true), or that > it was not practical to do so. With increasing demands on control-plane > resources of IP systems (be they Internet edge or otherwise) - there is > surely some query as to whether having a large amount of memory or > crypto offload hardware will be a priority over other features. The > question Wes raised as to whether we, as a working-group, are happy > with the assumption that this is the case, is very valid. It would seem > to me that we are being somewhat prescriptive with prioritising what > hardware vendors' solutions should look like, and what operator's > scaling approaches will look like - without necessarily explicitly > discussing why this is reasonable to do so. > > > > - Are the assumptions that we are making regarding how those > autonomous systems delivering an "Internet" product set are architected > valid? There is some assumption (AIUI, please feel free to correct me) > that we are looking at networks where we have explicit edge devices > which can scale to meet the validation workload that we're putting on > it. This would seem (again, to me) to be based around assumption that > there are a relatively high number of less-dense edge devices. I would > be interested whether it's the feeling of the WG that my reading of > what we're assuming is correct - and if so, whether the WG feels that > we can be prescriptive like this for how one should architect an > Internet network. > > > > I'm again very supportive of what problems bgpsec is trying to solve > - and do not want to put a dampener on any of the excellent efforts > that have gone into it - but think that we cannot wholly abstract > ourselves away from the actual deployability of the solutions that are > being developed. After all, we will not solve the problems that the WG > is chartered to solve if the fruits of the labours herein are not > actually deployed. > > > > I am not sure of exactly how we progress discussing the scalability > of the solution - but with Sriram's analysis, is it possible to discuss > within this forum, and perhaps others concerned with the general > scaling of IP routing elements, why the scaling > considerations/assumptions of bgpsec are valid, and where a departure > is made from the longer term view of scalability that is presented in > existing IETF documents. > > > > Thanks for reading this - and your consideration! > > r. > > > > > > > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From ietfc@btconnect.com Thu Sep 8 10:14:25 2011 Return-Path: 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 CF8AA21F8A64; Thu, 8 Sep 2011 10:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpvfkoMCQBas; Thu, 8 Sep 2011 10:14:25 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id 87D2121F8A4B; Thu, 8 Sep 2011 10:14:24 -0700 (PDT) Received: from host109-153-79-81.range109-153.btcentralplus.com (HELO pc6) ([109.153.79.81]) by c2beaomr07.btconnect.com with SMTP id EHO27619; Thu, 08 Sep 2011 18:16:12 +0100 (BST) Message-ID: <002d01cc6e42$1275aae0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sandra Murphy" References: Date: Thu, 8 Sep 2011 18:12:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E68F85C.0088, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.8.154515:17:7.944, ip=109.153.79.81, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4E68F85C.01DC,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 17:14:26 -0000 ---- Original Message ----- From: "Sandra Murphy" To: "Terry Manderson" Cc: "Christopher Morrow" ; ; Sent: Thursday, September 08, 2011 4:42 PM > But in your presentation at the wg meeting you noted that few in the room > had read it, with a wry comment that a last call might be necessary to > make that happen. (I agree that it seems to be the modus operandi, here > and IETF wide.) So it looks to me like your prediction came through. How IETF wide it is depends on how many I-Ds the WG has, and perhaps how that compares to how many it should have. Some WGs work on one (or two or three) I-Ds and then everyone reads everything. When the WG has 25, then yes, I am behind the curve and might even wait until IETF LC to raise issues. And particularly for SIDR, I think that there are more than are needed, that bits have been tacked on as the work has progressed, making it hard to understand the (lack of an?) overall plan, even for one who reads every e-mail to the SIDR list, to find where something is defined, or what to read to get an understanding of a particular aspect of sidr. Perhaps these comments are not addressed to you as an individual. Tom Petch > > This is an individual comment. > > --Sandy, regular ol' member > > On Thu, 8 Sep 2011, Terry Manderson wrote: > > > Hi Randy, > > > > It strikes me that this is the first time you have read this draft despite > > the several calls to the WG to do so. That's not bad exactly... just > > unexpected. > > > > > > On 8/09/11 4:42 PM, "Randy Bush" wrote: > > > >> i do not think this document is at all ready for publication. someone > >> with time and energy to clean up the wording needs to spend a half day > >> with the poor thing. > > > > I'm less interested in your abrupt critique and certainly much more > > interested in constructive reviews of which you started below and then gave > > up.. > > > >> > >> --- > >> > >> 1.2 i believe that redefining AS and ASN are ill-advised. just refer > >> elsewhere. we readlly do not want to go there. e.g. there are a lot of > >> ASs which are not under a single administrative control. > >> > >> if you insist on defining it, i would probably s/route/as-path/ > >> > >> Aggregate Route makes an assumption that 'more general' and 'specific' > >> are well definined. maybe try something like shorter and longer > >> netmask, or greater or smaller prefix mask length. > >> > >> 'Covering Aggregate' uses 'cover' in its definition, which makes it > >> pretty useless. > >> > >> 'Multi-homed prefix' is 'originated via'. is it transited via/through > >> or originated by/from? > >> > >> ... > >> > >> 3.1. Single Announcement > >> > >> An organization (Org A with ASN 64496) has been allocated the prefix > >> 192.168.2.0/24. It wishes to announce the /24 prefix from ASN 64496 > >> such that relying parties interpret the route as intended. > >> > >> look at rfc 5737 IPv4 Address Blocks Reserved for Documentation > > > > From time to time authors choose to use non rfc5737 address blocks as the > > examples can't often be adequately described or remain uniform with the > > documentation prefixes. > > > >> > >> i could go on and on. > > > > Please do.. send to me off list if you choose. > > > > Cheers > > Terry > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From rjs@rob.sh Thu Sep 8 11:16:53 2011 Return-Path: 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 3290B21F85B8 for ; Thu, 8 Sep 2011 11:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us3chBvUIv38 for ; Thu, 8 Sep 2011 11:16:52 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 98E2821F85AA for ; Thu, 8 Sep 2011 11:16:52 -0700 (PDT) Received: from [195.10.56.23] (helo=[212.137.15.59]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1R1jA8-0003YS-8j; Thu, 08 Sep 2011 19:17:21 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> Date: Thu, 8 Sep 2011 19:18:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 18:16:53 -0000 On 7 Sep 2011, at 19:57, George, Wesley wrote: > My guess from your response above is that you're looking for some = anecdotal evidence of equipment lifetimes in real networks to support = Rob's assertion that 5 years may not be a realistic event horizon, so = I'll take a stab at that. I'd like to lend some support to Wes' message here, the situation = described therein is something I've seen before at numerous operators. Randy - do you think that with the modelling that NIST provided, it is = possible for the WG to map (from a historical dataset of control-plane = growth) why the time-scale envisaged for hardware to reach the level = required for fairly ubiquitous bgpsec support is reasonable? This would = seem to answer at least the queries raised here around whether the = resource level envisaged is supportable within the quoted timeframe. Many thanks, r.= From wesley.george@twcable.com Thu Sep 8 12:11:29 2011 Return-Path: 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 9F1FF21F8804 for ; Thu, 8 Sep 2011 12:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoQBFv1DV2uL for ; Thu, 8 Sep 2011 12:11:29 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE121F87F0 for ; Thu, 8 Sep 2011 12:11:28 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,498,1309752000"; d="scan'208";a="256528048" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 08 Sep 2011 15:12:03 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 8 Sep 2011 15:13:21 -0400 From: "George, Wesley" To: "Sriram, Kotikalapudi" , sidr wg list Date: Thu, 8 Sep 2011 15:13:19 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxXlRYzx19OWW9WR+qLPmTOJN+B3gAtymVABVV7wuAAKuVRUA== Message-ID: <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 19:11:29 -0000 -----Original Message----- From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] Sent: Wednesday, September 07, 2011 5:52 PM To: George, Wesley; sidr wg list Subject: RE: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > > As far as where this leaves BGPSec, I don't know. Perhaps a solution come= s in the form of > some of us starting to champion the necessary work to move one or more of= the better ideas > from RRG into implementation so that the underlying scaling problem is be= ing addressed in > parallel. It should be quite possible to incorporate improvements to rout= e security into > whatever must already be done to improve scale, and even if not, these ar= e two things that > both share a barrier to deployment, especially incrementally, and would c= ertainly benefit > from being designed and deployed in concert instead of in separate silos= . Wes, Sorry for the belated response -- I was away in India on vacation :) We had some discussion earlier on this list about BGPSEC in conjunction with an RRG scalability solution (e.g., LISP). (You might have seen these posts back in May, but just in case.) http://www.ietf.org/mail-archive/web/sidr/current/msg02836.html http://www.ietf.org/mail-archive/web/sidr/current/msg02837.html http://www.ietf.org/mail-archive/web/sidr/current/msg02847.html These posts relate only to the above noted comment from you (but not directly to a different question you've raised w.r.t. the concerns in 4984/6227). WEG] Sriram - thanks for the pointers, but all this really tells me is that= I'm not the first one to point out a potential problem here. The issue wit= h making any assumption of a solution means that we're essentially closing = our eyes and hoping that someone else figures this out before the world end= s. My point is that we have to take a more active role in bringing this bac= k to the forefront of the discussion in IETF because we stand to be impacte= d by delays in finding a solution. If the timing is wrong, it ends up being= gating to deployment of BGPSec. If the timing is right, it probably requir= es a lot of redesign work and additional investment, neither of which are p= articularly optimal. I'd prefer that we document up-front that there is a r= eal concern here and that IETF needs to get moving on the scale problem, in= some way other than endless debate over options within RRG. Even making a = decision as to which direction to go (map and encap vs L/I split) would mov= e a long way towards allowing other things like BGPSec to optimize their de= signs accordingly. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jakob.heitz@ericsson.com Thu Sep 8 12:44:42 2011 Return-Path: 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 87F8C21F869C for ; Thu, 8 Sep 2011 12:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqhdp1gSI1Hw for ; Thu, 8 Sep 2011 12:44:41 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A455521F8686 for ; Thu, 8 Sep 2011 12:44:41 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p88JkTpW018189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Sep 2011 14:46:34 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 8 Sep 2011 15:46:29 -0400 From: Jakob Heitz To: sidr wg list Date: Thu, 8 Sep 2011 15:46:28 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxXlRYzx19OWW9WR+qLPmTOJN+B3gAtymVABVV7wuAAKuVRUAADmgJw Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A2F61F34@EUSAACMS0701.eamcs.ericsson.se> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 19:44:42 -0000 A router that implements BGPSec will *always* use more memory and more CPU that one that doesn't. CPU --- A router has a powerful CPU mainly to converge when it comes up and when a neighboring router comes up or goes down. During normal operation, it is largely unused. If we reprioritise BGPSec, we could make it work. Sugestion: during bringup, send routes without the BGPSec attribute. Once converged, during low CPU usage, send them again with the BGPSec attribute. Call this the first beacon. When receiving routes, delegate the BGPSec verification to a low priority task. Memory ------ Because BGPSec operations do not affect convergence (we send without BGPSec attribute to achieve convergence), it can use slower, cheaper memory like a hard disk or flash disk. Downside -------- There will be a few minutes after router bringup when unverified routes exist. Unverified routes can be given a lower preference. On Thursday, September 08, 2011 12:13 PM, George, Wesley <> wrote: > -----Original Message----- > From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] > Sent: Wednesday, September 07, 2011 5:52 PM > To: George, Wesley; sidr wg list > Subject: RE: [sidr] BGPSec scaling (was RE: beacons and bgpsec) >=20 >>=20 >> As far as where this leaves BGPSec, I don't know. Perhaps a solution >> comes in the form of some of us starting to champion the necessary >> work to move one or more of the better ideas from RRG into >> implementation so that the underlying scaling problem is being >> addressed in parallel. It should be quite possible to incorporate >> improvements to route security into whatever must already be done to >> improve scale, and even if not, these are two things that both share >> a barrier to deployment, especially incrementally, and would >> certainly benefit from being designed and deployed in concert >> instead of in separate silos. =20 >=20 > Wes, >=20 > Sorry for the belated response -- I was away in India on vacation :) > We had some discussion earlier on this list about > BGPSEC in conjunction with an RRG scalability solution (e.g., LISP). > (You might have seen these posts back in May, but just in case.) >=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg02836.html > http://www.ietf.org/mail-archive/web/sidr/current/msg02837.html > http://www.ietf.org/mail-archive/web/sidr/current/msg02847.html >=20 > These posts relate only to the above noted comment from you > (but not directly to a different question you've raised > w.r.t. the concerns in 4984/6227). >=20 > WEG] Sriram - thanks for the pointers, but all this really tells me > is that I'm not the first one to point out a potential problem here. > The issue with making any assumption of a solution means that we're > essentially closing our eyes and hoping that someone else figures > this out before the world ends. My point is that we have to take a > more active role in bringing this back to the forefront of the > discussion in IETF because we stand to be impacted by delays in > finding a solution. If the timing is wrong, it ends up being gating > to deployment of BGPSec. If the timing is right, it probably requires > a lot of redesign work and additional investment, neither of which > are particularly optimal. I'd prefer that we document up-front that > there is a real concern here and that IETF needs to get moving on the > scale problem, in some way other than endless debate over options > within RRG. Even making a decision as to which direction to go (map > and encap vs L/I split) would move a long way to wards allowing other > things like BGPSec to optimize their designs accordingly. =20 >=20 > Wes George >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. > _______________________________________________ =20 > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --=20 Jakob Heitz. x25475. 510-566-2901= From robert@raszuk.net Thu Sep 8 13:56:33 2011 Return-Path: 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 DBD1021F84FC for ; Thu, 8 Sep 2011 13:56:33 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVjaDMahmbUB for ; Thu, 8 Sep 2011 13:56:33 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 2EA4121F84B1 for ; Thu, 8 Sep 2011 13:56:30 -0700 (PDT) Received: (qmail 14657 invoked by uid 399); 8 Sep 2011 20:58:22 -0000 Received: from unknown (HELO ?216.69.69.167?) (216.69.69.167) by mail37.opentransfer.com with SMTP; 8 Sep 2011 20:58:22 -0000 Message-ID: <4E692C6F.6030104@raszuk.net> Date: Thu, 08 Sep 2011 22:58:23 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jakob Heitz References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D213914A2F61F34@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213914A2F61F34@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 20:56:34 -0000 Hi Jakob, > If we reprioritise BGPSec, we could make it work. Sugestion: > during bringup, send routes without the BGPSec attribute. I think there is a significant risk that this would cause unnecessary Internet wide churn. I would propose and alternative approach. To send the routes with whatever attributes sender decides to send then with and do it only once. Up-on reception if indeed inline CPU processing is an issue on given platform store the BGPSec related attributes without any processing then when CPU get's idle .. verify them. Hoping that only small fraction of all routes could be considered invalid you may later withdraw them. Of course this only attempts to fix inbound processing issue. You can not do the same when signing the routes outbound. --- It keeps me puzzled why sidr is so stuck on BGP inbound solution as opposed on number of proposals which deliver the same results using out of BGP bound control plane verification. Cheers, R. > A router that implements BGPSec will *always* use more memory > and more CPU that one that doesn't. > > CPU > --- > A router has a powerful CPU mainly to converge when it comes up > and when a neighboring router comes up or goes down. During normal > operation, it is largely unused. > > If we reprioritise BGPSec, we could make it work. Sugestion: > during bringup, send routes without the BGPSec attribute. > Once converged, during low CPU usage, send them again with > the BGPSec attribute. Call this the first beacon. > When receiving routes, delegate the BGPSec > verification to a low priority task. > > Memory > ------ > Because BGPSec operations do not affect convergence (we send > without BGPSec attribute to achieve convergence), it can use > slower, cheaper memory like a hard disk or flash disk. > > Downside > -------- > There will be a few minutes after router bringup when unverified > routes exist. Unverified routes can be given a lower preference. > > On Thursday, September 08, 2011 12:13 PM, George, Wesley<> wrote: > >> -----Original Message----- >> From: Sriram, Kotikalapudi [mailto:kotikalapudi.sriram@nist.gov] >> Sent: Wednesday, September 07, 2011 5:52 PM >> To: George, Wesley; sidr wg list >> Subject: RE: [sidr] BGPSec scaling (was RE: beacons and bgpsec) >> >>> >>> As far as where this leaves BGPSec, I don't know. Perhaps a solution >>> comes in the form of some of us starting to champion the necessary >>> work to move one or more of the better ideas from RRG into >>> implementation so that the underlying scaling problem is being >>> addressed in parallel. It should be quite possible to incorporate >>> improvements to route security into whatever must already be done to >>> improve scale, and even if not, these are two things that both share >>> a barrier to deployment, especially incrementally, and would >>> certainly benefit from being designed and deployed in concert >>> instead of in separate silos. >> >> Wes, >> >> Sorry for the belated response -- I was away in India on vacation :) >> We had some discussion earlier on this list about >> BGPSEC in conjunction with an RRG scalability solution (e.g., LISP). >> (You might have seen these posts back in May, but just in case.) >> >> http://www.ietf.org/mail-archive/web/sidr/current/msg02836.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg02837.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg02847.html >> >> These posts relate only to the above noted comment from you >> (but not directly to a different question you've raised >> w.r.t. the concerns in 4984/6227). >> >> WEG] Sriram - thanks for the pointers, but all this really tells me >> is that I'm not the first one to point out a potential problem here. >> The issue with making any assumption of a solution means that we're >> essentially closing our eyes and hoping that someone else figures >> this out before the world ends. My point is that we have to take a >> more active role in bringing this back to the forefront of the >> discussion in IETF because we stand to be impacted by delays in >> finding a solution. If the timing is wrong, it ends up being gating >> to deployment of BGPSec. If the timing is right, it probably requires >> a lot of redesign work and additional investment, neither of which >> are particularly optimal. I'd prefer that we document up-front that >> there is a real concern here and that IETF needs to get moving on the >> scale problem, in some way other than endless debate over options >> within RRG. Even making a decision as to which direction to go (map >> and encap vs L/I split) would move a long way to wards allowing other >> things like BGPSec to optimize their designs accordingly. >> >> Wes George >> >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or >> subject to copyright belonging to Time Warner Cable. This E-mail is >> intended solely for the use of the individual or entity to which it >> is addressed. If you are not the intended recipient of this E-mail, >> you are hereby notified that any dissemination, distribution, >> copying, or action taken in relation to the contents of and >> attachments to this E-mail is strictly prohibited and may be >> unlawful. If you have received this E-mail in error, please notify >> the sender immediately and permanently delete the original and any >> copy of this E-mail and any printout. >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > > From kotikalapudi.sriram@nist.gov Fri Sep 9 06:44:55 2011 Return-Path: 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 8E0C921F8AB8 for ; Fri, 9 Sep 2011 06:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpPqZIYD7Wzo for ; Fri, 9 Sep 2011 06:44:55 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id D704121F8AAC for ; Fri, 9 Sep 2011 06:44:54 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Fri, 9 Sep 2011 09:47:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 9 Sep 2011 09:46:14 -0400 From: "Sriram, Kotikalapudi" To: "robert@raszuk.net" , Jakob Heitz Date: Fri, 9 Sep 2011 09:46:14 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxuaiF/8NedlGWeTnyNz5fL+wOVvQAiV1Oy Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> <7309FCBCAE981B43ABBE69B31C8D213914A2F61F34@EUSAACMS0701.eamcs.ericsson.se>, <4E692C6F.6030104@raszuk.net> In-Reply-To: <4E692C6F.6030104@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 13:44:55 -0000 -- snip -- >> If we reprioritise BGPSec, we could make it work. Sugestion: >> during bringup, send routes without the BGPSec attribute. > >I think there is a significant risk that this would cause unnecessary >Internet wide churn. > >I would propose and alternative approach. To send the routes with >whatever attributes sender decides to send then with and do it only once. > >Up-on reception if indeed inline CPU processing is an issue on given >platform store the BGPSec related attributes without any processing then >when CPU get's idle .. verify them. > >Hoping that only small fraction of all routes could be considered >invalid you may later withdraw them. > >Of course this only attempts to fix inbound processing issue. You can >not do the same when signing the routes outbound. Jakob: Robert: The protocol permits the ideas you are proposing -- see Section 4.2. http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-00#section-4.2 The key wording there is: .... it is RECOMMENDED that if the BGPSEC speaker chooses to propagate the route that it generate an update message containing the BGPSEC_Path_Signatures attribute. However, a BGPSEC speaker MAY propagate a route advertisement by generating a (non-BGPSEC) update message that does not contain the BGPSEC_Path_Signatures attribute. Also, the optimizations you mention are included/discussed in Section 5.4 of the draft-sriram-bgpsec-design-choices document: 5.4. Temporary Suspension of Attestations and Validations http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-5.4 Robert seems to be asserting that the router must always sign and propagate the update (if it selected a signed update for best path). However, the current protocol specification allows for dropping BGPSEC_Path_Signatures attribute (potentially for cases when the route-processor is in overload state). Sriram From kotikalapudi.sriram@nist.gov Fri Sep 9 07:58:16 2011 Return-Path: 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 2AD5121F86C7 for ; Fri, 9 Sep 2011 07:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO1FPEBUANYO for ; Fri, 9 Sep 2011 07:58:15 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9B921F8681 for ; Fri, 9 Sep 2011 07:58:06 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Fri, 9 Sep 2011 11:00:44 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 9 Sep 2011 10:59:27 -0400 From: "Sriram, Kotikalapudi" To: "George, Wesley" , sidr wg list Date: Fri, 9 Sep 2011 10:59:27 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxXlRYzx19OWW9WR+qLPmTOJN+B3gAtymVABVV7wuAAKuVRUAArCkoc Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> , <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E0D6263@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 14:58:16 -0000 >If the timing is wrong, it ends up being gating to deployment of BGPSec. >If the timing is right, it probably requires a lot of redesign work >and additional investment, neither of which are particularly optimal. >I'd prefer that we document up-front that there is a real concern here and that >IETF needs to get moving on the scale problem, > >Wes George The devil is always in the details. But I am thinking (hope not too simplistically) that once you have a solution agreed upon and deployed for scaling the FIB, then all it does is slow down (hopefully quite significantly) the growth of the FIB and RIB sizes. It makes no changes to the eBGP protocol as such. (Only adds the additional step of mapping look up at the ingress routers.) It would appear that "BGPSEC protocol specification" by itself has no dependency on the FIB scalability solution (except that the potential impediments for BGPSEC deployment may be substantially alleviated -- benefiting from possibly significant reductions in RIB size, # updates/beacons, and route-processor workload). FIB scalability solution would ultimately reduce the cost of deployment of BGPSEC, but the specifications of the two solutions/protocols need not be intertwined. Having said that, I am all for full scale co-operation between the two efforts -- much as you have suggested. Sriram From randy@psg.com Fri Sep 9 08:04:48 2011 Return-Path: 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 600C721F8BEF for ; Fri, 9 Sep 2011 08:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtdqbNbn+B2U for ; Fri, 9 Sep 2011 08:04:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EA25121F8BEE for ; Fri, 9 Sep 2011 08:04:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R22fA-000KYY-P4; Fri, 09 Sep 2011 15:06:41 +0000 Date: Fri, 09 Sep 2011 17:06:37 +0200 Message-ID: From: Randy Bush To: Rob Shakir In-Reply-To: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 15:04:48 -0000 > Randy - do you think that with the modelling that NIST provided i am not very confident in any modeling done to date and am not making grand opinions until i, or others, have time to do credible measurement. but i do have some thought about what i want to model, mostly stolen from others due to design lead times and pricing, what will be on routing engine boards in three to five years is whatever is available as commodity today. i.e. what does a hot westmere chip give us? with a cheap crypto chip? as a vendor friend says, if ipv6 deploys, insha allah, we're gonna be upgrading those routers to do real v6 forwarding. if it does not deploy, you will be deploying massively bigger boxes to nat your ass into hell. randy From russw@riw.us Fri Sep 9 08:10:32 2011 Return-Path: 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 B902521F8BA4 for ; Fri, 9 Sep 2011 08:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTZiqNXfcxJB for ; Fri, 9 Sep 2011 08:10:32 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id B0FE821F8AED for ; Fri, 9 Sep 2011 08:10:31 -0700 (PDT) Received: from cpe-065-190-157-197.nc.res.rr.com ([65.190.157.197] helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R22kX-0000vC-9f for sidr@ietf.org; Fri, 09 Sep 2011 11:12:13 -0400 Message-ID: <4E6A2CD0.1010305@riw.us> Date: Fri, 09 Sep 2011 11:12:16 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 15:10:32 -0000 > as a vendor friend says, if ipv6 deploys, insha allah, we're gonna > be upgrading those routers to do real v6 forwarding. if it does not > deploy, you will be deploying massively bigger boxes to nat your ass > into hell. There are two possible results, it seems to me: 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so that BGPsec essentially becomes "free" in the IPv6 upgrade. 2. The cost of deploying BGPsec will be significant enough that it can't be "buried," in any other costs. The question is --which is true? I'm guessing #2 is going to be true, but many others seem to think #1 is true. The reality is that the market will decide, and no study is going to be able to answer this question fully. Russ From randy@psg.com Fri Sep 9 09:17:26 2011 Return-Path: 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 1B1BC21F869C for ; Fri, 9 Sep 2011 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fK9+ZYAOZnZ for ; Fri, 9 Sep 2011 09:17:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B57B921F8681 for ; Fri, 9 Sep 2011 09:17:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R23nU-000KmU-Q6; Fri, 09 Sep 2011 16:19:20 +0000 Date: Fri, 09 Sep 2011 18:19:19 +0200 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4E6A2CD0.1010305@riw.us> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:17:26 -0000 >> as a vendor friend says, if ipv6 deploys, insha allah, we're gonna >> be upgrading those routers to do real v6 forwarding. if it does not >> deploy, you will be deploying massively bigger boxes to nat your ass >> into hell. > > There are two possible results, it seems to me: > > 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so > that BGPsec essentially becomes "free" in the IPv6 upgrade. > > 2. The cost of deploying BGPsec will be significant enough that it can't > be "buried," in any other costs. > > The question is --which is true? as i have no data, any guess i make would be bullshit, would it not? randy From russw@riw.us Fri Sep 9 09:20:13 2011 Return-Path: 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 90D1321F86C1 for ; Fri, 9 Sep 2011 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QS276M9d1D-1 for ; Fri, 9 Sep 2011 09:20:13 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id E589521F863E for ; Fri, 9 Sep 2011 09:20:12 -0700 (PDT) Received: from cpe-065-190-157-197.nc.res.rr.com ([65.190.157.197] helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R23qB-0001BC-8j; Fri, 09 Sep 2011 12:22:07 -0400 Message-ID: <4E6A3D30.9030605@riw.us> Date: Fri, 09 Sep 2011 12:22:08 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Randy Bush References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:20:13 -0000 On 9/9/2011 12:19 PM, Randy Bush wrote: >>> as a vendor friend says, if ipv6 deploys, insha allah, we're gonna >>> be upgrading those routers to do real v6 forwarding. if it does not >>> deploy, you will be deploying massively bigger boxes to nat your ass >>> into hell. >> >> There are two possible results, it seems to me: >> >> 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so >> that BGPsec essentially becomes "free" in the IPv6 upgrade. >> >> 2. The cost of deploying BGPsec will be significant enough that it can't >> be "buried," in any other costs. >> >> The question is --which is true? > > as i have no data, any guess i make would be bullshit, would it not? Does anyone have the data needed to answer which is true? My guess is based on the cost of hardware in general --even small hardware costs don't normally end up being "swamped"-- and the cost of network convergence times, etc. Using different assumptions, you can come to different conclusions. I don't know how you can build a study that would tell you which set of assumptions is "correct." OTOH, it would be interesting to try. Russ From randy@psg.com Fri Sep 9 09:21:58 2011 Return-Path: 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 E4D3C21F8888 for ; Fri, 9 Sep 2011 09:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiQ7uXkS83AA for ; Fri, 9 Sep 2011 09:21:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6729C21F86C1 for ; Fri, 9 Sep 2011 09:21:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R23rr-000Knt-H3; Fri, 09 Sep 2011 16:23:51 +0000 Date: Fri, 09 Sep 2011 18:23:50 +0200 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4E6A3D30.9030605@riw.us> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <4E6A3D30.9030605@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:21:58 -0000 >>>> as a vendor friend says, if ipv6 deploys, insha allah, we're gonna >>>> be upgrading those routers to do real v6 forwarding. if it does not >>>> deploy, you will be deploying massively bigger boxes to nat your ass >>>> into hell. >>> >>> There are two possible results, it seems to me: >>> >>> 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so >>> that BGPsec essentially becomes "free" in the IPv6 upgrade. >>> >>> 2. The cost of deploying BGPsec will be significant enough that it can't >>> be "buried," in any other costs. >>> >>> The question is --which is true? >> >> as i have no data, any guess i make would be bullshit, would it not? > > Does anyone have the data needed to answer which is true? My guess is > based on the cost of hardware in general --even small hardware costs > don't normally end up being "swamped"-- and the cost of network > convergence times, etc. > > Using different assumptions, you can come to different conclusions. I > don't know how you can build a study that would tell you which set of > assumptions is "correct." > > OTOH, it would be interesting to try. gambatte! i am hoping to find time to try some simpler things. randy From jakob.heitz@ericsson.com Fri Sep 9 09:31:32 2011 Return-Path: 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 4970F21F8505 for ; Fri, 9 Sep 2011 09:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wycGAEkt6c4q for ; Fri, 9 Sep 2011 09:31:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9D921F84FC for ; Fri, 9 Sep 2011 09:31:31 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p89GXLxf006872; Fri, 9 Sep 2011 11:33:26 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 9 Sep 2011 12:33:17 -0400 From: Jakob Heitz To: Russ White Date: Fri, 9 Sep 2011 12:33:17 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxvDizUOZXk9cmhQIiOSh/2vtb9qg== Message-ID: <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <4E6A3D30.9030605@riw.us> In-Reply-To: <4E6A3D30.9030605@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:31:32 -0000 By doing "converge first verify later", the router can be made cheaper. However, there is still the cost of the RPKI and the cost of running/mainta= ining it. My guess is that will bury the cost of the routers. Just a guess, Randy. -- Jakob Heitz. On Sep 9, 2011, at 9:22 AM, "Russ White" wrote: > On 9/9/2011 12:19 PM, Randy Bush wrote: >>>> as a vendor friend says, if ipv6 deploys, insha allah, we're gonna >>>> be upgrading those routers to do real v6 forwarding. if it does no= t >>>> deploy, you will be deploying massively bigger boxes to nat your as= s >>>> into hell. >>>=20 >>> There are two possible results, it seems to me: >>>=20 >>> 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so >>> that BGPsec essentially becomes "free" in the IPv6 upgrade. >>>=20 >>> 2. The cost of deploying BGPsec will be significant enough that it can'= t >>> be "buried," in any other costs. >>>=20 >>> The question is --which is true? >>=20 >> as i have no data, any guess i make would be bullshit, would it not? >=20 > Does anyone have the data needed to answer which is true? My guess is > based on the cost of hardware in general --even small hardware costs > don't normally end up being "swamped"-- and the cost of network > convergence times, etc. >=20 > Using different assumptions, you can come to different conclusions. I > don't know how you can build a study that would tell you which set of > assumptions is "correct." >=20 > OTOH, it would be interesting to try. >=20 > Russ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Fri Sep 9 09:40:54 2011 Return-Path: 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 0A7CF21F8802 for ; Fri, 9 Sep 2011 09:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRORPUwTXww2 for ; Fri, 9 Sep 2011 09:40:53 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 796EB21F86DE for ; Fri, 9 Sep 2011 09:40:53 -0700 (PDT) Received: from cpe-065-190-157-197.nc.res.rr.com ([65.190.157.197] helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R24AA-0004md-Px; Fri, 09 Sep 2011 12:42:46 -0400 Message-ID: <4E6A420C.1020203@riw.us> Date: Fri, 09 Sep 2011 12:42:52 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Jakob Heitz References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <4E6A3D30.9030605@riw.us> <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com> In-Reply-To: <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:40:54 -0000 > By doing "converge first verify later", the router can be made cheaper. I'm not certain I'd agree with this assessment... I'd guess you can make convergence faster this way, but the memory and other costs on the router are going to be the same. You could make it cheaper by moving specific things off the router and onto auxiliary boxes, but the point of inline authentication is _not_ to move anything onto boxes outside the router (or even onto line cards within the router) --this is the reason all overlay proposals were rejected up front. > However, there is still the cost of the RPKI and the cost of running/maintaining it. > My guess is that will bury the cost of the routers. I would guess this, as well --and I would guess that the cost of the extra memory and processing to perform what BGPsec is asking for will never be buried. IMHO, there will always be a cost differential between a device capable of what BGPsec requires, and a device that's not capable. Security will always cost something, no matter how you slice it. The more "perfect" you try to make it, the more it will cost. SIDR seems to have started out with "let's engineer the most perfect security we can imagine," end of the stick --something most engineers (including myself) tend to do a lot. Russ From christopher.morrow@gmail.com Sun Sep 11 20:24:00 2011 Return-Path: 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 60E5D21F899D for ; Sun, 11 Sep 2011 20:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWkRcCl7KWMh for ; Sun, 11 Sep 2011 20:23:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCDB021F8802 for ; Sun, 11 Sep 2011 20:23:44 -0700 (PDT) Received: by yxt33 with SMTP id 33so1744390yxt.31 for ; Sun, 11 Sep 2011 20:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tc7WV0R4ZalYxuDIXgY0tX6dNLRzzN4KV1sKr9I60UE=; b=XVmPdj3jH29uOWR0Ckttne7yc2WaxX4IwRrj2S5/WfPc4h0deMxQ6mC9ket+aOwD5F m8x3W05ZrWocpz4nU28usZY29sqAVbatZb2PLd3JA8gpocqFzcUWhPpG7JWzeDDS5uS9 cYmr3NK/KeqctE1nC+IYVItbe3lmxPJniqvDE= MIME-Version: 1.0 Received: by 10.231.29.101 with SMTP id p37mr6406712ibc.81.1315797945653; Sun, 11 Sep 2011 20:25:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.65.5 with HTTP; Sun, 11 Sep 2011 20:25:45 -0700 (PDT) In-Reply-To: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> Date: Sun, 11 Sep 2011 23:25:45 -0400 X-Google-Sender-Auth: jaKSBysjWDKkb4cm6JXmGA9okIg Message-ID: From: Christopher Morrow To: Randy Bush , "George, Wesley" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 03:24:00 -0000 On Fri, Sep 9, 2011 at 12:19 PM, Randy Bush wrote: >>> =A0 =A0 as a vendor friend says, if ipv6 deploys, insha allah, we're go= nna >>> =A0 =A0 be upgrading those routers to do real v6 forwarding. =A0if it d= oes not >>> =A0 =A0 deploy, you will be deploying massively bigger boxes to nat you= r ass >>> =A0 =A0 into hell. >> >> There are two possible results, it seems to me: >> >> 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so >> that BGPsec essentially becomes "free" in the IPv6 upgrade. >> >> 2. The cost of deploying BGPsec will be significant enough that it can't >> be "buried," in any other costs. >> >> The question is --which is true? > > as i have no data, any guess i make would be bullshit, would it not? maybe what Wes is asking here is really: "Could someone model the load on a router doing bgpsec, in a world of bgpsec speaking devices?" Something like, for a core network edge device (say sprint, C&W, TWTC, UU/vzb,ATT an edge connecting device in their worst metro): o number of updates today/second (steady state and 'worst case') o projected growth of update stream (given historical data) o projected 'cost' (cpu cycles) of un-assisted bgpsec o projected RIB RAM size (use historical data to project forward) o projected beacons/second (which really just look like updates in the update stream) o routing table size (projected forward from historical data) It seems most of that data exists in one form or another, it seems that running the math isn't "hard". There's a question of the validity of the model... but that's always the case. Wes, is this sort of thing what you're asking for? -Chris From randy@psg.com Sun Sep 11 23:14:45 2011 Return-Path: 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 C252521F8B18 for ; Sun, 11 Sep 2011 23:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJsvK0gHBiwg for ; Sun, 11 Sep 2011 23:14:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6079F21F8AFA for ; Sun, 11 Sep 2011 23:14:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2zou-0006Nr-52; Mon, 12 Sep 2011 06:16:40 +0000 Date: Mon, 12 Sep 2011 08:16:37 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 06:14:45 -0000 > maybe what Wes is asking here is really: > "Could someone model the load on a router doing bgpsec, in a world of > bgpsec speaking devices?" as i have said, i hope to get the time to do real measurement and modeling. until i, or someone whose methods i trust does so, all is conjecturbation. randy From jakob.heitz@ericsson.com Sun Sep 11 23:19:55 2011 Return-Path: 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 0CDA321F857D for ; Sun, 11 Sep 2011 23:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuJAjOy4e1-O for ; Sun, 11 Sep 2011 23:19:54 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 21AD621F8509 for ; Sun, 11 Sep 2011 23:19:54 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p8C6LsH6018401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Sep 2011 01:21:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 12 Sep 2011 02:21:53 -0400 From: Jakob Heitz To: Randy Bush , Christopher Morrow Date: Mon, 12 Sep 2011 02:21:52 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxxE5Ii/7gAGe/fTDSVbj7dSIcsbQAAIvaQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 06:19:55 -0000 On Sunday, September 11, 2011 11:17 PM, Randy Bush <> wrote: >> maybe what Wes is asking here is really: >> "Could someone model the load on a router doing bgpsec, in a world of >> bgpsec speaking devices?" >=20 > as i have said, i hope to get the time to do real measurement and > modeling. until i, or someone whose methods i trust does so, all is > conjecturbation. Do you trust this? http://www.ietf.org/proceedings/81/slides/sidr-2.pdf --=20 Jakob Heitz.= From randy@psg.com Sun Sep 11 23:24:27 2011 Return-Path: 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 AA4B221F84A9 for ; Sun, 11 Sep 2011 23:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b59kxZHCABEs for ; Sun, 11 Sep 2011 23:24:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B06CB21F84A1 for ; Sun, 11 Sep 2011 23:24:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R2zyK-0006Pz-1R; Mon, 12 Sep 2011 06:26:24 +0000 Date: Mon, 12 Sep 2011 08:26:22 +0200 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 06:24:27 -0000 >> as i have said, i hope to get the time to do real measurement and >> modeling. until i, or someone whose methods i trust does so, all is >> conjecturbation. > Do you trust this? > http://www.ietf.org/proceedings/81/slides/sidr-2.pdf no. way too much excel model based on predictions of future growth rates and how operators will act and way too little hard data. randy From kotikalapudi.sriram@nist.gov Mon Sep 12 05:14:43 2011 Return-Path: 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 596BB21F8B05 for ; Mon, 12 Sep 2011 05:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-ncnd7yGERi for ; Mon, 12 Sep 2011 05:14:41 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D25D821F8B03 for ; Mon, 12 Sep 2011 05:14:40 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Mon, 12 Sep 2011 08:16:22 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 12 Sep 2011 08:16:07 -0400 From: "Sriram, Kotikalapudi" To: Jakob Heitz Date: Mon, 12 Sep 2011 08:16:06 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxxFNbyIgsLCtOuRzO3nYRI/zbk4QALYgRf Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:14:43 -0000 In a kinder, gentler world, Randy used to speak like this, or at least he did once! http://www.ietf.org/mail-archive/web/sidr/current/msg02845.html Sriram P.S. Regarding Toni's question in that email (to which Randy responded), I did extend the model to include separate projected growth rates for IPv4 and IPv6. _______________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Randy Bush [randy@psg.com] Sent: Monday, September 12, 2011 2:26 AM To: Jakob Heitz Cc: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) >> as i have said, i hope to get the time to do real measurement and >> modeling. until i, or someone whose methods i trust does so, all is >> conjecturbation. > Do you trust this? > http://www.ietf.org/proceedings/81/slides/sidr-2.pdf no. way too much excel model based on predictions of future growth rates and how operators will act and way too little hard data. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Mon Sep 12 05:38:48 2011 Return-Path: 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 C53F121F8508 for ; Mon, 12 Sep 2011 05:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu76q8Zgd4p0 for ; Mon, 12 Sep 2011 05:38:48 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2895021F84DC for ; Mon, 12 Sep 2011 05:38:48 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Mon, 12 Sep 2011 08:40:31 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 12 Sep 2011 08:40:51 -0400 From: "Sriram, Kotikalapudi" To: Jakob Heitz , Randy Bush , Christopher Morrow Date: Mon, 12 Sep 2011 08:40:15 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxxE5Ii/7gAGe/fTDSVbj7dSIcsbQAAIvaQAAx4448= Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> , <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 12:38:48 -0000 Jakob, Three key specific questions one would ask about a model are: Q1. Does it model the underlying physical system accurately. In this instance, would it correctly compute the RIB size, given a number of routes (i.e., total # prefix-paths) in the RIB? Q2: Is it well rooted in the historical measurement data for projecting into the future? Q3: Are additional assumptions made for projecting into the future reasonable? In this instance, are the assumptions regarding the BGPSEC take rate reasonable? Answers (IMHO): For Q1: Yes. There is no guess work involved here. I feel we've accurately factored in the update overheads of BGPSEC based on draft-ietf-sidr-bgpsec-protocol-00. For Q2: We used up to date historical measurement data from >Do you trust this? >http://www.ietf.org/proceedings/81/slides/sidr-2.pdf >-- >Jakob Heitz. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Mon Sep 12 06:28:45 2011 Return-Path: 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 096AC21F8B53 for ; Mon, 12 Sep 2011 06:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTjpiCzalreK for ; Mon, 12 Sep 2011 06:28:44 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id EEE6221F8B4A for ; Mon, 12 Sep 2011 06:28:43 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Mon, 12 Sep 2011 09:32:25 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 12 Sep 2011 09:30:11 -0400 From: "Sriram, Kotikalapudi" To: Jakob Heitz Date: Mon, 12 Sep 2011 09:30:11 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxxE5Ii/7gAGe/fTDSVbj7dSIcsbQAAIvaQAA1LcrE= Message-ID: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> , <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213914A3043FF3@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:28:45 -0000 Sorry, I accidentally hit Send (instead of Save) halfway through in the previous email. Here is the complete email. Jakob, Three key specific questions one would ask about a model are: Q1. Does it model the underlying physical system accurately. In this instance, would it correctly compute the RIB size, given a number of routes (i.e., total # prefix-paths) in the RIB? Q2: Is it well rooted in the historical measurement data for its projections into the future? Q3: Are additional assumptions made for projecting into the future reasonable? In this instance, are the assumptions regarding the BGPSEC take rate reasonable? Answers (IMHO): For Q1: Yes. There is no guess work involved here. I feel we've accurately factored in the update overheads of BGPSEC based on draft-ietf-sidr-bgpsec-protocol-00. For Q2: We used up to date historical measurement data from http://www.potaroo.net/ispcol/2009-03/bgp2008.html (also Geoff's 2009 predictions in that paper came out nearly accurate through the next two years into 2010 and 2011.) We also used current measurements (as of March 2011) from a large Tier 1 ISP regarding the total # routes they observed in the PE routers and in Route Reflectors. We used the observed growth rates for IPv4/IPv6 from the past several years to project into the future. (Needless to say, predicting the future is never a hard science.) We have provided the excel speadsheet so anyone can inject their world view regarding growth rates and see what happens. http://www.antd.nist.gov/~ksriram/BGPSEC_RIB.xls For Q3: This is the hardest part of the modeling -- very tricky and no one can speak to it with certainty. We did overlay a BGPSEC take rate model (slides 5 and 6) http://www.ietf.org/proceedings/81/slides/sidr-2.pdf This was broadly based on historical view of take rates of new technologies in general. (It is usually a Normal distribution curve.) This was felt to be OK within the BGPSEC design team discussions. Once again, anyone curious can play with the speadsheet to input their assumptions/knowledge regarding their projected take rates for BGPSEC. So at the minimum, if you just wish to find out the RIB size corresponding to a given number of routes (i.e., total # prefix-paths), the model would give you that accurately. You are further at liberty to input into the speadsheet any assumptions regarding the growth rates and take-rates per your view of the world. I hope this helps some. Sriram >Do you trust this? >http://www.ietf.org/proceedings/81/slides/sidr-2.pdf >-- >Jakob Heitz. From wesley.george@twcable.com Mon Sep 12 06:37:24 2011 Return-Path: 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 4CB4121F8B53 for ; Mon, 12 Sep 2011 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuoWoEpBTZo4 for ; Mon, 12 Sep 2011 06:37:23 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id AC39F21F8B49 for ; Mon, 12 Sep 2011 06:37:23 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,514,1309752000"; d="scan'208";a="272317177" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Sep 2011 09:36:59 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 12 Sep 2011 09:39:26 -0400 From: "George, Wesley" To: Russ White , "sidr@ietf.org" Date: Mon, 12 Sep 2011 09:39:25 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxvAuWNRBhIc+TSRzumUPWXj584LwCRqY/Q Message-ID: <34E4F50CAFA10349A41E0756550084FB0E0D6B12@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> In-Reply-To: <4E6A2CD0.1010305@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 13:37:24 -0000 -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Rus= s White Sent: Friday, September 09, 2011 11:12 AM To: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > as a vendor friend says, if ipv6 deploys, insha allah, we're gonna > be upgrading those routers to do real v6 forwarding. There are two possible results, it seems to me: 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so that BGPsec essentially becomes "free" in the IPv6 upgrade. WEG] Two or three years ago I might have at least partially agreed with the= above. Now, most large-scale ISPs have IPv6 deployed, using hardware that = they have been assured (through testing and contracts) can forward IPv6 tra= ffic at linerate. I believe that there are plenty of places where there is = real traffic running such that the concept that somehow we're all cruising = towards disaster if this IPv6 thing ever gets real is FUD at best anymore. = There is also a big difference in my mind between forwarding hardware and r= outing hardware, so talking about v6 forwarding is conflating the two in an= unhelpful way. However, rather than an assumption that the two share a timeline, I think t= hat this implies that IPv6 deployments may have the net effect of knocking = some of the oldest crap out of the network, which makes more sense to me. E= ven then, all it'll do is bring things up to today's state of the art (+/- = 2 years), so I think Randy's assumption about today's state of the art bein= g the absolute best that you can assume when modeling for 3-5+ years from n= ow is a good one. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Mon Sep 12 07:31:13 2011 Return-Path: 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 3C37F21F8B46 for ; Mon, 12 Sep 2011 07:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA-FvvxJwzKp for ; Mon, 12 Sep 2011 07:31:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C8E6C21F872A for ; Mon, 12 Sep 2011 07:31:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R37ZQ-0007cW-KF; Mon, 12 Sep 2011 14:33:12 +0000 Date: Mon, 12 Sep 2011 16:33:11 +0200 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:31:13 -0000 > Q2: Is it well rooted in the historical measurement data for its > projections into the future? > > Q3: Are additional assumptions made for projecting into the future > reasonable? In this instance, are the assumptions regarding the BGPSEC > take rate reasonable? as humans and as engineers, we are well known for poor predictions of the future. we each have a model and they differ widely. and if you extrapolate, especially with a complex model, i become very suspicious of any and all of your data. this is why the data i give on rpki-rtr is what we have measured and only what we have measured, 10u on a gsr/xr to validate one incoming prefix, 4-7 seconds on gsr/xr, 7206/ios, and juniper m7 and m240 to load 360k roas built to map the current route views table. this is from a freebsd 8.2 server over both local gige and wan with 63ms rtt, seems to make little difference. we have not yet been able to make finer grained measurements, you are welcome to extrapolate all you wish. i do not wish to. i have no idea what the timing would be with twice that many roas. i would guess it would take more time, but i really have no idea, it could be a flat constant! randy From wesley.george@twcable.com Mon Sep 12 07:38:07 2011 Return-Path: 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 8A87A21F853E for ; Mon, 12 Sep 2011 07:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu4E2dldOcf6 for ; Mon, 12 Sep 2011 07:38:07 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id D131321F851A for ; Mon, 12 Sep 2011 07:38:06 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,514,1309752000"; d="scan'208";a="272352081" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Sep 2011 10:37:42 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 12 Sep 2011 10:40:09 -0400 From: "George, Wesley" To: Russ White , Jakob Heitz Date: Mon, 12 Sep 2011 10:40:08 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxvD4UVOvAgTuWsSVOwGDihofgevgCSS6iw Message-ID: <34E4F50CAFA10349A41E0756550084FB0E26AD5B@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <4E6A3D30.9030605@riw.us> <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com> <4E6A420C.1020203@riw.us> In-Reply-To: <4E6A420C.1020203@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:38:07 -0000 -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Rus= s White Sent: Friday, September 09, 2011 12:43 PM To: Jakob Heitz Cc: sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) You could make it cheaper by moving specific things off the router and onto auxiliary boxes, but the point of inline authentication is _not_ to move anything onto boxes outside the router (or even onto line cards within the router) --this is the reason all overlay proposals were rejected up front. WEG] I think that this looks at the separation between forwarding and compu= te resources a bit too narrowly. As Shane pointed out in an earlier thread,= there are some implementations where the forwarding hardware and the routi= ng/general compute hardware are far too closely linked together in the way = that they grow and scale. Perhaps the solution is to stop trying to cram ne= w magic into RP slots and start pushing the external processing model where= the compute resources are physically, but not logically separate (eg a bla= de center with a fabric interface, not a standalone route server) so that c= omputing (routing) and forwarding can scale independently. It still ends up= with a model where you're throwing more CPU resources at the problem inste= ad of fixing the underlying internet routing scale problem, but perhaps tha= t kicks the can far enough down the road to be acceptable because it puts t= hings back on a commodity PC hardware growth and cost curve. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jakob.heitz@ericsson.com Mon Sep 12 07:42:51 2011 Return-Path: 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 C139821F8B7C for ; Mon, 12 Sep 2011 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoIHgTl9UKlL for ; Mon, 12 Sep 2011 07:42:51 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F02421F8B7A for ; Mon, 12 Sep 2011 07:42:51 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8CEip6o011966; Mon, 12 Sep 2011 09:44:53 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 12 Sep 2011 10:44:48 -0400 From: Jakob Heitz To: Randy Bush Date: Mon, 12 Sep 2011 10:44:53 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: AcxxWoSMnyGvdWW8RSeU5//2RG6Bew== Message-ID: <5696904F-7C8E-460B-8533-F5FDBDC06B4D@ericsson.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:42:51 -0000 10u to validate an incoming prefix. How long to validate an incoming path? How long to generate/sign an outgoing path? To one neighbor? To all neighbors? -- Jakob Heitz. On Sep 12, 2011, at 7:33 AM, "Randy Bush" wrote: >> Q2: Is it well rooted in the historical measurement data for its >> projections into the future? >>=20 >> Q3: Are additional assumptions made for projecting into the future >> reasonable? In this instance, are the assumptions regarding the BGPSEC >> take rate reasonable? >=20 > as humans and as engineers, we are well known for poor predictions of > the future. we each have a model and they differ widely. and if you > extrapolate, especially with a complex model, i become very suspicious > of any and all of your data. >=20 > this is why the data i give on rpki-rtr is what we have measured and > only what we have measured, 10u on a gsr/xr to validate one incoming > prefix, 4-7 seconds on gsr/xr, 7206/ios, and juniper m7 and m240 to load > 360k roas built to map the current route views table. this is from a > freebsd 8.2 server over both local gige and wan with 63ms rtt, seems to > make little difference. we have not yet been able to make finer grained > measurements, >=20 > you are welcome to extrapolate all you wish. i do not wish to. i have > no idea what the timing would be with twice that many roas. i would > guess it would take more time, but i really have no idea, it could be a > flat constant! >=20 > randy From randy@psg.com Mon Sep 12 07:49:54 2011 Return-Path: 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 DFB9821F8B88 for ; Mon, 12 Sep 2011 07:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVabJO-92USg for ; Mon, 12 Sep 2011 07:49:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 88B0B21F8B8D for ; Mon, 12 Sep 2011 07:49:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R37rZ-0007fa-FK; Mon, 12 Sep 2011 14:51:57 +0000 Date: Mon, 12 Sep 2011 16:51:55 +0200 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <5696904F-7C8E-460B-8533-F5FDBDC06B4D@ericsson.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <5696904F-7C8E-460B-8533-F5FDBDC06B4D@ericsson.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 14:49:55 -0000 > 10u to validate an incoming prefix. rpki-based origin validation, NOT bgpsec. > How long to validate an incoming path? > How long to generate/sign an outgoing path? > To one neighbor? To all neighbors? how many times to i need to repeat that i have no fracking idea? if i had measured it, i would have told you 35 messages ago. randy From robert@raszuk.net Mon Sep 12 08:07:59 2011 Return-Path: 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 C8B7421F8C04 for ; Mon, 12 Sep 2011 08:07:59 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSmXLoWzw9Ne for ; Mon, 12 Sep 2011 08:07:59 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id E97E821F8C00 for ; Mon, 12 Sep 2011 08:07:58 -0700 (PDT) Received: (qmail 6518 invoked by uid 399); 12 Sep 2011 15:10:01 -0000 Received: from unknown (HELO ?216.69.73.163?) (216.69.73.163) by mail37.opentransfer.com with SMTP; 12 Sep 2011 15:10:01 -0000 Message-ID: <4E6E20C9.4080201@raszuk.net> Date: Mon, 12 Sep 2011 17:10:01 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "George, Wesley" References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <4E6A3D30.9030605@riw.us> <2FC7C45F-D9A3-4418-A4FE-4C2AEB07711C@ericsson.com> <4E6A420C.1020203@riw.us> <34E4F50CAFA10349A41E0756550084FB0E26AD5B@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E26AD5B@PRVPEXVS04.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 15:07:59 -0000 Hi Wes, IMHO offloading essentially very similar computation which is architected to happen today on each ASBR (both inbound and outbound) to control plane device or set of devices residing anywhere within given AS which is _not_ an existing router would completely change the requirements as well as enable easy deployment of security in BGP, CCNx, you name it. And this is not only for CPU/Memory issue. You need to wait today 2-3 years for even minor feature enhancement from major vendors. Now add to this zoo of vendors and different dev priorities of each - anyone will clearly see that considering the reality deploying end to end Internet wide extension on existing/deployed equipment is just not going to happen. Cheers, R PS. And as you said boxes which support IPv6 at line rate are deployed and on some of them there are no plans for new major software upgrades. What do you do with those considering that they are just fine to act as routers for some time ? > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Russ White > Sent: Friday, September 09, 2011 12:43 PM > To: Jakob Heitz > Cc: sidr@ietf.org > Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > > You could make it cheaper by moving > specific things off the router and onto auxiliary boxes, but the point > of inline authentication is _not_ to move anything onto boxes outside > the router (or even onto line cards within the router) --this is the > reason all overlay proposals were rejected up front. > > WEG] I think that this looks at the separation between forwarding and compute resources a bit too narrowly. As Shane pointed out in an earlier thread, there are some implementations where the forwarding hardware and the routing/general compute hardware are far too closely linked together in the way that they grow and scale. Perhaps the solution is to stop trying to cram new magic into RP slots and start pushing the external processing model where the compute resources are physically, but not logically separate (eg a blade center with a fabric interface, not a standalone route server) so that computing (routing) and forwarding can scale independently. It still ends up with a model where you're throwing more CPU resources at the problem instead of fixing the underlying internet routing scale problem, but perhaps that kicks the can far enough down the road to be acceptable because it puts things back on a commodity PC hardware growth and cost curve. > > Wes > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From wesley.george@twcable.com Mon Sep 12 11:26:16 2011 Return-Path: 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 2593D21F8C0B for ; Mon, 12 Sep 2011 11:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.129 X-Spam-Level: X-Spam-Status: No, score=0.129 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKuTUTJsJh4T for ; Mon, 12 Sep 2011 11:26:15 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 408BD21F8B6C for ; Mon, 12 Sep 2011 11:26:15 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,516,1309752000"; d="scan'208";a="257730634" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Sep 2011 14:26:48 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 12 Sep 2011 14:28:18 -0400 From: "George, Wesley" To: Christopher Morrow , Randy Bush Date: Mon, 12 Sep 2011 14:28:17 -0400 Thread-Topic: [sidr] BGPSec scaling (was RE: beacons and bgpsec) Thread-Index: Acxw+6lMmkuZEwfjSfeyxWpzK0PFvgATicDA Message-ID: <34E4F50CAFA10349A41E0756550084FB0E26B03F@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 18:26:16 -0000 -----Original Message----- From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On= Behalf Of Christopher Morrow Sent: Sunday, September 11, 2011 11:26 PM To: Randy Bush; George, Wesley Cc: Russ White; sidr@ietf.org Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) maybe what Wes is asking here is really: "Could someone model the load on a router doing bgpsec, in a world of bgpsec speaking devices?" Something like, for a core network edge device (say sprint, C&W, TWTC, UU/vzb,ATT an edge connecting device in their worst metro): o number of updates today/second (steady state and 'worst case') o projected growth of update stream (given historical data) o projected 'cost' (cpu cycles) of un-assisted bgpsec o projected RIB RAM size (use historical data to project forward) o projected beacons/second (which really just look like updates in the update stream) o routing table size (projected forward from historical data) It seems most of that data exists in one form or another, it seems that running the math isn't "hard". There's a question of the validity of the model... but that's always the case. Wes, is this sort of thing what you're asking for? WEG] Yes, to some extent, but you're right that the model is the hard part,= not the math. In trying to unwind a similar problem of how to characterize= steady-state and peak CPU load on a L3VPN PE router so that there are real= rules of thumb for capacity management and scaling, we discovered a couple= of things - 1) (some) Vendors are quite bad at providing reasonably accurate multi-dime= nsional scaling models based on testing or real-world results. They tend to= give a lot of single-dimension scale limits (eg with this knob turned to 1= 1, you can get this value), but are very conservative and mumbly when it co= mes to what the actual real-life limits are, YMMV, etc. As a result, someti= mes you end up finding out about the scaling cliff as you're falling over i= t, or you pay for hardware that you can never fully use because you stick t= o very conservative limitations. 2) a corollary: behavior at scale becomes increasingly non-deterministic th= e more variables you're working with simultaneously. Even worse, it's diffi= cult to account in a model for things that work well enough at moderate sca= le, but are not efficient enough for high scale, or suffer some sort of sec= ondary impact due to dependencies, etc. 3) some routers are very bad at providing useful data about critical scalin= g vectors (updates per sec, changes in multicast state, etc). Coupled with = the fact that each router's numbers can be wildly different, it's difficult= to characterize a "common" router, let alone a common network. 4) there are widely varying opinions among vendors and operators as to what= is an acceptable level of performance at scale i.e. time to convergence of= last route, steady-state CPU utilization (how much headroom is enough), st= ability during system or network events. I think that what is coming up here are concerns in a couple of different c= ategories: 1) Short-term hardware scale - is BGPSec supportable with what is realistic= ally available today? For how long? Is that long enough? 2) Long-term hardware scale (5+ years) - What's the next breakthrough? How = long does that buy us? Is that long enough? What does it do to our time rem= aining before we have to redesign the routing system to make it keep scalin= g? This is where we should be considering RFC4984 and either updating or affir= ming the guidance there. 3) Cost for both - what is an acceptable assumption of the cost premium for= BGPSec, in both capital and personnel? On the hardware side, we're in a discussion that sounds a lot like predicti= ng peak oil - when do we run out of scale growth on Moore's law with the cu= rrent overall Internet architecture, and will BGPSec be just "one more gas-= guzzler on the road" or the straw that broke the camel's back? I don't know that we're going to get a definitive answer from modeling, and= I'm not trying to bring on analysis paralysis either. Randy's (and mine, a= nd everyone else's) guess may be BS, but even making a gut check based on w= hat info we have available and documenting the assumptions we're basing our= decision on would be a good thing. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Mon Sep 12 12:07:41 2011 Return-Path: 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 E126321F8C41 for ; Mon, 12 Sep 2011 12:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkHVh49A2R6m for ; Mon, 12 Sep 2011 12:07:41 -0700 (PDT) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 88E5621F8C5F for ; Mon, 12 Sep 2011 12:07:34 -0700 (PDT) Received: by gxk28 with SMTP id 28so4020262gxk.27 for ; Mon, 12 Sep 2011 12:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dV3lpEcfNgbO8S/Ciu0lsIG7JD9GXQD01PGpSvuSA58=; b=mBjnRHVcrEUg5iY0Jo86qZUEedr0UsLOWhLiMR40DEgB0BQS4PJ2llJKBPz6Xcyglu RRTcY/d1JYzRVFE3mg3qwHPhs9KOHYyl24EIS57O+5QgMH+QstK/hO46ympKR+eOxdQe UuiYzPP/u8cqEj+OsEHHaEWCxqf8kVKz2oLgs= MIME-Version: 1.0 Received: by 10.42.135.129 with SMTP id p1mr269590ict.56.1315854577866; Mon, 12 Sep 2011 12:09:37 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.65.5 with HTTP; Mon, 12 Sep 2011 12:09:37 -0700 (PDT) In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E26B03F@PRVPEXVS04.corp.twcable.com> References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <34E4F50CAFA10349A41E0756550084FB0E26B03F@PRVPEXVS04.corp.twcable.com> Date: Mon, 12 Sep 2011 15:09:37 -0400 X-Google-Sender-Auth: qew3vN0OhLH-jAnqYJsxtB3PhG0 Message-ID: From: Christopher Morrow To: "George, Wesley" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 19:07:42 -0000 On Mon, Sep 12, 2011 at 2:28 PM, George, Wesley wrote: > -----Original Message----- > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] = On Behalf Of Christopher Morrow > Sent: Sunday, September 11, 2011 11:26 PM > To: Randy Bush; George, Wesley > Cc: Russ White; sidr@ietf.org > Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) > > maybe what Wes is asking here is really: > "Could someone model the load on a router doing bgpsec, in a world of > bgpsec speaking devices?" > > Something like, for a core network edge device (say sprint, C&W, TWTC, > UU/vzb,ATT an edge connecting device in their worst metro): > =A0o number of updates today/second (steady state and 'worst case') > =A0o projected growth of update stream (given historical data) > =A0o projected 'cost' (cpu cycles) of un-assisted bgpsec > =A0o projected RIB RAM size (use historical data to project forward) > =A0o projected beacons/second (which really just look like updates in > the update stream) > =A0o routing table size (projected forward from historical data) > > It seems most of that data exists in one form or another, it seems > that running the math isn't "hard". There's a question of the validity > of the model... but that's always the case. > > Wes, is this sort of thing what you're asking for? > > WEG] Yes, to some extent, but you're right that the model is the hard par= t, not the math. In trying to unwind a similar problem of how to characteri= ze steady-state and peak CPU load on a L3VPN PE router so that there are re= al rules of thumb for capacity management and scaling, we discovered a coup= le of things - > 1) (some) Vendors are quite bad at providing reasonably accurate multi-di= mensional scaling models based on testing or real-world results. They tend = to give a lot of single-dimension scale limits (eg with this knob turned to= 11, you can get this value), but are very conservative and mumbly when it = comes to what the actual real-life limits are, YMMV, etc. As a result, some= times you end up finding out about the scaling cliff as you're falling over= it, or you pay for hardware that you can never fully use because you stick= to very conservative limitations. > 2) a corollary: behavior at scale becomes increasingly non-deterministic = the more variables you're working with simultaneously. Even worse, it's dif= ficult to account in a model for things that work well enough at moderate s= cale, but are not efficient enough for high scale, or suffer some sort of s= econdary impact due to dependencies, etc. > 3) some routers are very bad at providing useful data about critical scal= ing vectors (updates per sec, changes in multicast state, etc). Coupled wit= h the fact that each router's numbers can be wildly different, it's difficu= lt to characterize a "common" router, let alone a common network. > 4) there are widely varying opinions among vendors and operators as to wh= at is an acceptable level of performance at scale i.e. time to convergence = of last route, steady-state CPU utilization (how much headroom is enough), = stability during system or network events. > > I think that what is coming up here are concerns in a couple of different= categories: > 1) Short-term hardware scale - is BGPSec supportable with what is realist= ically available today? For how long? Is that long enough? > 2) Long-term hardware scale (5+ years) - What's the next breakthrough? Ho= w long does that buy us? Is that long enough? What does it do to our time r= emaining before we have to redesign the routing system to make it keep scal= ing? > This is where we should be considering RFC4984 and either updating or aff= irming the guidance there. > 3) Cost for both - what is an acceptable assumption of the cost premium f= or BGPSec, in both capital and personnel? > > On the hardware side, we're in a discussion that sounds a lot like predic= ting peak oil - when do we run out of scale growth on Moore's law with the = current overall Internet architecture, and will BGPSec be just "one more ga= s-guzzler on the road" or the straw that broke the camel's back? > > I don't know that we're going to get a definitive answer from modeling, a= nd I'm not trying to bring on analysis paralysis either. Randy's (and mine,= and everyone else's) guess may be BS, but even making a gut check based on= what info we have available and documenting the assumptions we're basing o= ur decision on would be a good thing. I agree with the above, and the last comment really was what I was aiming at.. If someone were to model the 6-ish items I outlined, and properly documented their test-harness (and maybe provided it out so folk could test with their favorite settings?) that would help us get around this paralysis problem. At least we'd feel a bit more comfortable having something to check against. -chris From rjs@rob.sh Tue Sep 13 11:23:22 2011 Return-Path: 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 7997A11E8098 for ; Tue, 13 Sep 2011 11:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2p-X25pV5FI for ; Tue, 13 Sep 2011 11:23:13 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id 92EBF11E8095 for ; Tue, 13 Sep 2011 11:23:11 -0700 (PDT) Received: from [195.10.56.23] (helo=[212.137.15.68]) by cappuccino.rob.sh with esmtpa (Exim 4.69) (envelope-from ) id 1R3XeC-0001sp-9L; Tue, 13 Sep 2011 19:23:52 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0E26B03F@PRVPEXVS04.corp.twcable.com> Date: Tue, 13 Sep 2011 19:25:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <4E6A2CD0.1010305@riw.us> <34E4F50CAFA10349A41E0756550084FB0E26B03F@PRVPEXVS04.corp.twcable.com> To: "George, Wesley" X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 18:23:22 -0000 On 12 Sep 2011, at 19:28, George, Wesley wrote: > I don't know that we're going to get a definitive answer from = modeling, and I'm not trying to bring on analysis paralysis either. = Randy's (and mine, and everyone else's) guess may be BS, but even making = a gut check based on what info we have available and documenting the = assumptions we're basing our decision on would be a good thing. +1 to all Wes said in this post. I've spent quite some time on similar problems (particularly around = control-plane scale for network elements), and agree that modelling does = not necessarily yield a definitive answer - however, some guidance as to = what we might expect to need to be able to cater for is of great = advantage from my perspective. r.= From internet-drafts@ietf.org Tue Sep 13 20:13:06 2011 Return-Path: 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 87B9111E80AC; Tue, 13 Sep 2011 20:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOSeHxjRrJIF; Tue, 13 Sep 2011 20:13:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9F211E80A0; Tue, 13 Sep 2011 20:13:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914031306.12941.26781.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 20:13:06 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 03:13:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-10.txt Pages : 8 Date : 2011-09-13 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-10.txt From internet-drafts@ietf.org Wed Sep 14 05:55:39 2011 Return-Path: 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 90B9D21F8CAF; Wed, 14 Sep 2011 05:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNbrZtbS4E+m; Wed, 14 Sep 2011 05:55:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878D21F8CA8; Wed, 14 Sep 2011 05:55:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914125535.19395.98326.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 05:55:35 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 12:55:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-11.txt Pages : 8 Date : 2011-09-14 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-11.txt From internet-drafts@ietf.org Wed Sep 14 08:41:49 2011 Return-Path: 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 7AB7C21F8B88; Wed, 14 Sep 2011 08:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri4uPOvDTgT0; Wed, 14 Sep 2011 08:41:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E60721F87FC; Wed, 14 Sep 2011 08:41:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914154149.30815.50396.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 08:41:49 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 15:41:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-12.txt Pages : 8 Date : 2011-09-14 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-12.txt From iesg-secretary@ietf.org Wed Sep 14 11:25:03 2011 Return-Path: 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 F26DB21F8CD3; Wed, 14 Sep 2011 11:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBvQub-D6gBk; Wed, 14 Sep 2011 11:25:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727D521F8C29; Wed, 14 Sep 2011 11:25:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914182502.19618.56338.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 11:25:02 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (The RPKI Ghostbusters Record) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:25:03 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI Ghostbusters Record' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-ghostbusters/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-ghostbusters/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Thu Sep 15 01:45:10 2011 Return-Path: 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 3A72521F85CE; Thu, 15 Sep 2011 01:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.317 X-Spam-Level: X-Spam-Status: No, score=-98.317 tagged_above=-999 required=5 tests=[AWL=4.283, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlBzZODoGweG; Thu, 15 Sep 2011 01:45:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C441E21F854D; Thu, 15 Sep 2011 01:45:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110915084509.27106.75533.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2011 01:45:09 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 08:45:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-13.txt Pages : 8 Date : 2011-09-15 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-13.txt From randy@psg.com Thu Sep 15 01:47:16 2011 Return-Path: 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 98E2821F851F; Thu, 15 Sep 2011 01:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNb7ZypCANOA; Thu, 15 Sep 2011 01:47:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABDD21F84ED; Thu, 15 Sep 2011 01:47:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R47dO-000J4r-Mx; Thu, 15 Sep 2011 08:49:27 +0000 Date: Thu, 15 Sep 2011 10:49:25 +0200 Message-ID: From: Randy Bush To: The IESG In-Reply-To: <20110914182502.19618.56338.idtracker@ietfa.amsl.com> References: <20110914182502.19618.56338.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF , sidr@ietf.org Subject: Re: [sidr] Last Call: (The RPKI Ghostbusters Record) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 08:47:16 -0000 > The IESG has received a request from the Secure Inter-Domain Routing WG > (sidr) to consider the following document: > - 'The RPKI Ghostbusters Record' > as a Proposed Standard note that some apps-area fixes have caused me to revise to -13 randy From stbryant@cisco.com Thu Sep 15 02:04:07 2011 Return-Path: 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 AB43A21F85D1 for ; Thu, 15 Sep 2011 02:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-xCs8Y94+5q for ; Thu, 15 Sep 2011 02:04:06 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 126B021F85BB for ; Thu, 15 Sep 2011 02:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1954; q=dns/txt; s=iport; t=1316077577; x=1317287177; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rk7+t2AjB28FOnTbES48oYWbRnS7eLeg5XEUSnuZqg4=; b=OKKyCn7ReNUifVWQosvn6bmz/Kud48vCTpuRa5LohbbjFLLSMM0hXi2/ EszQAKA6RzzqfJ2/iesM5/O8I+zLJ3iJqvDhQ+LbxCF7i6mPrKwyFM3E0 Ly5MNiktov3eyznxlgCdY5wnVY9h4vK2lt9snoy3JLMHbPlu8wx/452Xe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIGAFu/cU6Q/khR/2dsb2JhbAA4CpkWjjd4gVMBAQEBAgESAQIBHAEFLxEBBQcEHAMBAgEJFggHCQMCAQIBNAcCCBMBBQIBAQUZh1UElwoBgyYPAZppg02DJwSTR5Er X-IronPort-AV: E=Sophos;i="4.68,386,1312156800"; d="scan'208";a="54689339" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 15 Sep 2011 09:06:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8F96Dkt014107; Thu, 15 Sep 2011 09:06:13 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p8F968Ze013420; Thu, 15 Sep 2011 10:06:08 +0100 (BST) Message-ID: <4E71C000.6000702@cisco.com> Date: Thu, 15 Sep 2011 10:06:08 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: draft-ietf-sidr-ghostbusters@tools.ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: [sidr] Fwd: Re: [ietf-types] Registration of media type application/rpki-ghostbusters X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 09:04:07 -0000 This was the feedback on the types list. - Stewart -------- Original Message -------- Subject: Re: [ietf-types] Registration of media type application/rpki-ghostbusters Date: Wed, 14 Sep 2011 20:01:41 +0200 From: Bjoern Hoehrmann To: stbryant@cisco.com CC: ietf-types * Stewart Bryant wrote: >Please review http://www.ietf.org/id/draft-ietf-sidr-ghostbusters-12.txt > >The IANA is requested to register the media type application/ > rpki-ghostbusters as follows > > MIME media type name: application > MIME subtype name: rpki-ghostbusters > Required parameters: None > Optional parameters: None > Encoding considerations: binary > Security considerations: Carries an RPKI Ghostbusters Record > [I-D.ietf-sidr-ghostbusters]. > Interoperability considerations: None > Published specification: This document This seems to lack a statement what content you use this label for, from the document one might well think a vCard file that follows the rules in the document could use this type. > Applications which use this media type: Any MIME-complaint transport This should identify the class of applications (think "photo editing"). > Additional information: > Magic number(s): None > File extension(s): .gbr > Macintosh File Type Code(s): > Person& email address to contact for further information: > Randy Bush > Intended usage: COMMON > Author/Change controller: Randy Bush You are using an outdated template, the current one is in RFC 4288. Some of the fields are named and/or organized differently. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From randy@psg.com Thu Sep 15 02:20:34 2011 Return-Path: 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 B9BEB21F85F7 for ; Thu, 15 Sep 2011 02:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikoxvK5CuYXu for ; Thu, 15 Sep 2011 02:20:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5721F857D for ; Thu, 15 Sep 2011 02:20:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R489O-000J98-89; Thu, 15 Sep 2011 09:22:30 +0000 Date: Thu, 15 Sep 2011 11:22:28 +0200 Message-ID: From: Randy Bush To: Stewart Bryant In-Reply-To: <4E71C000.6000702@cisco.com> References: <4E71C000.6000702@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org, "sidr-chairs@tools.ietf.org" , draft-ietf-sidr-ghostbusters@tools.ietf.org Subject: Re: [sidr] Fwd: Re: [ietf-types] Registration of media type application/rpki-ghostbusters X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 09:20:34 -0000 > This was the feedback on the types list. oh goodie next rev, when i get time randy, on holiday From warren@kumari.net Thu Sep 15 13:42:01 2011 Return-Path: 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 2D1CF11E807F; Thu, 15 Sep 2011 13:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.346 X-Spam-Level: X-Spam-Status: No, score=-101.346 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, MANGLED_LOAN=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sVbASJUQD+P; Thu, 15 Sep 2011 13:42:00 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6800011E80A0; Thu, 15 Sep 2011 13:42:00 -0700 (PDT) Received: from dhcp-172-19-119-117.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 75DD81B416DA; Thu, 15 Sep 2011 16:44:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <318A63EA-6290-4D1E-B236-4F4621E0C2CB@kumari.net> Date: Thu, 15 Sep 2011 16:44:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <318A63EA-6290-4D1E-B236-4F4621E0C2CB@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) Cc: Christopher Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 20:42:01 -0000 On Sep 8, 2011, at 10:05 AM, Warren Kumari wrote: >=20 > On Sep 8, 2011, at 5:59 AM, Randy Bush wrote: >=20 >> hi terry, >>=20 >>> It strikes me that this is the first time you have read this draft = despite >>> the several calls to the WG to do so. >>=20 >> this version, yes. read a year or so ago, and it was structurally so >> off my map that i did not do more than scan. >>=20 >>> That's not bad exactly... just unexpected. >>=20 >> in one sense, it's what wglc is all about. and this is just not high = on >> my radar. >>=20 >>> I'm less interested in your abrupt critique and certainly much more >>> interested in constructive reviews of which you started below and = then >>> gave up.. >>=20 >> apologies, but the multiple hours needed would not come up on my >> priority stack for a long while. i would hope the authors would know >> how to be more precise. >>=20 >> as i said privately to the chairs >>=20 >> ... that docco is *really* sloppy. i am kinda wondering why no one >> else has raised the rather amazing editorial issues. no one >> bothered to read it? >=20 >=20 > I'll happily admit to not having responded to the WGLC because I = didn't read the document=85 >=20 > I have placed it on my ToRead pile, but it will take some time to = propagate up the stack=85 Alrighty, I took an initial pass at this, but believe that it needs: A: a second, much deeper reading and=20 B: some work to make it more ledgible. The base content seems good (and I support it moving forward), but I = found the language and wording to be difficult to follow and feel that = it should be cleaned up -- it feels a bit like there were multiple = editors? Some initial notes: Comments: 1:=20 I found the Abstract to be basically unparsable. Sooo many words, so = little punctuation. Suggest removing "in relation to the Internet routing system." or = liberally sprinkling with commas. 2:=20 Throughout the paper you use the term "as intended" (e.g: "It wishes to announce the /24 prefix from ASN 64496 such that relying = parties interpret the route as intended.") I found this tricky to parse - suggest explaining what you mean by "as = intended" (or changing that to "as a valid route" or something). 3:=20 Suggest sorting / grouping the Definitions (and probably pointing at = existing definitions for things like AS) and cleaning up the definitions = a bit. For example, 65534 is a valid ASN, but is not "officially = registered". 4:=20 Section 2.1: The first sentence is very hard to parse. How about:=20 "It is important that replying parties (RP) or relying party routing = software adopt a 'make before break' stance." instead? Also, it is really necessary to specify "or relying party routing = software"? It's unlikely that the parties themselves would do anything, = it's understood (I think) that it's the software working on their = behalf. Section 2.1: Last sentence, first paragraph. "For all of the cases in this document it is assumed that RPKI objects validate (or otherwise) in accordance with [I-D.ietf-sidr-res-certs], [I-D.ietf-sidr-arch], [I-D.ietf-sidr-roa-validation] unless otherwise stated. " The "(or otherwise)" is confusing - actually, to be honest I don't = really understand what you were trying to say here. Section 5.1: Title: "Parent does not do RPKI". Suggest rewording this -- not sure how, but the "do" seems vague. Section 6: The first sentence is confusing (to me).=20 My suggestion (only slightly better): Based on the previous section it should be easy to deduce what new ROAs = need to be created and what existing ones need to be maintained (or = revoked). Nits: Section 2.1: O: it should be recognised that a prefix holder P: it should be recognized that a prefix holder C: s/recognised/recognized/. Section 3.10 and also in Section 3.11:=20 O: It is currently not possible for an upstream to make a valid = aggregate annoucement of indepentant prefixes. =20 P: It is currently not possible for an upstream to make a valid = aggregate announcement of independent prefixes. =20 C: s/annoucement/announcement/, s/indepentant/independent/ 3.11: O: following resources which were acquired P: following resources that were acquired C: restrictive clause. Section 5.1: O: "An organization (Org A with ASN 64511) is multi-homed has been = assigned the prefix" C: "An organization that..." or "is multi-homed and has..." Section 5.2: O: Org B with ASN 64511 and and Org C=20 P: Org B with ASN 64511 and Org C=20 C: You have an 'and' and an 'and', making an 'and and' and all you need = is an 'and' :-) Section 6.3:=20 O: Organization A may optionally provide ROA coverage for Organisation B P: Organization A may optionally provide ROA coverage for Organization B C: s/Organisation/Organization/ -- consistency. Section 7.1: O: The use cases described here can be potentailly used as test cases P: The use cases described here can be potentially used as test cases C: s/potentailly/potentially/ Section 7.1.1: O: This is a straight forward prefix-origin validation use case; P: This is a straightforward prefix-origin validation use case; or P: This is the standard prefix-origin validation use case; or something! Section 7.1.6: O: and it turns out that there exit ROAs for more specifics which, if = combined,=20 P: and it turns out that there exist ROAs for more specifics that, if = combined,=20 C: s/exit/exist/ C: s/which/that/ - restrictive / non-restrictive rule. Section 7.1.11:=20 O: In fact, the update in consideration would have received an Invalid = staus=20 P: In fact, the update in consideration would have received an Invalid = status=20 C: s/staus/status/ ---- I'll try reread before WGLC cutoff. W >=20 > W >=20 >> i admit that i have not read it for a year or >> so. >>=20 >> please view my comments as just that. i do not formally object to >> the doc being passed to the iesg. imiho, they probably deserve >> it. :) >>=20 >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 From carlosm3011@gmail.com Thu Sep 15 15:03:11 2011 Return-Path: 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 6EBA521F869E for ; Thu, 15 Sep 2011 15:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCSXY3PM90jU for ; Thu, 15 Sep 2011 15:03:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20E21F85B9 for ; Thu, 15 Sep 2011 15:03:10 -0700 (PDT) Received: by fxd18 with SMTP id 18so1186902fxd.31 for ; Thu, 15 Sep 2011 15:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=hej0Gy3eBPSiWkUyzygL2ibZp/997QpnGFWl5Gddt50=; b=Z5TPN/yElSfEduutHaYnyG9o1F/K1TLdMDkM8ulvMK++HDSwEQDT8wMYIGPPkO7r/I EZ2p18hAzechrPIP8YtIToe8xU1RLaxcMLH6bFC1WP60p9hgI/E3zfEpoqUgOFlDYMCU SD2iRoFAg3BWSCgfFdBk//BgU3/bul7dP3tLg= MIME-Version: 1.0 Received: by 10.223.33.145 with SMTP id h17mr1240160fad.130.1316124322608; Thu, 15 Sep 2011 15:05:22 -0700 (PDT) Received: by 10.152.14.2 with HTTP; Thu, 15 Sep 2011 15:05:22 -0700 (PDT) Date: Thu, 15 Sep 2011 19:05:22 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] ROA management recommendations for users X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 22:03:11 -0000 Hello, I am working on a presentation giving some recommendations for RPKI early adopters. I want to provide some guidelines on how they should go about creating their ROAs, and I would love to receive some input from this list. Broadly speaking, and looking at what people have created in the repositories so far, there seem to be two different views on the matter: - ROAs that mirror BGP announcements and/or block de-aggregation within networks For example, an organization with as 100 holding 10.1/16 and having sub-allocated 10.1.128/18 to as 200 creates something like this: ROA #1: 10.1.0/17-18, 10.1.192/18-18 origin-as 100 ROA #2: 10.1.128/18-18 origin-as 200 - ROAs that protect all the way to /32 (in IPv4) Using the same example as above, they would have: ROA #1: 10.1/16-32 origin-as 100 ROA #2: 10.1.128/18-32 origin-as 200 Your input and thoughts are much appreciated! Warm regards, Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From kotikalapudi.sriram@nist.gov Thu Sep 15 16:25:25 2011 Return-Path: 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 464A821F8B4E for ; Thu, 15 Sep 2011 16:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLxuMXw8-oz5 for ; Thu, 15 Sep 2011 16:25:24 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7788D21F8B4C for ; Thu, 15 Sep 2011 16:25:16 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.323.0; Thu, 15 Sep 2011 19:29:01 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 15 Sep 2011 19:26:51 -0400 From: "Sriram, Kotikalapudi" To: "carlos@lacnic.net" , "sidr@ietf.org" Date: Thu, 15 Sep 2011 19:27:21 -0400 Thread-Topic: [sidr] ROA management recommendations for users Thread-Index: Acxz836i0KlQWNGXR1uFeXlIj20QjgACQvoA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] ROA management recommendations for users X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 23:25:25 -0000 Please see comments below. Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Carlos > > Broadly speaking, and looking at what people have created in the > repositories so far, there seem to be two different views on the > matter: > > - ROAs that mirror BGP announcements and/or block de-aggregation within networks > For example, an organization with as 100 holding 10.1/16 and having > sub-allocated 10.1.128/18 to as 200 creates something like this: > > ROA #1: 10.1.0/17-18, 10.1.192/18-18 origin-as 100 > ROA #2: 10.1.128/18-18 origin-as 200 > > - ROAs that protect all the way to /32 (in IPv4) > > Using the same example as above, they would have: > ROA #1: 10.1/16-32 origin-as 100 > ROA #2: 10.1.128/18-32 origin-as 200 The first approach (minimal maxLength in the ROA) is recommended. Please see Section 3 of http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-10 where it says: "One advantage of minimal ROA length is that the forged origin attack does not work for sub-prefixes that are not covered by overly long max length. E.g. if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed against 10.0.66.0/24. They must attack the whole /16, which is more likely to be noticed. Therefore, ROA generation software MUST use the prefix length as the max length if the user does not specify a max length." You may also take a look at http://tools.ietf.org/html/draft-ietf-sidr-usecases-02#section-3.3 Sriram From bje@apnic.net Thu Sep 15 18:34:25 2011 Return-Path: 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 8CDBE11E80B1 for ; Thu, 15 Sep 2011 18:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usm0NVa8X3nF for ; Thu, 15 Sep 2011 18:34:25 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 343FB11E80A2 for ; Thu, 15 Sep 2011 18:34:19 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:9d8d:d0bc:d275:51eb] (unknown [IPv6:2001:dc0:a000:4:9d8d:d0bc:d275:51eb]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 7A797B689A; Thu, 15 Sep 2011 21:36:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_E26F41CC-B702-464A-AC90-E8F29E8516EC"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Fri, 16 Sep 2011 11:36:24 +1000 Message-Id: <266A2D14-C3AC-4342-9270-4F5F0ADF135E@apnic.net> References: To: carlos@lacnic.net X-Mailer: Apple Mail (2.1244.3) Cc: sidr@ietf.org Subject: Re: [sidr] ROA management recommendations for users X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 01:34:25 -0000 --Apple-Mail=_E26F41CC-B702-464A-AC90-E8F29E8516EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Carlos, On 16/09/2011, at 8:05 AM, Carlos Martinez-Cagnazzo wrote: > Broadly speaking, and looking at what people have created in the > repositories so far, there seem to be two different views on the > matter: APNIC made the change to support sidr-origin-ops' MUST about prefix = length recently, but we did not re-issue ROAs. If you're looking at = objects in our repository, check the notBefore date to know what the = most current behaviour is :-) Byron= --Apple-Mail=_E26F41CC-B702-464A-AC90-E8F29E8516EC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH0zCCA8ow ggKyoAMCAQICCD2r7AwmaYdlMA0GCSqGSIb3DQEBBQUAMHIxEDAOBgNVBAMMB3Jvb3QtY2ExEjAQ BgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwIQnJpc2Jh bmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUwHhcNMTAwNTExMDQyODAzWhcNMTUw NTExMDQyODAzWjBzMREwDwYDVQQDDAhzdGFmZi1jYTESMBAGA1UECwwJVGVjaG5pY2FsMRYwFAYD VQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhCcmlzYmFuZTESMBAGCgmSJomT8ixkARkWAmNh MQswCQYDVQQGEwJBVTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANDIhBZoGNolhTjw o5Gkb9BX9OnqIE4xhbUKT8k1dA83q5DRutJbLDfzOiKN81FnbeuJijKwHo8QMAM4+hJW/fjGLXMe G25PD06aAX7kuyF/n4SJZ1YnZOp4wriYYDvEtp5WHtxSaJWBrRgzoQYo8fCRFC3QF+TPDtijQO36 AEmy0Y1hOokR6ps9s97VT8e/bGfrE3kXRzWLLGupM0++Px2A3GCmvnxI4keslVp5lZI8ULddVX0s GXqbjlcdHipQF3MklYO7glX3/lpAJupo3yk+xOCJu+g/GVkUAEl86VTQPKR7zUnRukuzCJ70h6Zj QTwYE2lVtfMir69Mx8a30r8CAwEAAaNjMGEwHQYDVR0OBBYEFOA9t5Jb7i6jsj5520WrMEIvAUus MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUbtpM6r1cZ29SwAakpWJiv0BBFTIwDgYDVR0P AQH/BAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQCgXALZN+XpsFl3TYi4l8UbwSvGMrQg7/6SYilO rm59coWoz1bfWV6sYGNRnLn7GQSVaBttk25FqHd/mQJNrphK+c6ajcEYCSBLp+1S+k+Zul3biwhr X5kFmt6KDN/JLmpCN8lUjcXUzsbBNeDQB66/z4Q5oEEw6znDMd7xgQgFqSw1fzrvM/3hVBkeiqa/ zrY6P3gb2yxmDlM5fET9ebwo+EHrMfyM15XwxFz2bUHXI2o4asIkxgVfNlBSB2n7MBaF/piXrEB/ eH1fq+JmZsBfqxEMr0yamcz1QpLIZrDcNVaW5dWgeSVpoPmqnmB2tqwQ6/5yN93CBj4Iid+14Owc MIIEATCCAumgAwIBAgIIPW0fj+lGjnUwDQYJKoZIhvcNAQEFBQAwczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUwHhcNMTAxMTMwMDYwNjI5 WhcNMTExMTMwMDYwNjI5WjCBkTETMBEGCgmSJomT8ixkAQEMA2JqZTEXMBUGA1UEAwwOQnlyb24g RWxsYWNvdHQxDjAMBgNVBCoMBUJ5cm9uMREwDwYDVQQEDAhFbGxhY290dDEPMA0GA1UECwwGUGVv cGxlMRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRkMRUwEwYKCZImiZPyLGQBGRYFc3RhZmYwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsIXl2q92/JXepd+uHY3OvuMmDgTU1sn2P+s5gHzB/ EoqUrqu3rOV6rLFC8PGJWb9VxA1wQrevtcvAtI8KwfBtlflZxKCcaTFY64DGbPXdP25h9o1nMVty P2hytrccIbIm+reD+2YmQGS32Auf5pOrGuWB4bdPor2VKJXyU4xNMxGglL4HEDPe4CKqTkmep9Yx 0uEsXAfEcaNlsszPNzycfgN1g6llHOu07DI46fl6HtCRdx/GW528gSRqmCp9Xh8Yt3/1yd52ynvu h2fgVPuufad2J3X39Ngf8K67Y8nBIQmZJM15l8f+yOlqLz+0hnn01i58ZvqE3XWFFjSlqE7bAgMB AAGjejB4MB0GA1UdDgQWBBTYoaRdR2+3TBx8iUvBghmZnnNBLzAMBgNVHRMBAf8EAjAAMB8GA1Ud IwQYMBaAFOA9t5Jb7i6jsj5520WrMEIvAUusMA4GA1UdDwEB/wQEAwIB8jAYBgNVHREEETAPgQ1i amVAYXBuaWMubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQCzAdtGkW9ezHysxrV+RozhLKVVPUwLy1vH h/mrDrLkbt1smKiODuiqwyXfvBS8CD8jeQEAdKi+NXUu2w758xGSNQXO6ykxh2eCbpsI8cNSG+4S ugxtjPHI9ve/mIneD6q64x15VQYT44YEcUdEbubExOAYVUypZFJGea+oWWgEauH3wYYOtU96Kg5A 3Q7C5nwRYBxSX87UPLAgpTL6Tz53irMGDQN9KL2lIjs5fBYJuS1UAOfwP+O8i7y40couFK5+V45u TinYfLHmiaVGn2ygZGRZwvd8/x8A+ihvqr2FWr6AKnr5tMQN7QHpwbaf4ARMltzV3rc+MVEf6hdh C1vIMYIDLTCCAykCAQEwfzBzMREwDwYDVQQDDAhzdGFmZi1jYTESMBAGA1UECwwJVGVjaG5pY2Fs MRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhCcmlzYmFuZTESMBAGCgmSJomT8ixk ARkWAmNhMQswCQYDVQQGEwJBVQIIPW0fj+lGjnUwCQYFKw4DAhoFAKCCAYMwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTE2MDEzNjMxWjAjBgkqhkiG9w0BCQQx FgQUm5sOj2H1w/mwaJRHQt3p36myEIYwgY8GCSsGAQQBgjcQBDGBgTB/MHMxETAPBgNVBAMMCHN0 YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNV BAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVAgg9bR+P6UaOdTCB kQYLKoZIhvcNAQkQAgsxgYGgfzBzMREwDwYDVQQDDAhzdGFmZi1jYTESMBAGA1UECwwJVGVjaG5p Y2FsMRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhCcmlzYmFuZTESMBAGCgmSJomT 8ixkARkWAmNhMQswCQYDVQQGEwJBVQIIPW0fj+lGjnUwDQYJKoZIhvcNAQEBBQAEggEAHYWsVrKA ar2Blczaqjqu40X3bn/LzdkygvqO7YF6ecKaZ6mGVIJ0UTolsSCwC+8G2ipD0GFYp775kXkV9ax6 2vLh+I9GDYq+4G6h3dlGB4g4bV9VLtO3x5hjNgRETcDDnqHUjntTxG/DKZIx0nLm/ZpP+k820YyT n6ODatM1+Gd6oQR1fIJALCUgmIHkJcb4L7bneOus72+CapokLEFyp4IUQpdfdskywkSr1g5HluLA DVD5MXDbmTyyjfFzw5iWFhEFryj2DeABjUmGoLqMQgLH+oOFQMi1zqX2f+erNw9aV6AkmP23b7S3 98KLYMOpXF1H1ZD5PhkfyuXly52rcQAAAAAAAA== --Apple-Mail=_E26F41CC-B702-464A-AC90-E8F29E8516EC-- From randy@psg.com Thu Sep 15 21:39:44 2011 Return-Path: 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 562F511E809A for ; Thu, 15 Sep 2011 21:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idx8enMmiSe2 for ; Thu, 15 Sep 2011 21:39:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D2FFE11E8086 for ; Thu, 15 Sep 2011 21:39:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R4QFP-000MQi-KV; Fri, 16 Sep 2011 04:41:55 +0000 Date: Fri, 16 Sep 2011 06:41:53 +0200 Message-ID: From: Randy Bush To: Carlos Martinez-Cagnazzo In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] ROA management recommendations for users X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 04:39:44 -0000 > I am working on a presentation giving some recommendations for RPKI > early adopters. I want to provide some guidelines on how they should > go about creating their ROAs, and I would love to receive some input > from this list. > > Broadly speaking, and looking at what people have created in the > repositories so far, there seem to be two different views on the > matter: > > - ROAs that mirror BGP announcements and/or block de-aggregation within networks > For example, an organization with as 100 holding 10.1/16 and having > sub-allocated 10.1.128/18 to as 200 creates something like this: > > ROA #1: 10.1.0/17-18, 10.1.192/18-18 origin-as 100 > ROA #2: 10.1.128/18-18 origin-as 200 > > - ROAs that protect all the way to /32 (in IPv4) > > Using the same example as above, they would have: > ROA #1: 10.1/16-32 origin-as 100 > ROA #2: 10.1.128/18-32 origin-as 200 from draft-ietf-sidr-origin-ops-10.txt To aid translation of ROAs into efficient search algorithms in routers, ROAs SHOULD be as precise as possible, i.e. match prefixes as announced in BGP. E.g. software and operators SHOULD avoid use of excessive max length values in ROAs unless operationally necessary. One advantage of minimal ROA length is that the forged origin attack does not work for sub-prefixes that are not covered by overly long max length. E.g. if, instead of 10.0.0.0/16-24, one issues 10.0.0.0/16 and 10.0.42.0/24, a forged origin attack can not succeed against 10.0.66.0/24. They must attack the whole /16, which is more likely to be noticed. Therefore, ROA generation software MUST use the prefix length as the max length if the user does not specify a max length. Operators SHOULD be conservative in use of max length in ROAs. E.g., if a prefix will have only a few sub-prefixes announced, multiple ROAs for the specific announcements SHOULD be used as opposed to one ROA with a long max length. randy From christopher.morrow@gmail.com Mon Sep 26 06:41:58 2011 Return-Path: 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 443F521F84D8; Mon, 26 Sep 2011 06:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeDqWYMvsw7D; Mon, 26 Sep 2011 06:41:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0921F84D3; Mon, 26 Sep 2011 06:41:55 -0700 (PDT) Received: by iaby26 with SMTP id y26so5721300iab.31 for ; Mon, 26 Sep 2011 06:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eywwTEHg4banOXR8tln5PV21WLmH/IiTZeygsrI2Sw4=; b=iIPH/ZqRk6r/PzIAW1+rROJiMEDvO8lBpfR1ttwhOUmru/2B0wiyLXbzVd63qK6T5N kfW8cMTguZe3dt3huCsVZYQi3WCgKG5LRwayB3XqfxQ/aZsO6Q4sG09BtsycjGn7Oq0I L+LVHeJyinRr0pv12Vi97IIgJ7Ya8k6zVi/Uk= MIME-Version: 1.0 Received: by 10.231.24.224 with SMTP id w32mr1110737ibb.75.1317044677944; Mon, 26 Sep 2011 06:44:37 -0700 (PDT) Received: by 10.231.59.206 with HTTP; Mon, 26 Sep 2011 06:44:37 -0700 (PDT) In-Reply-To: <4E55925A.90309@isi.edu> References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> <4E5570EF.4020202@isi.edu> <6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org> <4E55925A.90309@isi.edu> Date: Mon, 26 Sep 2011 09:44:37 -0400 Message-ID: From: Christopher Morrow To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:41:58 -0000 On Wed, Aug 24, 2011 at 8:07 PM, Joe Touch wrote: > > > On 8/24/2011 3:57 PM, Paul Hoffman wrote: >> >> On Aug 24, 2011, at 2:45 PM, Joe Touch wrote: >> >>> On 8/24/2011 1:27 PM, Paul Hoffman wrote: >>>> >>>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: >>>> >>>>> Is there ever a reason that this service should exist as a totally op= en >>>>> and insecure port? >>>> >>>> Given that it is explicitly listed in the draft, I find it worrisome >>>> that you even ask the question. >>>> >>>> =A0 =A0Caches and routers MUST implement unprotected transport over TC= P >>>> =A0 =A0using a port, RPKI-Rtr, to be assigned, see Section 12. =A0Oper= ators >>>> =A0 =A0SHOULD use procedural means, ACLs, ... to reduce the exposure t= o >>>> =A0 =A0authentication issues. >>> >>> I saw a declaration that this was required, but no REASON that >>> unprotected transport was necessary. >> >> Three paragraphs earlier in the document: >> >> =A0 =A0Unfortunately, >> =A0 =A0there is no protocol to do so on all currently used platforms. >> =A0 =A0Therefore, as of this document, there is no mandatory to implemen= t >> =A0 =A0transport which provides authentication and integrity protection. > > I recall that discussion, but not the assertion that this would mean that > you'd suggest using an insecure port. > > If that's the case, I strongly recommend NOT asking for a system port. > >> This was discussed heavily in the WG. >> >>>>> Also, is there a reason for not assuming that the out-of-band and >>>> >>>> in-band services cannot exist on the same port (other than performance >>>> of the connection establishment)? >>>> >>>> Those aren't enough !?!? >>> >>> "those"? I listed only one - performance. >> >> Sorry, I misread your parenthetical as "other than performance and >> connection establishment". The idea that you can do TLS on the same port >> as not-TLS has been widely debated. It was finally agreed (maybe not by >> you) that the STARTTLS method for sharing a port may or may not be >> appropriate for each protocol. When I look at this protocol, I do not >> see a way to do it without completely rewriting the protocol interaction= s. > > Here I wasn't asking about TLS vs open, I was asking about TLS vs. > IPsec/MD5/AO, and whether that has a different answer than TLS vs. open. > > Whether for this protocol or not, I would appreciate understanding that i= n > more detail - even if off-list. I cannot see how the protocol matters if = TLS > is started or not on a per-connection basis since the TLS would wrap (or > not) the data of the connect at the start. We can continue that off-list, > though. The doc in question hit version 16 on 8/13/2011... I think the authors feel that the problems/issues/discussion-points here are addressed in this version. Are we cycled down to acceptance of the language or no? The -16 version asks for a 'well-known' port, which gets to the main point of this discussion I think. (and an IANA request would still need to be made when the doc goes toward publishing) -Chris From internet-drafts@ietf.org Mon Sep 26 07:26:16 2011 Return-Path: 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 6A0A421F8D6E; Mon, 26 Sep 2011 07:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A41Fn7XYWZbS; Mon, 26 Sep 2011 07:26:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1721F8D66; Mon, 26 Sep 2011 07:26:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110926142612.2349.19253.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2011 07:26:12 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 14:26:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-14.txt Pages : 8 Date : 2011-09-26 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-14.txt From ietfc@btconnect.com Tue Sep 27 01:53:33 2011 Return-Path: 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 2D7AC21F8C4F; Tue, 27 Sep 2011 01:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlmsYoRuDpNz; Tue, 27 Sep 2011 01:53:32 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id C456621F8CBC; Tue, 27 Sep 2011 01:53:31 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2beaomr06.btconnect.com with SMTP id ESQ98406; Tue, 27 Sep 2011 09:56:00 +0100 (BST) Message-ID: <011b01cc7cea$48e59a20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" , "Joe Touch" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net><4E527D5B.2080104@isi.edu><003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net><4E554ECC.3020408@isi.edu><4E5570EF.4020202@isi.edu><6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org><4E55925A.90309@isi.edu> Date: Tue, 27 Sep 2011 09:51:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4E818F9F.00BA, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.27.74816:17:7.944, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4E818FA1.0220,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 08:53:33 -0000 Chris Joe also made the point that the Service names as currently specified have an invalid syntax in that there is a space in there, so that needs fixing, I think before an IETF LC. Tom Petch ----- Original Message ----- From: "Christopher Morrow" To: "Joe Touch" Cc: ; "Paul Hoffman" ; Sent: Monday, September 26, 2011 3:44 PM Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? On Wed, Aug 24, 2011 at 8:07 PM, Joe Touch wrote: > > > On 8/24/2011 3:57 PM, Paul Hoffman wrote: >> >> On Aug 24, 2011, at 2:45 PM, Joe Touch wrote: >> >>> On 8/24/2011 1:27 PM, Paul Hoffman wrote: >>>> >>>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: >>>> >>>>> Is there ever a reason that this service should exist as a totally open >>>>> and insecure port? >>>> >>>> Given that it is explicitly listed in the draft, I find it worrisome >>>> that you even ask the question. >>>> >>>> Caches and routers MUST implement unprotected transport over TCP >>>> using a port, RPKI-Rtr, to be assigned, see Section 12. Operators >>>> SHOULD use procedural means, ACLs, ... to reduce the exposure to >>>> authentication issues. >>> >>> I saw a declaration that this was required, but no REASON that >>> unprotected transport was necessary. >> >> Three paragraphs earlier in the document: >> >> Unfortunately, >> there is no protocol to do so on all currently used platforms. >> Therefore, as of this document, there is no mandatory to implement >> transport which provides authentication and integrity protection. > > I recall that discussion, but not the assertion that this would mean that > you'd suggest using an insecure port. > > If that's the case, I strongly recommend NOT asking for a system port. > >> This was discussed heavily in the WG. >> >>>>> Also, is there a reason for not assuming that the out-of-band and >>>> >>>> in-band services cannot exist on the same port (other than performance >>>> of the connection establishment)? >>>> >>>> Those aren't enough !?!? >>> >>> "those"? I listed only one - performance. >> >> Sorry, I misread your parenthetical as "other than performance and >> connection establishment". The idea that you can do TLS on the same port >> as not-TLS has been widely debated. It was finally agreed (maybe not by >> you) that the STARTTLS method for sharing a port may or may not be >> appropriate for each protocol. When I look at this protocol, I do not >> see a way to do it without completely rewriting the protocol interactions. > > Here I wasn't asking about TLS vs open, I was asking about TLS vs. > IPsec/MD5/AO, and whether that has a different answer than TLS vs. open. > > Whether for this protocol or not, I would appreciate understanding that in > more detail - even if off-list. I cannot see how the protocol matters if TLS > is started or not on a per-connection basis since the TLS would wrap (or > not) the data of the connect at the start. We can continue that off-list, > though. The doc in question hit version 16 on 8/13/2011... I think the authors feel that the problems/issues/discussion-points here are addressed in this version. Are we cycled down to acceptance of the language or no? The -16 version asks for a 'well-known' port, which gets to the main point of this discussion I think. (and an IANA request would still need to be made when the doc goes toward publishing) -Chris _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Tue Sep 27 05:45:28 2011 Return-Path: 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 24DEF21F8C95 for ; Tue, 27 Sep 2011 05:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ASk67Bd5eY2 for ; Tue, 27 Sep 2011 05:45:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C6FD621F8C98 for ; Tue, 27 Sep 2011 05:45:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R8X51-000Fsh-Fw; Tue, 27 Sep 2011 12:48:11 +0000 Date: Tue, 27 Sep 2011 05:48:10 -0700 Message-ID: From: Randy Bush To: Tom Petch In-Reply-To: <011b01cc7cea$48e59a20$4001a8c0@gateway.2wire.net> References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> <4E5570EF.4020202@isi.edu> <6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org> <4E55925A.90309@isi.edu> <011b01cc7cea$48e59a20$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 12:45:28 -0000 > Joe also made the point that the Service names as currently specified > have an invalid syntax in that there is a space in there, so that > needs fixing, I think before an IETF LC. a bit early and no coffee yet in this uncivilized culture. could you please point out where and what names? randy From ietfc@btconnect.com Tue Sep 27 08:16:38 2011 Return-Path: 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 0A4B221F8E25; Tue, 27 Sep 2011 08:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwdWv7+iRvBj; Tue, 27 Sep 2011 08:16:37 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 695C621F8DFF; Tue, 27 Sep 2011 08:16:35 -0700 (PDT) Received: from host86-163-147-122.range86-163.btcentralplus.com (HELO pc6) ([86.163.147.122]) by c2bthomr10.btconnect.com with SMTP id EOZ84937; Tue, 27 Sep 2011 16:19:18 +0100 (BST) Message-ID: <046801cc7d1f$d52483e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net><4E527D5B.2080104@isi.edu><003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net><4E554ECC.3020408@isi.edu><4E5570EF.4020202@isi.edu><6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org><4E55925A.90309@isi.edu> <011b01cc7cea$48e59a20$4001a8c0@gateway.2wire.net> Date: Tue, 27 Sep 2011 15:20:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4E81E975.0100, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.9.27.143015:17:7.944, ip=86.163.147.122, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS, MULTIPLE_RCPTS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4E81E976.012F,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:16:38 -0000 Chris I have just been reminded of another potential spanner in the works. TLS uses certificates but what they contain and how that information is used varies widely. Earlier this year, we got RFC6125 (not sure what we did to deserve it) which lays down rules on how to check a server certificate, such as pouring cold water on the use of CN, which s7.2 of this I-D mandates. In general, 'x over TLS' I-D and RFC go into a lot more detail than this I-D does. Pessimist that I am, born of bitter encounters with security paragons, I would expect some push back in this area. Is this something to bounce off a relevant party, such as a member of secdir, as you did with MD5 et al? I am looking at s7.2 and thinking that it will be found wanting, compared to, say, RFC5539 s.3. Tom Petch ----- Original Message ----- From: "t.petch" To: "Christopher Morrow" ; "Joe Touch" Cc: ; Sent: Tuesday, September 27, 2011 9:51 AM Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > Chris > > Joe also made the point that the Service names as currently specified have an > invalid syntax in that there is a space in there, so that needs fixing, I think > before an IETF LC. > > Tom Petch > > > ----- Original Message ----- > From: "Christopher Morrow" > To: "Joe Touch" > Cc: ; "Paul Hoffman" ; > > Sent: Monday, September 26, 2011 3:44 PM > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > On Wed, Aug 24, 2011 at 8:07 PM, Joe Touch wrote: > > > > > > On 8/24/2011 3:57 PM, Paul Hoffman wrote: > >> > >> On Aug 24, 2011, at 2:45 PM, Joe Touch wrote: > >> > >>> On 8/24/2011 1:27 PM, Paul Hoffman wrote: > >>>> > >>>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: > >>>> > >>>>> Is there ever a reason that this service should exist as a totally open > >>>>> and insecure port? > >>>> > >>>> Given that it is explicitly listed in the draft, I find it worrisome > >>>> that you even ask the question. > >>>> > >>>> Caches and routers MUST implement unprotected transport over TCP > >>>> using a port, RPKI-Rtr, to be assigned, see Section 12. Operators > >>>> SHOULD use procedural means, ACLs, ... to reduce the exposure to > >>>> authentication issues. > >>> > >>> I saw a declaration that this was required, but no REASON that > >>> unprotected transport was necessary. > >> > >> Three paragraphs earlier in the document: > >> > >> Unfortunately, > >> there is no protocol to do so on all currently used platforms. > >> Therefore, as of this document, there is no mandatory to implement > >> transport which provides authentication and integrity protection. > > > > I recall that discussion, but not the assertion that this would mean that > > you'd suggest using an insecure port. > > > > If that's the case, I strongly recommend NOT asking for a system port. > > > >> This was discussed heavily in the WG. > >> > >>>>> Also, is there a reason for not assuming that the out-of-band and > >>>> > >>>> in-band services cannot exist on the same port (other than performance > >>>> of the connection establishment)? > >>>> > >>>> Those aren't enough !?!? > >>> > >>> "those"? I listed only one - performance. > >> > >> Sorry, I misread your parenthetical as "other than performance and > >> connection establishment". The idea that you can do TLS on the same port > >> as not-TLS has been widely debated. It was finally agreed (maybe not by > >> you) that the STARTTLS method for sharing a port may or may not be > >> appropriate for each protocol. When I look at this protocol, I do not > >> see a way to do it without completely rewriting the protocol interactions. > > > > Here I wasn't asking about TLS vs open, I was asking about TLS vs. > > IPsec/MD5/AO, and whether that has a different answer than TLS vs. open. > > > > Whether for this protocol or not, I would appreciate understanding that in > > more detail - even if off-list. I cannot see how the protocol matters if TLS > > is started or not on a per-connection basis since the TLS would wrap (or > > not) the data of the connect at the start. We can continue that off-list, > > though. > > The doc in question hit version 16 on 8/13/2011... I think the authors > feel that the problems/issues/discussion-points here are addressed in > this version. Are we cycled down to acceptance of the language or no? > The -16 version asks for a 'well-known' port, which gets to the main > point of this discussion I think. > > (and an IANA request would still need to be made when the doc goes > toward publishing) > > -Chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From touch@isi.edu Tue Sep 27 14:51:42 2011 Return-Path: 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 4ADE721F8EB9; Tue, 27 Sep 2011 14:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCkDd7CzHVee; Tue, 27 Sep 2011 14:51:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A5B8E21F8EAC; Tue, 27 Sep 2011 14:51:41 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p8RLrXcS022869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Sep 2011 14:53:34 -0700 (PDT) Message-ID: <4E8245DD.6050800@isi.edu> Date: Tue, 27 Sep 2011 14:53:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "t.petch" References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net><4E527D5B.2080104@isi.edu><003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net><4E554ECC.3020408@isi.edu><4E5570EF.4020202@isi.edu><6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org><4E55925A.90309@isi.edu> <011b01cc7cea$48e59a20$4001a8c0@gateway.2wire.net> In-Reply-To: <011b01cc7cea$48e59a20$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Christopher Morrow , sidr-chairs@ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 21:51:42 -0000 Right - for those on this list: -16 says: This document requests the IANA to assign 'well known' TCP Port Numbers to the RPKI-Router Protocol for the following, see Section 7: RPKI-Rtr RPKI-Rtr TLS It should say: This document requests the IANA to assign 'well known' TCP Port Numbers to the RPKI-Router Protocol for the following, see Section 7: RPKI-Rtr TCP RPKI-Rtr-s TCP (with corresponding changes to section 7). Joe On 9/27/2011 12:51 AM, t.petch wrote: > Chris > > Joe also made the point that the Service names as currently specified have an > invalid syntax in that there is a space in there, so that needs fixing, I think > before an IETF LC. > > Tom Petch > > > ----- Original Message ----- > From: "Christopher Morrow" > To: "Joe Touch" > Cc:; "Paul Hoffman"; > > Sent: Monday, September 26, 2011 3:44 PM > Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? > > > On Wed, Aug 24, 2011 at 8:07 PM, Joe Touch wrote: >> >> >> On 8/24/2011 3:57 PM, Paul Hoffman wrote: >>> >>> On Aug 24, 2011, at 2:45 PM, Joe Touch wrote: >>> >>>> On 8/24/2011 1:27 PM, Paul Hoffman wrote: >>>>> >>>>> On Aug 24, 2011, at 12:19 PM, Joe Touch wrote: >>>>> >>>>>> Is there ever a reason that this service should exist as a totally open >>>>>> and insecure port? >>>>> >>>>> Given that it is explicitly listed in the draft, I find it worrisome >>>>> that you even ask the question. >>>>> >>>>> Caches and routers MUST implement unprotected transport over TCP >>>>> using a port, RPKI-Rtr, to be assigned, see Section 12. Operators >>>>> SHOULD use procedural means, ACLs, ... to reduce the exposure to >>>>> authentication issues. >>>> >>>> I saw a declaration that this was required, but no REASON that >>>> unprotected transport was necessary. >>> >>> Three paragraphs earlier in the document: >>> >>> Unfortunately, >>> there is no protocol to do so on all currently used platforms. >>> Therefore, as of this document, there is no mandatory to implement >>> transport which provides authentication and integrity protection. >> >> I recall that discussion, but not the assertion that this would mean that >> you'd suggest using an insecure port. >> >> If that's the case, I strongly recommend NOT asking for a system port. >> >>> This was discussed heavily in the WG. >>> >>>>>> Also, is there a reason for not assuming that the out-of-band and >>>>> >>>>> in-band services cannot exist on the same port (other than performance >>>>> of the connection establishment)? >>>>> >>>>> Those aren't enough !?!? >>>> >>>> "those"? I listed only one - performance. >>> >>> Sorry, I misread your parenthetical as "other than performance and >>> connection establishment". The idea that you can do TLS on the same port >>> as not-TLS has been widely debated. It was finally agreed (maybe not by >>> you) that the STARTTLS method for sharing a port may or may not be >>> appropriate for each protocol. When I look at this protocol, I do not >>> see a way to do it without completely rewriting the protocol interactions. >> >> Here I wasn't asking about TLS vs open, I was asking about TLS vs. >> IPsec/MD5/AO, and whether that has a different answer than TLS vs. open. >> >> Whether for this protocol or not, I would appreciate understanding that in >> more detail - even if off-list. I cannot see how the protocol matters if TLS >> is started or not on a per-connection basis since the TLS would wrap (or >> not) the data of the connect at the start. We can continue that off-list, >> though. > > The doc in question hit version 16 on 8/13/2011... I think the authors > feel that the problems/issues/discussion-points here are addressed in > this version. Are we cycled down to acceptance of the language or no? > The -16 version asks for a 'well-known' port, which gets to the main > point of this discussion I think. > > (and an IANA request would still need to be made when the doc goes > toward publishing) > > -Chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From touch@isi.edu Tue Sep 27 16:53:20 2011 Return-Path: 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 0311021F8EE1; Tue, 27 Sep 2011 16:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.198 X-Spam-Level: X-Spam-Status: No, score=-105.198 tagged_above=-999 required=5 tests=[AWL=1.401, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkFV5EgvlmAu; Tue, 27 Sep 2011 16:53:19 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8021F8EDC; Tue, 27 Sep 2011 16:53:19 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p8RNtTlF008883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Sep 2011 16:55:29 -0700 (PDT) Message-ID: <4E826271.9020700@isi.edu> Date: Tue, 27 Sep 2011 16:55:29 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <001801cc60bb$19329d00$4001a8c0@gateway.2wire.net> <4E527D5B.2080104@isi.edu> <003f01cc626f$4d2d2d40$4001a8c0@gateway.2wire.net> <4E554ECC.3020408@isi.edu> <4E5570EF.4020202@isi.edu> <6E68CE6B-920E-4A4C-AEB4-1E775C702284@vpnc.org> <4E55925A.90309@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr-chairs@ietf.org, Paul Hoffman , sidr@ietf.org Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 23:53:20 -0000 Hi, Christopher (et al.), On 9/26/2011 6:44 AM, Christopher Morrow wrote: > On Wed, Aug 24, 2011 at 8:07 PM, Joe Touch wrote: ... > The doc in question hit version 16 on 8/13/2011... I think the authors > feel that the problems/issues/discussion-points here are addressed in > this version. Are we cycled down to acceptance of the language or no? > The -16 version asks for a 'well-known' port, which gets to the main > point of this discussion I think. I would expect that it would NOT be a 'well-known' port, but a 'registered' port, given that security is optional. If security is required - just in a variety of forms - then I would expect that the text would need to be reworded. > (and an IANA request would still need to be made when the doc goes > toward publishing) That happens automatically as part of the processing of the IANA Considerations section, FWIW. Joe From randy@psg.com Thu Sep 29 19:36:30 2011 Return-Path: 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 668CB21F8ECA for ; Thu, 29 Sep 2011 19:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeA9+cA23MKn for ; Thu, 29 Sep 2011 19:36:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7421F8EC9 for ; Thu, 29 Sep 2011 19:36:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9T0T-0000ZA-SL for sidr@ietf.org; Fri, 30 Sep 2011 02:39:22 +0000 Date: Fri, 30 Sep 2011 11:39:21 +0900 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 02:36:30 -0000 there has been a bit of confusion over whether announcement of a longer prefix than is covered by a roa is valid, invalid, or not found. so let me try to clarify the underlying decision process for valid, invalid, and not found so we are all on the same page. i believe this is as it is documented in pfx-validate. --- if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other roas for 10/...) no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS may be marked NOT FOUND, after all, a covering roa is there. any announcement of any prefixes in that space, from /16 to /32, from an AS other than 42 are INVALID. this is the purpose of the exercise. and, an announcement of 10.0.666.0/24 from AS 42 is INVALID, as it has a prefix length not specified by the roa. someone is trying to punch a hole, not allowed. this could be an origin forger trying to punch a /24 in my /16. but if i publish a roa for 10.0.0.0/16-24 for AS 42, then an announcement for 10.0.666.0/24 from AS 42, would be marked VALID. randy From pmohapat@cisco.com Thu Sep 29 20:11:52 2011 Return-Path: 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 3353321F8B3A for ; Thu, 29 Sep 2011 20:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QCHBqp-WHS6 for ; Thu, 29 Sep 2011 20:11:51 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 93E5C21F8B39 for ; Thu, 29 Sep 2011 20:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1624; q=dns/txt; s=iport; t=1317352484; x=1318562084; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XE9Kp8jA9ddCulhaMGrTZBH9JskICIZ4LM47nVWr6qs=; b=aLkURLHZWY+rSfuCU9lL+MLKEzMch6oaOPZncKDzsxNCFlTUcz6quAM1 1HAl0KWXfOrvA4EDgV8JS3mnGgE0fih7DaGcYYPxbvzoBn1p4tlweo/n+ Coa77XWzLpd/tITTf5rBIO8nj764yz7aNJ+GZMR5fZU9KIjgy/moQAJA+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACgzhU6rRDoI/2dsb2JhbABBqB53gVMBAQEBAgEBAQEPASc0CwULC0YnMAYTIodYBppjAZ4zA4Y9YQSHdYtlhSSMNw X-IronPort-AV: E=Sophos;i="4.68,464,1312156800"; d="scan'208";a="5143987" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 30 Sep 2011 03:14:44 +0000 Received: from [10.21.118.111] ([10.21.118.111]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8U3EhTe006076; Fri, 30 Sep 2011 03:14:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: Date: Thu, 29 Sep 2011 20:21:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 03:11:52 -0000 > there has been a bit of confusion over whether announcement of a = longer > prefix than is covered by a roa is valid, invalid, or not found. so = let > me try to clarify the underlying decision process for valid, invalid, > and not found so we are all on the same page. i believe this is as it > is documented in pfx-validate. I concur. =46rom a partial deployment perspective, it does mean that once a ROA is=20= published for an address block (and follows the ops guideline of being = precise),=20 further sub-allocations NEED to have the ROA published. Otherwise, they would be marked invalid and risk being not routed. - Pradosh >=20 > --- >=20 > if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no = other > roas for 10/...) >=20 > no announcement of 10.0.0.0/16 or any longer prefix thereof from any = AS > may be marked NOT FOUND, after all, a covering roa is there. >=20 > any announcement of any prefixes in that space, from /16 to /32, from = an > AS other than 42 are INVALID. this is the purpose of the exercise. >=20 > and, an announcement of 10.0.666.0/24 from AS 42 is INVALID, as it has = a > prefix length not specified by the roa. someone is trying to punch a > hole, not allowed. this could be an origin forger trying to punch a = /24 > in my /16. >=20 > but if i publish a roa for 10.0.0.0/16-24 for AS 42, then an > announcement for 10.0.666.0/24 from AS 42, would be marked VALID. >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Thu Sep 29 20:19:35 2011 Return-Path: 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 8A0D821F8DB7 for ; Thu, 29 Sep 2011 20:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvbM0E7hz4I6 for ; Thu, 29 Sep 2011 20:19:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8C521F8DA2 for ; Thu, 29 Sep 2011 20:19:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9Tg7-0000gH-Il; Fri, 30 Sep 2011 03:22:23 +0000 Date: Fri, 30 Sep 2011 12:22:22 +0900 Message-ID: From: Randy Bush To: Pradosh Mohapatra In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 03:19:35 -0000 > From a partial deployment perspective, it does mean that once a ROA is > published for an address block (and follows the ops guideline of being > precise), further sub-allocations NEED to have the ROA > published. Otherwise, they would be marked invalid and risk being not > routed. from draft-ietf-sidr-origin-ops-10 Before issuing a ROA for a super-block, an operator MUST ensure that any sub-allocations from that block which are announced by other ASs, e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a ROA for the super-block will cause the announcements of sub- allocations with no ROAs to be viewed as Invalid, see [I-D.ietf-sidr-pfx-validate]. randy From robert@raszuk.net Fri Sep 30 00:57:05 2011 Return-Path: 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 045BC21F84DF for ; Fri, 30 Sep 2011 00:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN3z2D0MhVW9 for ; Fri, 30 Sep 2011 00:57:04 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by ietfa.amsl.com (Postfix) with SMTP id 47C4321F84DD for ; Fri, 30 Sep 2011 00:57:03 -0700 (PDT) Received: (qmail 6051 invoked by uid 399); 30 Sep 2011 07:59:54 -0000 Received: from unknown (HELO ?216.69.73.174?) (216.69.73.174) by mail37.opentransfer.com with SMTP; 30 Sep 2011 07:59:54 -0000 Message-ID: <4E8576FA.5020107@raszuk.net> Date: Fri, 30 Sep 2011 09:59:54 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Randy Bush , Pradosh Mohapatra References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 07:57:05 -0000 Let me clarify one nit ... In the other mail you said: "any announcement of any prefixes in that space, from /16 to /32, from an AS other than 42 are INVALID." In the light of the below quote from origin-ops-10 should the above be reworded as: "any announcement of any prefixes in that space, from /16 to /32, from an AS other than 42 are INVALID unless a valid ROA is present in the RPKI covering such sub-allocation" Thx, R. >> From a partial deployment perspective, it does mean that once a ROA is >> published for an address block (and follows the ops guideline of being >> precise), further sub-allocations NEED to have the ROA >> published. Otherwise, they would be marked invalid and risk being not >> routed. > > from draft-ietf-sidr-origin-ops-10 > > Before issuing a ROA for a super-block, an operator MUST ensure that > any sub-allocations from that block which are announced by other ASs, > e.g. customers, have correct ROAs in the RPKI. Otherwise, issuing a > ROA for the super-block will cause the announcements of sub- > allocations with no ROAs to be viewed as Invalid, see > [I-D.ietf-sidr-pfx-validate]. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From randy@psg.com Fri Sep 30 01:00:18 2011 Return-Path: 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 756BC21F8BEF for ; Fri, 30 Sep 2011 01:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kua6qjPT0B04 for ; Fri, 30 Sep 2011 01:00:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 149A621F84E5 for ; Fri, 30 Sep 2011 01:00:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9Y3q-0001FB-M2; Fri, 30 Sep 2011 08:03:11 +0000 Date: Fri, 30 Sep 2011 17:03:09 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4E8576FA.5020107@raszuk.net> References: <4E8576FA.5020107@raszuk.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 08:00:18 -0000 > Let me clarify one nit ... > > In the other mail you said: > > "any announcement of any prefixes in that space, from /16 to /32, from > an AS other than 42 are INVALID." > > In the light of the below quote from origin-ops-10 should the above be > reworded as: > > "any announcement of any prefixes in that space, from /16 to /32, from > an AS other than 42 are INVALID unless a valid ROA is present in the > RPKI covering such sub-allocation" perhaps you missed the start of the discussion >> if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no >> other roas for 10/...) randy From hannes@juniper.net Fri Sep 30 03:16:45 2011 Return-Path: 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 8C43221F8B7F for ; Fri, 30 Sep 2011 03:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1kyi0JD94Tt for ; Fri, 30 Sep 2011 03:16:45 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id D7CC821F8B73 for ; Fri, 30 Sep 2011 03:16:44 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKToWXuMRY0MCvmkrypaOF6GM2CLUj8ziE@postini.com; Fri, 30 Sep 2011 03:19:38 PDT Received: from hannes-755.juniper.net (172.23.4.253) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.83.0; Fri, 30 Sep 2011 03:17:56 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 6CB74263CC; Fri, 30 Sep 2011 12:17:55 +0200 (CEST) Date: Fri, 30 Sep 2011 12:17:55 +0200 From: Hannes Gredler To: Randy Bush Message-ID: <20110930101754.GB10004@juniper.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 10:16:45 -0000 On Fri, Sep 30, 2011 at 11:39:21AM +0900, Randy Bush wrote: | if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other | roas for 10/...) | | no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS | may be marked NOT FOUND, after all, a covering roa is there. | | any announcement of any prefixes in that space, from /16 to /32, from an | AS other than 42 are INVALID. this is the purpose of the exercise. i have a question then: what is the conceptual difference between 10.0.0.0/16-16 and 10.0.0.0/16-32 following the logic above ? my read of 10.0.0.0/16-16 is an exact match and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy terms ;-)) From randy@psg.com Fri Sep 30 03:31:35 2011 Return-Path: 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 6580021F8B1F for ; Fri, 30 Sep 2011 03:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STlnShwCq-kq for ; Fri, 30 Sep 2011 03:31:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8A221F8B1E for ; Fri, 30 Sep 2011 03:31:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9aQF-0001a8-AN; Fri, 30 Sep 2011 10:34:27 +0000 Date: Fri, 30 Sep 2011 19:34:26 +0900 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110930101754.GB10004@juniper.net> References: <20110930101754.GB10004@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 10:31:35 -0000 > my read of 10.0.0.0/16-16 is an exact match > and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy > terms ;-)) yes. fwiw, i do not remember junos as having a policy term to express 10.0.0.0/16-14 :) randy From hannes@juniper.net Fri Sep 30 05:26:15 2011 Return-Path: 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 A029B21F8B57 for ; Fri, 30 Sep 2011 05:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj5WgW4LDsB3 for ; Fri, 30 Sep 2011 05:26:15 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id BEAC921F8B56 for ; Fri, 30 Sep 2011 05:26:14 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKToW2EoOyIqYeF8riLK0Dfi7RZWVUvG5L@postini.com; Fri, 30 Sep 2011 05:29:08 PDT Received: from hannes-755.juniper.net (172.23.4.253) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.83.0; Fri, 30 Sep 2011 05:28:34 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 2EFBA238F9; Fri, 30 Sep 2011 14:28:33 +0200 (CEST) Date: Fri, 30 Sep 2011 14:28:33 +0200 From: Hannes Gredler To: Randy Bush Message-ID: <20110930122831.GA10176@juniper.net> References: <20110930101754.GB10004@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 12:26:15 -0000 On Fri, Sep 30, 2011 at 07:34:26PM +0900, Randy Bush wrote: | > my read of 10.0.0.0/16-16 is an exact match | > and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy | > terms ;-)) | | yes. so why is it (per your previous example) 'invalid' then - since a exact match was requested and no exact match could be found it should be 'not found'. - if one wanted to match against the whole subtree then 10.0.0.0/16-32 shall be advertised and signed; | fwiw, i do not remember junos as having a policy term to express | 10.0.0.0/16-14 :) have a look at 'prefix-length-range' policy qualifier. http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/defining-route-lists.html e.g. route-filter 10.0.0.0/14 prefix-length-range /14-/16 From randy@psg.com Fri Sep 30 07:32:27 2011 Return-Path: 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 C68BE21F8B3E for ; Fri, 30 Sep 2011 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW1O0k9n+fV8 for ; Fri, 30 Sep 2011 07:32:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28721F8B24 for ; Fri, 30 Sep 2011 07:32:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9eBL-00027c-FS; Fri, 30 Sep 2011 14:35:19 +0000 Date: Fri, 30 Sep 2011 23:35:18 +0900 Message-ID: From: Randy Bush To: Hannes Gredler In-Reply-To: <20110930122831.GA10176@juniper.net> References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 14:32:27 -0000 >>> my read of 10.0.0.0/16-16 is an exact match >>> and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy >>> terms ;-)) >> yes. > so why is it (per your previous example) 'invalid' then - > since a exact match was requested and no exact match could be found > it should be 'not found'. because we call it an attack. see all the specs. > if one wanted to match against the whole subtree then 10.0.0.0/16-32 > shall be advertised and signed; almost the opposite. >> fwiw, i do not remember junos as having a policy term to express >> 10.0.0.0/16-14 :) > e.g. route-filter 10.0.0.0/14 prefix-length-range /14-/16 cool randy From jakob.heitz@ericsson.com Fri Sep 30 09:06:34 2011 Return-Path: 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 9EC2B21F8CC7 for ; Fri, 30 Sep 2011 09:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABoFnuACmma5 for ; Fri, 30 Sep 2011 09:06:33 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A2D8921F8CC3 for ; Fri, 30 Sep 2011 09:06:33 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8UG9PZf006202; Fri, 30 Sep 2011 11:09:27 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 30 Sep 2011 12:09:21 -0400 From: Jakob Heitz To: "sidr@ietf.org" Date: Fri, 30 Sep 2011 12:09:58 -0400 Thread-Topic: [sidr] is a longer announce invalid or not found? Thread-Index: Acx/i0/tdR6njPo2RtOcGByQmvH/1g== Message-ID: <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 16:06:34 -0000 An attacker could announce 10.0.0.0/17 and 10.0.128.0/17. This is equivalent to announcing 10.0.0.0/16, so it must be INVALID. 10.0.0.0/16-16 means I can announce 10.0.0.0/16, but not 10.0.66.0/24. I wo= uld do this if I have sub-allocated 10.0.66.0/24 to my customer. My custome= r MUST publish an ROA for 10.0.66.0/24. If my customer does not support SIDR, then I MUST revoke my ROA for 10.0.0.= 0/16-16 and replace it with ROAs for 10.0.0.0/18-18 10.0.64.0/23-23 10.0.67.0/24-24 10.0.68.0/22-22 10.0.72.0/21-21 10.0.80.0/20-20 10.0.96.0/19-19 10.0.128.0/17-17 As I sub-allocate more, I must split it more. However, I could sub-allocate 10.0.666.0/24 to Randy and need split nothing= :) -- Jakob Heitz. On Sep 30, 2011, at 7:35 AM, "Randy Bush" wrote: >>>> my read of 10.0.0.0/16-16 is an exact match >>>> and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy >>>> terms ;-)) >>> yes. >> so why is it (per your previous example) 'invalid' then - >> since a exact match was requested and no exact match could be found >> it should be 'not found'. >=20 > because we call it an attack. see all the specs. >=20 >> if one wanted to match against the whole subtree then 10.0.0.0/16-32 >> shall be advertised and signed; >=20 > almost the opposite. >=20 >>> fwiw, i do not remember junos as having a policy term to express >>> 10.0.0.0/16-14 :) >> e.g. route-filter 10.0.0.0/14 prefix-length-range /14-/16 >=20 > cool >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Fri Sep 30 13:21:04 2011 Return-Path: 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 132B721F8C57 for ; Fri, 30 Sep 2011 13:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gpImMA13fKy for ; Fri, 30 Sep 2011 13:21:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC221F8B81 for ; Fri, 30 Sep 2011 13:21:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9jch-00030r-8C; Fri, 30 Sep 2011 20:23:55 +0000 Date: Sat, 01 Oct 2011 05:23:54 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:21:04 -0000 > If my customer does not support SIDR then create the subsidiary cert, ee cert, and roa for them. you will then have two certs, 10.0.0.0/16-16 10.0.66.0/24-24 i call this the lazy customer. they probably pay me to one or more of provision the circuit, configure their cpe, ... i might as well provision their certs and roa. randy From jakob.heitz@ericsson.com Fri Sep 30 13:29:34 2011 Return-Path: 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 A786921F8C45 for ; Fri, 30 Sep 2011 13:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESI6Qvl1DNpn for ; Fri, 30 Sep 2011 13:29:33 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BBFA221F8C33 for ; Fri, 30 Sep 2011 13:29:33 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8UKWOrB029552; Fri, 30 Sep 2011 15:32:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 30 Sep 2011 16:32:22 -0400 From: Jakob Heitz To: Randy Bush Date: Fri, 30 Sep 2011 16:32:20 -0400 Thread-Topic: [sidr] is a longer announce invalid or not found? Thread-Index: Acx/ruTTLhwHhBoiSKSTUAtO0oJ5/wAAOk8g Message-ID: <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:29:34 -0000 On Friday, September 30, 2011 1:24 PM, Randy Bush wr= ote: >> If my customer does not support SIDR >=20 > then create the subsidiary cert, ee cert, and roa for them. you will > then have two certs, > 10.0.0.0/16-16 > 10.0.66.0/24-24 >=20 > i call this the lazy customer. they probably pay me to one or more of > provision the circuit, configure their cpe, ... i might as well > provision their certs and roa. Will you sign his announcement too? If he doesn't implement sidr on all his routers yet, he will not sign his announcements. --=20 Jakob Heitz.= From randy@psg.com Fri Sep 30 13:37:59 2011 Return-Path: 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 E23F821F8BAD for ; Fri, 30 Sep 2011 13:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWyxO3xz+jd3 for ; Fri, 30 Sep 2011 13:37:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 76B3221F8BAA for ; Fri, 30 Sep 2011 13:37:59 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9jt8-00033n-0B; Fri, 30 Sep 2011 20:40:54 +0000 Date: Sat, 01 Oct 2011 05:40:53 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:38:00 -0000 >> then create the subsidiary cert, ee cert, and roa for them. you will >> then have two certs, >> 10.0.0.0/16-16 >> 10.0.66.0/24-24 >> >> i call this the lazy customer. they probably pay me to one or more of >> provision the circuit, configure their cpe, ... i might as well >> provision their certs and roa. > > Will you sign his announcement too? no, because we are talking origin validation, not bgpsec > If he doesn't implement sidr on all his routers yet, he will not sign > his announcements. first, 'sidr' is highly ambiguous. sidr is documenting three main technologies, rpki, rpki-based origin validation, and bgpsec. we were discussing the first two. second, origin validation and bgpsec can be partially deployed within an operator. this is one of the reasons they are blended into local policy, and do not force policy upon the operator. third, a (let's assume dual homed) leaf site does not have to do much for bgpsec. their upstreams validate, so they do not have to. all they have to do is sign their announcement. we refer to this as a 'simplex' site, they announce signed but do not accept signed data, do not hold any key or cert other than their own, ... cool result is that current leaf site hardware could do this, no upgrade. so, for my simplex lazy customer, yes i gen the bgpsec router key for them, and they or i stuff it in their router. randy From Sandra.Murphy@cobham.com Fri Sep 30 13:38:41 2011 Return-Path: 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 7F8AA21F8BAD for ; Fri, 30 Sep 2011 13:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQkbz-HITzBb for ; Fri, 30 Sep 2011 13:38:40 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 861DD21F8888 for ; Fri, 30 Sep 2011 13:38:40 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p8UKfV1T010850; Fri, 30 Sep 2011 15:41:32 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p8UKfWd3022321; Fri, 30 Sep 2011 15:41:32 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.164]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Sep 2011 16:41:31 -0400 Date: Fri, 30 Sep 2011 16:41:31 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> Message-ID: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 30 Sep 2011 20:41:31.0129 (UTC) FILETIME=[55BCFE90:01CC7FB1] Cc: "sidr@ietf.org" Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:38:41 -0000 Speaking as regular ol' member On Fri, 30 Sep 2011, Jakob Heitz wrote: > On Friday, September 30, 2011 1:24 PM, Randy Bush wrote: > >>> If my customer does not support SIDR >> >> then create the subsidiary cert, ee cert, and roa for them. you will >> then have two certs, >> 10.0.0.0/16-16 >> 10.0.66.0/24-24 >> >> i call this the lazy customer. they probably pay me to one or more of >> provision the circuit, configure their cpe, ... i might as well >> provision their certs and roa. > > Will you sign his announcement too? > If he doesn't implement sidr on all his routers yet, > he will not sign his announcements. > In origin authorization phase, no signing of announcements is done. In path validation phase (bgpsec), you are creating his ROAs - so make yourself the valid origin - and then yes, sign the originating (your) announcement. Or if you create the cert, then you hold the key, so yes, you could sign his announcement. (Holding the keys gives you ultimate power.) --Sandy, speaking as regular ol' member > -- > Jakob Heitz. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Fri Sep 30 13:46:38 2011 Return-Path: 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 23B9821F8A58 for ; Fri, 30 Sep 2011 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2gs-mDjRxAT for ; Fri, 30 Sep 2011 13:46:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B75C021F8A55 for ; Fri, 30 Sep 2011 13:46:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9k1U-00035c-Gc; Fri, 30 Sep 2011 20:49:32 +0000 Date: Sat, 01 Oct 2011 05:49:31 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:46:38 -0000 > a (let's assume dual homed) leaf site does not have to do much for > bgpsec. their upstreams validate, so they do not have to. all they > have to do is sign their announcement. we refer to this as a > 'simplex' site, they announce signed but do not accept signed data, do > not hold any key or cert other than their own, ... cool result is > that current leaf site hardware could do this, no upgrade. so, for my > simplex lazy customer, yes i gen the bgpsec router key for them, and > they or i stuff it in their router. < side discussion > cool hack 14.3: the router itself can gen the public/private key pair a la ssh, the person configuring can extract the public key and send it to the rpki goddesses to be signed by the appropriate cert and put in the rpki. the private key never leaves the router! randy From Sandra.Murphy@cobham.com Fri Sep 30 13:53:18 2011 Return-Path: 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 2A0D421F8AAA for ; Fri, 30 Sep 2011 13:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.211 X-Spam-Level: X-Spam-Status: No, score=-102.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRR-WWBZiN8t for ; Fri, 30 Sep 2011 13:53:17 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 659EE21F8AA9 for ; Fri, 30 Sep 2011 13:53:17 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p8UKu4Uo010950; Fri, 30 Sep 2011 15:56:04 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p8UKu2UW022672; Fri, 30 Sep 2011 15:56:04 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.164]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Sep 2011 16:56:01 -0400 Date: Fri, 30 Sep 2011 16:56:01 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 30 Sep 2011 20:56:01.0961 (UTC) FILETIME=[5CCB6990:01CC7FB3] Cc: "sidr@ietf.org" Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:53:18 -0000 Speaking as regular ol' member On Sat, 1 Oct 2011, Randy Bush wrote: >> a (let's assume dual homed) leaf site does not have to do much for >> bgpsec. their upstreams validate, so they do not have to. all they >> have to do is sign their announcement. we refer to this as a >> 'simplex' site, they announce signed but do not accept signed data, do >> not hold any key or cert other than their own, ... cool result is >> that current leaf site hardware could do this, no upgrade. so, for my >> simplex lazy customer, yes i gen the bgpsec router key for them, and >> they or i stuff it in their router. > > < side discussion > > > cool hack 14.3: the router itself can gen the public/private key pair a > la ssh, the person configuring can extract the public key and send it to > the rpki goddesses to be signed by the appropriate cert and put in the > rpki. the private key never leaves the router! I believe that Steve Kent says that usually a certificate request is required to present Proof Of Possession (of the private key). So just discovering the public key somehow would not be sufficient to be able to request a cert with that public key. I await correction in quoting Steve. --Sandy, speaking as regular ol' member > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Fri Sep 30 13:56:23 2011 Return-Path: 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 E98CA21F8ABB for ; Fri, 30 Sep 2011 13:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aydznn8y1Qbn for ; Fri, 30 Sep 2011 13:56:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8171121F8AAC for ; Fri, 30 Sep 2011 13:56:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R9kAu-00037R-S9; Fri, 30 Sep 2011 20:59:17 +0000 Date: Sat, 01 Oct 2011 05:59:15 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <20110930101754.GB10004@juniper.net> <20110930122831.GA10176@juniper.net> <3B65FD95-2E66-4D1F-B630-976ECE99050A@ericsson.com> <7309FCBCAE981B43ABBE69B31C8D213914A3308B30@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] is a longer announce invalid or not found? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 20:56:24 -0000 >> cool hack 14.3: the router itself can gen the public/private key pair >> a la ssh, the person configuring can extract the public key and send >> it to the rpki goddesses to be signed by the appropriate cert and put >> in the rpki. the private key never leaves the router! > I believe that Steve Kent says that usually a certificate request is > required to present Proof Of Possession (of the private key). So just > discovering the public key somehow would not be sufficient to be able > to request a cert with that public key. dear dr nit pick, when dealing with goddesses, one always frames things as a request randy