From Sandra.Murphy@sparta.com Tue Nov 6 07:35:05 2012 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 27B0A21F89B8 for ; Tue, 6 Nov 2012 07:35:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RefgPxUdH3Ft for ; Tue, 6 Nov 2012 07:35:04 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 87A0E21F879A for ; Tue, 6 Nov 2012 07:35:04 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA6FZ3U7032147 for ; Tue, 6 Nov 2012 09:35:03 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA6FZ1m0013140 for ; Tue, 6 Nov 2012 09:35:01 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Tue, 6 Nov 2012 10:35:01 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: slides from presenters by Thursday morning Thread-Index: AQHNvDRIet3snkdaTkGT50r0coApgA== Date: Tue, 6 Nov 2012 15:35:00 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5C1B@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] slides from presenters by Thursday morning 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, 06 Nov 2012 15:35:05 -0000 Our working group session on Friday will be using Meetecho for the remote p= resenters.=0A= =0A= The Meetecho staff need to upload the slides to their site for the presenta= tions.=0A= =0A= So please do get the slides to the chairs by Thursday morning so we can get= the slides to them and get any problems resolved before Friday morning.=0A= =0A= Slides by Thursday morning.=0A= =0A= --Sandy, speaking as co-chair= From Sandra.Murphy@sparta.com Tue Nov 6 09:35:56 2012 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 439A021F8738 for ; Tue, 6 Nov 2012 09:35:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQszY9-MD9ma for ; Tue, 6 Nov 2012 09:35:55 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A52F921F88EA for ; Tue, 6 Nov 2012 09:35:52 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA6HZlCP000702 for ; Tue, 6 Nov 2012 11:35:47 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA6HZlgO017309 for ; Tue, 6 Nov 2012 11:35:47 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Tue, 6 Nov 2012 12:35:47 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: additions and changes to agenda on Friday Thread-Index: Ac28OrfR/Q8DzNS0SPC8tLa/5HdiAQ== Date: Tue, 6 Nov 2012 17:35:46 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] additions and changes to agenda on Friday 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, 06 Nov 2012 17:35:56 -0000 We have three new topics to add to the agenda on Friday.=0A= =0A= Carlos Martinez would like to present a new version of draft-rogaglia-sidr-= multiple-publication-points.=0A= =0A= Sue Hares, idr co-chair, would like to request a review of work she is doin= g in a limited re-write of the base BGP spec, to fix errata in error handli= ng. She is aware that error handling can be a source of security issues an= d wants to be sure any issues are considered in the re-write.=0A= =0A= I would like to open a discussion with the wg concerning the recently annou= nced ARIN relying party agreement. I have concerns about this agreement's = impact on the envisioned RPKI architecture and dominant use. I think the w= g needs to consider the potential impact and any potential mechanisms that = would lessen impact. Note that the IETF can not interfere with ARIN legal = decisions!=0A= =0A= These revisions will be reflected in a more detailed agenda shortly.=0A= =0A= --Sandy= From dan-ietf@danyork.org Tue Nov 6 10:45:23 2012 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 45A5121F8AB7 for ; Tue, 6 Nov 2012 10:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt3MxwXyK+hX for ; Tue, 6 Nov 2012 10:45:22 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B78A21F8A9E for ; Tue, 6 Nov 2012 10:45:22 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so1258313iec.31 for ; Tue, 06 Nov 2012 10:45:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state; bh=N8ZYm7B6shBj/4oskZlOeWA2xZVx8b584dLfeuHVMXs=; b=Cq39z/IeO4YGSlSpMFsW9fM594OSkVn0i75BWABVgS5e6HPOyQwiO6J56K3Lln3MIT vBLidRpAc6pOfCwTvoQBChZ9H7HrAnEXoTQzfQUvbng1egbmDfSANDmip2VcGA4h9sBY vcrHV9gGryj5VqDK/RP4OFRZJxqOlYkXed64HhZ7t/HPbNo9COWlQEefYfM37bOzt/l+ gQGfwMN18yZk/umSKcfA2ysFF1/RJ83VE6zafBgeSKZbbC7GU3kwfIEKKZzc8dz6sW7O E/hd33T3Ny146wBRO5BrSey7PFY3nZwqGlnmegl47Az0NekzL1gtpAAiA5AbunhnBgi6 DSLQ== Received: by 10.50.208.99 with SMTP id md3mr2045686igc.67.1352227522010; Tue, 06 Nov 2012 10:45:22 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id xn10sm8659679igb.4.2012.11.06.10.45.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 10:45:21 -0800 (PST) From: Dan York Content-Type: multipart/alternative; boundary="Apple-Mail=_9C4996DF-3141-4435-9C24-CFB9BBC97AB1" Date: Tue, 6 Nov 2012 13:45:18 -0500 Message-Id: To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlsjBDyPXcPg8CUwQQ8a9aIw8CSy9ytCbqE7uB5gQkqLVD4SUvCh/4foSqDwQBnmj2bn0Br Subject: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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, 06 Nov 2012 18:45:23 -0000 --Apple-Mail=_9C4996DF-3141-4435-9C24-CFB9BBC97AB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here, in one easy-to-read article, is a great example of why we need = RPKI and/or other "secure routing" technologies that verify the origins = of route announcements: http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about Note: SIDR got a nice callout in the commentary on Hacker News: = http://news.ycombinator.com/item?id=3D4747910 (the exact SIDR reference = is here: http://news.ycombinator.com/item?id=3D4748108 ) --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_9C4996DF-3141-4435-9C24-CFB9BBC97AB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Here, in one = easy-to-read article, is a great example of why we need RPKI and/or = other "secure routing" technologies that verify the origins of route = announcements:


Note: SIDR got a nice callout in the = commentary on Hacker News: http://news.ycombin= ator.com/item?id=3D4747910  (the exact SIDR reference is = here: http://news.ycombin= ator.com/item?id=3D4748108 )

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork

= --Apple-Mail=_9C4996DF-3141-4435-9C24-CFB9BBC97AB1-- From randy@psg.com Tue Nov 6 16:23:22 2012 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 F133C21F8468 for ; Tue, 6 Nov 2012 16:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzESDrH0pGVH for ; Tue, 6 Nov 2012 16:23:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C549521F8466 for ; Tue, 6 Nov 2012 16:23:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TVtQM-0009ZP-Vf for sidr@ietf.org; Wed, 07 Nov 2012 00:23:19 +0000 Date: Wed, 07 Nov 2012 09:23:18 +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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] bgpsec protocol doc buglet 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 Nov 2012 00:23:22 -0000 in 3.1 penultimate paragraph, could you please change The first bit of the Flags field is the Confed_Segment flag. The Confed_Segment flag is set to one to indicate that the BGPSEC speaker that constructed this Secure_Path segment is sending the update message to a peer AS within the same Autonomous System confederation [5]. to say "The low order bit" instead? randy From christopher.morrow@gmail.com Tue Nov 6 17:01:47 2012 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 AE13321F8BC9 for ; Tue, 6 Nov 2012 17:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kllufDKdovw2 for ; Tue, 6 Nov 2012 17:01:46 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D16B21F8B81 for ; Tue, 6 Nov 2012 17:01:46 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so692646eek.31 for ; Tue, 06 Nov 2012 17:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/b3OKV4TpH8S+uZvBo3e3T9cgXQzRAqqQ1Z96DbXWVk=; b=CbznS9eJNwN6jh9oj88CqgJcEkftva+LrpGJeqn3wUDPiCKPrUmr8SRLf/qebT9pvl aoYi0FvYwR6/rF1OIyX+fadlSm10P7CqNtb4e985lZ/3LxnFhoUwzYcejwcPVEcKLoJd gRrbu6S8Ttk/liluogzio01saJb4e0H1I1i9sCTnxdc0a/oTYG6hy2lZQ0XW52QeybsR 2GIaXUyMtJDz38XpSBWnRemkS4LuyCECLWhq79toCi5u7ka//OIysP0pPOZLSDxit5/V pkt5RCBtv9je/NKTzpoZ1T6TPuXKa6vNCWdDjncWhk+qfts4Zc3vcPPUFbNpolOk7pge BNvA== MIME-Version: 1.0 Received: by 10.14.199.134 with SMTP id x6mr9391988een.31.1352250105611; Tue, 06 Nov 2012 17:01:45 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Tue, 6 Nov 2012 17:01:45 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Nov 2012 20:01:45 -0500 X-Google-Sender-Auth: I7hL6N5pVNzFLYZ5pcd097SHRRE Message-ID: From: Christopher Morrow To: Dan York Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 01:01:47 -0000 note I do want to see rpki/sidr deployment move forward, but... On Tue, Nov 6, 2012 at 1:45 PM, Dan York wrote: > > Here, in one easy-to-read article, is a great example of why we need RPKI > and/or other "secure routing" technologies that verify the origins of route > announcements: > origin here doesn't seem to actually be bad. path here seems to be unchanged from a possible path. probably moratel shouldn't have tried to send all of their routes to the rest of the world? maybe the provider to moratel could have filter 'not moratel' routes? (or filtered any of their routes... just like they didn't for pktelecom in 07). > http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about > > Note: SIDR got a nice callout in the commentary on Hacker News: > http://news.ycombinator.com/item?id=4747910 (the exact SIDR reference is > here: http://news.ycombinator.com/item?id=4748108 ) yes, nice... sadly I'm not sure that sidr's work would have helped here (aside from the possible early deployment steps of 'make prefix-lists from rpki informed data from IRRs' ... of course, if you can't be bothered to make prefix-filters to day :( > -- > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From dan-ietf@danyork.org Wed Nov 7 06:11:20 2012 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 441B121F8692 for ; Wed, 7 Nov 2012 06:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dps6JFkmfd2C for ; Wed, 7 Nov 2012 06:11:14 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8841421F8793 for ; Wed, 7 Nov 2012 06:11:14 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so1274366iak.31 for ; Wed, 07 Nov 2012 06:11:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Qm+LLJlwe1ym27OhIpdSWSa4/CPLFGTybByk3N9JgEk=; b=S90WDSkcPKJO9RT0Ew6o4+7SLAsDtUGZt9Rb4KwsM/jb/4FTqfvRrBpWBrwCOm318G OsOIfUrL834gHXmXA9LoO66P51Wg1lxdk/0I7sIwG8Nu03ddRZnCUOD4Eo/Zi3mIhVX8 4t340wBe5CHsZEerJicrGVK4Wg2z2TRjqS8lWy2a5EveMSc29S/itGDgSDBGpomGZwf8 ml0Y+d68qjpvNsy8nNrJE375U1rj3dbkowZqG9JHVmUxCd1Pz5bTvVLSlcq4SSY/IosL 9YLm1b43QJiixLvE/rCFB4TmrdWpJX6n58mLAcrQx4eoEEKdtTAA8WdbYaY82B+/5Aif i9ew== Received: by 10.50.0.171 with SMTP id 11mr4710127igf.14.1352297474005; Wed, 07 Nov 2012 06:11:14 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id uj6sm2126101igb.4.2012.11.07.06.11.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:11:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_5272EF0C-50BF-415F-B254-1364761572F2" From: Dan York In-Reply-To: Date: Wed, 7 Nov 2012 09:11:10 -0500 Message-Id: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnGGH9rCAJwWSlkw+jYo1IhWJeQ2K0+0XdeSvZCJYHR1aFo1FXaKsu52yfTmT5+8OW/MxiY Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 14:11:20 -0000 --Apple-Mail=_5272EF0C-50BF-415F-B254-1364761572F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Christopher, On Nov 6, 2012, at 8:01 PM, Christopher Morrow wrote: > On Tue, Nov 6, 2012 at 1:45 PM, Dan York wrote: >>=20 >> Here, in one easy-to-read article, is a great example of why we need = RPKI >> and/or other "secure routing" technologies that verify the origins of = route >> announcements: >>=20 >=20 > origin here doesn't seem to actually be bad. > path here seems to be unchanged from a possible path. > probably moratel shouldn't have tried to send all of their routes to > the rest of the world? > maybe the provider to moratel could have filter 'not moratel' routes? > (or filtered any of their routes... just like they didn't for > pktelecom in 07). Yes, someone else pointed out to me that this looks to be more of a = standard "route leakage" that RPI / BGPSEC / etc. would have really done = nothing to prevent. >=20 >> = http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about >>=20 >> Note: SIDR got a nice callout in the commentary on Hacker News: >> http://news.ycombinator.com/item?id=3D4747910 (the exact SIDR = reference is >> here: http://news.ycombinator.com/item?id=3D4748108 ) >=20 > yes, nice... sadly I'm not sure that sidr's work would have helped > here (aside from the possible early deployment steps of 'make > prefix-lists from rpki informed data from IRRs' ... of course, if you > can't be bothered to make prefix-filters to day :( Agreed, sadly... but the good news is that this whole thing did get more = people thinking about the underlying router infrastructure. So if it = gets some people to wake up and pay more attention, I think that's a = good thing. Thanks, Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_5272EF0C-50BF-415F-B254-1364761572F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Tue, Nov 6, 2012 at 1:45 PM, Dan York <dan-ietf@danyork.org> = wrote:

Here, in one easy-to-read article, is a great example of = why we need RPKI
and/or other = "secure routing" technologies that verify the origins of = route
announcements:


origin here doesn't seem to actually = be bad.
path here seems to be unchanged from a possible = path.
probably moratel shouldn't have tried to send all of their = routes to
the rest of the world?
maybe the provider to moratel = could have filter 'not moratel' routes?
(or filtered any of their = routes... just like they didn't for
pktelecom in = 07).

Yes, someone else pointed out = to me that this looks to be more of a standard "route leakage" that RPI = / BGPSEC / etc. would have really done nothing to = prevent.

http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit= -about

Note: SIDR got = a nice callout in the commentary on Hacker = News:
http://news.ycombin= ator.com/item?id=3D4747910  (the exact SIDR reference = is
here: http://news.ycombin= ator.com/item?id=3D4748108 )

yes, nice... sadly = I'm not sure that sidr's work would have helped
here (aside from the = possible early deployment steps of 'make
prefix-lists from rpki = informed data from IRRs' ... of course, if you
can't be bothered to = make prefix-filters to day = :(

Agreed, sadly... but the = good news is that this whole thing did get more people thinking about = the underlying router infrastructure.  So if it gets some people to = wake up and pay more attention, I think that's a good = thing.

Thanks,
Dan

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork

= --Apple-Mail=_5272EF0C-50BF-415F-B254-1364761572F2-- From christopher.morrow@gmail.com Wed Nov 7 07:13:51 2012 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 1AE3621F8BB1 for ; Wed, 7 Nov 2012 07:13:51 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ldemUqmOQD for ; Wed, 7 Nov 2012 07:13:50 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05C4321F8B96 for ; Wed, 7 Nov 2012 07:13:49 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1117247eek.31 for ; Wed, 07 Nov 2012 07:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U25CzTV0KmbgUHJui/KzcQKwM2K0nXBKyiEAVCPEygw=; b=BWBjUBh/oItBWcwEGs9gN2yvYG51eT2uGAKPyoQpP8wKAWLFrgL0T14vVJOgKBX6ge Io6j1bFR9E2R3nyaTXSJbl1+45+8XijC2abTnK0Y/W2Rw3aNMQuD6qRVP6ZaPgmZvFig /SrBX4tHhCZuZTa5NtXKEDCfnt3yebkdtcmU+63UjXeS4eDz0o5BElZ1Ed9pDdqRQUHf uLEI4+79PCkh6Y5qgTN2oduxe1lk/VkpZ5utt+IsMJ0YW99lRnckJ6QyGf8c2YVJq8cB M+stXrOQppvrlkATccN3oXsvvSjDmmSepLZWVK9X5FL5J2aoOSWBG5DeotDtDAa8LAri E8CQ== MIME-Version: 1.0 Received: by 10.14.175.71 with SMTP id y47mr16462258eel.36.1352301229183; Wed, 07 Nov 2012 07:13:49 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 07:13:49 -0800 (PST) In-Reply-To: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> Date: Wed, 7 Nov 2012 10:13:49 -0500 X-Google-Sender-Auth: xQsKISnF7XykFOgHpCAP45c62Go Message-ID: From: Christopher Morrow To: Dan York Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 15:13:51 -0000 On Wed, Nov 7, 2012 at 9:11 AM, Dan York wrote: > Agreed, sadly... but the good news is that this whole thing did get more > people thinking about the underlying router infrastructure. So if it gets > some people to wake up and pay more attention, I think that's a good thing. yep. From danny@tcb.net Wed Nov 7 07:25:19 2012 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 E9A4221F8BEB for ; Wed, 7 Nov 2012 07:25:18 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-k83Is1NdTb for ; Wed, 7 Nov 2012 07:25:17 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 8237B21F8BE9 for ; Wed, 7 Nov 2012 07:25:17 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 1541C207A for ; Wed, 7 Nov 2012 15:25:17 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 39155206A; Wed, 7 Nov 2012 08:25:16 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 10:25:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 08:25:17 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509a7d5d199639289316612 X-DSPAM-Factors: 27, be+#+a, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, at+the, 0.01000, the+#+of, 0.01000, in+the, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, Subject*Re+sidr, 0.01000, a+#+#+of, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, This+is, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000, to+be, 0.01000, with+the, 0.01000, Cc*sidr+ietf.org, 0.01000, Mime-Version*Apple+#+#+v1283, 0.01000, Mime-Version*Apple+Message, 0.01000, of+the, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 15:25:19 -0000 On Nov 7, 2012, at 10:13 AM, Christopher Morrow wrote: > On Wed, Nov 7, 2012 at 9:11 AM, Dan York wrote: >> Agreed, sadly... but the good news is that this whole thing did get = more >> people thinking about the underlying router infrastructure. So if it = gets >> some people to wake up and pay more attention, I think that's a good = thing. >=20 > yep. Chris,=20 Given that all the RPKI/BGPSEC machinery fully deployed would NOT have = helped here, what is your key desire for this RPKI/SIDR/BGPSEC work? Is = it simply for resource certification? What do you believe we should do about THIS problem? =20 This is precisely why we wrote the "leak" draft (and the IRR draft) - = work areas which are somehow out of scope of the _secure _inter-domain = _routing WG. Heck, the Friday conflict with the GROW WG illustrates the = disconnect here as well. And if at the end of the day the answer is that we need IRR-esque = capabilities anyway, and if we'd did just that we could remove most of = the threats in the routing system, then we sure appear to be doing a = helluva lot of work here while totally ignoring these problems? =20 -danny From christopher.morrow@gmail.com Wed Nov 7 08:12:00 2012 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 CBD3521F8C7A for ; Wed, 7 Nov 2012 08:12:00 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qMxPBL-ezgv for ; Wed, 7 Nov 2012 08:12:00 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8C9C21F8C45 for ; Wed, 7 Nov 2012 08:11:59 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so789799eaa.31 for ; Wed, 07 Nov 2012 08:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GhSpqxOkIrq1SIDQuZCu3ayCCq4tQ1e+pUvsc2mibC4=; b=q9+lCXfc3BkX6bsA7pvI8A6LrtV7HyHj+aOXoH7GFCbtyxqPMjmeYiTY5jaeAmQxti QlWZeMgmKNIzQJG/TYvF0KYpcezAamRP/EGfg8XI2zYdyI8RGRk2AbRkPQC/qxpM9YSm QJ1A4w6n8nE4uFtm9LzagC7sZ4j+T2KHn1WKb5DW8SWIhcCSmP+sfAAYTAF+q36/LQbY XjO9qhZK9B+lhEr8+CRUhNgHpa9qoYJnd0QbvXAvSdL+PfHz/LRRGJ4TijEGQnxLw9hh Jml/8W4DgspDlmZmyM1B5W56n5f2AevLttLAR4MCg3f8RMLA1iE1FkvibA+ZMBBOiUbF FI1Q== MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr16941240eem.42.1352304718737; Wed, 07 Nov 2012 08:11:58 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 08:11:58 -0800 (PST) In-Reply-To: <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> Date: Wed, 7 Nov 2012 11:11:58 -0500 X-Google-Sender-Auth: 4GegOh5GZhuspVjggZhVTLHjh1Q Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 16:12:00 -0000 On Wed, Nov 7, 2012 at 10:25 AM, Danny McPherson wrote: > > On Nov 7, 2012, at 10:13 AM, Christopher Morrow wrote: > >> On Wed, Nov 7, 2012 at 9:11 AM, Dan York wrote: >>> Agreed, sadly... but the good news is that this whole thing did get more >>> people thinking about the underlying router infrastructure. So if it gets >>> some people to wake up and pay more attention, I think that's a good thing. >> >> yep. > > > Chris, > Given that all the RPKI/BGPSEC machinery fully deployed would NOT have > helped here, what is your key desire for this RPKI/SIDR/BGPSEC work? Is resource certification, in the form of RPKI, would at least remove a barrier people put up about using IRR data to make prefix-filters... so ideally we get some win with just RPKI. Origin validation is also handy for the cases where people mis-originate (happens some). Path validation is handy for cases where people attempt to insert false information into the path (for whatever reason they seem to think is important). there isn't data in bgp today data which tells you 'this path is a leak'. Even at the immediately-leaked-to peer there isn't data in the message that's helpful for this problem. > it simply for resource certification? > > What do you believe we should do about THIS problem? go poke bdickson about his draft? (done several times, fyi) figure out how to tell if the 'leak' is a 'leak' based only on bgp data on the wire, from more than 2 as-hops away? (several proposals) > This is precisely why we wrote the "leak" draft (and the IRR draft) - work the leak draft submitted (the id I mean) doesn't say what a leak is in any way that's helpful given the bgp data today from more than outside the immediate leaked-to asn. > areas which are somehow out of scope of the _secure _inter-domain _routing I thought the determination was that there wasn't anything today in BGP that would be available to tell you that the data you see is actually a 'leak' and not a 'backup path' (or something similar, hidden path not previously seen || new transit path coming online || ....) and that SIDR asked IDR to make something be exposed, to which IDR said: "Is this a problem? ask GROW folks pls to determine if there is a problem to be worked on." GROW hasn't seen input on this... > WG. Heck, the Friday conflict with the GROW WG illustrates the disconnect > here as well. take that up with the secretariat? I'm not sure how 'sidr chairs have a conflict with grow chairs, since they are the same person' isn't a clear signal to: "do not schedule these at the sametime". > > And if at the end of the day the answer is that we need IRR-esque capabilities sure... and people willing to actually make filtering happen on their bgp peerings (pccw seems to just not do that, at least not in any sort of a reliable manner) > anyway, and if we'd did just that we could remove most of the threats in the > routing system, then we sure appear to be doing a helluva lot of work here > while totally ignoring these problems? the threats doc I think does try to outline other problems, and I don't think anyone working on SIDR things is ignoring this problem. -chris From danny@tcb.net Wed Nov 7 08:33:43 2012 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 371E621F865C for ; Wed, 7 Nov 2012 08:33:43 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj24lmkyg-FK for ; Wed, 7 Nov 2012 08:33:42 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D80421F8498 for ; Wed, 7 Nov 2012 08:33:42 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id AD2492080 for ; Wed, 7 Nov 2012 16:33:41 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id ABC3E2068; Wed, 7 Nov 2012 09:33:40 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 11:33:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 09:33:41 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509a8d65199631735120510 X-DSPAM-Factors: 27, be+#+a, 0.01000, be+#+a, 0.01000, in+#+routing, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+system, 0.01000, 2012+#+#+#+AM, 0.01000, of+#+#+at, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, the+routing, 0.01000, cases+where, 0.01000, cases+where, 0.01000, routing+system, 0.01000, for+the, 0.01000, at+#+time, 0.01000, Mime-Version*Apple+#+framework, 0.01000, the+#+#+#+routing, 0.01000, BGP+#+#+#+with, 0.01000, the+#+in, 0.01000, the+#+in, 0.01000, is+#+#+to, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, at+the, 0.01000, at+the, 0.01000, the+#+of, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 16:33:43 -0000 On Nov 7, 2012, at 11:11 AM, Christopher Morrow wrote: >=20 > resource certification, in the form of RPKI, would at least remove a > barrier people put up about using IRR data to make prefix-filters... > so ideally we get some win with just RPKI. I agree we need resource certification, but if I now have to replicate = policy data (e.g., ROAs) contained in that new system in IRRs and then = fix the problems in the IRRs anyway, well... > Origin validation is also handy for the cases where people > mis-originate (happens some). And you can get that from IRR data today, without ANY of the machinery = from rtr-rpki or BGPSEC. > Path validation is handy for cases where people attempt to insert > false information into the path (for whatever reason they seem to > think is important). >=20 > there isn't data in bgp today data which tells you 'this path is a > leak'. Even at the immediately-leaked-to peer there isn't data in the > message that's helpful for this problem. And I'm not convinced it needs to be in BGP. NOT being in BGP could be = considered a feature. > go poke bdickson about his draft? (done several times, fyi) > figure out how to tell if the 'leak' is a 'leak' based only on bgp > data on the wire, from more than 2 as-hops away? (several proposals) I'm not convinced that is the right approach, I don't think it needs to = be IN BGP. Hence the original route leak draft, which we just updated, = mind you: = > the leak draft submitted (the id I mean) doesn't say what a leak is in > any way that's helpful given the bgp data today from more than outside > the immediate leaked-to asn. I don't believe this needs to be fixed IN BGP. > I thought the determination was that there wasn't anything today in > BGP that would be available to tell you that the data you see is > actually a 'leak' and not a 'backup path' (or something similar, > hidden path not previously seen || new transit path coming online || > ....) and that SIDR asked IDR to make something be exposed, to which > IDR said: "Is this a problem? ask GROW folks pls to determine if there > is a problem to be worked on." GROW hasn't seen input on this... I don't think this needs to be done IN BGP. > take that up with the secretariat? I'm not sure how 'sidr chairs have > a conflict with grow chairs, since they are the same person' isn't a > clear signal to: "do not schedule these at the sametime". Telling, indeed.. > sure... and people willing to actually make filtering happen on their > bgp peerings (pccw seems to just not do that, at least not in any sort > of a reliable manner) Agreed.. >=20 >> anyway, and if we'd did just that we could remove most of the threats = in the >> routing system, then we sure appear to be doing a helluva lot of work = here >> while totally ignoring these problems? >=20 > the threats doc I think does try to outline other problems, and I > don't think anyone working on SIDR things is ignoring this problem. Not on my last read, e.g.: " (These behaviors are not precluded by the specification for BGP,=20 and might be the result of a local policy that is not publicly = disclosed. =20 As a result, they are not considered attacks. See Section 5 for = additional=20 discussion.)" and "Moreover, route leaks are outside the scope of PATHSEC, at this = time,=20 based on the SIDR charter." From christopher.morrow@gmail.com Wed Nov 7 08:35:42 2012 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 9E38021F865C for ; Wed, 7 Nov 2012 08:35:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJR6rICi1NKn for ; Wed, 7 Nov 2012 08:35:42 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E66E321F8498 for ; Wed, 7 Nov 2012 08:35:41 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so799539eaa.31 for ; Wed, 07 Nov 2012 08:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zEE1qQGjFj/E9if21ZpI0JA+ivKE2kePS8pWNDxvZfg=; b=tRcfgbAYWu4rYf6SsO9PJGp6VnkvAY+4X+fhzE5hDetzk5Rm0E4kjH45rCNcaLZs+0 XpE0YX5YMfZbyaS01TTEdyPqTvK5OegRXiLS7PY5n0nGcLZLC6ttH21vY5b1DIhfj+jy AHnGUqd1W0Ky094pretxjAAXIGykdKqMYu66qacQr08tpAtICTfZgMp9qEDxAlVR0uFg 8wZcIo0gNhQBL0KONZF9UW9nKGhO8Doas627Wx9L+D0u+wD6IQs/ogQi9tZQUdgqL+T3 NoG18Jf5OCCgU/oOmJzTGhgxVJY8aiToUWrwR7skbCvymZEqUaWWRLS9+JpcjnRucFli hXBQ== MIME-Version: 1.0 Received: by 10.14.199.134 with SMTP id x6mr17294080een.31.1352306141166; Wed, 07 Nov 2012 08:35:41 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 08:35:41 -0800 (PST) In-Reply-To: <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> Date: Wed, 7 Nov 2012 11:35:41 -0500 X-Google-Sender-Auth: E64TsUbilKMSU-rE08NoBe6GMXM Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 16:35:42 -0000 On Wed, Nov 7, 2012 at 11:33 AM, Danny McPherson wrote: >> take that up with the secretariat? I'm not sure how 'sidr chairs have >> a conflict with grow chairs, since they are the same person' isn't a >> clear signal to: "do not schedule these at the sametime". > > Telling, indeed.. apparently there's some action coming that may change this timing problem ... or so I hear. From danny@tcb.net Wed Nov 7 10:29:52 2012 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 6115921F8C46 for ; Wed, 7 Nov 2012 10:29:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i6Vgbf5yXj9 for ; Wed, 7 Nov 2012 10:29:52 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id F15EC21F8C24 for ; Wed, 7 Nov 2012 10:29:51 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 5C3B8207C for ; Wed, 7 Nov 2012 18:29:51 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id F34FD2068; Wed, 7 Nov 2012 11:29:50 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> Date: Wed, 7 Nov 2012 13:29:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 11:29:51 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509aa89f199631741811020 X-DSPAM-Factors: 27, to+#+the, 0.01000, Mime-Version*Message+#+v1283, 0.01000, would+#+#+#+a, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, would+#+to, 0.01000, at+#+#+PM, 0.01000, Mime-Version*Apple+#+framework, 0.01000, the+#+in, 0.01000, to+the, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, that+the, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*Re+sidr, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000, with+the, 0.01000, Cc*sidr+ietf.org, 0.01000, Cc*sidr+ietf.org, 0.01000, Mime-Version*Apple+#+#+v1283, 0.01000, Mime-Version*Apple+Message, 0.01000 Cc: "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 18:29:52 -0000 On Nov 6, 2012, at 12:35 PM, Murphy, Sandra wrote: >=20 > I would like to open a discussion with the wg concerning the recently = announced ARIN relying party agreement. I have concerns about this = agreement's impact on the envisioned RPKI architecture and dominant use. = I think the wg needs to consider the potential impact and any potential = mechanisms that would lessen impact. Note that the IETF can not = interfere with ARIN legal decisions! Sandy,=20 Can you elaborate what your "concerns about this agreement's impact on = the envisioned RPKI architecture and dominant use" are? Do you have a = reference or outline we can review prior to the discussion in order to = keep this from being a = bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuf= f fest? Thanks,=20 -danny From christopher.morrow@gmail.com Wed Nov 7 10:37:47 2012 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 A96CC21F8C96 for ; Wed, 7 Nov 2012 10:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9bEfzpy1LBr for ; Wed, 7 Nov 2012 10:37:46 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 258D621F8C4D for ; Wed, 7 Nov 2012 10:37:45 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1252972eek.31 for ; Wed, 07 Nov 2012 10:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VSFB+6yTxSlZGcCD3UUzsNtAkftuvdpeZefp0EL7MaU=; b=LADzho9HfEXcH0lQ5UXfUMpmqY6nHUGEavujvXP1YpXCmAMDJRJ8EmrxVgitP+3rmH xPuWpEpxtYSqWTywOvWSiiwo3Cti3t1iwyEOQwCaV3feHCfu8KP0eX1DtX+5uSY3fpwu e9YrbVCLI1NVh/p0lkCfWxdmuz/Kcv9h/3dqALjmRdHgheO0dxnJPYqySm6HJKxR/Dvt HPPY2BcQtWqdIp3905QYYdFuWNi6NnmSseb9xgtlqN0Kcztf+DUiGJdwUeJp3wyy1lOY W6rUg2xbmiI4KS0VtLd2waAImo17Nz8FviotZhHNRj1V6V3uzo6nyz/Ljy5bInlOmDw7 /2bw== MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr18203483eem.42.1352313465221; Wed, 07 Nov 2012 10:37:45 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 10:37:45 -0800 (PST) In-Reply-To: <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> Date: Wed, 7 Nov 2012 13:37:45 -0500 X-Google-Sender-Auth: u4t3IUU3-OJFTtQGZCqSdANk9To Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 18:37:47 -0000 On Wed, Nov 7, 2012 at 11:33 AM, Danny McPherson wrote: > I'm not convinced that is the right approach, I don't think it needs to be IN BGP. Hence the original route leak draft, which we just updated, mind you: > > where to send comments/questions? From danny@tcb.net Wed Nov 7 10:39:46 2012 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 221F421F8C01 for ; Wed, 7 Nov 2012 10:39:46 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL4ZqTc1DlgI for ; Wed, 7 Nov 2012 10:39:45 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7F51A21F8B71 for ; Wed, 7 Nov 2012 10:39:33 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 21A2A207E for ; Wed, 7 Nov 2012 18:39:33 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 8E8A82068; Wed, 7 Nov 2012 11:39:32 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 13:39:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8616D617-74B3-442D-BFBE-C20D34CBB227@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 11:39:33 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509aaae5199631083017553 X-DSPAM-Factors: 27, Cc*sidr+#+#+#+ietf.org, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Mime-Version*Apple+#+framework, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Cc*sidr+#+list, 0.01000, the+#+of, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, 2012+#+#+#+PM, 0.01000, Subject*Re+sidr, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, Cc*sidr+#+#+sidr, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000, Cc*sidr+ietf.org, 0.01000, Cc*sidr+ietf.org, 0.01000, Mime-Version*Apple+#+#+v1283, 0.01000, Nov+#+#+at, 0.01000, Mime-Version*Apple+Message, 0.01000, On+Nov, 0.01000, Cc*list+#+ietf.org, 0.01000, of+the, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 18:39:46 -0000 On Nov 7, 2012, at 1:37 PM, Christopher Morrow wrote: >=20 > where to send comments/questions? Fine question, apparently out of the scope of _S_I_D_R. Perhaps GROW, = we should ask the chairs :-) -danny From shane@castlepoint.net Wed Nov 7 10:39:48 2012 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 B02A421F8C2B for ; Wed, 7 Nov 2012 10:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMRbplriM-dl for ; Wed, 7 Nov 2012 10:39:48 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB721F8B3A for ; Wed, 7 Nov 2012 10:39:45 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id E52DD207E for ; Wed, 7 Nov 2012 18:39:44 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 62D6B2068; Wed, 7 Nov 2012 11:39:44 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Wed, 7 Nov 2012 13:39:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 11:39:44 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509aaaf0199634875613401 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, Subject*route+announcement, 0.01000, On+#+7, 0.01000, Subject*today+#+to, 0.01000, Subject*to+bogus, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, 2012+#+#+#+AM, 0.01000, Subject*outage+today, 0.01000, 2012+at, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, the+#+#+that, 0.01000, Subject*need+#+SIDR, 0.01000, 7+#+at, 0.01000, Subject*limited+#+#+due, 0.01000, Subject*today+due, 0.01000, is+#+to, 0.01000, Subject*need+#+#+-, 0.01000, for+this, 0.01000, Subject*Google+#+#+today, 0.01000, Subject*bogus+#+announcement, 0.01000, Subject*Re+#+#+need, 0.01000, the+#+in, 0.01000, Subject*for+#+-, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 18:39:48 -0000 Chris, On Nov 7, 2012, at 11:11 AM, Christopher Morrow = wrote: > there isn't data in bgp today data which tells you 'this path is a > leak'. Even at the immediately-leaked-to peer there isn't data in the > message that's helpful for this problem. Why isn't the above considered putting the cart in front of the horse? = Namely, there is this (seemingly) hard requirement that all information = must be self-contained within BGP -- even though the above acknowledges = that we CANNOT get this information out from BGP. Shouldn't that = suggest there is a pretty fundamental problem here wrt the current = definition of the problem? What's even more perplexing is the WG seems to accept that it's OK to = accept substantial complexity in creating, exchanging, validating = information using an "out-of-band" certificate repository system (RPKI) = ... which is OK to be used for Origin Validation by BGP, but for some = reason ... BGPSEC is saying that it cannot depend on external = information sources for Path Validation (other than per-router/per-AS = certs). Something really does not add up on where lines appear to be = arbitrarily drawn here. -shane= From christopher.morrow@gmail.com Wed Nov 7 10:42:57 2012 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 F037121F8B3A for ; Wed, 7 Nov 2012 10:42:57 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj-VkUIYzf0Y for ; Wed, 7 Nov 2012 10:42:57 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 365E421F8C0F for ; Wed, 7 Nov 2012 10:42:56 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so850873eaa.31 for ; Wed, 07 Nov 2012 10:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OXxet1KaDzCTOWHgFoXAL/9pyJVUKlU6LW3dLkk96PQ=; b=pxYfx+n2K0JOij+u9XU6udY7ySX20VQf4haQC6GK/bzCdyOSmkbc0i5RM3iPKyLK9m wtYl9uzDO572p5au4AeJLTD0E/cjX2g+oFWcMMLE+1vgjn/uYJpC6mna6O0gG9Cattt/ gsJyWg0uRysr9TzEqqoXlyaS05ru3SDvmkMeYx6BcNANc5QWvjayKQrZX5Mb+23oLnwS Zh0Z7RjNjST0AranxEk5Adp+thCkulWy5NqP8mAN1/aMAUXWlZ09pt56Uwyv14EFFDmM kwhD6kEN8om74R4lLEhXPhOdqfPQ+gmb53U5IKB/VS43APsdwZVDbkSnG0UZ1LNgdWGC vSkg== MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr18247437eem.42.1352313775369; Wed, 07 Nov 2012 10:42:55 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 10:42:55 -0800 (PST) In-Reply-To: <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> Date: Wed, 7 Nov 2012 13:42:55 -0500 X-Google-Sender-Auth: DMoLh1camfLfqZpdDlvzPomkHqs Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 18:42:58 -0000 On Wed, Nov 7, 2012 at 11:33 AM, Danny McPherson wrote: > Not on my last read, e.g.: > > " (These behaviors are not precluded by the specification for BGP, > and might be the result of a local policy that is not publicly disclosed. > As a result, they are not considered attacks. See Section 5 for additional > discussion.)" > yes, not ignored. > and > > "Moreover, route leaks are outside the scope of PATHSEC, at this time, > based on the SIDR charter." right, change the charter? find a way to describe the problem (which is what's been asked for for ~1+yrs now?). The draft you reference up-thread isn't actually helpful, it doesn't show how to know that the leak is a leak and not another backup path coming to light for other reasons in the system. -chris From christopher.morrow@gmail.com Wed Nov 7 10:48:48 2012 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 0684921F8C4C for ; Wed, 7 Nov 2012 10:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YASQp10HiKA3 for ; Wed, 7 Nov 2012 10:48:47 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C56D21F8C4F for ; Wed, 7 Nov 2012 10:48:47 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1258940eek.31 for ; Wed, 07 Nov 2012 10:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yz9qhvvyHxB8RmfQUbaDDSkAu4xVD7Hmv+egQGgWopE=; b=MRRAyef1JfXlgER+ZE4omYtKTy1HMq+gdw928+1g1iC/UmzAP/hls9Wae8vZ6dlQWA sRGKXi3OVZLK9AhUWBHddK7xOVEHzg5UyxNqqnXOgi4aWikGwe3Z5dkFS9iIW0GRzO5L zIemXLWUzg2RBzNf6V1rbuXa//iKv9qKCdxMTlRF/Aw1dw3N22fUw9KQlxaviE+2Kgni BsLw6Zt3MOWWjwm5+Os9i7M6uUOWINRvZKAfviwNTqqsWtAqxQYndGn60YONlltDMK8/ MVtzivJvobS6c6faSYsZZ/uWn9c7EXxDOc0BvS8MCcdwskkA9Onq4pA8LBmG2HS69aVm d5bQ== MIME-Version: 1.0 Received: by 10.14.184.1 with SMTP id r1mr18621933eem.4.1352314126407; Wed, 07 Nov 2012 10:48:46 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 10:48:46 -0800 (PST) In-Reply-To: <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> Date: Wed, 7 Nov 2012 13:48:46 -0500 X-Google-Sender-Auth: RlWAbN5kNF95HbDKI6kwPO8BGYY Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 18:48:48 -0000 On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante wrote: > Chris, > > On Nov 7, 2012, at 11:11 AM, Christopher Morrow wrote: >> there isn't data in bgp today data which tells you 'this path is a >> leak'. Even at the immediately-leaked-to peer there isn't data in the >> message that's helpful for this problem. > > Why isn't the above considered putting the cart in front of the horse? Namely, > there is this (seemingly) hard requirement that all information must be > self-contained within BGP -- even though the above acknowledges that > we CANNOT get this information out from BGP. Shouldn't that suggest there > is a pretty fundamental problem here wrt the current definition of the problem? I think if you have only a bgp message to deal with that's all you have to base your judgement upon. The SIDR work so far has added a signature for origination and in BGPSEC proposes adding signatures as part of bgpsec-path. If you know of, or can create, or can find inexistence already, data that helps solve the 'route leaks problem' please bring it forward. I think the wgs involved here (at least: sidr, idr, grow) all have agreed that the first step is: 1) show/agree that this is a problem (route leaks) 2) see if bgp data already has the right bits to fix this (idr) 3) slap some verification on those bits arguing about carts and horses isn't moving the above 3 steps forward. > What's even more perplexing is the WG seems to accept that it's OK to > accept substantial complexity in creating, exchanging, validating information > using an "out-of-band" certificate repository system (RPKI) ... which is OK to > be used for Origin Validation by BGP, but for some reason ... BGPSEC is > saying that it cannot depend on external information sources for Path > Validation (other than per-router/per-AS certs). Something really does not what external source? From christopher.morrow@gmail.com Wed Nov 7 10:49:36 2012 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 0189521F8C7A for ; Wed, 7 Nov 2012 10:49:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV7Q1s3mLtkb for ; Wed, 7 Nov 2012 10:49:35 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2021F8C4F for ; Wed, 7 Nov 2012 10:49:34 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so853703eaa.31 for ; Wed, 07 Nov 2012 10:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PEkw7pZLwp4t6JV4z5vngRPe48KVKbiK5oEDeNsxFt0=; b=sac+z8z4/Ca6Wr0iYhIA+6BMfQyIRNznXFNBkNc4atxPr7JLx0HDePRY3fwl0eKunN OtmJiHZC6U2QxkQVBbuXtjsi40OnLRdd0hdMWRCxiBrfqY5v5CnP2c7+VtRKJmX+UmlI N1hkPkCOerBgAxI4kFjwdIXwtgHBNN2twWXF9/1xSdS4kCI1j+E72pPF1Ys44FnctxSG 6GGrfAk1iU3HFxGDb1Gdf1yr495Dz5olQxlc1+XavA66WLuJVVA6ka63etw+x6aRmfyV Wv1ROZ1T4laRY8Hz0rl9FWNY/93uZCHSHjPOxJOBqEPxFOHyVf/csKdKKxwZnrlfscsb COtA== MIME-Version: 1.0 Received: by 10.14.172.195 with SMTP id t43mr18539201eel.17.1352314174197; Wed, 07 Nov 2012 10:49:34 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 10:49:34 -0800 (PST) In-Reply-To: <8616D617-74B3-442D-BFBE-C20D34CBB227@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <8616D617-74B3-442D-BFBE-C20D34CBB227@tcb.net> Date: Wed, 7 Nov 2012 13:49:34 -0500 X-Google-Sender-Auth: WDwL2ANLcGhtiiJSKOFpDxfwoBg Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 18:49:36 -0000 On Wed, Nov 7, 2012 at 1:39 PM, Danny McPherson wrote: > > On Nov 7, 2012, at 1:37 PM, Christopher Morrow wrote: >> >> where to send comments/questions? > > Fine question, apparently out of the scope of _S_I_D_R. Perhaps GROW, we should ask the chairs :-) > frankly I'm happy to add comments on the sidr list, or grow list or you directly... my question perhaps was mis-phrased, I'll try again: "Where would you like me (or others) to send comments on this draft?" From Sandra.Murphy@sparta.com Wed Nov 7 10:53:07 2012 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 65CBB21F8C7A for ; Wed, 7 Nov 2012 10:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-bZdmd9VRUU for ; Wed, 7 Nov 2012 10:53:04 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 587A921F8C4F for ; Wed, 7 Nov 2012 10:52:58 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA7IqwDf010454 for ; Wed, 7 Nov 2012 10:52:58 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA7IqvQs030118 for ; Wed, 7 Nov 2012 10:52:57 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Wed, 7 Nov 2012 13:52:57 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: Meetecho info for Friday meeting Thread-Index: Ac29GRmp+22T8TjVTBKcmNHwrAAO6Q== Date: Wed, 7 Nov 2012 18:52:56 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E88B7@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] Meetecho info for Friday meeting 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 Nov 2012 18:53:07 -0000 Meetecho is supporting the IETF and the IETF85 web site has lots of Meetech= o information:=0A= =0A= http://ietf85.conf.meetecho.com=0A= http://www.ietf.org/meeting/85/remote-participation.html#Meetecho=0A= =0A= =0A= Those who are intending to participate remotely should pay particular atten= tion to http://ietf85.conf.meetecho.com/index.php/Web_Client.=0A= =0A= The Meetecho page shows where Meetecho is supporting other wg, so you can t= ry this out ahead of time if you like.=0A= =0A= --Sandy= From danny@tcb.net Wed Nov 7 11:02:41 2012 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 40CF121F8CA1 for ; Wed, 7 Nov 2012 11:02:41 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDB+hFGpCpOS for ; Wed, 7 Nov 2012 11:02:40 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC421F8AB8 for ; Wed, 7 Nov 2012 11:02:40 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 47C66207E for ; Wed, 7 Nov 2012 19:02:40 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id A97A9206A; Wed, 7 Nov 2012 12:02:39 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 14:02:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 12:02:40 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ab050199631951014887 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, most+of, 0.01000, Subject*route+announcement, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, On+#+7, 0.01000, the+#+#+#+I, 0.01000, Subject*today+#+to, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Subject*outage+today, 0.01000, a+#+to, 0.01000, 2012+at, 0.01000, would+#+to, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, Subject*need+#+SIDR, 0.01000, the+#+#+a, 0.01000, the+#+#+a, 0.01000, 7+#+at, 0.01000, Subject*limited+#+#+due, 0.01000, Subject*today+due, 0.01000, Subject*need+#+#+-, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 19:02:41 -0000 On Nov 7, 2012, at 1:42 PM, Christopher Morrow wrote: > The draft you reference up-thread isn't actually helpful, it doesn't > show how to know that the leak is a leak and not another backup path > coming to light for other reasons in the system. The fact that even folks here were confused where RPKI/BGPSEC would be = helpful and would NOT highlights the disconnect about what problems = they're trying to solve for us in SIDR. The draft was written as an = attempt to help minimize confusion and it may have missed the mark but = I'm told some have found it helpful. How about this: "We need a way to show how to know that the leak is a = leak and not another backup path coming to light for other reasons in = the system" (that might sound familiar :-). The solution doesn't = presuppose it's codified in BGP on the wire, and shouldn't preclude = simply improving existing tooling and systems, of which many operators = already employ (e.g., IRRs and static [persistent] AS path and prefix = lists). With the hyper-focus on publication of standard-based RPKI/BGPSEC in = this WG I do concur that it's likely not the right place. However, I = would note that if I can solve most of the real problems above without = BGP changes or any new systems then I may not need RPKI/BGPSEC work at = all. That said, I would hate to see SIDR be Standards-Track and = "legislated" and not solve problems as fundamental as this, while the = lower hanging fruit is steam-rolled by efforts here. -danny From danny@tcb.net Wed Nov 7 11:04:36 2012 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 5F0B221F8C61 for ; Wed, 7 Nov 2012 11:04:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keinaEUqclg7 for ; Wed, 7 Nov 2012 11:04:36 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 236D821F8917 for ; Wed, 7 Nov 2012 11:04:34 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id A0959207E for ; Wed, 7 Nov 2012 19:04:33 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 2EACD206A; Wed, 7 Nov 2012 12:04:33 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 14:04:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <21AE3435-84EE-4F3C-9A52-B8F930FEA336@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <8616D617-74B3-442D-BFBE-C20D34CBB227@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 12:04:33 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ab0c1199631950213142 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, Subject*route+announcement, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, On+#+7, 0.01000, Subject*today+#+to, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Subject*outage+today, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, Subject*need+#+SIDR, 0.01000, 7+#+at, 0.01000, Subject*limited+#+#+due, 0.01000, Subject*today+due, 0.01000, Subject*need+#+#+-, 0.01000, Subject*Google+#+#+today, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Subject*bogus+#+announcement, 0.01000, Subject*Re+#+#+need, 0.01000, Christopher+#+wrote, 0.01000, Subject*for+#+-, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 19:04:36 -0000 On Nov 7, 2012, at 1:49 PM, Christopher Morrow wrote: >=20 > frankly I'm happy to add comments on the sidr list, or grow list or > you directly... my question perhaps was mis-phrased, I'll try again: >=20 > "Where would you like me (or others) to send comments on this draft?" The authors welcome direct comments, their email addresses are in the = draft :-) -danny= From danny@tcb.net Wed Nov 7 11:06:36 2012 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 AFE7021F8C61 for ; Wed, 7 Nov 2012 11:06:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE3hBIGrKSko for ; Wed, 7 Nov 2012 11:06:36 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4864921F8917 for ; Wed, 7 Nov 2012 11:06:36 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id DD7F8207E for ; Wed, 7 Nov 2012 19:06:35 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 66561206A; Wed, 7 Nov 2012 12:06:35 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 14:06:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 12:06:35 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ab13b199632045914316 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, Subject*route+announcement, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, On+#+7, 0.01000, in+BGP, 0.01000, Subject*today+#+to, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Subject*outage+today, 0.01000, 1+#+PM, 0.01000, 2012+at, 0.01000, Cc*ietf.org+#+#+ietf.org, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, Subject*need+#+SIDR, 0.01000, 7+#+at, 0.01000, Subject*limited+#+#+due, 0.01000, 7+#+#+1, 0.01000, Subject*today+due, 0.01000, Subject*need+#+#+-, 0.01000, Subject*Google+#+#+today, 0.01000, Mime-Version*Apple+#+framework, 0.01000 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 19:06:36 -0000 On Nov 7, 2012, at 1:48 PM, Christopher Morrow wrote: > 1) show/agree that this is a problem (route leaks) Do you believe this is a problem? When describing events such as this = as of late, what did you call it? > 2) see if bgp data already has the right bits to fix this (idr) > 3) slap some verification on those bits Are you presupposing this needs to be done *in* BGP? -danny From shane@castlepoint.net Wed Nov 7 11:15:35 2012 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 6F5CD21F8C82 for ; Wed, 7 Nov 2012 11:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+-WPZjKVm6j for ; Wed, 7 Nov 2012 11:15:35 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 359F221F8A64 for ; Wed, 7 Nov 2012 11:15:32 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 7A5A8207E for ; Wed, 7 Nov 2012 19:15:31 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id CE4D1206A; Wed, 7 Nov 2012 12:15:30 -0700 (MST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Wed, 7 Nov 2012 14:15:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 12:15:31 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ab353199632124914363 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, all+#+#+to, 0.01000, Subject*sidr+#+#+for, 0.01000, the+#+I, 0.01000, Subject*route+announcement, 0.01000, On+#+7, 0.01000, On+#+7, 0.01000, Mime-Version*OS+X, 0.01000, Subject*today+#+to, 0.01000, 11+#+AM, 0.01000, Subject*to+bogus, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, From*Amante+shane, 0.01000, 2012+#+#+#+AM, 0.01000, Subject*outage+today, 0.01000, 1+#+PM, 0.01000, 1+#+PM, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, Mime-Version*Mail+#+1499, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, the+#+#+that, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 19:15:35 -0000 On Nov 7, 2012, at 1:48 PM, Christopher Morrow = wrote: > On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante = wrote: >> Chris, >>=20 >> On Nov 7, 2012, at 11:11 AM, Christopher Morrow = wrote: >>> there isn't data in bgp today data which tells you 'this path is a >>> leak'. Even at the immediately-leaked-to peer there isn't data in = the >>> message that's helpful for this problem. >>=20 >> Why isn't the above considered putting the cart in front of the = horse? Namely, >> there is this (seemingly) hard requirement that all information must = be >> self-contained within BGP -- even though the above acknowledges that >> we CANNOT get this information out from BGP. Shouldn't that suggest = there >> is a pretty fundamental problem here wrt the current definition of = the problem? >=20 > I think if you have only a bgp message to deal with that's all you > have to base your judgement upon. Uhhh ... please tell me how a BGPSEC router, receiving a BGP PDU from = another AS, is supposed to validate a BGPSEC path signature without = relying on *any* offboard systems whatsoever? > The SIDR work so far has added a > signature for origination and in BGPSEC proposes adding signatures as > part of bgpsec-path. Right, and for all that *additional* complexity & fragility it brings in = to the global Internet Routing System it still doesn't solve for route = leaks ... one of the more frequent & pernicious threats to Internet = routing security. Weak sauce. > If you know of, or can create, or can find inexistence already, data > that helps solve the 'route leaks problem' please bring it forward. The problem with the above is your mandating I present a solution for = which, you yourself, acknowledge no such solution exists. If we cannot = accept and move past that, then how can we have a reasonable discussion = on _alternative_ solutions that /are not/ solely in the control plane? > I > think the wgs involved here (at least: sidr, idr, grow) all have > agreed that the first step is: > 1) show/agree that this is a problem (route leaks) > 2) see if bgp data already has the right bits to fix this (idr) > 3) slap some verification on those bits >=20 > arguing about carts and horses isn't moving the above 3 steps forward. The problem is in step #2, above. Specifically, there's an = unwillingness, which I don't understand, to accept that "bgp data may = not contain the right bits to fix this". If we're not willing to admit = we have a problem (at step #2), then step #3 "slap some verification on = those bits" ... is not doing anything to solve that problem, IMO. >> What's even more perplexing is the WG seems to accept that it's OK to >> accept substantial complexity in creating, exchanging, validating = information >> using an "out-of-band" certificate repository system (RPKI) ... which = is OK to >> be used for Origin Validation by BGP, but for some reason ... BGPSEC = is >> saying that it cannot depend on external information sources for Path >> Validation (other than per-router/per-AS certs). Something really = does not >=20 > what external source? Doesn't BGPSEC depend on the RPKI for publishing & retrieving of = per-router/per-AS certs? -shane From Sandra.Murphy@sparta.com Wed Nov 7 11:28:23 2012 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 E0D2821F8825 for ; Wed, 7 Nov 2012 11:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdd3dYQh0+wT for ; Wed, 7 Nov 2012 11:28:23 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98021F8800 for ; Wed, 7 Nov 2012 11:28:22 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA7JSMQO010851; Wed, 7 Nov 2012 11:28:22 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA7JSMTX030584; Wed, 7 Nov 2012 11:28:22 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Wed, 7 Nov 2012 14:28:21 -0500 From: "Murphy, Sandra" To: Danny McPherson Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: Ac28OrfR/Q8DzNS0SPC8tLa/5HdiAQBBRRiA//+teGM= Date: Wed, 7 Nov 2012 19:28:21 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com>, <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> In-Reply-To: <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 19:28:24 -0000 Sure.=0A= =0A= The relying party agreement is available at:=0A= =0A= https://www.arin.net/resources/rpki/rpa.pdf=0A= =0A= My concerns derive from the section PROHIBITED CONDUCT.=0A= =0A= That section says it forbids the relying party (the one retrieving RPKI dat= a from ARIN and validating wrt the ARIN trust anchor) from transferring, gi= ving access to, copying, broadcasting, etc., any "related content". =0A= =0A= I think that could impact the envisioned architecture and dominant use case= s,=0A= =0A= It also forbids "derivative works".=0A= =0A= I think that could impact looking-glass-like or route-views-like public ser= vices, the many different sites that are reporting status and route validit= y, etc, so an impact on operational usability.=0A= =0A= A couple of people have suggested mechanisms that might suit ARIN and minim= ize the impact and might be worth exploring.=0A= =0A= At the ARIN meeting week before last, this was a topic of off-agenda discus= sions. I and others did have a chance to talk to top ARIN staff. So they a= re aware.=0A= =0A= And it is not intended to be a "bash-the-RIR" and certainly not a "-and-for= ce-them-into-submission", since we have no authority over ARIN legal decisi= ons.=0A= =0A= --Sandy=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh= erson [danny@tcb.net]=0A= Sent: Wednesday, November 07, 2012 1:29 PM=0A= To: Murphy, Sandra=0A= Cc: sidr@ietf.org=0A= Subject: Re: [sidr] additions and changes to agenda on Friday=0A= =0A= On Nov 6, 2012, at 12:35 PM, Murphy, Sandra wrote:=0A= >=0A= > I would like to open a discussion with the wg concerning the recently ann= ounced ARIN relying party agreement. I have concerns about this agreement'= s impact on the envisioned RPKI architecture and dominant use. I think the= wg needs to consider the potential impact and any potential mechanisms tha= t would lessen impact. Note that the IETF can not interfere with ARIN lega= l decisions!=0A= =0A= Sandy,=0A= Can you elaborate what your "concerns about this agreement's impact on the = envisioned RPKI architecture and dominant use" are? Do you have a referenc= e or outline we can review prior to the discussion in order to keep this fr= om being a bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy= -this-stuff fest?=0A= =0A= Thanks,=0A= =0A= -danny=0A= =0A= =0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From danny@tcb.net Wed Nov 7 11:32:41 2012 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 CAE5021F8825 for ; Wed, 7 Nov 2012 11:32:41 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWb3z4sN8h1d for ; Wed, 7 Nov 2012 11:32:41 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5030921F8C21 for ; Wed, 7 Nov 2012 11:32:41 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D1A7D207C for ; Wed, 7 Nov 2012 19:32:40 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 89877206A; Wed, 7 Nov 2012 12:32:40 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> Date: Wed, 7 Nov 2012 14:32:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3ED338E7-E21B-4237-BC3F-2FFA171A1C01@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com>, <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 12:32:40 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ab758199631296058641 X-DSPAM-Factors: 27, On+#+7, 0.01000, wrote+I, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+at, 0.01000, PM+#+#+#+I, 0.01000, at+#+#+PM, 0.01000, 7+#+at, 0.01000, Mime-Version*Apple+#+framework, 0.01000, to+#+a, 0.01000, is+#+#+to, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, the+#+for, 0.01000, Mime-Version*1.0+#+Message, 0.01000, I+think, 0.01000, on+the, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, 2012+#+#+#+PM, 0.01000, might+be, 0.01000, those+#+the, 0.01000, Subject*Re+sidr, 0.01000, Mime-Version*1.0+#+#+framework, 0.01000, From*Danny+McPherson, 0.01000, Nov+7, 0.01000, Mime-Version*1.0+#+#+#+v1283, 0.01000 Cc: "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 19:32:41 -0000 On Nov 7, 2012, at 2:28 PM, Murphy, Sandra wrote: >=20 > I think that could impact the envisioned architecture and dominant use = cases, Agreed! > A couple of people have suggested mechanisms that might suit ARIN and = minimize the impact and might be worth exploring. Can you (or those folks) share those on the list for consideration? > And it is not intended to be a "bash-the-RIR" and certainly not a = "-and-force-them-into-submission", since we have no authority over ARIN = legal decisions. Good, thanks! -danny= From jakob.heitz@ericsson.com Wed Nov 7 12:04:30 2012 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 3AACD21F8C89 for ; Wed, 7 Nov 2012 12:04:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elko29JbH80i for ; Wed, 7 Nov 2012 12:04:29 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BD1D121F889E for ; Wed, 7 Nov 2012 12:04:29 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA7K9ZVL015759; Wed, 7 Nov 2012 14:09:37 -0600 Received: from EUSAAHC001.ericsson.se (147.117.188.75) by eusaamw0711.eamcs.ericsson.se (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 7 Nov 2012 15:04:21 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 15:04:21 -0500 From: Jakob Heitz To: Shane Amante , Christopher Morrow Thread-Topic: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement Thread-Index: AQHNvRxK8pXMngI7GkKIrAvqAUM7cJfextGg Date: Wed, 7 Nov 2012 20:04:20 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E0D165C@EUSAAMB109.ericsson.se> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> In-Reply-To: <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 20:04:30 -0000 Wasn't there a proposal along the lines of: Create an attribute that says: "I authorize you to announce this route to your provider" The originator and all transited ASes must sign it. Any AS can remove it. If you receive an update without it (but with a bgpsec) from a customer or peer, then human intervention is required before accepting it. This way, human intervention occurs before the problem, not after. What happened to that proposal? Was it Brian Dickson? -- Jakob Heitz.= From christopher.morrow@gmail.com Wed Nov 7 12:52:58 2012 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 AB28D21F8C27 for ; Wed, 7 Nov 2012 12:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y5HXvHdYFjg for ; Wed, 7 Nov 2012 12:52:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2D3C21F8C3E for ; Wed, 7 Nov 2012 12:52:57 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1329946eek.31 for ; Wed, 07 Nov 2012 12:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=URlDM7T8aN00TPFvFSzXlimMjt9UNQJ86cN+GLuUO0g=; b=A4KQV0fGVxEXXcH/VFNXilye19VGhYto178rPgtAZuNiyTcRa38wGLj6c2wwcigtnN ZjEwBKeGXtcCQE5W8U3omVd+tjrR9woDMhqzaeKGUr64R0AOzKARCllc52NahVKhJRug +/O0z1VL1/ocpeP/bHKtjTozjz7QACKaLK8hoKeoZdZMfIONtRdfH2S0X8lVVSdJ/I+/ DQN4zQF1HSB12d7/YkjBKyLCsOH39v4FcF/F5w6wQ7fnrb821ZF4hTLhGBz0c+F+vt2e Dhkp4iommK20m+3lvshi74rRHLlU03W1H8zed2/1s5S+BD3OBLxY4QZDQjk9zMgQOmCo kDOw== MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr19325596eem.42.1352321575544; Wed, 07 Nov 2012 12:52:55 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 12:52:55 -0800 (PST) In-Reply-To: <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> Date: Wed, 7 Nov 2012 15:52:55 -0500 X-Google-Sender-Auth: 8SDbtNTQoc981-eIw3NKP4z902A Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 20:52:58 -0000 (aside: ugh, your mail client doesn't wrap lines properly... or gmail isn't re-wrapping properly) On Wed, Nov 7, 2012 at 2:02 PM, Danny McPherson wrote: > > On Nov 7, 2012, at 1:42 PM, Christopher Morrow wrote: > >> The draft you reference up-thread isn't actually helpful, it doesn't >> show how to know that the leak is a leak and not another backup path >> coming to light for other reasons in the system. > > The fact that even folks here were confused where RPKI/BGPSEC would be > helpful and would NOT highlights the disconnect about what problems they're > trying to solve for us in SIDR. The draft was written as an attempt to help > minimize confusion and it may have missed the mark but I'm told some have > found it helpful. > > How about this: "We need a way to show how to know that the leak is a > leak and not another backup path coming to light for other reasons in the > system" (that might sound familiar :-). The solution doesn't presuppose > it's codified in BGP on the wire, and shouldn't preclude simply improving > existing tooling and systems, of which many operators already employ > (e.g., IRRs and static [persistent] AS path and prefix lists). sure, with resource certification in place (rpki?) you can go fix up irr data and go to town. that'd solve the problem, provided people actually filter. evidence suggests they don't... and won't no matter how 'simple' it seems. could we have something in the protocol to do this for us as well? for the cases of the operators who don't filter or won't filter or can't filter or ? could we have something in the protocol to tell a remote asn if this is a leak or not? not putting it in bgp is ok, but it seems like that limits things a bit, no? > With the hyper-focus on publication of standard-based RPKI/BGPSEC in > this WG I do concur that it's likely not the right place. However, I would note > that if I can solve most of the real problems above without BGP changes or > any new systems then I may not need RPKI/BGPSEC work at all. That you'd need rpki, or resource-certification, which is all rpki is... right? I don't think any 'make better filters' solution works without resource certification. > said, I would hate to see SIDR be Standards-Track and "legislated" and not > solve problems as fundamental as this, while the lower hanging fruit is > steam-rolled by efforts here. -chris From christopher.morrow@gmail.com Wed Nov 7 12:53:28 2012 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 6A4FD21F89B3 for ; Wed, 7 Nov 2012 12:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3Q+Vok5CA4m for ; Wed, 7 Nov 2012 12:53:28 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D068421F879E for ; Wed, 7 Nov 2012 12:53:26 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1329946eek.31 for ; Wed, 07 Nov 2012 12:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TDh2wZqLvTuzOrTUe1lGkGT9FnKxt8ri6ZaRhbL7vcM=; b=GFD5qZk/iEis50yvhT2WbN7o8Qv7h9z6LlEw1JlBjrOlRgunWvjCy45EMKRZ4q5gih iBEF90UlpEI7b9QFN01DBJ/RuP2c1ketentoVx7UVTanorNbGhxGVi2C0+AURbRJkpGk RaCNeXckPePzw0fDnHIHdGypc/tGWnt0QGnGp4g6dn4n0VEn19rrOsQZ2uEwDi++nOWe NFoycBBTcjIuBHytHQj3OX8mIAP3VR6A1EAM7524ul6T/Li3MIn9k404MFINWyOimPf9 0uFZANFr+OtWsLbk7UpvpiSFp3yGIkXgioHj18PgQO7i1R8HbUpihyJFU8ISrERMZJQQ 6KBA== MIME-Version: 1.0 Received: by 10.14.184.1 with SMTP id r1mr19653138eem.4.1352321606551; Wed, 07 Nov 2012 12:53:26 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 12:53:26 -0800 (PST) In-Reply-To: <21AE3435-84EE-4F3C-9A52-B8F930FEA336@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <8616D617-74B3-442D-BFBE-C20D34CBB227@tcb.net> <21AE3435-84EE-4F3C-9A52-B8F930FEA336@tcb.net> Date: Wed, 7 Nov 2012 15:53:26 -0500 X-Google-Sender-Auth: kO1pyQPk6svHwbILywYsjgcKRVk Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 20:53:28 -0000 On Wed, Nov 7, 2012 at 2:04 PM, Danny McPherson wrote: > > On Nov 7, 2012, at 1:49 PM, Christopher Morrow wrote: >> >> frankly I'm happy to add comments on the sidr list, or grow list or >> you directly... my question perhaps was mis-phrased, I'll try again: >> >> "Where would you like me (or others) to send comments on this draft?" > > The authors welcome direct comments, their email addresses are in the draft :-) great, also there's: I think... From christopher.morrow@gmail.com Wed Nov 7 12:56:35 2012 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 56B2221F8A59 for ; Wed, 7 Nov 2012 12:56:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR0g+NpG6SDv for ; Wed, 7 Nov 2012 12:56:34 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 360E921F89B3 for ; Wed, 7 Nov 2012 12:56:34 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so900660eaa.31 for ; Wed, 07 Nov 2012 12:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=usb+Fc/5kUXQJJvC3jgChL178qUYuKFfJTs/0ogwS2s=; b=QdKsp2ojjQU7XbM1u+/L5ljJUAgn7/x0IIjI4l74HLbusprHLfe+FulycAp7M+NZT7 HoB8qJ8KjlLB4zzvnDb44g42zB0dUN6CRz6XqYUFrwRL+UlACJQlS4JA8vph3j6PBs+H hBtERk4SL8msMr1lTHHbZt971Wpb5k0/vdhAiCJA4UlVrJCATsgqC4VKfwzPgSB+REV0 eFfxKcT9TmEDKKBhnm1v3Mr0vDt+fI7vrMB0ELIe9lltGkVrdLWcu0D7mjMQYLp53NTE 6ivC29WMLZLoF3WP9z2Us3gAecEam/8+1SZzoUskkymSkHYBzM8PodQ8u/pvaijdfDIb e98w== MIME-Version: 1.0 Received: by 10.14.182.9 with SMTP id n9mr19517173eem.24.1352321793246; Wed, 07 Nov 2012 12:56:33 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 12:56:33 -0800 (PST) In-Reply-To: <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> Date: Wed, 7 Nov 2012 15:56:33 -0500 X-Google-Sender-Auth: cMRd9tcA5qXSzMUXt2XDoGWR_AU Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 20:56:35 -0000 On Wed, Nov 7, 2012 at 2:06 PM, Danny McPherson wrote: > > On Nov 7, 2012, at 1:48 PM, Christopher Morrow wrote: > >> 1) show/agree that this is a problem (route leaks) > > Do you believe this is a problem? When describing events such as this as > of late, what did you call it? sure, but I'm not the grow-wg ... right? aim that question over -> there. >> 2) see if bgp data already has the right bits to fix this (idr) >> 3) slap some verification on those bits > > Are you presupposing this needs to be done *in* BGP? > I'm not presupposing, I'm saying that today you CAN do what you want with IRR data, some folks do this with varying degrees of success/failure. you could improve this with RPKI (or resource certification)... you'd still be limited to those folks who do filtering to begin with. You might pickup more filterers with 'more simpler filteringz', but that's a gamble. If you want to be closer to a solution, do it in the protocol that sends the data around, tag the route with a bit(s) that say: "customer" or "provider" or "transit" or "jimmyhat" ... sign that bit(s) and let's march on. -chris From christopher.morrow@gmail.com Wed Nov 7 13:11:43 2012 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 5672A21F8C59 for ; Wed, 7 Nov 2012 13:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyGoIEuE89Lj for ; Wed, 7 Nov 2012 13:11:42 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5D21F8C48 for ; Wed, 7 Nov 2012 13:11:41 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1338914eek.31 for ; Wed, 07 Nov 2012 13:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=liiul+dv/f5iRwhUXlbGMm/SgacyofFTJGbz2IeWSh0=; b=VCVOBDJb7sqJRym1nSOAiCozItlKQZm01QizPn63pcxiOhjTty7X5xI6cz+4H3evC5 s0Rp10e4YZpESHaazEz8uqPEcCwjR3Y0OhQAvJkw6rorF7I94aqDwQQsKeEvbsJcEcFf PUfBIYTFooP+9+YwKLgpTJIGSDh3idqr01ihN/ye3+M9E9mWCH+F9mCKVYlX5hNCIH3J fR3X/hC+DGJEiAN9IEyzvE6+WO3Jp8JEcFuU45R01WSLfTapHOgfX0B8qxjhb+sPzJn/ m91mtzq8ISj0v3iZ3a8UhFLhDrt+1AYYSPLn6Dkd4WmpWDttsSi13tOCX0wYZqFZskC3 Mxyg== MIME-Version: 1.0 Received: by 10.14.184.1 with SMTP id r1mr19806115eem.4.1352322701215; Wed, 07 Nov 2012 13:11:41 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 13:11:41 -0800 (PST) In-Reply-To: <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> Date: Wed, 7 Nov 2012 16:11:41 -0500 X-Google-Sender-Auth: ydoRBlCf7SM-iAESV9RFs5SQxf0 Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 21:11:43 -0000 (also, your mail client is not wrapping properly) On Wed, Nov 7, 2012 at 2:15 PM, Shane Amante wrote: > > On Nov 7, 2012, at 1:48 PM, Christopher Morrow wrote: >> On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante wrote: >>> Chris, >>> >>> On Nov 7, 2012, at 11:11 AM, Christopher Morrow wrote: >>>> there isn't data in bgp today data which tells you 'this path is a >>>> leak'. Even at the immediately-leaked-to peer there isn't data in the >>>> message that's helpful for this problem. >>> >>> Why isn't the above considered putting the cart in front of the horse? Namely, >>> there is this (seemingly) hard requirement that all information must be >>> self-contained within BGP -- even though the above acknowledges that >>> we CANNOT get this information out from BGP. Shouldn't that suggest there >>> is a pretty fundamental problem here wrt the current definition of the problem? >> >> I think if you have only a bgp message to deal with that's all you >> have to base your judgement upon. > > Uhhh ... please tell me how a BGPSEC router, receiving a BGP PDU from another > AS, is supposed to validate a BGPSEC path signature without relying on *any* > offboard systems whatsoever? > how does your browser verify the ssl certificate on your webserver? > >> The SIDR work so far has added a >> signature for origination and in BGPSEC proposes adding signatures as >> part of bgpsec-path. > > Right, and for all that *additional* complexity & fragility it brings in to the > global Internet Routing System it still doesn't solve for route leaks ... one if you don't want to do the bgpsec on your network, as an operator you certainly have that choice. If you already filter customer routes (or solve the route-leaks problem in another way) cool, you're probably done? > of the more frequent & pernicious threats to Internet routing security. Weak > sauce. again, propose a solution. I don't think anyone has said 'we do not want to listen to your problem', in fact many people have said: "yes, its a problem, provide a solution". also, resource-certification helps get to a filtering solution of more worth/merit... so that's nice, and isn't more goop on routers or in bgp... so, win? >> If you know of, or can create, or can find inexistence already, data >> that helps solve the 'route leaks problem' please bring it forward. > > The problem with the above is your mandating I present a solution for which, > you yourself, acknowledge no such solution exists. If we cannot accept and have you read brian's 3 drafts, do they help? are they a start to helping? is it off-base? also, I'm not really mandating anything... I'm just chatting. > move past that, then how can we have a reasonable discussion on > _alternative_ solutions that /are not/ solely in the control plane? said several times, added here again: "if you want only to filter routes with the equivalent of prefix-list + irr data, great!" resource certification (rpki) seems like it will help to clean up the filter data better/faster/cleaner than what's in the IRR today. it's not in bgp, it's not in the control-plane... hurray. if you don't think everyone will do filtering tomorrow (we already know they don't today) then we probably should think outside the static filtering realm. >> I >> think the wgs involved here (at least: sidr, idr, grow) all have >> agreed that the first step is: >> 1) show/agree that this is a problem (route leaks) >> 2) see if bgp data already has the right bits to fix this (idr) >> 3) slap some verification on those bits >> >> arguing about carts and horses isn't moving the above 3 steps forward. > > The problem is in step #2, above. Specifically, there's an unwillingness, which > I don't understand, to accept that "bgp data may not contain the right bits to fix > this". If we're not willing to admit we have a problem (at step #2), then step what? isn't that what #2 says? I only outlined the steps forward as agreed upon by the wg and chairs in the affected wgs... maybe I misunderstood your question/point or ? > #3 "slap some verification on those bits" ... is not doing anything to solve > that problem, IMO. > >>> What's even more perplexing is the WG seems to accept that it's OK to >>> accept substantial complexity in creating, exchanging, validating information >>> using an "out-of-band" certificate repository system (RPKI) ... which is OK to >>> be used for Origin Validation by BGP, but for some reason ... BGPSEC is >>> saying that it cannot depend on external information sources for Path >>> Validation (other than per-router/per-AS certs). Something really does not >> >> what external source? > > Doesn't BGPSEC depend on the RPKI for publishing & retrieving of > per-router/per-AS certs? I think techically rpki is just the jumble of certificate data and roas that talk about: o prefixes and ownership (right to use) o as ownerships/right-to-use o origination-information for prefixes/subprefixes (roas) if you just want to 'solve' route-leaks, and you want to do that with filters, you don't need to do anything to bgp. -chris From christopher.morrow@gmail.com Wed Nov 7 13:13:46 2012 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 C3A3D21F8B16 for ; Wed, 7 Nov 2012 13:13:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1scQVYmNDlN for ; Wed, 7 Nov 2012 13:13:46 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3EFE21F8B12 for ; Wed, 7 Nov 2012 13:13:45 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so906721eaa.31 for ; Wed, 07 Nov 2012 13:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ahJzLPNJ7WS0xQ48ZaXgItvOG6ftgQHsGC4KusQuyrI=; b=B/ysMrrD5j7pgGMYuqxULvEnNZU/u5EjDb9GP8onY/5ytZZe9JCT4tbMAZ+e23wuei 8QF5Vy8zFEsgoaWX+rjctihTZtLx66p5B77qDPwnLytnTVSBDISgoHKgouANoiSZj5g5 4hQzIqIRavLpHEfAqT2Tj2JKum/H9aa3Cf5rVl1o+A0YqokzS1EVXGwTOmhokcrCY/UH 8P5NkP/7lIYB+NvkEmACZDpHYyS0Exrt42zZJF4pTBDElqm6ay1Xcsm4HT8Anfto5q5/ FIsfh6E4gMIvhabmhUR+NAV/HN9lfzGis70GSDeqeRaURIkrGqNxRleKJ01ndiGd2b1T Nm9w== MIME-Version: 1.0 Received: by 10.14.172.195 with SMTP id t43mr19732856eel.17.1352322825111; Wed, 07 Nov 2012 13:13:45 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 13:13:45 -0800 (PST) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E0D165C@EUSAAMB109.ericsson.se> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <2F3EBB88EC3A454AAB08915FBF0B8C7E0D165C@EUSAAMB109.ericsson.se> Date: Wed, 7 Nov 2012 16:13:45 -0500 X-Google-Sender-Auth: lwHNVEsRHC1jq3MCc-4WXFhuKqU Message-ID: From: Christopher Morrow To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 21:13:46 -0000 On Wed, Nov 7, 2012 at 3:04 PM, Jakob Heitz wrote: > Wasn't there a proposal along the lines of: > > Create an attribute that says: > "I authorize you to announce this route to your provider" I think it was some form of 'bit for transit' and 'bit for customer' ... but sure. > The originator and all transited ASes must sign it. > Any AS can remove it. > If you receive an update without it (but with a bgpsec) > from a customer or peer, then human intervention > is required before accepting it. > This way, human intervention occurs before the problem, not after. I think the proposal was to mark the route as 'bad' and then decide to do somethign with it (or not... say lower-local-pref/med/etc or discard/reject/drop - let the local operator decide what to do with that class of problem) > What happened to that proposal? awaiting updates/edits/etc.. and I think moved from sidr to idr, notionally at least. > Was it Brian Dickson? > think so, yes. > -- > Jakob Heitz. From danny@tcb.net Wed Nov 7 13:22:47 2012 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 4798C21F89A1 for ; Wed, 7 Nov 2012 13:22:47 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HENPQcyRFewK for ; Wed, 7 Nov 2012 13:22:46 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id D32AF21F8889 for ; Wed, 7 Nov 2012 13:22:46 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id CCC762089 for ; Wed, 7 Nov 2012 21:22:42 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 9E938206A for ; Wed, 7 Nov 2012 14:22:42 -0700 (MST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 16:22:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 14:22:42 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ad122199631562211239 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, Subject*route+announcement, 0.01000, I+agree, 0.01000, Subject*today+#+to, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Subject*outage+today, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, Subject*need+#+SIDR, 0.01000, To*list+#+ietf.org, 0.01000, Subject*limited+#+#+due, 0.01000, of+#+#+#+there, 0.01000, Subject*today+due, 0.01000, Subject*need+#+#+-, 0.01000, Subject*Google+#+#+today, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Subject*bogus+#+announcement, 0.01000, Subject*Re+#+#+need, 0.01000, Subject*for+#+-, 0.01000, Subject*sidr+The, 0.01000, Subject*The+#+#+SIDR, 0.01000, Subject*SIDR+#+#+#+outage, 0.01000 Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 21:22:47 -0000 > you'd need rpki, or resource-certification, which is all rpki is... = right? No, there's lots of other stuff in there.. > I don't think any 'make better filters' solution works without = resource certification. I agree.. -danny= From Donald.Smith@CenturyLink.com Wed Nov 7 13:28:28 2012 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 4914B21F8B22 for ; Wed, 7 Nov 2012 13:28:28 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KscxcD4+Ba0q for ; Wed, 7 Nov 2012 13:28:27 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id B5A3621F892B for ; Wed, 7 Nov 2012 13:28:27 -0800 (PST) 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 qA7LSQeK014004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 15:28:26 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id E6C711E0060; Wed, 7 Nov 2012 14:28:20 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id B181D1E0053; Wed, 7 Nov 2012 14:28:20 -0700 (MST) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id qA7LSKOq021922; Wed, 7 Nov 2012 15:28:20 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id qA7LSJEM021883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 15:28:19 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 14:28:19 -0700 From: "Smith, Donald" To: "'Christopher Morrow'" , "'Danny McPherson'" Thread-Topic: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement Thread-Index: AQHNvSnzbOhtdFetckiPCIExSnnC0pfe4xGQ Date: Wed, 7 Nov 2012 21:28:18 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A25E492@PDDCWMBXEX503.ctl.intranet> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <8616D617-74B3-442D-BFBE-C20D34CBB227@tcb.net> <21AE3435-84EE-4F3C-9A52-B8F930FEA336@tcb.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'sidr@ietf.org list'" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 21:28:28 -0000 Doesn't look like we missed that much. A few of the talks may have been int= eresting but most were buy our product based on whom was presenting and wha= t their subject matter was:) "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >Christopher Morrow >Sent: Wednesday, November 07, 2012 1:53 PM >To: Danny McPherson >Cc: sidr@ietf.org list >Subject: Re: [sidr] The need for SIDR - Google limited outage today due >to bogus route announcement > >On Wed, Nov 7, 2012 at 2:04 PM, Danny McPherson wrote: >> >> On Nov 7, 2012, at 1:49 PM, Christopher Morrow wrote: >>> >>> frankly I'm happy to add comments on the sidr list, or grow list or >>> you directly... my question perhaps was mis-phrased, I'll try again: >>> >>> "Where would you like me (or others) to send comments on this draft?" >> >> The authors welcome direct comments, their email addresses are in the >draft :-) > >great, also there's: > >I think... >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From Donald.Smith@CenturyLink.com Wed Nov 7 13:29:23 2012 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 B51C921F8B4D for ; Wed, 7 Nov 2012 13:29:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHw+gSzWrJWS for ; Wed, 7 Nov 2012 13:29:23 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 221DA21F892B for ; Wed, 7 Nov 2012 13:29:23 -0800 (PST) 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 qA7LTLH6014449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 15:29:22 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A129A1E004D; Wed, 7 Nov 2012 14:29:16 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 6DA391E0071; Wed, 7 Nov 2012 14:29:16 -0700 (MST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id qA7LTFVf004731; Wed, 7 Nov 2012 15:29:15 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id qA7LTEdS004699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 15:29:15 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 14:29:14 -0700 From: "Smith, Donald" To: "Smith, Donald" , "'Christopher Morrow'" , "'Danny McPherson'" Thread-Topic: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement Thread-Index: AQHNvSnzbOhtdFetckiPCIExSnnC0pfe4xGQgAAAWIA= Date: Wed, 7 Nov 2012 21:29:14 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A25E4A5@PDDCWMBXEX503.ctl.intranet> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <8616D617-74B3-442D-BFBE-C20D34CBB227@tcb.net> <21AE3435-84EE-4F3C-9A52-B8F930FEA336@tcb.net> <68EFACB32CF4464298EA2779B058889D0A25E48D@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A25E48D@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'sidr@ietf.org list'" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 21:29:23 -0000 Sorry wrong list:( "Pampers use multiple layers of protection to prevent leakage. Rommel used = defense in depth to defend European fortresses." (A.White) Donald.Smith@Cen= turyLink.com >-----Original Message----- >From: Smith, Donald >Sent: Wednesday, November 07, 2012 2:28 PM >To: 'Christopher Morrow'; 'Danny McPherson' >Cc: 'sidr@ietf.org list' >Subject: RE: [sidr] The need for SIDR - Google limited outage today due >to bogus route announcement > >Doesn't look like we missed that much. A few of the talks may have been >interesting but most were buy our product based on whom was presenting >and what their subject matter was:) > > >"Pampers use multiple layers of protection to prevent leakage. Rommel >used defense in depth to defend European fortresses." (A.White) >Donald.Smith@CenturyLink.com > > >>-----Original Message----- >>From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >>Christopher Morrow >>Sent: Wednesday, November 07, 2012 1:53 PM >>To: Danny McPherson >>Cc: sidr@ietf.org list >>Subject: Re: [sidr] The need for SIDR - Google limited outage today due >>to bogus route announcement >> >>On Wed, Nov 7, 2012 at 2:04 PM, Danny McPherson wrote: >>> >>> On Nov 7, 2012, at 1:49 PM, Christopher Morrow wrote: >>>> >>>> frankly I'm happy to add comments on the sidr list, or grow list or >>>> you directly... my question perhaps was mis-phrased, I'll try again: >>>> >>>> "Where would you like me (or others) to send comments on this >draft?" >>> >>> The authors welcome direct comments, their email addresses are in the >>draft :-) >> >>great, also there's: >>help@tools.ietf.org> >>I think... >>_______________________________________________ >>sidr mailing list >>sidr@ietf.org >>https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Wed Nov 7 13:37:49 2012 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 10C6121F8BB1 for ; Wed, 7 Nov 2012 13:37:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKKewp2U3vfa for ; Wed, 7 Nov 2012 13:37:48 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5EB21F8B35 for ; Wed, 7 Nov 2012 13:37:48 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 01C5F2089 for ; Wed, 7 Nov 2012 21:37:47 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B9C62206A for ; Wed, 7 Nov 2012 14:37:47 -0700 (MST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 16:37:55 -0500 Content-Transfer-Encoding: 7bit Message-Id: <8031E4EF-B42E-46C1-8249-FD0FB5918BD4@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 14:37:47 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ad4ab199631826513885 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, to+#+the, 0.01000, Subject*route+announcement, 0.01000, On+#+7, 0.01000, Subject*today+#+to, 0.01000, with+#+#+of, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Subject*outage+today, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, Subject*need+#+SIDR, 0.01000, To*list+#+ietf.org, 0.01000, the+#+#+a, 0.01000, 7+#+at, 0.01000, Subject*limited+#+#+due, 0.01000, Subject*today+due, 0.01000, Subject*need+#+#+-, 0.01000, Subject*Google+#+#+today, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Subject*bogus+#+announcement, 0.01000 Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 21:37:49 -0000 On Nov 7, 2012, at 3:56 PM, Christopher Morrow wrote: > I'm not presupposing, I'm saying that today you CAN do what you want > with IRR data, some folks do this with varying degrees of > success/failure. you could improve this with RPKI (or resource > certification)... you'd still be limited to those folks who do > filtering to begin with. You might pickup more filterers with 'more > simpler filteringz', but that's a gamble. But forcing BGPSEC/RPKI on everyone is better? Ohh, and you still have to solve the IRR-esque problem. And the RPKI/BGPSEC steamroller is squashing low-hanging fruit. > If you want to be closer to a solution, do it in the protocol that > sends the data around, tag the route with a bit(s) that say: > "customer" or "provider" or "transit" or "jimmyhat" ... sign that > bit(s) and let's march on. Right, that's the disconnect. IF you start with solving this IN BGP, you end up here [sidr]. -danny From christopher.morrow@gmail.com Wed Nov 7 14:27:18 2012 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 7F05621F8443 for ; Wed, 7 Nov 2012 14:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gehOp6CaHvh6 for ; Wed, 7 Nov 2012 14:27:17 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5086521F8458 for ; Wed, 7 Nov 2012 14:00:32 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1363557eek.31 for ; Wed, 07 Nov 2012 14:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PIZebUapl6GzDsB5qQe3804OzubJmv4YvKGUFZCf2zs=; b=tbGYR/0vDQRixSZlyRZMiCdKb6wnsy7LQMyEPHHOlA4S1nTHAjYNlXm9hpT8xd0cXN IEOCavgMnm1ktbsQUHTZfh71JNM0hOZh/rXFTA5r+ZkR0uQFnl9oKwmR1jq5cBbIV6+d 9UANJjehv4oYaj3h5a4k52HgqFWZOVmWScqJeWP76+9pe/kJB5+V+0RoCHZzMcFJ/wu6 u/LL8hsf8wj+sezsLz9ngFGPOjVHpBz7XeoD2n6Kp+V5lHP6G8eawdgqKeJEdHm//CZX jBHGRQlAoIVack57PkrhgAJOkAumvwZWVbmid1kUkcq30eypzhCrCbImKN7cLBWu/K9g BgpA== MIME-Version: 1.0 Received: by 10.14.199.134 with SMTP id x6mr20029659een.31.1352325631303; Wed, 07 Nov 2012 14:00:31 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 14:00:31 -0800 (PST) In-Reply-To: <8031E4EF-B42E-46C1-8249-FD0FB5918BD4@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> <8031E4EF-B42E-46C1-8249-FD0FB5918BD4@tcb.net> Date: Wed, 7 Nov 2012 17:00:31 -0500 X-Google-Sender-Auth: yhk6IJJJcIIfRb-CfCxn1SPzo4A Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 22:27:18 -0000 On Wed, Nov 7, 2012 at 4:37 PM, Danny McPherson wrote: > > On Nov 7, 2012, at 3:56 PM, Christopher Morrow wrote: > >> I'm not presupposing, I'm saying that today you CAN do what you want >> with IRR data, some folks do this with varying degrees of >> success/failure. you could improve this with RPKI (or resource >> certification)... you'd still be limited to those folks who do >> filtering to begin with. You might pickup more filterers with 'more >> simpler filteringz', but that's a gamble. > > But forcing BGPSEC/RPKI on everyone is better? no one is forcing bgpsec on people... this is a market economy, people have to see the benefit and agree to use it. > Ohh, and you still have to solve the IRR-esque problem. > ideally, in my world view, I can wrap my IRR lookup: $ whois -h whois.radb.net -K -i mnt-by 'MAINT-AS15169' | head Warning: RIPE flags used with a traditional server. aut-num: AS15169 route: 208.68.108.0/22 origin: AS11344 and wrap that in some resource certification verification... then output prefix-lists. > And the RPKI/BGPSEC steamroller is squashing low-hanging fruit. > which low-hanging fruit? the 'you can make prefix-lists' one? or ? >> If you want to be closer to a solution, do it in the protocol that >> sends the data around, tag the route with a bit(s) that say: >> "customer" or "provider" or "transit" or "jimmyhat" ... sign that >> bit(s) and let's march on. > > Right, that's the disconnect. > > IF you start with solving this IN BGP, you end up here [sidr]. the work here didn't pre-suppose a solution in bgp itself... but there's not much space outside of bgp if you need to solve the leaking problem. it's fairly apparent that folk just don't deploy prefix filters at-all/reliably/updated/etc. if there's a way not in bgp and without resource-certification (rpki data) to stop leaks it'd be great to talk about that. So far I've not heard an answer, I've heard a lot of mish/mash but no 'how about X?' SIDR has worked on a few things, one of which is RPKI, which is really just 'resource certification'. It's added to that the idea that you could verify the origin of a route you hear, and later that the originator could sign the outgoing route such that folk down the line could say: "Yes, that really did originate from FOO-AS". Later/now it's trying to say that the other portion of the path (other than origin) could be verified so you believe the path as you see it is the path the route followed to get to you. -chris From randy@psg.com Wed Nov 7 14:43:55 2012 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 965D721F8441 for ; Wed, 7 Nov 2012 14:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHSppR+tyOJh for ; Wed, 7 Nov 2012 14:43:55 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85021F843A for ; Wed, 7 Nov 2012 14:43:55 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWELi-000CgB-CC; Wed, 07 Nov 2012 22:43:54 +0000 Date: Thu, 08 Nov 2012 07:43:53 +0900 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 22:43:55 -0000 > How about this: "We need a way to show how to know that the leak is a > leak and not another backup path coming to light for other reasons in > the system" (that might sound familiar :-). yes it does. what is not familiar is any actual proposed engineering approach to solve it beyond brian dickson's drafts. and i was hoping those would be updated and discussed. what i see instead is a bunch of noise about process and "it need not be in X." i simply do not have the spare time for that. i would deeply love to hear actual proposed solution(s). randy From eosterweil@verisign.com Wed Nov 7 14:47:23 2012 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 C0AD421F8481 for ; Wed, 7 Nov 2012 14:47:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTPFHaShYGSr for ; Wed, 7 Nov 2012 14:47:23 -0800 (PST) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3221F8441 for ; Wed, 7 Nov 2012 14:47:22 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUJrk991Jj7btB/XnHRfv6FSyMMurGPgH@postini.com; Wed, 07 Nov 2012 14:47:22 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA7MlF5H002258; Wed, 7 Nov 2012 17:47:19 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.236]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 17:47:15 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 7 Nov 2012 17:47:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Nov 2012 22:47:15.0616 (UTC) FILETIME=[D57D5A00:01CDBD39] Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 22:47:23 -0000 On Nov 7, 2012, at 4:11 PM, Christopher Morrow wrote: > (also, your mail client is not wrapping properly) How's my client treatin' ya? :-P >=20 > On Wed, Nov 7, 2012 at 2:15 PM, Shane Amante = wrote: >>=20 >> On Nov 7, 2012, at 1:48 PM, Christopher Morrow = wrote: >>> On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante = wrote: > how does your browser verify the ssl certificate on your webserver? I can take a whack at that: not well? I think DigiNotar helped to = illustrate some of the dangers here... Just sayin... ;) > again, propose a solution. I don't think anyone has said 'we do not > want to listen to your problem', in fact many people have said: "yes, > its a problem, provide a solution". The offer to provide input to the threats and requirements docs is a = genuine attempt to help. For real! :) I have the sneaking suspicion = that this week's... err, event... cost some people some sleep. I feel = like we _should_ be addressing it, no? >=20 > also, resource-certification helps get to a filtering solution of more > worth/merit... so that's nice, and isn't more goop on routers or in > bgp... so, win? I agree that resource certification is a critical component. > if you don't think everyone will do filtering tomorrow (we already > know they don't today) then we probably should think outside the > static filtering realm. But couldn't we also claim that they won't do any next-gen anything = tomorrow (rpki/bgpsec)? In that sense, wouldn't the above comment be a = bit pedantic statement? > what? isn't that what #2 says? I only outlined the steps forward as > agreed upon by the wg and chairs in the affected wgs... maybe I > misunderstood your question/point or ? I think I read in Shane's response that the idea that bits should be = added to BGP is false logic. The fact that these bits are not in BGP = today, does not mean they should be put there tomorrow. My 0.02 is that = there seem to be enough complexities in the policy semantics that the = amount of effort needed to get the minimum level of expressiveness into = BGP could be a non-starter... Just my 0.02... >> Doesn't BGPSEC depend on the RPKI for publishing & retrieving of >> per-router/per-AS certs? >=20 > I think techically rpki is just the jumble of certificate data and > roas that talk about: > o prefixes and ownership (right to use) > o as ownerships/right-to-use > o origination-information for prefixes/subprefixes (roas) I think there's a very complicated replication and fetching hierarchy = too. afaict, there is a huge amount of evaluation left to do just to = illustrate the scaling properties and systemic dependencies of the = substrate that serves these objects of the rpki... Well, we've seen = some surprising complexity and worrisome performance curves in our = preliminary evaluations and simulations. In short, I think the above = misses some of the issues. > if you just want to 'solve' route-leaks, and you want to do that with > filters, you don't need to do anything to bgp. What are we (as a wg) trying to solve? I.e. shouldn't we be talking = about threats and requirements? Eric= From danny@tcb.net Wed Nov 7 14:54:39 2012 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 57ED321F8582 for ; Wed, 7 Nov 2012 14:54:39 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYyfaxFKQ-a3 for ; Wed, 7 Nov 2012 14:54:39 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id DF9DE21F853B for ; Wed, 7 Nov 2012 14:54:38 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 740942099 for ; Wed, 7 Nov 2012 22:54:38 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 2722F206A; Wed, 7 Nov 2012 15:54:38 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 17:54:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> To: Randy Bush , sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 15:54:38 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ae6ae199631312667770 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, Subject*route+announcement, 0.01000, On+#+7, 0.01000, the+leak, 0.01000, Subject*today+#+to, 0.01000, not+be, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Subject*outage+today, 0.01000, 5+#+PM, 0.01000, To*wg+#+sidr, 0.01000, that+#+#+is, 0.01000, a+#+to, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, at+5, 0.01000, Subject*need+#+SIDR, 0.01000, To*list+#+ietf.org, 0.01000, the+#+#+a, 0.01000, 7+#+at, 0.01000 Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 22:54:39 -0000 On Nov 7, 2012, at 5:43 PM, Randy Bush wrote: >> How about this: "We need a way to show how to know that the leak is a >> leak and not another backup path coming to light for other reasons in >> the system" (that might sound familiar :-). >=20 > yes it does. =20 Eh? > what i see instead is a bunch of noise about process and "it need not = be > in X." Do you understand what happened to Google here Randy? Do you believe it's a problem? Do you believe we "ought" to try to solve it somewhere? Do you believe it's fine to deploy RPKI and BGPSEC and ignore this? People believe RPKI / BGPSEC solves this problem in the form of path = validation. It does NOT. =20 > i simply do not have the spare time for that. i would deeply > love to hear actual proposed solution(s). I'd like to agree on problems first.=20 -danny From randy@psg.com Wed Nov 7 14:57:06 2012 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 56F6621F8582 for ; Wed, 7 Nov 2012 14:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIfoSWObTbaL for ; Wed, 7 Nov 2012 14:57:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EC35721F853B for ; Wed, 7 Nov 2012 14:57:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWEYT-000CjY-5O; Wed, 07 Nov 2012 22:57:05 +0000 Date: Thu, 08 Nov 2012 07:57:04 +0900 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 22:57:06 -0000 >>> How about this: "We need a way to show how to know that the leak is a >>> leak and not another backup path coming to light for other reasons in >>> the system" (that might sound familiar :-). >> >> yes it does. > > Eh? > > > what i see instead is a bunch of noise about process and "it need not be > > in X." > > Do you understand what happened to Google here Randy? > > Do you believe it's a problem? > > Do you believe we "ought" to try to solve it somewhere? > > Do you believe it's fine to deploy RPKI and BGPSEC and ignore this? > > People believe RPKI / BGPSEC solves this problem in the form of path > validation. It does NOT. > > > i simply do not have the spare time for that. i would deeply > > love to hear actual proposed solution(s). > > I'd like to agree on problems first. [ i note lack of engineering suggestions ] as has been said many times, we agree route leaks are a problem. they are not the only problem. please do not send me any more email without a proposed solution. randy From eosterweil@verisign.com Wed Nov 7 15:09:00 2012 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 5828B21F8543 for ; Wed, 7 Nov 2012 15:09:00 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv1B9Zduel+2 for ; Wed, 7 Nov 2012 15:08:59 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9F65921F847B for ; Wed, 7 Nov 2012 15:08:59 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUJrqBqu4XJy72cKHgt0fp1/gDm+FGIvS@postini.com; Wed, 07 Nov 2012 15:08:59 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA7N8org003018; Wed, 7 Nov 2012 18:08:54 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.236]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 18:08:50 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 7 Nov 2012 18:08:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <684887FD-5A1D-478E-B95B-F1D8582B7BE2@verisign.com> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> <8031E4EF-B42E-46C1-8249-FD0FB5918BD4@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Nov 2012 23:08:50.0316 (UTC) FILETIME=[D930E4C0:01CDBD3C] Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:09:00 -0000 On Nov 7, 2012, at 5:00 PM, Christopher Morrow wrote: > On Wed, Nov 7, 2012 at 4:37 PM, Danny McPherson wrote: >>=20 >> On Nov 7, 2012, at 3:56 PM, Christopher Morrow wrote: > SIDR has worked on a few things, one of which is RPKI, which is really > just 'resource certification'. It's added to that the idea that you > could verify the origin of a route you hear, and later that the > originator could sign the outgoing route such that folk down the line > could say: "Yes, that really did originate from FOO-AS". Later/now > it's trying to say that the other portion of the path (other than > origin) could be verified so you believe the path as you see it is the > path the route followed to get to you. Right, but did anyone who was involved in remediating that Moratel leak = say, ``we're all set, I can see the path of the leak, it's miller = time!''? I'm pretty sure verifying the leak is not the same as = remediating it. Eric= From christopher.morrow@gmail.com Wed Nov 7 15:10:25 2012 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 4383B21F8543 for ; Wed, 7 Nov 2012 15:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io-g8+RQSnKd for ; Wed, 7 Nov 2012 15:10:24 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E64CB21F847B for ; Wed, 7 Nov 2012 15:10:19 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1391950eek.31 for ; Wed, 07 Nov 2012 15:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PHs0sT3kocA1qvGsc28ncOnaZjNAqb1ysLoY8j+QyZg=; b=hiVliuXG3Oa1cIoc5o8DFEE7MgaQqVCLkbJaojY+zdvXSqvrCtgX8oPkvDiretR7wx L4hFhQKOfG3FdWJwpXuxnqbRU7fwmxof2EwJtF0wdDlsn++9tPJcxcwYedmvpXi9HUyZ VOSF5b31U9W8oEdMgZIIRlcgkVttQZjHn+35MMOUnlQcJntHii/il9h0svm2IkQ6A+th igQY7txoNnjNlBQk4rUNadZdZ+XfP0e5K1F9xU3PNX1sy5NUKROrqYehBqO6i96G1vDO C8fQN4oAfZilWvaYfaZEbpXZ9NjlH/x55zv5wTyv8J2OR+4TWe+We8GSt0D7kR2tS2j7 Sqxw== MIME-Version: 1.0 Received: by 10.14.194.72 with SMTP id l48mr20769721een.9.1352329814402; Wed, 07 Nov 2012 15:10:14 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 15:10:14 -0800 (PST) In-Reply-To: <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> Date: Wed, 7 Nov 2012 18:10:14 -0500 X-Google-Sender-Auth: _yEn3r9FEhe7i2azztOkCz4rg5s Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:10:25 -0000 On Wed, Nov 7, 2012 at 5:47 PM, Eric Osterweil wrote: > > On Nov 7, 2012, at 4:11 PM, Christopher Morrow wrote: > >> (also, your mail client is not wrapping properly) > > How's my client treatin' ya? :-P just as broke, bug lodged (I hope) for a fix. >> >> On Wed, Nov 7, 2012 at 2:15 PM, Shane Amante wrote: >>> >>> On Nov 7, 2012, at 1:48 PM, Christopher Morrow wrote: >>>> On Wed, Nov 7, 2012 at 1:39 PM, Shane Amante wrote: > >> how does your browser verify the ssl certificate on your webserver? > > I can take a whack at that: not well? I think DigiNotar helped to illustrate some > of the dangers here... Just sayin... ;) point wasn't that multiple-uncontrolled/decentralized certificate authorities were a failure. it's a fair point though, which was why 'single root pls' was/is asked for here. >> again, propose a solution. I don't think anyone has said 'we do not >> want to listen to your problem', in fact many people have said: "yes, >> its a problem, provide a solution". > > > The offer to provide input to the threats and requirements docs is a genuine > attempt to help. For real! :) I have the sneaking suspicion that this week's... > err, event... cost some people some sleep. I feel like we _should_ be > addressing it, no? > don't disagree, haven't disagreed. (I think) I'm not sure how much sleep got lost, or anything else really about it... except that if the route was originated by the origin-asn in the reported CLI output and the path seen wasn't forged, bgpsec/origin-validation wouldn't have helped. nor did filtering on the upstream/customer peerings (clearly)... so folk that want to fall back on 'but de filterz!!' .. are also in failville. >> >> also, resource-certification helps get to a filtering solution of more >> worth/merit... so that's nice, and isn't more goop on routers or in >> bgp... so, win? > > I agree that resource certification is a critical component. > >> if you don't think everyone will do filtering tomorrow (we already >> know they don't today) then we probably should think outside the >> static filtering realm. > > But couldn't we also claim that they won't do any next-gen anything > tomorrow (rpki/bgpsec)? In that sense, wouldn't the above comment > be a bit pedantic statement? maybe? folk have to see a benefit to any of this in order for it to move into production use. if as a first step resource certification work gets me better filtering and/or more people filtering because more reliable filtering is possible, good. eventually though, people will realize that: 1) not everyone is filtering 2) not everyone will filter 3) the only solution left is something in the bgp update :( if there is another '3', let's talk about that. >> what? isn't that what #2 says? I only outlined the steps forward as >> agreed upon by the wg and chairs in the affected wgs... maybe I >> misunderstood your question/point or ? > > I think I read in Shane's response that the idea that bits should be added to > BGP is false logic. The fact that these bits are not in BGP today, does > not mean they should be put there tomorrow. My 0.02 is that there that's not what I read, but ok. where else does the data from which you make a decision about 'leak or not' come from? > seem to be enough complexities in the policy semantics that the amount > of effort needed to get the minimum level of expressiveness into BGP > could be a non-starter... Just my 0.02... perhaps you could explain more/better this problem. >>> Doesn't BGPSEC depend on the RPKI for publishing & retrieving of >>> per-router/per-AS certs? >> >> I think techically rpki is just the jumble of certificate data and >> roas that talk about: >> o prefixes and ownership (right to use) >> o as ownerships/right-to-use >> o origination-information for prefixes/subprefixes (roas) > > I think there's a very complicated replication and fetching hierarchy too. afaict, > there is a huge amount of evaluation left to do just to illustrate the scaling > properties and systemic dependencies of the substrate that serves these this is less concerning... and it's beside the discussion of leak-or-not. as noted on-list more than one time I'd love to see some scaling and such work done on the certificate repository... that's not today's problem though. > objects of the rpki... Well, we've seen some surprising complexity and > worrisome performance curves in our preliminary evaluations and simulations. > In short, I think the above misses some of the issues. sure, but not the issue about leaks, so another thread and another day. >> if you just want to 'solve' route-leaks, and you want to do that with >> filters, you don't need to do anything to bgp. > > What are we (as a wg) trying to solve? I.e. shouldn't we be talking about threats > and requirements? i think we are/were. From jcurran@arin.net Wed Nov 7 15:13:55 2012 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 C5EDB21F89A3 for ; Wed, 7 Nov 2012 15:13:55 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcmNhYNrcRdw for ; Wed, 7 Nov 2012 15:13:55 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9721F84FC for ; Wed, 7 Nov 2012 15:13:54 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 5F849213639; Wed, 7 Nov 2012 18:13:54 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 4D37A213623; Wed, 7 Nov 2012 18:13:49 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 7 Nov 2012 18:13:26 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 18:12:34 -0500 From: John Curran To: "Murphy, Sandra" Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: AQHNvT1e/Q8DzNS0SPC8tLa/5HdiAQ== Date: Wed, 7 Nov 2012 23:12:34 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <5AE6CB9FE2702340A621FD5DC575675B@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 23:13:55 -0000 On Nov 7, 2012, at 2:28 PM, "Murphy, Sandra" wro= te: > My concerns derive from the section PROHIBITED CONDUCT. >=20 > That section says it forbids the relying party (the one retrieving RPKI d= ata from ARIN and validating wrt the ARIN trust anchor) from transferring, = giving access to, copying, broadcasting, etc., any "related content".=20 >=20 > I think that could impact the envisioned architecture and dominant use ca= ses, Sandy - Could you elaborate on this just a bit? i.e. which types of partie= s=20 are expected to be subject to the relying party agreement would also need to share the obtained information with others? (others who would potentiall= y=20 be unaware of the RPA as well as the CP and CPS, in all likelihood...?)=20 > It also forbids "derivative works". >=20 > I think that could impact looking-glass-like or route-views-like public s= ervices, the many different sites that are reporting status and route valid= ity, etc, so an impact on operational usability. This can be addressed directly, as it is not the intent of ARIN to interfer= e in any way with such reporting and summary services. Obviously, it is dire= ctly intended to prevent us from having parties relying on the published objects themselves who are not also aware of the various terms and conditions which= =20 apply. If you are running a reporting or status RPKI public service, feel= =20 free to ask me directly and I'll send you an official note that says "feel= =20 free to summarize our published data for such purposes." If we can find a= =20 way to increment the RPA to safely exclude such status & reporting uses in the future, we will do so. Thanks! /John John Curran President and CEO ARIN From christopher.morrow@gmail.com Wed Nov 7 15:14:29 2012 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 35F8421F8B16 for ; Wed, 7 Nov 2012 15:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dXH-mlnhO32 for ; Wed, 7 Nov 2012 15:14:28 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85DAD21F84FC for ; Wed, 7 Nov 2012 15:14:28 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1393295eek.31 for ; Wed, 07 Nov 2012 15:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Uqvqr9SolqFZVWLsvkDLP0Itv3eGFBVmYoWHT4CD524=; b=iXldDAn5II7PfNd82xqcEM1tnTsR37yVyPyTGr9RMzyNtmNQFF4wNkkW4sCTUknyyP cM2+EsUe1+SPprdZMod5yo1Wmdz4Yo00cR1a8PLJOYjVyKMdd2Ex/tH+gWr0mgsF5BLM lNEcH+o9ScPMUgrXqii2jjTEjUiuDoqgOSVlEkr/ezVYFGtBiv5CsjdCaU6U9d9CfYSI IelJH8Bkzbg8GJFWkaoEcaGg5qiAF1B9njVJDh+1W0zL+YBxS4/IEdABtAxu0laCQT8Q IuyeCSGkRcFc+4GD4wwzWWrwHuAjxhUs2mnrxqV/5VkTdsFTNa2gb4nqwCloGxaJgKeZ THOA== MIME-Version: 1.0 Received: by 10.14.199.134 with SMTP id x6mr20622024een.31.1352330067698; Wed, 07 Nov 2012 15:14:27 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 15:14:27 -0800 (PST) In-Reply-To: <684887FD-5A1D-478E-B95B-F1D8582B7BE2@verisign.com> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> <8031E4EF-B42E-46C1-8249-FD0FB5918BD4@tcb.net> <684887FD-5A1D-478E-B95B-F1D8582B7BE2@verisign.com> Date: Wed, 7 Nov 2012 18:14:27 -0500 X-Google-Sender-Auth: dK1e6CPezNkpH_iEnOmGybf3Ce0 Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:14:29 -0000 On Wed, Nov 7, 2012 at 6:08 PM, Eric Osterweil wrote: > Right, but did anyone who was involved in remediating that Moratel leak say, > ``we're all set, I can see the path of the leak, it's miller time!''? I'm pretty > sure verifying the leak is not the same as remediating it. but today we're stuck 'verifying' by the fact of: "joe user says the internet gone bye-bye" again: What methodology or tool or data or ... would you use (and how) to determine if the route you see is a 'leak' or not? -chris From danny@tcb.net Wed Nov 7 15:16:58 2012 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 ABE0621F8A4B for ; Wed, 7 Nov 2012 15:16:58 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aHA6U12GvVw for ; Wed, 7 Nov 2012 15:16:58 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 39DF021F8B67 for ; Wed, 7 Nov 2012 15:16:58 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id CDC5D2099 for ; Wed, 7 Nov 2012 23:16:57 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 7AA00119; Wed, 7 Nov 2012 16:16:57 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 18:17:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5170CDAC-DDE8-4CB8-A0A7-5EF09095C481@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> To: sidr wg list , Randy Bush X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 16:16:57 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509aebe9199631726217575 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, and+not, 0.01000, Subject*route+announcement, 0.01000, On+#+7, 0.01000, Subject*today+#+to, 0.01000, to+#+this, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, is+#+#+in, 0.01000, Subject*outage+today, 0.01000, this+is, 0.01000, 5+#+PM, 0.01000, To*wg+#+sidr, 0.01000, WG+#+#+#+that, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, and+#+and, 0.01000, at+5, 0.01000, Subject*need+#+SIDR, 0.01000 Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:16:58 -0000 On Nov 7, 2012, at 5:57 PM, Randy Bush wrote: > we agree route leaks are a problem. =20 Excellent, progress.... =20 > please do not send me any more email without a proposed solution. I'll note that this email was NOT to you, Randy, it was to the = sidr@ietf.org mailing list. You are NOT the WG, as hard as that may be = to hear.=20 Quite frankly, my problem is that you in your tours to the FCC and DHS = and NOGs the world around have done such a bang up job making folks = believe RPKI-enabled BGPSEC path validation is lightweight and solves = all the problems that I as an operator should care about with regards to = routing security -- when I consider this a gapping hole. I have not pre-envisaged a solution. As an operator I want the people = designing the solution to recognize this is a problem that needs to be = solved. If I hadn't seen folks suggest they would expedite this work through the = Internet standards and convince the USG to put these Standards Track = documents in procurement materials to "foster" adoption, I'd go away and = not care. -danny= From shane@castlepoint.net Wed Nov 7 15:17:38 2012 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 A0E4A21F8B60 for ; Wed, 7 Nov 2012 15:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Y3xrsTt5oT for ; Wed, 7 Nov 2012 15:17:34 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A7A3921F8A4B for ; Wed, 7 Nov 2012 15:17:34 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id E7011209D for ; Wed, 7 Nov 2012 23:17:33 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 5B1FC119; Wed, 7 Nov 2012 16:17:33 -0700 (MST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Wed, 7 Nov 2012 18:17:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 16:17:33 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509aec0d199631324713444 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, route+#+are, 0.01000, route+#+are, 0.01000, Subject*route+announcement, 0.01000, 11+#+#+Morrow, 0.01000, even+though, 0.01000, even+though, 0.01000, On+#+7, 0.01000, in+BGP, 0.01000, Mime-Version*OS+X, 0.01000, Subject*today+#+to, 0.01000, Subject*to+bogus, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, From*Amante+shane, 0.01000, a+solution, 0.01000, a+solution, 0.01000, Subject*outage+today, 0.01000, a+#+path, 0.01000, the+#+#+the, 0.01000, AS+#+#+to, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, Mime-Version*Mail+#+1499, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:17:38 -0000 Chris, On Nov 7, 2012, at 4:11 PM, Christopher Morrow = wrote: > On Wed, Nov 7, 2012 at 2:15 PM, Shane Amante = wrote: >> Uhhh ... please tell me how a BGPSEC router, receiving a BGP PDU from = another >> AS, is supposed to validate a BGPSEC path signature without relying = on *any* >> offboard systems whatsoever? >>=20 >=20 > how does your browser verify the ssl certificate on your webserver? OK, so you appear to admit that offboard systems are needed (in fact, = critical?) for validation. Yet, the design space for BGPSEC has been = specifically restricted to that which can *only* be solved with data = carried in BGP itself. (See below for why I make this statement). [--snip--] >> of the more frequent & pernicious threats to Internet routing = security. Weak >> sauce. >=20 > again, propose a solution. I don't think anyone has said 'we do not > want to listen to your problem', in fact many people have said: "yes, > its a problem, provide a solution". I can't, nor do I believe can anyone else. I refer you to the = following: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-03#section-5 ---snip--- o "Route leaks" are viewed as a routing security problem by many operators, even though there is no IETF-codified definition of a route leak. BGP itself does not include semantics that preclude what many perceive as route leaks. Moreover, route leaks are outside the scope of PATHSEC, at this time, based on the SIDR charter. Thus route leaks are not addressed in this threat model. ---snip--- First, the threats document says "there is no IETF-codified definition = of a route leak", even though there exists the following: = and, apparently, based on other messages /no where in the IETF to = even discuss it/! Second, there is this sentence: "BGP itself ***does = not include semantics*** that preclude what many perceive as route = leaks." ... That statement reads to me as stating that _because_ BGP = does include semantics to solve for route-leaks, it's out-of-scope for = PATHSEC. Trimming the rest as irrelevant to the core of the argument here. -shane= From randy@psg.com Wed Nov 7 15:17:53 2012 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 476D021F8A4B for ; Wed, 7 Nov 2012 15:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qli-JoSWjfnx for ; Wed, 7 Nov 2012 15:17:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 711AD21F8B6D for ; Wed, 7 Nov 2012 15:17:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWEsZ-000Cnq-UL; Wed, 07 Nov 2012 23:17:52 +0000 Date: Thu, 08 Nov 2012 08:17:50 +0900 Message-ID: From: Randy Bush To: John Curran In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 23:17:53 -0000 > which types of parties are expected to be subject to the relying party > agreement would also need to share the obtained information with > others? (others who would potentially be unaware of the RPA as well as > the CP and CPS, in all likelihood...?) sita has cache and has agreed to arin's silliness. rama, trying not to put load on CA publishers, rsyncs sita's cache and wants to validate it. hanuman rsyncs rama's cache, ... randy From randy@psg.com Wed Nov 7 15:33:29 2012 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 386A021F8A55 for ; Wed, 7 Nov 2012 15:33:29 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykwarcRW8TAX for ; Wed, 7 Nov 2012 15:33:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 515AF21F8A4B for ; Wed, 7 Nov 2012 15:33:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWF7b-000Cqb-F5; Wed, 07 Nov 2012 23:33:23 +0000 Date: Thu, 08 Nov 2012 08:33:22 +0900 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: <5170CDAC-DDE8-4CB8-A0A7-5EF09095C481@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> <5170CDAC-DDE8-4CB8-A0A7-5EF09095C481@tcb.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:33:29 -0000 >> we agree route leaks are a problem. > Excellent, progress.... >> please do not send me any more email without a proposed solution. > I'll note that this email was NOT to you, Randy the header says otherwise. > I have not pre-envisaged a solution. http://en.wikipedia.org/wiki/Serenity_Prayer randy From eosterweil@verisign.com Wed Nov 7 15:38:24 2012 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 1FA2721F868D for ; Wed, 7 Nov 2012 15:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrLjar8-IqmX for ; Wed, 7 Nov 2012 15:38:23 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 43C6021F868C for ; Wed, 7 Nov 2012 15:38:23 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUJrw7Tnbi1dwbcDyjfmjQmDDctsQeXMK@postini.com; Wed, 07 Nov 2012 15:38:23 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA7NcH88003763; Wed, 7 Nov 2012 18:38:20 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.236]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 18:38:16 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 7 Nov 2012 18:38:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Nov 2012 23:38:16.0607 (UTC) FILETIME=[F5FB82F0:01CDBD40] Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:38:24 -0000 On Nov 7, 2012, at 6:10 PM, Christopher Morrow wrote: > On Wed, Nov 7, 2012 at 5:47 PM, Eric Osterweil = wrote: >>=20 >> On Nov 7, 2012, at 4:11 PM, Christopher Morrow wrote: >=20 > just as broke, bug lodged (I hope) for a fix. But, but, it works for me... jk ;) >> >> The offer to provide input to the threats and requirements docs is a = genuine >> attempt to help. For real! :) I have the sneaking suspicion that = this week's... >> err, event... cost some people some sleep. I feel like we _should_ = be >> addressing it, no? >> >=20 > don't disagree, haven't disagreed. (I think) I hear ya, but I feel like this obviates our need to begin discussions = with new design proposals. How can I offer you a design if we don't = agree on what it should do, right? > nor did filtering on the upstream/customer peerings (clearly)... so > folk that want to fall back on 'but de filterz!!' .. are also in > failville. Which of the parties was filtering? > maybe? folk have to see a benefit to any of this in order for it to > move into production use. Right on... I think that kind of thinking is really what's motivating a = lot of leak-based-discussion. Quick wins might come in plugging leaks, = so... on to the threats doc? :-P > if as a first step resource certification > work gets me better filtering and/or more people filtering because > more reliable filtering is possible, good. Yeah, we're on the same page w/ resource certification being a = prerequisite. > eventually though, people will realize that: > 1) not everyone is filtering > 2) not everyone will filter > 3) the only solution left is something in the bgp update :( >=20 > if there is another '3', let's talk about that. Just to follow the same logic, could I not say, 1) not everyone is running bgpsec [clearly, it's not here yet] 2) not everyone will run bgpsec [therefore there will be isolated = islands] 3) the only solution left can't be something in the bgp update? > where else does the data from which you make a decision about 'leak or > not' come from? My understanding is that we need to fallback to intent. With some way = to expose and verify intent, we get there. Discussing how to do that = seems like the right first step, imho. >> seem to be enough complexities in the policy semantics that the = amount >> of effort needed to get the minimum level of expressiveness into BGP >> could be a non-starter... Just my 0.02... >=20 > perhaps you could explain more/better this problem. Maybe I could just say, today we have a very complex policy = specification language, and it's not clear how much of it is used, by = whom, and to what extent... If we were to say, ``throw it all in an = update,'' I think we'd see BGP updates bigger than the bgpsec updates. = As of now, if we can't agree that leaks are a problem worth addressing = and/or we can't agree on what leaks actually are, how could we _not_ use = a very verbose language to expose relevant policy? >>> I think techically rpki is just the jumble of certificate data and = roas that talk about: > this is less concerning... and it's beside the discussion of = leak-or-not. Yeah, but I didn't bring it... I just wanted to clarify the above = comment. I didn't mean to distract, but felt the clarification was = important. > as noted on-list more than one time I'd love to see some scaling and > such work done on the certificate repository... that's not today's > problem though. Yeah, working on that for sure... >> What are we (as a wg) trying to solve? I.e. shouldn't we be talking = about threats >> and requirements? >=20 > i think we are/were. Then I would propose that the insistence on only submitting solutions = before allowing requirements discussions is not appropriate. Eric= From danny@tcb.net Wed Nov 7 15:38:45 2012 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 9877821F8AB8 for ; Wed, 7 Nov 2012 15:38:45 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHowPfoKKqY8 for ; Wed, 7 Nov 2012 15:38:40 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10821F8689 for ; Wed, 7 Nov 2012 15:38:40 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id EC9122099 for ; Wed, 7 Nov 2012 23:38:34 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id AFBBD441 for ; Wed, 7 Nov 2012 16:38:34 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Wed, 7 Nov 2012 18:38:42 -0500 Content-Transfer-Encoding: 7bit Message-Id: <5AC16F71-1EBE-4ABD-887C-ECC77C564ABD@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> <5170CDAC-DDE8-4CB8-A0A7-5EF09095C481@tcb.net> To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 16:38:34 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509af0fa199631413811660 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, the+#+I, 0.01000, the+#+I, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, Subject*route+announcement, 0.01000, On+#+7, 0.01000, Subject*today+#+to, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Subject*outage+today, 0.01000, To*wg+#+sidr, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, Subject*need+#+SIDR, 0.01000, To*list+#+ietf.org, 0.01000, Bush+wrote, 0.01000, 7+#+at, 0.01000, Subject*limited+#+#+due, 0.01000, Subject*today+due, 0.01000 Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:38:45 -0000 [I trust you're not reading this RB] On Nov 7, 2012, at 6:33 PM, Randy Bush wrote: > > http://en.wikipedia.org/wiki/Serenity_Prayer Beautiful... 1) "God, grant me the serenity to accept the things I cannot change," Fitting.. 2) "The courage to change the things I can," I'm trying.. 3) "And the wisdom to know the difference." 'nuff said... -danny From eosterweil@verisign.com Wed Nov 7 15:47:00 2012 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 7A86321F8BEF for ; Wed, 7 Nov 2012 15:47:00 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYapbJXHRKOw for ; Wed, 7 Nov 2012 15:47:00 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 662FB21F8BF9 for ; Wed, 7 Nov 2012 15:46:54 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUJry7OfiZaOnp3wXWu3cF1x4sd8elCvr@postini.com; Wed, 07 Nov 2012 15:46:54 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA7Nkl68004025; Wed, 7 Nov 2012 18:46:52 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.236]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 18:46:47 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 7 Nov 2012 18:46:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3DA38936-88A2-49B8-AD26-C9BC97385678@verisign.com> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <8A07AB18-3E10-427C-A407-FFF90863BBA4@tcb.net> <8031E4EF-B42E-46C1-8249-FD0FB5918BD4@tcb.net> <684887FD-5A1D-478E-B95B-F1D8582B7BE2@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Nov 2012 23:46:47.0761 (UTC) FILETIME=[26A76C10:01CDBD42] Cc: "sidr@ietf.org list" Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:47:00 -0000 On Nov 7, 2012, at 6:14 PM, Christopher Morrow wrote: > On Wed, Nov 7, 2012 at 6:08 PM, Eric Osterweil = wrote: >=20 >> Right, but did anyone who was involved in remediating that Moratel = leak say, >> ``we're all set, I can see the path of the leak, it's miller time!''? = I'm pretty >> sure verifying the leak is not the same as remediating it. >=20 > but today we're stuck 'verifying' by the fact of: "joe user says the > internet gone bye-bye" Uhh, point of order, I believe there would be a belch in there = somewhere? ;) > again: What methodology or tool or data or ... would you use (and how) > to determine if the route you see is a 'leak' or not? This is where my record get's stuck, can we put this in the threats and = requirements doc? I suspect there are a lot of ways people could = suggest we address these problems, but as of now, (as a valid security = threat) it's essentially outlawed by the threats document. If people = spend a lot of time addressing this security problem, the result could = be dismissed as not being in-scope. Why begin pushing on ideas if that = is their fate? Eric= From randy@psg.com Wed Nov 7 15:56:25 2012 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 584E721F8BCD for ; Wed, 7 Nov 2012 15:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d0hbd3RD3bx for ; Wed, 7 Nov 2012 15:56:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DB9F921F8BBA for ; Wed, 7 Nov 2012 15:56:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWFTr-000En6-Op; Wed, 07 Nov 2012 23:56:24 +0000 Date: Thu, 08 Nov 2012 08:56:21 +0900 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 23:56:25 -0000 > I hear ya, but I feel like this obviates our need to begin discussions > with new design proposals. How can I offer you a design if we don't > agree on what it should do, right? eric, folk agreed loooong ago that there is a class of problems we call leaks, and that they adversely affect operations. shane/danny did a draft starting to try to define the class. brian wrote a bit on his approach but did not follow through. i am in correspondence with some chinese folk who are thinking about the problem. but there is no actual proposal, other than brian's dropped one, for a solution. and, in the ietf, we tend not to put things in charters we are not confident of achieving. to me, the core of the problem is what semantics need to be communicated and the set of actions a distant player is expected to perform and what effect those actions should have. once we understand that, we can worry about the syntax and how it's transported. i.e. any bgp, dns, rpsl, foo transport discussion is just noise at the moment. randy From eosterweil@verisign.com Wed Nov 7 16:13:52 2012 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 B64AE21F8B72 for ; Wed, 7 Nov 2012 16:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kldFx5R6yqY8 for ; Wed, 7 Nov 2012 16:13:52 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 05A0821F8AD3 for ; Wed, 7 Nov 2012 16:13:52 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUJr5PpvQXE/r4Wk25jc6wU20SlMfYlRu@postini.com; Wed, 07 Nov 2012 16:13:52 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qA80DkYj004809; Wed, 7 Nov 2012 19:13:49 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.236]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 19:13:45 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 7 Nov 2012 19:13:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 Nov 2012 00:13:46.0235 (UTC) FILETIME=[EB56F4B0:01CDBD45] Cc: sidr wg list Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 00:13:52 -0000 On Nov 7, 2012, at 6:56 PM, Randy Bush wrote: > in the ietf, we tend not to put things in charters we > are not confident of achieving. My point has been that I believe we _can_ address this problem, but = comments in the mail archives and the threats draft itself outlaw this = work. I really feel that we need to at least acknowledge them in the = threats doc. > to me, the core of the problem is what semantics need to be = communicated > and the set of actions a distant player is expected to perform and = what > effect those actions should have. once we understand that, we can = worry > about the syntax and how it's transported. i.e. any bgp, dns, rpsl, = foo > transport discussion is just noise at the moment. Let's say there _is_ a solution, but there's another solution for = _other_ threats. How do we (as a wg) judge the relative merits of the = two approaches if we don't recognize all of the threats? To illustrate: Let's say that I'm afraid of bears and rats, but rats are = easier to catch, so I ignore bears. I would not want to try and use a = rat trap to catch a bear, but that doesn't mean that bears aren't able = to break into the pantry in my mountain cabin while I'm there... Now, = couple that with how much one has to invest in various solutions and you = may choose not to want to invest in very expensive rat traps during = spring (when bears wake up and go lookin fer fud). :) I think we can get there, but either way, there is a ``there...'' Just = my 0.02, Eric= From michael@burnttofu.net Wed Nov 7 16:48:19 2012 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 7EC8221F86A1 for ; Wed, 7 Nov 2012 16:48:19 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+BBtvtwl+U2 for ; Wed, 7 Nov 2012 16:48:19 -0800 (PST) Received: from burnttofu.net (cl-960.qas-01.us.sixxs.net [IPv6:2001:4830:1600:3bf::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF2F321F8460 for ; Wed, 7 Nov 2012 16:48:18 -0800 (PST) Received: from sonicyouth.es.net (sonicyouth.es.net [198.128.1.117]) (authenticated bits=0) by burnttofu.net (8.14.5/8.14.5) with ESMTP id qA80m9KC096514 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 00:48:14 GMT (envelope-from michael@burnttofu.net) Message-ID: <509B0149.1050308@burnttofu.net> Date: Wed, 07 Nov 2012 16:48:09 -0800 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Danny McPherson References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> In-Reply-To: <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (burnttofu.net [208.86.225.220]); Thu, 08 Nov 2012 00:48:17 +0000 (UTC) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 00:48:19 -0000 On 11/07/2012 10:29, Danny McPherson wrote: > Sandy, Can you elaborate what your "concerns about this agreement's > impact on the envisioned RPKI architecture and dominant use" are? Do > you have a reference or outline we can review prior to the discussion > in order to keep this from being a > bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuff > fest? In addition to Sandy's concerns, the agreement contains a third-party indemnification clause (as do other ARIN RPKI-related agreements) that makes it difficult for many state and federal government (and large EDUs) to simply click through and sign. In most of these environments, the network engineers who would be wanting to try out RPKI would not be permitted to agree to such indemnification. This may also be true at large corporations. This, I think, has very little architectural impact, but it does mean additional hoops for operators (like myself) to experiment with RPKI and/or put it in production. As such, further discussion is probably out of scope for SIDR, and I will take this to arin-discuss@ accordingly. But I did want to give this group an FYI that this may be at least a speed-bump on the deployment front. michael From danny@tcb.net Wed Nov 7 17:19:05 2012 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 3E03A21F8A55 for ; Wed, 7 Nov 2012 17:19:05 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOZHUuOzDzeA for ; Wed, 7 Nov 2012 17:19:04 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78D21F8B03 for ; Wed, 7 Nov 2012 17:19:04 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 2EAF82099 for ; Thu, 8 Nov 2012 01:19:04 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 3C6991F4B; Wed, 7 Nov 2012 18:19:02 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: <509B0149.1050308@burnttofu.net> Date: Wed, 7 Nov 2012 20:19:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4142B21B-69C7-4E17-AD6F-5A74BDFF8A4C@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net> To: Michael Sinatra X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 7 18:19:04 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509b0888199637441880093 X-DSPAM-Factors: 27, and+#+#+#+the, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, most+of, 0.01000, to+#+#+in, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, to+#+to, 0.01000, On+#+7, 0.01000, the+#+#+#+I, 0.01000, to+#+this, 0.01000, to+#+this, 0.01000, not+be, 0.01000, in+#+routing, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+system, 0.01000, be+#+#+a, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, the+routing, 0.01000, Cc*sidr+wg, 0.01000, the+#+#+a, 0.01000, of+scope, 0.01000, be+#+to, 0.01000, be+#+to, 0.01000, 7+#+at, 0.01000, network+#+#+#+be, 0.01000, routing+system, 0.01000 Cc: Sandra Murphy , sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 01:19:05 -0000 On Nov 7, 2012, at 7:48 PM, Michael Sinatra wrote: >=20 > In addition to Sandy's concerns, the agreement contains a third-party = indemnification clause (as do other ARIN RPKI-related agreements) that = makes it difficult for many state and federal government (and large = EDUs) to simply click through and sign. In most of these environments, = the network engineers who would be wanting to try out RPKI would not be = permitted to agree to such indemnification. This may also be true at = large corporations. > This, I think, has very little architectural impact, but it does mean = additional hoops for operators (like myself) to experiment with RPKI = and/or put it in production. As such, further discussion is probably = out of scope for SIDR, and I will take this to arin-discuss@ = accordingly. But I did want to give this group an FYI that this may be = at least a speed-bump on the deployment front. Thanks for the feedback and explanation Michael, I understand.=20 Quite frankly, I share _ARIN's concern about the implications of this = and their resulting exposures, and I appreciate their careful = consideration of this issue. It's certainly on _my "Risks relating to = our business" radar. I also appreciate Sandy's attempt to consider this in the context, i.e., = "I think the wg needs to consider the potential impact and any potential = mechanisms that would lessen impact." and I would add "and figure out = what the real constraints are and iterate our problem space and = design/solutions space to accommodate these concerns." Impacting state in routers through this machinery introduces new parties = to the Internet routing system control plane, and ARIN clearly takes = this seriously -- I'm glad. =20 Introducing RPKI data directly into routers, which this WG is doing, = will result in controls effectuated in the routing system. This has = system-wide implications and will impact my network *whether I = participate in that system or not*. This IS a fundamental architectural = change to how things work today, and we all need to consider the = implications very carefully. =20 This fuels a great deal of my concern here, particularly when I don't = see this solving some pretty fundamental issues, such as the Google = incident today. -danny= From jcurran@arin.net Wed Nov 7 17:26:53 2012 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 6521821F8B63 for ; Wed, 7 Nov 2012 17:26:53 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb5gsnB316w8 for ; Wed, 7 Nov 2012 17:26:53 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id B22CB21F8B60 for ; Wed, 7 Nov 2012 17:26:52 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 126861651CC; Wed, 7 Nov 2012 20:26:52 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9A6001651C9; Wed, 7 Nov 2012 20:26:51 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 7 Nov 2012 20:26:28 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 20:26:38 -0500 From: John Curran To: Randy Bush Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: AQHNvT1e/Q8DzNS0SPC8tLa/5HdiAZffVYwAgAAj/wA= Date: Thu, 8 Nov 2012 01:26:37 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 01:26:53 -0000 On Nov 7, 2012, at 6:17 PM, Randy Bush wrote: >> which types of parties are expected to be subject to the relying party >> agreement would also need to share the obtained information with >> others? (others who would potentially be unaware of the RPA as well as >> the CP and CPS, in all likelihood...?) >=20 > sita has cache and has agreed to arin's silliness. rama, trying not to > put load on CA publishers, rsyncs sita's cache and wants to validate it. > hanuman rsyncs rama's cache, ... In the above circumstance, how do rama and hanuman find and consider=20 the terms and conditions of the CA's CP/CPS prior to building reliance upon its surmised authentication and/or non-repudiation capabilities? /John From randy@psg.com Wed Nov 7 17:33:05 2012 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 35D3121F8B63 for ; Wed, 7 Nov 2012 17:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoNRNjdW+93t for ; Wed, 7 Nov 2012 17:33:04 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D6D9421F8B61 for ; Wed, 7 Nov 2012 17:33:04 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWGzP-000FS2-82; Thu, 08 Nov 2012 01:33:03 +0000 Date: Thu, 08 Nov 2012 10:33:02 +0900 Message-ID: From: Randy Bush To: John Curran In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 01:33:05 -0000 >> sita has cache and has agreed to arin's silliness. rama, trying not to >> put load on CA publishers, rsyncs sita's cache and wants to validate it. >> hanuman rsyncs rama's cache, ... > > In the above circumstance, how do rama and hanuman find and consider > the terms and conditions of the CA's CP/CPS prior to building reliance > upon its surmised authentication and/or non-repudiation capabilities? they don't. they are too busy running networks, and assume CAs do their damned jobs. randy From jcurran@arin.net Wed Nov 7 17:54:17 2012 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 D926C21F89B5 for ; Wed, 7 Nov 2012 17:54:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76Adl2P9Old3 for ; Wed, 7 Nov 2012 17:54:17 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 32DC621F898A for ; Wed, 7 Nov 2012 17:54:17 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 95DD9213643; Wed, 7 Nov 2012 20:54:16 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id EC8D6213627; Wed, 7 Nov 2012 20:54:15 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 7 Nov 2012 20:53:58 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 20:54:08 -0500 From: John Curran To: Randy Bush Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: AQHNvT1e/Q8DzNS0SPC8tLa/5HdiAZffVYwAgAAj/wCAAAHHAIAABemA Date: Thu, 8 Nov 2012 01:54:08 +0000 Message-ID: <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 01:54:18 -0000 On Nov 7, 2012, at 8:33 PM, Randy Bush wrote: >>> sita has cache and has agreed to arin's silliness. rama, trying not to >>> put load on CA publishers, rsyncs sita's cache and wants to validate it= . >>> hanuman rsyncs rama's cache, ... >>=20 >> In the above circumstance, how do rama and hanuman find and consider=20 >> the terms and conditions of the CA's CP/CPS prior to building reliance >> upon its surmised authentication and/or non-repudiation capabilities? >=20 > they don't. they are too busy running networks, and assume CAs do their > damned jobs. We may be working on somewhat different assumptions, given that the PKIX=20 certificate architecture was defined to be just like an other Internet=20 PKI certificate system, i.e. there is no automatic legal binding between=20 the CA and the relying party, and relying parties are responsible for=20 determining whether their application of the certificates of a given CA=20 is appropriate in light of applicable CP and CPS. RFC 5280 states this=20 as a basic requirement of the PKIX profile in section 2: "A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties." In your example, is sita taking on this responsibility on behalf of rama=20 and hanuman? It is not apparent that this type of application is within the standard's stated requirements, so it should not be surprising that=20 there's an impedance mismatch occurring. FYI, /John From christopher.morrow@gmail.com Wed Nov 7 18:04:31 2012 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 2DA8B21F8ACA for ; Wed, 7 Nov 2012 18:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bR4CniwAKE7 for ; Wed, 7 Nov 2012 18:04:30 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE0A821F8A55 for ; Wed, 7 Nov 2012 18:04:29 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1441879eek.31 for ; Wed, 07 Nov 2012 18:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gZg2yYASAucVmlTkk3ZQ0qUc/8i3sFF6TSsFnAC19tM=; b=y3wi8YvbsIj0x8urHbpfbLmWXRaoH6wegCAP4uKSufD8gERVk2kNycCd/GGwSSV30A iekaCPZMF8DBZ4JRzPCoJw6amx8mnvoLmsecgxq+iGFD6ISI0CMf5AoBRlz5CrInsk81 naXohGnazBXaKoZCWNYR/d2SxqhqBxdlLN+flfh2W+WROQOSATUGNTUpHKUjev1PGS5w mvRpuNVNLZeYftNG9GA9Ak35VgWXYIFAGn/RBryWevojfWDSu9khJD0qdaVz9iuWYA3s X33eATWuCUmTsEHIT6iEPkwiQMnTpFKFJpe+Dozk2dblR9xUd0mfjKS/+1iGvXy56OV/ BHUQ== MIME-Version: 1.0 Received: by 10.14.184.1 with SMTP id r1mr22202296eem.4.1352340269001; Wed, 07 Nov 2012 18:04:29 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 18:04:28 -0800 (PST) In-Reply-To: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> Date: Wed, 7 Nov 2012 21:04:28 -0500 X-Google-Sender-Auth: 0pVmzL7jNt0LqeDW8HBq-yKUhW0 Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 02:04:31 -0000 On Wed, Nov 7, 2012 at 6:38 PM, Eric Osterweil wrote: > > On Nov 7, 2012, at 6:10 PM, Christopher Morrow wrote: > >> On Wed, Nov 7, 2012 at 5:47 PM, Eric Osterweil wrote: >>> >>> On Nov 7, 2012, at 4:11 PM, Christopher Morrow wrote: >> >> just as broke, bug lodged (I hope) for a fix. > > But, but, it works for me... jk ;) > it's (apparently, or hopefully) a display only problem... which causes pita behavior for the responder (me in this case) if i want things to sort of look legible. >>> >>> The offer to provide input to the threats and requirements docs is a genuine >>> attempt to help. For real! :) I have the sneaking suspicion that this week's... >>> err, event... cost some people some sleep. I feel like we _should_ be >>> addressing it, no? >>> >> >> don't disagree, haven't disagreed. (I think) > > I hear ya, but I feel like this obviates our need to begin discussions with new > design proposals. How can I offer you a design if we don't agree on what it should do, right? 'it should stop leaks' or as someone else said: "Show how to know that the leak is a leak and not another backup path coming to light for other reasons in the system" >> nor did filtering on the upstream/customer peerings (clearly)... so >> folk that want to fall back on 'but de filterz!!' .. are also in >> failville. > > Which of the parties was filtering? neither it would seem. >> maybe? folk have to see a benefit to any of this in order for it to >> move into production use. > > Right on... I think that kind of thinking is really what's motivating a lot of > leak-based-discussion. Quick wins might come in plugging leaks, so... > on to the threats doc? :-P > >> if as a first step resource certification >> work gets me better filtering and/or more people filtering because >> more reliable filtering is possible, good. > > Yeah, we're on the same page w/ resource certification being a prerequisite. > >> eventually though, people will realize that: >> 1) not everyone is filtering >> 2) not everyone will filter >> 3) the only solution left is something in the bgp update :( >> >> if there is another '3', let's talk about that. > > Just to follow the same logic, could I not say, > 1) not everyone is running bgpsec [clearly, it's not here yet] > 2) not everyone will run bgpsec [therefore there will be isolated islands] > 3) the only solution left can't be something in the bgp update? not sure it quite goes that way, but i (and I think everyone else) do see that not everyone in the bright/new/shiney/future future will be happily configured and using bgpsec. Even if everyone does, it's fairly clear that there will be a range of answers to "the route signatures dont match". There's a clear entrance/exit protocol for the 'islands'... this isn't getting us to a 'what is a leak, in a way I can tell from even a directly connected peer' though. >> where else does the data from which you make a decision about 'leak or >> not' come from? > > My understanding is that we need to fallback to intent. With some way to expose > and verify intent, we get there. Discussing how to do that seems like the right first > step, imho. ok, see brian's docs... i think. >>> seem to be enough complexities in the policy semantics that the amount >>> of effort needed to get the minimum level of expressiveness into BGP >>> could be a non-starter... Just my 0.02... >> >> perhaps you could explain more/better this problem. > > Maybe I could just say, today we have a very complex policy specification language, and > it's not clear how much of it is used, by whom, and to what extent... If we were to say, > ``throw it all in an update,'' I think we'd see BGP updates bigger than the bgpsec updates. why? > As of now, if we can't agree that leaks are a problem worth addressing and/or we can't everyone stop... 'if we can't agree that leaks are a problem worth addressing' everyone (well, almost everyone I've read) has agreed they are a problem. Even one worth addressing. There's a path that, follow the path. now, re-read the above. please. > agree on what leaks actually are, how could we _not_ use a very verbose language to > expose relevant policy? > >>>> I think techically rpki is just the jumble of certificate data and roas that talk about: > >> this is less concerning... and it's beside the discussion of leak-or-not. > > Yeah, but I didn't bring it... I just wanted to clarify the above comment. I didn't mean > to distract, but felt the clarification was important. ok, it didn't seem to clarify... just distract. on we go though! >> as noted on-list more than one time I'd love to see some scaling and >> such work done on the certificate repository... that's not today's >> problem though. > > Yeah, working on that for sure... excellent. >>> What are we (as a wg) trying to solve? I.e. shouldn't we be talking about threats >>> and requirements? >> >> i think we are/were. > > Then I would propose that the insistence on only submitting solutions before > allowing requirements discussions is not appropriate. i had thought the requirement was 'stop leaks'. if so, again: great. also, again: how. -chris From randy@psg.com Wed Nov 7 18:09:23 2012 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 4254421F8AEC for ; Wed, 7 Nov 2012 18:09:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjLUBoERUrwH for ; Wed, 7 Nov 2012 18:09:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E094621F8ADD for ; Wed, 7 Nov 2012 18:09:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWHYY-000FW2-Ap; Thu, 08 Nov 2012 02:09:22 +0000 Date: Thu, 08 Nov 2012 11:09:21 +0900 Message-ID: From: Randy Bush To: John Curran In-Reply-To: <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 02:09:23 -0000 > In your example, is sita taking on this responsibility on behalf of rama > and hanuman? no need. this is object based security. rama and hanuman have tals and validate. having every cache in the world hit the CAs is not gonna scale. you may want to look at my ripe and nanog presos on the scaling experiments we did. randy From christopher.morrow@gmail.com Wed Nov 7 18:34:44 2012 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 C38E921F8A65 for ; Wed, 7 Nov 2012 18:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz9q6QmsMwpM for ; Wed, 7 Nov 2012 18:34:44 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C03C21F8A5D for ; Wed, 7 Nov 2012 18:34:43 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1449833eek.31 for ; Wed, 07 Nov 2012 18:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IPwfrPFxKn18WuXj0wcnNmkfQQCpgwSBUVEurxigJ+Q=; b=yU6JZc/kRCvaPaWayXmOd/pIISs5oENo8winjy7HYSy7GCm+dEIoUaWkqyWwIjp9iQ /UIBXZgra2x2NdqJRKw3/nsARG/kYf4WoBM+DEvoUkAQbk3usJK0YPxJ2SieGn8hxwTk 33PLh+wmat791MZf1OxC671Lm8GuuQcdsx/rDZBaZFV/jgzVi+hPGhR85ZBqPmHDRR3x Ir+4UU+o/iZUYaU0h/2d5EuZ/k8H7Ze5VXBx2jBe/Zhi7C7FbRnoKaftjic7ilel9yI7 ca0BIho/v5Zjdlz+BUzQquT0AntlQmdie3/8o30F4vHZ3TNqwd7zuOnvySFjzlrW8K3d a6VA== MIME-Version: 1.0 Received: by 10.14.184.1 with SMTP id r1mr22468740eem.4.1352342083133; Wed, 07 Nov 2012 18:34:43 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 18:34:42 -0800 (PST) In-Reply-To: <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> Date: Wed, 7 Nov 2012 21:34:42 -0500 X-Google-Sender-Auth: XsNc_UtXGJvA4UPpZykm5584iDE Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 02:34:44 -0000 On Wed, Nov 7, 2012 at 6:17 PM, Shane Amante wrote: > I can't, nor do I believe can anyone else. I refer you to the following: i don't know what your first sentence means. > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-03#section-5 > ---snip--- > o "Route leaks" are viewed as a routing security problem by many > operators, even though there is no IETF-codified definition of a > route leak. BGP itself does not include semantics that preclude > what many perceive as route leaks. Moreover, route leaks are > outside the scope of PATHSEC, at this time, based on the SIDR > charter. Thus route leaks are not addressed in this threat model. > ---snip--- > admittedly I'd have probably said in parts: "'Route leaks" are viewed as a routing security problem..." with a reference to the draft in the GROW-WG that talks about how route leaks are a problem to be resolved. > First, the threats document says "there is no IETF-codified definition of a route leak", > even though there exists the following: > and, > apparently, based on other messages /no where in the IETF to even discuss it/! I think the 'codified definition' Stephen's looking for is an rfc... I could be wrong though. I also think there are several messages that tell you where you could talk about route leaks. (in the ietf I mean). > Second, there is this sentence: "BGP itself ***does not include semantics*** that > preclude what many perceive as route leaks." ... That statement reads to me as > stating that _because_ BGP does include semantics to solve for route-leaks, it's > out-of-scope for PATHSEC. read the sentence again, I think you misread it. From randy@psg.com Wed Nov 7 19:22:21 2012 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 E9BD621F8AB8 for ; Wed, 7 Nov 2012 19:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbMf-Qvt38FI for ; Wed, 7 Nov 2012 19:22:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 036C821F8A69 for ; Wed, 7 Nov 2012 19:22:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWIh7-000Ffc-C7; Thu, 08 Nov 2012 03:22:17 +0000 Date: Thu, 08 Nov 2012 12:22:16 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 03:22:22 -0000 > "'Route leaks" are viewed as a routing security problem..." route leaks, as we anecdotally know them, are an operational problem. imiho, they are not particularly a security problem. but that does not mean i think the ietf routing community should not be working on a solution, quite the opposite. randy From jcurran@arin.net Wed Nov 7 19:28:15 2012 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 65C1C21F8A7E for ; Wed, 7 Nov 2012 19:28:15 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvtvWUVi4x6C for ; Wed, 7 Nov 2012 19:28:14 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4516821F8736 for ; Wed, 7 Nov 2012 19:28:14 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id C26191651C9; Wed, 7 Nov 2012 22:28:07 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 457191651BC; Wed, 7 Nov 2012 22:28:07 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 7 Nov 2012 22:27:56 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 22:27:03 -0500 From: John Curran To: Randy Bush Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: AQHNvT1e/Q8DzNS0SPC8tLa/5HdiAZffVYwAgAAj/wCAAAHHAIAABemAgAAEPYCAABW4gA== Date: Thu, 8 Nov 2012 03:27:02 +0000 Message-ID: <41E9E668-E0A5-48BF-8847-3BA0B35B6426@arin.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 03:28:15 -0000 On Nov 7, 2012, at 9:09 PM, Randy Bush wrote: >> In your example, is sita taking on this responsibility on behalf of rama= =20 >> and hanuman? >=20 > no need. this is object based security. rama and hanuman have tals and > validate. =20 This would leave Rama and hanuman dependent on the CA services but=20 not aware of the CPS term and conditions despite the explicit=20 requirement specified in the PKIX profile? If instead they get=20 the TAL from the RIR CA (once), then they can then readily validate=20 the objects but will also be aware of the relevant CA certificate=20 policies that are to be considered before establishing reliance on these services. =20 /John From christopher.morrow@gmail.com Wed Nov 7 19:30:03 2012 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 8A90721F8A7E for ; Wed, 7 Nov 2012 19:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-6-XoxrzDVN for ; Wed, 7 Nov 2012 19:30:03 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCB9D21F8A65 for ; Wed, 7 Nov 2012 19:30:02 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1462886eek.31 for ; Wed, 07 Nov 2012 19:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2SkEFxVfd/06WFDCB3qI52VTeFc619oPlfiC2WGDJqg=; b=snum94293PXys4qwCTAQR87onWiIQpHPCgJ5SLOrtuue28xxaFrCh0v7r/Rf1fRbMV lEx1/YhZLKlRKGDuFgHmwtLGzhcr6khBnrscna0KOdAgM0ekq8iZXrJ2lpFQln4pBFGF NY+iKQgtpj6+rS631m3+duyE0f4XrG3m2ezO03BWDv/StOZS56NcsumPIH2dQKoukaJA KVA37HHa/L4YM/W261+ool/QnhQl9eGGhyUyjfdAOr2e500UUcO7F86/UeoWWdXfA7Ac gR9LhLKVC7V2Xg/BYPxbgk0y1CwYsr87eQRiWMbVskeZOEOztgWBwnMuYHVBl9+Ji4I1 oMvg== MIME-Version: 1.0 Received: by 10.14.172.195 with SMTP id t43mr22838307eel.17.1352345402057; Wed, 07 Nov 2012 19:30:02 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 19:30:01 -0800 (PST) In-Reply-To: References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> Date: Wed, 7 Nov 2012 22:30:01 -0500 X-Google-Sender-Auth: AZJaBktR3jLuaEbmAo7GuWfNbSA Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 03:30:03 -0000 On Wed, Nov 7, 2012 at 10:22 PM, Randy Bush wrote: > > >> "'Route leaks" are viewed as a routing security problem..." > > route leaks, as we anecdotally know them, are an operational problem. sure, I was actually mostly quoting the draft, probably that comment belongs to the editor/authors. (my comment) > imiho, they are not particularly a security problem. but that does not > mean i think the ietf routing community should not be working on a > solution, quite the opposite. > > randy From randy@psg.com Wed Nov 7 19:40:00 2012 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 4C17321F8A69 for ; Wed, 7 Nov 2012 19:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTVEMf1Hrqlt for ; Wed, 7 Nov 2012 19:39:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 38D4B21F8A55 for ; Wed, 7 Nov 2012 19:39:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWIyE-000Fi3-Eg; Thu, 08 Nov 2012 03:39:58 +0000 Date: Thu, 08 Nov 2012 12:39:57 +0900 Message-ID: From: Randy Bush To: John Curran In-Reply-To: <41E9E668-E0A5-48BF-8847-3BA0B35B6426@arin.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> <41E9E668-E0A5-48BF-8847-3BA0B35B6426@arin.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 03:40:00 -0000 > This would leave Rama and hanuman dependent on the CA services but not > aware of the CPS term and conditions despite the explicit requirement > specified in the PKIX profile? OMG!!! my router forgot to call her lawyer! call the network police? john, you have been out of ops for waaaaay too long. randy From shane@castlepoint.net Wed Nov 7 19:48:57 2012 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 7B22E21F88EA for ; Wed, 7 Nov 2012 19:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9TPjgRNN47x for ; Wed, 7 Nov 2012 19:48:57 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 07AB421F8878 for ; Wed, 7 Nov 2012 19:48:57 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 081752090 for ; Thu, 8 Nov 2012 03:48:55 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 17826448; Wed, 7 Nov 2012 20:48:54 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <509B0149.1050308@burnttofu.net> Date: Wed, 7 Nov 2012 22:48:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net> To: Michael Sinatra X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 20:48:55 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509b2ba7199632711011769 X-DSPAM-Factors: 27, most+of, 0.01000, to+#+#+in, 0.01000, Subject*changes+#+#+on, 0.01000, to+#+to, 0.01000, On+#+7, 0.01000, Subject*sidr+additions, 0.01000, Mime-Version*OS+X, 0.01000, to+#+this, 0.01000, to+#+this, 0.01000, not+be, 0.01000, about+this, 0.01000, and+#+#+are, 0.01000, Subject*and+#+#+agenda, 0.01000, Cc*Danny+McPherson, 0.01000, the+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, be+#+#+a, 0.01000, of+#+#+#+and, 0.01000, 2012+at, 0.01000, Subject*on+Friday, 0.01000, Mime-Version*Mail+#+1499, 0.01000, at+#+#+PM, 0.01000, to+#+#+and, 0.01000, the+#+#+a, 0.01000, of+scope, 0.01000, at+#+#+#+I, 0.01000, be+#+to, 0.01000 Cc: "sidr@ietf.org" , "Murphy, Sandra" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 03:48:57 -0000 Michael, On Nov 7, 2012, at 7:48 PM, Michael Sinatra = wrote: > On 11/07/2012 10:29, Danny McPherson wrote: >=20 >> Sandy, Can you elaborate what your "concerns about this agreement's >> impact on the envisioned RPKI architecture and dominant use" are? Do >> you have a reference or outline we can review prior to the discussion >> in order to keep this from being a >> = bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuf= f >> fest? >=20 > In addition to Sandy's concerns, the agreement contains a third-party = indemnification clause (as do other ARIN RPKI-related agreements) that = makes it difficult for many state and federal government (and large = EDUs) to simply click through and sign. In most of these environments, = the network engineers who would be wanting to try out RPKI would not be = permitted to agree to such indemnification. This may also be true at = large corporations. >=20 > This, I think, has very little architectural impact, but it does mean = additional hoops for operators (like myself) to experiment with RPKI = and/or put it in production. As such, further discussion is probably = out of scope for SIDR, and I will take this to arin-discuss@ = accordingly. But I did want to give this group an FYI that this may be = at least a speed-bump on the deployment front. I (also) commend ARIN for their due diligence on this matter. = Commercial operators, in particular, should carefully evaluate the risks = posed to their core business (selling Internet transit) by now being = reliant on certificate information that directly affects = _reachability_information_ carried within their network. That = certificate information is maintained by an outside party that's outside = the operator organization's _direct_ (immediate) control and for which = they, seemingly, have no recourse if (when?) something goes wrong. That = risk without remedies/recourse is not something commercial entities are = prone to voluntarily accept. Obviously, each operator should seek advice from their own legal counsel = as to the risks and make their own decisions. -shane= From jcurran@arin.net Wed Nov 7 19:56:21 2012 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 C902D21F8A4B for ; Wed, 7 Nov 2012 19:56:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSH5eMvCMq5p for ; Wed, 7 Nov 2012 19:56:21 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id B5BAF21F8A48 for ; Wed, 7 Nov 2012 19:56:20 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 323AC213625; Wed, 7 Nov 2012 22:56:20 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 9FD3D213643; Wed, 7 Nov 2012 22:56:18 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 7 Nov 2012 22:55:55 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 22:55:04 -0500 From: John Curran To: Randy Bush Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: AQHNvT1e/Q8DzNS0SPC8tLa/5HdiAZffVYwAgAAj/wCAAAHHAIAABemAgAAEPYCAABW4gIAAA5iAgAAEPAA= Date: Thu, 8 Nov 2012 03:55:02 +0000 Message-ID: <8DDF5F0C-B778-47F3-86DE-780ABB868447@arin.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> <41E9E668-E0A5-48BF-8847-3BA0B35B6426@arin.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <6EA3A0DB77ECF240BBD579EB1432F353@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 03:56:21 -0000 On Nov 7, 2012, at 10:39 PM, Randy Bush wrote: >> This would leave Rama and hanuman dependent on the CA services but not >> aware of the CPS term and conditions despite the explicit requirement >> specified in the PKIX profile? >=20 > OMG!!! my router forgot to call her lawyer! call the network police? >=20 > john, you have been out of ops for waaaaay too long. I know that just smashing the bits together until they click seems like=20 a lot of fun, but the semantics behind the PKIX certificates are actually=20 there for good reason. While I'm sure you can make the bits syntactically fit, it is equally important that there is an actual meeting of the minds regarding the nature of the services to provided by the CA and to be used=20 by the relying party. /John From shane@castlepoint.net Wed Nov 7 21:00:48 2012 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 A210121F88C3 for ; Wed, 7 Nov 2012 21:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fhpMbsY3OSD for ; Wed, 7 Nov 2012 21:00:48 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id DAAF821F89E5 for ; Wed, 7 Nov 2012 21:00:47 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 7ADBA209F for ; Thu, 8 Nov 2012 05:00:46 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B6CED449; Wed, 7 Nov 2012 22:00:45 -0700 (MST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Thu, 8 Nov 2012 00:00:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1EF8C8C5-B5BF-4601-9FB6-2732F1D5D803@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 7 22:00:46 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509b3c7e199632026840477 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, the+#+I, 0.01000, route+#+are, 0.01000, route+#+are, 0.01000, Url*leak, 0.01000, to+#+#+in, 0.01000, Subject*route+announcement, 0.01000, Morrow+#+#+gmail, 0.01000, even+though, 0.01000, even+though, 0.01000, On+#+7, 0.01000, the+#+#+#+at, 0.01000, the+#+#+#+at, 0.01000, the+#+#+#+I, 0.01000, Mime-Version*OS+X, 0.01000, Subject*today+#+to, 0.01000, and+or, 0.01000, Subject*to+bogus, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, Cc*Danny+McPherson, 0.01000, From*Amante+shane, 0.01000, Url*foo, 0.01000, the+route, 0.01000, Subject*outage+today, 0.01000, Url*help, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 05:00:48 -0000 On Nov 7, 2012, at 9:34 PM, Christopher Morrow = wrote: >> = http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-03#section-5 >> ---snip--- >> o "Route leaks" are viewed as a routing security problem by many >> operators, even though there is no IETF-codified definition of a >> route leak. BGP itself does not include semantics that preclude >> what many perceive as route leaks. Moreover, route leaks are >> outside the scope of PATHSEC, at this time, based on the SIDR >> charter. Thus route leaks are not addressed in this threat = model. >> ---snip--- >=20 > admittedly I'd have probably said in parts: > "'Route leaks" are viewed as a routing security problem..." > with a reference to the draft in the GROW-WG that talks about how > route leaks are a problem to be resolved. Nice try; however, you didn't address the crux of the matter, which are = these statements in the threats document: ---snip---- BGP itself does not include semantics that preclude what many perceive as route leaks. Moreover, route leaks are outside the scope of PATHSEC, at this time, based on the SIDR charter. Thus route leaks are not addressed in this threat model. ---snip---- IMO, until those latter three statements are stricken from the threats = draft, it IS NOT worth anyone's time or effort in bringing forth any = proposed solutions, because it's very easy to dismiss them as = "out-of-scope". >> First, the threats document says "there is no IETF-codified = definition of a route leak", >> even though there exists the following: >> = and, >> apparently, based on other messages /no where in the IETF to even = discuss it/! >=20 > I think the 'codified definition' Stephen's looking for is an rfc... I > could be wrong though. If that's all it took, could the authors of = draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 ask for it to be = published as an RFC via the Independent Submissions process? I imagine = -- but I could be [very] wrong -- that the Independent Submissions = process does not meet the rigor of an "IETF-codified definition of a = route leak" that is stated in the route-leaks document. Thus, that = Independent Submissions process would be pointless. So, the question = is: what WG and/or IETF process does it need to go through? > I also think there are several messages that tell you where you could > talk about route leaks. (in the ietf I mean). Let me go pour over the recent barrage of list messages to see if I can = find that ... >> Second, there is this sentence: "BGP itself ***does not include = semantics*** that >> preclude what many perceive as route leaks." ... That statement reads = to me as >> stating that _because_ BGP does include semantics to solve for = route-leaks, it's >> out-of-scope for PATHSEC. >=20 > read the sentence again, I think you misread it. I don't think so. -shane From christopher.morrow@gmail.com Wed Nov 7 21:04:23 2012 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 8A49321F8A69 for ; Wed, 7 Nov 2012 21:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLLeBeSUOXhY for ; Wed, 7 Nov 2012 21:04:22 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56C8D21F8A5D for ; Wed, 7 Nov 2012 21:04:22 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1488269eek.31 for ; Wed, 07 Nov 2012 21:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=m3rnHgmwd9bcDwm/o6T0WASSW2BrLSuYR8lZE5AwNeM=; b=idzVtCAFCn+Nmlqx1czH0bMjFHrrZhU5AFQ9OZO01MpvmIifg4LGVepJg/F37XDxQW AgHGSnt6h9ib8YzQsVSBPB/RKxd2pSjFsP+F3lRtyZwxuIM98/7uicY8uHT+CHBLRQt3 1ZpiHgkosOs98SQJfwUcNFH/MTFwcbZANjcYVbI1ZUzz9e/pBKbG6T0duj0Qx4Udmezw ttP6sGqZ5JI3FeI3AAVQybHaeKaF9Sr6d+0SQZ3Oj9PiIJrwfTnerg0K2uCGs9K+AnQu +k1e6ZCj4xcGWDJv+iqG7f3CdpI3MitiZE9UJ/bTZRjCLvV1EfSvlQFVB+F9TU6ar/oI zIHw== MIME-Version: 1.0 Received: by 10.14.194.72 with SMTP id l48mr23712934een.9.1352351061246; Wed, 07 Nov 2012 21:04:21 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 21:04:21 -0800 (PST) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 00:04:21 -0500 X-Google-Sender-Auth: tRnJs4ilXdgh4x3obMFloUQ7tUM Message-ID: From: Christopher Morrow To: Byron Ellacott Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 05:04:23 -0000 On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott wrote: > Hi Chris, > > When did the WG reach consensus on adopting this draft? when it spent ~50 mesasages discussing it? it seems that, even if we abandon it in the end, discussing this over a draft is a good thing to do. > Thanks, > Byron > > On 13/10/2012, at 12:53 AM, Christopher Morrow wrote: > >> Helo, >> Since we've been through this for a while (originally) and this has >> been quiet for ~1 month... let's call this done and move to the next >> step. >> >> 1) there was lots of discussion on the topic at hand >> 2) lots of that discussion was not about acceptance/rejection of the >> idea into the WG >> 3) lots of people contributed >> >> I do think we should continue to have this discussion more officially >> around a draft, the wg discussion leads me to believe this is the >> right course... can the authors spin a newly named version and we can >> start discussing the topic / changes? >> >> I think if, in the end, the wg decides to abandon the work that's also >> fine, but we should have a more structured chat about the topic, that >> happens around a draft. >> >> -chris >> co-chair >> >> On Wed, Aug 29, 2012 at 5:06 PM, Murphy, Sandra >> wrote: >>> Speaking as wg co-chair >>> >>> Of course revision and new request for acceptance is possible. >>> >>> Even arguing some more leading to acceptance of draft as is is a possibility. >>> >>> Some commentors specifically requested that the discussion be added to some existing draft. >>> >>> Trying to judge wg desire of a way to proceed. >>> >>> >>> --Sandy >>> >>> >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Andy Newton [andy@arin.net] >>> >>> Sent: Wednesday, August 29, 2012 4:56 PM >>> >>> To: Murphy, Sandra; Alexey Melnikov; sidr@ietf.org >>> >>> Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting >>> >>> >>> >>> >>> >>> >>> Are the chairs not allowing the draft authors to address the issues and try again? >>> >>> >>> >>> -andy >>> >>> >>> >>> >>> >>> From: , Sandra >>> >>> Date: Wednesday, August 29, 2012 12:10 PM >>> >>> To: Alexey Melnikov , "sidr@ietf.org" >>> >>> >>> Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting >>> >>> >>> >>> >>> >>> >>> >>> BODY {direction: ltr;font-family: Arial;color: #000000;font-size: 10pt;}P {margin-top:0;margin-bottom:0;} >>> >>> Speaking as wg co-chair: >>> >>> >>> >>> Certainly a very lively acceptance call! >>> >>> >>> >>> The chairs do not see that there was consensus that the wg should adopt this draft. >>> >>> >>> >>> But there was ample evidence that the wg was interested in the issue - by the wg spending lots of time discussing the issue. >>> >>> >>> >>> So that leaves the chairs with an ambivalent message. The wg is very interested in the topic but not in adopting a draft that would record any decisions about the topic. >>> >>> >>> >>> What would the wg like to do now? Particularly those who disagreed with the content of the draft - if you would dislike the recommendations, are you OK with no recommendations instead? >>> >>> >>> >>> --Sandy, speaking as wg co-chair >>> >>> >>> >>> >>> >>> From: >>> >>> sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Alexey Melnikov [alexey.melnikov@isode.com] >>> >>> Sent: Saturday, August 04, 2012 2:12 PM >>> >>> To: >>> sidr@ietf.org >>> >>> Subject: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting >>> >>> >>> >>> >>> >>> Hi, >>> >>> On behalf of SIDR WG chairs I would like to initiate 2 weeks acceptance call for draft-ymbk-rpki-grandparenting starting from today, August 4th. Please >>> send your positive or negative feedback to the mailing list or directly to chairs. >>> >>> >>> >>> >>> Thank you, >>> Alexey >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Nov 7 21:09:28 2012 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 1DEF121F89F5 for ; Wed, 7 Nov 2012 21:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgculo3NZEYd for ; Wed, 7 Nov 2012 21:09:27 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB9E21F87AF for ; Wed, 7 Nov 2012 21:09:26 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1489935eek.31 for ; Wed, 07 Nov 2012 21:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=O8zjLi4clK4H9OQkmntAVTXXfVdcbwSRpy8zf+Ww82s=; b=gEKuE4rfgNjwnT4oa43V3O0Q5N8scS68kYVbiWAiFqU1xQZYEUId1zUcI8I2ZF4PAa +lMf77FFjjvcY0mcyJq7AAbNQoLbEUyN1dZowJqiH0NVuzwZAc0atmz/h64dvyrLIxad M/s8E57WzR/LSr7b5t2+CiR91PZCH764k/7xLIvqjKiVJibx4qVHvf11ZEGC3GNDtrNd NUTe/eVMu4r8Wvo9DM3u4aJS1wFnqxZHajN18+cyRwWF/t0w/tunxZSmjdU8u6ab54Cf KsPxAMl0t5OyX6cqZXbYf1dAK+IY3XT2mI6UhCedLH5zVcDv3Ie5hEAp1F2RBUrAA2H2 pxUA== MIME-Version: 1.0 Received: by 10.14.199.134 with SMTP id x6mr23569480een.31.1352351366265; Wed, 07 Nov 2012 21:09:26 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 21:09:26 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Nov 2012 00:09:26 -0500 X-Google-Sender-Auth: gAh5loMcWvylYHRTY5GoKnUQH3A Message-ID: From: Christopher Morrow To: Andy Newton Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 05:09:28 -0000 On Mon, Oct 15, 2012 at 9:21 AM, Andy Newton wrote: > On 10/12/12 10:53 AM, "Christopher Morrow" wrote: > >>I think if, in the end, the wg decides to abandon the work that's also >>fine, but we should have a more structured chat about the topic, that >>happens around a draft. > > > As the person who specifically asked of the chairs that the draft authors > be allowed to address the issues raised, I'd like specifics on this more > structured chat. I ask because it is not apparent that the normal means of I hope (and I think co-chairs hope) that the authors and commentors can discuss what the problem attempting to be documented is, add the right words to the document and then we can all decide if documenting something in an informational RFC that describes a capability that exists in the system today (and the downsides of executing that capability) is appropriate. it'd be nice, really, to know at the end if there is a reason to NOT publish something along those lines as well, and if the wg things not publishing is best, then we'll just wander off and leave the kitten by the lake on it's own. > IETF discussion were attempted. Of the 38 messages regarding the draft > directly, the draft author only responded 3 times, nor did the author > engage in any of the side discussions. And the draft submitted as a > working group document addresses NONE of the issues raised (it is just a > re-spin with the dates and file name changed). If normal IETF discourse is that's fine though, right? the author and commentors can work out the details. > being set aside especially when it was not fully engaged, we should also > be given the exception criteria under which this scenario qualifies when > others do not. don't think there's anything special going on, there was a bunch of discussion, keep on discussing and if this ends up being publishable 'ok', if not 'ok'. Some of the discussion was along the lines of 'you shouldn't do this because its bad' or 'doing this circumvents the point of the system'... that's also fine to document. the system seems to have the capabilities, it'd be nice to know when not to pull the trigger (while aimed at foot) and when TO pull trigger (downrange is clear). From christopher.morrow@gmail.com Wed Nov 7 21:13:34 2012 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 DD21521F877C for ; Wed, 7 Nov 2012 21:13:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMNXvTandezZ for ; Wed, 7 Nov 2012 21:13:34 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C3A21F86D3 for ; Wed, 7 Nov 2012 21:13:34 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so1022452eaa.31 for ; Wed, 07 Nov 2012 21:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FVVDgo10EFOMKkCPnjlILXm5k7WFjS8ViCjBM5ispxw=; b=S6uU6tSqOQ7/y7Oay0+J1NL+2Qqq2/HnzsEkfBufSmDFy1E7PPrZBZZOdUa+uakB6I 7A32ixNOuMKZDl9vGKP5zNxSxuJicKyK9IpejmP8IM91mgDvZ3z8vbQwwi4UzmNggSZh caJRJ85nLUVm4YDMZSRUWkajYk7swmznJj1z7S6TH/OTHr0o4UJ07WEz97/T66P3oOpM cXo2+SHXFnLWSA3H8KsBkExQjeJli2i6yeuqLR+VxNgok+rUtybqxugBWoI5xvdnhl4v HLgSiNQ1k6eUDwEHruzsxqc3YoUVBv6DuHBiUsxfDkanuivk1HlAUHlB9Unw9CErKA4x 1IFg== MIME-Version: 1.0 Received: by 10.14.172.195 with SMTP id t43mr23680703eel.17.1352351613450; Wed, 07 Nov 2012 21:13:33 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 21:13:33 -0800 (PST) In-Reply-To: <1EF8C8C5-B5BF-4601-9FB6-2732F1D5D803@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> <1EF8C8C5-B5BF-4601-9FB6-2732F1D5D803@castlepoint.net> Date: Thu, 8 Nov 2012 00:13:33 -0500 X-Google-Sender-Auth: DHolVYVoVnFOWzpSc6ZJIPVhD-k Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 05:13:35 -0000 On Thu, Nov 8, 2012 at 12:00 AM, Shane Amante wrote: > Nice try; however, you didn't address the crux of the matter, which are these statements in the threats document: ugh, i keep trying to be polite and point out that: 1) no one said you can't discuss this 2) no one said that leaks aren't a problem 3) the process to get this problem addressed was discussed and agreed upon in prague (I believe) - about 1yr ago in any effect. 4) continuously going around the mulberry bush isn't getting to a solution. please: 1) go get grow to agree that this is a problem (this should not be hard, apparently) 2) go get IDR to either provide the semantics in BGP OR aim you in another direction that does not include BGP as a transport/signaling protocol 3) if 2 == idr-work, happily bring that here so we can deal with it properly. -chris From christopher.morrow@gmail.com Wed Nov 7 21:14:31 2012 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 CC10121F8A12 for ; Wed, 7 Nov 2012 21:14:31 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H9Ay+DxJ9qY for ; Wed, 7 Nov 2012 21:14:31 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C41D021F878B for ; Wed, 7 Nov 2012 21:14:30 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so1022731eaa.31 for ; Wed, 07 Nov 2012 21:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KxI63rK9SeS6LLyaIJ9p1ayKqkdf7U30JwtlwFBMlxo=; b=PHoYJaXinDBEIn96heAxkVTAjNVdg8Vfybpy2hpX+01IuO9ASzFvJlP/J/ZaikqBch UPIz/pbaTf2ttZomrVRW8QRQrJ4AuwiO7jdsNGCgQLKNi/MK7hXaeMon6ON6D70hxNwo RKdz2wEYUh8jk+nEh4rBDZWuI2aQneNwrEuEZUGgWsMJPcJknFTLqUtm2fogvXa4i6ig n1Fel0CqFTCqzSo7OAz8SbE5yvEYH5H9+20IKbz04BOJlWu67bQI+4gwCoJZK180OjOn nfX8NXveJVcOHC9rw5MY8MoleLJ3jgtvWOZUk6sLcOYVgU49NWhQiXn8VLx1HZaAtJJv McNQ== MIME-Version: 1.0 Received: by 10.14.172.195 with SMTP id t43mr23688434eel.17.1352351669932; Wed, 07 Nov 2012 21:14:29 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 21:14:29 -0800 (PST) In-Reply-To: <1EF8C8C5-B5BF-4601-9FB6-2732F1D5D803@castlepoint.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> <1EF8C8C5-B5BF-4601-9FB6-2732F1D5D803@castlepoint.net> Date: Thu, 8 Nov 2012 00:14:29 -0500 X-Google-Sender-Auth: fRliY_Iab_iTUdEIgdA2TskAaoA Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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 Nov 2012 05:14:32 -0000 On Thu, Nov 8, 2012 at 12:00 AM, Shane Amante wrote: >>> Second, there is this sentence: "BGP itself ***does not include semantics*** that >>> preclude what many perceive as route leaks." ... That statement reads to me as >>> stating that _because_ BGP does include semantics to solve for route-leaks, it's >>> out-of-scope for PATHSEC. >> >> read the sentence again, I think you misread it. > > I don't think so. you did: "does not include" "does include" missing word important. From christopher.morrow@gmail.com Wed Nov 7 21:49:11 2012 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 ABA3B21F8799 for ; Wed, 7 Nov 2012 21:49:11 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJgw21anOjqa for ; Wed, 7 Nov 2012 21:49:10 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE5121F8798 for ; Wed, 7 Nov 2012 21:49:10 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so1032191eaa.31 for ; Wed, 07 Nov 2012 21:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MQizj3PqGNfGSyFRUTCxEVPbewhfHiSODRVIk9RDrdg=; b=bZo7+Xqct7YmcSyTV+rcrAUHcySmCd+hbPrmhcbLHxdASPzqYwLjnwBHucVrFPvmdF 5yYIfqk/KCpw8vFTVKmzZqF7MH51vhGIh/IAyU5jODd1rLX52mkRMG+wODsSYNA2ar61 VkvlHtYFitPCbPXCQEW5oM3yEaxyShJB6189hRendnw2ymY7ZulxEzVbsJHDTqK5o7I8 8Iuw7RJ4pLtr/IRYnrd5snxe1RzjQ7dx6/noT3p+fH6CEN0Y94mwQlw3y39jAa0g3tH7 JWQrLOVXiME1H2TmbJWrvQGKFZtZJJIKn9tGczx+NSRJPyBjLbgiszc6cVs2v0XwtA1c rP6w== MIME-Version: 1.0 Received: by 10.14.179.136 with SMTP id h8mr24110354eem.7.1352353749695; Wed, 07 Nov 2012 21:49:09 -0800 (PST) Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 21:49:09 -0800 (PST) Date: Thu, 8 Nov 2012 00:49:09 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@tools.ietf.org, Danny McPherson , Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] BGPSEC Threats Doc updates + comment handling 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 Nov 2012 05:49:11 -0000 The threats document: was updated September 14, 2012, the idea being it captured the comments made on -02, a primary author of comments was Danny (copied), had the commentors gotten time to review whether or not the comments met their expectations? I do note today's rambling discussion brought up something I'd have re-worded: In section 5: o "Route leaks" are viewed as a routing security problem by many operators, even though there is no IETF-codified definition of a route leak. BGP itself does not include semantics that preclude what many perceive as route leaks. Moreover, route leaks are outside the scope of PATHSEC, at this time, based on the SIDR charter. Thus route leaks are not addressed in this threat model. o I would have added a linkage to a document or draft which talks about operators and their views on route-leaks. (yes, someone should get that document done, the -no-help could be that possibly) o is the intent of 'ietf-codified' to mean: "Informational/Standards-Track RFC" ? is that the right height of bar? it seems higher than I would have expected. o it's possible that the meaning of the first sentence is 'people THINK this is a security problem, it is NOT. the downstream effects of leaks could, however, be security problems.' - is that the intent? Oh, there's interesting text about this section 5 text in 4.2: "... and might be the result of a local policy that is not publicly disclosed. As a result, they are not considered attacks" o it might due everyone a favor to say something in the next-to-last sentence about WHY route leaks are not included in the current charter, and that revising the document is expected (is it?) if later conditions change and route leaks are included in the charter. perhaps: "Moreover, route leaks are outside the scope of PATHSEC, because there is not a firm definition nor information in an update which could inform the local policy system about the existence of a route leak. Additionally, the current SIDR charter does not discuss route leaks. If at a later time, infrormation is included in the update and the charter is amended this document should be revised." In section 2, since you later (in 5) talk about there not being a codified definition, you may want to point the route-leak terminology at the same ID/reference. thanks! -chris From bje@apnic.net Wed Nov 7 21:53:32 2012 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 285E421F86E4 for ; Wed, 7 Nov 2012 21:53:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofbIGgS-Cmur for ; Wed, 7 Nov 2012 21:53:31 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3302D21F8699 for ; Wed, 7 Nov 2012 21:53:30 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:bc82:a6d0:f9fe:b22e] (unknown [IPv6:2001:dc0:a000:4:bc82:a6d0:f9fe:b22e]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 286B3B68DF; Thu, 8 Nov 2012 15:53:28 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_CA7A8D64-C4E9-41C7-9F81-10F714339031"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Byron Ellacott In-Reply-To: Date: Thu, 8 Nov 2012 15:53:27 +1000 Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) Cc: sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 05:53:32 -0000 --Apple-Mail=_CA7A8D64-C4E9-41C7-9F81-10F714339031 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Chris, On 08/11/2012, at 3:04 PM, Christopher Morrow = wrote: > On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott wrote: >> Hi Chris, >>=20 >> When did the WG reach consensus on adopting this draft? >=20 > when it spent ~50 mesasages discussing it? > it seems that, even if we abandon it in the end, discussing this over > a draft is a good thing to do. When that discussion happened, the chairs declared a lack of consensus = for adoption: = http://www.ietf.org/mail-archive/web/sidr/current/msg05015.html Have the chairs reconsidered that declaration of lack of WG consensus, = or adopted the draft despite a lack of WG consensus? Perhaps there's a problem to be addressed, and if a discussion should = happen around that problem, a document describing the problem might be a = more useful way forward. Byron --Apple-Mail=_CA7A8D64-C4E9-41C7-9F81-10F714339031 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDgwNTUzMjhaMCMGCSqGSIb3DQEJBDEWBBTV KlNcGBWR/K7Buqa38l8ZGFRq0TCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQDI4gAbOulBG6Bv sxu6oTP8kBgjkKpzbJeDhQEaVdipI2qIJ+em65v/9XHiIoZXfmy+m2YkZnagBCc09UOVAJvfBljr G6yksVVRk/fouQdHQfpbuFEJH97aR+axz8AT4yROt+6G5cMiTcJqZEW9SE4wmNDpov66jpIsh/tV BZUdyAjSgej/cDr9m29MRSRazmRRXNUpNW2+gQcuDJTTEX+EdoRoAV4bMPcOxZMCkVKi+R1Ye4Zc 82oEp4SRuZUwMiIknzMDQx4h20bASPynvc8sBYv7T587xKgkeTkDnt+vJYG2r5YR+lt6xNIgB4a+ 3J9qlp4kIbIOMVGAxRogfukaAAAAAAAA --Apple-Mail=_CA7A8D64-C4E9-41C7-9F81-10F714339031-- From christopher.morrow@gmail.com Wed Nov 7 21:56:54 2012 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 11DDB21F8A72 for ; Wed, 7 Nov 2012 21:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtdFO9GVRg5K for ; Wed, 7 Nov 2012 21:56:53 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D248321F88E9 for ; Wed, 7 Nov 2012 21:56:52 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1504977eek.31 for ; Wed, 07 Nov 2012 21:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VVpTiHThXJChd7ta5VehAVrQwkKrijFKGyWysqndRJY=; b=mOmQA9YDNeq+IaQ6uSZRuDGvkQLiWQu0JA6QQJXCABNY9hKd/xp2q74Q9xLGo3qsjn FtApERHPxeIuQG9B0Z2rfvd1WLHzu+7/2GkFWXQslOnbe3ZrPHnFP4jUqLiaFeSJMswb eQD0DmnBFOwLOvhb89iuk4y0fHVRSXyyT9f1c9VhxY7XLhuUEkeqmulBjTjdV0pX6qhM nPw1h5jXCT++LTfnyqUUUkfBt6PyN+0id1Fr+pUbEv5GDp7pMhgQ9EmE/7fbPV0nmisg xdcNN3G4rZ3inMnmuifH19D2Ugj3KQ3/8E/YSibxLSduaZrvYpl/TkMFmiWVFg19d8ki 2yZw== MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr23794236eem.42.1352354208372; Wed, 07 Nov 2012 21:56:48 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 21:56:48 -0800 (PST) In-Reply-To: <8DDF5F0C-B778-47F3-86DE-780ABB868447@arin.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> <41E9E668-E0A5-48BF-8847-3BA0B35B6426@arin.net> <8DDF5F0C-B778-47F3-86DE-780ABB868447@arin.net> Date: Thu, 8 Nov 2012 00:56:48 -0500 X-Google-Sender-Auth: uFL5MrEpasmkljis9WBMcusIlOY Message-ID: From: Christopher Morrow To: John Curran Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 05:56:54 -0000 On Wed, Nov 7, 2012 at 10:55 PM, John Curran wrote: > a lot of fun, but the semantics behind the PKIX certificates are actually > there for good reason. While I'm sure you can make the bits syntactically > fit, it is equally important that there is an actual meeting of the minds > regarding the nature of the services to provided by the CA and to be used > by the relying party. are you really saying that the RP should simply download (or have downloaded as part of the repository data) the CPS documents? Would that resolve the problem here? (I think that's all the arin doc is actually doing, making me download a cps and read/review/agree to that document, right?) -chris From christopher.morrow@gmail.com Wed Nov 7 22:00:38 2012 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 F0FC921F872E for ; Wed, 7 Nov 2012 22:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPL0KmxQQ9qr for ; Wed, 7 Nov 2012 22:00:37 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 515FC21F86D4 for ; Wed, 7 Nov 2012 22:00:36 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1506697eek.31 for ; Wed, 07 Nov 2012 22:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hAQaCKQt+UoN+DKH2Potfz0C4OFs1nyKhAjqQvpK9H0=; b=FkinkrNsigv5giBZen4czvHb9phRkYgd4OEhi75vQW8MBvXs/vWt0+YNgYdRvU4iEv rKiEgnmF3zKSpCi6AHsWuTIRGFfEdRCSeQDE19SMnVwNkr7OBPo8irSnUGmeHpJqChmb K/n6jExeX7NfNYP557ClWR8ldO1qdNzPRIU4HhMsao+slEtkJ0NAEUtYlmLjtBLaJNch RbAKQBcx4bwR61r48LjHzpF64t8KemeBFrWg5OvUhAFJMo7pOWsk/b5p83oNbq4ctZDb hykStO3Sl/CoekRq7ft/DilFqNZ/kM7mQoEy5MsalO0z/xVsKHeXhXxOT34UenqHQ2yA 4sTw== MIME-Version: 1.0 Received: by 10.14.175.71 with SMTP id y47mr23837427eel.36.1352354436087; Wed, 07 Nov 2012 22:00:36 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 22:00:35 -0800 (PST) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 01:00:35 -0500 X-Google-Sender-Auth: F7nMG8Zk78EAexyMP8McXS11JcY Message-ID: From: Christopher Morrow To: Byron Ellacott Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 06:00:39 -0000 On Thu, Nov 8, 2012 at 12:53 AM, Byron Ellacott wrote: > Hi Chris, > > On 08/11/2012, at 3:04 PM, Christopher Morrow wrote: > >> On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott wrote: >>> Hi Chris, >>> >>> When did the WG reach consensus on adopting this draft? >> >> when it spent ~50 mesasages discussing it? >> it seems that, even if we abandon it in the end, discussing this over >> a draft is a good thing to do. > > When that discussion happened, the chairs declared a lack of consensus for adoption: http://www.ietf.org/mail-archive/web/sidr/current/msg05015.html > ok, i suppose my point here is that there's a bunch of discussion, there's a draft that got chattered about quite a bit. having the wg talk about it a bit more formally (which could just wither away to nothing in the end) doesn't seem to hurt. > Have the chairs reconsidered that declaration of lack of WG consensus, or adopted the draft despite a lack of WG consensus? > yes, apparently. > Perhaps there's a problem to be addressed, and if a discussion should happen around that problem, a document describing the problem might be a more useful way forward. > that was the thought. again, maybe in the end it ends up not getting published... like: http://tools.ietf.org/html/draft-ietf-sidr-bogons it happens somewhat often, no harm though, near as I can tell. -chris From bje@apnic.net Wed Nov 7 22:26:43 2012 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 E138421F8792 for ; Wed, 7 Nov 2012 22:26:43 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVaGwi63Py43 for ; Wed, 7 Nov 2012 22:26:43 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 376BB21F8742 for ; Wed, 7 Nov 2012 22:26:42 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:bc82:a6d0:f9fe:b22e] (unknown [IPv6:2001:dc0:a000:4:bc82:a6d0:f9fe:b22e]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 40E70B68DF; Thu, 8 Nov 2012 16:26:39 +1000 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_6ADBC48F-581F-491C-978E-11D3309F6CAC"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Byron Ellacott In-Reply-To: Date: Thu, 8 Nov 2012 16:26:38 +1000 Message-Id: <111B9A0A-2999-4A2C-B6FC-34F591ECCC54@apnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 06:26:44 -0000 --Apple-Mail=_6ADBC48F-581F-491C-978E-11D3309F6CAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Chris, On 08/11/2012, at 4:00 PM, Christopher Morrow = wrote: > ok, i suppose my point here is that there's a bunch of discussion, > there's a draft that got chattered about quite a bit. having the wg > talk about it a bit more formally (which could just wither away to > nothing in the end) doesn't seem to hurt. I think I understand this somewhat better now, thanks. There's a wealth = of discussion that happened previously, I don't think there's a lot of = value in re-iterating those comments now, since they're all still there = in the archive - or do you think it would be constructive to list some = of those discussion points again? Byron --Apple-Mail=_6ADBC48F-581F-491C-978E-11D3309F6CAC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDgwNjI2MzlaMCMGCSqGSIb3DQEJBDEWBBRA 37IAfo0ZJL6FZNhxZ9hbcueolDCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQBxEUyODY7/zx8M huLMdNcb+gRwS+JaR/cyR9lkczjFH37HrcmxCMa3cQIcgQvsEphLUAzT7E9aYEIS3t5w3zb4diLs U1k9RCrxwmSUhaOEPNqPRRCSWeLEWdttTwLT4B0wSWdZE1m9s+kdVBhexxoSkVsLWF0T39ikp7xq wjC2a5nNGseUxD5rFE4w0EsRIXfL1IHS1M54nE6wbLdW5sc1nmaCDr4sLBVfiVBazZUOCPqdXA0a eHtjrgkoLSp3RlREpFH77A0Mm+y8gAVnu5rOZtRkMRQMw0ioNrw7bBzYJfGVoMNgADPfKmAjeYUt tSSGpmWaBIKhe4P6sayfsl9rAAAAAAAA --Apple-Mail=_6ADBC48F-581F-491C-978E-11D3309F6CAC-- From christopher.morrow@gmail.com Wed Nov 7 22:41:55 2012 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 9226B21F8893 for ; Wed, 7 Nov 2012 22:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOPV4nySgn+F for ; Wed, 7 Nov 2012 22:41:55 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCDF21F889D for ; Wed, 7 Nov 2012 22:41:54 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so1523441eek.31 for ; Wed, 07 Nov 2012 22:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=E7fLigC620kdnhdv+TTYfELBwzQ6cq9Z3Y97yQr2XtA=; b=yk7SAMOCkkmcWo5EY0GACPj4pTcEcl+t8sdFxKRAv5gxfaD+Fj5D6omwqYCik0xvCF Zx5pgM9CT2mnjHbBWCsGurQA79vujrL33nKAE2xlGGByBGWhux7eVC8LxFCPTJxSX7JA 8vW+f1XGGXdtXiNAvEIdDRf/Y4XJicNGMLza0txcQeoFX2O/5LAt+5cUasmzX/XrSLLP pFf4UCZ3sSVgyZ/oQ5tzwVhEVA2GsHd87g+r1tM5Urt8uvUBjZql1e4XsHdBB3xCEK4R A5EX6ReeuT9j4b7JyWloI+1RwsDf3YB5HBBX3K6nQwu/16P1lR+FkfTGPyZyUbGUmerY Y4Bg== MIME-Version: 1.0 Received: by 10.14.184.1 with SMTP id r1mr24472112eem.4.1352356913672; Wed, 07 Nov 2012 22:41:53 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 7 Nov 2012 22:41:53 -0800 (PST) In-Reply-To: <111B9A0A-2999-4A2C-B6FC-34F591ECCC54@apnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> <111B9A0A-2999-4A2C-B6FC-34F591ECCC54@apnic.net> Date: Thu, 8 Nov 2012 01:41:53 -0500 X-Google-Sender-Auth: l5pOjkvkbD5PIUftiH0khnjFNps Message-ID: From: Christopher Morrow To: Byron Ellacott Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org wg" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 06:41:55 -0000 On Thu, Nov 8, 2012 at 1:26 AM, Byron Ellacott wrote: > Hi Chris, > > On 08/11/2012, at 4:00 PM, Christopher Morrow w= rote: > >> ok, i suppose my point here is that there's a bunch of discussion, >> there's a draft that got chattered about quite a bit. having the wg >> talk about it a bit more formally (which could just wither away to >> nothing in the end) doesn't seem to hurt. > > I think I understand this somewhat better now, thanks. There's a wealth = of discussion that happened previously, I don't think there's a lot of valu= e in re-iterating those comments now, since they're all still there in the = archive - or do you think it would be constructive to list some of those di= scussion points again? > i hope that after the current hub-bub dies down (meeting hub-bub) we can get back to this document, wrangle the comments into feedback the authors can use and see where the discussion goes from there. -chris From heas@shrubbery.net Wed Nov 7 23:07:32 2012 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 95D6321F889D for ; Wed, 7 Nov 2012 23:07:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2I18HMlCb+x for ; Wed, 7 Nov 2012 23:07:32 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2427421F877E for ; Wed, 7 Nov 2012 23:07:32 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id B5D349AFBE; Thu, 8 Nov 2012 07:07:32 +0000 (UTC) Date: Thu, 8 Nov 2012 07:07:32 +0000 From: heasley To: John Curran Message-ID: <20121108070732.GX5880@shrubbery.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> <41E9E668-E0A5-48BF-8847-3BA0B35B6426@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E9E668-E0A5-48BF-8847-3BA0B35B6426@arin.net> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 07:07:32 -0000 Thu, Nov 08, 2012 at 03:27:02AM +0000, John Curran: > > no need. this is object based security. rama and hanuman have tals and > > validate. > > This would leave Rama and hanuman dependent on the CA services but > not aware of the CPS term and conditions despite the explicit > requirement specified in the PKIX profile? It looks like a SHOULD to me, not a MUST. no? From randy@psg.com Thu Nov 8 00:08:27 2012 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 00D5721F8692 for ; Thu, 8 Nov 2012 00:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03NQo9WG5b+t for ; Thu, 8 Nov 2012 00:08:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A3A1F21F868D for ; Thu, 8 Nov 2012 00:08:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWN9y-000GWJ-9w; Thu, 08 Nov 2012 08:08:22 +0000 Date: Thu, 08 Nov 2012 17:08:21 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> <111B9A0A-2999-4A2C-B6FC-34F591ECCC54@apnic.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 08:08:27 -0000 > i hope that after the current hub-bub dies down (meeting hub-bub) we > can get back to this document, wrangle the comments into feedback the > authors can use and see where the discussion goes from there. i suspect that the authors would greatly appreciate a concise list of improvements to the document. rumor is that they don't have the copious spare time to sift through hub-bub, process noise, etc. randy From Sandra.Murphy@sparta.com Thu Nov 8 03:25:53 2012 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 9693821F867E for ; Thu, 8 Nov 2012 03:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKAOApTdbtMj for ; Thu, 8 Nov 2012 03:25:53 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 05E3D21F8654 for ; Thu, 8 Nov 2012 03:25:53 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA8BPn8W016427; Thu, 8 Nov 2012 03:25:49 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA8BPjTX006263; Thu, 8 Nov 2012 03:25:49 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 06:25:45 -0500 From: "Murphy, Sandra" To: Shane Amante , Michael Sinatra Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: Ac28OrfR/Q8DzNS0SPC8tLa/5HdiAQBBRRiAAA01X4AABlAIAAAEq3BN Date: Thu, 8 Nov 2012 11:25:44 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 11:25:53 -0000 Speaking as regular ol' member=0A= =0A= On Wednesday, November 07, 2012 10:48 PM, Shane Amante [shane@castlepoint.n= et] said:=0A= =0A= >Commercial operators, in particular, should carefully evaluate the risks p= osed to=0A= > their core business (selling Internet transit) by now being reliant on ce= rtificate =0A= >information that directly affects _reachability_information_ carried withi= n their =0A= >network. That certificate information is maintained by an outside party t= hat's =0A= >outside the operator organization's _direct_ (immediate) control and for= =0A= > which they, seemingly, have no recourse if (when?) something goes wrong.= =0A= =0A= I think the Internet is already there.=0A= =0A= There are ISPs that spend considerable energy creating prefix filters from = IRR data and strongly encourage their customers to register in IRRs. Those= registers are maintained by an outside party that's outside the operator o= rganization's direct control. Those registered objects directly affect rea= chability information carried within their network.=0A= =0A= Commercial operators have been comfortable with this mode of operation for = many years. I doubt whether any of them have felt the need to carefully ev= aluate the risks or consult their legal departments. It has been best curr= ent practice and urged on operators at *OG meetings.=0A= =0A= I don't think we want people asking ISPs that use IRRs why they run such a = risky operation.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Shane Aman= te [shane@castlepoint.net]=0A= Sent: Wednesday, November 07, 2012 10:48 PM=0A= To: Michael Sinatra=0A= Cc: sidr@ietf.org; Murphy, Sandra=0A= Subject: Re: [sidr] additions and changes to agenda on Friday=0A= =0A= Michael,=0A= =0A= On Nov 7, 2012, at 7:48 PM, Michael Sinatra wrote:= =0A= > On 11/07/2012 10:29, Danny McPherson wrote:=0A= >=0A= >> Sandy, Can you elaborate what your "concerns about this agreement's=0A= >> impact on the envisioned RPKI architecture and dominant use" are? Do=0A= >> you have a reference or outline we can review prior to the discussion=0A= >> in order to keep this from being a=0A= >> bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-st= uff=0A= >> fest?=0A= >=0A= > In addition to Sandy's concerns, the agreement contains a third-party ind= emnification clause (as do other ARIN RPKI-related agreements) that makes i= t difficult for many state and federal government (and large EDUs) to simpl= y click through and sign. In most of these environments, the network engin= eers who would be wanting to try out RPKI would not be permitted to agree t= o such indemnification. This may also be true at large corporations.=0A= >=0A= > This, I think, has very little architectural impact, but it does mean add= itional hoops for operators (like myself) to experiment with RPKI and/or pu= t it in production. As such, further discussion is probably out of scope f= or SIDR, and I will take this to arin-discuss@ accordingly. But I did want= to give this group an FYI that this may be at least a speed-bump on the de= ployment front.=0A= =0A= =0A= I (also) commend ARIN for their due diligence on this matter. Commercial o= perators, in particular, should carefully evaluate the risks posed to their= core business (selling Internet transit) by now being reliant on certifica= te information that directly affects _reachability_information_ carried wit= hin their network. That certificate information is maintained by an outsid= e party that's outside the operator organization's _direct_ (immediate) con= trol and for which they, seemingly, have no recourse if (when?) something g= oes wrong. That risk without remedies/recourse is not something commercial= entities are prone to voluntarily accept.=0A= =0A= Obviously, each operator should seek advice from their own legal counsel as= to the risks and make their own decisions.=0A= =0A= -shane=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From andy@arin.net Thu Nov 8 03:50:56 2012 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 08E8621F8A55 for ; Thu, 8 Nov 2012 03:50:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hco6GFWcREyb for ; Thu, 8 Nov 2012 03:50:55 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 679ED21F8B68 for ; Thu, 8 Nov 2012 03:50:53 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id B5DDA1651D7; Thu, 8 Nov 2012 06:50:52 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 25A1C1651AD; Thu, 8 Nov 2012 06:50:52 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 8 Nov 2012 06:50:24 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 06:49:31 -0500 From: Andy Newton To: Christopher Morrow Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmy8FCcE8Dzhaka0MZcJTJP7npdxX+YAgAAMpICAAEYPAIBEvmMAgARaKACAJYJGAIAAG/SA Date: Thu, 8 Nov 2012 11:49:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C055DE431D96B4EBD98D415FD8CD83E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 11:50:56 -0000 On 11/8/12 12:09 AM, "Christopher Morrow" wrote: >On Mon, Oct 15, 2012 at 9:21 AM, Andy Newton wrote: >> On 10/12/12 10:53 AM, "Christopher Morrow" >>wrote: >> >>>I think if, in the end, the wg decides to abandon the work that's also >>>fine, but we should have a more structured chat about the topic, that >>>happens around a draft. >> >> >> As the person who specifically asked of the chairs that the draft >>authors >> be allowed to address the issues raised, I'd like specifics on this more >> structured chat. I ask because it is not apparent that the normal means >>of > >I hope (and I think co-chairs hope) that the authors and commentors >can discuss what the problem attempting to be documented is, add the >right words to the document and then we can all decide if documenting >something in an informational RFC that describes a capability that >exists in the system today (and the downsides of executing that >capability) is appropriate. > >it'd be nice, really, to know at the end if there is a reason to NOT >publish something along those lines as well, and if the wg things not >publishing is best, then we'll just wander off and leave the kitten by >the lake on it's own. As I stated before, the author of the document did not engage in the discussion nor has the author done any work to the document to address any of the concerns raised. So I'll ask again, what specifically do you, the chairs, intend to do to facilitate a more "structured" discussion? > >> IETF discussion were attempted. Of the 38 messages regarding the draft >> directly, the draft author only responded 3 times, nor did the author >> engage in any of the side discussions. And the draft submitted as a >> working group document addresses NONE of the issues raised (it is just a >> re-spin with the dates and file name changed). If normal IETF discourse >>is > >that's fine though, right? the author and commentors can work out the >details. No, it is not fine as the author has not engaged in the discussion. > >> being set aside especially when it was not fully engaged, we should also >> be given the exception criteria under which this scenario qualifies when >> others do not. > >don't think there's anything special going on, there was a bunch of >discussion, keep on discussing and if this ends up being publishable >'ok', if not 'ok'. > >Some of the discussion was along the lines of 'you shouldn't do this >because its bad' or 'doing this circumvents the point of the >system'... that's also fine to document. the system seems to have the >capabilities, it'd be nice to know when not to pull the trigger (while >aimed at foot) and when TO pull trigger (downrange is clear). > So then, any document that comes before the working group shall be accepted? Is that the new criteria? -andy From danny@tcb.net Thu Nov 8 04:40:03 2012 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 D17F021F8B0D for ; Thu, 8 Nov 2012 04:40:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qsZSH7AlU-E for ; Thu, 8 Nov 2012 04:40:03 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1D21F84DC for ; Thu, 8 Nov 2012 04:40:03 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id AB54F209E for ; Thu, 8 Nov 2012 12:40:02 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 60C9D441; Thu, 8 Nov 2012 05:40:02 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 07:40:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> To: sidr wg list , Sandra Murphy X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Nov 8 05:40:02 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509ba822199631419710706 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, the+#+I, 0.01000, Subject*changes+#+#+on, 0.01000, Subject*sidr+additions, 0.01000, Murphy+Sandra, 0.01000, with+#+#+of, 0.01000, wrote+I, 0.01000, Subject*and+#+#+agenda, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+#+#+#+AM, 0.01000, To*wg+#+sidr, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, Subject*on+Friday, 0.01000, the+#+to, 0.01000, To*list+#+ietf.org, 0.01000, Subject*changes+#+agenda, 0.01000, Subject*Re+#+additions, 0.01000, Mime-Version*Apple+#+framework, 0.01000, AM+#+#+wrote, 0.01000, Murphy+#+wrote, 0.01000, the+#+#+of, 0.01000, Subject*Re+#+#+and, 0.01000, Subject*sidr+#+#+changes, 0.01000, at+#+#+#+Murphy, 0.01000, and+#+#+and, 0.01000, Subject*and+#+#+#+on, 0.01000 Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 12:40:04 -0000 On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote: > I doubt whether any of them have felt the need to carefully evaluate = the risks or consult their legal departments.=20 And therein lies the disconnect! =20 I think it'd be extremely naive to think that operators don't know, or = care about, or evaluate the risks of the systems that enable their = operations. If this weren't the case, many of those folks that have = expressed concern here would not do so. Given that our services and businesses rely on these systems with = varying levels of buffers, I assure you that _many [most] operators DO = carefully evaluate the risks and consult their legal departments. This = isn't simply a science project. > I don't think we want people asking ISPs that use IRRs why they run = such a risky operation. I think that's exactly what we want. That's the purpose of engineering = and risk management, and why operators that operate commercial networks, = care a whole lot when you introduce a new dependency.=20 -danny= From Sandra.Murphy@sparta.com Thu Nov 8 05:17:41 2012 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 B816621F8B87 for ; Thu, 8 Nov 2012 05:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzRnyLiawHq6 for ; Thu, 8 Nov 2012 05:17:41 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 47E7521F8B7E for ; Thu, 8 Nov 2012 05:17:41 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA8DHeQR017506; Thu, 8 Nov 2012 05:17:40 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA8DHeJm007548; Thu, 8 Nov 2012 05:17:40 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 08:17:40 -0500 From: "Murphy, Sandra" To: Danny McPherson , sidr wg list Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: Ac28OrfR/Q8DzNS0SPC8tLa/5HdiAQBBRRiAAA01X4AABlAIAAAEq3BNAA3im4D//7TsTQ== Date: Thu, 8 Nov 2012 13:17:39 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 13:17:41 -0000 Shane's message said that reliance on outside parties was a risk. I was po= inting out that operators already are relying on outside parties. Whatever= means they employ now to evaluate risk or legal impact, they are comfortab= le with outside parties.=0A= =0A= If operators always consult their legal departments on deploying new featur= es, then there is no need to advise them to consult their legal departments= .=0A= =0A= Tutorials galore urging use of route filters (and drafts describing same) n= ever find it necessary to add "and consult your legal department". Perhaps= as you say, that is because operators always consult their legal departmen= ts. But if so, this is no different.=0A= =0A= --Sandy, speaking as regular ol' member=0A= ________________________________________=0A= From: Danny McPherson [danny@tcb.net]=0A= Sent: Thursday, November 08, 2012 7:40 AM=0A= To: sidr wg list; Murphy, Sandra=0A= Subject: Re: [sidr] additions and changes to agenda on Friday=0A= =0A= On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:=0A= =0A= > I doubt whether any of them have felt the need to carefully evaluate the = risks or consult their legal departments.=0A= =0A= And therein lies the disconnect!=0A= =0A= I think it'd be extremely naive to think that operators don't know, or care= about, or evaluate the risks of the systems that enable their operations. = If this weren't the case, many of those folks that have expressed concern = here would not do so.=0A= =0A= Given that our services and businesses rely on these systems with varying l= evels of buffers, I assure you that _many [most] operators DO carefully eva= luate the risks and consult their legal departments. This isn't simply a s= cience project.=0A= =0A= > I don't think we want people asking ISPs that use IRRs why they run such = a risky operation.=0A= =0A= I think that's exactly what we want. That's the purpose of engineering and= risk management, and why operators that operate commercial networks, care = a whole lot when you introduce a new dependency.=0A= =0A= -danny=0A= From Sandra.Murphy@sparta.com Thu Nov 8 05:21:55 2012 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 39B8121F8BA9 for ; Thu, 8 Nov 2012 05:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm7B9-NTiPXM for ; Thu, 8 Nov 2012 05:21:54 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB9321F8BA7 for ; Thu, 8 Nov 2012 05:21:54 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA8DLgF6017545; Thu, 8 Nov 2012 05:21:42 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA8DLfg1007593; Thu, 8 Nov 2012 05:21:41 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 08:21:41 -0500 From: "Murphy, Sandra" To: Andy Newton , Christopher Morrow Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdxGn+dgACVHQD//74d04BFA0IAgASt+QCAJS52AIAAb8iA//+vkRU= Date: Thu, 8 Nov 2012 13:21:39 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BFB@Hermes.columbia.ads.sparta.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 13:21:55 -0000 >the author of the document did not engage in the=0A= >discussion=0A= =0A= As Yakov was fond of saying, "send text". Authors of wg drafts are suppose= d to represent consensus. =0A= =0A= >nor has the author done any work to the document to address any=0A= >of the concerns raised.=0A= =0A= Ironically, there was a recent discussion on the wgchairs list about ensuri= ng that a recently adopted draft was submitted with NO changes from its ind= ividual draft form.=0A= =0A= Calls for adoption are not calls for acceptance of the draft content, just = a call to work on the topic. Certainly the discussion demonstrated that pe= ople thought this was important.=0A= =0A= >So then, any document that comes before the working group shall be=0A= >accepted?=0A= =0A= A topic that generates a fire storm of discussion has a good chance. Nothi= ng like actively working on a topic to demonstrate interest in working on t= he topic.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Andy Newton [andy@arin.net]=0A= Sent: Thursday, November 08, 2012 6:49 AM=0A= To: Christopher Morrow=0A= Cc: Murphy, Sandra; Alexey Melnikov; sidr@ietf.org=0A= Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting= =0A= =0A= On 11/8/12 12:09 AM, "Christopher Morrow" wrote:= =0A= =0A= >On Mon, Oct 15, 2012 at 9:21 AM, Andy Newton wrote:=0A= >> On 10/12/12 10:53 AM, "Christopher Morrow" =0A= >>wrote:=0A= >>=0A= >>>I think if, in the end, the wg decides to abandon the work that's also= =0A= >>>fine, but we should have a more structured chat about the topic, that=0A= >>>happens around a draft.=0A= >>=0A= >>=0A= >> As the person who specifically asked of the chairs that the draft=0A= >>authors=0A= >> be allowed to address the issues raised, I'd like specifics on this more= =0A= >> structured chat. I ask because it is not apparent that the normal means= =0A= >>of=0A= >=0A= >I hope (and I think co-chairs hope) that the authors and commentors=0A= >can discuss what the problem attempting to be documented is, add the=0A= >right words to the document and then we can all decide if documenting=0A= >something in an informational RFC that describes a capability that=0A= >exists in the system today (and the downsides of executing that=0A= >capability) is appropriate.=0A= >=0A= >it'd be nice, really, to know at the end if there is a reason to NOT=0A= >publish something along those lines as well, and if the wg things not=0A= >publishing is best, then we'll just wander off and leave the kitten by=0A= >the lake on it's own.=0A= =0A= As I stated before, the author of the document did not engage in the=0A= discussion nor has the author done any work to the document to address any= =0A= of the concerns raised.=0A= =0A= So I'll ask again, what specifically do you, the chairs, intend to do to=0A= facilitate a more "structured" discussion?=0A= =0A= >=0A= >> IETF discussion were attempted. Of the 38 messages regarding the draft= =0A= >> directly, the draft author only responded 3 times, nor did the author=0A= >> engage in any of the side discussions. And the draft submitted as a=0A= >> working group document addresses NONE of the issues raised (it is just a= =0A= >> re-spin with the dates and file name changed). If normal IETF discourse= =0A= >>is=0A= >=0A= >that's fine though, right? the author and commentors can work out the=0A= >details.=0A= =0A= No, it is not fine as the author has not engaged in the discussion.=0A= =0A= >=0A= >> being set aside especially when it was not fully engaged, we should also= =0A= >> be given the exception criteria under which this scenario qualifies when= =0A= >> others do not.=0A= >=0A= >don't think there's anything special going on, there was a bunch of=0A= >discussion, keep on discussing and if this ends up being publishable=0A= >'ok', if not 'ok'.=0A= >=0A= >Some of the discussion was along the lines of 'you shouldn't do this=0A= >because its bad' or 'doing this circumvents the point of the=0A= >system'... that's also fine to document. the system seems to have the=0A= >capabilities, it'd be nice to know when not to pull the trigger (while=0A= >aimed at foot) and when TO pull trigger (downrange is clear).=0A= >=0A= =0A= So then, any document that comes before the working group shall be=0A= accepted? Is that the new criteria?=0A= =0A= -andy=0A= =0A= From danny@tcb.net Thu Nov 8 05:39:50 2012 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 F0FA421F8A69 for ; Thu, 8 Nov 2012 05:39:50 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4zHwPDG1WBX for ; Thu, 8 Nov 2012 05:39:50 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 8F87521F8A55 for ; Thu, 8 Nov 2012 05:39:50 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 00E91209F for ; Thu, 8 Nov 2012 13:39:49 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 5E9D9449; Thu, 8 Nov 2012 06:39:49 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BFB@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 08:39:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5EAD8147-2EEF-45B8-938F-1D2CC5C5830F@tcb.net> References: , <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BFB@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Nov 8 06:39:49 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509bb625199631073215858 X-DSPAM-Factors: 27, the+#+I, 0.01000, to+#+#+in, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, to+#+this, 0.01000, Murphy+Sandra, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+#+#+#+AM, 0.01000, this+is, 0.01000, a+#+to, 0.01000, 2012+at, 0.01000, Cc*sidr+wg, 0.01000, the+#+#+a, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, Mime-Version*Apple+#+framework, 0.01000, To*Sandra+#+sparta.com, 0.01000, AM+#+#+wrote, 0.01000, Murphy+#+wrote, 0.01000, Cc*wg+#+sidr, 0.01000, at+#+#+#+Murphy, 0.01000, Mime-Version*1.0+Apple, 0.01000, the+#+for, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000, on+the, 0.01000, in+the, 0.01000, in+#+#+that, 0.01000 Cc: sidr wg list Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 13:39:51 -0000 On Nov 8, 2012, at 8:21 AM, Murphy, Sandra wrote: > A topic that generates a fire storm of discussion has a good chance. = Nothing like actively working on a topic to demonstrate interest in = working on the topic. I do NOT support adoption of this. It creates the opportunity for = collisions in the system that a relying party has no capability to = resolve. =20 AS0-esque hacks make this even worse. If the CA or some "grandparent" wants to provide this capability there = are ways they can do this. Quite frankly, this is why I like delegation models where you can't do = this (e.g., DNS-esque). -danny =20= From danny@tcb.net Thu Nov 8 05:44:26 2012 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 6CD3221F8B0C for ; Thu, 8 Nov 2012 05:44:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY1Z9SMdkeV3 for ; Thu, 8 Nov 2012 05:44:26 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 09CFB21F8AEF for ; Thu, 8 Nov 2012 05:44:26 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 663E1209E for ; Thu, 8 Nov 2012 13:44:25 +0000 (UTC) Received: from dhcp-17b7.meeting.ietf.org (dhcp-17b7.meeting.ietf.org [130.129.23.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 252D3449; Thu, 8 Nov 2012 06:44:25 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 08:44:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Nov 8 06:44:25 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509bb739199637483814704 X-DSPAM-Factors: 27, Cc*sidr+#+#+#+ietf.org, 0.01000, Subject*changes+#+#+on, 0.01000, Subject*sidr+additions, 0.01000, Murphy+Sandra, 0.01000, Subject*and+#+#+agenda, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+#+#+#+AM, 0.01000, 2012+at, 0.01000, Subject*on+Friday, 0.01000, Cc*sidr+wg, 0.01000, Subject*changes+#+agenda, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, Subject*Re+#+additions, 0.01000, Mime-Version*Apple+#+framework, 0.01000, To*Sandra+#+sparta.com, 0.01000, AM+#+#+wrote, 0.01000, Murphy+#+wrote, 0.01000, Cc*wg+#+sidr, 0.01000, Subject*Re+#+#+and, 0.01000, Subject*sidr+#+#+changes, 0.01000, is+#+#+to, 0.01000, at+#+#+#+Murphy, 0.01000, Subject*and+#+#+#+on, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 13:44:26 -0000 On Nov 8, 2012, at 8:17 AM, Murphy, Sandra wrote: > Shane's message said that reliance on outside parties was a risk. I = was pointing out that operators already are relying on outside parties. = Whatever means they employ now to evaluate risk or legal impact, they = are comfortable with outside parties. That's a rather liberal use of "comfortable", methinks. > If operators always consult their legal departments on deploying new = features, then there is no need to advise them to consult their legal = departments. This is incorrect. =20 It's "Risks to our business" -- "risks" is plural, and new risks that do = not lessen overall residual threats are problematic in real companies, = especially public ones. -danny= From alexey.melnikov@isode.com Thu Nov 8 05:51:37 2012 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 C52B121F8B7D for ; Thu, 8 Nov 2012 05:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hObNHdS7OYHK for ; Thu, 8 Nov 2012 05:51:36 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id AF41F21F8B7E for ; Thu, 8 Nov 2012 05:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1352382694; d=isode.com; s=selector; i=@isode.com; bh=dk0Ixcl7gHa1hQ3S/ndzcM1Gjkmgmr4K+z4LD9q9Yg0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RdyGsKKBBdGamN0yFmBJoS+p3l7I+17NO1cyfWQxEZze4lAR79MsYnUPVPIJtSPm2uPaO+ zf7V7PzVjrqJ1VFhmTKnEhZLkje6Rzqj5Lnxm0Bi+/SUiMo788jgeJoNUlTylBhFBK+cYd j3OJgdKbO2UKvFimbgIrD3yMvqqBv00=; Received: from [130.129.18.182] (dhcp-12b6.meeting.ietf.org [130.129.18.182]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 8 Nov 2012 13:51:33 +0000 Message-ID: <509BB8EF.7040901@isode.com> Date: Thu, 08 Nov 2012 13:51:43 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: sidr wg MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] draft-ietf-sidr-algorithm-agility submitted to AD for publication 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 Nov 2012 13:51:37 -0000 I've reviewed the mailing list discussion a year ago and I think that comments raised on the mailing list were addressed. There was an alternative procedure suggested on the mailing list, but I haven't see any support for it from others on the mailing list. So I wrote the shepherding write-up and requested document publication by our responsible AD. If you believe that the above is an error, please email me and my co-chairs at sidr-chairs@tools.ietf.org. Best Regards, Alexey, as a SIDR co-chair. From shane@castlepoint.net Thu Nov 8 06:01:10 2012 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 7AF0A21F887F for ; Thu, 8 Nov 2012 06:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJCis-eR0BUf for ; Thu, 8 Nov 2012 06:01:09 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id A73AD21F8462 for ; Thu, 8 Nov 2012 06:01:09 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D9DE8209F for ; Thu, 8 Nov 2012 14:01:08 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 8FE94441; Thu, 8 Nov 2012 07:01:07 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 09:01:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <07B1B4AA-0D73-4D10-AEE5-C393FA6D620C@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 8 07:01:08 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509bbb24199637612012456 X-DSPAM-Factors: 27, to+#+#+#+an, 0.01000, Nov+8, 0.01000, into+their, 0.01000, them+into, 0.01000, most+of, 0.01000, dominant+use, 0.01000, to+#+#+in, 0.01000, 8+#+at, 0.01000, be+#+#+try, 0.01000, Subject*changes+#+#+on, 0.01000, to+#+to, 0.01000, On+#+7, 0.01000, would+not, 0.01000, Subject*sidr+additions, 0.01000, Mime-Version*OS+X, 0.01000, and+or, 0.01000, RPKI+and, 0.01000, to+#+this, 0.01000, to+#+this, 0.01000, not+be, 0.01000, force+#+into, 0.01000, about+this, 0.01000, and+#+#+are, 0.01000, Murphy+Sandra, 0.01000, Murphy+Sandra, 0.01000, with+#+#+of, 0.01000, Subject*and+#+#+agenda, 0.01000 Cc: "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 14:01:10 -0000 Sandy, On Nov 8, 2012, at 6:25 AM, "Murphy, Sandra" = wrote: > Speaking as regular ol' member >=20 > On Wednesday, November 07, 2012 10:48 PM, Shane Amante = [shane@castlepoint.net] said: >=20 >> Commercial operators, in particular, should carefully evaluate the = risks posed to >> their core business (selling Internet transit) by now being reliant = on certificate=20 >> information that directly affects _reachability_information_ carried = within their=20 >> network. That certificate information is maintained by an outside = party that's=20 >> outside the operator organization's _direct_ (immediate) control and = for >> which they, seemingly, have no recourse if (when?) something goes = wrong. >=20 > I think the Internet is already there. >=20 > There are ISPs that spend considerable energy creating prefix filters = from IRR data and strongly encourage their customers to register in = IRRs. Those registers are maintained by an outside party that's outside = the operator organization's direct control. Those registered objects = directly affect reachability information carried within their network. >=20 > Commercial operators have been comfortable with this mode of operation = for many years. I doubt whether any of them have felt the need to = carefully evaluate the risks or consult their legal departments. It has = been best current practice and urged on operators at *OG meetings. >=20 > I don't think we want people asking ISPs that use IRRs why they run = such a risky operation. >=20 > --Sandy, speaking as regular ol' member There is not, in my understanding, a single root for the IRR's. = Although RIR's for a particular region do allocate and register those = resources (IP prefixes, ASN's, etc.) into their respective IRR instance = ... there is absolutely nothing stopping the resource holder from = registering their resources in one, or more, "3rd-party IRR" instances = /not/ run or controlled by any RIR, i.e.: RADB, ALT.DB, etc. IMO, the = ability to do that constitutes "risk mitigation" on the part of the = resource holder who publishes their objects (customer) as well as the = _direct_ ISP's (from whom their buy service) that consume those objects, = since there is no single, central authority with direct control over = their business. That said, I acknowledge the downside with the present IRR model is = that, in most instances, no IRR can express authority for the resources = held in their IRR DB. IMO, that creates a problem for /3rd-parties/ -- = researchers, LEO, etc. -- who have no direct (contractual) relationship = with both the ISP and their customer, since those third-parties have a = difficult time in understanding which IRR to believe has the most = up-to-date copy of resources. However, keep in mind (and this is key = here), that each ISP *does* have a direct contractual relationship with = its customers. At the time such contracts are signed, the customer must = tell the ISP which specific IRR instance(s) the customer has registered = and maintains their IRR objects, which gets around at least /part/ (but, = not all) of the problem. =20 Before you respond with: each RP (ISP) in the RPKI system is free to = choose whatever TA's they want to mitigate such risks -- I would ask: if = ISP's did that, how is that /any/ different from the operation of the = present-day IRR model? IMO, it's not clear that the RPKI is "fixing" = anything, unless everyone voluntarily or _involuntarily_ accepts a = single-rooted RPKI as the sole source of resource information ... As with many things, risk is subjective and each party in a system = should decide for themselves what constitutes acceptable risk for their = operations. -shane P.S. -- I apologize for having veered off of technical topics for an = IETF mailing list. I will refrain from responding to this thread = further. > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Shane = Amante [shane@castlepoint.net] > Sent: Wednesday, November 07, 2012 10:48 PM > To: Michael Sinatra > Cc: sidr@ietf.org; Murphy, Sandra > Subject: Re: [sidr] additions and changes to agenda on Friday >=20 > Michael, >=20 > On Nov 7, 2012, at 7:48 PM, Michael Sinatra = wrote: >> On 11/07/2012 10:29, Danny McPherson wrote: >>=20 >>> Sandy, Can you elaborate what your "concerns about this agreement's >>> impact on the envisioned RPKI architecture and dominant use" are? = Do >>> you have a reference or outline we can review prior to the = discussion >>> in order to keep this from being a >>> = bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuf= f >>> fest? >>=20 >> In addition to Sandy's concerns, the agreement contains a third-party = indemnification clause (as do other ARIN RPKI-related agreements) that = makes it difficult for many state and federal government (and large = EDUs) to simply click through and sign. In most of these environments, = the network engineers who would be wanting to try out RPKI would not be = permitted to agree to such indemnification. This may also be true at = large corporations. >>=20 >> This, I think, has very little architectural impact, but it does mean = additional hoops for operators (like myself) to experiment with RPKI = and/or put it in production. As such, further discussion is probably = out of scope for SIDR, and I will take this to arin-discuss@ = accordingly. But I did want to give this group an FYI that this may be = at least a speed-bump on the deployment front. >=20 >=20 > I (also) commend ARIN for their due diligence on this matter. = Commercial operators, in particular, should carefully evaluate the risks = posed to their core business (selling Internet transit) by now being = reliant on certificate information that directly affects = _reachability_information_ carried within their network. That = certificate information is maintained by an outside party that's outside = the operator organization's _direct_ (immediate) control and for which = they, seemingly, have no recourse if (when?) something goes wrong. That = risk without remedies/recourse is not something commercial entities are = prone to voluntarily accept. >=20 > Obviously, each operator should seek advice from their own legal = counsel as to the risks and make their own decisions. >=20 > -shane > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From Sandra.Murphy@sparta.com Thu Nov 8 06:37:19 2012 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 B853F21F8A84 for ; Thu, 8 Nov 2012 06:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdIA9jmvnweo for ; Thu, 8 Nov 2012 06:37:19 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 416A921F8A78 for ; Thu, 8 Nov 2012 06:37:19 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA8EbIcM018260; Thu, 8 Nov 2012 06:37:18 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA8EbI57008456; Thu, 8 Nov 2012 06:37:18 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 09:37:18 -0500 From: "Murphy, Sandra" To: Danny McPherson Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: Ac28OrfR/Q8DzNS0SPC8tLa/5HdiAQBBRRiAAA01X4AABlAIAAAEq3BNAA3im4D//7TsTYAAXREA//+6C7w= Date: Thu, 8 Nov 2012 14:37:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CCF@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com>, <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> In-Reply-To: <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 14:37:19 -0000 On Thursday, November 08, 2012 8:44 AM, Danny McPherson [danny@tcb.net] sai= d:=0A= =0A= =0A= =0A= >> If operators always consult their legal departments on deploying new fea= tures, =0A= >>then there is no need to advise them to consult their legal departments.= =0A= >=0A= >This is incorrect.=0A= >=0A= >It's "Risks to our business" -- "risks" is plural, and new risks that do n= ot lessen =0A= >overall residual threats are problematic in real companies, especially pub= lic ones.=0A= =0A= I think you may have misread my statement. I did not say there was no need= to consult their legal departments. I said there was no need to advise th= em to consult their legal department. Your thesis was that they always do.= So no need to tell then to do it.=0A= =0A= --Sandy= From andy@arin.net Thu Nov 8 06:39:22 2012 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 5721E21F8ADD for ; Thu, 8 Nov 2012 06:39:22 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adsq8cq+CqEJ for ; Thu, 8 Nov 2012 06:39:21 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id AE75A21F8A65 for ; Thu, 8 Nov 2012 06:39:21 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 30B8121366D; Thu, 8 Nov 2012 09:39:21 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id A034D2135A0; Thu, 8 Nov 2012 09:39:20 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 8 Nov 2012 09:39:01 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 09:38:12 -0500 From: Andy Newton To: "Murphy, Sandra" , Christopher Morrow Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmy8FCcE8Dzhaka0MZcJTJP7npdxX+YAgAAMpICAAEYPAIBEvmMAgARaKACAJYJGAIAAG/SAgABtkoD//8GOgA== Date: Thu, 8 Nov 2012 14:38:12 +0000 Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BFB@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <4916817E2423CE4689722A0597413FD8@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 14:39:22 -0000 On 11/8/12 8:21 AM, "Murphy, Sandra" wrote: >>the author of the document did not engage in the >>discussion > >As Yakov was fond of saying, "send text". Authors of wg drafts are >supposed to represent consensus. If this is true, then the current document should be blank since it does not represent consensus. Also are you now saying that the author does not need to participate in the discussion since he can now only represent consensus decisions? If so, that would mean the author of this draft has been able to completely avoid addressing any of the issues raised. That strikes me as not being the IETF way. > >A topic that generates a fire storm of discussion has a good chance. >Nothing like actively working on a topic to demonstrate interest in >working on the topic. Thank you for clarifying this. For confirmation, in the future any draft put forward to SIDR that generates "interest" but not necessarily rough consensus will be admitted as a working group document. Is that correct? -andy From Sandra.Murphy@sparta.com Thu Nov 8 06:57:18 2012 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 600D121F890A for ; Thu, 8 Nov 2012 06:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0CHoUQm5gst for ; Thu, 8 Nov 2012 06:57:17 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E14521F8B2F for ; Thu, 8 Nov 2012 06:57:16 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA8EvEWJ012833; Thu, 8 Nov 2012 08:57:14 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA8EvDML030506; Thu, 8 Nov 2012 08:57:14 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 09:57:13 -0500 From: "Murphy, Sandra" To: Andy Newton , Christopher Morrow Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdxGn+dgACVHQD//74d04BFA0IAgASt+QCAJS52AIAAb8iA//+vkRWAAH+QAP//roiy Date: Thu, 8 Nov 2012 14:57:12 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CF8@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BFB@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 14:57:18 -0000 >Thank you for clarifying this. For confirmation, in the future any draft= =0A= >put forward to SIDR that generates "interest" but not necessarily rough=0A= >consensus will be admitted as a working group document. Is that correct?= =0A= =0A= The point of a call for adoption is to see if the working group is interest= ed in working on a topic, not to achieve consensus on content. Calls for a= doption are not (supposed) to discuss content. =0A= =0A= Are you sure you are not thinking of wglc, where consensus on the content i= s needed?=0A= =0A= And I said it generated "a first storm of discussion", not "interest".=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Andy Newton [andy@arin.net]=0A= Sent: Thursday, November 08, 2012 9:38 AM=0A= To: Murphy, Sandra; Christopher Morrow=0A= Cc: Alexey Melnikov; sidr@ietf.org=0A= Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting= =0A= =0A= On 11/8/12 8:21 AM, "Murphy, Sandra" wrote:=0A= =0A= >>the author of the document did not engage in the=0A= >>discussion=0A= >=0A= >As Yakov was fond of saying, "send text". Authors of wg drafts are=0A= >supposed to represent consensus.=0A= =0A= If this is true, then the current document should be blank since it does=0A= not represent consensus.=0A= =0A= Also are you now saying that the author does not need to participate in=0A= the discussion since he can now only represent consensus decisions? If so,= =0A= that would mean the author of this draft has been able to completely avoid= =0A= addressing any of the issues raised. That strikes me as not being the IETF= =0A= way.=0A= =0A= >=0A= >A topic that generates a fire storm of discussion has a good chance.=0A= >Nothing like actively working on a topic to demonstrate interest in=0A= >working on the topic.=0A= =0A= Thank you for clarifying this. For confirmation, in the future any draft=0A= put forward to SIDR that generates "interest" but not necessarily rough=0A= consensus will be admitted as a working group document. Is that correct?=0A= =0A= -andy=0A= =0A= From arturo.servin@gmail.com Thu Nov 8 07:13:03 2012 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 DC50421F85F4 for ; Thu, 8 Nov 2012 07:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPrmnZ1waQBZ for ; Thu, 8 Nov 2012 07:13:03 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 31AF721F85A1 for ; Thu, 8 Nov 2012 07:13:03 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2237683pbb.31 for ; Thu, 08 Nov 2012 07:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9QWEnNAMjx4b69x89rATHdmoiTsukktkQv7n7TfsW0Q=; b=ZjdYojWY4vk6aFm6cqmTG4m37IalsgyW0KnnsYC0Nt8cD2ImPrtCkMhkV1a6oTumEl UlbDZ12EgcLAPM0kqlH3M45DJs0lcY3PoTmzzOOuFT/L/cHAFrbag2IsyqqARwpDJ4PV hG2smDS9WMj8JDoyN7NtCc7x8qUhewj4HyfpQJHb9b3/wzwMgRoEvjsOaVdpeFXSXxMh z26zbdzbezQnhu1JEqwD+FYf4j+mPyuNYE3FVv/rWuvuup6RiwZ8hSVqdqDW08X8wd8/ vfAI3v62FFIluj8XCPYQ6CKiDTfHPMXXVhg2diOeK8yu5zSgikIjO+1x9M+1bp7p4MAU r7LQ== Received: by 10.68.134.130 with SMTP id pk2mr24806910pbb.31.1352387577725; Thu, 08 Nov 2012 07:12:57 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org (dhcp-16f2.meeting.ietf.org. [130.129.22.242]) by mx.google.com with ESMTPS id k9sm16264483paz.22.2012.11.08.07.12.55 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 07:12:56 -0800 (PST) Message-ID: <509BCBF5.3030406@gmail.com> Date: Thu, 08 Nov 2012 10:12:53 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 15:13:04 -0000 On 07/11/2012 21:09, Randy Bush wrote: >> In your example, is sita taking on this responsibility on behalf of rama >> and hanuman? > > no need. this is object based security. rama and hanuman have tals and > validate. having every cache in the world hit the CAs is not gonna > scale. Yes, perhaps we need a different architecture and transport protocol. But that is beyond this thread and topic. > > you may want to look at my ripe and nanog presos on the scaling > experiments we did. More arguments to think on alternate paths. as > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From andy@arin.net Thu Nov 8 07:41:48 2012 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 B0F6921F85B2 for ; Thu, 8 Nov 2012 07:41:48 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3b9YmPy3WSS for ; Thu, 8 Nov 2012 07:41:48 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id E9AF021F8432 for ; Thu, 8 Nov 2012 07:41:47 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 5CCA01651CB; Thu, 8 Nov 2012 10:41:47 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id CA52D1651A3; Thu, 8 Nov 2012 10:41:46 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 8 Nov 2012 10:41:34 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 10:41:46 -0500 From: Andy Newton To: "Murphy, Sandra" , Christopher Morrow Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmy8FCcE8Dzhaka0MZcJTJP7npdxX+YAgAAMpICAAEYPAIBEvmMAgARaKACAJYJGAIAAG/SAgABtkoD//8GOgIAAWSQA//+4oAA= Date: Thu, 8 Nov 2012 15:41:45 +0000 Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CF8@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B953C8910DC9F489A07046FE64EC4BB@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 15:41:48 -0000 On 11/8/12 9:57 AM, "Murphy, Sandra" wrote: >>Calls for adoption are not (supposed) to discuss content. Thanks for that clarification. The IETF is a deliberative body, and I was under the impression that discussion at any point in the process, though not optimal, was acceptable. I did not realize SIDR had deviated. >Are you sure you are not thinking of wglc, where consensus on the content >is needed? I'm pretty sure I understand the difference between WGLC and wg document acceptance. What I am uncertain about is the criteria for working group document acceptance in SIDR. >And I said it generated "a first storm of discussion", not "interest". So, is "a fire storm of discussion" the threshold for document acceptance? If a document fails to generate such a storm, will it not be accepted? Since ROVER did generate a storm, will you be accepting it as a working group document? Again, I'm trying to determine the criteria upon which the chairs accept a document as a working group item. I do find "a fire storm of discussion" to be a unique threshold. I'll note that you did say, "Nothing like actively working on a topic to demonstrate interest in working on the topic." Hence my confusion. -andy From Sandra.Murphy@sparta.com Thu Nov 8 07:44:39 2012 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 21ECA21F89FE for ; Thu, 8 Nov 2012 07:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1voxS3A1HNHm for ; Thu, 8 Nov 2012 07:44:38 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1582021F89A3 for ; Thu, 8 Nov 2012 07:44:37 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA8FibVt013247 for ; Thu, 8 Nov 2012 09:44:37 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA8FibgN032049 for ; Thu, 8 Nov 2012 09:44:37 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 10:44:36 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: please number your slides Thread-Index: Ac29x/Rk3OZwVDWZSjOl686YW8YoMg== Date: Thu, 8 Nov 2012 15:44:36 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9D88@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] please number your slides 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 Nov 2012 15:44:39 -0000 Please all those submitting slides - please number your slides.=0A= =0A= --Sandy, speaking as wg co-chair= From danny@tcb.net Thu Nov 8 07:54:11 2012 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 3261721F8508 for ; Thu, 8 Nov 2012 07:54:11 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naJa36yuwqZ7 for ; Thu, 8 Nov 2012 07:54:10 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC2A21F848D for ; Thu, 8 Nov 2012 07:54:10 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 0A71120AA for ; Thu, 8 Nov 2012 15:54:08 +0000 (UTC) Received: from [172.17.4.250] (209-23-246-1-ip-static.hfc.comcastbusiness.net [209.23.246.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B3CFE20A9; Thu, 8 Nov 2012 08:54:07 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CCF@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 10:54:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <25C89C42-1B53-4107-BFFF-13F0E47AFD7E@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com>, <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CCF@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Nov 8 08:54:07 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509bd59f199633298710718 X-DSPAM-Factors: 27, Nov+8, 0.01000, Nov+8, 0.01000, the+#+I, 0.01000, think+that, 0.01000, a+#+lot, 0.01000, 8+#+at, 0.01000, 8+#+at, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Subject*changes+#+#+on, 0.01000, would+not, 0.01000, Subject*sidr+additions, 0.01000, the+risks, 0.01000, the+risks, 0.01000, Murphy+Sandra, 0.01000, Murphy+Sandra, 0.01000, with+#+#+of, 0.01000, with+#+#+of, 0.01000, wrote+I, 0.01000, wrote+I, 0.01000, Subject*and+#+#+agenda, 0.01000, Mime-Version*Message+#+v1283, 0.01000, wrote+#+#+you, 0.01000, 2012+#+#+#+AM, 0.01000, 2012+#+#+#+AM, 0.01000, and+#+#+that, 0.01000, Murphy+#+#+I, 0.01000, Murphy+#+#+I, 0.01000 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 15:54:11 -0000 On Nov 8, 2012, at 9:37 AM, Murphy, Sandra wrote: >=20 > I think you may have misread my statement. No, I didn't: On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote: "I doubt whether any of them have felt the need to carefully evaluate = the risks or consult their legal departments."=20 In response: November 8, 2012 7:40:11 AM EST, I said: "Given that our services and businesses rely on these systems with = varying levels of buffers, I assure you that _many [most] operators DO = carefully evaluate the risks and consult their legal departments." > I did not say there was no need to consult their legal departments. = I said there was no need to advise them to consult their legal = department. > Your thesis was that they always do. =20 No, it wasn't - go reread [1], or see text above. Please don't tell me = what I said, and please don't assume operators are naive. -danny [1] inline below: Begin forwarded message: > From: Danny McPherson > Subject: Re: [sidr] additions and changes to agenda on Friday > Date: November 8, 2012 7:40:11 AM EST > To: sidr wg list , Sandra Murphy = >=20 >=20 > On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote: >=20 >> I doubt whether any of them have felt the need to carefully evaluate = the risks or consult their legal departments.=20 >=20 > And therein lies the disconnect! =20 >=20 > I think it'd be extremely naive to think that operators don't know, or = care about, or evaluate the risks of the systems that enable their = operations. If this weren't the case, many of those folks that have = expressed concern here would not do so. >=20 > Given that our services and businesses rely on these systems with = varying levels of buffers, I assure you that _many [most] operators DO = carefully evaluate the risks and consult their legal departments. This = isn't simply a science project. >=20 >> I don't think we want people asking ISPs that use IRRs why they run = such a risky operation. >=20 > I think that's exactly what we want. That's the purpose of = engineering and risk management, and why operators that operate = commercial networks, care a whole lot when you introduce a new = dependency.=20 >=20 > -danny From Sandra.Murphy@sparta.com Thu Nov 8 07:54:24 2012 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 605BC21F8AEA for ; Thu, 8 Nov 2012 07:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgvGdKrEdGq5 for ; Thu, 8 Nov 2012 07:54:23 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id C667321F8536 for ; Thu, 8 Nov 2012 07:54:22 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA8FsG29019083; Thu, 8 Nov 2012 07:54:16 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA8FsGN1009504; Thu, 8 Nov 2012 07:54:16 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 10:54:15 -0500 From: "Murphy, Sandra" To: Christopher Morrow Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmzBDgLmICzaeEOZLRGrqn0RiJdxGn+dgACVHQD//74d04BFA0IAgASt+QCAJS52AIAAb8iA//+vkRWAAH+QAP//roiyAAxnQ4D//6+HLg== Date: Thu, 8 Nov 2012 15:54:15 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DA7@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CF8@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 15:54:25 -0000 >>Calls for adoption are not (supposed) to discuss content.=0A= >=0A= >Thanks for that clarification. The IETF is a deliberative body, and I was= =0A= >under the impression that discussion at any point in the process, though= =0A= >not optimal, was acceptable. I did not realize SIDR had deviated.=0A= =0A= I did not say discussion was prohibited. That "supposed" is as in "suppose= dly".=0A= =0A= Calls for adoption are to indicate interest in working on a topic. The int= ent of a call for adoption is not consensus on the content. Review of the = content is not the purpose of a call for adoption.=0A= =0A= I know I've said something like this before in calls for adoption. This sh= ould not be a surprise.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Andy Newton [andy@arin.net]=0A= Sent: Thursday, November 08, 2012 10:41 AM=0A= To: Murphy, Sandra; Christopher Morrow=0A= Cc: Alexey Melnikov; sidr@ietf.org=0A= Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting= =0A= =0A= On 11/8/12 9:57 AM, "Murphy, Sandra" wrote:=0A= =0A= >>Calls for adoption are not (supposed) to discuss content.=0A= =0A= Thanks for that clarification. The IETF is a deliberative body, and I was= =0A= under the impression that discussion at any point in the process, though=0A= not optimal, was acceptable. I did not realize SIDR had deviated.=0A= =0A= >Are you sure you are not thinking of wglc, where consensus on the content= =0A= >is needed?=0A= =0A= I'm pretty sure I understand the difference between WGLC and wg document=0A= acceptance. What I am uncertain about is the criteria for working group=0A= document acceptance in SIDR.=0A= =0A= >And I said it generated "a first storm of discussion", not "interest".=0A= =0A= So, is "a fire storm of discussion" the threshold for document acceptance?= =0A= If a document fails to generate such a storm, will it not be accepted?=0A= Since ROVER did generate a storm, will you be accepting it as a working=0A= group document? Again, I'm trying to determine the criteria upon which the= =0A= chairs accept a document as a working group item. I do find "a fire storm= =0A= of discussion" to be a unique threshold.=0A= =0A= I'll note that you did say, "Nothing like actively working on a topic to=0A= demonstrate interest in working on the topic." Hence my confusion.=0A= =0A= -andy=0A= =0A= From Sandra.Murphy@sparta.com Thu Nov 8 07:55:34 2012 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 C64DE21F8522 for ; Thu, 8 Nov 2012 07:55:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YiiUdKwxk4O for ; Thu, 8 Nov 2012 07:55:31 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8353621F84EA for ; Thu, 8 Nov 2012 07:55:23 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA8FtMjm013359; Thu, 8 Nov 2012 09:55:22 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA8FtGkf032452; Thu, 8 Nov 2012 09:55:16 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 10:55:16 -0500 From: "Murphy, Sandra" To: Danny McPherson Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: Ac28OrfR/Q8DzNS0SPC8tLa/5HdiAQBBRRiAAA01X4AABlAIAAAEq3BNAA3im4D//7TsTYAAXREA//+6C7yAAGozgP//rF7c Date: Thu, 8 Nov 2012 15:55:16 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DBB@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com>, <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CCF@Hermes.columbia.ads.sparta.com>, <25C89C42-1B53-4107-BFFF-13F0E47AFD7E@tcb.net> In-Reply-To: <25C89C42-1B53-4107-BFFF-13F0E47AFD7E@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 15:55:35 -0000 Sorry, you did not say "all" you said "most"=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Danny McPherson [danny@tcb.net]=0A= Sent: Thursday, November 08, 2012 10:54 AM=0A= To: Murphy, Sandra=0A= Cc: sidr wg list=0A= Subject: Re: [sidr] additions and changes to agenda on Friday=0A= =0A= On Nov 8, 2012, at 9:37 AM, Murphy, Sandra wrote:=0A= >=0A= > I think you may have misread my statement.=0A= =0A= No, I didn't: On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:=0A= =0A= "I doubt whether any of them have felt the need to carefully evaluate the r= isks or consult their legal departments."=0A= =0A= In response: November 8, 2012 7:40:11 AM EST, I said:=0A= =0A= "Given that our services and businesses rely on these systems with varying = levels of buffers, I assure you that _many [most] operators DO carefully ev= aluate the risks and consult their legal departments."=0A= =0A= > I did not say there was no need to consult their legal departments. I = said there was no need to advise them to consult their legal department.=0A= =0A= =0A= > Your thesis was that they always do.=0A= =0A= No, it wasn't - go reread [1], or see text above. Please don't tell me wha= t I said, and please don't assume operators are naive.=0A= =0A= -danny=0A= =0A= =0A= [1] inline below:=0A= =0A= Begin forwarded message:=0A= =0A= > From: Danny McPherson =0A= > Subject: Re: [sidr] additions and changes to agenda on Friday=0A= > Date: November 8, 2012 7:40:11 AM EST=0A= > To: sidr wg list , Sandra Murphy =0A= >=0A= >=0A= > On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:=0A= >=0A= >> I doubt whether any of them have felt the need to carefully evaluate the= risks or consult their legal departments.=0A= >=0A= > And therein lies the disconnect!=0A= >=0A= > I think it'd be extremely naive to think that operators don't know, or ca= re about, or evaluate the risks of the systems that enable their operations= . If this weren't the case, many of those folks that have expressed concer= n here would not do so.=0A= >=0A= > Given that our services and businesses rely on these systems with varying= levels of buffers, I assure you that _many [most] operators DO carefully e= valuate the risks and consult their legal departments. This isn't simply a= science project.=0A= >=0A= >> I don't think we want people asking ISPs that use IRRs why they run such= a risky operation.=0A= >=0A= > I think that's exactly what we want. That's the purpose of engineering a= nd risk management, and why operators that operate commercial networks, car= e a whole lot when you introduce a new dependency.=0A= >=0A= > -danny=0A= =0A= =0A= From danny@tcb.net Thu Nov 8 08:03:26 2012 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 65D3B21F81FF for ; Thu, 8 Nov 2012 08:03:26 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G341Hhua-Cnq for ; Thu, 8 Nov 2012 08:03:26 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7028F21F8B8E for ; Thu, 8 Nov 2012 08:03:04 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id EAC2C20A8 for ; Thu, 8 Nov 2012 16:03:03 +0000 (UTC) Received: from [172.17.4.250] (209-23-246-1-ip-static.hfc.comcastbusiness.net [209.23.246.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 9D6A020A7; Thu, 8 Nov 2012 09:03:03 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DBB@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 11:03:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com>, <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CCF@Hermes.columbia.ads.sparta.com>, <25C89C42-1B53-4107-BFFF-13F0E47AFD7E@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DBB@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Nov 8 09:03:03 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509bd7b7199631608692288 X-DSPAM-Factors: 27, Nov+8, 0.01000, 8+#+at, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Subject*changes+#+#+on, 0.01000, Subject*sidr+additions, 0.01000, the+risks, 0.01000, Murphy+Sandra, 0.01000, Subject*and+#+#+agenda, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+#+#+#+AM, 0.01000, 2012+at, 0.01000, Subject*on+Friday, 0.01000, Cc*sidr+wg, 0.01000, legal+departments, 0.01000, Subject*changes+#+agenda, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, take+this, 0.01000, Subject*Re+#+additions, 0.01000, Mime-Version*Apple+#+framework, 0.01000, the+#+#+#+their, 0.01000, To*Sandra+#+sparta.com, 0.01000, AM+#+#+wrote, 0.01000, carefully+#+the, 0.01000, evaluate+#+#+#+consult, 0.01000, Murphy+#+wrote, 0.01000, On+#+8, 0.01000, Cc*wg+#+sidr, 0.01000 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 16:03:26 -0000 On Nov 8, 2012, at 10:55 AM, Murphy, Sandra wrote: > Sorry, you did not say "all" you said "most" Sandy, could you please not take this out of context? I quoted it = below, but one more time: I said "_many [most] operators DO carefully evaluate the risks and = consult their legal departments." Do you agree with that? -danny= From Sandra.Murphy@sparta.com Thu Nov 8 08:14:54 2012 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 D920E21F884D for ; Thu, 8 Nov 2012 08:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUsxaJDxVdSS for ; Thu, 8 Nov 2012 08:14:54 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5909C21F8AEA for ; Thu, 8 Nov 2012 08:14:54 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA8GErnP019308; Thu, 8 Nov 2012 08:14:53 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA8GEriA009844; Thu, 8 Nov 2012 08:14:53 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 11:14:50 -0500 From: "Murphy, Sandra" To: Danny McPherson Thread-Topic: [sidr] additions and changes to agenda on Friday Thread-Index: Ac28OrfR/Q8DzNS0SPC8tLa/5HdiAQBBRRiAAA01X4AABlAIAAAEq3BNAA3im4D//7TsTYAAXREA//+6C7yAAGozgP//rF7cgABWIYD//66Jpw== Date: Thu, 8 Nov 2012 16:14:49 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9E29@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com>, <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CCF@Hermes.columbia.ads.sparta.com>, <25C89C42-1B53-4107-BFFF-13F0E47AFD7E@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DBB@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 16:14:55 -0000 Sorry, I thought your complaint that I was misquoting was that I had said "= all" when you said "most".=0A= =0A= So your complaint that I am misquoting is... what did I get wrong?=0A= =0A= I'm lost in a maze of twisty passages.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: Danny McPherson [danny@tcb.net]=0A= Sent: Thursday, November 08, 2012 11:03 AM=0A= To: Murphy, Sandra=0A= Cc: sidr wg list=0A= Subject: Re: [sidr] additions and changes to agenda on Friday=0A= =0A= On Nov 8, 2012, at 10:55 AM, Murphy, Sandra wrote:=0A= =0A= > Sorry, you did not say "all" you said "most"=0A= =0A= Sandy, could you please not take this out of context? I quoted it below, b= ut one more time:=0A= =0A= I said "_many [most] operators DO carefully evaluate the risks and consult = their legal departments."=0A= =0A= Do you agree with that?=0A= =0A= -danny=0A= From danny@tcb.net Thu Nov 8 08:17:17 2012 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 DEF7021F8800 for ; Thu, 8 Nov 2012 08:17:17 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb1JIjV5BBaN for ; Thu, 8 Nov 2012 08:17:17 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 74AC521F87E5 for ; Thu, 8 Nov 2012 08:17:17 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id ECD4E20A6 for ; Thu, 8 Nov 2012 16:17:16 +0000 (UTC) Received: from [172.17.4.250] (209-23-246-1-ip-static.hfc.comcastbusiness.net [209.23.246.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 9F667209F; Thu, 8 Nov 2012 09:17:16 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9E29@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 11:17:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9C53@Hermes.columbia.ads.sparta.com>, <3D974D40-0B3B-40BD-87AB-24AFA5817254@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CCF@Hermes.columbia.ads.sparta.com>, <25C89C42-1B53-4107-BFFF-13F0E47AFD7E@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DBB@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9E29@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Nov 8 09:17:16 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509bdb0c199631065512083 X-DSPAM-Factors: 27, Nov+8, 0.01000, Nov+8, 0.01000, 8+#+at, 0.01000, 8+#+at, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Subject*changes+#+#+on, 0.01000, Subject*sidr+additions, 0.01000, Murphy+Sandra, 0.01000, Murphy+Sandra, 0.01000, Subject*and+#+#+agenda, 0.01000, 11+#+AM, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+#+#+#+AM, 0.01000, 2012+#+#+#+AM, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, Subject*on+Friday, 0.01000, Cc*sidr+wg, 0.01000, Subject*changes+#+agenda, 0.01000, Nov+#+#+#+9, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, Subject*Re+#+additions, 0.01000, Mime-Version*Apple+#+framework, 0.01000, To*Sandra+#+sparta.com, 0.01000, AM+#+#+wrote, 0.01000, AM+#+#+wrote, 0.01000, Murphy+#+wrote, 0.01000 Cc: sidr wg list Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 16:17:18 -0000 On Nov 8, 2012, at 11:14 AM, Murphy, Sandra wrote: > Sorry, I thought your complaint that I was misquoting was that I had = said "all" when you said "most". >=20 > So your complaint that I am misquoting is... what did I get wrong? This:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= On Nov 8, 2012, at 9:37 AM, Murphy, Sandra wrote: "Your thesis was that they always do." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= That is wrong, it is NOT my thesis. > I'm lost in a maze of twisty passages. Yes, apparently. -danny= From michael@burnttofu.net Thu Nov 8 09:45:04 2012 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 1DD4B21F8533 for ; Thu, 8 Nov 2012 09:45:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv6zlXVRZcSR for ; Thu, 8 Nov 2012 09:45:03 -0800 (PST) Received: from burnttofu.net (cl-960.qas-01.us.sixxs.net [IPv6:2001:4830:1600:3bf::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A94E21F84FC for ; Thu, 8 Nov 2012 09:45:02 -0800 (PST) Received: from schuylkill.es.net (schuylkill.es.net [IPv6:2001:400:14:1:129a:ddff:fe61:8874]) (authenticated bits=0) by burnttofu.net (8.14.5/8.14.5) with ESMTP id qA8Hij87099768 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 8 Nov 2012 17:44:59 GMT (envelope-from michael@burnttofu.net) Message-ID: <509BEF8D.1030402@burnttofu.net> Date: Thu, 08 Nov 2012 09:44:45 -0800 From: Michael Sinatra User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Shane Amante References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> <07B1B4AA-0D73-4D10-AEE5-C393FA6D620C@castlepoint.net> In-Reply-To: <07B1B4AA-0D73-4D10-AEE5-C393FA6D620C@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (burnttofu.net [IPv6:2001:4830:1600:3bf::2]); Thu, 08 Nov 2012 17:45:00 +0000 (UTC) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 17:45:04 -0000 On 11/8/12 6:01 AM, Shane Amante wrote: > Sandy, > > On Nov 8, 2012, at 6:25 AM, "Murphy, Sandra" > wrote: >> Speaking as regular ol' member >> >> On Wednesday, November 07, 2012 10:48 PM, Shane Amante >> [shane@castlepoint.net] said: >> >>> Commercial operators, in particular, should carefully evaluate >>> the risks posed to their core business (selling Internet transit) >>> by now being reliant on certificate information that directly >>> affects _reachability_information_ carried within their network. >>> That certificate information is maintained by an outside party >>> that's outside the operator organization's _direct_ (immediate) >>> control and for which they, seemingly, have no recourse if >>> (when?) something goes wrong. >> >> I think the Internet is already there. >> >> There are ISPs that spend considerable energy creating prefix >> filters from IRR data and strongly encourage their customers to >> register in IRRs. Those registers are maintained by an outside >> party that's outside the operator organization's direct control. >> Those registered objects directly affect reachability information >> carried within their network. >> >> Commercial operators have been comfortable with this mode of >> operation for many years. I doubt whether any of them have felt >> the need to carefully evaluate the risks or consult their legal >> departments. It has been best current practice and urged on >> operators at *OG meetings. >> >> I don't think we want people asking ISPs that use IRRs why they run >> such a risky operation. >> >> --Sandy, speaking as regular ol' member > > There is not, in my understanding, a single root for the IRR's. > Although RIR's for a particular region do allocate and register those > resources (IP prefixes, ASN's, etc.) into their respective IRR > instance ... there is absolutely nothing stopping the resource holder > from registering their resources in one, or more, "3rd-party IRR" > instances /not/ run or controlled by any RIR, i.e.: RADB, ALT.DB, > etc. IMO, the ability to do that constitutes "risk mitigation" on > the part of the resource holder who publishes their objects > (customer) as well as the _direct_ ISP's (from whom their buy > service) that consume those objects, since there is no single, > central authority with direct control over their business. > > That said, I acknowledge the downside with the present IRR model is > that, in most instances, no IRR can express authority for the > resources held in their IRR DB. IMO, that creates a problem for > /3rd-parties/ -- researchers, LEO, etc. -- who have no direct > (contractual) relationship with both the ISP and their customer, > since those third-parties have a difficult time in understanding > which IRR to believe has the most up-to-date copy of resources. > However, keep in mind (and this is key here), that each ISP *does* > have a direct contractual relationship with its customers. At the > time such contracts are signed, the customer must tell the ISP which > specific IRR instance(s) the customer has registered and maintains > their IRR objects, which gets around at least /part/ (but, not all) > of the problem. > > Before you respond with: each RP (ISP) in the RPKI system is free to > choose whatever TA's they want to mitigate such risks -- I would ask: > if ISP's did that, how is that /any/ different from the operation of > the present-day IRR model? IMO, it's not clear that the RPKI is > "fixing" anything, unless everyone voluntarily or _involuntarily_ > accepts a single-rooted RPKI as the sole source of resource > information ... > > As with many things, risk is subjective and each party in a system > should decide for themselves what constitutes acceptable risk for > their operations. I think these are very valid points from an operational standpoint, but that is not the concern regarding the third-party indemnification clause. The third-party indemnification means that I have to assume all of ARIN's liability arising from *my* use of the RPKI, if I choose to use it. IANAL, so it is not clear to me if that covers cases where clearly ARIN is at fault. I assume that the legitimate intention is to avoid a MAPS-like situation, where the RIR gets sued because I choose not to carry ISP-X's routes because of invalid ROAs. But what if the RIR does something stupid and breaks RPKI and I stop carrying ISP-X's routes? Do I have to assume the RIR's liability? My layman's perspective on this is that we should ditch the indemnification clause and each have to assume our own risks--and that seems to be consistent with your argument. At any rate, I am pretty sure this issue isn't an IETF concern, and I will raise this on arin-discuss@ later today or tomorrow. ARIN members are welcome to join me there. michael From heas@shrubbery.net Thu Nov 8 10:16:37 2012 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 33B0B21F8808 for ; Thu, 8 Nov 2012 10:16:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kKKLCckpPJT for ; Thu, 8 Nov 2012 10:16:34 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0FD21F8552 for ; Thu, 8 Nov 2012 10:16:33 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 83CCE9BA60; Thu, 8 Nov 2012 18:16:34 +0000 (UTC) Date: Thu, 8 Nov 2012 18:16:34 +0000 From: heasley To: "Murphy, Sandra" Message-ID: <20121108181634.GC5880@shrubbery.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <509B0149.1050308@burnttofu.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9BB8@Hermes.columbia.ads.sparta.com> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "sidr@ietf.org" Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 18:16:38 -0000 Thu, Nov 08, 2012 at 11:25:44AM +0000, Murphy, Sandra: > There are ISPs that spend considerable energy creating prefix filters from IRR data and strongly encourage their customers to register in IRRs. Those registers are maintained by an outside party that's outside the operator organization's direct control. Those registered objects directly affect reachability information carried within their network. Some operators maintain their own registry and mirror the database of others, as we do. Others run their own server which mirrors the DB of some subset of registries. Others rely on the servers operated by those who own the registries (or other publicly available servers). We'll do the same, to whatever extent possible, for rpki, so as to be as independant as possible. > Commercial operators have been comfortable with this mode of operation for many years. I doubt whether any of them have felt the need to carefully evaluate the risks or consult their legal departments. It has been best current practice and urged on operators at *OG meetings. Not all that comfortable; but it is what we have. we expend great effort to insulate ourselves from failures. From aservin@lacnic.net Thu Nov 8 10:29:16 2012 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 60B2021F8E4D for ; Thu, 8 Nov 2012 10:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haoQ6kKQGy11 for ; Thu, 8 Nov 2012 10:29:15 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id B6D2C21F8E1E for ; Thu, 8 Nov 2012 10:29:15 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org (dhcp-16f2.meeting.ietf.org [130.129.22.242]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7E7F43084DF for ; Thu, 8 Nov 2012 16:29:15 -0200 (UYST) Message-ID: <509BF9F7.3050606@lacnic.net> Date: Thu, 08 Nov 2012 13:29:11 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9CF8@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DA7@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9DA7@Hermes.columbia.ads.sparta.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 18:29:16 -0000 Discussion != want-to-work-on-the-topic /as On 08/11/2012 10:54, Murphy, Sandra wrote: >>> Calls for adoption are not (supposed) to discuss content. >> >> Thanks for that clarification. The IETF is a deliberative body, and I was >> under the impression that discussion at any point in the process, though >> not optimal, was acceptable. I did not realize SIDR had deviated. > > I did not say discussion was prohibited. That "supposed" is as in "supposedly". > > Calls for adoption are to indicate interest in working on a topic. The intent of a call for adoption is not consensus on the content. Review of the content is not the purpose of a call for adoption. > > I know I've said something like this before in calls for adoption. This should not be a surprise. > > --Sandy > ________________________________________ > From: Andy Newton [andy@arin.net] > Sent: Thursday, November 08, 2012 10:41 AM > To: Murphy, Sandra; Christopher Morrow > Cc: Alexey Melnikov; sidr@ietf.org > Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting > > On 11/8/12 9:57 AM, "Murphy, Sandra" wrote: > >>> Calls for adoption are not (supposed) to discuss content. > > Thanks for that clarification. The IETF is a deliberative body, and I was > under the impression that discussion at any point in the process, though > not optimal, was acceptable. I did not realize SIDR had deviated. > >> Are you sure you are not thinking of wglc, where consensus on the content >> is needed? > > I'm pretty sure I understand the difference between WGLC and wg document > acceptance. What I am uncertain about is the criteria for working group > document acceptance in SIDR. > >> And I said it generated "a first storm of discussion", not "interest". > > So, is "a fire storm of discussion" the threshold for document acceptance? > If a document fails to generate such a storm, will it not be accepted? > Since ROVER did generate a storm, will you be accepting it as a working > group document? Again, I'm trying to determine the criteria upon which the > chairs accept a document as a working group item. I do find "a fire storm > of discussion" to be a unique threshold. > > I'll note that you did say, "Nothing like actively working on a topic to > demonstrate interest in working on the topic." Hence my confusion. > > -andy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@sparta.com Thu Nov 8 12:02:26 2012 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 6C08821F8802 for ; Thu, 8 Nov 2012 12:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhahWzmFa7Wa for ; Thu, 8 Nov 2012 12:02:25 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 53A4221F8546 for ; Thu, 8 Nov 2012 12:02:25 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA8K2JXr015410 for ; Thu, 8 Nov 2012 14:02:19 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA8K2J7e007615 for ; Thu, 8 Nov 2012 14:02:19 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 15:02:19 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: more agenda changes Thread-Index: Ac296JrNCViYfcV6Sam31Oo9iuMOlQ== Date: Thu, 8 Nov 2012 20:02:18 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9FF6@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] more agenda changes 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 Nov 2012 20:02:26 -0000 Please be aware that one of our presenters this time is remote, so take ext= ra care to practice good mike and speaking manners.=0A= =0A= I have uploaded the latest version of the agenda. Please do pay attention = to the agenda and make sure everyone is shown there.=0A= =0A= Slides are coming in and SOME of them are numbered (whee!). =0A= =0A= One of the requesters of agenda time (the idr error-reporting concern) beca= me ill and left . We'll have to try to open that discussion on the list.= =0A= =0A= I had mistakenly omitted the discussion of the LACNIC conference experience= , after I was the one that suggested it!=0A= =0A= In the idr meeting on Monday, the wg suggested to one of the presenters tha= t they ask for advice from sidr about the proposed work. This is not being= suggested as a sidr work item, but the right sort of people to advise are = presumed to frequent this group.=0A= =0A= And finally, there is an overlap between the last hour of sidr and grow. O= ne of the sidr co-chairs is a grow co-chair (yes, grow was on the sidr do-n= ot-conflict list). There are bgp operationally oriented folk in sidr who w= ill likely depart for grow. So I have attempted to compress all the topics= into the 9-11, 11:20-12:20 slots. Additional discussion of any particular= topic that needs more time can be during the 12:30-13:30 time slot, but wi= th a potentially reduced audience.=0A= =0A= We have about 40 min reserved for a free-wheeling discussion of the impact = of the ARIN relying party agreement.=0A= =0A= The tools site displays blanks oddly in some browsers. So I am copying the= plain text of the agenda below.=0A= =0A= --Sandy=0A= =0A= =0A= =0A= Secure Inter-Domain Routing WG (sidr)=0A= IETF 85 - Atlanta, GA, US=0A= =0A= CHAIR(s): Sandra Murphy Sandra.Murphy at Sparta.com=0A= Chris Morrow morrowc at ops-netman.net=0A= Alexey Melnikov alexey.melnikov at isode.com=0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=0A= =0A= FRIDAY, November 9, 2012=0A= 0900-1100 Morning Session I=0A= 1120-1220 Afternoon Session I=0A= 1230-1330 Afternoon Session II=0A= Grand Ballroom C=0A= =0A= AGENDA:=0A= =0A= Morning Session I 0900-1100=0A= =0A= 1) Administrivia & Draft status 5 = min=0A= =0A= - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html=0A= - WG Resources: http://tools.ietf.org/wg/sidr/ =0A= - Minute taker?=0A= - Jabber Scribe?=0A= - Blue Sheets=0A= - Agenda Bashing=0A= =0A= 2) Existing Drafts=0A= =0A= a) BGPSEC Protocol Specification 25= min =0A= draft-ietf-sidr-bgpsec-protocol-06.txt=0A= http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-06 =0A= =0A= Presenter: Matt Lepinski =0A= =0A= b) Local Trust Anchor Management for the Resource Public Key 10= min=0A= Infrastructure=0A= draft-ietf-sidr-ltamgmt-07.txt=0A= http://tools.ietf.org/html/draft-ietf-sidr-ltamgmt-07=0A= =0A= Presenter: Richard Barnes=0A= =0A= c) BGPSEC router key rollover as an alternative to beaconing 10= min=0A= draft-ietf-sidr-bgpsec-rollover-01.txt=0A= http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-01 =0A= =0A= Presenter: Brian Weis=0A= =0A= =0A= 3) Previous Topics=0A= =0A= a)Discussion and Analysis of Variants of Key Rollover Method for Replay Pro= tection 10 mi= n=0A= =0A= draft-sriram-replay-protection-design-discussion-00=0A= http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion= -00 =0A= =0A= Presenter: Kotikalapudi Sriram=0A= =0A= b) AS Aliasing 10= min=0A= BGPSec Considerations for AS Migration=0A= draft-george-sidr-as-migration-00=0A= http://tools.ietf.org/html/draft-george-sidr-as-migration-00=0A= =0A= Presenter: Wes George (remotely)=0A= =0A= c) Multiple Publication Points 10= min=0A= =0A= Multiple Repository Publication Points support in the Resource Public=0A= Key Infrastructure (RPKI)=0A= draft-rogaglia-sidr-multiple-publication-points-01=0A= http://tools.ietf.org/html/draft-rogaglia-sidr-multiple-publication-points-= 01 =0A= =0A= Presenter: Carlos Martinez=0A= =0A= d) Policy Qualifier of the CP 1= 0 min=0A= =0A= Presenter: Andy Newton=0A= =0A= e) Retrieval/Validation Separation 10= min=0A= =0A= Persenter: Tim Bruijnzeels [tim@ripe.net]=0A= =0A= 4) Real World Experiences=0A= =0A= a) RPSTIR Validator Testing 10= min=0A= =0A= Presenter: Andrew Chi=0A= =0A= b) LACNIC Experiences with Origin Validation 10= min=0A= =0A= Presenter: Carlos Martinez =0A= =0A= Afternoon Session I 1120-1220=0A= =0A= 1) IETF 85 Experiences with Origin Validation 10= min=0A= =0A= Presenter: Warren Kumari=0A= =0A= 2) L3VPN 10= min=0A= Authenticating L3VPN Origination Signaling=0A= draft-ymbk-l3vpn-origination-02=0A= http://tools.ietf.org/html/draft-ymbk-l3vpn-origination-02 =0A= =0A= Presenter: =0A= Arjun Sreekantiah=0A= =0A= 3) General Discussion of Relying Party Agreement 40= min=0A= =0A= Presenter: Sandra Murphy=0A= =0A= Afternoon Session II 1230-1330=0A= =0A= =0A= =0A= From danny@tcb.net Thu Nov 8 12:53:52 2012 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 198C121F8686 for ; Thu, 8 Nov 2012 12:53:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdAndfjlwEbG for ; Thu, 8 Nov 2012 12:53:51 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9589821F8419 for ; Thu, 8 Nov 2012 12:53:51 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id E7F4920A9 for ; Thu, 8 Nov 2012 20:53:50 +0000 (UTC) Received: from [172.17.4.250] (209-23-246-1-ip-static.hfc.comcastbusiness.net [209.23.246.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 7258B209E; Thu, 8 Nov 2012 13:53:48 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9FF6@Hermes.columbia.ads.sparta.com> Date: Thu, 8 Nov 2012 15:53:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <263653A6-8D74-4EC1-A43D-E7A9C872E2D4@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E9FF6@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Nov 8 13:53:50 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509c1bde199631943817167 X-DSPAM-Factors: 27, and+#+#+#+the, 0.01000, Nov+8, 0.01000, 8+#+at, 0.01000, of+#+#+#+that, 0.01000, Murphy+Sandra, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, Mime-Version*Message+#+v1283, 0.01000, and+#+#+that, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Cc*ietf.org+sidr, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, the+#+#+not, 0.01000, of+#+and, 0.01000, Mime-Version*Apple+#+framework, 0.01000, To*Sandra+#+sparta.com, 0.01000, for+#+#+I, 0.01000, Murphy+#+wrote, 0.01000, the+#+#+of, 0.01000, On+#+8, 0.01000, Subject*sidr+#+#+changes, 0.01000, at+#+#+#+Murphy, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, and+#+#+the, 0.01000, Mime-Version*1.0+#+Message, 0.01000 Cc: "sidr@ietf.org" Subject: Re: [sidr] more agenda changes 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 Nov 2012 20:53:52 -0000 On Nov 8, 2012, at 3:02 PM, Murphy, Sandra wrote: > And finally, there is an overlap between the last hour of sidr and = grow. One of the sidr co-chairs is a grow co-chair (yes, grow was on = the sidr do-not-conflict list). There are bgp operationally oriented = folk in sidr who will likely depart for grow. So I have attempted to = compress all the topics into the 9-11, 11:20-12:20 slots. Additional = discussion of any particular topic that needs more time can be during = the 12:30-13:30 time slot, but with a potentially reduced audience. I'd also observe that OPSEC is from 0900-1100, and it's another = extremely unfortunate conflict, particularly considering they have = things on their agenda like "BGP Operations and Security". In the future, the chairs _can iterate with the secretariat and strongly = request that these conflicts be resolved. -danny From Sandra.Murphy@sparta.com Thu Nov 8 13:18:33 2012 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 6D53E21F8683 for ; Thu, 8 Nov 2012 13:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3MACp2r03GH for ; Thu, 8 Nov 2012 13:18:33 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 902B421F85E8 for ; Thu, 8 Nov 2012 13:18:32 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA8LIV9D015968 for ; Thu, 8 Nov 2012 15:18:31 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA8LIPBZ009794 for ; Thu, 8 Nov 2012 15:18:26 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Thu, 8 Nov 2012 16:18:25 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes taker and jabber scribe Thread-Index: Ac28YpcUrMOoVE1eR4KDTeFvsTSH3wBk8rxA Date: Thu, 8 Nov 2012 21:18:25 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6EA07F@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E6E2B@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E6E2B@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] minutes taker and jabber scribe 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 Nov 2012 21:18:33 -0000 No one has stepped forward to take minutes or serve as the jabber scribe.= =0A= =0A= Please do volunteer. We can't proceed without both.=0A= =0A= --Sandy=0A= ________________________________________=0A= Sent: Tuesday, November 06, 2012 4:06 PM=0A= To: sidr@ietf.org=0A= Subject: minutes taker and jabber scribe=0A= =0A= We presently have two remote presenters in this Friday's session.=0A= =0A= That puts even more focus on the support for remote participation.=0A= =0A= Volunteers are needed to be minutes takers and for jabber scribe.=0A= =0A= Jabber scribe is particularly important for immediate participation in the = meeting.=0A= =0A= Minutes takers are needed to record discussion and action items.=0A= =0A= Both are needed.=0A= =0A= We will have the etherpad available again, so=0A= =0A= =0A= --Sandy=0A= From randy@psg.com Fri Nov 9 01:07:36 2012 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 643C021F85E4 for ; Fri, 9 Nov 2012 01:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MvU3fWa1SLo for ; Fri, 9 Nov 2012 01:07:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5921C21F8608 for ; Fri, 9 Nov 2012 01:07:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWkYn-000KYb-Tz; Fri, 09 Nov 2012 09:07:34 +0000 Date: Fri, 09 Nov 2012 18:07:33 +0900 Message-ID: From: Randy Bush To: Arturo Servin In-Reply-To: <509BCBF5.3030406@gmail.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> <509BCBF5.3030406@gmail.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 09:07:36 -0000 >> no need. this is object based security. rama and hanuman have tals and >> validate. having every cache in the world hit the CAs is not gonna >> scale. > Yes, perhaps we need a different architecture and transport protocol. measurement has shown that rsync is about as good as you're gonna do performance-wise for a system where publication is centralized. and have a look at the ripe publication loads late last month. way to go tim and alex. >> you may want to look at my ripe and nanog presos on the scaling >> experiments we did. > More arguments to think on alternate paths. actually, the results were the opposite. not that i am uninterested in working on future architectures. randy From Sandra.Murphy@sparta.com Fri Nov 9 03:49:08 2012 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 70AD221F862B for ; Fri, 9 Nov 2012 03:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJEK1zOQJG+l for ; Fri, 9 Nov 2012 03:49:08 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0329A21F8623 for ; Fri, 9 Nov 2012 03:49:06 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id qA9Bn6vW018382 for ; Fri, 9 Nov 2012 05:49:06 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qA9Bn5At018817 for ; Fri, 9 Nov 2012 05:49:05 -0600 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Fri, 9 Nov 2012 06:49:05 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: still need minutes taker Thread-Index: Ac2+cDfq6twhu9cPSd2U6ex4KRkkvA== Date: Fri, 9 Nov 2012 11:49:04 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6EA21C@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] still need minutes taker 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 Nov 2012 11:49:08 -0000 We still need a minute taker for today's session.=0A= =0A= Please do volunteer.=0A= =0A= --Sandy, speaking as co-chair= From tim@ripe.net Fri Nov 9 05:24:16 2012 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 D32CD21F8538 for ; Fri, 9 Nov 2012 05:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUcgmQY9v+oU for ; Fri, 9 Nov 2012 05:24:15 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id B55A521F862A for ; Fri, 9 Nov 2012 05:24:14 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TWoZ9-0003RT-VQ for sidr@ietf.org; Fri, 09 Nov 2012 14:24:13 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TWoZ9-0004ff-Kx for sidr@ietf.org; Fri, 09 Nov 2012 14:24:11 +0100 From: Tim Bruijnzeels Content-Type: multipart/alternative; boundary="Apple-Mail=_81D686EC-E04E-40BB-A7AD-5AF2BDDA8A65" Message-Id: <191C8370-A074-4B58-9BB5-47EACC92FBF0@ripe.net> Date: Fri, 9 Nov 2012 08:24:09 -0500 To: "sidr@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121109 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.2 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.1 SARE_TOWRITE BODY: Contains phrasing used by spammers -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071988b5c8488e81d2500c51b0b2cf969759 Subject: [sidr] New draft on separating validation from object retrieval 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 Nov 2012 13:24:16 -0000 --Apple-Mail=_81D686EC-E04E-40BB-A7AD-5AF2BDDA8A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I have already had some informal discussions about this and decided to = write our ideas up in a informational draft: = http://www.ietf.org/internet-drafts/draft-tbruijnzeels-sidr-validation-loc= al-cache-00.txt I will do a short talk on this during today's sidr session to explain = the background. Further discussion can then be done on list. For the impatient, the gist: In our view this approach demonstrates a way to do top-down RPKI = validation that is independent from *where* objects were retrieved and = thus it is useful when thinking about multiple publication points, or = alternative ways to fetch or share unvalidated objects. The main question for the working group is wether we're willing to = change the way RPs can handle manifest, i.e. MAY they treat them as = authoritative sources to walk down the rpki tree? Cheers Tim= --Apple-Mail=_81D686EC-E04E-40BB-A7AD-5AF2BDDA8A65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

I have already had some informal discussions = about this and decided to write our ideas up in a informational = draft:

I = will do a short talk on this during today's sidr session to explain the = background. Further discussion can then be done on = list.

For the impatient, the = gist:

In our view this approach demonstrates a = way to do top-down RPKI validation that is independent from *where* = objects were retrieved and thus it is useful when thinking about = multiple publication points, or alternative ways to fetch or share = unvalidated objects.

The main question for the = working group is wether we're willing to change the way RPs can handle = manifest, i.e. MAY they treat them as authoritative sources to walk down = the rpki = tree?

Cheers
Tim
= --Apple-Mail=_81D686EC-E04E-40BB-A7AD-5AF2BDDA8A65-- From tim@ripe.net Fri Nov 9 06:35:23 2012 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 4663521F868E for ; Fri, 9 Nov 2012 06:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJh36WbqBAD1 for ; Fri, 9 Nov 2012 06:35:22 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 274DD21F8542 for ; Fri, 9 Nov 2012 06:35:22 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TWpfz-0006bf-Pg; Fri, 09 Nov 2012 15:35:21 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TWpfz-0001Lr-F8; Fri, 09 Nov 2012 15:35:19 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_8B37C127-671A-49CA-8687-1523314D12A3" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 9 Nov 2012 09:35:18 -0500 Message-Id: <1E01BA5D-DCA0-4029-B541-1E50C2D9A55D@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> <509BCBF5.3030406@gmail.com> To: Randy Bush X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121109 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071954cf77c77eaa1e2064300cb64351a31d Cc: Arturo Servin , sidr@ietf.org Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 14:35:23 -0000 --Apple-Mail=_8B37C127-671A-49CA-8687-1523314D12A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Nov 9, 2012, at 4:07 AM, Randy Bush wrote: >>> no need. this is object based security. rama and hanuman have tals = and >>> validate. having every cache in the world hit the CAs is not gonna >>> scale. >> Yes, perhaps we need a different architecture and transport protocol. >=20 > measurement has shown that rsync is about as good as you're gonna do > performance-wise for a system where publication is centralised. Could you share those measurements? When we did lab testing on this our results were rather different. Presented at the interim in Vancouver: = http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-inte= rim-2012-sidr-5-0.pdf If one looks at just the simple case of performing a recursive rsync on = a substantial rsync repository to determine if there are any updates, = when there are none.. so just the overhead, determining this, no data = transferred.. Then it's clear that rsync is not able to deal with substantial load and = it's trivial to DoS. = http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-inte= rim-2012-sidr-5-1.pdf Here we proposed having a simple update file (10kB for test purposes) = that can be fetched to determine if updates are needed. This performs = several orders of magnitude better than doing a recursive rsync (5000 = req/s vs 2 req/s on simple hardware). Then looking at the transport for = just this file using http is roughly 10 times better than rsync = (non-recursive, just that file). > and have a look at the ripe publication loads late last month. way to > go tim and alex. >=20 I agree that given the current architecture a hierarchical structure is = better for clients. As I mentioned though this is hard on the server for substantial = repositories (roughly 10 times today: 70k objects and up vs our 7k = today). >>> you may want to look at my ripe and nanog presos on the scaling >>> experiments we did. >> More arguments to think on alternate paths. >=20 > actually, the results were the opposite. >=20 > not that i am uninterested in working on future architectures. >=20 Good. On that note I think it's worthwhile thinking about different = complementary ways to deal with this. I.e. make the server side more = scalable as well as considering flooding protocols and other ways to = share data between RPs. > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_8B37C127-671A-49CA-8687-1523314D12A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii randy@psg.com> wrote:

no need.  this is object = based security.  rama and hanuman have tals and
validate. =  having every cache in the world hit the CAs is not = gonna
scale.
Yes, perhaps we need a different = architecture and transport protocol.

measurement has = shown that rsync is about as good as you're gonna do
performance-wise = for a system where publication is = centralised.

Could you share those = measurements?

When we did lab testing on this = our results were rather different.

Presented at = the interim in Vancouver:

If one looks at just the simple case of performing a recursive = rsync on a substantial rsync repository to determine if there are any = updates, when there are none.. so just the overhead, determining this, = no data transferred..

Then it's clear that = rsync is not able to deal with substantial load and it's trivial to = DoS.


Here we proposed having a simple update file (10kB for test = purposes) that can be fetched to determine if updates are needed. This = performs several orders of magnitude better than doing a recursive rsync = (5000 req/s vs 2 req/s on simple hardware). Then looking at the = transport for just this file using http is roughly 10 times better than = rsync (non-recursive, just that = file).

and have a = look at the ripe publication loads late last month.  way to
go = tim and alex.


I agree that given = the current architecture a hierarchical structure is better for = clients.

As I mentioned though this is hard on = the server for substantial repositories (roughly 10 times today: 70k = objects and up vs our 7k today).

you = may want to look at my ripe and nanog presos on the = scaling
experiments we did.
More arguments to think = on alternate paths.

actually, the results were the = opposite.

not that i am uninterested in working on future = architectures.


Good. On that = note I think it's worthwhile thinking about different complementary ways = to deal with this. I.e. make the server side more scalable as well as = considering flooding protocols and other ways to share data between = RPs.


randy
_______________________________________________
= sidr mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr

= --Apple-Mail=_8B37C127-671A-49CA-8687-1523314D12A3-- From jcurran@arin.net Fri Nov 9 06:54:19 2012 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 6324821F870C for ; Fri, 9 Nov 2012 06:54:19 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8QhJH8s4nNY for ; Fri, 9 Nov 2012 06:54:18 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFAC21F857E for ; Fri, 9 Nov 2012 06:54:18 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id C1CF51652C2; Fri, 9 Nov 2012 09:54:17 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 2308A1652B3; Fri, 9 Nov 2012 09:54:17 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 9 Nov 2012 09:53:48 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Fri, 9 Nov 2012 09:53:00 -0500 From: John Curran To: Sandra Murphy Thread-Topic: ARIN RPA presentation - Comments from ARIN Thread-Index: AQHNvono0ft/D58u6EGvvJ0+dy5YFA== Importance: high X-Priority: 1 Date: Fri, 9 Nov 2012 14:52:59 +0000 Message-ID: <745C9F38-6EC8-4F6A-94C4-E1B6B9D4E436@corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: [sidr] ARIN RPA presentation - Comments from ARIN 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 Nov 2012 14:54:19 -0000 Sandra -=20 Regarding http://tools.ietf.org/agenda/85/slides/slides-85-sidr-14.pdf to b= e presentated later today: Page 10 - > Potential Impact >=20 > =95 Operators have said to me =93I don=92t want to run anything. I just = want to click on a website somewhere=94 >=20 > =95 There are already tools/sites that display stats and summaries >=20 > =95 There are already tools/sites that display the certification status o= f prefixes, that display the validity of BGP routes, etc. >=20 > =95 Public services like Looking glass sites =96 extensions to report val= idity >=20 > =95 Are these modes of use permitted under the ARIN RPA I'd like it made clear during the presentation that indeed a strict reading= of the current=20 ARIN RPA would disallow such applications, but as noted earlier in this lis= t, ARIN is=20 quite willing to provide waiver for such statistic, status, and summary use= s. If we=20 can find a way to safely provide a blanket waiver in a future RPA, we will = do so. Page 13 -=20 > Object Security Architecture & Use >=20 > =95 Single authoritative source >=20 > =95 =96 Transport security: source is single point of access >=20 > =95 =96 Object security: Objects created by source can be mirrored by a= nyone anywhere =96 global caches, regional, metro, ... >=20 > =95 Would the ARIN RPA prevent this object security architecture and use I would also like it made clear during the presentation that the ARIN RPA d= oes _not_=20 prevent the object security architecture, but does require that the partici= pants in the=20 model confirm _once_ that they follow the basic requirement of the PKIX arc= hitecture (per RFC 5280) of being aware of the applicable policy for ARIN's CA. Part= ies are free=20 to replicate objects far and wide by any and all methods; it is simply vali= dation that=20 requires that they have accepted the RPA in the process of obtaining the TA= L (which presumably occurs once during their initial setup.) In light of the above, I believe that the slides that follow ("Crazy Ideas = to Reduce Impact") are both appropriately titled and are likely to have questionable effort/pa= yback ratios. I apologize for sending these comments to the list rather than providing th= em via remote participation methods, but given the number and duration of sidr sessions t= oday, I cannot be certain that I'll be online during the your presentation. Thanks! /John John Curran President and CEO ARIN From Sandra.Murphy@sparta.com Fri Nov 9 07:28:25 2012 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 B791021F857C for ; Fri, 9 Nov 2012 07:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8MPWWtxjRFm for ; Fri, 9 Nov 2012 07:28:25 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id D5FE221F84E6 for ; Fri, 9 Nov 2012 07:28:22 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qA9FSKQV028931; Fri, 9 Nov 2012 07:28:20 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qA9FSKLJ023612; Fri, 9 Nov 2012 07:28:20 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Fri, 9 Nov 2012 10:28:20 -0500 From: "Murphy, Sandra" To: John Curran Thread-Topic: ARIN RPA presentation - Comments from ARIN Thread-Index: AQHNvono0ft/D58u6EGvvJ0+dy5YFJfhme/R Date: Fri, 9 Nov 2012 15:28:19 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6EA290@Hermes.columbia.ads.sparta.com> References: <745C9F38-6EC8-4F6A-94C4-E1B6B9D4E436@corp.arin.net> In-Reply-To: <745C9F38-6EC8-4F6A-94C4-E1B6B9D4E436@corp.arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] ARIN RPA presentation - Comments from ARIN 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 Nov 2012 15:28:25 -0000 wrt:=0A= =0A= I'd like it made clear during the presentation that indeed a strict reading= of the current=0A= ARIN RPA would disallow such applications, but as noted earlier in this lis= t, ARIN is=0A= quite willing to provide waiver for such statistic, status, and summary use= s. If we=0A= can find a way to safely provide a blanket waiver in a future RPA, we will = do so.=0A= =0A= Absolutely.=0A= =0A= Your previous comment was that you might state "feel free to summarize our = published data for such purposes." That covers many of the possible existi= ng services - I will point to services that I wonder might still be a probl= em. But given the below, it might not be a concern anyway.=0A= =0A= wrt:=0A= =0A= Parties are free=0A= to replicate objects far and wide by any and all methods; it is simply vali= dation that=0A= requires that they have accepted the RPA in the process of obtaining the TA= L (which=0A= presumably occurs once during their initial setup.)=0A= =0A= =0A= Can I quote you on the "free to replicate objects far and wide by any and a= ll methods" part?=0A= =0A= I am quite relieved. That would indeed reduce the impact!=0A= =0A= But I am also quite confused about how that works wrt the RPA language that= prohibits=0A= =0A= "to engage in any activity: that ... transfers or in any way gives any othe= r=0A= party Your access to or use of any ORCP Services"=0A= =0A= I did attempt to clarify that language with ARIN staff. Those discussions = had left me and the others included with the impression that this language = would not permit the data sharing.=0A= =0A= Your clarifying in a public forum is very useful.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: John Curran [jcurran@arin.net]=0A= Sent: Friday, November 09, 2012 9:52 AM=0A= To: Murphy, Sandra=0A= Cc: sidr wg list=0A= Subject: ARIN RPA presentation - Comments from ARIN=0A= =0A= Sandra -=0A= =0A= Regarding http://tools.ietf.org/agenda/85/slides/slides-85-sidr-14.pdf to b= e presentated=0A= later today:=0A= =0A= Page 10 -=0A= > Potential Impact=0A= >=0A= > =95 Operators have said to me =93I don=92t want to run anything. I just = want to click on a website somewhere=94=0A= >=0A= > =95 There are already tools/sites that display stats and summaries=0A= >=0A= > =95 There are already tools/sites that display the certification status o= f prefixes, that display the validity of BGP routes, etc.=0A= >=0A= > =95 Public services like Looking glass sites =96 extensions to report val= idity=0A= >=0A= > =95 Are these modes of use permitted under the ARIN RPA=0A= =0A= I'd like it made clear during the presentation that indeed a strict reading= of the current=0A= ARIN RPA would disallow such applications, but as noted earlier in this lis= t, ARIN is=0A= quite willing to provide waiver for such statistic, status, and summary use= s. If we=0A= can find a way to safely provide a blanket waiver in a future RPA, we will = do so.=0A= =0A= Page 13 -=0A= > Object Security Architecture & Use=0A= >=0A= > =95 Single authoritative source=0A= >=0A= > =95 =96 Transport security: source is single point of access=0A= >=0A= > =95 =96 Object security: Objects created by source can be mirrored= by anyone anywhere =96 global caches, regional, metro, ...=0A= >=0A= > =95 Would the ARIN RPA prevent this object security architecture and use= =0A= =0A= =0A= I would also like it made clear during the presentation that the ARIN RPA d= oes _not_=0A= prevent the object security architecture, but does require that the partici= pants in the=0A= model confirm _once_ that they follow the basic requirement of the PKIX arc= hitecture=0A= (per RFC 5280) of being aware of the applicable policy for ARIN's CA. Part= ies are free=0A= to replicate objects far and wide by any and all methods; it is simply vali= dation that=0A= requires that they have accepted the RPA in the process of obtaining the TA= L (which=0A= presumably occurs once during their initial setup.)=0A= =0A= In light of the above, I believe that the slides that follow ("Crazy Ideas = to Reduce Impact")=0A= are both appropriately titled and are likely to have questionable effort/pa= yback ratios.=0A= =0A= I apologize for sending these comments to the list rather than providing th= em via remote=0A= participation methods, but given the number and duration of sidr sessions t= oday, I cannot=0A= be certain that I'll be online during the your presentation.=0A= =0A= Thanks!=0A= /John=0A= =0A= John Curran=0A= President and CEO=0A= ARIN=0A= =0A= From alexey.melnikov@isode.com Fri Nov 9 08:14:50 2012 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 91BBC21F874B for ; Fri, 9 Nov 2012 08:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNnF7C4Q+gUL for ; Fri, 9 Nov 2012 08:14:50 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E92C21F8618 for ; Fri, 9 Nov 2012 08:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1352477688; d=isode.com; s=selector; i=@isode.com; bh=SsD+7vpCXT72U0pzZLtbau+vhQbTHe6BrtbQ4KNQYa4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZLdI9cMDwq/I558VLL9j3R8zFEAheqMaIs+MbKK4ie1wUcwWvHUbuN/tptmJeKo8yM+1FW ks6hxyuJfFFB8qCpNQyNlwds5rDA6na1fPCK8jdA9cO7WDTLuip3kUvNRGngQ7bNMRD60c PAPAHbQRn0xpDzqkQaPVu+VPUSAGcs0=; Received: from [130.129.18.182] (dhcp-12b6.meeting.ietf.org [130.129.18.182]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 9 Nov 2012 16:14:48 +0000 Message-ID: <509D2C04.4020704@isode.com> Date: Fri, 09 Nov 2012 16:15:00 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Byron Ellacott References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 16:14:50 -0000 On 08/11/2012 05:53, Byron Ellacott wrote: > Hi Chris, > > On 08/11/2012, at 3:04 PM, Christopher Morrow wrote: > >> On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott wrote: >>> Hi Chris, >>> >>> When did the WG reach consensus on adopting this draft? >> when it spent ~50 mesasages discussing it? >> it seems that, even if we abandon it in the end, discussing this over >> a draft is a good thing to do. > When that discussion happened, the chairs declared a lack of consensus for adoption: http://www.ietf.org/mail-archive/web/sidr/current/msg05015.html Byron and others, I think WG chairs (collectively) dropped the ball here: 3 of us have discussed the acceptance call a couple of times. We would like to apologize for sending inconsistent messages. After talking to various people this week, it looks like the best way forward is for the chairs to redo the acceptance call and ask very specific questions to keep everybody unconfused and hopefully happy. > Have the chairs reconsidered that declaration of lack of WG consensus, or adopted the draft despite a lack of WG consensus? > > Perhaps there's a problem to be addressed, and if a discussion should happen around that problem, a document describing the problem might be a more useful way forward. From aservin@lacnic.net Fri Nov 9 08:36:18 2012 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 1C5E721F86FC for ; Fri, 9 Nov 2012 08:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhNVvSqpuZwv for ; Fri, 9 Nov 2012 08:36:17 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5043E21F86FB for ; Fri, 9 Nov 2012 08:36:17 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org (dhcp-16f2.meeting.ietf.org [130.129.22.242]) by mail.lacnic.net.uy (Postfix) with ESMTP id 6E954308503 for ; Fri, 9 Nov 2012 14:36:05 -0200 (UYST) Message-ID: <509D30F0.9000004@lacnic.net> Date: Fri, 09 Nov 2012 11:36:00 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: [sidr] Invalids in the wild (Was Re: additions and changes to agenda on Friday) 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 Nov 2012 16:36:18 -0000 Related to our presentation today, if you are curious about why we have a lot of invalids: IPv4 http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/0.0.0.0/0/ For v6 our app does not support to query all the invalids, but you can check with something like: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/2001%3A13c7%3A7002%3A%3A/48/ Or just go to: http://www.labs.lacnic.net/rpkitools/looking_glass/ Regards as On 06/11/2012 12:35, Murphy, Sandra wrote: > We have three new topics to add to the agenda on Friday. > > Carlos Martinez would like to present a new version of draft-rogaglia-sidr-multiple-publication-points. > > Sue Hares, idr co-chair, would like to request a review of work she is doing in a limited re-write of the base BGP spec, to fix errata in error handling. She is aware that error handling can be a source of security issues and wants to be sure any issues are considered in the re-write. > > I would like to open a discussion with the wg concerning the recently announced ARIN relying party agreement. I have concerns about this agreement's impact on the envisioned RPKI architecture and dominant use. I think the wg needs to consider the potential impact and any potential mechanisms that would lessen impact. Note that the IETF can not interfere with ARIN legal decisions! > > These revisions will be reflected in a more detailed agenda shortly. > > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From brian.peter.dickson@gmail.com Fri Nov 9 08:42:18 2012 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 8345421F86D0 for ; Fri, 9 Nov 2012 08:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okJc8Z-+cyLn for ; Fri, 9 Nov 2012 08:42:17 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 665D021F85C1 for ; Fri, 9 Nov 2012 08:42:17 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id jg9so285053bkc.31 for ; Fri, 09 Nov 2012 08:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H4laJCcUvMaLBU/r7/hJwTj0l3Iauxu9jpaS+w/NTYk=; b=qJe7K1kxMLFCENS8D1jc97BnvdOxdUAmXqyY42Zsb5956rMCiiSecP0Ci4JQqZzrgo QVhiki6eCk74ZUIkFZgGxYbyRlBTpy0i/uAo7/fRINOS+7Jh1636VdPSJr6Ug3IN71FK d4OF/sKLZ1G7JamclOyCgJ7WvUqZ9hwdNPp79nubSGVapGFFOL9h5tNnQblSx1pOuf6/ QIWVFQdtcyPuSLe98DFfsZBhBreCgE8WMhicoxOqNSTqimruWSeRzMJ4IxcOzBDVQb/6 XkM8P/pzIvq4Rv6xnETFMCZSxtKYmbiCJw1eKBaT7KDNUmo+ZuUHM2ARoEcUbjcuFUhZ oBPA== MIME-Version: 1.0 Received: by 10.204.146.13 with SMTP id f13mr3919144bkv.29.1352479336214; Fri, 09 Nov 2012 08:42:16 -0800 (PST) Received: by 10.204.66.83 with HTTP; Fri, 9 Nov 2012 08:42:15 -0800 (PST) In-Reply-To: <509D2C04.4020704@isode.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> <509D2C04.4020704@isode.com> Date: Fri, 9 Nov 2012 11:42:15 -0500 Message-ID: From: Brian Dickson To: Alexey Melnikov Content-Type: multipart/alternative; boundary=0015175cf84066b16e04ce12a25f Cc: "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 16:42:18 -0000 --0015175cf84066b16e04ce12a25f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 9, 2012 at 11:15 AM, Alexey Melnikov wrote: > On 08/11/2012 05:53, Byron Ellacott wrote: > >> Hi Chris, >> >> On 08/11/2012, at 3:04 PM, Christopher Morrow >> wrote: >> >> On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott wrote: >>> >>>> Hi Chris, >>>> >>>> When did the WG reach consensus on adopting this draft? >>>> >>> when it spent ~50 mesasages discussing it? >>> it seems that, even if we abandon it in the end, discussing this over >>> a draft is a good thing to do. >>> >> When that discussion happened, the chairs declared a lack of consensus >> for adoption: http://www.ietf.org/mail-**archive/web/sidr/current/** >> msg05015.html >> > Byron and others, > I think WG chairs (collectively) dropped the ball here: 3 of us have > discussed the acceptance call a couple of times. We would like to apologize > for sending inconsistent messages. > > After talking to various people this week, it looks like the best way > forward is for the chairs to redo the acceptance call and ask very specific > questions to keep everybody unconfused and hopefully happy. > I'd like to note that in general, WG acceptance processes are a critical part of IETF processes. In particular, the WG consensus on adoption, is the one critical place in preventing "gaming the system". An adoption call should have three (or four) responses: Ready for Adoption Needs more work BEFORE Adoption Should not (never) be adopted Abstain/don't care The "needs more work" is the way that WG participants can hold authors/editors accountable for making requested changes. If a draft is accepted in its current state, then any promises by the authors to make changes are much like promises by politicians during election campaigns - not worth the paper they are written on. However, if the WG insists on changes BEFORE adoption, the reliance on promises goes away - which is a good thing. Any discussion on the content of a draft, which is prompted by a WG adoption request, SHOULD be taken by chairs as "Needs more work BEFORE Adoption". Since this does not seem to have been the case, please ask the WG to answer one of the four ways, explicitly. BTW: I believe that this draft should not be adopted in its current form (if ever). Brian --0015175cf84066b16e04ce12a25f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 9, 2012 at 11:15 AM, Alexey = Melnikov <alexey.melnikov@isode.com> wrote:
On 08/11/2012 05:53, Byron Ellacott wrote:
Hi Chris,

On 08/11/2012, at 3:04 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:<= br>
On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott <bje@apnic.net> wrote:
Hi Chris,

When did the WG reach consensus on adopting this draft?
when it spent ~50 mesasages discussing it?
it seems that, even if we abandon it in the end, discussing this over
a draft is a good thing to do.
When that discussion happened, the chairs declared a lack of consensus for = adoption: http://www.ietf.org/mail-archive/web/si= dr/current/msg05015.html
Byron and others,
I think WG chairs (collectively) dropped the ball here: 3 of us have discus= sed the acceptance call a couple of times. We would like to apologize for s= ending inconsistent messages.

After talking to various people this week, it looks like the best way forwa= rd is for the chairs to redo the acceptance call and ask very specific ques= tions to keep everybody unconfused and hopefully happy.


I'd like to note that = in general, WG acceptance processes are a critical part of IETF processes.<= /div>

In particular, the WG consensus on adoption, is th= e one critical place in preventing "gaming the system".

An adoption call should have three (or four) responses:=

Ready for Adoption
Needs more work BEFO= RE Adoption
Should not (never) be adopted
Abstain/don&#= 39;t care

The "needs more work" is the way that WG part= icipants can hold authors/editors accountable for making requested changes.=

If a draft is accepted in its current state, then= any promises by the authors to make changes are much like promises by poli= ticians during election campaigns - not worth the paper they are written on= .

However, if the WG insists on changes BEFORE adoption, = the reliance on promises goes away - which is a good thing.

<= /div>
Any discussion on the content of a draft, which is prompted by a = WG adoption request, SHOULD be taken by chairs as "Needs more work BEF= ORE Adoption".

Since this does not seem to have been the case, please = ask the WG to answer one of the four ways, explicitly.

=
BTW:

I believe that this draft should not be adopted= in its current form (if ever).

Brian
--0015175cf84066b16e04ce12a25f-- From alexey.melnikov@isode.com Fri Nov 9 08:43:45 2012 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 A54A721F8516 for ; Fri, 9 Nov 2012 08:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVa2JvdN6HFa for ; Fri, 9 Nov 2012 08:43:45 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id F345E21F8467 for ; Fri, 9 Nov 2012 08:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1352479423; d=isode.com; s=selector; i=@isode.com; bh=tUnZRlNDWIrI8XOH+AYzm7/S6zz3yyNGl5+ouyuTxH8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZlYwquL9B8GmxbK6aP6//Idbh9Hq3Qoca+tqFUIlynYlRZOq6W5C1CRFdDt5s07RLWjIS8 v6+VR6EsBo6fjn+al/NqEk9BRSPbQslqWVFzsmbNAb/nEJEylfn/5kOhZZmVLZbDzSuGNi 0fmnq6uJcQuMKfEvrRTLW5UGPCqHGXU=; Received: from [130.129.18.182] (dhcp-12b6.meeting.ietf.org [130.129.18.182]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 9 Nov 2012 16:43:42 +0000 Message-ID: <509D32CA.3080107@isode.com> Date: Fri, 09 Nov 2012 16:43:54 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: sidr wg MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Reviews of draft-ietf-sidr-rpki-rtr-protocol-mib-02.txt needed 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 Nov 2012 16:43:45 -0000 Hi WG, Can I please get at least 3 people (other than editors or WG chairs) that can reply that they looked at the document and it looks Ok? Saying that there are some issues with the document is also fine. I can't really send it to our responsible AD without any reviews. Thanks, Alexey From waehlisch@ieee.org Fri Nov 9 08:46:41 2012 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 8C52B21F8516 for ; Fri, 9 Nov 2012 08:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1LSleJNRiPY for ; Fri, 9 Nov 2012 08:46:40 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id A8B2821F847F for ; Fri, 9 Nov 2012 08:46:40 -0800 (PST) Envelope-to: sidr@ietf.org Received: from dhcp-917f.meeting.ietf.org ([130.129.9.127] helo=mw-PC.meeting.ietf.org) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TWrj4-0000F6-NF; Fri, 09 Nov 2012 17:46:39 +0100 Date: Fri, 9 Nov 2012 11:46:29 -0500 (Eastern Normalzeit) From: Matthias Waehlisch To: Alexey Melnikov In-Reply-To: <509D32CA.3080107@isode.com> Message-ID: References: <509D32CA.3080107@isode.com> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr wg Subject: Re: [sidr] Reviews of draft-ietf-sidr-rpki-rtr-protocol-mib-02.txt needed 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 Nov 2012 16:46:41 -0000 Hi Alexey, I read the document and have no objections. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Fri, 9 Nov 2012, Alexey Melnikov wrote: > Hi WG, > Can I please get at least 3 people (other than editors or WG chairs) that can > reply that they looked at the document and it looks Ok? Saying that there are > some issues with the document is also fine. I can't really send it to our > responsible AD without any reviews. > > Thanks, > Alexey > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From arturo.servin@gmail.com Fri Nov 9 08:53:59 2012 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 A7A4821F8718 for ; Fri, 9 Nov 2012 08:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE3VwX4SMbwm for ; Fri, 9 Nov 2012 08:53:59 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF0121F870F for ; Fri, 9 Nov 2012 08:53:59 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3149746pbb.31 for ; Fri, 09 Nov 2012 08:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AgIx/hSsd/PSoDjb6vU2Qtz6+G6Aaz2jvOfz6lXX3kA=; b=UTTNMpJcciaeoHFLeAPLQCaXRlgSC9lY9njaFHE62Ueaz28Ur+Oo0lgyL2gc5RCsxj OrMqel+eg6TiDyX8cNkex+nUQl/rzTYHhJH9VHSZqTMqLoVLMu5eE/mDXzu5OjqIX7IP JzTQ/ZIk7Yh7HW5xn+Yh2MweFSD7KHF3xVwO1qkTofu8iZ3AmSsjhkui49fEULnY6Z3u LkR1bnOINbQrkPGYzPKOFBL9dXNCt05TsB5dHMvv6jWpmr8MqjRil6zzput3y5rxjMys eJh3paqLuT9VljBTdi2pZf/jjmJgvyC6yG7k5RiaCnr4kHDtTihl9W2dQCO+ELexir00 y8yg== Received: by 10.68.83.68 with SMTP id o4mr35761295pby.25.1352480038475; Fri, 09 Nov 2012 08:53:58 -0800 (PST) Received: from dhcp-16f2.meeting.ietf.org (dhcp-16f2.meeting.ietf.org. [130.129.22.242]) by mx.google.com with ESMTPS id ai8sm11279302pbd.14.2012.11.09.08.53.56 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 08:53:57 -0800 (PST) Message-ID: <509D3522.7060906@gmail.com> Date: Fri, 09 Nov 2012 11:53:54 -0500 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> <509D2C04.4020704@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 16:53:59 -0000 Brian, Thanks for the clarification, very very useful. Regards, as On 09/11/2012 11:42, Brian Dickson wrote: > > > > > I'd like to note that in general, WG acceptance processes are a critical > part of IETF processes. > > In particular, the WG consensus on adoption, is the one critical place > in preventing "gaming the system". > > An adoption call should have three (or four) responses: > > Ready for Adoption > Needs more work BEFORE Adoption > Should not (never) be adopted > Abstain/don't care > > The "needs more work" is the way that WG participants can hold > authors/editors accountable for making requested changes. > > If a draft is accepted in its current state, then any promises by the > authors to make changes are much like promises by politicians during > election campaigns - not worth the paper they are written on. > > However, if the WG insists on changes BEFORE adoption, the reliance on > promises goes away - which is a good thing. > > Any discussion on the content of a draft, which is prompted by a WG > adoption request, SHOULD be taken by chairs as "Needs more work BEFORE > Adoption". > > Since this does not seem to have been the case, please ask the WG to > answer one of the four ways, explicitly. > > BTW: > > I believe that this draft should not be adopted in its current form (if > ever). > > Brian > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From carlosm3011@gmail.com Fri Nov 9 09:01:50 2012 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 9480721F8751 for ; Fri, 9 Nov 2012 09:01:50 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgMiGxLSOpkG for ; Fri, 9 Nov 2012 09:01:50 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7521F874E for ; Fri, 9 Nov 2012 09:01:39 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1862885dan.31 for ; Fri, 09 Nov 2012 09:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=J6dyKynwQoptOOAJXp4JpDsE9D3lJVzh2Eu6veOMSDw=; b=jc1V/xbat2Fhci+dh7QdHsdXlLBFjL1i0+3UYRjlWFdQ8330+icfYZrX91Ua0wr7Ql P177pqcLHzeNbsXl4jU/AN9U2agkZkD14/WW3/omOA7VVu4z/fjEL8v+c3vnZWlk9KxS M/ZDaOrlbwP1ZnviK1yc1+/DQlJ+dzVIMtjrcUrBHgIaaVPaKuFHTIGlB3dszKRnJKFd CLp4GhnULnsobyCwzo+3YXQrMi8xKqLzU/f91B+G9rQT26UILM68yOBRj+RdxwDOwUPP Z3xKPkBpnIFksJaPgT2xITazzudrgPfFouUH4sBgCuD+K3RG4bNlq7jeI25NgP0bTDC0 r87w== Received: by 10.66.86.165 with SMTP id q5mr26950160paz.18.1352480499534; Fri, 09 Nov 2012 09:01:39 -0800 (PST) Received: from ?IPv6:2001:df8:0:16:d50a:342d:e559:209b? ([2001:df8:0:16:d50a:342d:e559:209b]) by mx.google.com with ESMTPS id wg3sm17979778pbc.28.2012.11.09.09.01.37 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 09:01:38 -0800 (PST) Message-ID: <509D36F0.50302@gmail.com> Date: Fri, 09 Nov 2012 12:01:36 -0500 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alexey Melnikov References: <509D32CA.3080107@isode.com> In-Reply-To: <509D32CA.3080107@isode.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] Reviews of draft-ietf-sidr-rpki-rtr-protocol-mib-02.txt needed 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 Nov 2012 17:01:50 -0000 I've looked at it, have no objections. On 11/9/2012 11:43 AM, Alexey Melnikov wrote: > Hi WG, > Can I please get at least 3 people (other than editors or WG chairs) > that can reply that they looked at the document and it looks Ok? Saying > that there are some issues with the document is also fine. I can't > really send it to our responsible AD without any reviews. > > Thanks, > Alexey > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From andy@arin.net Fri Nov 9 09:42:24 2012 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 66F1D21F8595 for ; Fri, 9 Nov 2012 09:42:24 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrddOYC67O6e for ; Fri, 9 Nov 2012 09:42:24 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE021F8554 for ; Fri, 9 Nov 2012 09:42:23 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 270E4213600; Fri, 9 Nov 2012 12:42:23 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 4DCD921355C; Fri, 9 Nov 2012 12:42:22 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 9 Nov 2012 12:42:05 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.182]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Fri, 9 Nov 2012 12:41:18 -0500 From: Andy Newton To: Alexey Melnikov , Byron Ellacott Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: AQHNcmy8FCcE8Dzhaka0MZcJTJP7npdxX+YAgAAMpICAAEYPAIBEvmMAgAQbWICAJb+qgIAADbiAgAI//gD//8RHgA== Date: Fri, 9 Nov 2012 17:41:17 +0000 Message-ID: In-Reply-To: <509D2C04.4020704@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.149.252.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 17:42:24 -0000 On 11/9/12 11:15 AM, "Alexey Melnikov" wrote: >I think WG chairs (collectively) dropped the ball here: 3 of us have >discussed the acceptance call a couple of times. We would like to >apologize for sending inconsistent messages. > >After talking to various people this week, it looks like the best way >forward is for the chairs to redo the acceptance call and ask very >specific questions to keep everybody unconfused and hopefully happy. Alexey, Thanks for addressing this issue. Much appreciated. -andy From SONALKERA@battelle.org Fri Nov 9 12:10:44 2012 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 0499921F85EE for ; Fri, 9 Nov 2012 12:10:44 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1mw8KWwyGHd for ; Fri, 9 Nov 2012 12:10:43 -0800 (PST) Received: from egw3.battelle.org (egw3.battelle.org [131.167.253.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7164F21F8521 for ; Fri, 9 Nov 2012 12:10:43 -0800 (PST) Received: from pps.filterd (lp-prfpnta3 [127.0.0.1]) by lp-prfpnta3.battelle.org (8.14.5/8.14.5) with SMTP id qA9KAf27028291; Fri, 9 Nov 2012 15:10:41 -0500 Received: from lp-prfpnta5.milky-way.battelle.org ([10.50.10.72]) by lp-prfpnta3.battelle.org with ESMTP id 18c3y925m6-1; Fri, 09 Nov 2012 15:10:41 -0500 Received: from pps.filterd (lp-prfpnta5 [127.0.0.1]) by lp-prfpnta5.milky-way.battelle.org (8.14.5/8.14.5) with SMTP id qA9K8Cle026499; Fri, 9 Nov 2012 15:10:41 -0500 Received: from ws-bco-cas2.milky-way.battelle.org (ws-bco-cas2.milky-way.battelle.org [131.167.8.115]) by lp-prfpnta5.milky-way.battelle.org with ESMTP id 18c3xvsqye-1; Fri, 09 Nov 2012 15:10:41 -0500 Received: from WS-BEST-MBX1.milky-way.battelle.org (131.167.188.7) by ws-bco-cas2.milky-way.battelle.org (131.167.8.115) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 9 Nov 2012 15:10:41 -0500 Received: from WS-BEST-MBX1.milky-way.battelle.org ([131.167.188.7]) by WS-BEST-MBX1.milky-way.battelle.org ([131.167.188.7]) with mapi; Fri, 9 Nov 2012 15:10:39 -0500 From: "Sonalker, Anuja" To: Alexey Melnikov , sidr wg Date: Fri, 9 Nov 2012 15:10:36 -0500 Thread-Topic: [sidr] Reviews of draft-ietf-sidr-rpki-rtr-protocol-mib-02.txt needed Thread-Index: Ac2+mWTUl1lq9ifhQiShwcOrwhxTNwAHGheA Message-ID: References: <509D32CA.3080107@isode.com> In-Reply-To: <509D32CA.3080107@isode.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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-09_03:2012-11-09, 2012-11-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1211090193 Subject: Re: [sidr] Reviews of draft-ietf-sidr-rpki-rtr-protocol-mib-02.txt needed 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 Nov 2012 20:10:44 -0000 Hi Alexey, I looked at this document and have no objections with it. Anuja -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Ale= xey Melnikov Sent: Friday, November 09, 2012 11:44 AM To: sidr wg Subject: [sidr] Reviews of draft-ietf-sidr-rpki-rtr-protocol-mib-02.txt nee= ded Hi WG, Can I please get at least 3 people (other than editors or WG chairs) that c= an reply that they looked at the document and it looks Ok? Saying that ther= e are some issues with the document is also fine. I can't really send it to= our responsible AD without any reviews. Thanks, Alexey _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Fri Nov 9 18:16:46 2012 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 DAE8F21F85EE for ; Fri, 9 Nov 2012 18:16:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYOkxNfAO0s9 for ; Fri, 9 Nov 2012 18:16:46 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0021F85AB for ; Fri, 9 Nov 2012 18:16:46 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TX0cn-0006Lq-Mv for sidr@ietf.org; Fri, 09 Nov 2012 18:16:45 -0800 Message-ID: <509DB910.6000401@riw.us> Date: Fri, 09 Nov 2012 21:16:48 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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, 10 Nov 2012 02:16:47 -0000 > maybe? folk have to see a benefit to any of this in order for it to > move into production use. if as a first step resource certification > work gets me better filtering and/or more people filtering because > more reliable filtering is possible, good. > > eventually though, people will realize that: > 1) not everyone is filtering > 2) not everyone will filter > 3) the only solution left is something in the bgp update :( > > if there is another '3', let's talk about that. I don't think the conclusion follows from the premises, because it assumes: 1. Specifying new information in the BGP update will have the magical powers of forcing the deployment of said system. 2. The information required to resolve this problem cannot be carried in some other way, nor expressed with something other than a filter --or even that filters cannot express the solution to the leak issue. I find both of these presuppositions to be problematic, at best. > where else does the data from which you make a decision about 'leak or > not' come from? Lots and lots of places. Proposals have been made in the past, only to be shot down because they don't resolve the "man in the middle attack" (which is also a policy failure rather than "attack," and it has nothing to do with "a man in the middle"). Reality check: 1. Leaks are caused, essentially, by someone who isn't following policy. 2. Providers have said (on this list and otherwise) that they are not willing to release _any_ policy in _any_ way, _ever_ into the hands of _anyone_ (even, "this peer is not a transit AS"). 3. Any solution actually adopted _must_ be able to prevent leaks of this type, or it's essentially adding a lot of complexity and overhead for very minimal (or no) gain. Given these three points, we have an impasse. There are three possible solutions to this impasse: 1. Providers realize that much of the policy at the heart of preventing a leak is pretty much already public knowledge (if you're careful in analyzing the BGP table), and hence #2 is a red herring. 2. Create a system that allows you to announce enforceable policy without telling anyone what that policy is. I hear there is research in this area, but I've never seen the problem actually solved. 3. Do nothing. There might be a #4, but I imagine what it is. Russ -- <>< riwhite@verisign.com russw@riw.us From russw@riw.us Fri Nov 9 18:30:17 2012 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 A8F1921F8553 for ; Fri, 9 Nov 2012 18:30:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gccnuqQj89CX for ; Fri, 9 Nov 2012 18:30:17 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4140021F853E for ; Fri, 9 Nov 2012 18:30:17 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TX0ps-0006f3-SJ for sidr@ietf.org; Fri, 09 Nov 2012 18:30:16 -0800 Message-ID: <509DBC3B.8050707@riw.us> Date: Fri, 09 Nov 2012 21:30:19 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> <509DB910.6000401@riw.us> In-Reply-To: <509DB910.6000401@riw.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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, 10 Nov 2012 02:30:17 -0000 > There might be a #4, but I imagine what it is. -- insert "can't" in the appropriate place. Fingers faster than brain problem. :-) Russ -- <>< riwhite@verisign.com russw@riw.us From danny@tcb.net Sat Nov 10 08:46:06 2012 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 5847621F84E0 for ; Sat, 10 Nov 2012 08:46:06 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtFtpd-YPIYK for ; Sat, 10 Nov 2012 08:46:05 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB9321F84CF for ; Sat, 10 Nov 2012 08:46:05 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 03DF520BB for ; Sat, 10 Nov 2012 16:46:04 +0000 (UTC) Received: from [192.168.5.132] (ip-64-134-70-192.public.wayport.net [64.134.70.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 7FE2820AE; Sat, 10 Nov 2012 09:46:04 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <509DB910.6000401@riw.us> Date: Sat, 10 Nov 2012 11:46:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7F352D97-39D3-4813-91B0-B6C7A81E6873@tcb.net> References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <21369C10-3FDB-43F3-99BC-F40AFFF4784F@verisign.com> <509DB910.6000401@riw.us> To: Russ White X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Nov 10 09:46:04 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 509e84cc199631385910775 X-DSPAM-Factors: 27, Subject*limited+#+today, 0.01000, Subject*sidr+#+#+for, 0.01000, Subject*route+announcement, 0.01000, Subject*today+#+to, 0.01000, with+#+#+of, 0.01000, Subject*to+bogus, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*due+#+#+route, 0.01000, Subject*today+#+#+bogus, 0.01000, the+#+#+#+to, 0.01000, Subject*outage+today, 0.01000, of+#+#+at, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, would+#+to, 0.01000, at+#+#+PM, 0.01000, Subject*to+#+#+announcement, 0.01000, Subject*due+to, 0.01000, Subject*for+#+#+Google, 0.01000, their+#+#+on, 0.01000, Subject*need+#+SIDR, 0.01000, it+is, 0.01000, be+#+to, 0.01000, Subject*limited+#+#+due, 0.01000, that+#+#+#+the, 0.01000, Nov+#+#+#+9, 0.01000, Subject*today+due, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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, 10 Nov 2012 16:46:06 -0000 On Nov 9, 2012, at 9:16 PM, Russ White wrote: >=20 > 2. Providers have said (on this list and otherwise) that they are not > willing to release _any_ policy in _any_ way, _ever_ into the hands of > _anyone_ (even, "this peer is not a transit AS"). Actually, some subset of providers allegedly said this. I've not seen = any actual catalog of who, but it is certainly NOT everyone. Lots of = other folks do this today, via the IRRs, warts et al. You can get = "valid origin" capabilities anywhere without touching the protocols at = all. =20 > 3. Any solution actually adopted _must_ be able to prevent leaks of = this > type, or it's essentially adding a lot of complexity and overhead for > very minimal (or no) gain. Concur. > Given these three points, we have an impasse. There are three possible > solutions to this impasse: >=20 > 1. Providers realize that much of the policy at the heart of = preventing > a leak is pretty much already public knowledge (if you're careful in > analyzing the BGP table), and hence #2 is a red herring. Agreed. And given that providers don't even have a system that allows = them to automatically configure their customers based on certificated = data, well, can't necessarily blame them when these event occur.=20 Proceeding directly to RPKI-enabled BGPSEC and ignoring this problem as = acceptable residual would mean you're more concerned about what's routed = on the Internet, as opposed to the broader operational security = implications. =20 I could understand why governments or RIRs might find utility in that, = but given that neither is in the current operational system and now will = be, this gives me pause. Especially with the weight of what's being = proposed, where "large scale" measurements don't even represent 1% of = today's Internet, or consider things like rollover and other soft state = that routers would need to process and effectuate reachability upon. -danny= From sm@resistor.net Sat Nov 10 10:59:23 2012 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 32C7A21F84F3 for ; Sat, 10 Nov 2012 10:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdRvMcIRhDbW for ; Sat, 10 Nov 2012 10:59:22 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B2D21F8507 for ; Sat, 10 Nov 2012 10:59:21 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAAIxBwT029719; Sat, 10 Nov 2012 10:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1352573956; bh=XontqCF/i8GAlz5cTCtqa8pyo5scz9ok4lwzv/aZVzw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PA7YfogTQQPyb3B54WCXUvV1InAS7AgO7/WsMTfisW1a8q/jxNp5MlRYmVFBiKfjp G5uizRKZiNlMVE0sypQUr5BTb3RL6iAzSBAavJsTgU4fufdqeYr2OjeGku4oLiWlKM yCo6gyk6YOaSwLnkDVNToES0k8yWCeExloCXjupw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1352573956; i=@resistor.net; bh=XontqCF/i8GAlz5cTCtqa8pyo5scz9ok4lwzv/aZVzw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g6RMQbND1Eh5bEc3GXD9YbkYGjChwHTrhJU/02sQX25tPbsbZk/JOVpt1t5lZgfEw RBYeyqT59wrlDYjBTLTFnkHkjfzYfjuMyPUzAQf6+JMy5y+lsPGHGeN/d9LPPFa+Ov 0Ef1Ni4PnK//I2CNU2bFlLOsXJVjnWBaVyYvropw= Message-Id: <6.2.5.6.2.20121110095220.09c03100@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 10 Nov 2012 10:04:19 -0800 To: Brian Dickson From: SM In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> <509D2C04.4020704@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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, 10 Nov 2012 18:59:23 -0000 Hi Brian, At 08:42 09-11-2012, Brian Dickson wrote: >An adoption call should have three (or four) responses: > >Ready for Adoption >Needs more work BEFORE Adoption >Should not (never) be adopted >Abstain/don't care > >The "needs more work" is the way that WG participants can hold >authors/editors accountable for making requested changes. If people agree that the problem is worth solving and people agree to help with the "needs more work", the adoption is like saying "we are ok to do this work". >If a draft is accepted in its current state, then any promises by >the authors to make changes are much like promises by politicians >during election campaigns - not worth the paper they are written on. Not really, as you have the WGLC. There is also an option to submit an alternative proposal. The real question is actually about how to facilitate a more "structured" discussion. Regards, -sm From ietf@meetecho.com Sat Nov 10 13:26:53 2012 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 5655D21F85D4 for ; Sat, 10 Nov 2012 13:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mo-v-a0VJxC for ; Sat, 10 Nov 2012 13:26:52 -0800 (PST) Received: from smtpdg10.aruba.it (smtpdg10.aruba.it [62.149.158.240]) by ietfa.amsl.com (Postfix) with ESMTP id 54AB921F84F3 for ; Sat, 10 Nov 2012 13:26:52 -0800 (PST) Received: from [192.168.0.4] ([151.77.98.23]) by smtpcmd04.ad.aruba.it with bizsmtp id MxSo1k0070WGHKK01xSpbo; Sat, 10 Nov 2012 22:26:50 +0100 Message-ID: <509EC694.5050106@meetecho.com> Date: Sat, 10 Nov 2012 22:26:44 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Meetecho session recording 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, 10 Nov 2012 21:26:53 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From john@jlc.net Sat Nov 10 14:14:50 2012 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 6FC3921F8482 for ; Sat, 10 Nov 2012 14:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLAhB7AyWbgg for ; Sat, 10 Nov 2012 14:14:50 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D7A7C21F8481 for ; Sat, 10 Nov 2012 14:14:49 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id C379234124; Sat, 10 Nov 2012 17:14:49 -0500 (EST) Date: Sat, 10 Nov 2012 17:14:49 -0500 From: John Leslie To: Brian Dickson Message-ID: <20121110221449.GI78300@verdi> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> <509D2C04.4020704@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: sidr@ietf.org Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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, 10 Nov 2012 22:14:50 -0000 Brian Dickson wrote: >... Date: Fri, 9 Nov 2012 11:42:15 -0500 > > If a draft is accepted in its current state, then any promises by the > authors to make changes are much like promises by politicians during > election campaigns - not worth the paper they are written on. While technically true: 1) if the WGCs let this happen, it's an abuse of power. At adoption as a WG draft, authors "relinquish change control" and different persons must be appointed document editors if authors aren't OK with that. 2) nothing goes to IESG without consensus at WG LastCall. -- John Leslie From russw@riw.us Sat Nov 10 18:05:42 2012 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 6F7C121F885D for ; Sat, 10 Nov 2012 18:05:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYkHH4D6ma8Y for ; Sat, 10 Nov 2012 18:05:41 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id AB08821F8873 for ; Sat, 10 Nov 2012 18:05:41 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TXMvX-0006t2-Tu for sidr@ietf.org; Sat, 10 Nov 2012 18:05:36 -0800 Message-ID: <509F07F2.1090903@riw.us> Date: Sat, 10 Nov 2012 21:05:38 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <8B645B33-B736-45A5-A7F4-9A632600E0FD@tcb.net> <7F4CEF2A-AB52-42F8-9669-20104862BBA6@tcb.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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, 11 Nov 2012 02:05:42 -0000 > as has been said many times, we agree route leaks are a problem. they > are not the only problem. > > please do not send me any more email without a proposed solution. Generally speaking, the best path to good engineering is to define the problem first, then suggest solutions. I understand this isn't the way SIDR works --solutions are proposed, to be followed by problem statements, but we are talking about the way engineering should be done, not the way it's been done here historically. Please do not send any more email (or drafts) without a clearly defined problem. Russ -- <>< riwhite@verisign.com russw@riw.us From russw@riw.us Sat Nov 10 18:26:32 2012 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 38FD821F889F for ; Sat, 10 Nov 2012 18:26:32 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLuF-lxwWHpY for ; Sat, 10 Nov 2012 18:26:31 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B4EFC21F8847 for ; Sat, 10 Nov 2012 18:26:31 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TXNFn-0007Pj-BM for sidr@ietf.org; Sat, 10 Nov 2012 18:26:31 -0800 Message-ID: <509F0CDA.1090607@riw.us> Date: Sat, 10 Nov 2012 21:26:34 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <311C4656-8EF2-4A78-BD69-098BC5DA5216@danyork.org> <593DB9C4-D44C-403D-A002-589E7BA510FF@tcb.net> <6FE97B00-8CA4-4FE5-AC11-3CF7F3DA5FF1@castlepoint.net> <06073D88-ABF8-4E33-818B-8698A3D6D6CB@castlepoint.net> <1DD0A85E-3FC5-4A89-8CD6-AE00C47160D6@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] The need for SIDR - Google limited outage today due to bogus route announcement 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, 11 Nov 2012 02:26:32 -0000 > route leaks, as we anecdotally know them, are an operational problem. > imiho, they are not particularly a security problem. but that does not > mean i think the ietf routing community should not be working on a > solution, quite the opposite. You're walking through the office and see someone picking papers up off your desk. Do you ask if they are properly signed in, and through which door they entered? Or do you ask what their intent is and whether or not they're authorized to be there (which is still intent)? If you receive a route, you need to know more than who touched it to know if it's correct or not. You must know the intent so you can compare it to the reality you see in front of your face. We've been walking around this problem of intent for years, trying to mask it out of the problem to be solved, because we somehow think it can't be solved. The latest attempt is to call it an operational problem and push it to GROW. Three points: 1. The problem of intent was always going to come back and bite us where it hurts. This small incident just illustrates the scope of the problem. 2. Including signed "evil bits," doesn't solve anything in the long run, because they're still just "evil bits." Are you planning on having a new bit for every possible intent? And carry them all the way through the system although someone four hops away really doesn't care? 3. It's sweet that everyone is trying to push the problem onto GROW, but if you do that, expect to take GROW to take over your entire charter (or all the meaningful work in this space), because knowing intent is the only problem worth solving here. Suggestions have been made before and rejected in this space, and more suggestions are available (if you take five minutes and poke around looking for them). However, it's always going to be difficult to get alternate options through a working group founded on the premise of standardizing on specific solution, rather than solving a problem. Don't ask for suggestions unless you really mean it. And if someone gives you one, listen, rather than throwing them out on their ear. Russ -- <>< riwhite@verisign.com russw@riw.us From Sandra.Murphy@sparta.com Mon Nov 12 07:50:06 2012 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 4CB2D21F854C for ; Mon, 12 Nov 2012 07:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.588 X-Spam-Level: X-Spam-Status: No, score=-101.588 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXliF6is7JoC for ; Mon, 12 Nov 2012 07:50:05 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54921F85C4 for ; Mon, 12 Nov 2012 07:50:05 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qACFnxf6022236; Mon, 12 Nov 2012 07:50:00 -0800 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qACFnx08003938; Mon, 12 Nov 2012 07:49:59 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Mon, 12 Nov 2012 10:49:59 -0500 From: "Murphy, Sandra" To: George Michaelson , "sidr@ietf.org list" Thread-Topic: [sidr] If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. Thread-Index: AQHNqpBEn7TfiMC940mnLUzACOlV1JfmhQ9e Date: Mon, 12 Nov 2012 15:49:57 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6EB586@Hermes.columbia.ads.sparta.com> References: <010952DB-D6E1-4394-97E6-4F8BC844C435@apnic.net> In-Reply-To: <010952DB-D6E1-4394-97E6-4F8BC844C435@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. 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 Nov 2012 15:50:06 -0000 I happened across the following quite by chance. It seems to be further ex= planation of the 5 trust anchors George mentioned previously.=0A= =0A= http://www.apnic.net/services/services-apnic-provides/resource-certificatio= n/RPKI=0A= =0A= --Sandy, speaking as regular ol' member=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of George Mic= haelson [ggm@apnic.net]=0A= Sent: Monday, October 15, 2012 12:47 AM=0A= To: sidr@ietf.org list=0A= Subject: [sidr] If you are using APNIC as an RPKI trust anchor, please upda= te your Trust Anchor Set.=0A= =0A= If you are using APNIC as an RPKI trust anchor, please update your=0A= Trust Anchor Set.=0A= =0A= APNIC will be switching to a new RPKI 'split' trust anchor system=0A= on the 25th of October. This change is needed to align APNIC=0A= administered resources with their allocation hierarchy. These=0A= resources will also be certified under each responsible parent=0A= registry at the appropriate time.=0A= =0A= In accordance with RFC6490 the old APNIC Trust Anchor Locator,=0A= associated certificate and repository will be removed, when the=0A= certificate expires on the 28th of October.=0A= =0A= 5 new Trust Anchor Locator (TAL) have been published. These will=0A= be kept up to date as an independent trust anchor set for resources=0A= maintained by APNIC. The production cycle will start on the 25th=0A= of October.=0A= =0A= Relying parties must add these new TAL by the 25th of October in=0A= order to maintain continuity of validation.=0A= =0A= If you have any questions please contact me.=0A= =0A= George Michaelson (ggm@apnic.net)=0A= =0A= =0A= Please add the following to your trust anchor set:=0A= =0A= rsync://rpki.apnic.net/repository/apnic-rpki-root-afrinic-origin.cer=0A= MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuMLL96YV9pf0rZ4Ow/bk=0A= cgpoPfsRzkcgmisyCuMUdotHwrp8pepujhohatScRK09ILRrZYCdpX4121MJhqXC=0A= P3u3hy9fF0CeARKX/Q82nJccD4dtUp23UcFys8hwJgNYZI910ajkAxwNT//H/TFw=0A= oUYbzZGBR7o2awMc7GdQl/j6dgOkV6AfYy5DyDEgOUNHnUxED2rreefL/E2Fr2ST=0A= Esar6bTR4Tg4+nVF1PjAkgN0tKZYe4wZ6VmtqV/VTngSLysim6av7ki+JR3cVgVU=0A= OqXeh1vPjH2tNu6u9bX37ZrdVb6NBRer9I99IDbKvyhELb6nzo8+Q74zga9HI+Pf=0A= QwIDAQAB=0A= =0A= rsync://rpki.apnic.net/repository/apnic-rpki-root-arin-origin.cer=0A= MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp6vscYtzhe0CfFk5Ro44=0A= llPhsInXtfAxqfYmK7m9V3khkqK3d3/ZAW6pcJm7qW8XhEGl+F5mUeeLIm5JoIhr=0A= kT5B5M6uL0VlCCkZJH4h76ybOa83vWITNZEDy9L3c3nK4S+Basu3vYoE4ICXGG+J=0A= 7zg5Iw9saV+p03E2w1g16pt1QI3Cnggp6edkeWClEz3aPw/ULOIHb7YmatWwdERl=0A= tL9LsuMSKszQLUY7F4XVpxey/rJYAZgzDUh+b6813WAClCkkydNjsbviuekAWJbx=0A= sW7Mcw53u30K4g8MP03CjkDOubyoR4Qo99R1UQJCdrRsFKbSSfN/fOA4y7ikc3xs=0A= jQIDAQAB=0A= =0A= rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer=0A= MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8=0A= qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI=0A= 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr=0A= LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf=0A= i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H=0A= cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou=0A= 0wIDAQAB=0A= =0A= rsync://rpki.apnic.net/repository/apnic-rpki-root-lacnic-origin.cer=0A= MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyoYPp3l3DWyPtLWrmRn4=0A= Oux9hQ5bxd0SX/f6ygHxik+I3eMJP5J0Pr2e500tyXb2uKsX9kDqu/kckr+TUMhV=0A= BHd5yAv8OAE3YYEvpz/7uTX7cYy2yUeA76OEP75Y88OIQEzGpPLNpIzDxMggxuDh=0A= IhkA5xMiUJgVoEgmWSzR+MuRBjv2422wAGB5GpLgYsOjpwvG0VPmhnE+39+10ucQ=0A= CLt0Ny5kOR4an2tkvHjm7rzKDnFm8MWxPzAWESdf+8g7ITzSglqxDNiK5E5rdzNt=0A= h1Kvp+9RwaFArw6Ky1A4HhnoplN4EfKwxq0YamuKV0ZTTpWyT2+qDuE6sOfHRbJ0=0A= 5QIDAQAB=0A= =0A= rsync://rpki.apnic.net/repository/apnic-rpki-root-ripe-origin.cer=0A= MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwsQlXmEklLYApoDo7GEa=0A= NNTEGFPU5wJpi04iXuga2xn+g/TMLOlyJbjuPYRtRm/7VbRnN3m9Ta+WETy03+Fm=0A= EbXzB4xxhJKVik/ARHBnrBWhLyURy8Q5/XplE9cJein37IE1mIsbKM7o/90S225w=0A= 7GuvW7T4kjPWYmBFOywHWsfQO1EdsgiJrkz+Ab67ZkdSIiKHkf2UE6/MrbDEj+QK=0A= 9+s/vKH8BtDhaLmTWY+bVvfJ3+AWDH6roo1ozbl5yamQFbLOl3ns30f3yOJcNSNu=0A= /qgMQRRyp2sXXQovhTy8yqm3LFspaCWnTmQtBieWZwibuOa4Z27A1FzTMst2T4wY=0A= /wIDAQAB=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From christopher.morrow@gmail.com Wed Nov 14 14:27:04 2012 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 EE5A521F8701 for ; Wed, 14 Nov 2012 14:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7xhmLbiSHSC for ; Wed, 14 Nov 2012 14:27:02 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3E2221F8575 for ; Wed, 14 Nov 2012 14:27:01 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so675451eek.31 for ; Wed, 14 Nov 2012 14:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=83LZu2QBjx5DzGX4PapgRTrs6ekS5PnZi1lAWlzxEGU=; b=LH8Yb6knUwEYhgvAaUWD/nBshoxDxnMW246xa6thRwPfW7ZcsMqfCe/hTbHfKungCO qInl+VI9e2UGZd3bmRJMdfP0xa6sgJf8EdPSlXb+mYXmA31QSnTY0Fo5up61csDa7G7T 5mFKC5oIVocBHDrjFWgecabLTS2ppc/cv1R23XFuMS00pv3bHlRvFPOc+4pb3/8WBvKr stkKlqfjwAlj0xZ5TVU3hlkwJFKz1qMfJPSLR/liY3WvvFdeV5vGIUhJwi06+/8dGsXe v38o8whjH5DdoBf8NEFZlDXlBIxguUPDYGYoRbhJNcToSZkTixhHsRaLYelkXflfXVPe v/tg== MIME-Version: 1.0 Received: by 10.14.175.71 with SMTP id y47mr91529530eel.36.1352932021033; Wed, 14 Nov 2012 14:27:01 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 14 Nov 2012 14:27:00 -0800 (PST) In-Reply-To: <1E01BA5D-DCA0-4029-B541-1E50C2D9A55D@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63B6E5CC0@Hermes.columbia.ads.sparta.com> <7011BD00-1537-4BC6-AB11-3051D4F5186B@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63B6E8885@Hermes.columbia.ads.sparta.com> <1B884368-6850-46D6-8C93-34A83255FED7@arin.net> <509BCBF5.3030406@gmail.com> <1E01BA5D-DCA0-4029-B541-1E50C2D9A55D@ripe.net> Date: Wed, 14 Nov 2012 17:27:00 -0500 X-Google-Sender-Auth: 7HKzziQbf0FnbtxpKihW_0VK0SM Message-ID: From: Christopher Morrow To: Tim Bruijnzeels Content-Type: text/plain; charset=ISO-8859-1 Cc: Arturo Servin , sidr@ietf.org Subject: Re: [sidr] additions and changes to agenda on Friday 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 Nov 2012 22:27:04 -0000 On Fri, Nov 9, 2012 at 9:35 AM, Tim Bruijnzeels wrote: > Good. On that note I think it's worthwhile thinking about different > complementary ways to deal with this. I.e. make the server side more > scalable as well as considering flooding protocols and other ways to share > data between RPs. can we break the 'current protocol choice' away from the 'future protocol choice(s)' discussion then? Meaning, can those folk interested in pursuing alternate options decide on: 1) size of a single repository (pick a large ISP as a for-instance, some one like L3 who has ~30k customers, each with 5 routes average x2 for keyroll situations? - or better yet, make up your own set of numbers, document them and the reasoning why) 2) number of repositories in existence (say, number of ASN in the global table, or ...) 3) re-fetch times of every repository (3 hrs for instance for any object type?) 4) average network latency from fetcher to fetchee (~150ms for instance) document that and then start looking at tradeoffs and consequences? talking about other transports is good, I think to date we keep getting muddled in 'but today works so...' If we want to re-think the transport, or offer alternate transports for existing folks, let's step away from 'today works'. -chris regular-guy-voice. From eosterweil@verisign.com Wed Nov 14 19:48:04 2012 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 C7ED221F8510 for ; Wed, 14 Nov 2012 19:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzooBidcy6ji for ; Wed, 14 Nov 2012 19:48:04 -0800 (PST) Received: from exprod6ob106.obsmtp.com (exprod6ob106.obsmtp.com [64.18.1.190]) by ietfa.amsl.com (Postfix) with ESMTP id 175C921F8503 for ; Wed, 14 Nov 2012 19:48:04 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUKRl8zMUcLWCe01vEH7rqRLZjHdbnJco@postini.com; Wed, 14 Nov 2012 19:48:03 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qAF3m0tD023172 for ; Wed, 14 Nov 2012 22:48:02 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.46]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Nov 2012 22:47:59 -0500 From: Eric Osterweil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Nov 2012 22:47:57 -0500 Message-Id: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Nov 2012 03:47:59.0912 (UTC) FILETIME=[019EAA80:01CDC2E4] Subject: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 03:48:04 -0000 Hey everyone, A couple of us have done some quick back-of-the-envelope style = calculations to help get an idea of what a global deployment of RPKI = (supporting a global BGPSEC deployment) might look like, if we were to = be able to deploy it. We've written up our methodology, evaluation, and = findings in a short little tech-note here: http://techreports.verisignlabs.com/tr-lookup.cgi?trid=3D1120005 What we tried to do was calculate an extreme _lower_bound_ on what the = overall gather/fetch times might be for a cache trying to gather a fully = deployed RPKI repository. This seemed to be particularly opportune = moment to raise this topic, re: some comments recently posted in the = thread, ``Re: [sidr] additions and changes to agenda on Friday:'' > 1) size of a single repository (pick a large ISP as a for-instance, > some one like L3 who has ~30k customers, each with 5 routes average x2 > for keyroll situations? - or better yet, make up your own set of > numbers, document them and the reasoning why) > 2) number of repositories in existence (say, number of ASN in the > global table, or ...) > 3) re-fetch times of every repository (3 hrs for instance for any > object type?) > 4) average network latency from fetcher to fetchee (~150ms for = instance) >=20 > document that and then start looking at tradeoffs and consequences? What we found is that by creating a _systematic_ estimate of what a = global RPKI would look like, we wind up with roughly 1.5 million objects = (we explain why we feel this is a large _underestimate_ in the = tech-note), and in order to ensure that all caches have received updated = information (such as getting new certificates/CRLs/etc disseminated), = repositories may have to wait about a month (roughly 32 days by our = estimates), just for gatherers to reliably pick up a repo's changes. = Or, a month before a key compromise might get remediated throughout the = RPKI system. Our sincere hope is that this tech note will be a living document. To = that end, comments, corrections, and feedback are very welcome. Eric= From brweber2@yahoo.com Wed Nov 14 20:29:51 2012 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 4B16121E8039 for ; Wed, 14 Nov 2012 20:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F2tQwfm0mO7 for ; Wed, 14 Nov 2012 20:29:50 -0800 (PST) Received: from nm8-vm7.bullet.mail.gq1.yahoo.com (nm8-vm7.bullet.mail.gq1.yahoo.com [98.136.218.230]) by ietfa.amsl.com (Postfix) with ESMTP id DB6CC21E8049 for ; Wed, 14 Nov 2012 20:29:49 -0800 (PST) Received: from [98.137.12.174] by nm8.bullet.mail.gq1.yahoo.com with NNFMP; 15 Nov 2012 04:29:49 -0000 Received: from [208.71.42.203] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 15 Nov 2012 04:29:49 -0000 Received: from [127.0.0.1] by smtp214.mail.gq1.yahoo.com with NNFMP; 15 Nov 2012 04:29:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352953789; bh=9rOLZo+EUlAJfYLSK4epFoEA+kwiKnp67KOzBmxXAYs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=utQ3PQyOK1GFhez09HMbyfLkp3RzzIeJK5TvLXA5zQcVxYl7sXpCfzftL1O5hAfiH6qjonfrsP5/bj4qiE4ETf8xzuu2sReZz5JXGv+eWmMup7g8mSKMo839FU7hnlPgQnW7uVejjNTLDPf4TJws8HwX1LUkYZJHxKlM3Gg3zHw= X-Yahoo-Newman-Id: 182785.33196.bm@smtp214.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Y.8UpEsVM1mn3oj7fs48ysxasolNfgflYsabjH1kA6Q7cbv SFIT9Bd3EEaXTmp5Ss_sXENMHmom4obPk3mBr2ns.W8Nj3UXznBxM5jrSWtN 1Qhbs92e7G4mkKAgi97evfyRkMmxpgISvNTNrqu3wFLqe_fzWLR4NLi3vsmA b5Ci3MRuvv2KPwvch9zGGodZ7wriLcvEzylFDo3b3ppQDAz2GBsPi2wOQmXo S4SXm_WeHcGGn3RiBTBwlbNsPg.my_zvnghUW3yBCstRGG0OQxl01z_vXFVl a3tKR6LBAXmmiZIet79gP9L5bqLq2sfYyL74XAQP2VNfeq90t7CUiw6B_Kut BVgi67hEf_Ji9uIYYNbNX5pKoVyCqkeLRkohPfPvM2e24p9x.lrmLs5StSDm nrYLANQmnpEydyPmcL6Rx6UiQqXc3hgdicMRXTbskv5na.Rlje_GGc_skOyj JvmFeSNWNXqPfyevqKLqMl0Al77SqZaDzI6sn4BIuUfMyTwEgOvdkHv8Qida Pe.FUFJ8EOLo6aBzQXI6aIXVSid8ubeZDLHLEM0KkmTAn7DJbFssB7MiABku eFNAWToNmE02k29NZrbE8JpdHpA-- X-Yahoo-SMTP: f4ZrQXCswBB5jGYwSTd4wDs0ZJPe Received: from [192.168.1.8] (brweber2@68.100.90.3 with plain) by smtp214.mail.gq1.yahoo.com with SMTP; 14 Nov 2012 20:29:49 -0800 PST Content-Type: multipart/alternative; boundary="Apple-Mail=_BCA9EF6F-B8E5-4154-B368-080DE9ABDF3D" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Bryan Weber In-Reply-To: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> Date: Wed, 14 Nov 2012 23:29:45 -0500 Message-Id: <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1499) Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 04:29:51 -0000 --Apple-Mail=_BCA9EF6F-B8E5-4154-B368-080DE9ABDF3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have quite a few questions/statements about this document. If you feel = that this list is not the appropriate place to answer them please = respond to me at bryan@cobenian.com. Thanks. *) Aren't the EE certs contained in the Certificate, Manifest and ROA = artifacts? Should they be counted as separate items to retrieve? *) I'm not sure about the status of ghostbuster records today. Has any = RIR implemented or deployed them yet? To my knowledge an RPKI repository = contains CA certs with RFC 3779 extensions, manifests, CRLs and ROAs. = Admittedly I am not familiar with the implementations of all of the = RIRs. *) Is there any reason that ARIN's pilot is listed? The service is = deprecated and the production system is live at this point. Granted it = probably does not have a large volume of data yet. *) You note that=20 "In addition, in regards to multihoming, we need one ROA and one EE = certi=EF=AC=81cate for each feasible origin for a pre=EF=AC=81x, yet we will only see on entry in a RIB." but on the other hand because of the maximum length in a ROA I believe = that it is very difficult to surmise a relationship between the number = of ROAs and the number of entries in the RIB. *) Just as a side note, combining tables 1 and 2 might make the data = easier to read. In separate tables I am forced to keep find the = correlated rows. *) Just for my own education, what are the router EE certs? *) Another question: should the set of interconnected repositories be = considered a directed graph or a tree hierarchy? Since the certs are = hierarchical shouldn't the URIs pointing to external repositories be = hierarchical as well? *) Does cache synching have to be done serially? If these estimates are accurate then the I think the current expiry = periods of manifests in some of the RIRs would be considered woefully = inadequate.=20 Regards, Bryan On Nov 14, 2012, at 10:47 PM, Eric Osterweil = wrote: > Hey everyone, >=20 > A couple of us have done some quick back-of-the-envelope style = calculations to help get an idea of what a global deployment of RPKI = (supporting a global BGPSEC deployment) might look like, if we were to = be able to deploy it. We've written up our methodology, evaluation, and = findings in a short little tech-note here: > http://techreports.verisignlabs.com/tr-lookup.cgi?trid=3D1120005 >=20 > What we tried to do was calculate an extreme _lower_bound_ on what the = overall gather/fetch times might be for a cache trying to gather a fully = deployed RPKI repository. This seemed to be particularly opportune = moment to raise this topic, re: some comments recently posted in the = thread, ``Re: [sidr] additions and changes to agenda on Friday:'' >> 1) size of a single repository (pick a large ISP as a for-instance, >> some one like L3 who has ~30k customers, each with 5 routes average = x2 >> for keyroll situations? - or better yet, make up your own set of >> numbers, document them and the reasoning why) >> 2) number of repositories in existence (say, number of ASN in the >> global table, or ...) >> 3) re-fetch times of every repository (3 hrs for instance for any >> object type?) >> 4) average network latency from fetcher to fetchee (~150ms for = instance) >>=20 >> document that and then start looking at tradeoffs and consequences? >=20 > What we found is that by creating a _systematic_ estimate of what a = global RPKI would look like, we wind up with roughly 1.5 million objects = (we explain why we feel this is a large _underestimate_ in the = tech-note), and in order to ensure that all caches have received updated = information (such as getting new certificates/CRLs/etc disseminated), = repositories may have to wait about a month (roughly 32 days by our = estimates), just for gatherers to reliably pick up a repo's changes. = Or, a month before a key compromise might get remediated throughout the = RPKI system. >=20 > Our sincere hope is that this tech note will be a living document. To = that end, comments, corrections, and feedback are very welcome. >=20 > Eric > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_BCA9EF6F-B8E5-4154-B368-080DE9ABDF3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 bryan@cobenian.com. =  Thanks.

*) Aren't the EE certs contained in = the Certificate, Manifest and ROA artifacts? Should they be counted as = separate items to retrieve?

*) I'm not sure about the = status of ghostbuster records today. Has any RIR implemented or deployed = them yet? To my knowledge an RPKI repository contains CA certs with RFC = 3779 extensions, manifests, CRLs and ROAs. Admittedly I am not familiar = with the implementations of all of the RIRs.

*) = Is there any reason that ARIN's pilot is listed? The service is = deprecated and the production system is live at this point. Granted it = probably does not have a large volume of data = yet.

*) You note = that 

"In addition, in regards to = multihoming, we need one ROA and one EE certi=EF=AC=81cate for each = feasible origin for
a pre=EF=AC=81x, yet we will only see on = entry in a RIB."

but on the other hand = because of the maximum length in a ROA I believe that it is very = difficult to surmise a relationship between the number of ROAs and the = number of entries in the RIB.

*) Just as a side = note, combining tables 1 and 2 might make the data easier to read. In = separate tables I am forced to keep find the correlated = rows.

*) Just for my own education, what are = the router EE certs?

*) Another question: = should the set of interconnected repositories be considered a directed = graph or a tree hierarchy? Since the certs are hierarchical shouldn't = the URIs pointing to external repositories be hierarchical as = well?

*) Does cache synching have to be done = serially?

If these estimates are accurate then = the I think the current expiry periods of manifests in some of the RIRs = would be considered woefully = inadequate. 

Regards,
Bryan
<= div>

On Nov 14, 2012, at 10:47 PM, Eric = Osterweil <eosterweil@verisign.com> = wrote:

Hey everyone,

A couple of us have done some quick = back-of-the-envelope style calculations to help get an idea of what a = global deployment of RPKI (supporting a global BGPSEC deployment) might = look like, if we were to be able to deploy it.  We've written up = our methodology, evaluation, and findings in a short little tech-note = here:
= = http://techreports.verisignlabs.com/tr-lookup.cgi?trid=3D1120005
What we tried to do was calculate an extreme _lower_bound_ on what the = overall gather/fetch times might be for a cache trying to gather a fully = deployed RPKI repository.  This seemed to be particularly opportune = moment to raise this topic, re: some comments recently posted in the = thread, ``Re: [sidr] additions and changes to agenda on = Friday:''
1) size of a single repository = (pick a large ISP as a for-instance,
some one like L3 who has ~30k = customers, each with 5 routes average x2
for keyroll situations? - or = better yet, make up your own set of
numbers, document them and the = reasoning why)
2) number of repositories in existence (say, number = of ASN in the
global table, or ...)
3) re-fetch times of every = repository (3 hrs for instance for any
object type?)
4) average = network latency from fetcher to fetchee (~150ms for = instance)

document that and then start looking at tradeoffs and = consequences?

What we found is that by creating a =  _systematic_ estimate of what a global RPKI would look like, we = wind up with roughly 1.5 million objects (we explain why we feel this is = a large _underestimate_ in the tech-note), and in order to ensure that = all caches have received updated information (such as getting new = certificates/CRLs/etc disseminated), repositories may have to wait about = a month (roughly 32 days by our estimates), just for gatherers to = reliably pick up a repo's changes.  Or, a month before a key = compromise might get remediated throughout the RPKI system.

Our = sincere hope is that this tech note will be a living document.  To = that end, comments, corrections, and feedback are very = welcome.

Eric
_______________________________________________sidr mailing = list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

= --Apple-Mail=_BCA9EF6F-B8E5-4154-B368-080DE9ABDF3D-- From arturo.servin@gmail.com Wed Nov 14 20:36:43 2012 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 4F34721E8048 for ; Wed, 14 Nov 2012 20:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+m07DCTFQuh for ; Wed, 14 Nov 2012 20:36:41 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC521F853F for ; Wed, 14 Nov 2012 20:36:41 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id i4so268513ggn.31 for ; Wed, 14 Nov 2012 20:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ojybheJLXuO0BYA+M11ihIEiGGjqAABl0YbS+xkRrS8=; b=oIFst+m6QPdmvoLBW16nOi46vbHduPx/sJatbI7eI5Gj0oBNd/wn26SAhV/Y+2913o B0QU4AeghwIoz6SK5TyBebLKaFJDPrFf7DE1CX2lGUuTlRsx4zAEdE3jwNuSsHtltcry 8mZ7IXdHYUKKBA2q8LpsqUqgeTNxjUAMx5QbSB0Rm5g5W18tnZCesFxx1t7r4ZhDBqBq G7uZ1ZJIiR7D+9/Ew1kFPnHt9ThrR6/Zcoj9T0PYOVNktEhivG7Ac0DzIoDEPWjXvPSS nwqLpwuvDL6T2zztFLlGlB7whxf90l6ghtpE429IkabNERPyZfVJ12086IE5vJVJkyHa ecrQ== Received: by 10.236.92.6 with SMTP id i6mr29452366yhf.40.1352954200490; Wed, 14 Nov 2012 20:36:40 -0800 (PST) Received: from ?IPv6:2800:af:ba30:fa08:d4ff:760d:af8:6568? ([2800:af:ba30:fa08:d4ff:760d:af8:6568]) by mx.google.com with ESMTPS id z65sm14981538yhe.22.2012.11.14.20.36.37 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 20:36:39 -0800 (PST) Message-ID: <50A47152.6010903@gmail.com> Date: Thu, 15 Nov 2012 02:36:34 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> In-Reply-To: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 04:36:43 -0000 Erick Very interesting research. But I am finding difficult to understand how you got 1.4 M objects. Let me try to explain what I have seen in the young deployment of RPKI. For simplicity let's use the "hosted" model of RIRs. Let's suppose, each RIR issues in average 1 certificate per member containing all the resources (v4,v6,ASNs). I would say that there are 40,000 entities holding IP(4 and 6) prefixes and/or ASNs in the world (same as number of ASs). What I have see is that most prefix holders issue one roa with all the resources, but let's use 5 ROAs per organization as average. Then we have: 40,000 certificates 200,000 roas 80,000 CRL,manifest 40,000 ghostbuster (not very deployed but let's count it) Am I missing something besides the Router EE? Or is the Router EE that makes the difference? It seems that we agree that Ototal is the same equation, but the values for Cas, Eas, etc. are different. But, anyways. It's aprox 350K objects. If we want to load all in 5 minutes (it would be good to define what is acceptable) we need to deliver objects in less 0.00085 secs. Regards, as On 15/11/2012 01:47, Eric Osterweil wrote: > Hey everyone, > > A couple of us have done some quick back-of-the-envelope style calculations to help get an idea of what a global deployment of RPKI (supporting a global BGPSEC deployment) might look like, if we were to be able to deploy it. We've written up our methodology, evaluation, and findings in a short little tech-note here: > http://techreports.verisignlabs.com/tr-lookup.cgi?trid=1120005 > > What we tried to do was calculate an extreme _lower_bound_ on what the overall gather/fetch times might be for a cache trying to gather a fully deployed RPKI repository. This seemed to be particularly opportune moment to raise this topic, re: some comments recently posted in the thread, ``Re: [sidr] additions and changes to agenda on Friday:'' >> 1) size of a single repository (pick a large ISP as a for-instance, >> some one like L3 who has ~30k customers, each with 5 routes average x2 >> for keyroll situations? - or better yet, make up your own set of >> numbers, document them and the reasoning why) >> 2) number of repositories in existence (say, number of ASN in the >> global table, or ...) >> 3) re-fetch times of every repository (3 hrs for instance for any >> object type?) >> 4) average network latency from fetcher to fetchee (~150ms for instance) >> >> document that and then start looking at tradeoffs and consequences? > > What we found is that by creating a _systematic_ estimate of what a global RPKI would look like, we wind up with roughly 1.5 million objects (we explain why we feel this is a large _underestimate_ in the tech-note), and in order to ensure that all caches have received updated information (such as getting new certificates/CRLs/etc disseminated), repositories may have to wait about a month (roughly 32 days by our estimates), just for gatherers to reliably pick up a repo's changes. Or, a month before a key compromise might get remediated throughout the RPKI system. > > Our sincere hope is that this tech note will be a living document. To that end, comments, corrections, and feedback are very welcome. > > Eric > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Wed Nov 14 21:23:35 2012 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 4630E21E8053 for ; Wed, 14 Nov 2012 21:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOvcAnX+PN7y for ; Wed, 14 Nov 2012 21:23:34 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2747C21E8051 for ; Wed, 14 Nov 2012 21:23:33 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so808543eek.31 for ; Wed, 14 Nov 2012 21:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=lZI6i7jIAzIs7a0QFJcjrp0bIJ/KnhRnvqYlwMxgex4=; b=J+dvKHrN/D2urqdfbYRd2s+dZTZ/bAaevb6E21sIkvlvLDwxo4RRwusVmKdirelxSL q+QarDeaaIAeDUzZ/XBkCls58wEkfHPxULQLA8FDqDrpaVqOteO/HFrec4sKHV+LuT21 BguTK947POy8pEpdwKtcDswWOc+MHuRrogV7jcCis+2xJSYNHoh2H/uGXpSGujEPLd7u r1mXDGWgi90XljVeU4MLcwpnzS3VKKBqBiA0/hZ1ddxUZRJBcIM4waBPGYlVIKyx8BKT SkU/uubHCGgt+AHdCFw9AGNaZKUFpLy7+IwCr/7NAjzjPExT1s+S7gMOO82EWz5/wtQl g8og== MIME-Version: 1.0 Received: by 10.14.175.71 with SMTP id y47mr94971509eel.36.1352957013034; Wed, 14 Nov 2012 21:23:33 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Wed, 14 Nov 2012 21:23:32 -0800 (PST) In-Reply-To: <50A47152.6010903@gmail.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50A47152.6010903@gmail.com> Date: Thu, 15 Nov 2012 00:23:32 -0500 X-Google-Sender-Auth: J5hpJkdtg5--eHyuyxDwuCRoXrA Message-ID: From: Christopher Morrow To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 05:23:35 -0000 1 quick note on the numbers below (I've not read the paper, just the commen= tary) also, thanks to eric for making some work available, and taking a stab at the numbers/sizing/speeding. On Wed, Nov 14, 2012 at 11:36 PM, Arturo Servin w= rote: > Erick > > Very interesting research. But I am finding difficult to understa= nd how > you got 1.4 M objects. > > Let me try to explain what I have seen in the young deployment of= RPKI. > For simplicity let's use the "hosted" model of RIRs. > > Let's suppose, each RIR issues in average 1 certificate per membe= r > containing all the resources (v4,v6,ASNs). I would say that there are > 40,000 entities holding IP(4 and 6) prefixes and/or ASNs in the world > (same as number of ASs). What I have see is that most prefix holders > issue one roa with all the resources, but let's use 5 ROAs per > organization as average. Then we have: > > 40,000 certificates > 200,000 roas > 80,000 CRL,manifest > 40,000 ghostbuster (not very deployed but let's count it) > > Am I missing something besides the Router EE? Or is the Router EE= that > makes the difference? > > It seems that we agree that Ototal is the same equation, but the = values > for Cas, Eas, etc. are different. > > But, anyways. It's aprox 350K objects. If we want to load all in = 5 x2 - keyrollover -chris > minutes (it would be good to define what is acceptable) we need to > deliver objects in less 0.00085 secs. > > Regards, > as > > > > > On 15/11/2012 01:47, Eric Osterweil wrote: >> Hey everyone, >> >> A couple of us have done some quick back-of-the-envelope style calculati= ons to help get an idea of what a global deployment of RPKI (supporting a g= lobal BGPSEC deployment) might look like, if we were to be able to deploy i= t. We've written up our methodology, evaluation, and findings in a short l= ittle tech-note here: >> http://techreports.verisignlabs.com/tr-lookup.cgi?trid=3D1120005 >> >> What we tried to do was calculate an extreme _lower_bound_ on what the o= verall gather/fetch times might be for a cache trying to gather a fully dep= loyed RPKI repository. This seemed to be particularly opportune moment to = raise this topic, re: some comments recently posted in the thread, ``Re: [s= idr] additions and changes to agenda on Friday:'' >>> 1) size of a single repository (pick a large ISP as a for-instance, >>> some one like L3 who has ~30k customers, each with 5 routes average x2 >>> for keyroll situations? - or better yet, make up your own set of >>> numbers, document them and the reasoning why) >>> 2) number of repositories in existence (say, number of ASN in the >>> global table, or ...) >>> 3) re-fetch times of every repository (3 hrs for instance for any >>> object type?) >>> 4) average network latency from fetcher to fetchee (~150ms for instanc= e) >>> >>> document that and then start looking at tradeoffs and consequences? >> >> What we found is that by creating a _systematic_ estimate of what a glo= bal RPKI would look like, we wind up with roughly 1.5 million objects (we e= xplain why we feel this is a large _underestimate_ in the tech-note), and i= n order to ensure that all caches have received updated information (such a= s getting new certificates/CRLs/etc disseminated), repositories may have to= wait about a month (roughly 32 days by our estimates), just for gatherers = to reliably pick up a repo's changes. Or, a month before a key compromise = might get remediated throughout the RPKI system. >> >> Our sincere hope is that this tech note will be a living document. To t= hat end, comments, corrections, and feedback are very welcome. >> >> Eric >> _______________________________________________ >> 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 wesley.george@twcable.com Fri Nov 16 06:08:40 2012 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 AA86E21F8669 for ; Fri, 16 Nov 2012 06:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuEKSuiKED2N for ; Fri, 16 Nov 2012 06:08:40 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id EE09821F87A2 for ; Fri, 16 Nov 2012 06:08:39 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.83,264,1352091600"; d="scan'208";a="452864745" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 Nov 2012 09:08:36 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 16 Nov 2012 09:08:35 -0500 From: "George, Wes" To: Alexey Melnikov , Byron Ellacott Date: Fri, 16 Nov 2012 09:08:33 -0500 Thread-Topic: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting Thread-Index: Ac2+lgei4m7ybX43TImI9N7i2utwrgFbReAA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303373BDF57@PRVPEXVS15.corp.twcable.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6733D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F68471@Hermes.columbia.ads.sparta.com> <509D2C04.4020704@isode.com> In-Reply-To: <509D2C04.4020704@isode.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-chairs@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WG acceptance call for draft-ymbk-rpki-grandparenting 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 Nov 2012 14:08:40 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Alexey Melnikov > > > >> On Mon, Oct 15, 2012 at 1:36 AM, Byron Ellacott > wrote: > >>> Hi Chris, > >>> > >>> When did the WG reach consensus on adopting this draft? > >> when it spent ~50 mesasages discussing it? > >> it seems that, even if we abandon it in the end, discussing this over > >> a draft is a good thing to do. [WEG] Chris, I realize that every WG and WG Chair has a different interpret= ation of the discuss/adoption/refinement/WGLC lifecycle, but IMO, discussio= n !=3D "should adopt". There are plenty of drafts that get lots of discussi= on because lots of people say "stop, no, this is a bad idea" or there is co= ntroversy over a specific part of the draft along with some back-and-forth = with the authors as they defend or refine their idea. In some WGs (which sh= all remain nameless to protect the clueless), 50 messages can show up in *o= ne day* on a draft that is never going to be adopted. > Byron and others, > I think WG chairs (collectively) dropped the ball here: 3 of us have > discussed the acceptance call a couple of times. We would like to > apologize for sending inconsistent messages. > > After talking to various people this week, it looks like the best way > forward is for the chairs to redo the acceptance call and ask very > specific questions to keep everybody unconfused and hopefully happy. > I see two questions the WG needs to answer: 1) Is the problem described/solved by this draft actually a problem that we= need to address? 2) Does this need to be in a standalone draft, or can it be incorporated in= to another existing draft If #1 is yes, even if people don't agree with the solution proposed, that's= a decent starting point for refinement. As to the need to have refinement discussions over a document: I posed ques= tion #2 during the adoption call, and the reasoning for having it as a sepa= rate draft was never really discussed, so I think that's still outstanding.= Personally I think the answer to #1 is probably yes, so I'm not opposed to= the *content* and think it's worthwhile to refine it, but I'm not convince= d it needs to be separate. With apologies to Wheeler/Henney - all problems can be solved with another = IETF draft, except the problem of too many IETF drafts. 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 randy@psg.com Fri Nov 16 06:38:23 2012 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 D8F4E21F87A7 for ; Fri, 16 Nov 2012 06:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g88AIcZgurc3 for ; Fri, 16 Nov 2012 06:38:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5F16421F8791 for ; Fri, 16 Nov 2012 06:38:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TZN3h-000Obw-8y; Fri, 16 Nov 2012 14:38:18 +0000 Date: Fri, 16 Nov 2012 21:38:14 +0700 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 14:38:24 -0000 first, thanks for getting a larger model started. but i think many of the numbers are off. i have had no time this last week, and will not for another week. so i will pick on just three, as examples. for bgpsec, i would assume a million routers each having the current signing cert and the next one, i.e. two million total. scattered over O(100) repositories. the best handle we have on rcynic time today is the ripe repository, 4,400 objects in 47 seconds, i.e. about .01 secs/obj. and note that, thank you rsync, time is seriously sub-linear in object count. and a roa has it's ee cert built in for free. so there is a factor of two there. i have not had time to look further, but i think, when numbers are a factor of two to a factor of six off, and you are multiplying, a bit more rigor is appropriate. randy From tim@ripe.net Fri Nov 16 07:45:57 2012 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 0DCA121F8792 for ; Fri, 16 Nov 2012 07:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDAJ6AndYYlM for ; Fri, 16 Nov 2012 07:45:55 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 024DF21F8772 for ; Fri, 16 Nov 2012 07:45:54 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TZO74-0000RJ-RF for sidr@ietf.org; Fri, 16 Nov 2012 16:45:53 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TZO74-0003NG-OA for sidr@ietf.org; Fri, 16 Nov 2012 16:45:50 +0100 From: Tim Bruijnzeels Content-Type: multipart/alternative; boundary="Apple-Mail=_D50F5AF7-D24A-4E57-A82E-635DDC4828E9" Message-Id: <89C00A38-151D-4980-9951-DC3A33D565DC@ripe.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Fri, 16 Nov 2012 16:45:54 +0100 References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50A47152.6010903@gmail.com> To: "sidr@ietf.org" In-Reply-To: <50A47152.6010903@gmail.com> X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121116 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.0 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07192e6ff06c223f96a4c219de43808202fb Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 15:45:57 -0000 --Apple-Mail=_D50F5AF7-D24A-4E57-A82E-635DDC4828E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Some more comments on the numbers and formula.. On Nov 15, 2012, at 5:36 AM, Arturo Servin = wrote: > Erick >=20 > Very interesting research. But I am finding difficult to = understand how > you got 1.4 M objects. >=20 > Let me try to explain what I have seen in the young deployment = of RPKI. > For simplicity let's use the "hosted" model of RIRs. >=20 > Let's suppose, each RIR issues in average 1 certificate per = member > containing all the resources (v4,v6,ASNs). I would say that there are > 40,000 entities holding IP(4 and 6) prefixes and/or ASNs in the world > (same as number of ASs). What I have see is that most prefix holders > issue one roa with all the resources, but let's use 5 ROAs per > organization as average. Then we have: >=20 > 40,000 certificates > 200,000 roas > 80,000 CRL,manifest > 40,000 ghostbuster (not very deployed but let's count it) >=20 > Am I missing something besides the Router EE? Or is the Router = EE that > makes the difference? >=20 > It seems that we agree that Ototal is the same equation, but the = values > for Cas, Eas, etc. are different. I don't agree with the formula although my O total is closer.. The formula in the document confuses SIAs with the number of repository = (rsync) servers. Apart from any signed objects it may publish, every CA typically has: =3D 1 certificate published by its parent =3D 1 manifest =3D 1 CRL =3D 1 GB record (as Arturo said not widely deployed, but let's throw it = in for full deployment) So that's 4 objects. During a key roll the CA will have the following additional objects: =3D 1 cert published by the parent =3D 1 manifest =3D 1 CRL Making 7 objects. But typically not all CAs roll at the same time. The number of signed ROAs and Router certificates does, in my opinion, = not depend on the number of CAs, but: =3D ROA -> The number of announcements seen in BGP * some aggregation = factor (1 / # average prefixes on one ROA) =3D Router certs -> The number of ASNs * the number of keys for each ASN So I think a better model would be to say: number object #CA CA cert #CA MFT #CA CRL #CA GB #prefixes * X ROAs #ASNs * Y Router certs Ototal =3D 4 * #CA + #prefixes * X + #ASNs * Y As for the numbers.. this is a bit of a guessing game.. we just really = don't know at this time. We can take our best guess, but should keep in = mind that our best guess is probably off, and needs re-evaluation in = years to come. #CAs If this were the total number of current members for all RIRs this = number would be around 40k. However, there are also PI users that are = not direct members of the RIRs, and some members will delegate some of = their resources further. For reference I believe that in the RIPE region = we have around 25k PI prefixes. I expect that a lot of the organisations = that hold these resources will be happy to let a sponsoring RIR member = (LIR in our region) manage their ROAs. But not all.. So I think that in = a full deployment world this number may be significantly bigger. If = anyone has any ideas on this, please chime in=85 Going on nothing more = than gut feeling I would say the total could be in the order of:=20 =20 =3D 40k RIR members plus 40k self managing PI holders / children of = members? 80k.=20 #prefixes and 'X' The number of announced prefixes is still rising. Currently we are = nearing 500k. Worst case X is 1, meaning every ASN - prefix combination has its own = ROA. In reality this number will be lower because we can and do aggregate. = But not all implementers will do this. There is something to be said for = *not* fate-sharing ROAs for different prefixes from the same ASN. Also, = most our members are fairly small, and they do not do huge numbers of = announcements individually. Our current aggregation rate -- and we = really try... is: 792 ROAs / (2197 IPv4 + 468 IPv6 prefixes) =3D 0.3 ROA/prefix (see: http://certification-stats.ripe.net/)=20 For scalability assessment I am not sure though that a factor of = (1/0.3=3D) 3 between this level of aggregation, which seems best case, = and no aggregation, worst case, is that significant in the big picture. = I will use the mean of these two numbers below.. #ASNs * Y The number of current ASNs is approx. 40k. I have no good idea about how = many keys are needed at a single ASN. I know there was discussion about = a single key per router, and re-using the same key for different = routers. The suggested number 10 seems as good as any guess I could = make. If anyone has more clue here, again, chime in please.. > But, anyways. It's aprox 350K objects. Combining the above guesses I arrive at: O total =3D 4 * 80k + 500k * 0.65 + 40k * 10 =3D=3D> ~ 1M > If we want to load all in 5 > minutes (it would be good to define what is acceptable) we need to > deliver objects in less 0.00085 secs. In principal I like the approach to turn this around and define what an = acceptable average delivery rate would be given the total number of = objects and the maximum sync time. But on the other hand this can lead = to rejecting any infrastructure we could come up with.. just set the = goals high enough and nothing will be enough. So I think we should be = cautious here. If there are absolute objective minimal requirements it = would be good to know them. But other than that it may be best to be = pragmatic about it and turn this back.. try to think of other ways and = see if they actually perform significantly better.. Bearing with the document, if we take the current rsync repositories as = a starting point to see where we are heading without changes: =3D It should be noted that fetch times depend on lay-out, hierarchical = layout, allowing recursive, saves a lot of overhead (and latency) =3D We *do* recursive fetches on all current RIR repositories (yes, we = hacked in which base directory to use) =3D Testing on my laptop I typically see fetch times of around 20ms per = object, not 628ms A full fetch based on today's numbers would then take 1M * 20 ms =3D 20k = seconds =3D 330 minutes =3D 5.5 hours =3D 0.25 days. So this is quite a bit faster. Eric, Danny how did you get to the = numbers in table 3? Like I said: I just got some times from validation = runs done on my laptop. We do collect data from our validators 'in the = wild' though.. unfortunately the format of this data (we store a *lot*) = is such that it will take some time for me to dig out more = representative numbers. More time than I have now, but I will try=85. Another important factor is the amount of RPs that we can expect.. I = know that Rob and Randy et al are looking into ways to let RPs share = data and be less reliant on central repository servers. On the other = hand if all ASNs run at least 1 rpki validation cache that talks to the = repositories directly then we're looking at 40k clients. If they want = updates, say just 3 times per day, that's 120k requests per day, so = something like 1 - 1.5 per second. Our server scalability experiments that I talked about at the Vancouver = IETF suggest that we would have a hard time scaling rsyncd to these = numbers: = http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-inte= rim-2012-sidr-5-0.pdf =3D Slide #24. NOTE: This slide does not show the time it takes for a relying party to = download the repository. This slide shows the happy case where all RPs are up to date, and they = just check with the server to see if there are any updates. So = importantly this does not include long running data transfers.. This is = not server grade hardware (just a mac mini) but it's useful as an order = of magnitude indication imo. We see that the total number of RPs just = checking for updates that the server can handle / second depends = linearly on the repository size (it needs to do an O(n) scan). The total = number of concurrent RPs also depends on the repository size. It appears = that some list / index is kept in memory for every connection. Long = story short, we can only process small numbers of RPs per second and = it's quite trivial to end up with too many concurrent RPs pushing the = servers to the memory limited cliff for huge repositories. It's because of this that I keep going on about: =3D We should have a separate delta protocol and notification mechanism = and not rely on rsync for this =3D For scalability: =3D the hard work (CPU) should be done by the clients, not the = server =3D it should be possible to offload connections & memory away from = the server (proxies) =3D It makes sense to look at http and scalability of existing CDNs for = delivery My gut feeling (yes it's involved a lot today) tells me that this SHOULD = scale a lot better.. For example serving a small update notification = file over http using a CDN, 10ks of request / second, easy.. Data = transfer to RPs.. probably not a whole lot better actually if you need = it all -- though using existing CDNs with a global infrastructure closer = to RPs may help here. But if we have a notification file that points to = small deltas and fetching these small files is cheap this may actually = be a big improvement.. So although it may take a while to do the first = sync, *staying* in sync may actually perform a lot better. Well.. all = this is thought experiment at this stage. Without a pilot and actual = measurements it's hard to be sure. Regards Tim= --Apple-Mail=_D50F5AF7-D24A-4E57-A82E-635DDC4828E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 arturo.servin@gmail.com> = wrote:

Erick

Very interesting research. But I = am finding difficult to understand how
you got 1.4 M = objects.

= Let me try to explain what I have seen in the young deployment of = RPKI.
For simplicity let's use the "hosted" model of = RIRs.

= Let's suppose, each RIR issues in average 1 certificate per = member
containing all the resources (v4,v6,ASNs). I would say that = there are
40,000 entities holding IP(4 and 6) prefixes and/or ASNs in = the world
(same as number of ASs). What I have see is that most = prefix holders
issue one roa with all the resources, but let's use 5 = ROAs per
organization as average. Then we have:

40,000 = certificates
200,000 roas
80,000 CRL,manifest
40,000 = ghostbuster (not very deployed but let's count it)

Am I = missing something besides the Router EE? Or is the Router EE = that
makes the difference?

= It seems that we agree that Ototal is the same equation, but the = values
for Cas, Eas, etc. are = different.


I don't = agree with the formula although my O total is = closer..

The formula in the document confuses = SIAs with the number of repository (rsync) = servers.

Apart from any signed objects it may = publish, every CA typically has:
=3D 1 certificate published = by its parent
=3D 1 manifest
=3D 1 CRL
=3D = 1 GB record (as Arturo said not widely deployed, but let's throw it in = for full deployment)

So that's 4 = objects.

During a key roll the CA will have the = following additional objects:
=3D 1 cert published by the = parent
=3D 1 manifest
=3D 1 = CRL

Making 7 objects. But typically not all CAs = roll at the same time.

The number of signed = ROAs and Router certificates does, in my opinion, not depend on the = number of CAs, but:
=3D ROA -> The number of announcements = seen in BGP * some aggregation factor (1 / # average prefixes on one = ROA)
=3D Router certs -> The number of ASNs * the number of = keys for each ASN

So I think a better model = would be to say:

number       =     object
#CA           =       CA cert
#CA         =         MFT
#CA       =           CRL
#CA     =             = GB

#prefixes * X =  ROAs

#ASNs * Y      Router = certs

 Ototal  =3D 4 * #CA + = #prefixes * X + #ASNs * Y

As for the numbers.. = this is a bit of a guessing game.. we just really don't know at this = time. We can take our best guess, but should keep in mind that our best = guess is probably off, and needs re-evaluation in years to = come.

 #CAs

If = this were the total number of current members for all RIRs this number = would be around 40k. However, there are also PI users that are not = direct members of the RIRs, and some members will delegate some of their = resources further. For reference I believe that in the RIPE region we = have around 25k PI prefixes. I expect that a lot of the organisations = that hold these resources will be happy to let a sponsoring RIR member = (LIR in our region) manage their ROAs. But not all.. So I think that in = a full deployment world this number may be significantly bigger. If = anyone has any ideas on this, please chime in=85 Going on nothing more = than gut feeling I would say the total could be in the order = of: 
   
 =3D 40k RIR members = plus 40k self managing PI holders / children of = members?

  =  80k. 

#prefixes and = 'X'

The number of announced prefixes is still = rising. Currently we are nearing 500k.
Worst case X is 1, = meaning every ASN - prefix combination has its own = ROA.

In reality this number will be lower = because we can and do aggregate. But not all implementers will do this. = There is something to be said for *not* fate-sharing ROAs for different = prefixes from the same ASN. Also, most our members are fairly small, and = they do not do huge numbers of announcements individually. Our = current aggregation rate -- and we really try... = is:
  792 ROAs / (2197 IPv4 + 468 IPv6 = prefixes) =3D 0.3 ROA/prefix


For scalability assessment = I am not sure though that a factor of (1/0.3=3D) 3 between this level of = aggregation, which seems best case, and no aggregation, worst case, is = that significant in the big picture. I will use the mean of these two = numbers below..


#ASNs * = Y

The number of current ASNs is approx. = 40k. I have no good idea about how many keys are needed at a single ASN. = I know there was discussion about a single key per router, and re-using = the same key for different routers. The suggested number 10 seems as = good as any guess I could make. If anyone has more clue here, again, = chime in please..

But, = anyways. It's aprox 350K = objects.

Combining the above = guesses I arrive at:

 O total =3D 4 * 80k = + 500k * 0.65 + 40k * 10    =3D=3D> ~ = 1M

If we want to = load all in 5
minutes (it would be good to define what is acceptable) = we need to
deliver objects in less 0.00085 = secs.

In principal I like the = approach to turn this around and define what an acceptable average = delivery rate would be given the total number of objects and the maximum = sync time. But on the other hand this can lead to rejecting any = infrastructure we could come up with.. just set the goals high enough = and nothing will be enough. So I think we should be cautious here. If = there are absolute objective minimal requirements it would be good to = know them. But other than that it may be best to be pragmatic about it = and turn this back.. try to think of other ways and see if they actually = perform significantly better..

Bearing with the = document, if we take the current rsync repositories as a starting point = to see where we are heading without changes:
=3D It should be = noted that fetch times depend on lay-out, hierarchical layout, allowing = recursive, saves a lot of overhead (and latency)
=3D We *do* = recursive fetches on all current RIR repositories (yes, we hacked in = which base directory to use)
=3D Testing on my laptop I = typically see fetch times of around 20ms per object, not = 628ms

A full fetch based on today's numbers = would then take 1M * 20 ms =3D 20k seconds =3D 330 minutes =3D 5.5 hours = =3D 0.25 days.

So this is quite a bit faster. = Eric, Danny how did you get to the numbers in table 3? Like I said: I = just got some times from validation runs done on my laptop. We do = collect data from our validators 'in the wild' though.. unfortunately = the format of this data (we store a *lot*) is such that it will take = some time for me to dig out more representative numbers. More time than = I have now, but I will = try=85.


Another important factor = is the amount of RPs that we can expect.. I know that Rob and Randy et = al are looking into ways to let RPs share data and be less reliant on = central repository servers. On the other hand if all ASNs run at least 1 = rpki validation cache that talks to the repositories directly then we're = looking at 40k clients. If they want updates, say just 3 times per day, = that's 120k requests per day, so something like 1 - 1.5 per = second.

Our server scalability experiments that = I talked about at the Vancouver IETF suggest that we would have a hard = time scaling rsyncd to these numbers:

=3D Slide #24.

NOTE: This slide does = not show the time it takes for a relying party to download the = repository.

This slide shows the happy case = where all RPs are up to date, and they just check with the server to see = if there are any updates. So importantly this does not include long = running data transfers.. This is not server grade hardware (just a mac = mini) but it's useful as an order of magnitude indication imo. We see = that the total number of RPs just checking for updates that the server = can handle / second depends linearly on the repository size (it needs to = do an O(n) scan). The total number of concurrent RPs also depends on the = repository size. It appears that some list / index is kept in memory for = every connection. Long story short, we can only process small numbers of = RPs per second and it's quite trivial to end up with too many concurrent = RPs pushing the servers to the memory limited cliff for huge = repositories.

It's because of this that I keep = going on about:
=3D We should have a separate delta protocol = and notification mechanism and not rely on rsync for this
=3D = For scalability:
     =3D the hard work (CPU) = should be done by the clients, not the server
    =  =3D it should be possible to offload connections & memory away = from the server (proxies)
=3D It makes sense to look at http = and scalability of existing CDNs for = delivery

My gut feeling (yes it's involved a = lot today) tells me that this SHOULD scale a lot better.. For = example serving a small update notification file over http using a CDN, = 10ks of request / second, easy.. Data transfer to RPs.. probably not a = whole lot better actually if you need it all -- though using existing = CDNs with a global infrastructure closer to RPs may help here. But if we = have a notification file that points to small deltas and fetching these = small files is cheap this may actually be a big improvement.. So = although it may take a while to do the first sync, *staying* in sync may = actually perform a lot better. Well.. all this is thought experiment at = this stage. Without a pilot and actual measurements it's hard to be = sure.



Regards
=

Tim
= --Apple-Mail=_D50F5AF7-D24A-4E57-A82E-635DDC4828E9-- From arturo.servin@gmail.com Fri Nov 16 09:34:20 2012 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 F22B221F8897 for ; Fri, 16 Nov 2012 09:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iFYfvAerIrD for ; Fri, 16 Nov 2012 09:34:18 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBFA21F8872 for ; Fri, 16 Nov 2012 09:34:18 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id m14so112273yen.31 for ; Fri, 16 Nov 2012 09:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xEQZFDY0EFmSCZCDeEbgwZI3iEHz8A3E+vY3YZigedA=; b=h5bSWwLcVqXxFn/RoXlYhKmIYIKen3boBTH7h2hi8QbKQuWFaBoz0uLpdPJU6kqDNT q0gvIp1WkeFEOl6UkTlVqS1d0bd59oVIhD6zCTfEdLvLrKmnPMhM1E5VKF7KrwZdnRRs g3zgrPjW5qL2C11j3EltveT9bV9KFOC8U6h4pm7dlV0zXScxCqJBuUcbHMjCmFChdHDd WW9MmhzaCWB/Ich3B04yfgLfvjZJhKZLDnyyT2Ot4GJiUBMy7rEJdAVxPPQXu7aZKQ9T myent9wWEodj3Bau3vuuBlAXrdco05jdi+Ma6w9rvautzjxK4oflXpQFIpGpMw0+Lv9r ccIw== Received: by 10.236.54.138 with SMTP id i10mr5067363yhc.23.1353087257822; Fri, 16 Nov 2012 09:34:17 -0800 (PST) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:2d91:7f1d:1058:39ea]) by mx.google.com with ESMTPS id h16sm1858821ani.0.2012.11.16.09.34.14 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 09:34:16 -0800 (PST) Message-ID: <50A67913.9000603@gmail.com> Date: Fri, 16 Nov 2012 15:34:11 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tim Bruijnzeels References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50A47152.6010903@gmail.com> <89C00A38-151D-4980-9951-DC3A33D565DC@ripe.net> In-Reply-To: <89C00A38-151D-4980-9951-DC3A33D565DC@ripe.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 17:34:20 -0000 A small comment about yours and Erick/Danny's number. Are you supposing #roas = #routes ? These is because you are assuming the worst scenario? Because in reality I have seen that operators are using a single ROA for multiple prefixes. Regards, as On 16/11/2012 13:45, Tim Bruijnzeels wrote: > Hi, > > Some more comments on the numbers and formula.. > > On Nov 15, 2012, at 5:36 AM, Arturo Servin > wrote: > >> Erick >> >> Very interesting research. But I am finding difficult to understand how >> you got 1.4 M objects. >> >> Let me try to explain what I have seen in the young deployment of RPKI. >> For simplicity let's use the "hosted" model of RIRs. >> >> Let's suppose, each RIR issues in average 1 certificate per member >> containing all the resources (v4,v6,ASNs). I would say that there are >> 40,000 entities holding IP(4 and 6) prefixes and/or ASNs in the world >> (same as number of ASs). What I have see is that most prefix holders >> issue one roa with all the resources, but let's use 5 ROAs per >> organization as average. Then we have: >> >> 40,000 certificates >> 200,000 roas >> 80,000 CRL,manifest >> 40,000 ghostbuster (not very deployed but let's count it) >> >> Am I missing something besides the Router EE? Or is the Router EE that >> makes the difference? >> >> It seems that we agree that Ototal is the same equation, but the values >> for Cas, Eas, etc. are different. > > > I don't agree with the formula although my O total is closer.. > > The formula in the document confuses SIAs with the number of repository > (rsync) servers. > > Apart from any signed objects it may publish, every CA typically has: > = 1 certificate published by its parent > = 1 manifest > = 1 CRL > = 1 GB record (as Arturo said not widely deployed, but let's throw it in > for full deployment) > > So that's 4 objects. > > During a key roll the CA will have the following additional objects: > = 1 cert published by the parent > = 1 manifest > = 1 CRL > > Making 7 objects. But typically not all CAs roll at the same time. > > The number of signed ROAs and Router certificates does, in my opinion, > not depend on the number of CAs, but: > = ROA -> The number of announcements seen in BGP * some aggregation > factor (1 / # average prefixes on one ROA) > = Router certs -> The number of ASNs * the number of keys for each ASN > > So I think a better model would be to say: > > number object > #CA CA cert > #CA MFT > #CA CRL > #CA GB > > #prefixes * X ROAs > > #ASNs * Y Router certs > > Ototal = 4 * #CA + #prefixes * X + #ASNs * Y > > As for the numbers.. this is a bit of a guessing game.. we just really > don't know at this time. We can take our best guess, but should keep in > mind that our best guess is probably off, and needs re-evaluation in > years to come. > > #CAs > > If this were the total number of current members for all RIRs this > number would be around 40k. However, there are also PI users that are > not direct members of the RIRs, and some members will delegate some of > their resources further. For reference I believe that in the RIPE region > we have around 25k PI prefixes. I expect that a lot of the organisations > that hold these resources will be happy to let a sponsoring RIR member > (LIR in our region) manage their ROAs. But not all.. So I think that in > a full deployment world this number may be significantly bigger. If > anyone has any ideas on this, please chime in… Going on nothing more > than gut feeling I would say the total could be in the order of: > > = 40k RIR members plus 40k self managing PI holders / children of members? > > 80k. > > #prefixes and 'X' > > The number of announced prefixes is still rising. Currently we are > nearing 500k. > Worst case X is 1, meaning every ASN - prefix combination has its own ROA. > > In reality this number will be lower because we can and do aggregate. > But not all implementers will do this. There is something to be said for > *not* fate-sharing ROAs for different prefixes from the same ASN. Also, > most our members are fairly small, and they do not do huge numbers of > announcements individually. Our current aggregation rate -- and we > really try... is: > 792 ROAs / (2197 IPv4 + 468 IPv6 prefixes) = 0.3 ROA/prefix > > (see: http://certification-stats.ripe.net/) > > For scalability assessment I am not sure though that a factor of > (1/0.3=) 3 between this level of aggregation, which seems best case, and > no aggregation, worst case, is that significant in the big picture. I > will use the mean of these two numbers below.. > > > #ASNs * Y > > The number of current ASNs is approx. 40k. I have no good idea about how > many keys are needed at a single ASN. I know there was discussion about > a single key per router, and re-using the same key for different > routers. The suggested number 10 seems as good as any guess I could > make. If anyone has more clue here, again, chime in please.. > >> But, anyways. It's aprox 350K objects. > > Combining the above guesses I arrive at: > > O total = 4 * 80k + 500k * 0.65 + 40k * 10 ==> ~ 1M > >> If we want to load all in 5 >> minutes (it would be good to define what is acceptable) we need to >> deliver objects in less 0.00085 secs. > > In principal I like the approach to turn this around and define what an > acceptable average delivery rate would be given the total number of > objects and the maximum sync time. But on the other hand this can lead > to rejecting any infrastructure we could come up with.. just set the > goals high enough and nothing will be enough. So I think we should be > cautious here. If there are absolute objective minimal requirements it > would be good to know them. But other than that it may be best to be > pragmatic about it and turn this back.. try to think of other ways and > see if they actually perform significantly better.. > > Bearing with the document, if we take the current rsync repositories as > a starting point to see where we are heading without changes: > = It should be noted that fetch times depend on lay-out, hierarchical > layout, allowing recursive, saves a lot of overhead (and latency) > = We *do* recursive fetches on all current RIR repositories (yes, we > hacked in which base directory to use) > = Testing on my laptop I typically see fetch times of around 20ms per > object, not 628ms > > A full fetch based on today's numbers would then take 1M * 20 ms = 20k > seconds = 330 minutes = 5.5 hours = 0.25 days. > > So this is quite a bit faster. Eric, Danny how did you get to the > numbers in table 3? Like I said: I just got some times from validation > runs done on my laptop. We do collect data from our validators 'in the > wild' though.. unfortunately the format of this data (we store a *lot*) > is such that it will take some time for me to dig out more > representative numbers. More time than I have now, but I will try…. > > > Another important factor is the amount of RPs that we can expect.. I > know that Rob and Randy et al are looking into ways to let RPs share > data and be less reliant on central repository servers. On the other > hand if all ASNs run at least 1 rpki validation cache that talks to the > repositories directly then we're looking at 40k clients. If they want > updates, say just 3 times per day, that's 120k requests per day, so > something like 1 - 1.5 per second. > > Our server scalability experiments that I talked about at the Vancouver > IETF suggest that we would have a hard time scaling rsyncd to these numbers: > http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-interim-2012-sidr-5-0.pdf > > = Slide #24. > > NOTE: This slide does not show the time it takes for a relying party to > download the repository. > > This slide shows the happy case where all RPs are up to date, and they > just check with the server to see if there are any updates. So > importantly this does not include long running data transfers.. This is > not server grade hardware (just a mac mini) but it's useful as an order > of magnitude indication imo. We see that the total number of RPs just > checking for updates that the server can handle / second depends > linearly on the repository size (it needs to do an O(n) scan). The total > number of concurrent RPs also depends on the repository size. It appears > that some list / index is kept in memory for every connection. Long > story short, we can only process small numbers of RPs per second and > it's quite trivial to end up with too many concurrent RPs pushing the > servers to the memory limited cliff for huge repositories. > > It's because of this that I keep going on about: > = We should have a separate delta protocol and notification mechanism > and not rely on rsync for this > = For scalability: > = the hard work (CPU) should be done by the clients, not the server > = it should be possible to offload connections & memory away from > the server (proxies) > = It makes sense to look at http and scalability of existing CDNs for > delivery > > My gut feeling (yes it's involved a lot today) tells me that this SHOULD > scale a lot better.. For example serving a small update notification > file over http using a CDN, 10ks of request / second, easy.. Data > transfer to RPs.. probably not a whole lot better actually if you need > it all -- though using existing CDNs with a global infrastructure closer > to RPs may help here. But if we have a notification file that points to > small deltas and fetching these small files is cheap this may actually > be a big improvement.. So although it may take a while to do the first > sync, *staying* in sync may actually perform a lot better. Well.. all > this is thought experiment at this stage. Without a pilot and actual > measurements it's hard to be sure. > > > > Regards > > Tim > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From eosterweil@verisign.com Fri Nov 16 13:44:10 2012 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 C4DF921F8B05 for ; Fri, 16 Nov 2012 13:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtiuAAg4iRue for ; Fri, 16 Nov 2012 13:44:10 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 431FD21F8AF7 for ; Fri, 16 Nov 2012 13:44:09 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUKazqNCzlAevf3FlMb2v7Wih7HuvEGjz@postini.com; Fri, 16 Nov 2012 13:44:09 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qAGLi54r018918; Fri, 16 Nov 2012 16:44:05 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.43]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Nov 2012 16:44:04 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Eric Osterweil In-Reply-To: <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.com> Date: Fri, 16 Nov 2012 16:44:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.com> To: Bryan Weber X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 16 Nov 2012 21:44:04.0767 (UTC) FILETIME=[7FAF72F0:01CDC443] Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 21:44:10 -0000 Hey Bryan, Thanks a lot for the comments! My thoughts are inline: On Nov 14, 2012, at 11:29 PM, Bryan Weber wrote: > I have quite a few questions/statements about this document. If you = feel that this list is not the appropriate place to answer them please = respond to me at bryan@cobenian.com. Thanks. >=20 > *) Aren't the EE certs contained in the Certificate, Manifest and ROA = artifacts? Should they be counted as separate items to retrieve? afaik, EE certs are not contained in manifests. Manifests enumerate = things like EE certs, but they are separate objects (with a different = cardinality). I do believe that the cardinality of EE certs is 1:1 with = ROAs. Though, they are still separately managed objects and have = different management overheads (like managing crypto information when = reissuing, etc). >=20 > *) I'm not sure about the status of ghostbuster records today. Has any = RIR implemented or deployed them yet? To my knowledge an RPKI repository = contains CA certs with RFC 3779 extensions, manifests, CRLs and ROAs. = Admittedly I am not familiar with the implementations of all of the = RIRs. Well, I think by the same token, not all ASes have deployed SIA = repositories, or issued ROAs yet. The goal of the document is to = represent a global RPKI as prescribed. In the future, if an AS is to = run its own SIA (which I believe is envisioned to be far and away be the = common case), I believe it _must_ have a ghostbuster record so that RPs = can tell whose Cert they are dealing with. There's no other way to = (say) find the administrative contact for a routing object. >=20 > *) Is there any reason that ARIN's pilot is listed? The service is = deprecated and the production system is live at this point. Granted it = probably does not have a large volume of data yet. We only listed the repositories in the the cited presentation, but we = felt it was important to include them all for completeness and to avoid = bias. We were trying to be unbiased and use the numbers and = measurements that the BGPSEC design team has been publicizing. I don't = know what their metric was for including those measurements, but I = suspect others in the wg could explain better. >=20 > *) You note that=20 >=20 > "In addition, in regards to multihoming, we need one ROA and one EE = certi=EF=AC=81cate for each feasible origin for > a pre=EF=AC=81x, yet we will only see on entry in a RIB." >=20 > but on the other hand because of the maximum length in a ROA I believe = that it is very difficult to surmise a relationship between the number = of ROAs and the number of entries in the RIB. It is, admittedly, a rough estimate, and we are totally open to other = systematic measures. However, to illustrate why it is tough to find a = good estimate, while some aspects of using the RIB cause this number to = seem large (as you have stated), consider also that the = allocation/suballocation/subsuballocation hierarchy requires resource = holders to issue a chain of certificates (from holder to holder to = holder). =46rom there, a single entry in the RIB could correspond to = multiple allocation objects. This would inflate the number of objects, = but we didn't see an obvious/clean way to estimate this either. As = such, we definitely acknowledge that this is an imperfect estimator, but = we felt it was likely a good ballpark. Make sense? >=20 > *) Just as a side note, combining tables 1 and 2 might make the data = easier to read. In separate tables I am forced to keep find the = correlated rows. Gotcha, thanks. >=20 > *) Just for my own education, what are the router EE certs? In BGPSEC, each router must be able to sign each update it transmits = (originates and forwards). The design team seems to have recently = acknowledged that pushing a single organizational signing cert's private = key to all routers in (say) a multinational AS could be a security = concern. As such, each CA can/should have separate EE certs issued for = routers, such that these certs have their authority delegated from an = organizational CA cert. >=20 > *) Another question: should the set of interconnected repositories be = considered a directed graph or a tree hierarchy? Since the certs are = hierarchical shouldn't the URIs pointing to external repositories be = hierarchical as well? Well, can you be sure that there will be no cycles in this envisioned = set? I, for example, cannot be sure that an object in one repo does not = point to an external repo that in turn has an object that does not point = back to the original. In fact, this issue is mentioned in the RPKI arch = RFC (6480) as a possibility. Nothing ever goes to plan in the Internet, = so I think it is a very realistic concern. >=20 > *) Does cache synching have to be done serially? I believe the time estimates in the presentation that we cited are = actual downloads, so I believe this is using whatever the current best = practices are, though I admit the details were not 100% clear to me. >=20 > If these estimates are accurate then the I think the current expiry = periods of manifests in some of the RIRs would be considered woefully = inadequate.=20 Agreed. :( Eric= From eosterweil@verisign.com Fri Nov 16 13:44:27 2012 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 D2DE221F8AF7 for ; Fri, 16 Nov 2012 13:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v2ZkTQre80Q for ; Fri, 16 Nov 2012 13:44:27 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id CB92621F8B0F for ; Fri, 16 Nov 2012 13:44:26 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUKazuMnwe15CJ7twXt9VPtxB4hZVT5Cc@postini.com; Fri, 16 Nov 2012 13:44:26 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qAGLiN4H018962; Fri, 16 Nov 2012 16:44:23 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.43]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Nov 2012 16:44:23 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50A47152.6010903@gmail.com> Date: Fri, 16 Nov 2012 16:44:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50A47152.6010903@gmail.com> To: Arturo Servin X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 16 Nov 2012 21:44:23.0283 (UTC) FILETIME=[8AB8C430:01CDC443] Cc: sidr@ietf.org Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 21:44:27 -0000 Hey AS, We are very open to feedback, but the numbers below seem to be derived = somewhat more qualitatively than the estimations we used. Would it be = possible to frame the questions in terms of the numbers we estimated? = Clearly we acknowledge that anyone is 100% encouraged to agree with us, = disagree with us, or create their own estimates, but I think the numbers = below miss some the important aspects that we included in our = evaluation. If, perhaps, you think some of the justification is wrong = in the tech-note, I'd be much obliged if you would point it out. We = tried very hard not to ballpark too many numbers, and use actual = deployment statistics, as opposed to qualitatively evaluating. We = worried that being too qualitative may open up the possibility of = measurement biases. Would you mind taking a look at the reported = methodology and estimates? On Nov 14, 2012, at 11:36 PM, Arturo Servin wrote: > Erick >=20 > Very interesting research. But I am finding difficult to = understand how > you got 1.4 M objects. >=20 > Let me try to explain what I have seen in the young deployment = of RPKI. > For simplicity let's use the "hosted" model of RIRs. >=20 > Let's suppose, each RIR issues in average 1 certificate per = member > containing all the resources (v4,v6,ASNs). I would say that there are > 40,000 entities holding IP(4 and 6) prefixes and/or ASNs in the world > (same as number of ASs). And if an entity is a member of multiple RIRs? I think that would = inflate the above, but perhaps just claiming there are #AS Autonomous = Somethings lets us use the CIDR report's 42,000. ;) > What I have see is that most prefix holders > issue one roa with all the resources, but let's use 5 ROAs per > organization as average. See, I don't understand this generalization. You can't have one ROA for = non-overlapping allocations, so we already know the above is not a good = mapping. I don't know why we would guess 5. That's why we chose a = systematic estimator. I'd be happy to look at others, but this seems a = little too qualitative for this type of estimation (imho). Also, = there's no discussion of router EE certs below (except acknowledgement = of their omission) =46rom here, I think the numbers are based on a = foundation I have trouble following, so I think it might be easier to = frame this discussion on replacing/addressing the estimates we were = using? Thanks, Eric > Then we have: >=20 > 40,000 certificates > 200,000 roas > 80,000 CRL,manifest > 40,000 ghostbuster (not very deployed but let's count it) >=20 > Am I missing something besides the Router EE? Or is the Router = EE that > makes the difference? >=20 > It seems that we agree that Ototal is the same equation, but the = values > for Cas, Eas, etc. are different. > =09 > But, anyways. It's aprox 350K objects. If we want to load all in = 5 > minutes (it would be good to define what is acceptable) we need to > deliver objects in less 0.00085 secs. > =09 > Regards, > as >=20 > =09 > =09 >=20 > On 15/11/2012 01:47, Eric Osterweil wrote: >> Hey everyone, >>=20 >> A couple of us have done some quick back-of-the-envelope style = calculations to help get an idea of what a global deployment of RPKI = (supporting a global BGPSEC deployment) might look like, if we were to = be able to deploy it. We've written up our methodology, evaluation, and = findings in a short little tech-note here: >> http://techreports.verisignlabs.com/tr-lookup.cgi?trid=3D1120005 >>=20 >> What we tried to do was calculate an extreme _lower_bound_ on what = the overall gather/fetch times might be for a cache trying to gather a = fully deployed RPKI repository. This seemed to be particularly = opportune moment to raise this topic, re: some comments recently posted = in the thread, ``Re: [sidr] additions and changes to agenda on Friday:'' >>> 1) size of a single repository (pick a large ISP as a for-instance, >>> some one like L3 who has ~30k customers, each with 5 routes average = x2 >>> for keyroll situations? - or better yet, make up your own set of >>> numbers, document them and the reasoning why) >>> 2) number of repositories in existence (say, number of ASN in the >>> global table, or ...) >>> 3) re-fetch times of every repository (3 hrs for instance for any >>> object type?) >>> 4) average network latency from fetcher to fetchee (~150ms for = instance) >>>=20 >>> document that and then start looking at tradeoffs and consequences? >>=20 >> What we found is that by creating a _systematic_ estimate of what a = global RPKI would look like, we wind up with roughly 1.5 million objects = (we explain why we feel this is a large _underestimate_ in the = tech-note), and in order to ensure that all caches have received updated = information (such as getting new certificates/CRLs/etc disseminated), = repositories may have to wait about a month (roughly 32 days by our = estimates), just for gatherers to reliably pick up a repo's changes. = Or, a month before a key compromise might get remediated throughout the = RPKI system. >>=20 >> Our sincere hope is that this tech note will be a living document. = To that end, comments, corrections, and feedback are very welcome. >>=20 >> Eric >> _______________________________________________ >> 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 From eosterweil@verisign.com Fri Nov 16 13:44:44 2012 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 831CC21F8AF7 for ; Fri, 16 Nov 2012 13:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.687 X-Spam-Level: X-Spam-Status: No, score=-4.687 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CGLb-CIUyIW for ; Fri, 16 Nov 2012 13:44:43 -0800 (PST) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id BEFF621F8B05 for ; Fri, 16 Nov 2012 13:44:42 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUKazyD3yNOyLI7m0+I87WgG2VTN0jYXR@postini.com; Fri, 16 Nov 2012 13:44:42 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qAGLieDW032343; Fri, 16 Nov 2012 16:44:40 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.43]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Nov 2012 16:44:38 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Eric Osterweil In-Reply-To: <89C00A38-151D-4980-9951-DC3A33D565DC@ripe.net> Date: Fri, 16 Nov 2012 16:44:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50A47152.6010903@gmail.com> <89C00A38-151D-4980-9951-DC3A33D565DC@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 16 Nov 2012 21:44:38.0300 (UTC) FILETIME=[93AC2DC0:01CDC443] Cc: "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 21:44:44 -0000 On Nov 16, 2012, at 10:45 AM, Tim Bruijnzeels wrote: > Hi, >=20 > Some more comments on the numbers and formula.. >=20 > On Nov 15, 2012, at 5:36 AM, Arturo Servin = wrote: >=20 > Apart from any signed objects it may publish, every CA typically has: > =3D 1 certificate published by its parent But, as I asked Arturo, would we expect to have a CA from each parent = (i.e. each RIR that an org may allocations from)? While this may often = still just be 1, it seems important to note, no? THat was one reason we = had for breaking it apart. I'm more than willing to believe that I'm = wrong here, but I'd like to understand how.=20 > =3D 1 manifest > =3D 1 CRL > =3D 1 GB record (as Arturo said not widely deployed, but let's throw = it in for full deployment) How does the RPKI certify ASN allocations? This is needed to certify = router EE certs (they are tied to an ASN, no?). Such an AS cert would = add another 1 to the above and make it 5, right? Otherwise, how does a = forward signing peer associate itself with the ASN, instead of some = prefix? The ASN isn't necessarily allocated by the same RIR as any of = the allocations, so IP allocation and ASN allocation are orthogonal, no? >=20 > So that's 4 objects. >=20 > During a key roll the CA will have the following additional objects: > =3D 1 cert published by the parent > =3D 1 manifest > =3D 1 CRL >=20 > Making 7 objects. But typically not all CAs roll at the same time. Unless it is an algorithm rollover, and that is expected to last for = years (iirc). Then this set would be doubled (plus double the numbers = below), right? >=20 > The number of signed ROAs and Router certificates does, And EE certs. While 1:1 with ROAs, they require additional (very = different) processing, esp if you start down the road of HSMs. So, we = claimed this additional operational requirement means that even if you = double up on the downloads, those are still two separate objects. You = have to manage EE rollover keeping crypto material the same or changing = it, depending on details of the ROA, etc. That won't come for free, and = (again) needing HSMs makes this a big deal. So, we really felt it was = important to call this complexity out by counting each.=20 > in my opinion, not depend on the number of CAs, but: > =3D ROA -> The number of announcements seen in BGP * some aggregation = factor (1 / # average prefixes on one ROA) I, pretty much agree with this (as I think the tech-note said). I do, = however have to note that with MOAS, you need multiple ROAs. Small = point, but worth stating. :) > =3D Router certs -> The number of ASNs * the number of keys for each = ASN \times The number of eBGP speakers you mean, right? >=20 > So I think a better model would be to say: >=20 > number object > #CA CA cert > #CA MFT > #CA CRL > #CA GB Ack, we just estimated this as the # of SIAs, and then varied it from 5 = to 42,000. >=20 > #prefixes * X ROAs Yeah, but we didn't guestimate the $X$ value. It sounds like we should, = but is there any data we can use to do so? >=20 > #ASNs * Y Router certs >=20 > Ototal =3D 4 * #CA + #prefixes * X + #ASNs * Y Re: the above, I think this would be=20 O^Total =3D 4 * #CA + #ASNs + #prefixes + X * #prefixes + Y * #ASNs We had called out the need for AS EE cert (which was not in the equation = you outlined), and we felt it was important to not omit EE certs (if for = no other reason than the operational complexity they bring). >=20 > As for the numbers.. this is a bit of a guessing game.. we just really = don't know at this time. We can take our best guess, but should keep in = mind that our best guess is probably off, and needs re-evaluation in = years to come. 100% agree. That is why we called this a back-of-the-envelope = calculation and are totally seeking feedback, and are absolutely = interested in pushing revisions as things evolve. >=20 > #CAs >=20 > If this were the total number of current members for all RIRs this = number would be around 40k. However, there are also PI users that are = not direct members of the RIRs, and some members will delegate some of = their resources further. For reference I believe that in the RIPE region = we have around 25k PI prefixes. I expect that a lot of the organisations = that hold these resources will be happy to let a sponsoring RIR member = (LIR in our region) manage their ROAs. But not all.. So I think that in = a full deployment world this number may be significantly bigger. If = anyone has any ideas on this, please chime in=85 Going on nothing more = than gut feeling I would say the total could be in the order of:=20 > =20 > =3D 40k RIR members plus 40k self managing PI holders / children of = members? >=20 > 80k.=20 Really? I had been thinking that this number was tied to the origins, = but I can see your logic. It would great to try and find a way to = estimate this, so I'd like to echo your request for anyone with info to = chime in. >=20 > #prefixes and 'X' >=20 > The number of announced prefixes is still rising. Currently we are = nearing 500k. > Worst case X is 1, meaning every ASN - prefix combination has its own = ROA. >=20 > In reality this number will be lower because we can and do aggregate. = But not all implementers will do this. There is something to be said for = *not* fate-sharing ROAs for different prefixes from the same ASN. Also, = most our members are fairly small, and they do not do huge numbers of = announcements individually. Our current aggregation rate -- and we = really try... is: > 792 ROAs / (2197 IPv4 + 468 IPv6 prefixes) =3D 0.3 ROA/prefix >=20 > (see: http://certification-stats.ripe.net/)=20 >=20 > For scalability assessment I am not sure though that a factor of = (1/0.3=3D) 3 between this level of aggregation, which seems best case, = and no aggregation, worst case, is that significant in the big picture. = I will use the mean of these two numbers below.. Fair enough. I can certainly see the logic here, but if we wound up = with a good way to do the estimation that would be even better, no? :) > In principal I like the approach to turn this around and define what = an acceptable average delivery rate would be given the total number of = objects and the maximum sync time. But on the other hand this can lead = to rejecting any infrastructure we could come up with.. just set the = goals high enough and nothing will be enough. So I think we should be = cautious here. If there are absolute objective minimal requirements it = would be good to know them. But other than that it may be best to be = pragmatic about it and turn this back.. try to think of other ways and = see if they actually perform significantly better.. I can respect this concern, but we really do have to deal with any = systemic/complexity/operational/etc. facets of the system that we have = designed. We need to know how this design is going to behave if we are = going to enshrine it. For example, the above calculations, and ours, = and any derivative formulation would make revoking a key within an hour = seem to be impossible. Is it a day, a week, a month, etc? That may = still be unclear (depending on how we model this), but how can we go any = farther forward without taking a careful look at this design? We must = know if it meets our requirements, and I think measurements like these = help tell us how feasible this will all be. > Bearing with the document, if we take the current rsync repositories = as a starting point to see where we are heading without changes: > =3D It should be noted that fetch times depend on lay-out, = hierarchical layout, allowing recursive, saves a lot of overhead (and = latency) > =3D We *do* recursive fetches on all current RIR repositories (yes, we = hacked in which base directory to use) > =3D Testing on my laptop I typically see fetch times of around 20ms = per object, not 628ms To be perfectly fair, I just used the #s I found form the BGPSEC design = team's measurements. I was very hesitant to use any particular set of = numbers here. As I'm sure you know, there are opinions about rsync, = what it looks like under load, with asynchrony, repos' operational = uptimes, restarting because of changes in the repository (I think that = was something from your preso), etc. I think you likely know (much = better than me) that if a repo is under heavy load, churn, or just = having an outage, that can cause cache's sync time to suffer. Hence, I = really liked getting real operational data from non-lab measurements. I = actually really feel that data is quite useful. Consider this, you all = (who are running these things) are the experts. If we wind up w/ = ~42,000 repos, they will _not_ all be run as well as you run them. >=20 > A full fetch based on today's numbers would then take 1M * 20 ms =3D = 20k seconds =3D 330 minutes =3D 5.5 hours =3D 0.25 days. Sorry, but I really think this has some problems. First, the numbers I = see in the cited preso are way larger than this, and just for the object = sets we see today. So, I have to say that this calculation doesn't seem = to jive with Randy's numbers. >=20 > So this is quite a bit faster. Eric, Danny how did you get to the = numbers in table 3? Like I said: I just got some times from validation = runs done on my laptop. We do collect data from our validators 'in the = wild' though.. unfortunately the format of this data (we store a *lot*) = is such that it will take some time for me to dig out more = representative numbers. More time than I have now, but I will try=85. The citation at the end of the document comes from Randy. It shows = (MRT?) graphs with these numbers on them. This doesn't include issues = like repos under load from 42,000 caches DNS, outages, etc. I think the = numbers taken from his preso are very charitable, and they are actual = measurements. Moreover, his own experiments showed that replicating = this all inside a ``fairly large scale'' experiment took 660 minutes by = itself... and that was with just 14,000 objects. This actually totally = contradicts the numbers you calculated above. Sorry, I think it just = doesn't add up. > Another important factor is the amount of RPs that we can expect.. I = know that Rob and Randy et al are looking into ways to let RPs share = data and be less reliant on central repository servers. On the other = hand if all ASNs run at least 1 rpki validation cache that talks to the = repositories directly then we're looking at 40k clients. If they want = updates, say just 3 times per day, that's 120k requests per day, so = something like 1 - 1.5 per second. Again, I used Randy's numbers and even his experiments on 14k objects on = a small topology show it takes twice as long as your global estimates. > This slide shows the happy case where all RPs are up to date, and they = just check with the server to see if there are any updates. So = importantly this does not include long running data transfers.. This is = not server grade hardware (just a mac mini) but it's useful as an order = of magnitude indication imo. We see that the total number of RPs just = checking for updates that the server can handle / second depends = linearly on the repository size (it needs to do an O(n) scan). The total = number of concurrent RPs also depends on the repository size. It appears = that some list / index is kept in memory for every connection. Long = story short, we can only process small numbers of RPs per second and = it's quite trivial to end up with too many concurrent RPs pushing the = servers to the memory limited cliff for huge repositories. Yeah, I was wondering about that. It felt like it was beyond my = perspective to estimate, so I tried to focus this sizing analysis on a = more general systemic view. I totally appreciate the above comment, but = maybe we could try to model that in another tech-note? I'm happy to try = and help, if you would like. >=20 > It's because of this that I keep going on about: > =3D We should have a separate delta protocol and notification = mechanism and not rely on rsync for this > =3D For scalability: > =3D the hard work (CPU) should be done by the clients, not the = server > =3D it should be possible to offload connections & memory away = from the server (proxies) > =3D It makes sense to look at http and scalability of existing CDNs = for delivery ibid. >=20 > My gut feeling (yes it's involved a lot today) tells me that this = SHOULD scale a lot better.. For example serving a small update = notification file over http using a CDN, 10ks of request / second, = easy.. Data transfer to RPs.. probably not a whole lot better actually = if you need it all -- though using existing CDNs with a global = infrastructure closer to RPs may help here. But if we have a = notification file that points to small deltas and fetching these small = files is cheap this may actually be a big improvement.. So although it = may take a while to do the first sync, *staying* in sync may actually = perform a lot better. Well.. all this is thought experiment at this = stage. Without a pilot and actual measurements it's hard to be sure. I really think these are they types of conversations that we should be = having. Thank you very much for putting your thoughts here! Eric= From eosterweil@verisign.com Fri Nov 16 13:50:36 2012 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 27B1321F8B78 for ; Fri, 16 Nov 2012 13:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcbUt+vkATvY for ; Fri, 16 Nov 2012 13:50:35 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id CDB8621F8B4B for ; Fri, 16 Nov 2012 13:50:34 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUKa1KU7eN8fDSXqxdWVTGZ/j+TIZWsNe@postini.com; Fri, 16 Nov 2012 13:50:34 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qAGLoT5N032524; Fri, 16 Nov 2012 16:50:32 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.43]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Nov 2012 16:50:24 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 16 Nov 2012 16:50:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 16 Nov 2012 21:50:28.0326 (UTC) FILETIME=[644DE860:01CDC444] Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 21:50:36 -0000 On Nov 16, 2012, at 9:38 AM, Randy Bush wrote: > first, thanks for getting a larger model started. >=20 > but i think many of the numbers are off. i have had no time this last > week, and will not for another week. so i will pick on just three, as > examples. Great, thanks. >=20 > for bgpsec, i would assume a million routers each having the current > signing cert and the next one, i.e. two million total. scattered over > O(100) repositories. Really? I didn't realize such a large estimate was the case. Do others = agree with the 1m. Also, the standby cert is a good point, I hadn't = factored that in. > the best handle we have on rcynic time today is the ripe repository, > 4,400 objects in 47 seconds, i.e. about .01 secs/obj. and note that, > thank you rsync, time is seriously sub-linear in object count. I just used the numbers that I think you measured and presented at = NANOG, etc. You had some sync performance graphs with average #objects = and average sync time in the lower right/left corners. I just used = those, but that made things seem a little more bleak. > and a roa has it's ee cert built in for free. so there is a factor of > two there. I just put some text to the rationale behind calling this out separately = into an email to Tim (on list). Rather than re-type, maybe we can = converse over that? > i have not had time to look further, but i think, when numbers are a > factor of two to a factor of six off, and you are multiplying, a bit > more rigor is appropriate. I'm totally happy to address the formulation. It could, very well, be = off. However, I think having such a formulation is critical, so can we = talk about evolving what's there to something that lets us measure? Thanks, Eric= From brweber2@yahoo.com Sat Nov 17 05:34:25 2012 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 26C6821F8513 for ; Sat, 17 Nov 2012 05:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dMmdNh1sKW2 for ; Sat, 17 Nov 2012 05:34:23 -0800 (PST) Received: from nm21-vm4.bullet.mail.gq1.yahoo.com (nm21-vm4.bullet.mail.gq1.yahoo.com [98.136.217.51]) by ietfa.amsl.com (Postfix) with ESMTP id 74E8921F8505 for ; Sat, 17 Nov 2012 05:34:23 -0800 (PST) Received: from [98.137.12.191] by nm21.bullet.mail.gq1.yahoo.com with NNFMP; 17 Nov 2012 13:34:23 -0000 Received: from [208.71.42.210] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 17 Nov 2012 13:34:23 -0000 Received: from [127.0.0.1] by smtp221.mail.gq1.yahoo.com with NNFMP; 17 Nov 2012 13:34:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353159263; bh=ZZ2zzYOS5nYcloPWoUlO2FzxpK7Ie3N0Lsr6Zxh+Emw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=fy+Qg2AhH/ZW0Vek7TU3XYq0lPXx0VIVedhEgUrX4sZY2L7HwTPhZ34m7e6Rk+CYBZNC16gISH/3p817PsMiPSrvQu5aU3r4WRpXaH3QI0Os3POXSDBi4IuvZG6hAk5DjwwBP3dJj+5LNaR5G4viJv0Gxrx+IqJQz9/OWRgAHNg= X-Yahoo-Newman-Id: 141388.51606.bm@smtp221.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Fp3qttkVM1liG9U4bkY.2G4cOyZz3OaeKUcazFCRZwdrBNb WercOWqVzmPCickdPcw9PmiT4WAEj95rdFzL8lxJXasuWEo1zGx_CgOn82pC wDu_IBeVEDUeRxYuNrMU5Kp.d7LYslBbYWyAwk2GXMcy23A04f2myxcyxqpp g0LqU5PFBZKiwV0t.aEti2XuZiGCIsoQ1eAgSbYhIgf9vLVZBgqSm8yOQ5rl bnG5jG6MDrzF250CdcgSBB_WskErCDU0Z5YXHQlsiGyuRMI3YEmXmg2BiBin HPKrOiUdtWltpGOjARsNq1WTggTrv6X6Q7G2uaLumq4tmrgEZVKfcM3i.Uur JInetFSTfxL6aA9VWgBSORcDm4Gd7rXF5FcgOYuZbAm7sd5VYjoKUcIeOa3C FH_8cYq6SrmqECzMJ8HxV8bFQZq2amL8.koaFfd5gujb4Zu_tJyr75cOq2hE 8FvE6L.NcPxuWto7IU9bHu2_KzQhk8i1JsTTcSZ8tr9Q_Z9H5ziN.uWj5ECo CXuwYSXMDbhp0GaViFbsT3y5M7j2bSx28WKF8ow-- X-Yahoo-SMTP: f4ZrQXCswBB5jGYwSTd4wDs0ZJPe Received: from [192.168.1.10] (brweber2@68.100.90.3 with plain) by smtp221.mail.gq1.yahoo.com with SMTP; 17 Nov 2012 05:34:22 -0800 PST Content-Type: multipart/alternative; boundary="Apple-Mail=_6CEFBB34-1551-4B39-8B11-48967AD13729" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Bryan Weber In-Reply-To: Date: Sat, 17 Nov 2012 08:34:20 -0500 Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1499) Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 17 Nov 2012 13:34:25 -0000 --Apple-Mail=_6CEFBB34-1551-4B39-8B11-48967AD13729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eric, More comments in line: On Nov 16, 2012, at 4:44 PM, Eric Osterweil = wrote: > Hey Bryan, >=20 > Thanks a lot for the comments! My thoughts are inline: No problem. I'm happy to provide feedback. >=20 > On Nov 14, 2012, at 11:29 PM, Bryan Weber wrote: >=20 >> I have quite a few questions/statements about this document. If you = feel that this list is not the appropriate place to answer them please = respond to me at bryan@cobenian.com. Thanks. >>=20 >> *) Aren't the EE certs contained in the Certificate, Manifest and ROA = artifacts? Should they be counted as separate items to retrieve? >=20 > afaik, EE certs are not contained in manifests. Manifests enumerate = things like EE certs, but they are separate objects (with a different = cardinality). I do believe that the cardinality of EE certs is 1:1 with = ROAs. Though, they are still separately managed objects and have = different management overheads (like managing crypto information when = reissuing, etc). >=20 Yes the manifest enumerates the certificates, ROAs and CRL associated = with (or signed by) the certificate, but it also contains an EE cert. =46rom RFC 6486 that describes the RPKI Manifest: Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used to verify it [RFC6488]. Thus, there is no requirement to separately publish that EE certificate at the CA's repository publication point. It does recommend a one time use EE cert. And yes, ROAs do have a 1:1 cardinality with an EE cert assuming a one = time cert as the RFC recommends. The ROA is also a CMS object that = always contains an EE cert. For performance reasons an EE cert could be = re-used to prevent the expensive key generation portion on the crypto = side. >>=20 >> *) I'm not sure about the status of ghostbuster records today. Has = any RIR implemented or deployed them yet? To my knowledge an RPKI = repository contains CA certs with RFC 3779 extensions, manifests, CRLs = and ROAs. Admittedly I am not familiar with the implementations of all = of the RIRs. >=20 > Well, I think by the same token, not all ASes have deployed SIA = repositories, or issued ROAs yet. The goal of the document is to = represent a global RPKI as prescribed. In the future, if an AS is to = run its own SIA (which I believe is envisioned to be far and away be the = common case), I believe it _must_ have a ghostbuster record so that RPs = can tell whose Cert they are dealing with. There's no other way to = (say) find the administrative contact for a routing object. >=20 Certainly not all of them have. :) But point taken on what you are = trying to accomplish. >>=20 >> *) Is there any reason that ARIN's pilot is listed? The service is = deprecated and the production system is live at this point. Granted it = probably does not have a large volume of data yet. >=20 > We only listed the repositories in the the cited presentation, but we = felt it was important to include them all for completeness and to avoid = bias. We were trying to be unbiased and use the numbers and = measurements that the BGPSEC design team has been publicizing. I don't = know what their metric was for including those measurements, but I = suspect others in the wg could explain better. >=20 OK, so this was just point in time data.=20 >>=20 >> *) You note that=20 >>=20 >> "In addition, in regards to multihoming, we need one ROA and one EE = certi=EF=AC=81cate for each feasible origin for >> a pre=EF=AC=81x, yet we will only see on entry in a RIB." >>=20 >> but on the other hand because of the maximum length in a ROA I = believe that it is very difficult to surmise a relationship between the = number of ROAs and the number of entries in the RIB. >=20 > It is, admittedly, a rough estimate, and we are totally open to other = systematic measures. However, to illustrate why it is tough to find a = good estimate, while some aspects of using the RIB cause this number to = seem large (as you have stated), consider also that the = allocation/suballocation/subsuballocation hierarchy requires resource = holders to issue a chain of certificates (from holder to holder to = holder). =46rom there, a single entry in the RIB could correspond to = multiple allocation objects. This would inflate the number of objects, = but we didn't see an obvious/clean way to estimate this either. As = such, we definitely acknowledge that this is an imperfect estimator, but = we felt it was likely a good ballpark. Make sense? >=20 I think that a heuristic, like average, is probably the only way this = estimate can be done, but likely we'll need more participation to get = enough data for the average to be statistically significant (my guess). = I would also expect to see a power law distribution here (again my = guess). >>=20 >> *) Just as a side note, combining tables 1 and 2 might make the data = easier to read. In separate tables I am forced to keep find the = correlated rows. >=20 > Gotcha, thanks. >=20 >>=20 >> *) Just for my own education, what are the router EE certs? >=20 > In BGPSEC, each router must be able to sign each update it transmits = (originates and forwards). The design team seems to have recently = acknowledged that pushing a single organizational signing cert's private = key to all routers in (say) a multinational AS could be a security = concern. As such, each CA can/should have separate EE certs issued for = routers, such that these certs have their authority delegated from an = organizational CA cert. >=20 And the intent of the EE cert is to verify the transmitted updates? I'll = have to read up a little more on this side of the specs, but I'm = assuming that the EE private key associated with the EE cert must be = kept by the router to sign the updates? I could be way off base here, = I'll go read more like I suggested. :)=20 >>=20 >> *) Another question: should the set of interconnected repositories be = considered a directed graph or a tree hierarchy? Since the certs are = hierarchical shouldn't the URIs pointing to external repositories be = hierarchical as well? >=20 > Well, can you be sure that there will be no cycles in this envisioned = set? I, for example, cannot be sure that an object in one repo does not = point to an external repo that in turn has an object that does not point = back to the original. In fact, this issue is mentioned in the RPKI arch = RFC (6480) as a possibility. Nothing ever goes to plan in the Internet, = so I think it is a very realistic concern. >=20 OK, I see and I agree. I can envision business partnerships that could = lead to this sort of scenario.=20 >>=20 >> *) Does cache synching have to be done serially? >=20 > I believe the time estimates in the presentation that we cited are = actual downloads, so I believe this is using whatever the current best = practices are, though I admit the details were not 100% clear to me. >=20 >>=20 >> If these estimates are accurate then the I think the current expiry = periods of manifests in some of the RIRs would be considered woefully = inadequate.=20 >=20 > Agreed. :( >=20 > Eric Thanks, Bryan= --Apple-Mail=_6CEFBB34-1551-4B39-8B11-48967AD13729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 eosterweil@verisign.com> = wrote:

Hey Bryan,

Thanks a lot for the comments!  My = thoughts are inline:

No problem. I'm = happy to provide feedback.


On = Nov 14, 2012, at 11:29 PM, Bryan Weber wrote:

I have quite a few questions/statements about this = document. If you feel that this list is not the appropriate place to = answer them please respond to me at bryan@cobenian.com. =  Thanks.

*) Aren't the EE certs contained in the = Certificate, Manifest and ROA artifacts? Should they be counted as = separate items to retrieve?

afaik, EE certs are not = contained in manifests.  Manifests enumerate things like EE certs, = but they are separate objects (with a different cardinality).  I do = believe that the cardinality of EE certs is 1:1 with ROAs.  Though, = they are still separately managed objects and have different management = overheads (like managing crypto information when reissuing, = etc).


Yes the manifest = enumerates the certificates, ROAs and CRL associated with (or signed by) = the certificate, but it also contains an EE = cert.

=46rom RFC 6486 that describes the RPKI = Manifest:

Every RPKI signed object includes, in the =
Cryptographic Message
   Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate =
used
   to verify it [RFC6488].  Thus, there is no =
requirement to separately
   publish that EE certificate at the CA's repository publication =
point.

It does recommend a one time use EE = cert.

And yes, ROAs do have a 1:1 cardinality = with an EE cert assuming a one time cert as the RFC recommends. The ROA = is also a CMS object that always contains an EE cert. For performance = reasons an EE cert could be re-used to prevent the expensive key = generation portion on the crypto side.


*) I'm not sure about the = status of ghostbuster records today. Has any RIR implemented or deployed = them yet? To my knowledge an RPKI repository contains CA certs with RFC = 3779 extensions, manifests, CRLs and ROAs. Admittedly I am not familiar = with the implementations of all of the RIRs.

Well, I = think by the same token, not all ASes have deployed SIA repositories, or = issued ROAs yet.  The goal of the document is to represent a global = RPKI as prescribed.  In the future, if an AS is to run its own SIA = (which I believe is envisioned to be far and away be the common case), I = believe it _must_ have a ghostbuster record so that RPs can tell whose = Cert they are dealing with.  There's no other way to (say) find the = administrative contact for a routing = object.


Certainly not all of = them have. :) But point taken on what you are trying to = accomplish.


*) Is there any reason that ARIN's pilot is listed? = The service is deprecated and the production system is live at this = point. Granted it probably does not have a large volume of data = yet.

We only listed the repositories in the the = cited presentation, but we felt it was important to include them all for = completeness and to avoid bias.  We were trying to be unbiased and = use the numbers and measurements that the BGPSEC design team has been = publicizing.  I don't know what their metric was for including = those measurements, but I suspect others in the wg could explain = better.


OK, so this was just = point in time data. 


*) You note that

"In addition, in regards to = multihoming, we need one ROA and one EE certi=EF=AC=81cate for each = feasible origin for
a pre=EF=AC=81x, yet we will only see on entry in = a RIB."

but on the other hand because of the maximum length in a = ROA I believe that it is very difficult to surmise a relationship = between the number of ROAs and the number of entries in the = RIB.

It is, admittedly, a rough estimate, and we are = totally open to other systematic measures.  However, to illustrate = why it is tough to find a good estimate, while some aspects of using the = RIB cause this number to seem large (as you have stated), consider also = that the allocation/suballocation/subsuballocation hierarchy requires = resource holders to issue a chain of certificates (from holder to holder = to holder).  =46rom there, a single entry in the RIB could = correspond to multiple allocation objects.  This would inflate the = number of objects, but we didn't see an obvious/clean way to estimate = this either.  As such, we definitely acknowledge that this is an = imperfect estimator, but we felt it was likely a good ballpark. =  Make sense?


I think that a = heuristic, like average, is probably the only way this estimate can be = done, but likely we'll need more participation to get enough data for = the average to be statistically significant (my guess). I would also = expect to see a power law distribution here (again my = guess).


*) Just as a side note, combining tables 1 and 2 might = make the data easier to read. In separate tables I am forced to keep = find the correlated rows.

Gotcha, = thanks.


*) Just for my own = education, what are the router EE certs?

In BGPSEC, = each router must be able to sign each update it transmits (originates = and forwards).  The design team seems to have recently acknowledged = that pushing a single organizational signing cert's private key to all = routers in (say) a multinational AS could be a security concern. =  As such, each CA can/should have separate EE certs issued for = routers, such that these certs have their authority delegated from an = organizational CA cert.


And the = intent of the EE cert is to verify the transmitted updates? I'll have to = read up a little more on this side of the specs, but I'm assuming that = the EE private key associated with the EE cert must be kept by the = router to sign the updates? I could be way off base here, I'll go read = more like I suggested. :) 


*) Another question: should = the set of interconnected repositories be considered a directed graph or = a tree hierarchy? Since the certs are hierarchical shouldn't the URIs = pointing to external repositories be hierarchical as = well?

Well, can you be sure that there will be no = cycles in this envisioned set?  I, for example, cannot be sure that = an object in one repo does not point to an external repo that in turn = has an object that does not point back to the original. In fact, this = issue is mentioned in the RPKI arch RFC (6480) as a possibility. =  Nothing ever goes to plan in the Internet, so I think it is a very = realistic concern.


OK, I see and = I agree. I can envision business partnerships that could lead to this = sort of scenario. 


*) Does cache synching have to be done = serially?

I believe the time estimates in the = presentation that we cited are actual downloads, so I believe this is = using whatever the current best practices are, though I admit the = details were not 100% clear to me.


If= these estimates are accurate then the I think the current expiry = periods of manifests in some of the RIRs would be considered woefully = inadequate.

Agreed. = :(

Eric

Thanks,
Bryan= --Apple-Mail=_6CEFBB34-1551-4B39-8B11-48967AD13729-- From randy@psg.com Sat Nov 17 06:48:22 2012 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 8CD8521F8EF6 for ; Sat, 17 Nov 2012 06:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z65no9n3WbVF for ; Sat, 17 Nov 2012 06:48:22 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BC57021F8E8F for ; Sat, 17 Nov 2012 06:48:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TZjgt-0007gl-4b; Sat, 17 Nov 2012 14:48:16 +0000 Date: Sat, 17 Nov 2012 21:48:11 +0700 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 17 Nov 2012 14:48:22 -0000 > if an AS is to run its own SIA (which I believe is envisioned to be > far and away be the common case) quite the opposite. the vast majority of ASs will likely use the RIRs' or a tier-1's hosted model. look at the euro region today, a thousand+ in the ncc repository and three or four playing with up-down. randy From eosterweil@verisign.com Sat Nov 17 13:20:55 2012 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 B42B521F8524 for ; Sat, 17 Nov 2012 13:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.619 X-Spam-Level: X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnInLl6weoC8 for ; Sat, 17 Nov 2012 13:20:55 -0800 (PST) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id C7AC921F84E7 for ; Sat, 17 Nov 2012 13:20:49 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUKf/r2fe3YjnBmka9Vt77PSrqoDtccMg@postini.com; Sat, 17 Nov 2012 13:20:49 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qAHLKi0j021337; Sat, 17 Nov 2012 16:20:47 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.43]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Nov 2012 16:20:44 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Sat, 17 Nov 2012 16:20:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA8A3CE-95A3-43B0-9A0F-FE2C237BF206@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 17 Nov 2012 21:20:44.0172 (UTC) FILETIME=[67475CC0:01CDC509] Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 17 Nov 2012 21:20:55 -0000 On Nov 17, 2012, at 9:48 AM, Randy Bush wrote: >> if an AS is to run its own SIA (which I believe is envisioned to be >> far and away be the common case) >=20 > quite the opposite. the vast majority of ASs will likely use the = RIRs' > or a tier-1's hosted model. look at the euro region today, a = thousand+ > in the ncc repository and three or four playing with up-down. Hey Randy, Heh, my crystal ball is clearly neither as big nor as shiny as yours is. = ;) Kidding, actually, I really don't claim to know this, which is why = we modeled deployments with 5, 10, 100, 1,000, and 42,000 repos. As you = should be able to see from Figure 1 in our tech-note, this results in = only about a 10% difference in gathering time (significant, but still = leaves us in the same ballpark). Our hope with this measurement was to = accommodate differences in opinions between all of our crystal balls by = evaluating the spectrum of possibilities here. :) Though, as you and others have pointed out, some of our model's numbers = might need some work. For example, I think you pointed out that our = estimates for the number of router certs appears to be an order of = magnitude too small. We are currently culling corrections so that we = can update the tech-note. Eric= From bryan@cobenian.com Mon Nov 19 20:02:51 2012 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 0E68721F87A4 for ; Mon, 19 Nov 2012 20:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QvuXeYEELuV for ; Mon, 19 Nov 2012 20:02:50 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C993721F8772 for ; Mon, 19 Nov 2012 20:02:48 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5985340oag.31 for ; Mon, 19 Nov 2012 20:02:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version:x-mailer :x-gm-message-state; bh=yExY2o2vf9dH/buuRsO2BjFymYgXKAm09ImqTXDwJAI=; b=Oc1NIQDZErz5qQ5SAecAMFUkrXZaq9+DW+yFvc+GZecxqtFZxK6LqwnKsR1SmIKnOn QAPMVE9ao3cLsT7f21gphZFVs3YJq0l6NsEP9pdCYVAWuiyxEugwQRy+QyhYd9ZWpZqW pScL3BvYUz/ekyoaAkhL8wCWl/15NhDNZwxf/mQtzM2HwM819Z7jKmzZfYiFrqdsG7bG q4s7iWQpN17C8owRQXi1bPUDJZi983vF9zjlZ7LSpxLy8iArpmFDKhAPXISH90vsImCI VUVJlglMHphly1Jn3MyWiv6hs4dRPjslIm5Dda903EXWnI361nSIlQbtbnr48DXjruEN 5CXA== Received: by 10.60.27.68 with SMTP id r4mr12210273oeg.53.1353384167733; Mon, 19 Nov 2012 20:02:47 -0800 (PST) Received: from [192.168.1.9] (ip68-100-90-3.dc.dc.cox.net. [68.100.90.3]) by mx.google.com with ESMTPS id h13sm11971407obp.2.2012.11.19.20.02.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Nov 2012 20:02:47 -0800 (PST) From: Bryan Weber Content-Type: multipart/alternative; boundary="Apple-Mail=_F486ED58-D12A-4860-AEB2-955F56FF178B" Message-Id: <5ED5F195-497C-4043-B44B-A23395987F7E@cobenian.com> Date: Mon, 19 Nov 2012 23:02:46 -0500 To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlSguq+FFZMe6UIESpWBLEI10Lj8jOOKC3wuZT7TJWUWZPiShMRTEZtM4D4IN/cMQQl4bxy Subject: [sidr] RPKI Repository Distribution Protocol - a proposal for an rsync replacement for the RPKI 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, 20 Nov 2012 04:07:11 -0000 --Apple-Mail=_F486ED58-D12A-4860-AEB2-955F56FF178B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii SIDR working group, I humbly submit a proposal for your consideration. It is for an rsync = replacement that for now I am calling the 'RPKI Repository Distribution = Protocol (RRDP)'. It is intended to replace the use of rsync by the RPKI = validators or at least re-open some previous discussion on possible = replacements. The primary benefit is that RRDP is a combination of a very limited = Distributed Version Control System (DVCS) with a transport agnostic = communication protocol. This means that repository changes can be = snapshotted and retrieved as an atomic change. This solves the problem = of in progress transfers when a new repository generation is kicked off. = It also means that different protocols (HTTP/SSL/TLS/etc.) can be used = for the actual transport. Finally, it can work with the existing rsync = URIs and it can work alongside rsync at the same time. Should the = protocol be considered for real adoption this should help to ease in = gradual adoption. A brief paper that describes the protocol can be found at = http://www.cobenian.com/documentation/rrdp.pdf. This is very much a = first draft, but I would appreciate any feedback/comments you have and = any interest you might have in trying to use this protocol with a real = validator. I am all ears to suggestions for improvements. I would = especially love to make it more aware of the contents of RPKI manifests. The beginning of a reference implementation can be found at = http://www.github.com/cobenian/rrdp. This is not feature complete and = certainly not compliant with the specification at the moment, but it = should be in the very near future (a few days to a few weeks). Regards, Bryan (703) 828.5180 bryan@cobenian.com --Apple-Mail=_F486ED58-D12A-4860-AEB2-955F56FF178B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.cobenia= n.com/documentation/rrdp.pdf. This is very much a first draft, but I = would appreciate any feedback/comments you have and any interest you = might have in trying to use this protocol with a real validator. I am = all ears to suggestions for improvements. I would especially love to = make it more aware of the contents of RPKI = manifests.

The beginning of a reference = implementation can be found at http://www.github.com/cobenia= n/rrdp. This is not feature complete and certainly not compliant = with the specification at the moment, but it should be in the very near = future (a few days to a few weeks).

Regards,
Bryan

(703) 828.5180
bryan@cobenian.com

= --Apple-Mail=_F486ED58-D12A-4860-AEB2-955F56FF178B-- From christopher.morrow@gmail.com Mon Nov 19 21:04:49 2012 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 D092B21F8808 for ; Mon, 19 Nov 2012 21:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzwQ8ifNrxFB for ; Mon, 19 Nov 2012 21:04:49 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 142D821F8805 for ; Mon, 19 Nov 2012 21:04:48 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so3618747eek.31 for ; Mon, 19 Nov 2012 21:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+XvfirPLXCl2fPLwKq9Xgr8rSZWqzq8I7IzYXYtpySE=; b=JVzsCt6XSRJKL7Pefs+m9piVwCsCUw4L/qbWsx9rW4vqHTAubtL7ZoWFMLOrvKk4/E br8OIx5eraS52q2kg1auaTljVeMzg+VWcdy/CNlwkNkPQT6wBfbjcwJxoslgs0VoJVh0 +V5QBcVPvS7/3dskzi0a3Ws5aZ3JPbsjQJfiYHcKRtFR4a9CjFStoMBehPtrDa94tFt8 ov9k468D4jadDQ2knMERHV36BrlEsr48qFs5Gwxxa2b0V1ioU/V+58MfcG2RHhPcUdNX ZZKM4o6Vm2QBzQQEogT3miogGusV1P9c8J7MRB3tUSBNTJC6GOUiMBbUXlFBs0y5KIw2 5Z4g== MIME-Version: 1.0 Received: by 10.14.211.135 with SMTP id w7mr22997617eeo.4.1353387888214; Mon, 19 Nov 2012 21:04:48 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.71 with HTTP; Mon, 19 Nov 2012 21:04:48 -0800 (PST) In-Reply-To: <7FA8A3CE-95A3-43B0-9A0F-FE2C237BF206@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.com> <7FA8A3CE-95A3-43B0-9A0F-FE2C237BF206@verisign.com> Date: Tue, 20 Nov 2012 00:04:48 -0500 X-Google-Sender-Auth: 889-Mhn_BwD_nzd1G-OWipwDJdw Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 20 Nov 2012 05:04:50 -0000 On Sat, Nov 17, 2012 at 4:20 PM, Eric Osterweil wrote: > > On Nov 17, 2012, at 9:48 AM, Randy Bush wrote: > >>> if an AS is to run its own SIA (which I believe is envisioned to be >>> far and away be the common case) >> >> quite the opposite. the vast majority of ASs will likely use the RIRs' >> or a tier-1's hosted model. look at the euro region today, a thousand+ >> in the ncc repository and three or four playing with up-down. I think that even if you use a hosted service, your URL is probably going to evolve into a separate connection from mine on the same hosted model. That single hosted URL seems like a great target to poke at with the ddos-cannon :( In the DNS world, many folk use different /24's for each set of cctld/etc NS hosts, when folk like godaddy/worldnic do NOT we learn how much of the internet namespace lives behind their ips :( (note that both providers above have more than 2-4 ips in play, but all of them have many resources behind a shared smaller set of targets) > Heh, my crystal ball is clearly neither as big nor as shiny as yours is. ;) Kidding, actually, > I really don't claim to know this, which is why we modeled deployments with 5, 10, 100, > 1,000, and 42,000 repos. As you should be able to see from Figure 1 in our tech-note, in the end, modeling at 42k is the 'worst case' right? (worst today, tomorrow it'll be 42001, of course). -chris From housley@vigilsec.com Tue Nov 20 00:18:51 2012 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 EAFAE21F8766 for ; Tue, 20 Nov 2012 00:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka5OANZHQ3He for ; Tue, 20 Nov 2012 00:18:51 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9E19B21F85B6 for ; Tue, 20 Nov 2012 00:18:50 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 90F099A4003; Tue, 20 Nov 2012 03:18:51 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id dM1M8rf8IL5T; Tue, 20 Nov 2012 03:18:45 -0500 (EST) Received: from [5.5.33.24] (vpn.snozzages.com [204.194.22.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1B2C79A4002; Tue, 20 Nov 2012 03:18:45 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-130--717315260 From: Russ Housley In-Reply-To: <5ED5F195-497C-4043-B44B-A23395987F7E@cobenian.com> Date: Tue, 20 Nov 2012 03:18:42 -0500 Message-Id: <480B1D2A-1FCE-4569-90F8-26CBF042FDB3@vigilsec.com> References: <5ED5F195-497C-4043-B44B-A23395987F7E@cobenian.com> To: Bryan Weber X-Mailer: Apple Mail (2.1085) Cc: sidr wg list Subject: Re: [sidr] RPKI Repository Distribution Protocol - a proposal for an rsync replacement for the RPKI 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, 20 Nov 2012 08:18:52 -0000 --Apple-Mail-130--717315260 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At the meeting in Atlanta, we heard some very impressive performance = numbers for the restructured RIPE repository with rsync. While your = code is not feature complete, do you have any expectations of similar = performance? Russ On Nov 19, 2012, at 11:02 PM, Bryan Weber wrote: > SIDR working group, >=20 > I humbly submit a proposal for your consideration. It is for an rsync = replacement that for now I am calling the 'RPKI Repository Distribution = Protocol (RRDP)'. It is intended to replace the use of rsync by the RPKI = validators or at least re-open some previous discussion on possible = replacements. >=20 > The primary benefit is that RRDP is a combination of a very limited = Distributed Version Control System (DVCS) with a transport agnostic = communication protocol. This means that repository changes can be = snapshotted and retrieved as an atomic change. This solves the problem = of in progress transfers when a new repository generation is kicked off. = It also means that different protocols (HTTP/SSL/TLS/etc.) can be used = for the actual transport. Finally, it can work with the existing rsync = URIs and it can work alongside rsync at the same time. Should the = protocol be considered for real adoption this should help to ease in = gradual adoption. >=20 > A brief paper that describes the protocol can be found at = http://www.cobenian.com/documentation/rrdp.pdf. This is very much a = first draft, but I would appreciate any feedback/comments you have and = any interest you might have in trying to use this protocol with a real = validator. I am all ears to suggestions for improvements. I would = especially love to make it more aware of the contents of RPKI manifests. >=20 > The beginning of a reference implementation can be found at = http://www.github.com/cobenian/rrdp. This is not feature complete and = certainly not compliant with the specification at the moment, but it = should be in the very near future (a few days to a few weeks). >=20 > Regards, > Bryan >=20 > (703) 828.5180 > bryan@cobenian.com --Apple-Mail-130--717315260 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii At = the meeting in Atlanta, we heard some very impressive performance = numbers for the restructured RIPE repository with rsync.  While = your code is not feature complete, do you have any expectations of = similar = performance?

Russ


On Nov 19, 2012, at 11:02 PM, Bryan Weber wrote:

SIDR working = group,

I humbly submit a proposal for your = consideration. It is for an rsync replacement that for now I am calling = the 'RPKI Repository Distribution Protocol (RRDP)'. It is = intended to replace the use of rsync by the RPKI validators or at least = re-open some previous discussion on possible = replacements.

The primary benefit is that RRDP = is a combination of a very limited Distributed Version Control System = (DVCS) with a transport agnostic communication protocol. This means that = repository changes can be snapshotted and retrieved as an atomic change. = This solves the problem of in progress transfers when a new repository = generation is kicked off. It also means that different protocols = (HTTP/SSL/TLS/etc.) can be used for the actual transport. Finally, it = can work with the existing rsync URIs and it can work alongside rsync at = the same time. Should the protocol be considered for real adoption this = should help to ease in gradual adoption.

A = brief paper that describes the protocol can be found at http://www.cobenia= n.com/documentation/rrdp.pdf. This is very much a first draft, but I = would appreciate any feedback/comments you have and any interest you = might have in trying to use this protocol with a real validator. I am = all ears to suggestions for improvements. I would especially love to = make it more aware of the contents of RPKI = manifests.

The beginning of a reference = implementation can be found at http://www.github.com/cobenia= n/rrdp. This is not feature complete and certainly not compliant = with the specification at the moment, but it should be in the very near = future (a few days to a few weeks).

Regards,
Bryan

(703) 828.5180
bryan@cobenian.com

= --Apple-Mail-130--717315260-- From danny@tcb.net Tue Nov 20 07:43:17 2012 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 BAA2B21F8753 for ; Tue, 20 Nov 2012 07:43:17 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFVDw0zr-d0d for ; Tue, 20 Nov 2012 07:43:17 -0800 (PST) Received: from mail.friendswithtools.org (unknown [IPv6:2600:3000:150f:701:5054:ff:fed1:24a9]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6AF21F8427 for ; Tue, 20 Nov 2012 07:43:17 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 2F5731B34 for ; Tue, 20 Nov 2012 15:43:14 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-71-171-124-149.clppva.fios.verizon.net [71.171.124.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 631583A3; Tue, 20 Nov 2012 08:43:13 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <480B1D2A-1FCE-4569-90F8-26CBF042FDB3@vigilsec.com> Date: Tue, 20 Nov 2012 10:43:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5ED5F195-497C-4043-B44B-A23395987F7E@cobenian.com> <480B1D2A-1FCE-4569-90F8-26CBF042FDB3@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Nov 20 08:43:14 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50aba512199639484612033 X-DSPAM-Factors: 27, Cc*sidr+#+#+#+ietf.org, 0.01000, 2012+#+3, 0.01000, of+#+#+#+that, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+#+#+#+AM, 0.01000, 2012+at, 0.01000, Cc*sidr+wg, 0.01000, the+#+#+that, 0.01000, the+#+#+#+we, 0.01000, of+#+and, 0.01000, for+the, 0.01000, Mime-Version*Apple+#+framework, 0.01000, AM+#+#+wrote, 0.01000, the+#+in, 0.01000, Cc*wg+#+sidr, 0.01000, Mime-Version*1.0+Apple, 0.01000, is+not, 0.01000, wrote+#+#+#+in, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000, definition+of, 0.01000, From*Danny+#+danny, 0.01000, From*Danny+#+#+tcb.net, 0.01000, Mime-Version*framework+v1283, 0.01000, at+3, 0.01000, Subject*Re+sidr, 0.01000 Cc: Bryan Weber , sidr wg list Subject: Re: [sidr] RPKI Repository Distribution Protocol - a proposal for an rsync replacement for the RPKI 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, 20 Nov 2012 15:43:17 -0000 On Nov 20, 2012, at 3:18 AM, Russ Housley wrote: > At the meeting in Atlanta, we heard some very impressive performance = numbers for the restructured RIPE repository with rsync. While your = code is not feature complete, do you have any expectations of similar = performance? Russ,=20 Can you clarify which thing "we heard" about that you consider = "impressive"? Had we started with requirements here we might have wound up with a = model for push of changes and seconds to single-digit minutes for = changes to be picked up by RPs - "seconds" would be my definition of = impressive (e.g., Tweet them), else we're going to wind up with many of = the latency issues that contributed to "challenges" with IRRs. -danny From eosterweil@verisign.com Tue Nov 20 11:26:45 2012 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 1AE8421F882E for ; Tue, 20 Nov 2012 11:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBRNKeexrxLL for ; Tue, 20 Nov 2012 11:26:44 -0800 (PST) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9821F87F7 for ; Tue, 20 Nov 2012 11:26:44 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUKvZcSyC87eZKKuxGMMp9XBIuE8D5wd0@postini.com; Tue, 20 Nov 2012 11:26:44 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qAKJQcT8006252; Tue, 20 Nov 2012 14:26:40 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.1.112]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Nov 2012 14:26:37 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 20 Nov 2012 14:26:38 -0500 Content-Transfer-Encoding: 7bit Message-Id: <9FBE41C0-43E0-401E-8328-7E6D3E4C789E@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <5EAB24AD-4FD9-4036-9A3F-72F6DD7183AC@yahoo.com> <7FA8A3CE-95A3-43B0-9A0F-FE2C237BF206@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Nov 2012 19:26:37.0747 (UTC) FILETIME=[F5BB1030:01CDC754] Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 20 Nov 2012 19:26:45 -0000 On Nov 20, 2012, at 12:04 AM, Christopher Morrow wrote: > in the end, modeling at 42k is the 'worst case' right? (worst today, > tomorrow it'll be 42001, of course). Exactly. Eric From randy@psg.com Wed Nov 21 04:37:57 2012 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 5D80021F85E0 for ; Wed, 21 Nov 2012 04:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4lSZFyCPwMB for ; Wed, 21 Nov 2012 04:37:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F067921F8519 for ; Wed, 21 Nov 2012 04:37:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tb9Yr-00061a-DY; Wed, 21 Nov 2012 12:37:50 +0000 Date: Wed, 21 Nov 2012 19:37:44 +0700 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: References: <5ED5F195-497C-4043-B44B-A23395987F7E@cobenian.com> <480B1D2A-1FCE-4569-90F8-26CBF042FDB3@vigilsec.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Bryan Weber , sidr wg list Subject: Re: [sidr] RPKI Repository Distribution Protocol - a proposal for an rsync replacement for the RPKI 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, 21 Nov 2012 12:37:57 -0000 > Had we started with requirements here we might have wound up with a > model for push of changes and seconds to single-digit minutes for > changes to be picked up by RPs - "seconds" would be my definition of > impressive (e.g., Tweet them), else we're going to wind up with many > of the latency issues that contributed to "challenges" with IRRs. and here i was expecting microseconds :) randy From tim@ripe.net Thu Nov 22 07:13:15 2012 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 9A58421F88F7 for ; Thu, 22 Nov 2012 07:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAMHe28YPJ2R for ; Thu, 22 Nov 2012 07:13:11 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4A21F88F8 for ; Thu, 22 Nov 2012 07:13:10 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TbYSf-0001Qj-1K; Thu, 22 Nov 2012 16:13:07 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TbYSe-0006CF-UZ; Thu, 22 Nov 2012 16:13:04 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4974855A-B4BB-4843-886B-E0D90D094A7E" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Bruijnzeels In-Reply-To: <480B1D2A-1FCE-4569-90F8-26CBF042FDB3@vigilsec.com> Date: Thu, 22 Nov 2012 16:13:06 +0100 Message-Id: References: <5ED5F195-497C-4043-B44B-A23395987F7E@cobenian.com> <480B1D2A-1FCE-4569-90F8-26CBF042FDB3@vigilsec.com> To: Russ Housley , Bryan Weber X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121122 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071975475e4067ddb322851c89b34e6e9d77 Cc: sidr wg list Subject: Re: [sidr] RPKI Repository Distribution Protocol - a proposal for an rsync replacement for the RPKI 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, 22 Nov 2012 15:13:15 -0000 --Apple-Mail=_4974855A-B4BB-4843-886B-E0D90D094A7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, =20 As some of you might know I have also done some thinking on analysing = the problems with the current infrastructure, and also have some ideas = about improvements and talked about this at the Vancouver interim. It's = way too much for inline email, so I also took the liberty of writing my = ideas down in an IETF format, that hopefully helps to discuss this in a = more structured way: = http://www.ietf.org/internet-drafts/draft-tbruijnzeels-sidr-delta-protocol= -00.txt This too is of course a first draft and intended for discussion.. On Nov 20, 2012, at 9:18 AM, Russ Housley wrote: > At the meeting in Atlanta, we heard some very impressive performance = numbers for the restructured RIPE repository with rsync. =20 Although the performance has improved dramatically for some RPs now that = the structure is hierarchical, I don't think today's performance is a = good indicator for the future. We now see: - Around 50-60 unique IP addresses for RPs connecting every day - One of these (gw1.antd.nist.gov) is responsible for roughly 9k = connections per day - Ignoring that one for now the remaining are responsible for around = 1.8k connections per day:=20 =3D> about 36 fetches / day for each client, or once every 40 minutes We have around 4.5k objects in our repository. In a full deployment scenario we can expect many more relying parties, = one for each ASN seems likely, so that is 40k clients. And while we = don't agree yet what the size of the total repository would be, = indications are it's in the order of 1-2M at least, so roughly 1/5th of = that places our repository at 200-400k. There are also indications that = more frequent updates are actually desirable. Say once every 5 minutes = vs 40.. In short that's 10^3 times the clients, 10^2 times the objects, and 10 = times the connection frequency.=20 With those numbers it's very hard to predict exactly what behaviour we = will see, it's very likely non-linear, but if it were, we're talking = 10^6 times today's load. > While your code is not feature complete, do you have any expectations = of similar performance? When measured 1:1 rsync performance is actually pretty good. As described in my document: One of the major problems I see is that in = this space we're not talking 1:1, but something like 1 server : 40k = clients. > On Nov 19, 2012, at 11:02 PM, Bryan Weber wrote: >=20 >> SIDR working group, >>=20 >> I humbly submit a proposal for your consideration. It is for an rsync = replacement that for now I am calling the 'RPKI Repository Distribution = Protocol (RRDP)'. It is intended to replace the use of rsync by the RPKI = validators or at least re-open some previous discussion on possible = replacements. >>=20 >> The primary benefit is that RRDP is a combination of a very limited = Distributed Version Control System (DVCS) with a transport agnostic = communication protocol. This means that repository changes can be = snapshotted and retrieved as an atomic change. This solves the problem = of in progress transfers when a new repository generation is kicked off. = It also means that different protocols (HTTP/SSL/TLS/etc.) can be used = for the actual transport. Finally, it can work with the existing rsync = URIs and it can work alongside rsync at the same time. Should the = protocol be considered for real adoption this should help to ease in = gradual adoption. >>=20 I like the idea of the snapshotted atomic changes. But I have problems = with a communication protocol where the server needs to chat with up to = 40k RPs. The CPU and memory usage stats per client may not be the same = as with rsync (see slides interim), but the same fundamental problem = remains: you're proposing a smart server that has to spend cycles = talking to too many clients. As described in my proposal I prefer a protocol that lets RPs work out = which changes to fetch by themselves, and although I too do not want to = restrict to one protocol, I want something that can leverage existing = proven http CDN infrastructure to deliver data to clients. >> A brief paper that describes the protocol can be found at = http://www.cobenian.com/documentation/rrdp.pdf. This is very much a = first draft, but I would appreciate any feedback/comments you have and = any interest you might have in trying to use this protocol with a real = validator. I am all ears to suggestions for improvements. I would = especially love to make it more aware of the contents of RPKI manifests. >>=20 First of all I want to thank you for thinking about solutions, even if = our ideas may differ somewhat. I had drafts of my proposal on my machine for a while, presented parts = of it in Vancouver, and have discussed with various people, but I did = not send it to sidr yet. Now that you sent your version, I felt like = sharing mine though ;) >> The beginning of a reference implementation can be found at = http://www.github.com/cobenian/rrdp. This is not feature complete and = certainly not compliant with the specification at the moment, but it = should be in the very near future (a few days to a few weeks). Tim= --Apple-Mail=_4974855A-B4BB-4843-886B-E0D90D094A7E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.ietf.org/internet-drafts/draft-tbruijnzeels-si= dr-delta-protocol-00.txt

This too is = of course a first draft and intended for = discussion..


On Nov = 20, 2012, at 9:18 AM, Russ Housley <housley@vigilsec.com> = wrote:
At the meeting in Atlanta, we heard some very = impressive performance numbers for the restructured RIPE repository with = rsync.  

Although the = performance has improved dramatically for some RPs now that the = structure is hierarchical, I don't think today's performance is a good = indicator for the future.

We now = see:
- Around 50-60 unique IP addresses for RPs connecting = every day
- One of these (gw1.antd.nist.gov) is responsible = for roughly 9k connections per day
- Ignoring that one for now = the remaining are responsible for around 1.8k connections per = day: 
   =3D> about 36 fetches / day for = each client, or once every 40 minutes

We have = around 4.5k objects in our repository.

In a = full deployment scenario we can expect many more relying parties, one = for each ASN seems likely, so that is 40k clients. And while we don't = agree yet what the size of the total repository would be, indications = are it's in the order of 1-2M at least, so roughly 1/5th of that places = our repository at 200-400k. There are also indications that more = frequent updates are actually desirable. Say once every 5 minutes vs = 40..

In short that's 10^3 times the clients, = 10^2 times the objects, and 10 times the connection = frequency. 

With those numbers it's very = hard to predict exactly what behaviour we will see, it's very likely = non-linear, but if it were, we're talking 10^6 times today's = load.

While your code is not feature = complete, do you have any expectations of similar = performance?

When measured 1:1 = rsync performance is actually pretty good.

As = described in my document: One of the major problems I see is that in = this space we're not talking 1:1, but something like 1 server : 40k = clients.



On Nov 19, 2012, at = 11:02 PM, Bryan Weber wrote:

SIDR working = group,

I humbly submit a proposal for your = consideration. It is for an rsync replacement that for now I am calling = the 'RPKI Repository Distribution Protocol (RRDP)'. It is = intended to replace the use of rsync by the RPKI validators or at least = re-open some previous discussion on possible = replacements.

The primary benefit is that RRDP is a = combination of a very limited Distributed Version Control System (DVCS) = with a transport agnostic communication protocol. This means that = repository changes can be snapshotted and retrieved as an atomic change. = This solves the problem of in progress transfers when a new repository = generation is kicked off. It also means that different protocols = (HTTP/SSL/TLS/etc.) can be used for the actual transport. Finally, it = can work with the existing rsync URIs and it can work alongside rsync at = the same time. Should the protocol be considered for real adoption this = should help to ease in gradual = adoption.


I like the idea of the snapshotted atomic = changes. But I have problems with a communication protocol where the = server needs to chat with up to 40k RPs. The CPU and memory usage stats = per client may not be the same as with rsync (see slides interim), but = the same fundamental problem remains: you're proposing a smart server = that has to spend cycles talking to too many = clients.

As described in my proposal I prefer a = protocol that lets RPs work out which changes to fetch by themselves, = and although I too do not want to restrict to one protocol, I want = something that can leverage existing proven http CDN infrastructure to = deliver data to clients.

A brief paper that = describes the protocol can be found at http://www.cobenia= n.com/documentation/rrdp.pdf. This is very much a first draft, but I = would appreciate any feedback/comments you have and any interest you = might have in trying to use this protocol with a real validator. I am = all ears to suggestions for improvements. I would especially love to = make it more aware of the contents of RPKI = manifests.


First of all I want to thank you for thinking = about solutions, even if our ideas may differ = somewhat.

I had drafts of my proposal on my = machine for a while, presented parts of it in Vancouver, and have = discussed with various people, but I did not send it to sidr yet. Now = that you sent your version, I felt like sharing mine though = ;)


The beginning of a = reference implementation can be found at http://www.github.com/cobenia= n/rrdp. This is not feature complete and certainly not compliant = with the specification at the moment, but it should be in the very near = future (a few days to a few = weeks).



Tim
= --Apple-Mail=_4974855A-B4BB-4843-886B-E0D90D094A7E-- From carlosm3011@gmail.com Thu Nov 22 10:40:30 2012 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 1EEAD21F8602 for ; Thu, 22 Nov 2012 10:40:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niZRFl6ev1qB for ; Thu, 22 Nov 2012 10:40:29 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 459EF21F8600 for ; Thu, 22 Nov 2012 10:40:29 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so1637167yhq.31 for ; Thu, 22 Nov 2012 10:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=CO/ut1IGm8W53q1P7RL/1dtQL7aVtV9Uag1/xc9J0zE=; b=VgZSJCtZINplrset2VpS098Ra61aHy0VD6wf/jZNVgjxnwa15Meld43D7zP9PKOz/y 3MhawgCdDg/scu5ftZ8NSGxmavUhIAIA9rmjKlwBQjZkyPHIbtVXT9o3X0cPEQhEOoLo 5vsVmzyQVYMAXmgAEjBnHK4YI1fTXDEY9BUFNpP+vdj7doNg8e+OCC/04lp+BYb4SSMp d+IH4b71/3YnlWjMpYu9EuncN/LBW1vJwnUuRynsJQbLQ+iBL0blb+JBoEVfwzXc5oQu ZEoh5+MsE0oTqhyqL8yob7Cu2xrAOGjLzZGqu6heuXr/IuB3jtzet65hsyFuxKS4E7LK IBvQ== Received: by 10.236.81.242 with SMTP id m78mr1333414yhe.36.1353609628559; Thu, 22 Nov 2012 10:40:28 -0800 (PST) Received: from europa.local ([200.7.87.205]) by mx.google.com with ESMTPS id t14sm3713081anl.17.2012.11.22.10.40.25 (version=SSLv3 cipher=OTHER); Thu, 22 Nov 2012 10:40:27 -0800 (PST) Message-ID: <50AE7197.4040002@gmail.com> Date: Thu, 22 Nov 2012 16:40:23 -0200 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] LACNIC RTA key rollover 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, 22 Nov 2012 18:40:30 -0000 Folks, On Thursday, November 29, 2012 LACNIC will be performing a system migration to a new release of the RPKI system. We will take the opportunity to also perform a key rollover of LACNIC's RPKI trust anchor. The new TAL (trust anchor locator) file can be downloaded from [1]. Also a ready-to-use configuration file for RIPE-NCC's Validation Application is available at [2]. Both the certificate and repository this TAL points to are already active, but the main repository material (resource CAs and ROAs) will be migrated on the same date at 14.00 UTC. All relying-party operators are encouraged to download the TAL file and add it to their validation tool configuration before that time in order to maintain continuity of validation. [1] https://rpki.lacnic.net/tal/lacnic-201212.tal [2] https://rpki.lacnic.net/tal/lacnic-ripeval-201212.tal If you have any questions please do not hesitate to contact us at rpki-admin@lacnic.net Warm regards, Carlos From tim@ripe.net Fri Nov 23 08:26:41 2012 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 609F621F8533 for ; Fri, 23 Nov 2012 08:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-1.435, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqf1TQETjLWM for ; Fri, 23 Nov 2012 08:26:38 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 1929721F854F for ; Fri, 23 Nov 2012 08:26:38 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Tbw5H-0008I8-O8; Fri, 23 Nov 2012 17:26:36 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Tbw5H-0005mU-Jp; Fri, 23 Nov 2012 17:26:31 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_FD196ED6-DEB2-473A-92B8-7D0E16664ADD" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Bruijnzeels In-Reply-To: Date: Fri, 23 Nov 2012 17:26:32 +0100 Message-Id: <8CC97F34-991B-411A-BE0D-B39972740C72@ripe.net> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50A47152.6010903@gmail.com> <89C00A38-151D-4980-9951-DC3A33D565DC@ripe.net> To: Eric Osterweil X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121123 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.3 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c5a0c29037e01deb9905f7c61d0105d7 Cc: "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 23 Nov 2012 16:26:41 -0000 --Apple-Mail=_FD196ED6-DEB2-473A-92B8-7D0E16664ADD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Eric, Sorry for the late response.. With regards to some of your comments regarding requirements and ideas = for alternative deltas, some responses inline below, but other than that = see the thread where both Bryan Weber and I talk about our ideas. This = is somewhat separate from the questions about "how a fully deployed RPKI = tree would look like", and "what churn we might see" and "how many = connecting RPs, and how frequent". All that can feed into requirements, = but is in essence another discussion, so I suggest we keep them = separate. On Nov 16, 2012, at 10:44 PM, Eric Osterweil = wrote: >=20 > On Nov 16, 2012, at 10:45 AM, Tim Bruijnzeels wrote: >=20 >> Hi, >>=20 >> Some more comments on the numbers and formula.. >>=20 >> On Nov 15, 2012, at 5:36 AM, Arturo Servin = wrote: >>=20 >=20 > >=20 >> Apart from any signed objects it may publish, every CA typically has: >> =3D 1 certificate published by its parent >=20 > But, as I asked Arturo, would we expect to have a CA from each parent = (i.e. each RIR that an org may allocations from)? While this may often = still just be 1, it seems important to note, no? THat was one reason we = had for breaking it apart. I'm more than willing to believe that I'm = wrong here, but I'd like to understand how.=20 >=20 >> =3D 1 manifest >> =3D 1 CRL >> =3D 1 GB record (as Arturo said not widely deployed, but let's throw = it in for full deployment) >=20 > How does the RPKI certify ASN allocations? This is needed to certify = router EE certs (they are tied to an ASN, no?). Such an AS cert would = add another 1 to the above and make it 5, right? Otherwise, how does a = forward signing peer associate itself with the ASN, instead of some = prefix? The ASN isn't necessarily allocated by the same RIR as any of = the allocations, so IP allocation and ASN allocation are orthogonal, no? Okay, let me rephrase.. it gets confusing when talking about = organisations as CAs, and CA certificates: i.e. certificates that have = the CA bit set and can sign and publish other certificates, signed = objects etc. We're talking 4 objects for each CA Certificate: =3D 1 CA Certificate with IPv4, IPv6 and/or ASN =3D 1 mft =3D 1 CRL =3D 1 GB An organisation may have more than one CA certificate: =3D if it has different parents and get certificates from more than one =3D if it has 'minority space'. For example if one of our members has = resources for which another RIR is the majority holder, then this is not = on our normal certificate. We get a certificate with all such resources = signed by the other RIR, and then we use this to sign an additional = certificate for this member. Certificates can have only one parent, so = we can not merge this. Regarding the second point: I haven't done detailed analysis on our data = yet. This does affect at least a portion of our members, so the average = number of CA certs per member organisation is more than 1. I expect that = it will not be a *lot* higher, but like I said I haven't analysed the = data yet. Having said that, it seems that the relative component of these, in a = sense, boilerplate objects of the total count, are of a different order = than the amount of expected ROAs and router certificates. >>=20 >> So that's 4 objects. >>=20 >> During a key roll the CA will have the following additional objects: >> =3D 1 cert published by the parent >> =3D 1 manifest >> =3D 1 CRL >>=20 >> Making 7 objects. But typically not all CAs roll at the same time. >=20 > Unless it is an algorithm rollover, and that is expected to last for = years (iirc). Then this set would be doubled (plus double the numbers = below), right? >=20 I did not consider algorithm roll over, but I think you're right. >>=20 >> The number of signed ROAs and Router certificates does, >=20 > And EE certs. While 1:1 with ROAs, they require additional (very = different) processing, esp if you start down the road of HSMs. So, we = claimed this additional operational requirement means that even if you = double up on the downloads, those are still two separate objects. You = have to manage EE rollover keeping crypto material the same or changing = it, depending on details of the ROA, etc. That won't come for free, and = (again) needing HSMs makes this a big deal. So, we really felt it was = important to call this complexity out by counting each.=20 I don't understand the use of EE certs and HSMs here. And I don't see = how this can significantly raise the object count. In the rpki EE certs can only be used to sign rpki signed objects and = they are embedded in those objects, not published separately. All keys in our online system are protected by HSMs. The keys in EE = certificates even more so: they are generated in an HSM, used only once, = and then forgotten. In the online system the HSM protects against key = theft if an attacker somehow gets access to the database/file system.. = The will not be able to export the keys without access to a quorum of = key cards that protect the internal key of the HSM. If you want to use an *offline* key protected by an HSM, then you would = have an additional CA cert (and mft, crl and gb). This is what we do = with our TA at least: TA (offline) -> signs CA cert for online use =3D> signs member CAs The idea being that if the worst happens to our online system, we can = rebuild and re-issue using the more secure offline key. The hosted = members don't have their own offline key, they are protected by the same = one.. Non-hosted CAs may want to use an intermediate offline = certificate. This adds some overhead: 4 objects per offline key (CA = cert, mft, crl, gb).=20 >> in my opinion, not depend on the number of CAs, but: >> =3D ROA -> The number of announcements seen in BGP * some aggregation = factor (1 / # average prefixes on one ROA) >=20 > I, pretty much agree with this (as I think the tech-note said). I do, = however have to note that with MOAS, you need multiple ROAs. Small = point, but worth stating. :) Yes, a ROA can have one ASN only, but multiple prefixes. We aggregate prefixes for the same ASN as much as we can on a single = ROA. So far we are managing a factor of around 3 prefixes per ROA. = Lacnic is similar. The other RIRs seem to aggregate a bit less at this = time. See here: http://certification-stats.ripe.net/ >=20 >> =3D Router certs -> The number of ASNs * the number of keys for each = ASN >=20 > \times The number of eBGP speakers you mean, right? Yes. My model assumes that this number of speakers can related to the = number of ASNs. Randy suggested a number of physical bhp sec speaking routers and that = they may have two keys. That may well be a better model. >=20 >>=20 >> So I think a better model would be to say: >>=20 >> number object >> #CA CA cert >> #CA MFT >> #CA CRL >> #CA GB >=20 > Ack, we just estimated this as the # of SIAs, and then varied it from = 5 to 42,000. 5 here would mean the current RIR TAs without any other signed content. The total object count for this depends on the number of CA certs. See = my previous best estimate below. >=20 >>=20 >> #prefixes * X ROAs >=20 > Yeah, but we didn't guestimate the $X$ value. It sounds like we = should, but is there any data we can use to do so? >=20 >>=20 >> #ASNs * Y Router certs >>=20 >> Ototal =3D 4 * #CA + #prefixes * X + #ASNs * Y >=20 > Re: the above, I think this would be=20 >=20 > O^Total =3D 4 * #CA + #ASNs + #prefixes + X * #prefixes + Y * #ASNs >=20 > We had called out the need for AS EE cert (which was not in the = equation you outlined), and we felt it was important to not omit EE = certs (if for no other reason than the operational complexity they = bring). >=20 >>=20 >> As for the numbers.. this is a bit of a guessing game.. we just = really don't know at this time. We can take our best guess, but should = keep in mind that our best guess is probably off, and needs = re-evaluation in years to come. >=20 > 100% agree. That is why we called this a back-of-the-envelope = calculation and are totally seeking feedback, and are absolutely = interested in pushing revisions as things evolve. >=20 >>=20 >> #CAs >>=20 >> If this were the total number of current members for all RIRs this = number would be around 40k. However, there are also PI users that are = not direct members of the RIRs, and some members will delegate some of = their resources further. For reference I believe that in the RIPE region = we have around 25k PI prefixes. I expect that a lot of the organisations = that hold these resources will be happy to let a sponsoring RIR member = (LIR in our region) manage their ROAs. But not all.. So I think that in = a full deployment world this number may be significantly bigger. If = anyone has any ideas on this, please chime in=85 Going on nothing more = than gut feeling I would say the total could be in the order of:=20 >>=20 >> =3D 40k RIR members plus 40k self managing PI holders / children of = members? >>=20 >> 80k.=20 >=20 > Really? I had been thinking that this number was tied to the origins, = but I can see your logic. It would great to try and find a way to = estimate this, so I'd like to echo your request for anyone with info to = chime in. >=20 >>=20 >> #prefixes and 'X' >>=20 >> The number of announced prefixes is still rising. Currently we are = nearing 500k. >> Worst case X is 1, meaning every ASN - prefix combination has its own = ROA. >>=20 >> In reality this number will be lower because we can and do aggregate. = But not all implementers will do this. There is something to be said for = *not* fate-sharing ROAs for different prefixes from the same ASN. Also, = most our members are fairly small, and they do not do huge numbers of = announcements individually. Our current aggregation rate -- and we = really try... is: >> 792 ROAs / (2197 IPv4 + 468 IPv6 prefixes) =3D 0.3 ROA/prefix >>=20 >> (see: http://certification-stats.ripe.net/)=20 >>=20 >> For scalability assessment I am not sure though that a factor of = (1/0.3=3D) 3 between this level of aggregation, which seems best case, = and no aggregation, worst case, is that significant in the big picture. = I will use the mean of these two numbers below.. >=20 > Fair enough. I can certainly see the logic here, but if we wound up = with a good way to do the estimation that would be even better, no? :) >=20 > >=20 >> In principal I like the approach to turn this around and define what = an acceptable average delivery rate would be given the total number of = objects and the maximum sync time. But on the other hand this can lead = to rejecting any infrastructure we could come up with.. just set the = goals high enough and nothing will be enough. So I think we should be = cautious here. If there are absolute objective minimal requirements it = would be good to know them. But other than that it may be best to be = pragmatic about it and turn this back.. try to think of other ways and = see if they actually perform significantly better.. >=20 > I can respect this concern, but we really do have to deal with any = systemic/complexity/operational/etc. facets of the system that we have = designed. We need to know how this design is going to behave if we are = going to enshrine it. For example, the above calculations, and ours, = and any derivative formulation would make revoking a key within an hour = seem to be impossible. Is it a day, a week, a month, etc? That may = still be unclear (depending on how we model this), but how can we go any = farther forward without taking a careful look at this design? We must = know if it meets our requirements, and I think measurements like these = help tell us how feasible this will all be. >=20 >> Bearing with the document, if we take the current rsync repositories = as a starting point to see where we are heading without changes: >> =3D It should be noted that fetch times depend on lay-out, = hierarchical layout, allowing recursive, saves a lot of overhead (and = latency) >> =3D We *do* recursive fetches on all current RIR repositories (yes, = we hacked in which base directory to use) >> =3D Testing on my laptop I typically see fetch times of around 20ms = per object, not 628ms >=20 > To be perfectly fair, I just used the #s I found form the BGPSEC = design team's measurements. I was very hesitant to use any particular = set of numbers here. As I'm sure you know, there are opinions about = rsync, what it looks like under load, with asynchrony, repos' = operational uptimes, restarting because of changes in the repository (I = think that was something from your preso), etc. I think you likely know = (much better than me) that if a repo is under heavy load, churn, or just = having an outage, that can cause cache's sync time to suffer. Hence, I = really liked getting real operational data from non-lab measurements. I = actually really feel that data is quite useful. Consider this, you all = (who are running these things) are the experts. If we wind up w/ = ~42,000 repos, they will _not_ all be run as well as you run them. >=20 I understand your concern about many repos, some of them small and = possibly not well managed. But the number of repos is not 1:1 the number of organisations acting as = CAs. We currently see 5 different repositories for the hosted solutions = provided by the RIRs. Non-hosted is being worked on, but so far not done = in the production environment. When this arrives, some non-hosted people = will want to do their own publishing, some others will use a bigger = repository, for example with their RIR, or it may be that 3rd parties = will start providing this service. In any case 42k repositories seems a = bit much, though more than 5 is very likely. >>=20 >> A full fetch based on today's numbers would then take 1M * 20 ms =3D = 20k seconds =3D 330 minutes =3D 5.5 hours =3D 0.25 days. >=20 > Sorry, but I really think this has some problems. First, the numbers = I see in the cited preso are way larger than this, and just for the = object sets we see today. So, I have to say that this calculation = doesn't seem to jive with Randy's numbers. >=20 As you can read in my other emails I agree in general. I don't think = rsync can scale to the levels we need. But the numbers on today's *small* repositories can be improved a lot by = making them hierarchical, or if your validator happens to know that it = can use a higher directory. We do that last thing, rcynic does not. We = made our repository hierarchical though. I think Randy's numbers may be outdated and represent the totals for our = old *flat* rsync repo. This adds a huge amount of latency and setup = overhead. The numbers I got was by just running our validator* and watch the log = for lines like: 16:51:12,883 INFO Prefetching 'rsync://rpki.ripe.net/repository/' 16:52:06,980 INFO Done prefetching for = 'rsync://rpki.ripe.net/repository/' 16:52:26,189 INFO Finished validating RIPE NCC RPKI Root, fetched 4447 = valid Objects So the crypto took 20 seconds. The fetching of 4447 objects took 54 = seconds =3D> 12 ms/object. For Lacnic: 280 objects in 5 seconds =3D> 17 = ms/object from my laptop on a wireless in Amsterdam to South America. *: = http://www.ripe.net/lir-services/resource-management/certification/tools-a= nd-resources >>=20 >> So this is quite a bit faster. Eric, Danny how did you get to the = numbers in table 3? Like I said: I just got some times from validation = runs done on my laptop. We do collect data from our validators 'in the = wild' though.. unfortunately the format of this data (we store a *lot*) = is such that it will take some time for me to dig out more = representative numbers. More time than I have now, but I will try=85. >=20 > The citation at the end of the document comes from Randy. It shows = (MRT?) graphs with these numbers on them. This doesn't include issues = like repos under load from 42,000 caches DNS, outages, etc. I think the = numbers taken from his preso are very charitable, and they are actual = measurements. Moreover, his own experiments showed that replicating = this all inside a ``fairly large scale'' experiment took 660 minutes by = itself... and that was with just 14,000 objects. This actually totally = contradicts the numbers you calculated above. Sorry, I think it just = doesn't add up. >=20 >> Another important factor is the amount of RPs that we can expect.. I = know that Rob and Randy et al are looking into ways to let RPs share = data and be less reliant on central repository servers. On the other = hand if all ASNs run at least 1 rpki validation cache that talks to the = repositories directly then we're looking at 40k clients. If they want = updates, say just 3 times per day, that's 120k requests per day, so = something like 1 - 1.5 per second. >=20 > Again, I used Randy's numbers and even his experiments on 14k objects = on a small topology show it takes twice as long as your global = estimates. >=20 We are talking about different things here: =3D You're looking at how long it takes for 1 RP to get in sync. =3D I was referring to the number of RPs that a repository can expect to = connect per second. >> This slide shows the happy case where all RPs are up to date, and = they just check with the server to see if there are any updates. So = importantly this does not include long running data transfers.. This is = not server grade hardware (just a mac mini) but it's useful as an order = of magnitude indication imo. We see that the total number of RPs just = checking for updates that the server can handle / second depends = linearly on the repository size (it needs to do an O(n) scan). The total = number of concurrent RPs also depends on the repository size. It appears = that some list / index is kept in memory for every connection. Long = story short, we can only process small numbers of RPs per second and = it's quite trivial to end up with too many concurrent RPs pushing the = servers to the memory limited cliff for huge repositories. >=20 > Yeah, I was wondering about that. It felt like it was beyond my = perspective to estimate, so I tried to focus this sizing analysis on a = more general systemic view. I totally appreciate the above comment, but = maybe we could try to model that in another tech-note? I'm happy to try = and help, if you would like. >=20 This is one of the main reasons why I think that rsync won't scale to = the needs we can expect in full deployment. Even if all RIR repositories = are hierarchical, and we don't see a lot of non-hosted CAs publishing = elsewhere. We can not expect to keep getting that number of say 20 = ms/object.. Not without very *huge* investments in setting up some home = grown rsync CDN, spreading them like very busy root servers over the = world. Not something that the non-hosted folk will likely want to do = either btw.. Then regarding non-hosted CAs not publishing in their RIR repository.. I = hadn't really thought of this before, but he advantage of the recursive = rsync is lost here. Say 5 organisations do non-hosted and they all = publish with a 3rd party providing a repository service.. they are = siblings. This repo is flat. So apart from the other things I list in the document I sent yesterday, = I think we have a requirement that the delta protocol is not dependent = on the PKI hierarchy. >>=20 >> It's because of this that I keep going on about: >> =3D We should have a separate delta protocol and notification = mechanism and not rely on rsync for this >> =3D For scalability: >> =3D the hard work (CPU) should be done by the clients, not the = server >> =3D it should be possible to offload connections & memory away = from the server (proxies) >> =3D It makes sense to look at http and scalability of existing CDNs = for delivery >=20 > ibid. >=20 >>=20 >> My gut feeling (yes it's involved a lot today) tells me that this = SHOULD scale a lot better.. For example serving a small update = notification file over http using a CDN, 10ks of request / second, = easy.. Data transfer to RPs.. probably not a whole lot better actually = if you need it all -- though using existing CDNs with a global = infrastructure closer to RPs may help here. But if we have a = notification file that points to small deltas and fetching these small = files is cheap this may actually be a big improvement.. So although it = may take a while to do the first sync, *staying* in sync may actually = perform a lot better. Well.. all this is thought experiment at this = stage. Without a pilot and actual measurements it's hard to be sure. >=20 > I really think these are they types of conversations that we should be = having. Thank you very much for putting your thoughts here! >=20 > Eric --Apple-Mail=_FD196ED6-DEB2-473A-92B8-7D0E16664ADD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Eric,

Sorry for the late = response..

With regards to some of your = comments regarding requirements and ideas for alternative deltas, some = responses inline below, but other than that see the thread where both = Bryan Weber and I talk about our ideas. This is somewhat separate from = the questions about "how a fully deployed RPKI tree would look like", = and "what churn we might see" and "how many connecting RPs, and how = frequent". All that can feed into requirements, but is in essence = another discussion, so I suggest we keep them = separate.


On Nov 16, 2012, at = 10:44 PM, Eric Osterweil <eosterweil@verisign.com> = wrote:


On Nov 16, 2012, at 10:45 AM, Tim Bruijnzeels = wrote:

Hi,

Some more comments on = the numbers and formula..

On Nov 15, 2012, at 5:36 AM, Arturo = Servin <arturo.servin@gmail.com> = wrote:


<snip>

Apart from any signed objects it may publish, every CA = typically has:
=3D 1 certificate published by its = parent

But, as I asked Arturo, would we expect to = have a CA from each parent (i.e. each RIR that an org may allocations = from)?  While this may often still just be 1, it seems important to = note, no?  THat was one reason we had for breaking it apart. =  I'm more than willing to believe that I'm wrong here, but I'd like = to understand how.

=3D 1 manifest
=3D= 1 CRL
=3D 1 GB record (as Arturo said not widely deployed, but let's = throw it in for full deployment)

How does the RPKI = certify ASN allocations?  This is needed to certify router EE certs = (they are tied to an ASN, no?).  Such an AS cert would add another = 1 to the above and make it 5, right?  Otherwise, how does a forward = signing peer associate itself with the ASN, instead of some prefix? =  The ASN isn't necessarily allocated by the same RIR as any of the = allocations, so IP allocation and ASN allocation are orthogonal, = no?

Okay, let me rephrase.. it gets = confusing when talking about organisations as CAs, and CA certificates: = i.e. certificates that have the CA bit set and can sign and publish = other certificates, signed objects etc.

We're = talking 4 objects for each CA Certificate:
=3D 1 CA = Certificate with IPv4, IPv6 and/or ASN
=3D 1 mft
=3D = 1 CRL
=3D 1 GB

An organisation may = have more than one CA certificate:
=3D if it has different = parents and get certificates from more than one
=3D if it has = 'minority space'. For example if one of our members has resources for = which another RIR is the majority holder, then this is not on our normal = certificate. We get a certificate with all such resources signed by the = other RIR, and then we use this to sign an additional certificate for = this member. Certificates can have only one parent, so we can not merge = this.

Regarding the second point: I = haven't done detailed analysis on our data yet. This does affect at = least a portion of our members, so the average number of CA certs per = member organisation is more than 1. I expect that it will not be a *lot* = higher, but like I said I haven't analysed the data = yet.

Having said that, it seems that the = relative component of these, in a sense, boilerplate objects of the = total count, are of a different order than the amount of expected ROAs = and router certificates.


So that's 4 = objects.

During a key roll the CA will have the following = additional objects:
=3D 1 cert published by the parent
=3D 1 = manifest
=3D 1 CRL

Making 7 objects. But typically not all CAs = roll at the same time.

Unless it is an algorithm = rollover, and that is expected to last for years (iirc).  Then this = set would be doubled (plus double the numbers below), = right?


I did not consider = algorithm roll over, but I think you're right.


The number of signed ROAs = and Router certificates does,

And EE certs. =  While 1:1 with ROAs, they require additional (very different) = processing, esp if you start down the road of HSMs.  So, we claimed = this additional operational requirement means that even if you double up = on the downloads, those are still two separate objects.  You have = to manage EE rollover keeping crypto material the same or changing it, = depending on details of the ROA, etc.  That won't come for free, = and (again) needing HSMs makes this a big deal.  So, we really felt = it was important to call this complexity out by counting each. =

I don't understand the use of EE = certs and HSMs here. And I don't see how this can significantly raise = the object count.

In the rpki EE certs can only = be used to sign rpki signed objects and they are embedded in those = objects, not published separately.

All keys in = our online system are protected by HSMs. The keys in EE certificates = even more so: they are generated in an HSM, used only once, and then = forgotten. In the online system the HSM protects against key theft if an = attacker somehow gets access to the database/file system.. The will not = be able to export the keys without access to a quorum of key cards that = protect the internal key of the HSM.

If you = want to use an *offline* key protected by an HSM, then you would have an = additional CA cert (and mft, crl and gb). This is what we do with our TA = at least:

TA (offline) -> signs CA cert for = online use =3D> signs member CAs

The idea = being that if the worst happens to our online system, we can rebuild and = re-issue using the more secure offline key. The hosted members don't = have their own offline key, they are protected by the same one.. = Non-hosted CAs may want to use an intermediate offline certificate. This = adds some overhead: 4 objects per offline key (CA cert, mft, crl, = gb). 

in my opinion, not depend on the number of CAs, but:
=3D = ROA -> The number of announcements seen in BGP * some aggregation = factor (1 / # average prefixes on one ROA)

I, pretty = much agree with this (as I think the tech-note said).  I do, = however have to note that with MOAS, you need multiple ROAs.  Small = point, but worth stating. :)

Yes, a = ROA can have one ASN only, but multiple = prefixes.

We aggregate prefixes for the same = ASN as much as we can on a single ROA. So far we are managing a factor = of around 3 prefixes per ROA. Lacnic is similar. The other RIRs seem to = aggregate a bit less at this time.

See = here:



=3D Router certs -> The = number of ASNs * the number of keys for each = ASN

\times The number of eBGP speakers you mean, = right?

Yes. My model assumes that = this number of speakers can related to the number of = ASNs.

Randy suggested a number of physical bhp = sec speaking routers and that they may have two keys. That may well be a = better model.




So I think a better = model would be to say:

number =           object
#CA =             &n= bsp;   CA cert
#CA =             &n= bsp;   MFT
#CA =             &n= bsp;   CRL
#CA =             &n= bsp;   GB

Ack, we just estimated this = as the # of SIAs, and then varied it from 5 to = 42,000.

5 here would mean the = current RIR TAs without any other signed = content.

The total object count for this = depends on the number of CA certs. See my previous best estimate = below.




#prefixes * X =  ROAs

Yeah, but we didn't guestimate the $X$ = value.  It sounds like we should, but is there any data we can use = to do so?


#ASNs * Y =      Router certs

Ototal  =3D 4 * = #CA + #prefixes * X + #ASNs * Y

Re: the above, I = think this would be

O^Total =3D 4 * #CA + #ASNs + #prefixes + X = * #prefixes + Y * #ASNs

We had called out the need for AS EE cert = (which was not in the equation you outlined), and we felt it was = important to not omit EE certs (if for no other reason than the = operational complexity they bring).


As for the numbers.. this is a bit of a guessing = game.. we just really don't know at this time. We can take our best = guess, but should keep in mind that our best guess is probably off, and = needs re-evaluation in years to come.

100% agree. =  That is why we called this a back-of-the-envelope calculation and = are totally seeking feedback, and are absolutely interested in pushing = revisions as things evolve.


= #CAs

If this were the total number of current members for all = RIRs this number would be around 40k. However, there are also PI users = that are not direct members of the RIRs, and some members will delegate = some of their resources further. For reference I believe that in the = RIPE region we have around 25k PI prefixes. I expect that a lot of the = organisations that hold these resources will be happy to let a = sponsoring RIR member (LIR in our region) manage their ROAs. But not = all.. So I think that in a full deployment world this number may be = significantly bigger. If anyone has any ideas on this, please chime in=85 = Going on nothing more than gut feeling I would say the total could be in = the order of:

=3D 40k RIR members plus 40k self managing PI = holders / children of members?

  80k. =

Really?  I had been thinking that this number = was tied to the origins, but I can see your logic.  It would great = to try and find a way to estimate this, so I'd like to echo your request = for anyone with info to chime in.


#prefixes and 'X'

The number of announced = prefixes is still rising. Currently we are nearing 500k.
Worst case X = is 1, meaning every ASN - prefix combination has its own ROA.

In = reality this number will be lower because we can and do aggregate. But = not all implementers will do this. There is something to be said for = *not* fate-sharing ROAs for different prefixes from the same ASN. Also, = most our members are fairly small, and they do not do huge numbers of = announcements individually. Our current aggregation rate -- and we = really try... is:
 792 ROAs / (2197 IPv4 + 468 IPv6 prefixes) =3D= 0.3 ROA/prefix

(see: http://certification-stats.r= ipe.net/)

For scalability assessment I am not sure though = that a factor of (1/0.3=3D) 3 between this level of aggregation, which = seems best case, and no aggregation, worst case, is that significant in = the big picture. I will use the mean of these two numbers = below..

Fair enough.  I can certainly see the = logic here, but if we wound up with a good way to do the estimation that = would be even better, no? :)

<snip>

In principal I like the approach to turn this around and = define what an acceptable average delivery rate would be given the total = number of objects and the maximum sync time. But on the other hand this = can lead to rejecting any infrastructure we could come up with.. just = set the goals high enough and nothing will be enough. So I think we = should be cautious here. If there are absolute objective minimal = requirements it would be good to know them. But other than that it may = be best to be pragmatic about it and turn this back.. try to think of = other ways and see if they actually perform significantly = better..

I can respect this concern, but we really = do have to deal with any systemic/complexity/operational/etc. facets of = the system that we have designed.  We need to know how this design = is going to behave if we are going to enshrine it.  For example, = the above calculations, and ours, and any derivative formulation would = make revoking a key within an hour seem to be impossible.  Is it a = day, a week, a month, etc?  That may still be unclear (depending on = how we model this), but how can we go any farther forward without taking = a careful look at this design?  We must know if it meets our = requirements, and I think measurements like these help tell us how = feasible this will all be.

Bearing with = the document, if we take the current rsync repositories as a starting = point to see where we are heading without changes:
=3D It should be = noted that fetch times depend on lay-out, hierarchical layout, allowing = recursive, saves a lot of overhead (and latency)
=3D We *do* = recursive fetches on all current RIR repositories (yes, we hacked in = which base directory to use)
=3D Testing on my laptop I typically see = fetch times of around 20ms per object, not 628ms

To = be perfectly fair, I just used the #s I found form the BGPSEC design = team's measurements.  I was very hesitant to use any particular set = of numbers here.  As I'm sure you know, there are opinions about = rsync, what it looks like under load, with asynchrony, repos' = operational uptimes, restarting because of changes in the repository (I = think that was something from your preso), etc.  I think you likely = know (much better than me) that if a repo is under heavy load, churn, or = just having an outage, that can cause cache's sync time to suffer. =  Hence, I really liked getting real operational data from non-lab = measurements.  I actually really feel that data is quite useful. =  Consider this, you all (who are running these things) are the = experts.  If we wind up w/ ~42,000 repos, they will _not_ all be = run as well as you run them.


I = understand your concern about many repos, some of them small and = possibly not well managed.

But the number of = repos is not 1:1 the number of organisations acting as = CAs.

We currently see 5 different repositories = for the hosted solutions provided by the RIRs. Non-hosted is being = worked on, but so far not done in the production environment. When this = arrives, some non-hosted people will want to do their own publishing, = some others will use a bigger repository, for example with their RIR, or = it may be that 3rd parties will start providing this service. In any = case 42k repositories seems a bit much, though more than 5 is very = likely.


A full fetch based on = today's numbers would then take 1M * 20 ms =3D 20k seconds =3D 330 = minutes =3D 5.5 hours =3D 0.25 days.

Sorry, but I = really think this has some problems.  First, the numbers I see in = the cited preso are way larger than this, and just for the object sets = we see today.  So, I have to say that this calculation doesn't seem = to jive with Randy's numbers.


As = you can read in my other emails I agree in general. I don't think rsync = can scale to the levels we = need.


But the numbers on today's = *small* repositories can be improved a lot by making them hierarchical, = or if your validator happens to know that it can use a higher directory. = We do that last thing, rcynic does not. We made our repository = hierarchical though.

I think Randy's numbers = may be outdated and represent the totals for our old *flat* rsync repo. = This adds a huge amount of latency and setup = overhead.

The numbers I got was by just running = our validator* and watch the log for lines = like:
16:51:12,883 INFO  Prefetching 'rsync://rpki.ripe.net/reposito= ry/'
16:52:06,980 INFO  Done prefetching for 'rsync://rpki.ripe.net/reposito= ry/'
16:52:26,189 INFO  Finished = validating RIPE NCC RPKI Root, fetched 4447 valid = Objects

So the crypto took 20 seconds. = The fetching of 4447 objects took 54 seconds =3D> 12 ms/object. For = Lacnic: 280 objects in 5 seconds =3D> 17 ms/object from my = laptop on a wireless in Amsterdam to South = America.




=

So this is = quite a bit faster. Eric, Danny how did you get to the numbers in table = 3? Like I said: I just got some times from validation runs done on my = laptop. We do collect data from our validators 'in the wild' though.. = unfortunately the format of this data (we store a *lot*) is such that it = will take some time for me to dig out more representative numbers. More = time than I have now, but I will try=85.

The = citation at the end of the document comes from Randy.  It shows = (MRT?) graphs with these numbers on them.  This doesn't include = issues like repos under load from 42,000 caches DNS, outages, etc. =  I think the numbers taken from his preso are very charitable, and = they are actual measurements.  Moreover, his own experiments showed = that replicating this all inside a ``fairly large scale'' experiment = took 660 minutes by itself... and that was with just 14,000 objects. =  This actually totally contradicts the numbers you calculated = above.  Sorry, I think it just doesn't add up.

Another important factor is the amount of RPs that we can = expect.. I know that Rob and Randy et al are looking into ways to let = RPs share data and be less reliant on central repository servers. On the = other hand if all ASNs run at least 1 rpki validation cache that talks = to the repositories directly then we're looking at 40k clients. If they = want updates, say just 3 times per day, that's 120k requests per day, so = something like 1 - 1.5 per second.

Again, I used = Randy's numbers and even his experiments on 14k objects on a small = topology show it takes twice as long as your global = estimates.


We are talking about = different things here:
=3D You're looking at how long it takes = for 1 RP to get in sync.
=3D I was referring to the number of = RPs that a repository can expect to connect per = second.

This slide shows the happy case where all RPs are up to = date, and they just check with the server to see if there are any = updates. So importantly this does not include long running data = transfers.. This is not server grade hardware (just a mac mini) but it's = useful as an order of magnitude indication imo. We see that the total = number of RPs just checking for updates that the server can handle / = second depends linearly on the repository size (it needs to do an O(n) = scan). The total number of concurrent RPs also depends on the repository = size. It appears that some list / index is kept in memory for every = connection. Long story short, we can only process small numbers of RPs = per second and it's quite trivial to end up with too many concurrent RPs = pushing the servers to the memory limited cliff for huge = repositories.

Yeah, I was wondering about that. =  It felt like it was beyond my perspective to estimate, so I tried = to focus this sizing analysis on a more general systemic view.  I = totally appreciate the above comment, but maybe we could try to model = that in another tech-note?  I'm happy to try and help, if you would = like.


This is one of the main = reasons why I think that rsync won't scale to the needs we can expect in = full deployment. Even if all RIR repositories are hierarchical, and we = don't see a lot of non-hosted CAs publishing elsewhere. We can not = expect to keep getting that number of say 20 ms/object.. Not without = very *huge* investments in setting up some home grown rsync CDN, = spreading them like very busy root servers over the world. Not something = that the non-hosted folk will likely want to do either = btw..

Then regarding non-hosted CAs not = publishing in their RIR repository.. I hadn't really thought of this = before, but he advantage of the recursive rsync is lost here. Say 5 = organisations do non-hosted and they all publish with a 3rd party = providing a repository service.. they are siblings. This repo is = flat.

So apart from the other things I list in = the document I sent yesterday, I think we have a requirement that the = delta protocol is not dependent on the PKI = hierarchy.




It's because of this that I = keep going on about:
=3D We should have a separate delta protocol and = notification mechanism and not rely on rsync for this
=3D For = scalability:
    =3D the hard work (CPU) should = be done by the clients, not the server
    =3D = it should be possible to offload connections & memory away from the = server (proxies)
=3D It makes sense to look at http and scalability = of existing CDNs for = delivery

ibid.


My= gut feeling (yes it's involved a lot today) tells me that this SHOULD = scale a lot better.. For example serving a small update notification = file over http using a CDN, 10ks of request / second, easy.. Data = transfer to RPs.. probably not a whole lot better actually if you need = it all -- though using existing CDNs with a global infrastructure closer = to RPs may help here. But if we have a notification file that points to = small deltas and fetching these small files is cheap this may actually = be a big improvement.. So although it may take a while to do the first = sync, *staying* in sync may actually perform a lot better. Well.. all = this is thought experiment at this stage. Without a pilot and actual = measurements it's hard to be sure.

I really think = these are they types of conversations that we should be having. =  Thank you very much for putting your thoughts = here!

Eric

= --Apple-Mail=_FD196ED6-DEB2-473A-92B8-7D0E16664ADD-- From kotikalapudi.sriram@nist.gov Tue Nov 27 15:18:14 2012 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 59A6621F86FB for ; Tue, 27 Nov 2012 15:18:14 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNtm0PXCchKH for ; Tue, 27 Nov 2012 15:18:13 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83221F86E7 for ; Tue, 27 Nov 2012 15:18:13 -0800 (PST) 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.2.318.4; Tue, 27 Nov 2012 18:17:33 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 27 Nov 2012 18:15:37 -0500 From: "Sriram, Kotikalapudi" To: "Eric Osterweil (eosterweil@verisign.com)" Date: Tue, 27 Nov 2012 18:17:48 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3C4+fyNHfgNfx1TICABD1n3if3LQKCHcfA Message-ID: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> In-Reply-To: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.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 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 23:18:14 -0000 This email is somewhat long. So I also have a tech-note (pdf) version of this (including the table, figure, etc.). If you prefer to read it in the tech-note format, you may skip the rest of this email and click: http://www.nist.gov/itl/antd/upload/rpki-rsync-delay-technote.pdf Hi Eric, These are comments from Doug and I. We have read your/Danny's tech-note and also followed the email thread. Thank you for the study. We have several comments. A. Consideration of a range of basic rsync fetch time measurements (seconds/object): Regarding the basic rpki rsync measurement of fetch time (seconds per object), there seems to be more evidence that it could be a lot faster than the measurements you have used from Randy's NANOG presentation. Tim has reaffirmed once again in his most recent post ( http://www.ietf.org/mail-archive/web/sidr/current/msg05369.html ) that the fetch times seem to be in the range of 10 to 20 ms per object rather than the 628 ms that you've used. Tim mentions that "Randy's numbers may be outdated and represent the totals for our old *flat* rsync repo. This adds a huge amount of latency and setup overhead." Randy also separately mentioned the updated 10 ms/object measurement in one of his responses to your original post. So we thought it would be good to redo your total RPKI rsync delay numbers considering these lower measurements from Tim/Randy. The resulting table and plot are shown in slides 1 and 2 at this link: http://www.nist.gov/itl/antd/upload/RPKI-rsync-delay.pdf As you can see from Table 1, for the same number of total rpki objects (approx. 1.5M) that you have used, the total rpki rsync delays is only about 4 hours and 8 hours, respectively, for 10 ms/object and 20 ms/object, which are 63 and 31 times smaller, respectively, as compared to the 260 hours number in your table. A plot of the data in Table 1 is shown in Figure 1. Note that both axes are logarithmic. It is also important to note that a running RP fetches only *changed* RPKI objects during each polling instance in normal (steady-state) operation (i.e., whatever the delta happens to be since the previous polling instance). The RP would download *all* RPKI objects rather rarely, e.g., when there is a restart (i.e., failure recovery). So the common fetch delay seen at RPs would be more like seconds or minutes as shown in the lower left corner of plot on slide 2 (or, top of the table in slide 1), corresponding to fetches of 100 to 10,000 changed rpki objects. B. Estimate of RPKI repositories: It is known that 84% of all ASes are stub, and 16% are non-stub. So about 35,280 are stub ASes and only 6,720 are non-stub. The stub ASes are likely to only run simplex bgpsec and they would likely contract out publication point service to their upstream ISP or a third party (Tim also observed this). Even many non-stub ASes can be expected to do the same. So in the end, we think the total number of repositories (what you call SIAs) will be O(100) or O(1000), much less than the 42,000 you have assumed. C. Number of router certs: Observe that per-router certs are not required; certs can be per AS. It remains to be seen what granularity (ranging from per AS to per router) will be used. But, for worse case, if we assume per-router certs in all ASes, then a conservative estimate can be obtained as follows. The stub ASes will have a low average # eBGPSEC routers (say, 2 per AS), and the non-stub ASes will have a relatively larger value for the same (say, 20 per AS). Then the total number of eBGPSEC routers can be estimated at 204,960 (= 20*6720 + 2*35280). You had assumed 420,000 (10 x 42,000). Also, there should be 4 certs per *non-stub* eBGPSEC router; one pair (current and next) for origination prefixes and another pair (current and next) for transit ASes (please see draft-rogaglia-sidr-bgpsec-rollover and draft-sriram-replay-protection-design-discussion). And there should be only 2 certs per *stub* eBGPSEC router since it does not have transit prefixes. That gives us an estimate of 678,720 (=4*20*6720 + 2*2*35280) for the total # router certs. We think this number is conservative (high) but reasonable for now. D. Time for caches to receive updated RPKI info: Quoting from your original post in this thread: > in order to ensure that all caches have received updated information >(such as getting new certificates/CRLs/etc disseminated), >repositories may have to wait about a month (roughly 32 days by our estimates), >just for gatherers to reliably pick up a repo's changes. >Or, a month before a key compromise might get remediated throughout the RPKI system. We find it hard to understand your assumptions and computation here (including the details about this in your tech-note). Here we should focus on fetching only the delta (changes) since the last fetch. From my table (slide 1), the delta fetch should take only seconds to minutes (also noted above in comment A for fetches of RPKI changes up to 1000 or 10,000 objects). If you factor in time-jittered polling from caches once every z hours, then the delay is of the order of z hours for the caches to fetch updated info from the time the info is available at the publication points. Clearly, Randy's NANOG results (60 to 80 minute delay range) are dominated by the one hour jitter on polling gatherers. It seems that the major contributing factor is the polling interval and not the workload at the publication points. E. Characterizing the Size and Shape of RPKI (pointer to a NIST study): Okhee Kim (colleague at NIST) had led an effort to characterize the size and shape of a deployed RPKI a couple of years ago. She based it on measurements of address space registrations (inet-num in RPSL, NetHandle in SWIP), AS registrations (aut-num in RPSL, AS-Handle in SWIP) and route object registrations (in IRRs, RADB). The presentation slides of this study can be accessed at: http://www.nist.gov/itl/antd/upload/RPKI-size-shape-modeling.pdf This work was done almost two years ago and we haven't had a chance to update the results since then. But you may glance through the slides just to get an idea. There are some interesting analyses and insights reported in the presentation. We hope that the comments/analysis offered here are helpful. Sriram From randy@psg.com Tue Nov 27 22:18:17 2012 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 B913521F87DE for ; Tue, 27 Nov 2012 22:18:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIisk6-cyz3S for ; Tue, 27 Nov 2012 22:18:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 47A5521F87C5 for ; Tue, 27 Nov 2012 22:18:17 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TdayN-0004MH-Nr; Wed, 28 Nov 2012 06:18:16 +0000 Date: Wed, 28 Nov 2012 15:18:14 +0900 Message-ID: From: Randy Bush To: Kotikalapudi Sriram In-Reply-To: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 28 Nov 2012 06:18:17 -0000 thank you. this makes a lot more sense than taking well-known exteme worst cases (since fixed) and using them to calculate a so called 'lower bound.' your document looks like responsible engineering and describes about the numbers we have been expecting and talking all along. thanks. randy From russw@riw.us Wed Nov 28 04:40:42 2012 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 A2EF321F84BA for ; Wed, 28 Nov 2012 04:40:42 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Imtl2H2Y0igu for ; Wed, 28 Nov 2012 04:40:42 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id EE30821F841E for ; Wed, 28 Nov 2012 04:40:41 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TdgwS-0001VR-VB for sidr@ietf.org; Wed, 28 Nov 2012 04:40:41 -0800 Message-ID: <50B6064F.8030805@riw.us> Date: Wed, 28 Nov 2012 07:40:47 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sidr@ietf.org References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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, 28 Nov 2012 12:40:42 -0000 > It is also important to note that a running RP fetches only *changed* RPKI objects > during each polling instance in normal (steady-state) operation > (i.e., whatever the delta happens to be since the previous polling instance). > The RP would download *all* RPKI objects rather rarely, e.g., when there is a restart > (i.e., failure recovery). So the common fetch delay seen at RPs would be > more like seconds or minutes as shown in the lower left corner of plot on slide 2 > (or, top of the table in slide 1), corresponding to fetches of 100 to 10,000 changed rpki objects. > > B. Estimate of RPKI repositories: > It is known that 84% of all ASes are stub, and 16% are non-stub. So about 35,280 are stub ASes > and only 6,720 are non-stub. The stub ASes are likely to only run simplex bgpsec and > they would likely contract out publication point service to their upstream ISP or a third party > (Tim also observed this). Even many non-stub ASes can be expected to do the same. > So in the end, we think the total number of repositories (what you call SIAs) > will be O(100) or O(1000), much less than the 42,000 you have assumed. Several points: 1. It is never a good idea to "just right" engineer a system to the "best available numbers from today." Yes, I know the old saw about the glass being neither half empty nor half full, but overengineered --but I also know that virtually every system that counts on a specific traffic pattern, or a specific rate of usage, finds those underlying assumptions completely and totally wrong. 2. If I ran a large network (like a big financial, or major traffic sink), I would never hand my certificate advertisement over to my SP. If I've taken the time and trouble to get my own addresses in order to maintain some level of independence from my provider, I wouldn't undo my independence by using that same provider as the point of advertisement for my routes in a system that can take 4+ hours to synchronize (only in SIDR do we talk about minutes and hours as if they are "short" convergence times). 3. So, I would assume a much higher number than the O(1000) you're assuming here, and bring the number closer to the 40,000 contained in the original process. > C. Number of router certs: > > Observe that per-router certs are not required; certs can be per AS. It remains to be seen > what granularity (ranging from per AS to per router) will be used. But, for worse case, > if we assume per-router certs in all ASes, then a conservative estimate can be obtained as follows. > The stub ASes will have a low average # eBGPSEC routers (say, 2 per AS), > and the non-stub ASes will have a relatively larger value for the same (say, 20 per AS). > Then the total number of eBGPSEC routers can be estimated at 204,960 (= 20*6720 + 2*35280). > You had assumed 420,000 (10 x 42,000). Also, there should be 4 certs per *non-stub* eBGPSEC router; > one pair (current and next) for origination prefixes and another pair (current and next) for transit ASes > (please see draft-rogaglia-sidr-bgpsec-rollover and draft-sriram-replay-protection-design-discussion). > And there should be only 2 certs per *stub* eBGPSEC router since it does not have transit prefixes. > That gives us an estimate of 678,720 (=4*20*6720 + 2*2*35280) for the total # router certs. > We think this number is conservative (high) but reasonable for now. I don't think this is right, either --you're assuming a "stub AS" will only have two routers, which is completely off base. The smallest stub AS will have two routers, larger ones will have more as they scale upwards. Several large enterprise networks I've worked on have at least 20, if not more, edge routers across a single AS, into multiple providers. The size of a transit is also questionable --I can't imagine an average of 20 edge routers for a transit provider. Are there really so many 2 and 3 edge router transits that it would offset AT&T, Level 3, and many others we know must be on the order of hundreds of edges? 204k eBGP speakers is a gross understimate of the size of the Internet at large. Russ -- <>< riwhite@verisign.com russw@riw.us From internet-drafts@ietf.org Wed Nov 28 06:11:35 2012 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 411BF21F8814; Wed, 28 Nov 2012 06:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOlg2-GVapoP; Wed, 28 Nov 2012 06:11:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB00E21F87F6; Wed, 28 Nov 2012 06:11:34 -0800 (PST) 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: 4.36 Message-ID: <20121128141134.29910.77561.idtracker@ietfa.amsl.com> Date: Wed, 28 Nov 2012 06:11:34 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-03.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, 28 Nov 2012 14:11:35 -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 Group= of the IETF. Title : Definitions of Managed Objects for the RPKI-Router Proto= col Author(s) : Randy Bush Bert Wijnen Keyur Patel Michael Baer Filename : draft-ietf-sidr-rpki-rtr-protocol-mib-03.txt Pages : 23 Date : 2012-11-28 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-protocol-mib-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From turners@ieca.com Wed Nov 28 07:51:14 2012 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 8E99821F8869 for ; Wed, 28 Nov 2012 07:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6U6OylLBsi9 for ; Wed, 28 Nov 2012 07:51:14 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.212.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67221F849F for ; Wed, 28 Nov 2012 07:51:14 -0800 (PST) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 7B73B9356F20F; Wed, 28 Nov 2012 09:51:13 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 5ED8D9356F193 for ; Wed, 28 Nov 2012 09:51:13 -0600 (CST) Received: from [108.45.19.185] (port=64793 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tdjur-0000JE-2X for sidr@ietf.org; Wed, 28 Nov 2012 09:51:13 -0600 Message-ID: <50B632F0.8080006@ieca.com> Date: Wed, 28 Nov 2012 10:51:12 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <20121128141134.29910.77561.idtracker@ietfa.amsl.com> In-Reply-To: <20121128141134.29910.77561.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:64793 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-03.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, 28 Nov 2012 15:51:14 -0000 The MIB doctors approved a change to MIB security considerations: https://www.ietf.org/mail-archive/web/mib-doctors/current/msg01369.html change here: https://www.ietf.org/mail-archive/web/mib-doctors/current/msg01368.html Need to make the following change in the security considerations: OLD SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). NEW SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. and add some new informative references: [RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004. [RFC5591] Harrington, D., and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", June 2009. [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", June 2009. [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", July 2011. spt From bertietf@bwijnen.net Wed Nov 28 07:55:59 2012 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 B92D821F855A for ; Wed, 28 Nov 2012 07:55:59 -0800 (PST) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15I5XUpp8aa4 for ; Wed, 28 Nov 2012 07:55:58 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 833B121F8521 for ; Wed, 28 Nov 2012 07:55:58 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TdjzP-0007bT-Aa; Wed, 28 Nov 2012 16:55:57 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TdjzO-0006Ou-UN; Wed, 28 Nov 2012 16:55:55 +0100 Message-ID: <50B6340A.1060000@bwijnen.net> Date: Wed, 28 Nov 2012 16:55:54 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sean Turner References: <20121128141134.29910.77561.idtracker@ietfa.amsl.com> <50B632F0.8080006@ieca.com> In-Reply-To: <50B632F0.8080006@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121128 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a4d1f60df9d990327aebcbb02287adcf Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-03.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, 28 Nov 2012 15:55:59 -0000 Mmm.. seems I even forget about such updates. OK, I agree we should make that change. Randy (Bush) do you want me to do that or will you do it? Bert On 11/28/12 4:51 PM, Sean Turner wrote: > The MIB doctors approved a change to MIB security considerations: > > https://www.ietf.org/mail-archive/web/mib-doctors/current/msg01369.html > change here: > https://www.ietf.org/mail-archive/web/mib-doctors/current/msg01368.html > > Need to make the following change in the security considerations: > > OLD > > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPsec), > even then, there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the objects > in this MIB module. > > It is RECOMMENDED that implementers consider the security features as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). > > NEW > > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPsec), > there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete) the objects > in this MIB module. > > Implementations MUST provide the security features described by the > SNMPv3 framework (see [RFC3410]), including full support for > authentication and privacy via the User-based Security Model (USM) > [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations > MAY also provide support for the Transport Security Model (TSM) > [RFC5591] in combination with a secure transport such as SSH > [RFC5592] or TLS/DTLS [RFC6353]. > > and add some new informative references: > > [RFC3414] Blumenthal, U., and B. Wijnen, > "User-based Security Model (USM) for version 3 of the > Simple Network Management Protocol (SNMPv3)", RFC 3414, > December 2002. > > [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, > "The Advanced Encryption Standard (AES) Cipher > Algorithm in the SNMP User-based Security Model", > RFC 3826, June 2004. > > [RFC5591] Harrington, D., and W. Hardaker, > "Transport Security Model for the Simple Network > Management Protocol (SNMP)", June 2009. > > [RFC5592] Harrington, D., Saloway, J., and W. Hardaker, > "Secure Shell Transport Model for the Simple Network > Management Protocol (SNMP)", June 2009. > > [RFC6353] W. Hardaker, "Transport Layer Security (TLS) Transport > Model for the Simple Network Management Protocol (SNMP)", > July 2011. > > spt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Wed Nov 28 13:32:31 2012 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 3BBAB21F888F; Wed, 28 Nov 2012 13:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3luWM+75G9E; Wed, 28 Nov 2012 13:32:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9550A21F84BB; Wed, 28 Nov 2012 13:32:30 -0800 (PST) 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: 4.36 Message-ID: <20121128213230.2653.30224.idtracker@ietfa.amsl.com> Date: Wed, 28 Nov 2012 13:32:30 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-04.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, 28 Nov 2012 21:32:31 -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 Group= of the IETF. Title : Definitions of Managed Objects for the RPKI-Router Proto= col Author(s) : Randy Bush Bert Wijnen Keyur Patel Michael Baer Filename : draft-ietf-sidr-rpki-rtr-protocol-mib-04.txt Pages : 24 Date : 2012-11-28 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-protocol-mib-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From randy@psg.com Wed Nov 28 13:35:47 2012 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 C819921F84C6 for ; Wed, 28 Nov 2012 13:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AaXhTn0RkpY for ; Wed, 28 Nov 2012 13:35:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBBC21F84C1 for ; Wed, 28 Nov 2012 13:35:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TdpII-0006o8-7w; Wed, 28 Nov 2012 21:35:46 +0000 Date: Thu, 29 Nov 2012 06:35:44 +0900 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: <50B632F0.8080006@ieca.com> References: <20121128141134.29910.77561.idtracker@ietfa.amsl.com> <50B632F0.8080006@ieca.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-protocol-mib-03.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, 28 Nov 2012 21:35:47 -0000 > Need to make the following change in the security considerations: thanks for making the hack easy randy From wjhns1@hardakers.net Thu Nov 29 13:14:18 2012 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 4B27B21F8C3D for ; Thu, 29 Nov 2012 13:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBRoyqtDNLHV for ; Thu, 29 Nov 2012 13:14:17 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id D480F21F8C3A for ; Thu, 29 Nov 2012 13:14:17 -0800 (PST) Received: from localhost (unknown [50.13.187.159]) by mail.hardakers.net (Postfix) with ESMTPSA id 4963F52 for ; Thu, 29 Nov 2012 13:14:17 -0800 (PST) From: Wes Hardaker To: sidr@ietf.org In-Reply-To: <20121013031003.29504.80256.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Fri, 12 Oct 2012 20:10:03 -0700") Date: Thu, 29 Nov 2012 10:18:53 -0800 Message-ID: <0lmwy0gtma.fsf@wjh.hardakers.net> References: <20121013031003.29504.80256.idtracker@ietfa.amsl.com> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [sidr] sidrI-D Action: draft-ietf-sidr-rpki-grandparenting-00.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, 29 Nov 2012 21:14:18 -0000 internet-drafts@ietf.org writes: > There are circumstances in RPKI operations where a resource holder's > parent may not be able to, or may not choose to, facilitate full and > proper registration of the holder's data. As in real life, the > holder may form a relationship with their grandparent who is willing > to aid the grandchild. This document describes simple procedures for > doing so. It's probably worth documenting that the other option for A in the draft is to split C's space into two sub-delegations, with C's consent, and give G a new delegation for it's space directly under A so there is no conflict of G's address space being controlled by both C and G where their relationship has clearly dissolved. Yes, that really was one sentence. -- Wes Hardaker SPARTA, Inc. From kotikalapudi.sriram@nist.gov Thu Nov 29 16:41:28 2012 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 AC39E21F883F for ; Thu, 29 Nov 2012 16:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpIExwqRxtO5 for ; Thu, 29 Nov 2012 16:41:28 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 75CD221F8810 for ; Thu, 29 Nov 2012 16:41:24 -0800 (PST) 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.2.318.4; Thu, 29 Nov 2012 19:40:44 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 29 Nov 2012 19:38:41 -0500 From: "Sriram, Kotikalapudi" To: Russ White , "sidr@ietf.org" Date: Thu, 29 Nov 2012 19:40:59 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3NZUiapUDqeANNT8GVwByCFIsY1wBI2zlg Message-ID: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50B6064F.8030805@riw.us> In-Reply-To: <50B6064F.8030805@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" MIME-Version: 1.0 Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 00:41:28 -0000 >can take 4+ hours to synchronize (only in SIDR do we talk about minutes and >hours as if they are "short" >convergence times). As has been noted before, a *running* rpki cache server has low delays at each polling instance (see top of Table 1 for 100 up to 10,000 *changed* RPKI objects). For a *new* rpki cache server that is starting up and fetching all 1.5 million objects, the rpki rsync delay is larger (4 hours). Routers would not be using this *new* server until it signals it is ready to serve. In the meanwhile, routers are being served by other *up and running* rpki cache servers. > >3. So, I would assume a much higher number than the O(1000) you're assuming >here, and bring the number closer to the 40,000 contained in the original >process. As Eric has also shown, it makes a difference of only about 10% in the total rpki rsync delay when you increase the # SIAs (repositories) from 5 to 42,000. BTW, just to note here again Tim's comment to Eric about this, "In any case 42k repositories seems a bit much, though more than 5 is very likely." > >> C. Number of router certs: >> --snip -- >> That gives us an estimate of 678,720 (=4*20*6720 + 2*2*35280) for the total ># router certs. >> We think this number is conservative (high) but reasonable for now. > >I don't think this is right, either --you're assuming a "stub AS" will only have two >routers, which is completely off base. The smallest stub AS will have two >routers, larger ones will have more as they scale upwards. Several large >enterprise networks I've worked on have at least 20, if not more, edge routers >across a single AS, into multiple providers. > >The size of a transit is also questionable --I can't imagine an average of 20 edge >routers for a transit provider. Are there really so many 2 and 3 edge router >transits that it would offset AT&T, Level 3, and many others we know must be >on the order of hundreds of edges? > >204k eBGP speakers is a gross understimate of the size of the Internet at large. Would you like to share a ball park number you know that is a better estimate for the # eBGP speakers? It is a parameter in the model; so easy to rerun. Sriram From Sandra.Murphy@sparta.com Fri Nov 30 06:57:59 2012 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 5A03621F8B15 for ; Fri, 30 Nov 2012 06:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7pB5qIgYUsr for ; Fri, 30 Nov 2012 06:57:59 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id DF33221F8598 for ; Fri, 30 Nov 2012 06:57:58 -0800 (PST) Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id qAUEvvUK031355 for ; Fri, 30 Nov 2012 06:57:57 -0800 Received: from Hermes.columbia.ads.sparta.com ([10.62.56.107]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id qAUEvv37028702 for ; Fri, 30 Nov 2012 06:57:57 -0800 Received: from HERMES.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5]) by Hermes.columbia.ads.sparta.com ([fe80::e4a8:a383:2128:c0e5%19]) with mapi id 14.01.0379.000; Fri, 30 Nov 2012 09:57:57 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes from IETF85 uploaded Thread-Index: Ac3PCenjxY2AUZ/kQhCYDP6qWgtzwQ== Date: Fri, 30 Nov 2012 14:57:57 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63B6FBF2F@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] minutes from IETF85 uploaded 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 Nov 2012 14:57:59 -0000 I have uploaded minutes to the IETF85 site. Minutes were taken in the ethe= rpad tool and I took them from there.=0A= =0A= Please review the minutes for needed changes.=0A= =0A= --Sandy, speaking as co-chair= From iesg-secretary@ietf.org Fri Nov 30 07:38:36 2012 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 07F9721F8B25; Fri, 30 Nov 2012 07:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO4AW6uQO0ac; Fri, 30 Nov 2012 07:38:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7760B21F8551; Fri, 30 Nov 2012 07:38:35 -0800 (PST) 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: 4.36 Message-ID: <20121130153835.30764.59524.idtracker@ietfa.amsl.com> Date: Fri, 30 Nov 2012 07:38:35 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Algorithm Agility Procedure for RPKI.) 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: Fri, 30 Nov 2012 15:38:36 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Algorithm Agility Procedure for RPKI.' as 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 2012-12-14. 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 This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility/ballot/ No IPR declarations have been submitted directly on this I-D. From russw@riw.us Fri Nov 30 08:50:05 2012 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 4967C21F8B62 for ; Fri, 30 Nov 2012 08:50:05 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jknPajlCbRq for ; Fri, 30 Nov 2012 08:50:04 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEE121F8B48 for ; Fri, 30 Nov 2012 08:50:04 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TeTmt-00021n-E0; Fri, 30 Nov 2012 08:50:03 -0800 Message-ID: <50B8E3C4.6020901@riw.us> Date: Fri, 30 Nov 2012 11:50:12 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50B6064F.8030805@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 16:50:05 -0000 >> can take 4+ hours to synchronize (only in SIDR do we talk about minutes and >> hours as if they are "short" >> convergence times). > > As has been noted before, a *running* rpki cache server has low delays at each > polling instance (see top of Table 1 for 100 up to 10,000 *changed* RPKI objects). > For a *new* rpki cache server that is starting up and fetching all 1.5 million objects, > the rpki rsync delay is larger (4 hours). Routers would not be using this *new* server > until it signals it is ready to serve. In the meanwhile, routers are being served > by other *up and running* rpki cache servers. So the routing system is being secured by information that is at least several minutes behind actual topology changes. What impact will this have on the overall number of updates, speed of reachability, etc. --and what's the business impact? We don't live in a world of minutes and hours any longer. > Would you like to share a ball park number you know that is a better estimate > for the # eBGP speakers? It is a parameter in the model; so easy to rerun. I would guess at least 6 per stub as. For transit AS' --if you look at the maps on navigators.com, you'll find every ISP on there shows at least 50 interconnect points, each of which is at least 1 router --and this doesn't count private peering points. So I would say 50 is a minimal number, and something larger is probably more likely. But again, this all predicated on current numbers --building scaling around, "this is what we have today," is a recipe for disaster within a matter of years. Of course, SIDR has never cared about what happens ten years from now, since that's beyond the time horizon for the actual goals at hand. Russ From iesg-secretary@ietf.org Fri Nov 30 09:02:38 2012 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 B88B021F8B89; Fri, 30 Nov 2012 09:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP33gr3kie+b; Fri, 30 Nov 2012 09:02:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588C621F8B60; Fri, 30 Nov 2012 09:02:38 -0800 (PST) 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: 4.36 Message-ID: <20121130170238.4029.37203.idtracker@ietfa.amsl.com> Date: Fri, 30 Nov 2012 09:02:38 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties) to Informational RFC 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: Fri, 30 Nov 2012 17:02:38 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties' as Informational RFC 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 2012-12-14. 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 This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-usecases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-usecases/ballot/ No IPR declarations have been submitted directly on this I-D. From dougm@nist.gov Fri Nov 30 10:12:46 2012 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 6B1DA21F8B34 for ; Fri, 30 Nov 2012 10:12:46 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqTcH2LF840o for ; Fri, 30 Nov 2012 10:12:45 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 549B721F8B1F for ; Fri, 30 Nov 2012 10:12:42 -0800 (PST) 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.2.318.4; Fri, 30 Nov 2012 13:12:19 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 30 Nov 2012 13:10:15 -0500 From: "Montgomery, Douglas" To: Russ White , "Sriram, Kotikalapudi" Date: Fri, 30 Nov 2012 13:10:14 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3PJfHkLnumi5sPRei7teuicsM/tA== Message-ID: In-Reply-To: <50B8E3C4.6020901@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 18:12:46 -0000 On 11/30/12 11:50 AM, "Russ White" wrote: > >>> can take 4+ hours to synchronize (only in SIDR do we talk about >>>minutes and >>> hours as if they are "short" >>> convergence times). >> >> As has been noted before, a *running* rpki cache server has low delays >>at each >> polling instance (see top of Table 1 for 100 up to 10,000 *changed* >>RPKI objects). >> For a *new* rpki cache server that is starting up and fetching all 1.5 >>million objects, >> the rpki rsync delay is larger (4 hours). Routers would not be using >>this *new* server >> until it signals it is ready to serve. In the meanwhile, routers are >>being served >> by other *up and running* rpki cache servers. > >So the routing system is being secured by information that is at least >several minutes behind actual topology changes. What impact will this >have on the overall number of updates, speed of reachability, etc. --and >what's the business impact? > >We don't live in a world of minutes and hours any longer. RPKI does not reflect run-time changes in topology. It is a declarative system in which one would expect information to typically change with human driven processes (e.g., allocation of addresses, establishment of peering relationships, etc.) Routing itself can proceed at the speed of light. > >> Would you like to share a ball park number you know that is a better >>estimate >> for the # eBGP speakers? It is a parameter in the model; so easy to >>rerun. > >I would guess at least 6 per stub as. > >For transit AS' --if you look at the maps on navigators.com, you'll find >every ISP on there shows at least 50 interconnect points, each of which >is at least 1 router --and this doesn't count private peering points. So >I would say 50 is a minimal number, and something larger is probably >more likely. > >But again, this all predicated on current numbers --building scaling >around, "this is what we have today," is a recipe for disaster within a >matter of years. > >Of course, SIDR has never cared about what happens ten years from now, >since that's beyond the time horizon for the actual goals at hand. ? SIDR has never cared about what happens in the near term ... Where did you get this idea. > >Russ >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Fri Nov 30 10:23:36 2012 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 6ECF321F8AF5 for ; Fri, 30 Nov 2012 10:23:36 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIEBFIuljLn8 for ; Fri, 30 Nov 2012 10:23:36 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1002C21F8983 for ; Fri, 30 Nov 2012 10:23:36 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TeVFP-0008Me-5c; Fri, 30 Nov 2012 10:23:35 -0800 Message-ID: <50B8F9AB.8090709@riw.us> Date: Fri, 30 Nov 2012 13:23:39 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 18:23:36 -0000 >> We don't live in a world of minutes and hours any longer. > > RPKI does not reflect run-time changes in topology. It is a declarative > system in which one would expect information to typically change with > human driven processes (e.g., allocation of addresses, establishment of > peering relationships, etc.) > > Routing itself can proceed at the speed of light. Given BGP is actually mostly about policy, what you're saying is: "Policy (routing) can move at the speed of light, even though policy (human action) can't/won't." Somehow I find this to be a distinction without a difference. The RPKI needs to react in seconds, rather than minutes, hours, or days. Russ From christopher.morrow@gmail.com Fri Nov 30 10:37:10 2012 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 55CBB21F8A9F for ; Fri, 30 Nov 2012 10:37:10 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gvTHbsMfQup for ; Fri, 30 Nov 2012 10:37:10 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6C21F8976 for ; Fri, 30 Nov 2012 10:37:09 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id fl11so12026vcb.15 for ; Fri, 30 Nov 2012 10:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aUydJK/mAkoSdYbq6UcwDRX7L3BXKAJ95Ejcl4KjNYU=; b=Y/ei1cyBD0EYuWhqtuQyUp/qSMl7s9Ud6t0tKFqt0OP1I9UxEoyxgXIs/BDwCeoZYP 6Fhahiuy/SF4ZmGT4LaVF9P1Ct4F9PZf6/OTxuBZo0Myj4xjcFX4JPEfGoEqCwlQNvAo 6inHLoOjDz5izXmsddOnfjInS/gtF2UEW9DE/tUdLFRCG3g3K5f4DAU2v562afHf8vmm LBu2Xu9r3c21xP6rM8EvJxpFziTIZeGuP7UJx/TNGe2X73j8f259uM7mFWcnje5gNhL/ hBpvZlNOCaJMaRTyvdCrrvR28U+rQNXxeDH/uyzz3Mck7IlW2xW7vYbu+1/oGpKmPc5l ap6A== MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr1568397vdv.20.1354300628705; Fri, 30 Nov 2012 10:37:08 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.58.205.148 with HTTP; Fri, 30 Nov 2012 10:37:08 -0800 (PST) In-Reply-To: <50B8E3C4.6020901@riw.us> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50B6064F.8030805@riw.us> <50B8E3C4.6020901@riw.us> Date: Fri, 30 Nov 2012 13:37:08 -0500 X-Google-Sender-Auth: olG9mqwd4WyuYbNxeY72aLzNzZ4 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 18:37:10 -0000 On Fri, Nov 30, 2012 at 11:50 AM, Russ White wrote: > So the routing system is being secured by information that is at least > several minutes behind actual topology changes. What impact will this > have on the overall number of updates, speed of reachability, etc. --and > what's the business impact? You mean ROA updates, for instance... or router/asn ee-cert, right? should the expectation be that you can start announcing and using a prefix in seconds or is a more planned process to be expected? From dougm@nist.gov Fri Nov 30 10:37:39 2012 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 E560721F8958 for ; Fri, 30 Nov 2012 10:37:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 592K5-RBGx1r for ; Fri, 30 Nov 2012 10:37:38 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3A34521F8952 for ; Fri, 30 Nov 2012 10:37:38 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 30 Nov 2012 13:36:55 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 30 Nov 2012 13:37:15 -0500 From: "Montgomery, Douglas" To: Russ White Date: Fri, 30 Nov 2012 13:37:04 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3PKWO6+3n4DkHpQAW0b+cgPcU62g== Message-ID: In-Reply-To: <50B8F9AB.8090709@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 18:37:39 -0000 On 11/30/12 1:23 PM, "Russ White" wrote: > >>> We don't live in a world of minutes and hours any longer. >> >> RPKI does not reflect run-time changes in topology. It is a >>declarative >> system in which one would expect information to typically change with >> human driven processes (e.g., allocation of addresses, establishment of >> peering relationships, etc.) >> >> Routing itself can proceed at the speed of light. > >Given BGP is actually mostly about policy, what you're saying is: > >"Policy (routing) can move at the speed of light, even though policy >(human action) can't/won't." > >Somehow I find this to be a distinction without a difference. That is not what I was saying ... And it seems a bit confused. Policy never has, nor likely never will move at the speed of light. Policy by definition is a reflection of human intent. Routing moves at the speed of bits, while passing through what are typically relatively static policy filters and functions. Not sure what you are referring to, unless it was just a fun semantic transformation, when you say policy moves at the speed of light. > >The RPKI needs to react in seconds, rather than minutes, hours, or days. Based upon what analysis or requirement? dougm > >Russ From christopher.morrow@gmail.com Fri Nov 30 10:38:20 2012 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 DD21421F8958 for ; Fri, 30 Nov 2012 10:38:20 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d89asse+GuUb for ; Fri, 30 Nov 2012 10:38:20 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 553B721F8952 for ; Fri, 30 Nov 2012 10:38:20 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so11177831vbb.17 for ; Fri, 30 Nov 2012 10:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wAdRIxNzPaVEHoEI8Y65i6M628aqdpAkTF7d4Ks3GCg=; b=yeH13TFGLrRJlMV+b4FfS8U2rB3rj/AU1DhkN40HZ5OYe2zKOfG9vzezKQADCkXgzZ 5RtswFLXcnNLkbIeiQh1CF74ZeLWTMMe6xMbmN+PzeOslxxkPEr3nIj62ZKj0f0myts4 z+SOYM/udTfG8kDKOQKWveKPwVmMVbRdTgnSLCGVijvJ0vwHrpaOjcJd2iOe2qXrsMaI Rqr7xITNm021PJeDlMTRTEJLaFmx5pdXQDrt/6wn5YoYAs9Y2//lY1MN6weKwhfL2RHD f1EIvhJmHmRv5WI6mWlv5xHqSL6ljGzBhgq/IcbgAmDBVLJsTRrb9c0EhMvwCY8xHs1d Hr9Q== MIME-Version: 1.0 Received: by 10.52.27.138 with SMTP id t10mr1531809vdg.81.1354300699803; Fri, 30 Nov 2012 10:38:19 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.58.205.148 with HTTP; Fri, 30 Nov 2012 10:38:19 -0800 (PST) In-Reply-To: <50B8E3C4.6020901@riw.us> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50B6064F.8030805@riw.us> <50B8E3C4.6020901@riw.us> Date: Fri, 30 Nov 2012 13:38:19 -0500 X-Google-Sender-Auth: YP4j8oL3KS7P2EwW8-jCdzA6UC0 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 18:38:21 -0000 On Fri, Nov 30, 2012 at 11:50 AM, Russ White wrote: > Of course, SIDR has never cared about what happens ten years from now, > since that's beyond the time horizon for the actual goals at hand. this isn't a particularly useful line of commentary, could we stick with the problem we're discussion and leave editorializing out? From danny@tcb.net Fri Nov 30 11:00:46 2012 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 5767321F89A7 for ; Fri, 30 Nov 2012 11:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36lThBTGX9Mt for ; Fri, 30 Nov 2012 11:00:45 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id AB37121F89A2 for ; Fri, 30 Nov 2012 11:00:45 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 244A723AB for ; Fri, 30 Nov 2012 19:00:45 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id C35F922BB; Fri, 30 Nov 2012 12:00:44 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Fri, 30 Nov 2012 14:00:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Nov 30 12:00:45 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50b9025d199633763117863 X-DSPAM-Factors: 27, 2012+#+#+37, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Mime-Version*Message+#+v1283, 0.01000, at+#+37, 0.01000, 1+#+PM, 0.01000, 2012+at, 0.01000, to+#+in, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, as+an, 0.01000, to+#+#+#+in, 0.01000, routing+system, 0.01000, not+have, 0.01000, Mime-Version*Apple+#+framework, 0.01000, a+#+#+#+is, 0.01000, I+have, 0.01000, needs+to, 0.01000, Cc*wg+#+sidr, 0.01000, that+#+the, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, that+#+not, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000, 37+#+#+#+wrote, 0.01000, Nov+#+#+#+1, 0.01000 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:00:46 -0000 On Nov 30, 2012, at 1:37 PM, Montgomery, Douglas wrote: >>=20 >> The RPKI needs to react in seconds, rather than minutes, hours, or = days. >=20 > Based upon what analysis or requirement? Good question Doug.=20 Today I have a requirement as an operator to mitigate DDoS attacks in = seconds to single digit minutes and this commonly requires routing = system changes that may not have been envisioned beforehand - hours and = days of delay [imposed by a system that does little more than control = what's routed - not if it's routed in a way I believe is secure] breaks = this. Where are the requirements that informed the current design? -danny From russw@riw.us Fri Nov 30 11:02:02 2012 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 E428A21F8B29 for ; Fri, 30 Nov 2012 11:02:02 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjIg82Ml2SSE for ; Fri, 30 Nov 2012 11:02:02 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEDC21F89A2 for ; Fri, 30 Nov 2012 11:02:02 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TeVqc-000296-2H; Fri, 30 Nov 2012 11:02:02 -0800 Message-ID: <50B902B2.8060804@riw.us> Date: Fri, 30 Nov 2012 14:02:10 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Montgomery, Douglas" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:02:03 -0000 > Policy never has, nor likely never will move at the speed of light. > Policy by definition is a reflection of human intent. And humans don't have intent that moves at the speed of light? >> The RPKI needs to react in seconds, rather than minutes, hours, or days. > > Based upon what analysis or requirement? That people expect their networks to react within seconds to change, not minutes, hours, or days. What do you base your requirement that it's okay for the routing system to react in minutes on? Are you certain those requirements will hold into the future, or do you think convergence speed requirements (including policy propagation) will increase? Russ From danny@tcb.net Fri Nov 30 11:16:32 2012 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 9619F21F87AB for ; Fri, 30 Nov 2012 11:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quss6tk5kRJr for ; Fri, 30 Nov 2012 11:16:32 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 295C021F8717 for ; Fri, 30 Nov 2012 11:16:32 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id C207223AD for ; Fri, 30 Nov 2012 19:16:31 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 710D122BB; Fri, 30 Nov 2012 12:16:31 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Fri, 30 Nov 2012 14:16:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Nov 30 12:16:31 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50b9060f199635350920104 X-DSPAM-Factors: 27, Cc*sidr+#+#+#+ietf.org, 0.01000, and+#+#+#+these, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 1+#+PM, 0.01000, 2012+at, 0.01000, to+#+in, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, routing+security, 0.01000, that+I, 0.01000, may+#+be, 0.01000, Mime-Version*Apple+#+framework, 0.01000, RPKI+#+not, 0.01000, Cc*wg+#+sidr, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Cc*sidr+#+list, 0.01000, Cc*wg+list, 0.01000, Nov+#+#+#+1, 0.01000, is+a, 0.01000, From*Danny+#+danny, 0.01000, at+1, 0.01000, From*Danny+#+#+tcb.net, 0.01000, not+a, 0.01000, Mime-Version*framework+v1283, 0.01000, 2012+#+#+#+PM, 0.01000 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:16:32 -0000 On Nov 30, 2012, at 1:10 PM, Montgomery, Douglas wrote: > RPKI does not reflect run-time changes in topology. It is a = declarative > system in which one would expect information to typically change with > human driven processes (e.g., allocation of addresses, establishment = of > peering relationships, etc.) It's not a question of speed, it's a question of reaction time. As _one example, I know of many commercial DDoS products and services = that automate these processes, RPKI as designed hampers our ability to = respond in less than hours, and BGPSEC likely much longer. How do I = rationalize this when it doesn't even fix things that I consider routing = security issues (e.g., the Google sanfu weeks back?)? Here the cure may well be worse than the disease. Mefloquine, anyone? -danny= From arturo.servin@gmail.com Fri Nov 30 11:38:00 2012 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 A5FC621F8AC8 for ; Fri, 30 Nov 2012 11:38:00 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkIPpXLdk-kW for ; Fri, 30 Nov 2012 11:38:00 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8CC21F8AC3 for ; Fri, 30 Nov 2012 11:37:59 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so133540ggn.31 for ; Fri, 30 Nov 2012 11:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0bx9JvODGIwLTHCiXhuPedXwDqEuKPdwEuYEcKaLDGQ=; b=zA3NxSGO0D8T0VEahR/TEshRae43xNZDVLgcpPu+HRMFKxBhzB0ruWWHS2lGFris1o 1OO9dsvhFk5ovTLCRHSq8A9LjfCfpO9k56MHDDGvaoyl+O22IJrwNIyDtD66csEdDzEp SEgaKvta1qCDk6LqUe4x2bkTXIpsGo8F9pxaZOkWS5jIZMBELhy5pl7PIfrByMnE0liw 1yTmJGzg5PeBzq0O1xpA5I0xxzlUOfZUCZmqeQIL1mY8eNITy7mceTY5kXMlYkcv/Pc7 7TvW4SZtuAmoXDpN0OwC4IwUXe6Y+NZHAHYWdPON0akmRpjb/Loh/L1nYGV1L+EACCcD j8MA== Received: by 10.101.28.40 with SMTP id f40mr767764anj.85.1354304279020; Fri, 30 Nov 2012 11:37:59 -0800 (PST) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:a942:13e8:af75:905a]) by mx.google.com with ESMTPS id e24sm5796234yhh.4.2012.11.30.11.37.55 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 11:37:57 -0800 (PST) Message-ID: <50B90B13.1000502@gmail.com> Date: Fri, 30 Nov 2012 17:37:55 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Danny McPherson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:38:00 -0000 If you only have one cache, and this fails, and you need to restore the whole repository(ies): then yes. You have a problem. But if you have two cache servers, perhaps you would not even notice while the second one is getting the whole repository(ies). But I am not sure if I am following your and Russ rationale. Regards, as On 30/11/2012 17:16, Danny McPherson wrote: > > On Nov 30, 2012, at 1:10 PM, Montgomery, Douglas wrote: > >> RPKI does not reflect run-time changes in topology. It is a declarative >> system in which one would expect information to typically change with >> human driven processes (e.g., allocation of addresses, establishment of >> peering relationships, etc.) > > It's not a question of speed, it's a question of reaction time. > > As _one example, I know of many commercial DDoS products and services that automate these processes, RPKI as designed hampers our ability to respond in less than hours, and BGPSEC likely much longer. How do I rationalize this when it doesn't even fix things that I consider routing security issues (e.g., the Google sanfu weeks back?)? > > Here the cure may well be worse than the disease. Mefloquine, anyone? > > -danny > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From russw@riw.us Fri Nov 30 11:43:33 2012 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 392D821F89DC for ; Fri, 30 Nov 2012 11:43:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZeLuXbFeq0p for ; Fri, 30 Nov 2012 11:43:32 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC7D21F85D0 for ; Fri, 30 Nov 2012 11:43:32 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TeWUj-0004aJ-3e for sidr@ietf.org; Fri, 30 Nov 2012 11:43:29 -0800 Message-ID: <50B90C69.2050101@riw.us> Date: Fri, 30 Nov 2012 14:43:37 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sidr@ietf.org References: <50B90B13.1000502@gmail.com> In-Reply-To: <50B90B13.1000502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:43:33 -0000 > But if you have two cache servers, perhaps you would not even notice > while the second one is getting the whole repository(ies). This isn't about rebuilding an entire cache, it's about one off changes to that cache. What I'm hearing is that one-off changes could take minutes, hours, or even days in some circumstances. In a world that moves in the subsecond range, seconds are the minimal requirement, not minutes. There's more here than the startup case. What will be the scaling of getting even a single change out to hundreds of thousands of caches, and from thence to hundreds of thousands of routers, so a change in the correct origin can actually be reflected in the policy tables of the Internet at large? It seems, to me, like a pertinent question --and hand waving isn't a good answer at this point. Russ P.S. That we're discussion how well a system will scale and perform after it has been designed and standardized seems a little odd, at least to me. -- <>< riwhite@verisign.com russw@riw.us From danny@tcb.net Fri Nov 30 11:49:01 2012 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 0DFCB21F852A for ; Fri, 30 Nov 2012 11:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7T-x84+0VEX for ; Fri, 30 Nov 2012 11:49:00 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 92A9A21F8B63 for ; Fri, 30 Nov 2012 11:49:00 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 39D5D234A for ; Fri, 30 Nov 2012 19:49:00 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 95B091F3F; Fri, 30 Nov 2012 12:48:59 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: <50B90B13.1000502@gmail.com> Date: Fri, 30 Nov 2012 14:48:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B90B13.1000502@gmail.com> To: Arturo Servin X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Nov 30 12:49:00 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50b90dac199632272912450 X-DSPAM-Factors: 27, to+#+the, 0.01000, 2012+#+#+37, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, would+not, 0.01000, in+BGP, 0.01000, not+#+#+the, 0.01000, Mime-Version*Message+#+v1283, 0.01000, to+#+#+for, 0.01000, at+#+37, 0.01000, 2012+at, 0.01000, a+#+#+#+you, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, to+#+#+and, 0.01000, to+#+#+#+in, 0.01000, Mime-Version*Apple+#+framework, 0.01000, RPKI+#+#+be, 0.01000, have+#+#+#+to, 0.01000, the+#+#+is, 0.01000, and+#+#+#+in, 0.01000, I+have, 0.01000, If+you, 0.01000, a+problem, 0.01000, Cc*wg+#+sidr, 0.01000, and+#+#+and, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:49:01 -0000 On Nov 30, 2012, at 2:37 PM, Arturo Servin wrote: >=20 > If you only have one cache, and this fails, and you need to = restore the > whole repository(ies): then yes. You have a problem. >=20 > But if you have two cache servers, perhaps you would not even = notice > while the second one is getting the whole repository(ies). >=20 > But I am not sure if I am following your and Russ rationale. I'm not talking about the new attack surface elements we're introducing = here Arturo, that's an orthogonal second order concern. I'm talking about my inability to assert reachability for new = destinations on the Internet (i.e., my infrastructure or DDoS customers = prefixes) when attacks occur, without hours or days of downtime on the = properties being attacked, until RPKI objects are fetched from every = publication point on the Internet, controls are derived, and propagated = to every RPKI cache in every operators network, and distributed to some = sort of policy engine in routers for validation (and such) for routes in = BGP. This is not a worry I have today when responding to these threats, = and a serious problem if it exists. The fact that the RPKI itself could be attacked is just gravy. -danny= From dougm@nist.gov Fri Nov 30 11:52:35 2012 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 C849221F89F1 for ; Fri, 30 Nov 2012 11:52:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtM7MFa9m40x for ; Fri, 30 Nov 2012 11:52:35 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1820521F85A9 for ; Fri, 30 Nov 2012 11:52:35 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 30 Nov 2012 14:52:13 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 30 Nov 2012 14:52:34 -0500 From: "Montgomery, Douglas" To: Danny McPherson Date: Fri, 30 Nov 2012 14:52:18 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3PM+iecyHcl6XTTn2sxc9PMbu7tQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:52:35 -0000 On 11/30/12 2:00 PM, "Danny McPherson" wrote: > >On Nov 30, 2012, at 1:37 PM, Montgomery, Douglas wrote: > >>> >>> The RPKI needs to react in seconds, rather than minutes, hours, or >>>days. >> >> Based upon what analysis or requirement? > >Good question Doug. > >Today I have a requirement as an operator to mitigate DDoS attacks in >seconds to single digit minutes and this commonly requires routing system >changes that may not have been envisioned beforehand - hours and days of >delay [imposed by a system that does little more than control what's >routed - not if it's routed in a way I believe is secure] breaks this. I for one have long recognized that the current proposed system may have limits on its reaction time. Certainly from my perspective, more suited to pre-publishing preventative data, then creating reactionary data. The question is if there is consensus on the use cases like those above, if it is impossible to pre-publish the potential origination ROAs before their need/use, and if not, could the system be made more reactive and at what other scaling cost? Remember a ROA is an authorization to originate, not a declaration that is currently happening. If the business relationships that bring customers to your DDoS mitigation service are established at a slower rate, might one pre-publish the necessary ROAs? > >Where are the requirements that informed the current design? My own opinion is ... The observation that ResCerts are inherently linked to the business process of number resource allocation, and the time scales that operators seemed comfortable in current systems that construct policy from out of band data sets. RPKI should be able to move faster than those current processes. Also a personal opinion, but I am not sure that policy systems that operate much much faster than the underlying processes/human systems they are linked to, is necessarily a good thing. I hear lots of operator feed back on relative comfort levels of things becoming "too automated". Dougm > >-danny From christopher.morrow@gmail.com Fri Nov 30 11:53:15 2012 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 7E2E721F8A1E for ; Fri, 30 Nov 2012 11:53:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yG3Sro7nvYE for ; Fri, 30 Nov 2012 11:53:15 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E25E121F8A06 for ; Fri, 30 Nov 2012 11:53:14 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so33194vcb.31 for ; Fri, 30 Nov 2012 11:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=biPQOm1elkhK9ZIRhPzk7zhMkX0bplz/nbR8/gG1Uzg=; b=UmkcpiP6BH1vipNepo4Tch5pvKR79UuLOrmUW6zMrEaQnb3GTDC/aPvQ3JK1DSZlRd uXtj+tKO90HfVL8q9vEnDuXnZXMpwMqkqdOwTo7/jixgC4DmMfcjr/1MUeAUwVIIeXH9 Le2cVS6jTaI1phDD3OVNZghgs9l8cJkc6jYDZdGuijWSgxh+rs1/n99S8JRBMwNpK8+K HERuqzehvMDU9loEd+7gzuzplN7Cc8oFKn4/7F4GYaMtmhnD/bklTySCYHlkgL1BCwb+ T5/DQSZIEcqu/5IYolSiv5N6VKL9byFrme+GCcV9aR8GNaHyFBzUy5CsJPPqE6RcHPVA IzCg== MIME-Version: 1.0 Received: by 10.52.73.10 with SMTP id h10mr1667604vdv.97.1354305193965; Fri, 30 Nov 2012 11:53:13 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.58.205.148 with HTTP; Fri, 30 Nov 2012 11:53:13 -0800 (PST) In-Reply-To: <50B90B13.1000502@gmail.com> References: <50B90B13.1000502@gmail.com> Date: Fri, 30 Nov 2012 14:53:13 -0500 X-Google-Sender-Auth: s597PNYin3AeAvQEQpullQ6-bhU Message-ID: From: Christopher Morrow To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 19:53:15 -0000 On Fri, Nov 30, 2012 at 2:37 PM, Arturo Servin wrote: > > If you only have one cache, and this fails, and you need to restore the > whole repository(ies): then yes. You have a problem. > > But if you have two cache servers, perhaps you would not even notice > while the second one is getting the whole repository(ies). > > But I am not sure if I am following your and Russ rationale. > a worked example is something like: ROA in repository for X years: as701-1.2.3.0/24 Time T0: bgp route: 1.2.3.0/24 as-path: 701 Time T1: dos attack on 1.2.3.4/32 Time T2: AS701 says: "oh, ddos_svc, pls to help us!! Yes, we are a new customer we just signed up on your website, please helpz!!" Time T3: new-roa: 1.2.3.0/24 - AS-DDOS_SVCS Time T4: bgp-route: 1.2.3.0/24 as-path: AS-DDOS_SVCS Time T5: routing validates and things divert to ddos-svc I think Danny (and russ as well, at least) are worried that in the case of no prior agreements the time TODAY for this process is 'minutes', and that if I have to publish a new roa, ship that around, make sure everyone gets it ... the time is 'longer' tomorrow. (eric's numbers would say full replication and availability of the data is O(2days) or something) today there's no validation on the origin so if you pick your upstreams 'right' you can get reach-ability from a large portion of the network quickly. tomorrow in a 'only validated routes' world, you have to wait for propagation of the roa content. So, the (a) question is: "How fast does the certified resources data (as seen by bgp speakers) have to meet up with reality?" -chris From eosterweil@verisign.com Fri Nov 30 12:02:44 2012 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 702F221F8543 for ; Fri, 30 Nov 2012 12:02:44 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM2-Ajp0LpBx for ; Fri, 30 Nov 2012 12:02:44 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id AB4B321F8457 for ; Fri, 30 Nov 2012 12:02:43 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKULkQ4LuCcSGh8Ct+rmr9vbeKaAPImJyE@postini.com; Fri, 30 Nov 2012 12:02:43 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id qAUK2bB8031146; Fri, 30 Nov 2012 15:02:39 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Nov 2012 15:02:36 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 30 Nov 2012 15:02:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 30 Nov 2012 20:02:36.0916 (UTC) FILETIME=[A4D39B40:01CDCF35] Cc: Kotikalapudi Sriram , sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 20:02:44 -0000 ``Confirmation bias ... connotes the seeking or interpreting of evidence = in ways that are partial to existing beliefs, expectations, or a = hypothesis in hand.'' [ 1 ] On Nov 28, 2012, at 1:18 AM, Randy Bush wrote: > thank you. this makes a lot more sense than taking well-known > exteme worst cases (since fixed) and using them to calculate a > so called 'lower bound.' your document looks like responsible > engineering and describes about the numbers we have been > expecting and talking all along. thanks. Actually, Randy, engineering with the upper bound is pretty typical. = The counter tends to be viewed as quite amateurish. Understanding = failures and failings is part of responsible engineering. In fact, = codifying a system's design after building an implementation, and then = retrofitting requirements to that design so that we can _then_ back into = a threat model that befits a system's capabilities is typically frowned = upon by engineers. ymmv, Eric [ 1 ] Nickerson, Raymond S. "Confirmation bias: A ubiquitous = phenomenon in many guises."=20 Review of General Psychology; Review of General Psychology 2, = no. 2 (1998): 175. From danny@tcb.net Fri Nov 30 12:11:19 2012 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 5A65221F866B for ; Fri, 30 Nov 2012 12:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+IWWGgqa4KL for ; Fri, 30 Nov 2012 12:11:18 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id E349321F8666 for ; Fri, 30 Nov 2012 12:11:17 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 526D8234A for ; Fri, 30 Nov 2012 20:11:17 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id A9C0822B5; Fri, 30 Nov 2012 13:11:16 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Fri, 30 Nov 2012 15:11:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4D542903-E566-4F63-918A-1D058DE1F5B9@tcb.net> References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Nov 30 13:11:17 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50b912e5199631363168260 X-DSPAM-Factors: 27, and+#+#+#+the, 0.01000, to+#+#+in, 0.01000, that+operators, 0.01000, 2012+#+2, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Subject*sidr+#+#+of, 0.01000, a+#+#+I, 0.01000, Subject*sidr+#+#+#+caching, 0.01000, wrote+I, 0.01000, Subject*globally+#+RPKI, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+system, 0.01000, being+a, 0.01000, and+#+#+#+to, 0.01000, to+#+#+#+that, 0.01000, Subject*properties+#+caching, 0.01000, and+#+#+that, 0.01000, of+#+#+#+and, 0.01000, of+#+#+#+and, 0.01000, this+is, 0.01000, a+#+to, 0.01000, as+well, 0.01000, the+#+#+the, 0.01000, Subject*Scaling+properties, 0.01000, 2012+at, 0.01000, Subject*caching+#+a, 0.01000, Subject*BGPSEC+system, 0.01000 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 20:11:19 -0000 On Nov 30, 2012, at 2:52 PM, Montgomery, Douglas wrote: >=20 > I for one have long recognized that the current proposed system may = have > limits on its reaction time. Certainly from my perspective, more = suited > to pre-publishing preventative data, then creating reactionary data. And the state of the art in DDoS mitigation doesn't allow this, period. > The question is if there is consensus on the use cases like those = above, > if it is impossible to pre-publish the potential origination ROAs = before > their need/use, and if not, could the system be made more reactive and = at > what other scaling cost? Most folks don't buy DDoS protection services proactively (admittedly, = more are beginning to), they buy them when they're being attack. We get = a phone call and offer one of n options to mitigation, with a routing = assertion being a key techniques employed in the mix. We also have many = techniques related to hour core businesses that require routing changes = that may not have been pre-envisioned. Many commercial products and = solutions allow codifying of this as well, if you so choose. > Remember a ROA is an authorization to originate, not a declaration = that is > currently happening. If the business relationships that bring = customers > to your DDoS mitigation service are established at a slower rate, = might > one pre-publish the necessary ROAs? See above.. And also note that pre-publishing ROAs may well be a = *policy* thing (e.g., disclosure attack, "methods") that those who may = get attacked don't wish to exposure before absolutely necessary. > My own opinion is ... The observation that ResCerts are inherently = linked > to the business process of number resource allocation, and the time = scales > that operators seemed comfortable in current systems that construct = policy > from out of band data sets. RPKI should be able to move faster than = those > current processes. >=20 > Also a personal opinion, but I am not sure that policy systems that > operate much much faster than the underlying processes/human systems = they > are linked to, is necessarily a good thing. I hear lots of operator = feed > back on relative comfort levels of things becoming "too automated". Talk to anyone on the receiving end of a large scale DDoS attack Doug, = you shouldn't have to go far. Go tell them why it may well take hours = or days to respond, because we've "secured" the routing system (when = we've not done enough for me to justify investment in RPKI to my CFO). As one reasonably skilled in the art of DDoS mitigation services, and = commercial products that enable them, and as CSO of Verisign in my day = job where we are commonly on the end of lots of targeted and leveraged = DDoS attacks, and offer a service to mitigate them, this is my informed = opinion. =20 -danny= From danny@tcb.net Fri Nov 30 12:14:02 2012 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 857DE21F8688 for ; Fri, 30 Nov 2012 12:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.28 X-Spam-Level: X-Spam-Status: No, score=-100.28 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF7Z4rnCdYbG for ; Fri, 30 Nov 2012 12:14:02 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2537121F8678 for ; Fri, 30 Nov 2012 12:14:02 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D71C123AE for ; Fri, 30 Nov 2012 20:14:01 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 318F822B5; Fri, 30 Nov 2012 13:14:01 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Fri, 30 Nov 2012 15:14:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50B90B13.1000502@gmail.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Nov 30 13:14:01 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50b91389199631982561631 X-DSPAM-Factors: 27, a+#+route, 0.01000, 2012+#+2, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Subject*sidr+#+#+of, 0.01000, Subject*sidr+#+#+#+caching, 0.01000, Subject*globally+#+RPKI, 0.01000, Mime-Version*Message+#+v1283, 0.01000, Subject*properties+#+caching, 0.01000, no+#+#+the, 0.01000, Subject*Scaling+properties, 0.01000, 2012+at, 0.01000, Subject*caching+#+a, 0.01000, Subject*BGPSEC+system, 0.01000, at+#+#+PM, 0.01000, of+#+#+of, 0.01000, Cc*sidr+wg, 0.01000, have+to, 0.01000, have+to, 0.01000, 30+#+at, 0.01000, for+#+#+the, 0.01000, Subject*caching+#+#+globally, 0.01000, Mime-Version*Apple+#+framework, 0.01000, PM+#+Morrow, 0.01000, the+#+#+is, 0.01000, Christopher+#+wrote, 0.01000, Subject*of+caching, 0.01000, route+#+#+#+of, 0.01000 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 20:14:02 -0000 On Nov 30, 2012, at 2:53 PM, Christopher Morrow wrote: >=20 > today there's no validation on the origin so if you pick your > upstreams 'right' you can get reach-ability from a large portion of > the network quickly. tomorrow in a 'only validated routes' world, you > have to wait for propagation of the roa content. Right! and hope it's not a multi-mode attack that exploits just that = "property" of this new system with a rogue route announcement from one = of the millions of keyboards that have enable access to BGP speaking = routers. > So, the (a) question is: > "How fast does the certified resources data (as seen by bgp > speakers) have to meet up with reality?" Interesting we're visiting requirements now :-) I'd prefer it make my routing changes no slower than they are today. =20 -danny= From eosterweil@verisign.com Fri Nov 30 12:19:33 2012 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 9BDF321F8430 for ; Fri, 30 Nov 2012 12:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs1vpYMLohNF for ; Fri, 30 Nov 2012 12:19:33 -0800 (PST) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id E017521F841E for ; Fri, 30 Nov 2012 12:19:32 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKULkU0ugR+SmnbcGqebdmzJa7A8zdCPid@postini.com; Fri, 30 Nov 2012 12:19:32 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id qAUKJQ8s006389; Fri, 30 Nov 2012 15:19:30 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Nov 2012 15:19:25 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 30 Nov 2012 15:19:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022150307.1824.50258.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 30 Nov 2012 20:19:25.0980 (UTC) FILETIME=[FE468DC0:01CDCF37] Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-05.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: Fri, 30 Nov 2012 20:19:33 -0000 On Oct 22, 2012, at 11:14 AM, Randy Bush wrote: > just added as aliasing. if i missed something, whack me. six and a > half hours to dreadline. As we recently started talking about requirements again, I'd like to = point out that none of my comments on this draft have ever been = addressed: http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html Eric= From christopher.morrow@gmail.com Fri Nov 30 13:08:34 2012 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 9C12721F84F3 for ; Fri, 30 Nov 2012 13:08:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q67O8uqiIOAe for ; Fri, 30 Nov 2012 13:08:34 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1525A21F8462 for ; Fri, 30 Nov 2012 13:08:34 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so14035939vba.27 for ; Fri, 30 Nov 2012 13:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JCkkVCXBPchsLXjQYTnRZswAh6DDgrGgfUobzcJAJjQ=; b=t3bpoE9M+Tlsi+oRTwHuFNP3SniYQ8XTHf6SxmALtyxlsl/w3KwVsP4ZgQM6g6JlAB dACxMUECG8hiRBDMaKf9UGC8bx6slc2/t6uLoGOkQpWtXQw3ZqfSttdf43g0yM31Py1p 7NcusHZMTzJyKOswa08XnQQEMmsB4y4ecEUoolDBuLboCdzpcO4D1uErfSQTyxjWouy3 TRrEnJqg+uc0pqSKEhel8yhFnXDJZ3hMgpv9LHOTyRsfO7DYAhdiJwrQln3jtiS+yLVY +jTX6Wd9PUCIC6uLEjXmSgFx124nNjPPCP0O7GixBE9Tp8ZOOi7VudcHY4F6xiualGi2 CYbA== MIME-Version: 1.0 Received: by 10.52.27.138 with SMTP id t10mr1874653vdg.81.1354309713422; Fri, 30 Nov 2012 13:08:33 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.58.205.148 with HTTP; Fri, 30 Nov 2012 13:08:33 -0800 (PST) In-Reply-To: <4D542903-E566-4F63-918A-1D058DE1F5B9@tcb.net> References: <4D542903-E566-4F63-918A-1D058DE1F5B9@tcb.net> Date: Fri, 30 Nov 2012 16:08:33 -0500 X-Google-Sender-Auth: W4lwGR-VPlX94mtT6yrLQxorwTQ Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 21:08:34 -0000 On Fri, Nov 30, 2012 at 3:11 PM, Danny McPherson wrote: >> limits on its reaction time. Certainly from my perspective, more suited >> to pre-publishing preventative data, then creating reactionary data. > > And the state of the art in DDoS mitigation doesn't allow this, period. it sure does, if there's a contract in place... it's the 'oh noz! now we're under attack and need to bring in $DDOSPROVIDER!!' that isn't covered. From danny@tcb.net Fri Nov 30 13:19:36 2012 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 B52D121F8B0C for ; Fri, 30 Nov 2012 13:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.415 X-Spam-Level: X-Spam-Status: No, score=-100.415 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhGSjoh5so3T for ; Fri, 30 Nov 2012 13:19:35 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id D178121F866B for ; Fri, 30 Nov 2012 13:19:35 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 5B51223B1 for ; Fri, 30 Nov 2012 21:19:35 +0000 (UTC) Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id CFCF921DA; Fri, 30 Nov 2012 14:19:34 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Fri, 30 Nov 2012 16:19:33 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4D542903-E566-4F63-918A-1D058DE1F5B9@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Nov 30 14:19:35 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50b922e7199632065012467 X-DSPAM-Factors: 27, Cc*sidr+#+#+#+ietf.org, 0.01000, Subject*sidr+#+#+of, 0.01000, 2012+#+3, 0.01000, Subject*sidr+#+#+#+caching, 0.01000, Subject*globally+#+RPKI, 0.01000, Mime-Version*Message+#+v1283, 0.01000, to+#+#+#+that, 0.01000, danny+#+net, 0.01000, Subject*properties+#+caching, 0.01000, Nov+#+#+#+3, 0.01000, the+#+#+the, 0.01000, Subject*Scaling+properties, 0.01000, 2012+at, 0.01000, 2012+at, 0.01000, Subject*caching+#+a, 0.01000, Subject*BGPSEC+system, 0.01000, to+#+in, 0.01000, at+#+#+PM, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, tcb+net, 0.01000, 30+#+at, 0.01000, 30+#+at, 0.01000, will+#+#+to, 0.01000, danny+tcb, 0.01000, Subject*caching+#+#+globally, 0.01000, Mime-Version*Apple+#+framework, 0.01000 Cc: sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 21:19:36 -0000 On Nov 30, 2012, at 4:08 PM, Christopher Morrow wrote: > On Fri, Nov 30, 2012 at 3:11 PM, Danny McPherson wrote: >>> limits on its reaction time. Certainly from my perspective, more suited >>> to pre-publishing preventative data, then creating reactionary data. >> >> And the state of the art in DDoS mitigation doesn't allow this, period. > > it sure does, if there's a contract in place... it's the 'oh noz! now > we're under attack and need to bring in $DDOSPROVIDER!!' that isn't > covered. Right, IF there's a contract in place.. Perhaps this new latency will drive folks to be more proactive.. not! :-) -danny From randy@psg.com Fri Nov 30 15:38:04 2012 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 03AD321F842F for ; Fri, 30 Nov 2012 15:38:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjqMmWe7x7WS for ; Fri, 30 Nov 2012 15:38:03 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9053121F8442 for ; Fri, 30 Nov 2012 15:38:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tea9g-000PVd-8i; Fri, 30 Nov 2012 23:38:00 +0000 Date: Sat, 01 Dec 2012 08:37:59 +0900 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Kotikalapudi Sriram , sidr wg list Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system 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 Nov 2012 23:38:04 -0000 >> thank you. this makes a lot more sense than taking well-known >> exteme worst cases (since fixed) and using them to calculate a >> so called 'lower bound.' your document looks like responsible >> engineering and describes about the numbers we have been >> expecting and talking all along. thanks. > > Actually, Randy, engineering with the upper bound is pretty typical. from your document "The calculations in this document, while just candidate representations of RPKI, project a very long lower-bound on the potential time needed for RP caches to gather all objects in the RPKI" > The counter tends to be viewed as quite amateurish. personally, i would be professionally embarrassed to have my name on such wild assed cabbage throwing as that document. > codifying a system's design after building an implementation, and then > retrofitting requirements to that design so that we can _then_ back > into a threat model that befits a system's capabilities is typically > frowned upon by engineers. let's be honest here. the threat model was done in the late '80s. the base of the design in the early '90s. we're just slogging through the saussage machine. randy From randy@psg.com Fri Nov 30 15:41:49 2012 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 7120521F89A4 for ; Fri, 30 Nov 2012 15:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39L7x-GaE+ZB for ; Fri, 30 Nov 2012 15:41:49 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58221F8586 for ; Fri, 30 Nov 2012 15:41:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TeaDM-000PWC-Ik; Fri, 30 Nov 2012 23:41:48 +0000 Date: Sat, 01 Dec 2012 08:41:47 +0900 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <20121022150307.1824.50258.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-05.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: Fri, 30 Nov 2012 23:41:49 -0000 > point out that none of my comments on this draft have ever been > addressed: > http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html my memory is some were 'whatever' and some were quite helpful. but i do not trust my own memory, so do not advise you do so. but in the queue. i have not focused back on revving this one. writing two papers, a nasty review to do, and a couple of auth48s come first. and the real problem is, while i am shoveling that, more stuff comes up. randy