From dougm@nist.gov Sat Dec 1 07:18: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 0BC5411E8097 for ; Sat, 1 Dec 2012 07:18:47 -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 uUuc3gmQmo5n for ; Sat, 1 Dec 2012 07:18:46 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id C973F1F0C49 for ; Sat, 1 Dec 2012 07:18:32 -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; Sat, 1 Dec 2012 10:17:47 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sat, 1 Dec 2012 10:15:44 -0500 From: "Montgomery, Douglas" To: Danny McPherson , Christopher Morrow Date: Sat, 1 Dec 2012 10:17:48 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3P1rtks84ZkqidTGKuHuudckrLqw== 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: Sat, 01 Dec 2012 15:18:47 -0000 On 11/30/12 4:19 PM, "Danny McPherson" wrote: > >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 It is kind of interesting to think about this requirement - the ability to need to announce a prefix from a new, previously unseen origin, driven by a previously non-existant business relationship, anywhere in the world with a moments notice ... This will be a challenge to any system that where the users of resource certification information caches data from its authoritative sources. It is also interesting to consider that these requirements are basically the requirements of a hijack, with the exception that some-where, at the speed of light, some-one declared this one is "OK". Not trying to be provocative (dialing that down in general would be a good thing) ... Just actually trying to think about this as a serious system requirement. Maybe we should have just put the ROA in the BGPSEC update! Call up your DDOS mitigation provider, give them the private key for your Address Allocation .. And your done! The new BGP update, contains the ROA. That is the authorization of the new origin moves at the same speed of the updates that need it. Just and idea. Dougm From brweber2@yahoo.com Sat Dec 1 07:48: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 1EC191F0C49 for ; Sat, 1 Dec 2012 07:48: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 0d3mfTHV-Gnj for ; Sat, 1 Dec 2012 07:48:20 -0800 (PST) Received: from nm9-vm1.bullet.mail.gq1.yahoo.com (nm9-vm1.bullet.mail.gq1.yahoo.com [98.136.218.240]) by ietfa.amsl.com (Postfix) with ESMTP id 9865A1F0C67 for ; Sat, 1 Dec 2012 07:48:19 -0800 (PST) Received: from [98.137.12.59] by nm9.bullet.mail.gq1.yahoo.com with NNFMP; 01 Dec 2012 15:48:19 -0000 Received: from [98.136.185.47] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 01 Dec 2012 15:48:19 -0000 Received: from [127.0.0.1] by smtp108.mail.gq1.yahoo.com with NNFMP; 01 Dec 2012 15:48:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354376899; bh=ILumApdwflRmrRpg2hPnIRBRQm+IBup5OeVln+zyz/0=; 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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=f8HWWykL1BB2qDuxG5BJRfRV+wOqQVhjYQa8xNiPlvJit0Dg2ibYD2/5f8fnrlkTyAmgTly3AOxG3PO2lpsbN5B32XVLnyg8tsQWkLX7FhqwBTzkonFs/LCy00o428vSDQhPBRoVnAD71kBXAuQAHjnh8X9sM/xfMQVADIo5nQ8= X-Yahoo-Newman-Id: 298861.93720.bm@smtp108.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: FIOLHMEVM1mJ8JIDKd5yVBzph08aK4evzrW8_jPXFibKXW5 CityWhd7DtrkUJBUaW8bgU8sw1LdWiG4k2f9Bvr4ZAMEWkNVePs789IOx8mN 8TuNbDiTep6_JkNdDtHDDNm7HRyk1MgxNpR1G2kWUWpdyx4INvHgPZpP.EuH Qi5aVSfRXcC5Qp1twz6Pf9c8pPED_xRmMjiLmUwU7MTbkB9MHG0pB.xR3U1j pFxgIHaEE_tYymtbLOYgKib2zAUts3BfIs67w9iCrDF.xNxg1aHTWyEWfV5d sD8rrSYmpxjDKTFfKbLwq.0mge0s0kR1PieG4BRpRVXb_eHzyOQoLNWlbvHa qYDxW_SdKii3l4S89rXieqg.rSUPV6dk8Pmazt01nFytHrwd8So9g_Lb4HsY ekDbSHintfD51mhwpJ9AdfIcZd4Pzud5XB7mPWeetqs7WuZPig0wqSGuoMni mKkFqDwGf1eZsXeSdPlgxb_BmoA-- X-Yahoo-SMTP: f4ZrQXCswBB5jGYwSTd4wDs0ZJPe Received: from [192.168.1.9] (brweber2@68.100.90.3 with plain) by smtp108.mail.gq1.yahoo.com with SMTP; 01 Dec 2012 07:48:19 -0800 PST Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Bryan Weber In-Reply-To: Date: Sat, 1 Dec 2012 10:48:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <19D818D7-0832-4870-9EF3-54B3F4624BE9@yahoo.com> References: To: "Montgomery, Douglas" 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, 01 Dec 2012 15:48:21 -0000 I can think of several possible problems with sticking a ROA in a BGP = update. *) The crypto to validate the ROA must be performed. My third hand = knowledge of this is that since this can be expensive the router vendors = don't want to do this on the actual routers. Thus the reason for the = repository caches in the first place. So this is not a technical reason = as much as a real world reason. *) Are ROAs sufficient? What about BGP speaking server certificates or = whatever other CMS objects end up being part of BGPSec? For the DDoS = example a ROA might be sufficient, but would there be cases where other = types of objects should be disseminated via update messages? *) Can a BGP update accommodate the amount of extra data that would be = required?=20 *) Finally, an actual technical hurdle. In a hosted model, you might not = have the private key for your address allocation. It may be protected = and only live in memory on an HSM somewhere=85 And do you *really* want = to share your private key with another company anyway? Just my opinion, but I suspect that a party attempting a hijack would = probably be more patient than a legitimate party. The hijacker would = care more about being able to take over the traffic successfully as = opposed to quickly I suspect. Quick would just be a bonus. The party = being DDoS'd on the other hand has financial incentive to alleviate the = attack as quickly as possible. Just my 2 cents. -Bryan On Dec 1, 2012, at 10:17 AM, "Montgomery, Douglas" = wrote: >=20 > On 11/30/12 4:19 PM, "Danny McPherson" wrote: >=20 >>=20 >> On Nov 30, 2012, at 4:08 PM, Christopher Morrow wrote: >>=20 >>> 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. >>>>=20 >>>> And the state of the art in DDoS mitigation doesn't allow this, = period. >>>=20 >>> 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. >>=20 >> Right, IF there's a contract in place.. >>=20 >> Perhaps this new latency will drive folks to be more proactive.. = not! >> :-) >>=20 >> -danny >=20 > It is kind of interesting to think about this requirement - the = ability to > need to announce a prefix from a new, previously unseen origin, driven = by > a previously non-existant business relationship, anywhere in the world > with a moments notice ... This will be a challenge to any system that > where the users of resource certification information caches data from = its > authoritative sources. >=20 > It is also interesting to consider that these requirements are = basically > the requirements of a hijack, with the exception that some-where, at = the > speed of light, some-one declared this one is "OK". >=20 > Not trying to be provocative (dialing that down in general would be a = good > thing) ... Just actually trying to think about this as a serious = system > requirement. >=20 > Maybe we should have just put the ROA in the BGPSEC update! Call up = your > DDOS mitigation provider, give them the private key for your Address > Allocation .. And your done! The new BGP update, contains the ROA. = That > is the authorization of the new origin moves at the same speed of the > updates that need it. >=20 > Just and idea. >=20 > Dougm >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From sm@resistor.net Sat Dec 1 10:52:12 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 7D0DE21E803F for ; Sat, 1 Dec 2012 10:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 UI8EjFAP706F for ; Sat, 1 Dec 2012 10:52:11 -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 C349921E8039 for ; Sat, 1 Dec 2012 10:52:11 -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 qB1Iq5aP023119 for ; Sat, 1 Dec 2012 10:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354387930; bh=6DfNEySqxpw52TrI7wll7+z22SRHr1gUcVKJeiVpPmQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=koiXYwR5TBNc7FnzspRtfK7NRlXV+bLZuvmyggxbRialJYhHDvPRWyM9GrOQEDHOM PASGMo92OaqGULqrs2j3/bq+O2yqp1BB6AVheA7qEKcFs8+6jKKcKhaiWVy5SZBIXX j0mf5zZHIT0r8pERZCnhpr7l71y4Cz8l+T/CrUmw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1354387930; i=@resistor.net; bh=6DfNEySqxpw52TrI7wll7+z22SRHr1gUcVKJeiVpPmQ=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=1gSlF5JsIErm9antfCWSzVxGXlCLgdFdh2d2v4XdWgmmcbbtARLJTsIHiIa+vKtBt EALo6PVJ32KmfKyHVhbB9rrPDu2H8kXUJuqPaOBIVZsO8rVbVNOj2SVyJ5HpFVbGx4 vi5NuXQhzt3CZ+aM4Je/2pz61dsXt9HUIV2taLoM= Message-Id: <6.2.5.6.2.20121201102002.09659ad8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 01 Dec 2012 10:45:14 -0800 To: sidr@ietf.org From: SM In-Reply-To: <20121130170238.4029.37203.idtracker@ietfa.amsl.com> References: <20121130170238.4029.37203.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [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 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 18:52:12 -0000 At 09:02 30-11-2012, The IESG wrote: >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 There's a nice document shepherd write-up. Section 1.4 could be dropped as there's no requirements in the draft. In Section 10: "This memo requires no security considerations" That's terse. Regards, -sm From randy@psg.com Sat Dec 1 14:36: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 16E981F0C6A for ; Sat, 1 Dec 2012 14:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orL-cLOJDKoX for ; Sat, 1 Dec 2012 14:36:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id ABE4C1F0C61 for ; Sat, 1 Dec 2012 14:36:52 -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 1Tevfu-00032K-4l; Sat, 01 Dec 2012 22:36:42 +0000 Date: Sun, 02 Dec 2012 07:36:41 +0900 Message-ID: From: Randy Bush To: "Montgomery, Douglas" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.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, 01 Dec 2012 22:36:53 -0000 > It is kind of interesting to think about this requirement - the > ability to need to announce a prefix from a new, previously unseen > origin, driven by a previously non-existant business relationship, > anywhere in the world with a moments notice ... This will be a > challenge to any system that where the users of resource certification > information caches data from its authoritative sources. it will be a 'challenge' to any system where a secondary data set is being used to validate bgp, certificates, irr, smoke signals. randy From danny@tcb.net Mon Dec 3 06:04: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 095FC21F8661 for ; Mon, 3 Dec 2012 06:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.488 X-Spam-Level: X-Spam-Status: No, score=-99.488 tagged_above=-999 required=5 tests=[AWL=-0.910, BAYES_20=-0.74, 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 qCuxeQWfI77E for ; Mon, 3 Dec 2012 06:04:55 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 64DE321F8654 for ; Mon, 3 Dec 2012 06:04:55 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D801723DF for ; Mon, 3 Dec 2012 14:04:54 +0000 (UTC) Received: from [10.88.209.23] (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 6DF6C1ECE; Mon, 3 Dec 2012 07:04:54 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 3 Dec 2012 09:04:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7C516C40-B604-43C7-986B-858572B9D66F@tcb.net> References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Dec 3 07:04:54 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50bcb186199631269058685 X-DSPAM-Factors: 27, To*Montgomery+#+dougm, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, to+#+to, 0.01000, Subject*sidr+#+#+of, 0.01000, the+#+#+#+at, 0.01000, how+#+#+#+the, 0.01000, about+this, 0.01000, about+this, 0.01000, in+#+routing, 0.01000, Subject*sidr+#+#+#+caching, 0.01000, with+#+#+of, 0.01000, Subject*globally+#+RPKI, 0.01000, that+#+it, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+system, 0.01000, at+#+#+#+Montgomery, 0.01000, the+#+#+#+to, 0.01000, to+#+#+#+that, 0.01000, 2012+#+#+#+AM, 0.01000, Subject*properties+#+caching, 0.01000, pretty+fundamental, 0.01000, a+#+to, 0.01000, at+#+#+speed, 0.01000, To*Montgomery+#+#+nist.gov, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, Subject*Scaling+properties, 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: Mon, 03 Dec 2012 14:04:56 -0000 On Dec 1, 2012, at 10:17 AM, Montgomery, Douglas wrote: > It is kind of interesting to think about this requirement - the = ability to > need to announce a prefix from a new, previously unseen origin, driven = by > a previously non-existant business relationship, anywhere in the world > with a moments notice ... This will be a challenge to any system that > where the users of resource certification information caches data from = its > authoritative sources. >=20 > It is also interesting to consider that these requirements are = basically > the requirements of a hijack, with the exception that some-where, at = the > speed of light, some-one declared this one is "OK". It's a route announcement in the system Doug, just like any other today. > Not trying to be provocative (dialing that down in general would be a = good > thing) ... Just actually trying to think about this as a serious = system > requirement. >=20 > Maybe we should have just put the ROA in the BGPSEC update! Call up = your > DDOS mitigation provider, give them the private key for your Address > Allocation .. And your done! The new BGP update, contains the ROA. = That > is the authorization of the new origin moves at the same speed of the > updates that need it. See, again, we're trying to start with solutions and deal with the = imposition of an architectures reeking of 80s and early 90s baggage = (i.e., PKI & SBGP-esque) and all their constraints, without recognizing = why those systems are no longer favorable or why they weren't adopted in = the first place! Adding all this rigidity and ignoring systemic = complexities you're introducing, while not address some pretty = fundamental concerns (e.g., use of "expired data in RPKI", "lack of = robustness in today's nation-state/cyber security landscape", doesn't = deal with "leaks", downgrade attacks from algorithms, expired = certificates, or unprotected attributes, latency in RPs being aware of = new information", etc... Slamming a hierarchical PKI into a distributed routing system is what = didn't work in the 90s, agreed. I still contend that work in SIDR would = be more effective if we'd focus on a general Internet number resource = certification system and decouple precisely how it's employed in the = routing system (or other applications, e.g. SAVI, SEND, whatever..). = Here, we're focusing on routed resource certification to control what's = routed on the Internet, not how or if it's "secure", or the lack of = responsiveness of the system. At least employing some pub/sub models for new object availability, = rather than requiring CAs and RPs to discover all new information about = objects in the system, would be useful in this decade. Of course,=20 -danny= From danny@tcb.net Mon Dec 3 06:39: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 6F03321F8690 for ; Mon, 3 Dec 2012 06:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.316 X-Spam-Level: X-Spam-Status: No, score=-100.316 tagged_above=-999 required=5 tests=[AWL=0.121, 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 X3YINlgNDl8U for ; Mon, 3 Dec 2012 06:39:23 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABBD21F8757 for ; Mon, 3 Dec 2012 06:39:23 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 4221023DF for ; Mon, 3 Dec 2012 14:39:23 +0000 (UTC) Received: from [10.88.209.23] (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 101081C23 for ; Mon, 3 Dec 2012 07:39:22 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Mon, 3 Dec 2012 09:39:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Dec 3 07:39:23 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50bcb99b199631499312375 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, to+#+to, 0.01000, Subject*sidr+#+#+of, 0.01000, to+#+this, 0.01000, about+this, 0.01000, Subject*sidr+#+#+#+caching, 0.01000, Subject*globally+#+RPKI, 0.01000, the+#+with, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+#+#+to, 0.01000, Subject*properties+#+caching, 0.01000, 5+#+PM, 0.01000, To*wg+#+sidr, 0.01000, a+#+to, 0.01000, a+#+to, 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, at+5, 0.01000, the+#+to, 0.01000, To*list+#+ietf.org, 0.01000, the+#+#+a, 0.01000, Bush+wrote, 0.01000, Subject*caching+#+#+globally, 0.01000, This+#+#+a, 0.01000 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: Mon, 03 Dec 2012 14:39:37 -0000 On Dec 1, 2012, at 5:36 PM, Randy Bush wrote: >> It is kind of interesting to think about this requirement - the >> ability to need to announce a prefix from a new, previously unseen >> origin, driven by a previously non-existant business relationship, >> anywhere in the world with a moments notice ... This will be a >> challenge to any system that where the users of resource = certification >> information caches data from its authoritative sources. >=20 > it will be a 'challenge' to any system where a secondary data set is > being used to validate bgp, certificates, irr, smoke signals. And precisely why expecting relying parties to "discover" this new = information through periodic full infrastructure fetch and iteration is = fundamentally broken. -danny= From dougm@nist.gov Mon Dec 3 06:43: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 C49AF21F8475 for ; Mon, 3 Dec 2012 06:43:50 -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 DLur63sRSt9S for ; Mon, 3 Dec 2012 06:43:49 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9F82C21F843D for ; Mon, 3 Dec 2012 06:43:47 -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; Mon, 3 Dec 2012 09:42:59 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 3 Dec 2012 09:40:52 -0500 From: "Montgomery, Douglas" To: Bryan Weber Date: Mon, 3 Dec 2012 09:40:52 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3RZDGpT9qmhaVLQ5u2gvRhrUYyHw== Message-ID: In-Reply-To: <19D818D7-0832-4870-9EF3-54B3F4624BE9@yahoo.com> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable 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: Mon, 03 Dec 2012 14:43:51 -0000 Let's not pick apart the strawman details of an abstract idea. One could imagine aspects of an approach that only adds one sig to an udpate, signed by the prefix owner, not the first hop AS .. I.e., not an entire ROA CMS object. One could imagine this as and optional way of doing this for emergency announcements, with the existing approach being done for the vast, vast majority of updates, etc. The real high level point is one way of dealing with a requirement where authorization must move at the speed of updates, is to include the authorization in the update, when necessary. Clearly that will have trade offs. The points you make below would have to be considered *if* someone actually fleshed out that idea ... dougm On 12/1/12 10:48 AM, "Bryan Weber" wrote: >I can think of several possible problems with sticking a ROA in a BGP >update. > >*) The crypto to validate the ROA must be performed. My third hand >knowledge of this is that since this can be expensive the router vendors >don't want to do this on the actual routers. Thus the reason for the >repository caches in the first place. So this is not a technical reason >as much as a real world reason. >*) Are ROAs sufficient? What about BGP speaking server certificates or >whatever other CMS objects end up being part of BGPSec? For the DDoS >example a ROA might be sufficient, but would there be cases where other >types of objects should be disseminated via update messages? >*) Can a BGP update accommodate the amount of extra data that would be >required?=20 >*) Finally, an actual technical hurdle. In a hosted model, you might not >have the private key for your address allocation. It may be protected and >only live in memory on an HSM somewhere=8A And do you *really* want to >share your private key with another company anyway? > >Just my opinion, but I suspect that a party attempting a hijack would >probably be more patient than a legitimate party. The hijacker would care >more about being able to take over the traffic successfully as opposed to >quickly I suspect. Quick would just be a bonus. The party being DDoS'd on >the other hand has financial incentive to alleviate the attack as quickly >as possible. That is if the hijack needed a persistent address. If it just needs to be on the net long enough to do something specific, then maybe not. dougm > >Just my 2 cents. > >-Bryan > > >On Dec 1, 2012, at 10:17 AM, "Montgomery, Douglas" wrote: > >>=20 >> On 11/30/12 4:19 PM, "Danny McPherson" wrote: >>=20 >>>=20 >>> On Nov 30, 2012, at 4:08 PM, Christopher Morrow wrote: >>>=20 >>>> 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. >>>>>=20 >>>>> And the state of the art in DDoS mitigation doesn't allow this, >>>>>period. >>>>=20 >>>> 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. >>>=20 >>> Right, IF there's a contract in place.. >>>=20 >>> Perhaps this new latency will drive folks to be more proactive.. not! >>> :-) >>>=20 >>> -danny >>=20 >> It is kind of interesting to think about this requirement - the ability >>to >> need to announce a prefix from a new, previously unseen origin, driven >>by >> a previously non-existant business relationship, anywhere in the world >> with a moments notice ... This will be a challenge to any system that >> where the users of resource certification information caches data from >>its >> authoritative sources. >>=20 >> It is also interesting to consider that these requirements are basically >> the requirements of a hijack, with the exception that some-where, at the >> speed of light, some-one declared this one is "OK". >>=20 >> Not trying to be provocative (dialing that down in general would be a >>good >> thing) ... Just actually trying to think about this as a serious system >> requirement. >>=20 >> Maybe we should have just put the ROA in the BGPSEC update! Call up >>your >> DDOS mitigation provider, give them the private key for your Address >> Allocation .. And your done! The new BGP update, contains the ROA. >>That >> is the authorization of the new origin moves at the same speed of the >> updates that need it. >>=20 >> Just and idea. >>=20 >> Dougm >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From dougm@nist.gov Mon Dec 3 07:19: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 972B621F8823 for ; Mon, 3 Dec 2012 07:19:34 -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=[AWL=0.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 Ow42OvFFFWkz for ; Mon, 3 Dec 2012 07:19:33 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7072C21F884B for ; Mon, 3 Dec 2012 07:19:33 -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; Mon, 3 Dec 2012 10:18:47 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 3 Dec 2012 10:16:37 -0500 From: "Montgomery, Douglas" To: Danny McPherson Date: Mon, 3 Dec 2012 10:14:52 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3RaTAvwDNF6uLKSHOYF9E2MTaLQQ== Message-ID: In-Reply-To: <7C516C40-B604-43C7-986B-858572B9D66F@tcb.net> 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: Mon, 03 Dec 2012 15:19:34 -0000 On 12/3/12 9:04 AM, "Danny McPherson" wrote: > >On Dec 1, 2012, at 10:17 AM, Montgomery, Douglas wrote: > >> It is kind of interesting to think about this requirement - the ability >>to >> need to announce a prefix from a new, previously unseen origin, driven >>by >> a previously non-existant business relationship, anywhere in the world >> with a moments notice ... This will be a challenge to any system that >> where the users of resource certification information caches data from >>its >> authoritative sources. >> >> It is also interesting to consider that these requirements are basically >> the requirements of a hijack, with the exception that some-where, at the >> speed of light, some-one declared this one is "OK". > >It's a route announcement in the system Doug, just like any other today. Sure. But my point was typically today we don't do general filtering of unauthorized originations. If we were to accept that as a goal, then the only difference in the emergency DDoS mitigation origination and a hijack is a phone call. How to represent that phone call in the system at the speed of BGP update propagations is the point. > >> Not trying to be provocative (dialing that down in general would be a >>good >> thing) ... Just actually trying to think about this as a serious system >> requirement. >> >> Maybe we should have just put the ROA in the BGPSEC update! Call up >>your >> DDOS mitigation provider, give them the private key for your Address >> Allocation .. And your done! The new BGP update, contains the ROA. >>That >> is the authorization of the new origin moves at the same speed of the >> updates that need it. > >See, again, we're trying to start with solutions and deal with the >imposition of an architectures reeking of 80s and early 90s baggage >(i.e., PKI & SBGP-esque) and all their constraints, without recognizing >why those systems are no longer favorable or why they weren't adopted in >the first place! Adding all this rigidity and ignoring systemic >complexities you're introducing, while not address some pretty >fundamental concerns (e.g., use of "expired data in RPKI", "lack of >robustness in today's nation-state/cyber security landscape", doesn't >deal with "leaks", downgrade attacks from algorithms, expired >certificates, or unprotected attributes, latency in RPs being aware of >new information", etc... > >Slamming a hierarchical PKI into a distributed routing system is what >didn't work in the 90s, agreed. I still contend that work in SIDR would >be more effective if we'd focus on a general Internet number resource >certification system and decouple precisely how it's employed in the >routing system (or other applications, e.g. SAVI, SEND, whatever..). >Here, we're focusing on routed resource certification to control what's >routed on the Internet, not how or if it's "secure", or the lack of >responsiveness of the system. Address allocation is strictly hierarchical and distributed in the Internet today. It seems that any resource certification system would have to reflect that fact. > >At least employing some pub/sub models for new object availability, >rather than requiring CAs and RPs to discover all new information about >objects in the system, would be useful in this decade. I was trying to talk about the suggested requirement of near real-time authorization of route updates, divorced from any specific mechanisms. OK, I know I suggested a mechanism. But all I really meant was the observation that the only real way to get authorization to move at the speed of updates, is to carry the auth data in the update. If we want to relax that a bit ... But still be more responsive than existing proposed mechanisms, we would need modified/different distributions mechanisms for authorization data. > >Of course, > > >-danny Obviously, Dougm From bertietf@bwijnen.net Tue Dec 4 08:25: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 7C8BB21F8C47 for ; Tue, 4 Dec 2012 08:25:23 -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 2pbCY+113QRq for ; Tue, 4 Dec 2012 08:25:21 -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 C1C0721F8C42 for ; Tue, 4 Dec 2012 08:25:21 -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 1TfvJ7-0003gK-7X; Tue, 04 Dec 2012 17:25:18 +0100 Received: from cat.ripe.net ([193.0.1.249] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1TfvJ7-0001y9-27; Tue, 04 Dec 2012 17:25:17 +0100 Message-ID: <50BE23EC.30003@bwijnen.net> Date: Tue, 04 Dec 2012 17:25:16 +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: heasley References: <20121204161521.GA46671@shrubbery.net> In-Reply-To: <20121204161521.GA46671@shrubbery.net> 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: 20121204 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: 86ab03e524994f79ca2c75a176445dd42115f25c5451f58202b0ef42c22095e0 Cc: michael.baer@sparta.com, sidr wg list Subject: Re: [sidr] http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 04 Dec 2012 16:25:23 -0000 Not sure why you send this to authors/editors. The document is in IETF Last Call. So comments need to to got to IETF or IESG list. Your comments seem to be comments that get responded to a WG or IETF Last Call. Those comments need to go to WG and/or IESG or IETF list. On 12/4/12 5:15 PM, heasley wrote: > rpkiRtrCacheServerPreference doesnt indicate which is more preferred, 0 or > 255, but should imo. > Since it is an Unsigned 32, I think that this text: A lower value means more preferred. If two entries have the same preference, then the order is arbitrary. Which is present in the DESCRIPTION clause clearly explains that 0 is more preferred than 255. > shouldnt rpkiRtrCacheServerV4ActiveRecords et al be in an afi/safi table? > in theory, other afis may be supported. > not sure I can properly answer this one. possibly you'd like to see them there too? But I don't think this is a fatal flaw is it? Bert From heas@shrubbery.net Tue Dec 4 23:18: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 AB5C621F8C69 for ; Tue, 4 Dec 2012 23:18:39 -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 atjPBGO2qiFW for ; Tue, 4 Dec 2012 23:18:39 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373C621F8C65 for ; Tue, 4 Dec 2012 23:18:38 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id CB1C49A865; Wed, 5 Dec 2012 07:18:38 +0000 (UTC) Date: Wed, 5 Dec 2012 07:18:38 +0000 From: heasley To: "Bert Wijnen (IETF)" Message-ID: <20121205071838.GD71722@shrubbery.net> References: <20121204161521.GA46671@shrubbery.net> <50BE23EC.30003@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50BE23EC.30003@bwijnen.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: michael.baer@sparta.com, sidr wg list Subject: Re: [sidr] http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 05 Dec 2012 07:18:39 -0000 Tue, Dec 04, 2012 at 05:25:16PM +0100, Bert Wijnen (IETF): > Not sure why you send this to authors/editors. > > The document is in IETF Last Call. > So comments need to to got to IETF or IESG list. > > Your comments seem to be comments that get responded > to a WG or IETF Last Call. Those comments need to > go to WG and/or IESG or IETF list. > > > On 12/4/12 5:15 PM, heasley wrote: > > rpkiRtrCacheServerPreference doesnt indicate which is more preferred, 0 or > > 255, but should imo. > > > Since it is an Unsigned 32, I think that this text: > > > A lower value means more preferred. If two > entries have the same preference, then the > order is arbitrary. > > Which is present in the DESCRIPTION clause clearly explains > that 0 is more preferred than 255. grumble; the mib import tool is truncating descriptions. sorry for the noise. > > shouldnt rpkiRtrCacheServerV4ActiveRecords et al be in an afi/safi table? > > in theory, other afis may be supported. > > > not sure I can properly answer this one. > possibly you'd like to see them there too? > > But I don't think this is a fatal flaw is it? you tell me; seems like afi/safi tables are common now and other rpki pairs are possible. From randy@psg.com Wed Dec 5 00:06: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 2CE8621F85C8 for ; Wed, 5 Dec 2012 00:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 UAf5pKX2Q9Hl for ; Wed, 5 Dec 2012 00:06:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C1A2721F858C for ; Wed, 5 Dec 2012 00:06:18 -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 1Tg9zd-000L80-Qa; Wed, 05 Dec 2012 08:06:09 +0000 Date: Wed, 05 Dec 2012 03:06:08 -0500 Message-ID: From: Randy Bush To: heasley In-Reply-To: <20121205071838.GD71722@shrubbery.net> References: <20121204161521.GA46671@shrubbery.net> <50BE23EC.30003@bwijnen.net> <20121205071838.GD71722@shrubbery.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: michael.baer@sparta.com, sidr wg list Subject: Re: [sidr] http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 05 Dec 2012 08:06:19 -0000 > shouldnt rpkiRtrCacheServerV4ActiveRecords et al be in an afi/safi table? > in theory, other afis may be supported. the rpki and rfc 3779 support only ipv6 and ipv6. so i think there is an issue here. randy From andy@arin.net Wed Dec 5 08:55: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 BFAA221F8CB6 for ; Wed, 5 Dec 2012 08:55:25 -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 P9AgZt+CocNn for ; Wed, 5 Dec 2012 08:55:25 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1045B21F8C04 for ; Wed, 5 Dec 2012 08:55:25 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id C6DA621365E; Wed, 5 Dec 2012 11:55:19 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id F2875213624 for ; Wed, 5 Dec 2012 11:55:18 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 5 Dec 2012 11:55:04 -0500 Received: from CHAXCH02.corp.arin.net ([169.254.2.60]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Wed, 5 Dec 2012 11:55:18 -0500 From: Andy Newton To: "sidr@ietf.org" Thread-Topic: New Version Notification for draft-newton-sidr-policy-qualifiers-00.txt Thread-Index: AQHN0wlN84XImasOW02WDpuTRs0Buw== Date: Wed, 5 Dec 2012 16:55:17 +0000 Message-ID: In-Reply-To: <20121205165345.20676.44933.idtracker@ietfa.amsl.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: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <17C278567F89BB40BE30F56A660D18BA@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] FW: New Version Notification for draft-newton-sidr-policy-qualifiers-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: Wed, 05 Dec 2012 16:55:25 -0000 On 12/5/12 11:53 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-newton-sidr-policy-qualifiers-00.txt >has been successfully submitted by Andrew Lee Newton and posted to the >IETF repository. > >Filename: draft-newton-sidr-policy-qualifiers >Revision: 00 >Title: Policy Qualifiers in RPKI Certificates >Creation date: 2012-12-05 >WG ID: Individual Submission >Number of pages: 7 >URL: =20 >http://www.ietf.org/internet-drafts/draft-newton-sidr-policy-qualifiers-00 >.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-newton-sidr-policy-qualifiers >Htmlized: =20 >http://tools.ietf.org/html/draft-newton-sidr-policy-qualifiers-00 > > >Abstract: > This document updates RFC 6487 by clarifying the inclusion of policy > qualifiers in the certificate policies extension of RPKI resource > certificates. > > =20 > =20 > > >The IETF Secretariat > > From turners@ieca.com Wed Dec 5 13:30: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 8BCA621F8C5C for ; Wed, 5 Dec 2012 13:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 RKtFk1IcWcy4 for ; Wed, 5 Dec 2012 13:30:23 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.35.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1408921F8B9E for ; Wed, 5 Dec 2012 13:30:23 -0800 (PST) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 698D69EED55B5; Wed, 5 Dec 2012 15:30:18 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id A8BD89EED42D0 for ; Wed, 5 Dec 2012 15:30:17 -0600 (CST) Received: from [108.45.19.185] (port=50866 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TgMXp-00049k-LR; Wed, 05 Dec 2012 15:30:17 -0600 Message-ID: <50BFBCE9.2010806@ieca.com> Date: Wed, 05 Dec 2012 16:30:17 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: 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]:50866 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sidr@ietf.org" Subject: Re: [sidr] FW: New Version Notification for draft-newton-sidr-policy-qualifiers-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: Wed, 05 Dec 2012 21:30:23 -0000 Andy, A couple of comments: 1) I'm hoping to constrain the type and number of qualifiers that can be included. 5280 defines two types: cps (for certificate practice statements) and unotice (to display info to relying parties when the certificate is used). I'm hoping you just want the cps choice, which is just a URI. And, if it's just the CPS then there's only one CPS under which a certificate is issued - right? How about: OLD: This document updates [RFC6487], Section 4.8.9, to explicitly allow optional PolicyQualifierInfo objects in the PolicyInformation specified by [RFC6487]. NEW: This document updates [RFC6487], Section 4.8.9, as follows: OLD: This extension MUST be present and MUST be marked critical. It MUST include exactly one policy, as specified in the RPKI CP [RFC6484]. NEW: This extension MUST be present and MUST be marked critical. It MUST include exactly one policy, as specified in the RPKI CP [RFC6484]. Exactly one policy qualifier MAY be included. If a policy qualifier is included, the policyQualifierId MUST be the CPS pointer qualifier type (id-qt-cps). I think it's clear the value is the cPSuri choice, do you think anybody else would pick userNotice? 3) Two process points: 3.1) Need an IANA considerations section: IANA Considerations None. 3.2) Need a security considerations section. It would also be good to say why it's not a security issue to add the URI, but you'll need to confirm my assumption that relying parties aren't actually going to chase the URI. Alternatively, text could be added to s7.1.1 of RFC 6487 to say "don't process the URI", but I think putting it in the security considerations is probably less painful. Suggested text: Security Considerations The Security Considerations of [RFC6487] apply to this document. This document updates the RPKI certificate profile to specify that the certificate policies extension can include a policy qualifier, which is a URI. Checking of the URI might allow denial-of-service (DoS) attacks, where the target host may be subjected to bogus work resolving the URI. However, this specification, like [RFC5280], places no processing requirements on the URI included in the qualifier. 4) I hope you'll ask the WG to adopt this draft ;) spt From eosterweil@verisign.com Thu Dec 6 09:55: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 3594621F87CC for ; Thu, 6 Dec 2012 09:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, 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 Z39pOwVwHgOc for ; Thu, 6 Dec 2012 09:55:19 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCBA21F86EE for ; Thu, 6 Dec 2012 09:55:19 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUMDcBWXXuGanT2hSYLpIafnz+ynuOzfW@postini.com; Thu, 06 Dec 2012 09:55:19 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 qB6HtDGO005626; Thu, 6 Dec 2012 12:55:17 -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); Thu, 6 Dec 2012 12:55:12 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 6 Dec 2012 12:55:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 17:55:12.0646 (UTC) FILETIME=[D6F71260:01CDD3DA] 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: Thu, 06 Dec 2012 17:55:21 -0000 Sorry for the delay... $dayjob... On Nov 27, 2012, at 6:17 PM, Sriram, Kotikalapudi wrote: > This email is somewhat long.=20 > 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 My comments below are taken from you document (as you comment above = advised): General comment: I think a lot of the supporting information in this document seems to be = derived from qualitative estimation. I worry about this kind of = ``guestimation'' from an engineering perspective, and in deference to = those people that might have to operate this kind of infrastructure = based on guesswork. Specific comments: - In Section A you discuss the merit of different sets of performance = numbers: It is true that after Randy spent months presenting and = supporting those performance numbers at multiple venues, he has now come = back on the list with anecdotal numbers that are strangely very = different. However, I have to point out that his anecdotal snapshot = numbers don't seem to be quite as credible as his _own_ longitudinal = study's numbers. If, for example, he were to do a similar longitudinal = study and issue new numbers over the same protracted timescale, it would = make a lot of sense to use those too. However, (form the standpoint of = both an engineer and a scientist) snapshot measurements do not = constitute the same amount of information as long-term studies. Tim's = numbers are also point numbers, I'd like to find a way to factor them in = as additional data points, but it is, again, hard to compare apples to = oranges (one measurement vs. aggregated performance over a longitudinal = study). Remember, Randy's original numbers are the results of measuring = over a long period, they include operational eventualities (like outages = and performance hiccups, etc.), instead of a self-proclaimed = confirmation bias. - In Section A you present ``best case'' numbers. First, recall that = the numbers you've based your best case performance on are snapshots (at = best), and appear to be somewhat anecdotal. Our tech note illustrated = that Randy's previous numbers are averages across 10 repositories, AND = their average values were actually all reasonably consistent with each = other in the performance (within the same order of magnitude, modulo 2 = smaller repos whose numbers were basically averaged out). Also, I have = never seen ``best case'' numbers used as the justification of = performance, or operational soundness. For example, in complexity = theory, one often speaks about worst-case performance (big-O notation). = In general, one wants to know how bad things can get. Thus, you might = be able to say something like, ``the best this thing could ever possibly = run is x, y, z...'' But we have a long way to go before we can say we've = quantified the optimal theoretical performance. Again, from complexity = theory, if you want to (for example) describe average complexity = (big-omega), that is a lot harder to do than big-O, but would be very = useful, and I would applaud the initiative. Is that what your document = is trying to do? I guess, at best, it seems like we might be pursuing = opposite ends of the spectrum? I was trying to tell people that we have = to be ready for operational issues to provide a worst-case estimate. It = seems you were trying to illustrate that the system's peak performance = is still quite slow. Though, I admit that I am having trouble following = your methodology (perhaps your goal is loftier than mine).=20 - Later in Section A, at the top of page 2: I (obviously) see the = arithmetic effect of lowering the multiple, but we ought to ask _why_ = the other numbers are so high? What do _you_ see as the difference = (since both were taking by the same person)? What I see is that the = original numbers include real operations, real latencies, etc. and they = are taken over a long period. We (as engineers) have to respect that. = By the way, these are _not_ my numbers. You likely ought to cite the = work you are referencing properly, since calling these ``Eric's = numbers'' isn't quite right. A citation lets readers find out the = origin of cited information properly. ;) This is, I think, especially = true in this case where the actual presenter of the the original numbers = is the _same_person_ that is now trying to back away from them. This = is, scientifically speaking, an important point. - Second para on page 2: ``normal (steady-state) operation'' citation needed. ``rather rarely'' citation needed. ``would be more like seconds or minutes'' citation needed. These speculations sound like biased views, but my concerns might be = totally debunked with proper citations. As someone on the list pointed = out, this is engineering. We need evidence and measurements, and _not_ = intuition, guesswork, and experimental bias. - Section B: third para on page 2: ``84% of all ASes are stub ... 16% are non-stub'' citation = needed. What is this statement based on? ``The stub ASes are likely to only run simplex bgpsec and they = would likely contract out publication''=20 Also, each hosted instance that is _not_ flat still needs infrastructure = objects (GB, Mft, CA, etc) + DNS domain name + Also a noteworthy point = about your hosted model ( ;) ) is that hosted models remove resource = holders' abilities to manage their own information directly. That is, = if I have you host my info, and you have my private key, you likely = cannot give that key to me for me to make my own operational changes (if = you have it in an HSM, that private key cannot be shared). So, I (as a = resource holder) cannot author changes to my (say) ROA, or create new = router EE certs unless _YOU_ do it for me. So, right now, that would = require conversations like, ``hey ARIN, can you generate a new ROA for = me since I have a new feasible origin?'' (no big deal), but in the = future that would be, ``hey ARIN, can you create a new EE cert for my = router, and send me both the pub/priv key pair so I can configure a new = router (or $n$ new routers)?'' I'd hazard that _this_ is a much bigger = deal, especially with the need for a private key exchange. One more = complexity to note. ;) - Section C: You comment that there could be a single router key for an = entire AS is simply _not_ operationally feasible. Any operator can feel = free to open this discussion again, but I think we've covered that = ground here quite a few times. In fact, I think Randy was the most = recent person to hit that nail on the head (re: his 2 million router = keys comment). - Section C: Your estimates on routers per AS... Wow... So, I see some = other people have taken you to task on those estimates. I'll simply add = that I think your numbers are wrong, and even Randy pointed to 1 million = routers as a good starting point. - Section D: You mention that you (``We?'') had trouble following the = notion that updates will only be propagated to the whole system at about = 2*T (where T is the update period). I am struggling to find a citation = now, but will keep looking. In the meantime, here's a thought exercise = that illustrates the point: Suppose you take $n$ second to crawl the = rpki. If you start polling at $t$, but at $t + \epsilon$, the first = cache updates its entries. Then you will have to wait until $t + n$ = before you get to _start_ crawling the rpki again. However, if you then = pick up the new entry, you may have to expect that someone's caching = software will have to finish its crawl before your local cache has all = of the rpki. Why wait? Well, if you have a hierarchical cache system = (like the one Randy describes in his preso), or any large multinational = AS would likely need, then the data authorities (i.e. not the ones = caching) cannot be sure _everyone_ in the Internet has the fresh values = until caches like this have propagated out. Thus, $t + n + n$. This = makes your response time $2 \times n$. I will find a citation in the = literature and send it out. In the meantime, we have been updating our tech note with a lot of great = feedback and will be releasing a new revision soon. Eric From eosterweil@verisign.com Thu Dec 6 09:57: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 4CB4221F87E1 for ; Thu, 6 Dec 2012 09:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 1x1EmEUHa6qb for ; Thu, 6 Dec 2012 09:57:15 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0DF21F87D2 for ; Thu, 6 Dec 2012 09:57:15 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUMDcdvDbpSHxa8ikUdO7qBcOvmP7xn+4@postini.com; Thu, 06 Dec 2012 09:57:15 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 qB6Hv9eT013943; Thu, 6 Dec 2012 12:57:09 -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); Thu, 6 Dec 2012 12:57:08 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 6 Dec 2012 12:57:08 -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: 06 Dec 2012 17:57:08.0822 (UTC) FILETIME=[1C361F60:01CDD3DB] 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, 06 Dec 2012 17:57:16 -0000 On Nov 30, 2012, at 6:37 PM, Randy Bush wrote: >> Actually, Randy, engineering with the upper bound is pretty typical. >=20 > from your document >=20 > "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" lol... Good point: computing the upper bound on time, using the lower = bound on size... Different subjects, both conservative estimates, but my = bad for being unclear. :) >> The counter tends to be viewed as quite amateurish. >=20 > personally, i would be professionally embarrassed to have my name on > such wild assed cabbage throwing as that document. That's very constructive, thank you! >> 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. >=20 > 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. Um... Kind of a lot has changed since then, and I _believe_ the design = was rejected back then too... I think it might be less professionally = embarrassing to ask, what needs to change to make this viable? ;) ymmv, Eric= From eosterweil@verisign.com Thu Dec 6 09: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 209F421F87FD for ; Thu, 6 Dec 2012 09:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=-2.604, BAYES_40=-0.185, J_CHICKENPOX_15=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 QspDNXUR5Hog for ; Thu, 6 Dec 2012 09:57:16 -0800 (PST) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8C06D21F87CC for ; Thu, 6 Dec 2012 09:57:15 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUMDceSrurTE1PW6cHYqypsYQfmGMPt7i@postini.com; Thu, 06 Dec 2012 09:57:15 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 qB6HvCdn005672; Thu, 6 Dec 2012 12:57:12 -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); Thu, 6 Dec 2012 12:57:12 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Eric Osterweil In-Reply-To: <8CC97F34-991B-411A-BE0D-B39972740C72@ripe.net> Date: Thu, 6 Dec 2012 12:57:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1F4503D1-FC32-44D9-9E42-3D6547DEADAD@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50A47152.6010903@gmail.com> <89C00A38-151D-4980-9951-DC3A33D565DC@ripe.net> <8CC97F34-991B-411A-BE0D-B39972740C72@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 17:57:12.0338 (UTC) FILETIME=[1E4E9F20:01CDD3DB] 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, 06 Dec 2012 17:57:18 -0000 Hey Tim, My turn to apologize for the delay. I have taken your very excellent = feedback and tried to address it in a new revision of the tech note. = That should be coming out soon. Please do let me know if it seems off = again! Eric On Nov 23, 2012, at 11:26 AM, Tim Bruijnzeels wrote: > Hi Eric, >=20 > Sorry for the late response.. >=20 > 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. >=20 >=20 > On Nov 16, 2012, at 10:44 PM, Eric Osterweil = wrote: >=20 >>=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? >=20 > 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. >=20 > 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 >=20 > 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. >=20 > 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. >=20 > 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 >>>=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 >=20 > I did not consider algorithm roll over, but I think you're right. >=20 >>>=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 >=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. >=20 > In the rpki EE certs can only be used to sign rpki signed objects and = they are embedded in those objects, not published separately. >=20 > 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. >=20 > 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: >=20 > TA (offline) -> signs CA cert for online use =3D> signs member CAs >=20 > 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 >=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. :) >=20 > Yes, a ROA can have one ASN only, but multiple prefixes. >=20 > 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. >=20 > See here: > http://certification-stats.ripe.net/ >=20 >=20 >>=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? >=20 > Yes. My model assumes that this number of speakers can related to the = number of ASNs. >=20 > 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 >>=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. >=20 > 5 here would mean the current RIR TAs without any other signed = content. >=20 > The total object count for this depends on the number of CA certs. See = my previous best estimate below. >=20 >=20 >>=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 >=20 > I understand your concern about many repos, some of them small and = possibly not well managed. >=20 > But the number of repos is not 1:1 the number of organisations acting = as CAs. >=20 > 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 >>>=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 >=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. >=20 >=20 > 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. >=20 > 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. >=20 > 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 >=20 > 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. >=20 >=20 > *: = http://www.ripe.net/lir-services/resource-management/certification/tools-a= nd-resources >=20 >=20 >=20 >>>=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 >=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. >=20 >>> 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 >=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.. >=20 > 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. >=20 > 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 >=20 >=20 >>>=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 >=20 From eosterweil@verisign.com Thu Dec 6 09:57: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 AAFD421F881D for ; Thu, 6 Dec 2012 09:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.175 X-Spam-Level: X-Spam-Status: No, score=-4.175 tagged_above=-999 required=5 tests=[AWL=-0.576, 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 j-g6AJaJieI6 for ; Thu, 6 Dec 2012 09:57:21 -0800 (PST) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id C8EA021F87FD for ; Thu, 6 Dec 2012 09:57:20 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUMDcgGLgjDJ5M5saV7ax/XlfSrhCW4fv@postini.com; Thu, 06 Dec 2012 09:57:20 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 qB6HvJWk013956; Thu, 6 Dec 2012 12:57:19 -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); Thu, 6 Dec 2012 12:57:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 6 Dec 2012 12:57:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Danny McPherson X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 17:57:18.0947 (UTC) FILETIME=[223F1330:01CDD3DB] 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, 06 Dec 2012 17:57:21 -0000 On Dec 3, 2012, at 9:39 AM, Danny McPherson wrote: >=20 > On Dec 1, 2012, at 5:36 PM, Randy Bush wrote: >=20 >>> It is kind of interesting to think about this requirement - the >>> ability to need to announce a prefix from a new, previously unseen >>> origin, driven by a previously non-existant business relationship, >>> anywhere in the world with a moments notice ... This will be a >>> challenge to any system that where the users of resource = certification >>> information caches data from its authoritative sources. >>=20 >> it will be a 'challenge' to any system where a secondary data set is >> being used to validate bgp, certificates, irr, smoke signals. >=20 > And precisely why expecting relying parties to "discover" this new = information through periodic full infrastructure fetch and iteration is = fundamentally broken. +1 Eric= From russw@riw.us Thu Dec 6 10:09: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 3624021F88A1 for ; Thu, 6 Dec 2012 10:09:01 -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 XOFGRT2n-XQb for ; Thu, 6 Dec 2012 10:09:00 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B710921F8893 for ; Thu, 6 Dec 2012 10:08:57 -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 1TgfsW-0008O8-PY for sidr@ietf.org; Thu, 06 Dec 2012 10:08:56 -0800 Message-ID: <50C0DF46.7010400@riw.us> Date: Thu, 06 Dec 2012 13:09: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: sidr@ietf.org 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 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, 06 Dec 2012 18:09:01 -0000 >>> it will be a 'challenge' to any system where a secondary data set is >>> being used to validate bgp, certificates, irr, smoke signals. >> >> And precisely why expecting relying parties to "discover" this new information through periodic full infrastructure fetch and iteration is fundamentally broken. > > +1 +2 Russ -- <>< riwhite@verisign.com russw@riw.us From russw@riw.us Thu Dec 6 10:31: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 E789021F8773 for ; Thu, 6 Dec 2012 10:31:16 -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 J46KmBoDWD38 for ; Thu, 6 Dec 2012 10:31:16 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8978D21F875B for ; Thu, 6 Dec 2012 10:31:16 -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 1TggE5-0001cy-KU for sidr@ietf.org; Thu, 06 Dec 2012 10:31:13 -0800 Message-ID: <50C0E47F.9090702@riw.us> Date: Thu, 06 Dec 2012 13:31:27 -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: Thu, 06 Dec 2012 18:31:17 -0000 >> 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. "The debate is over?" There was a debate? I seem to have missed it. Were there competing requirements documents? Who authored them? Who was polled to find real world requirements? How were the final requirements determined? We're now slogging through sausage, but it's sausage we could have done without had we started from the proper end of the problem and actually built requirements first. > Um... Kind of a lot has changed since then, and I _believe_ the design was rejected back then too... I think it might be less professionally embarrassing to ask, what needs to change to make this viable? ;) Now, now --let's not interfere with the sausage making process by any means. That might be embarrassing to the folks who chose the required sausage. Russ -- <>< riwhite@verisign.com russw@riw.us From andy@arin.net Thu Dec 6 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 82F6121F87E9 for ; Thu, 6 Dec 2012 10:39: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 WYp-dZVHQ0ed for ; Thu, 6 Dec 2012 10:39: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 D72A521F86A6 for ; Thu, 6 Dec 2012 10:39:47 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 5BA11165456; Thu, 6 Dec 2012 13:39:47 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id B7B8916544B; Thu, 6 Dec 2012 13:39:46 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 6 Dec 2012 13:39:22 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.120]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0318.004; Thu, 6 Dec 2012 13:39:40 -0500 From: Andy Newton To: Sean Turner Thread-Topic: [sidr] FW: New Version Notification for draft-newton-sidr-policy-qualifiers-00.txt Thread-Index: AQHN0wlN84XImasOW02WDpuTRs0Bu5gLDS+AgAEO1IA= Date: Thu, 6 Dec 2012 18:39:39 +0000 Message-ID: In-Reply-To: <50BFBCE9.2010806@ieca.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: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] FW: New Version Notification for draft-newton-sidr-policy-qualifiers-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, 06 Dec 2012 18:39:48 -0000 Sean, Thanks for the quick review. Replies inline... On 12/5/12 4:30 PM, "Sean Turner" wrote: >Andy, > >A couple of comments: > >1) I'm hoping to constrain the type and number of qualifiers that can be >included. > >5280 defines two types: cps (for certificate practice statements) and >unotice (to display info to relying parties when the certificate is >used). I'm hoping you just want the cps choice, which is just a URI. >And, if it's just the CPS then there's only one CPS under which a >certificate is issued - right? How about: > >OLD: > > This document updates [RFC6487], Section 4.8.9, to explicitly allow > optional PolicyQualifierInfo objects in the PolicyInformation > specified by [RFC6487]. > >NEW: > > This document updates [RFC6487], Section 4.8.9, as follows: > > OLD: > > This extension MUST be present and MUST be marked critical. It > MUST include exactly one policy, as specified in the RPKI CP > [RFC6484]. > > NEW: > > This extension MUST be present and MUST be marked critical. It > MUST include exactly one policy, as specified in the RPKI CP > [RFC6484]. Exactly one policy qualifier MAY be included. If a > policy qualifier is included, the policyQualifierId MUST be the > CPS pointer qualifier type (id-qt-cps). > >I think it's clear the value is the cPSuri choice, do you think anybody >else would pick userNotice? It is possible that somebody somewhere might find them useful. But I'm not gonna fall on my sword over the inclusion of user notices. A CPS pointer is what we need. I'll incorporate your text. Thanks. > >3) Two process points: > >3.1) Need an IANA considerations section: > >IANA Considerations > >None. Noted. > >3.2) Need a security considerations section. It would also be good to >say why it's not a security issue to add the URI, but you'll need to >confirm my assumption that relying parties aren't actually going to >chase the URI. Alternatively, text could be added to s7.1.1 of RFC 6487 >to say "don't process the URI", but I think putting it in the security >considerations is probably less painful. Suggested text: > >Security Considerations > >The Security Considerations of [RFC6487] apply to this document. > >This document updates the RPKI certificate profile to specify that the >certificate policies extension can include a policy qualifier, which is >a URI. Checking of the URI might allow denial-of-service (DoS) attacks, >where the target host may be subjected to bogus work resolving the URI. > However, this specification, like [RFC5280], places no processing >requirements on the URI included in the qualifier. This is a very good point. And I think addressing it in security considerations, as you have suggested, is the appropriate thing to do. > >4) I hope you'll ask the WG to adopt this draft ;) Yes, I was planning to do so after a re-spin of this document. Thanks for your review and text. -andy From christopher.morrow@gmail.com Thu Dec 6 10:47: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 BDFC021F863B for ; Thu, 6 Dec 2012 10:47:03 -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 Z+8+hw7wRg5q for ; Thu, 6 Dec 2012 10:47: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 15BBA21F8599 for ; Thu, 6 Dec 2012 10:47:02 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so4222182eek.31 for ; Thu, 06 Dec 2012 10:47: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=A4B6y8G2PF1Ga2PcYQHYHj9+Haxqc1vOK359ZVtlfzc=; b=idQd8LD1lBBSdfd79rPog5Sd/nFAp5yHAKU4Pjh4vHh4afRI7ETMr9UwIgFnWVkV9W NIS2ER97EqB2ccjRDRSHvY6uoH0E5ryccmvwjydhprv6facnoLOuS/amprSl018RiAM9 XaKlt9qJyfDPhrCuTiUOV0KiYlbflRnGsgCtSIFEZTy09hhFWkjSqQq7a/uCKRYN088A INRuzENaWlXzKTEwywehC2wiLnQ+zWahTFEuJRi44NglWEVpdMRziJHPBWjqjeoYsWQd F6wKTO2imNl+MSgrMG/hwh+C8VvYvIwhpeUkARk5D4m+upcedNG6UQr5uo9bRhfzkLTU mPKg== MIME-Version: 1.0 Received: by 10.14.202.3 with SMTP id c3mr8463734eeo.4.1354819622182; Thu, 06 Dec 2012 10:47:02 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Thu, 6 Dec 2012 10:47:02 -0800 (PST) In-Reply-To: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> Date: Thu, 6 Dec 2012 13:47:02 -0500 X-Google-Sender-Auth: 7J4cLgOtjxn42UeIBDT2T7c_W0A Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 06 Dec 2012 18:47:03 -0000 On Fri, Nov 30, 2012 at 6:37 PM, Randy Bush wrote: >> 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. I would point out to all folks on this list, and particularly randy this time, let's try to keep the discussion focused on technical topics and not devolve into banter such as this example. all this does is pull us off the more important topic of 'will it blend?'. -chris From randy@psg.com Thu Dec 6 10:52: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 9FDBE21F87C1 for ; Thu, 6 Dec 2012 10:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 V5YMnjaXp2TT for ; Thu, 6 Dec 2012 10:52:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 038D321F86FD for ; Thu, 6 Dec 2012 10:52:21 -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 1TggYP-000D0v-Kz; Thu, 06 Dec 2012 18:52:14 +0000 Date: Fri, 07 Dec 2012 03:52:12 +0900 Message-ID: From: Randy Bush To: Christopher Morrow 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: Thu, 06 Dec 2012 18:52:26 -0000 > I would point out to all folks on this list, and particularly randy > this time, let's try to keep the discussion focused on technical > topics and not devolve into banter such as this example. guilty as charged. my apologies. randy From aservin@lacnic.net Thu Dec 6 11:33: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 970F121F8827 for ; Thu, 6 Dec 2012 11:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.003 X-Spam-Level: * X-Spam-Status: No, score=1.003 tagged_above=-999 required=5 tests=[AWL=-3.604, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, MANGLED_DEALS=2.3, 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 QbX9tcBTmDQe for ; Thu, 6 Dec 2012 11:33:55 -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 8553D21F8813 for ; Thu, 6 Dec 2012 11:33:55 -0800 (PST) Received: from 219.9.wired.gter.nic.br (unknown [200.160.9.219]) by mail.lacnic.net.uy (Postfix) with ESMTP id 571D4308453 for ; Thu, 6 Dec 2012 17:33:48 -0200 (UYST) Message-ID: <50C0F31A.4040400@lacnic.net> Date: Thu, 06 Dec 2012 17:33:46 -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: sidr@ietf.org References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> In-Reply-To: X-Enigmail-Version: 1.4.6 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] 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, 06 Dec 2012 19:33:57 -0000 Eric, Just for the sake of clarity. Not sure if I understand, but hosted system does not work 100% in the way that you described. Yes, the hosted keep your private key, but you can modify your ROAs anytime you want. At least the hosted systems that I know provide a web interface to do that. The ROA would be published immediately or a few minute/hours later, depending of the rpki-operator (my personal view and with my network operator hat on is that it should be immediately or in minutes). You could argue that effectively the hosted system "does it for you" and "you require conversation with them", but the way described is a bit misleading because it gives the impression that it is a slow or human-driven process when in reality its not. As for EE cert for routers those do not exist yet in the rpki-operator systems (AFAIK), so anything here would be a guess. Cheers /as On 06/12/2012 15:55, Eric Osterweil wrote: > What is this statement based on? > ``The stub ASes are likely to only run simplex bgpsec and they would likely contract out publication'' > Also, each hosted instance that is _not_ flat still needs infrastructure objects (GB, Mft, CA, etc) + DNS domain name + Also a noteworthy point about your hosted model ( ;) ) is that hosted models remove resource holders' abilities to manage their own information directly. That is, if I have you host my info, and you have my private key, you likely cannot give that key to me for me to make my own operational changes (if you have it in an HSM, that private key cannot be shared). So, I (as a resource holder) cannot author changes to my (say) ROA, or create new router EE certs unless _YOU_ do it for me. So, right now, that would require conversations like, ``hey ARIN, can you generate a new ROA for me since I have a new feasible origin?'' (no big deal), but in the future that would be, ``hey ARIN, can you create a new EE cert for my router, and send me both the pub/priv key pair so I can configure a new router (or $n$ new routers)?'' I'd hazard that _this_ is a much bigger de > al, especially with the need for a private key exchange. One more complexity to note. ;) From russw@riw.us Thu Dec 6 11:42: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 1F43C21F88C1 for ; Thu, 6 Dec 2012 11:42:40 -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 ad8jOSZlLXG0 for ; Thu, 6 Dec 2012 11:42:39 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id DF9D221F87FC for ; Thu, 6 Dec 2012 11:42: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 1TghLA-000665-1j for sidr@ietf.org; Thu, 06 Dec 2012 11:42:36 -0800 Message-ID: <50C0F53A.7090408@riw.us> Date: Thu, 06 Dec 2012 14:42:50 -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> <50C0F31A.4040400@lacnic.net> In-Reply-To: <50C0F31A.4040400@lacnic.net> 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: Thu, 06 Dec 2012 19:42:40 -0000 > Yes, the hosted keep your private key, but you can modify your ROAs > anytime you want. At least the hosted systems that I know provide a web > interface to do that. The ROA would be published immediately or a few > minute/hours later, depending of the rpki-operator (my personal view and > with my network operator hat on is that it should be immediately or in > minutes). Modulo the propagation time... But isn't it bad to allow automated changes to a certificate that's designed to operate "at human speeds," (based on other conversations on this list), and is so critical to the operation of the routing system? Aren't we just adding to the total attack surface available against the routing system by allowing users to go into a web page and change what's advertised into the ROA system? I know --it takes that bit of the problem out of the actual BGP space, and moves it into another space altogether, but... I don't see banking as being "more secure" because you can do all your banking on line --it's more convenient, but I think there's a clear tradeoff in security and convenience here, right? If this is the type of system that's envisioned, shouldn't the risks involved be documented someplace? Russ -- <>< riwhite@verisign.com russw@riw.us From aservin@lacnic.net Thu Dec 6 11:54: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 8704D21F86BD for ; Thu, 6 Dec 2012 11:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.655 X-Spam-Level: * X-Spam-Status: No, score=1.655 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, 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 OkRDH16va2s5 for ; Thu, 6 Dec 2012 11:54:27 -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 E9B7921F8543 for ; Thu, 6 Dec 2012 11:54:26 -0800 (PST) Received: from 219.9.wired.gter.nic.br (unknown [200.160.9.219]) by mail.lacnic.net.uy (Postfix) with ESMTP id A3A7B308432; Thu, 6 Dec 2012 17:54:17 -0200 (UYST) Message-ID: <50C0F7E8.2090008@lacnic.net> Date: Thu, 06 Dec 2012 17:54:16 -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: Russ White References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <50C0F53A.7090408@riw.us> In-Reply-To: <50C0F53A.7090408@riw.us> X-Enigmail-Version: 1.4.6 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 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, 06 Dec 2012 19:54:27 -0000 Russ, The "automated" changes would be similar to the ones that you would do on your own CA. As adding a new attack surface by using web interfaces, yes we are as you said, the convenience has a price. Nevertheless if well protected it could be an acceptable trade-off. Forcing everyone to have their own CA (possible as it should be from a security stand point) would make rpki very complex to deploy for the small/medium players (similar to DNSSEC today). Perhaps we should document all these. Regards, as On 06/12/2012 17:42, Russ White wrote: > >> Yes, the hosted keep your private key, but you can modify your ROAs >> anytime you want. At least the hosted systems that I know provide a web >> interface to do that. The ROA would be published immediately or a few >> minute/hours later, depending of the rpki-operator (my personal view and >> with my network operator hat on is that it should be immediately or in >> minutes). > > Modulo the propagation time... > > But isn't it bad to allow automated changes to a certificate that's > designed to operate "at human speeds," (based on other conversations on > this list), and is so critical to the operation of the routing system? > Aren't we just adding to the total attack surface available against the > routing system by allowing users to go into a web page and change what's > advertised into the ROA system? > > I know --it takes that bit of the problem out of the actual BGP space, > and moves it into another space altogether, but... I don't see banking > as being "more secure" because you can do all your banking on line > --it's more convenient, but I think there's a clear tradeoff in security > and convenience here, right? > > If this is the type of system that's envisioned, shouldn't the risks > involved be documented someplace? > > Russ > From christopher.morrow@gmail.com Thu Dec 6 12: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 3311C21F8A1D for ; Thu, 6 Dec 2012 12: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 er8Lv0yWMen9 for ; Thu, 6 Dec 2012 12:13:45 -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 7577221F8A1B for ; Thu, 6 Dec 2012 12:13:45 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so2916942eaa.31 for ; Thu, 06 Dec 2012 12:13:44 -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=/bHIfs9sdLT3edK/HqhdVeLDvoCGb8hcsiJQA5BSpW8=; b=xI1TZ5BtWBlXvsHwIP1uAlj4Y5ws2Rk9Iyau5fYBTVz9a5eyvnbh9AVbiSbzR4xnuS lAJ/QVgje2qMlKTbR0TgyZymCbJvx1QGp0wVpo+X3LYG1X4T/p7/9dLzlTkn4wlBjr3H EBFIcOsh7IpYelAKKM+VbtisOBpxoAJOJF5dQafZxG7XuwTZiD5WJJyRf8DSEynTpWtP d+NoSl9sPcDOfPJs/kN7S6JwU3hmXQSBV8Xt5bwQ1CB3HjPYjHBQZWkmXpriT7+Ry4+q K+l57MKtEZsFlxJwFRZbp3rh/kl7PVzFkydl8h7deQUu9ZkwI3zzHVPYtsY47g2vWGHL rpjA== MIME-Version: 1.0 Received: by 10.14.214.132 with SMTP id c4mr8842558eep.18.1354824824619; Thu, 06 Dec 2012 12:13:44 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Thu, 6 Dec 2012 12:13:44 -0800 (PST) In-Reply-To: <50C0F53A.7090408@riw.us> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <50C0F53A.7090408@riw.us> Date: Thu, 6 Dec 2012 15:13:44 -0500 X-Google-Sender-Auth: -voIOq9rTXwcFCpVsdvWKZRRDTk Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 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, 06 Dec 2012 20:13:46 -0000 On Thu, Dec 6, 2012 at 2:42 PM, Russ White wrote: > Aren't we just adding to the total attack surface available against the > routing system by allowing users to go into a web page and change what's > advertised into the ROA system? could be, but so are ssl cert things from thawte, or dns services that permit users to interact with the dns provider... the hosted model is there for, ideally, people who do not want to run their own infrastructure... in a sense it's godaddy-dns for rpki data, instead of 'running your own dns server'. From eosterweil@verisign.com Thu Dec 6 12:56: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 3680321F8587 for ; Thu, 6 Dec 2012 12:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, J_CHICKENPOX_42=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 0YaW4BGGLphA for ; Thu, 6 Dec 2012 12:56:58 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA4F21F8551 for ; Thu, 6 Dec 2012 12:56:53 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUMEGlVb57C1yp4d/H0bPV0Gdlx7pyGDY@postini.com; Thu, 06 Dec 2012 12:56:56 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 qB6KunkI011758; Thu, 6 Dec 2012 15:56:49 -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); Thu, 6 Dec 2012 15:56:49 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50C0F31A.4040400@lacnic.net> Date: Thu, 6 Dec 2012 15:56:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 20:56:49.0651 (UTC) FILETIME=[36161430:01CDD3F4] 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, 06 Dec 2012 20:56:59 -0000 On Dec 6, 2012, at 2:33 PM, Arturo Servin wrote: > Yes, the hosted keep your private key, but you can modify your = ROAs > anytime you want. At least the hosted systems that I know provide a = web > interface to do that. The ROA would be published immediately or a few > minute/hours later, depending of the rpki-operator (my personal view = and > with my network operator hat on is that it should be immediately or in > minutes). That's all fine and dandy, and while I agree with what Russ said in his = response, you should note that I did say, ``no big deal.'' That said, = after thinking about what Russ said and your response, I actually do = think this is a big deal... now... ;) If/when I (as a prospective user of the system) decide to move my = information from your hostage model to my own repository, how will I be = able to migrate the private portion of my certificate from _your_ hosted = system to my own? How are we doing this private key exchange? Do you = realize that you won't be able to use an HSM at all if the private = portion will ever need to be exported? Maybe I missed that part of the = explanation? > You could argue that effectively the hosted system "does it for = you" > and "you require conversation with them", but the way described is a = bit > misleading because it gives the impression that it is a slow or > human-driven process when in reality its not. Sorry, this was just a colloquialism... Not meant to be misleading. I = understand that this would likely be a web interface, or whatever. That = said, in either case, aren't we now saying that for someone to update = their secure routing information, they need to go through you? Is that = a Single Point of Failure (SPF)? What if your web interface is being = DDoS'ed when I need to update my ROA (perhaps because _I'm_ being = DDoS'ed and am engaging a DDoS mitigation service for the first time)? = Anyway, these are (as I said) complexities to note.... >=20 > As for EE cert for routers those do not exist yet in the = rpki-operator > systems (AFAIK), so anything here would be a guess. I seriously disagree here... We are building a system that is intended = to do this! The rpki must have router certs in it (according to the = bgpsec design), and we therefore must to be proactive in evaluating that = aspect. In the above hosted model, you absolutely will be on the hook = for this, and if you invest in a system whose design will be = architecturally (or even operationally) unable to accommodate this = eventuality, you are doing yourself a _huge_ disservice by ignoring the = writing on the wall. The bottom line is, there needs to be some = thinking around this, or it will bite all of us (I have packets on the = interwebz too). My 0.02, I worry that your web interface is inadequate for the eventual = secure provisioning of router certs. Eric= From rbarnes@bbn.com Thu Dec 6 13:12: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 600F421F876C for ; Thu, 6 Dec 2012 13:12:17 -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=[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 w5Vi9X5mLseJ for ; Thu, 6 Dec 2012 13:12:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DE56021F86FD for ; Thu, 6 Dec 2012 13:12:16 -0800 (PST) Received: from ros-dhcp192-1-51-58.bbn.com ([192.1.51.58]:59247) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tgijt-000OP4-6X; Thu, 06 Dec 2012 16:12:13 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: Date: Thu, 6 Dec 2012 16:12:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> To: Eric Osterweil X-Mailer: Apple Mail (2.1499) 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, 06 Dec 2012 21:12:17 -0000 On Dec 6, 2012, at 3:56 PM, Eric Osterweil = wrote: > My 0.02, I worry that your web interface is inadequate for the = eventual secure provisioning of router certs. I'm curious what sort of UI you would recommend for provisioning router = certs. There's not a fundamental difference between trusting TLS to = deliver HTTPS and trusting, say, SSH to protect your router CLI. =20 Any UI presents a point of vulnerability. I don't really see a reason = to pick on web apps in this context. --Richard= From eosterweil@verisign.com Thu Dec 6 13:20: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 E38F611E809B for ; Thu, 6 Dec 2012 13:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.682 X-Spam-Level: X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=0.917, 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 oLLptZpVUdZc for ; Thu, 6 Dec 2012 13:20:14 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 920A511E8097 for ; Thu, 6 Dec 2012 13:20:06 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUMEMA1KpwacCs3PeaQIo+ktKzMZ/bi6m@postini.com; Thu, 06 Dec 2012 13:20: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 qB6LK02U020472; Thu, 6 Dec 2012 16:20:00 -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); Thu, 6 Dec 2012 16:20:00 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> Date: Thu, 6 Dec 2012 16:20:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 21:20:00.0461 (UTC) FILETIME=[7312D7D0:01CDD3F7] 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, 06 Dec 2012 21:20:19 -0000 On Dec 6, 2012, at 4:12 PM, Richard Barnes wrote: >> My 0.02, I worry that your web interface is inadequate for the = eventual secure provisioning of router certs. >=20 > I'm curious what sort of UI you would recommend for provisioning = router certs. =20 As I thought I had outlined, the fundamental problem is in the hosted = model. I don't think data owners/operators should be captive to = external systemic dependencies in this case. > There's not a fundamental difference between trusting TLS to deliver = HTTPS and trusting, say, SSH to protect your router CLI. =20 Right, they're both dangerous choices when you do them over the = vast/untrusted/public interwebz compared to doing provisioning in = house... Not sure where you're going with this... > Any UI presents a point of vulnerability. I don't really see a reason = to pick on web apps in this context. No... there's a lot of systemic dependencies that get roped in when you = start doing these things out over the Internet vs. in your NOC. Eric= From rbarnes@bbn.com Thu Dec 6 13:59: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 C982221F8780 for ; Thu, 6 Dec 2012 13:59:51 -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=[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 YvZ2wwKupbC6 for ; Thu, 6 Dec 2012 13:59:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 53CFC21F876B for ; Thu, 6 Dec 2012 13:59:51 -0800 (PST) Received: from ros-dhcp192-1-51-58.bbn.com ([192.1.51.58]:60479) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TgjTv-0006mP-OM; Thu, 06 Dec 2012 16:59:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> Date: Thu, 6 Dec 2012 16:59:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1499) 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, 06 Dec 2012 21:59:51 -0000 On Dec 6, 2012, at 4:20 PM, Eric Osterweil = wrote: >=20 > On Dec 6, 2012, at 4:12 PM, Richard Barnes wrote: >=20 >>> My 0.02, I worry that your web interface is inadequate for the = eventual secure provisioning of router certs. >>=20 >> I'm curious what sort of UI you would recommend for provisioning = router certs. =20 >=20 > As I thought I had outlined, the fundamental problem is in the hosted = model. I don't think data owners/operators should be captive to = external systemic dependencies in this case. >=20 >> There's not a fundamental difference between trusting TLS to deliver = HTTPS and trusting, say, SSH to protect your router CLI. =20 >=20 > Right, they're both dangerous choices when you do them over the = vast/untrusted/public interwebz compared to doing provisioning in = house... Not sure where you're going with this... >=20 >> Any UI presents a point of vulnerability. I don't really see a = reason to pick on web apps in this context. >=20 > No... there's a lot of systemic dependencies that get roped in when = you start doing these things out over the Internet vs. in your NOC. As Chris mentioned down-thread: Could you explain how these = considerations differ from considerations around hosted services for = critical services, e.g., DNSSEC? --Richard= From eosterweil@verisign.com Thu Dec 6 14:11: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 B05CB21F87CC for ; Thu, 6 Dec 2012 14:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.296 X-Spam-Level: X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[AWL=-0.697, 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 gDKq4YU+D6-d for ; Thu, 6 Dec 2012 14:11:25 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 56E6421F8659 for ; Thu, 6 Dec 2012 14:11:22 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUMEYB8O6/KCx3Td6hnN9RIMzXwpltFI1@postini.com; Thu, 06 Dec 2012 14:11:24 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 qB6MBJl6022063; Thu, 6 Dec 2012 17:11:19 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Dec 2012 17:11:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> Date: Thu, 6 Dec 2012 17:11:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 22:11:18.0993 (UTC) FILETIME=[9E058C10:01CDD3FE] 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, 06 Dec 2012 22:11:30 -0000 > As Chris mentioned down-thread: Could you explain how these = considerations differ from considerations around hosted services for = critical services, e.g., DNSSEC? This system (and therefore, its considerations) is/are VASTLY different = than those of DNSSEC... In a lot of ways: 1 - This repository system requires RPs to have a FULLY synchronized = copy of all objects at all times. DNSSEC does not. a - This means all systems have to be high = performing/reachable/etc. or there begin to be problems b - This means that global crawling must be done before = computation can be reliable c - ... 2 - This system's hosting model is proposing to put all of the object = generation information in a very few places (the hosted model), DNSSEC = does not (the hosting colocation coefficient in DNSSEC is vastly = different that 5, for rpki) a - I am not even encouraged to have all my DNS zones hosted by = RIRs... I can get a registrar or hoster to do it, but I can choose from = many many options... b - ... 3 - The downside of borking routing is all your [connectivity] bases are = belong to us... Lots of problems exist when destinations are unreachable = that do not exist (or are semantically different) when names are = unresolvable. In short, these are very different systems, with _very_ = different architectures, with very _very_ different goals, etc. I could = go on, but is this sufficient? Eric= From rbarnes@bbn.com Thu Dec 6 14:42: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 F2A7C21F8773 for ; Thu, 6 Dec 2012 14:42:27 -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=[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 j3GNyVzQfDEe for ; Thu, 6 Dec 2012 14:42:27 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E50121F8728 for ; Thu, 6 Dec 2012 14:42:27 -0800 (PST) Received: from ros-dhcp192-1-51-58.bbn.com ([192.1.51.58]:60757) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tgk9B-00078E-44; Thu, 06 Dec 2012 17:42:25 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> Date: Thu, 6 Dec 2012 17:42:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1499) 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, 06 Dec 2012 22:42:28 -0000 On Dec 6, 2012, at 5:11 PM, Eric Osterweil = wrote: >> As Chris mentioned down-thread: Could you explain how these = considerations differ from considerations around hosted services for = critical services, e.g., DNSSEC? >=20 > This system (and therefore, its considerations) is/are VASTLY = different than those of DNSSEC... In a lot of ways: > 1 - This repository system requires RPs to have a FULLY synchronized = copy of all objects at all times. DNSSEC does not. > a - This means all systems have to be high = performing/reachable/etc. or there begin to be problems > b - This means that global crawling must be done before = computation can be reliable > c - =85 DNSSEC requires you to have up-to-date information on all the things you = care about. It's just that in BGPSEC, everyone cares about everything = :) W.r.t. (a) -- Doesn't this argue in favor of hosting? Isn't the "all" = less burdensome if there are fewer things to keep alive? I know I would = rather have my web site on Dreamhost than on my on host in a colo. W.r.t. (b) -- Again, this seems to argue in favor of the hosted model, = since you have to crawl fewer repos. =20 And it's not really true that you have to crawl the whole tree before = you can do anything. If you have a partial tree, then you can validate = part of the ROAs. Especially if you crawl intelligently, e.g., trying = to avoid missing links in a cert chain. I believe that RPSTIR does = something like this. > 2 - This system's hosting model is proposing to put all of the object = generation information in a very few places (the hosted model), DNSSEC = does not (the hosting colocation coefficient in DNSSEC is vastly = different that 5, for rpki) > a - I am not even encouraged to have all my DNS zones hosted by = RIRs... I can get a registrar or hoster to do it, but I can choose from = many many options... > b - =85 Not sure where you're going with this. I thought you were arguing that = the hosting model in general was a bad technology, which would not = depend on the coefficient or which entities were doing the hosting. > 3 - The downside of borking routing is all your [connectivity] bases = are belong to us... Lots of problems exist when destinations are = unreachable that do not exist (or are semantically different) when names = are unresolvable. In short, these are very different systems, with = _very_ different architectures, with very _very_ different goals, etc. = I could go on, but is this sufficient? Different services have different values for different networks. There = are certainly lots of stakeholders for whom loss of DNS reachability = would be as bad as loss of IP reachability, as would seem to be attested = by the predominant focus in the cyber crime community on DNS hijacking = rather than BGP hijacking. To be clear, I have no particular dog in this fight. I'm not even = really clear on why this discussion is happening on the SIDR list, given = that it's a deployment decision between an CA and its customers. =20 --Richard= From aservin@lacnic.net Thu Dec 6 14:55: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 5967021F8773 for ; Thu, 6 Dec 2012 14:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.585 X-Spam-Level: ** X-Spam-Status: No, score=2.585 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_42=0.6, RCVD_IN_XBL=3.033, 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 x-dtGUivQnVM for ; Thu, 6 Dec 2012 14:55:05 -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 6DCE321F8774 for ; Thu, 6 Dec 2012 14:55:05 -0800 (PST) Received: from MiniR2D2.local (unknown [187.33.33.158]) by mail.lacnic.net.uy (Postfix) with ESMTP id 83F4C30843C; Thu, 6 Dec 2012 20:54:46 -0200 (UYST) Message-ID: <50C1222F.5080309@lacnic.net> Date: Thu, 06 Dec 2012 20:54:39 -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: Eric Osterweil References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> In-Reply-To: X-Enigmail-Version: 1.4.6 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 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, 06 Dec 2012 22:55:06 -0000 Eric Chris said much better than me. Hosted rpki is like the "go-daddy" of RPKI. It is intended as a bootstraping solution to take rpki up. The hosted solution is not aimed to everybody, it is aimed to small/medium operators that otherwise would struggle to sign their resources, run a CA, and run a repository. Large operators DO NOT need to use the hosted solution, they can if they want but they can run their own CAs and they should. If a hosted ISP wants to go to up/down and run their own CA they can do that with a key-rollover and a "make before break" strategy. About the EE certs for router I didn't explain correctly. Hosted solution do not have it now because they haven't been defined yet (we are still arguing about BGPSEC specs). However, in the moment that the specs are ready router certs will be supported. Regards, as On 06/12/2012 18:56, Eric Osterweil wrote: > > On Dec 6, 2012, at 2:33 PM, Arturo Servin wrote: > >> Yes, the hosted keep your private key, but you can modify your ROAs >> anytime you want. At least the hosted systems that I know provide a web >> interface to do that. The ROA would be published immediately or a few >> minute/hours later, depending of the rpki-operator (my personal view and >> with my network operator hat on is that it should be immediately or in >> minutes). > > That's all fine and dandy, and while I agree with what Russ said in his response, you should note that I did say, ``no big deal.'' That said, after thinking about what Russ said and your response, I actually do think this is a big deal... now... ;) > > If/when I (as a prospective user of the system) decide to move my information from your hostage model to my own repository, how will I be able to migrate the private portion of my certificate from _your_ hosted system to my own? How are we doing this private key exchange? Do you realize that you won't be able to use an HSM at all if the private portion will ever need to be exported? Maybe I missed that part of the explanation? > >> You could argue that effectively the hosted system "does it for you" >> and "you require conversation with them", but the way described is a bit >> misleading because it gives the impression that it is a slow or >> human-driven process when in reality its not. > > Sorry, this was just a colloquialism... Not meant to be misleading. I understand that this would likely be a web interface, or whatever. That said, in either case, aren't we now saying that for someone to update their secure routing information, they need to go through you? Is that a Single Point of Failure (SPF)? What if your web interface is being DDoS'ed when I need to update my ROA (perhaps because _I'm_ being DDoS'ed and am engaging a DDoS mitigation service for the first time)? Anyway, these are (as I said) complexities to note.... > >> >> As for EE cert for routers those do not exist yet in the rpki-operator >> systems (AFAIK), so anything here would be a guess. > > I seriously disagree here... We are building a system that is intended to do this! The rpki must have router certs in it (according to the bgpsec design), and we therefore must to be proactive in evaluating that aspect. In the above hosted model, you absolutely will be on the hook for this, and if you invest in a system whose design will be architecturally (or even operationally) unable to accommodate this eventuality, you are doing yourself a _huge_ disservice by ignoring the writing on the wall. The bottom line is, there needs to be some thinking around this, or it will bite all of us (I have packets on the interwebz too). > > My 0.02, I worry that your web interface is inadequate for the eventual secure provisioning of router certs. > > Eric > From eosterweil@verisign.com Thu Dec 6 14:57: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 0262121F86EA for ; Thu, 6 Dec 2012 14:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=0.880, 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 m8bwkKjxvi6S for ; Thu, 6 Dec 2012 14:57:27 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id D28F621F86E7 for ; Thu, 6 Dec 2012 14:57:24 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUMEi0fS6LdGWYh236nzXeiI1A6oBZhv+@postini.com; Thu, 06 Dec 2012 14:57:27 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 qB6MvIo1015642; Thu, 6 Dec 2012 17:57:18 -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); Thu, 6 Dec 2012 17:57:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> Date: Thu, 6 Dec 2012 17:57:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6CEBEA58-8F12-4B1B-8669-B159E4F5AC02@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> To: Richard Barnes X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 22:57:18.0398 (UTC) FILETIME=[0AC155E0:01CDD405] 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, 06 Dec 2012 22:57:28 -0000 On Dec 6, 2012, at 5:42 PM, Richard Barnes wrote: > DNSSEC requires you to have up-to-date information on all the things = you care about. It's just that in BGPSEC, everyone cares about = everything :) Uh... big difference. DNSSEC doesn't require you to care about anything = before you need it (on demand). RPKI is prefetching... I can't really = outline the architectural difference better than that. > W.r.t. (a) -- Doesn't this argue in favor of hosting? Isn't the "all" = less burdensome if there are fewer things to keep alive? I know I would = rather have my web site on Dreamhost than on my on host in a colo. Nope, it doesn't. It actually points out that hosting's myopic benefits = are fools-gold, and they come with a much more dangerous price tag. = Your choice of dreamhost is a _choice_, not a mandate from a set of 5 = options. Fundamentally different. > W.r.t. (b) -- Again, this seems to argue in favor of the hosted model, = since you have to crawl fewer repos. =20 Again, I fear you've missed the point. This points out that there is a = _fundamental_flaw_ in the architecture. You inherit the instability and = latency of all hosted environments all over the world, and you are = captive until it is resolved. This is an architectural issue. > And it's not really true that you have to crawl the whole tree before = you can do anything. If you have a partial tree, then you can validate = part of the ROAs. Especially if you crawl intelligently, e.g., trying = to avoid missing links in a cert chain. I believe that RPSTIR does = something like this. So, if I need _you_ (an RP) to get my ROA because I've just come under = attack, do you think it's OK to just schedule me for later? That's not = going to help you reach the critical services that I might be offering. = I'd call that, seriously suboptimal engineering. ;) Architecturally, it = would be better to reach out for information when you need it... In = fact, that's kinda how other name mapping systems that you might have = mentioned earlier do it... ;) > Not sure where you're going with this. I thought you were arguing = that the hosting model in general was a bad technology, which would not = depend on the coefficient or which entities were doing the hosting. I am, and it doesn't. I was, and am, illustrating for you how inapt the = comparison is. > Different services have different values for different networks. = There are certainly lots of stakeholders for whom loss of DNS = reachability would be as bad as loss of IP reachability, as would seem = to be attested by the predominant focus in the cyber crime community on = DNS hijacking rather than BGP hijacking. Sorry, a quick look at my dayjob might inform you of the fact that I put = a high price on the importance of DNS... ;) That said, I have to say = that the cybercime analogy is pretty weak. How about, the angle where = cyber criminals DDoS a company and they come to someone (maybe us?) for = DDoS remediation _through_BGP_? That work fer ya? ;) > To be clear, I have no particular dog in this fight. I'm not even = really clear on why this discussion is happening on the SIDR list, given = that it's a deployment decision between an CA and its customers. =20 This is a deployment discussion about the rpki infrastructure, which has = quite a bit to do w/ sidr. Eric= From eosterweil@verisign.com Thu Dec 6 15:03: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 13E7421F857C for ; Thu, 6 Dec 2012 15:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, J_CHICKENPOX_42=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 ffg+HOfsRY1Y for ; Thu, 6 Dec 2012 15:03:24 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1DA21F8575 for ; Thu, 6 Dec 2012 15:03:23 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUMEkOmEDSfLM4gvgOg2EmIqRGOQiO7aJ@postini.com; Thu, 06 Dec 2012 15:03:24 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 qB6N3JXf015852; Thu, 6 Dec 2012 18:03:19 -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); Thu, 6 Dec 2012 18:03:19 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50C1222F.5080309@lacnic.net> Date: Thu, 6 Dec 2012 18:03:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <50C1222F.5080309@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 23:03:19.0253 (UTC) FILETIME=[E1D77050:01CDD405] 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, 06 Dec 2012 23:03:25 -0000 On Dec 6, 2012, at 5:54 PM, Arturo Servin wrote: > Eric >=20 > Chris said much better than me. Hosted rpki is like the = "go-daddy" of > RPKI. It is intended as a bootstraping solution to take rpki up. Maybe you can help me answer the questions I posed in my last email = then? :-P > The hosted solution is not aimed to everybody, it is aimed to > small/medium operators that otherwise would struggle to sign their > resources, run a CA, and run a repository. How do they get their private keys from you? This is important to think = through _now_ before it becomes an operational blackhole... Also, what = happens if you get DDoS'ed and I need your services? In DNS, there are = a lot of registrars to choose from, and no single point of failure... = The RIRs are not as plentiful in numbers as them, so you are a higher = value target this way... > Large operators DO NOT need to use the hosted solution, they can = if > they want but they can run their own CAs and they should. Anyone who uses you would need these services, it seems like it would be = worth working out the ``what ifs,'' no? > About the EE certs for router I didn't explain correctly. Hosted > solution do not have it now because they haven't been defined yet (we > are still arguing about BGPSEC specs). However, in the moment that the > specs are ready router certs will be supported. If we've enshrined operations and practices (i.e. the hosted/HSM model) = because we didn't think through the complexities, and that later impedes = our needs, then we have been negligent. This seems like a pretty = serious problem and it ought to be worked out now before we decide = people should be doing the hosted anything. Eric= From eosterweil@verisign.com Thu Dec 6 15:04: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 CC54E21F86CE for ; Thu, 6 Dec 2012 15:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fbY8HLaYLcKC for ; Thu, 6 Dec 2012 15:04:21 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 002FF21F85C7 for ; Thu, 6 Dec 2012 15:04:20 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUMEkc9DGxtZf2H538+/yKCn37H5AngZU@postini.com; Thu, 06 Dec 2012 15:04:21 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 qB6N4Ihv023569; Thu, 6 Dec 2012 18:04:18 -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); Thu, 6 Dec 2012 18:04:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 6 Dec 2012 18:04:18 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6B3BBF5C-DC81-4CEF-AF57-EB6065BB97FB@verisign.com> References: <20121022150307.1824.50258.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 06 Dec 2012 23:04:18.0708 (UTC) FILETIME=[05478D40:01CDD406] 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: Thu, 06 Dec 2012 23:04:21 -0000 On Nov 30, 2012, at 6:41 PM, Randy Bush wrote: >> 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. Too bad you can't click on the link to review them. ;) Eric From russw@riw.us Thu Dec 6 15:35: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 7F56421F86A8 for ; Thu, 6 Dec 2012 15:35:16 -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 BZz9zXdleEfO for ; Thu, 6 Dec 2012 15:35:15 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5BB21F86A7 for ; Thu, 6 Dec 2012 15:35:15 -0800 (PST) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.117]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TgkyI-0001v3-PH for sidr@ietf.org; Thu, 06 Dec 2012 15:35:14 -0800 Message-ID: <50C12BA5.70503@riw.us> Date: Thu, 06 Dec 2012 18:35:01 -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> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> In-Reply-To: <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> Content-Type: text/plain; charset=windows-1252 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: Thu, 06 Dec 2012 23:35:16 -0000 > And it's not really true that you have to crawl the whole tree before you can do anything. If you have a partial tree, then you can validate part of the ROAs. Especially if you crawl intelligently, e.g., trying to avoid missing links in a cert chain. I believe that RPSTIR does something like this. The simplest way to explain this is that you've created a three way dependency here --the routing system is dependent on the RPKI, which is in turn dependent on the hosting service, which is in turn dependent on the routing system, but you have the third interaction with the RPKI itself. You've gone from three moving parts on the protocol side to three, which makes it more complex. On the human side, you've added the complexity of yet another contractural relationship, which makes things more complex there, adding more places to make mistakes. So adding another moving piece makes things more complex, which will make an already fragile system more fragile. :-) Russ -- <>< riwhite@verisign.com russw@riw.us From dougm@nist.gov Thu Dec 6 16:01: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 40C4A21F86EE for ; Thu, 6 Dec 2012 16:01:22 -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 4v6TBpkElsp4 for ; Thu, 6 Dec 2012 16:01:21 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id EDA8D21F86CE for ; Thu, 6 Dec 2012 16:01:20 -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, 6 Dec 2012 19:00:51 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 6 Dec 2012 18:58:34 -0500 From: "Montgomery, Douglas" To: Eric Osterweil , Richard Barnes Importance: low X-Priority: 5 Date: Thu, 6 Dec 2012 19:00:42 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3UDZmepRnQ36yKRcGmccwvjqLYbQ== Message-ID: In-Reply-To: <6CEBEA58-8F12-4B1B-8669-B159E4F5AC02@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 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, 07 Dec 2012 00:01:22 -0000 On 12/6/12 5:57 PM, "Eric Osterweil" wrote: > >On Dec 6, 2012, at 5:42 PM, Richard Barnes wrote: > >> DNSSEC requires you to have up-to-date information on all the things >>you care about. It's just that in BGPSEC, everyone cares about >>everything :) > >Uh... big difference. DNSSEC doesn't require you to care about anything >before you need it (on demand). RPKI is prefetching... I can't really >outline the architectural difference better than that. So this seems to be about sub-system behavior in various transient states. Cold start of a relying party, when there are no other "hot" instances in contact. While some will argue that one can engineer redundant systems, and smart RPs (e.g., that initialize with last running check-pointed state at boot), still I will admit that one could envisions firing up a new RP, just out of the box, for the first time and it taking time to load its initial state. Won't a demand driven system will experience something very similar when first fired up and and a full table dump comes across the wire in BGP? If a demand driven system wasn't smart enough to use a hot standby with significant cached state, it too will suffer the latency of pulling a significant portion of the data it needs instantly. While I see the architectural differences in those two, it is not clear to me that the end result to a running BGP system that uses them is all that different. Once either approach has achieved steady state, assuming there was some caching done in the demand based system, if the cache holding time of demand queries was the same as the poling interval of the RP, do you think the responsive ness of a change of authoritative info is all that different? Or do you not assume there will be any caching in a demand based system? And if so, would you be concerned about the peers * full_table number of queries that would result from a router reboot? Truly just asking to understand ... Dougm From aservin@lacnic.net Thu Dec 6 17:59: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 5874021F8550 for ; Thu, 6 Dec 2012 17:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 lJ8P40sFNhjm for ; Thu, 6 Dec 2012 17:59:16 -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 6325321F854E for ; Thu, 6 Dec 2012 17:59:16 -0800 (PST) Received: from www.lacnic.net.uy (localhost [IPv6:::1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 5047C308445; Thu, 6 Dec 2012 23:59:11 -0200 (UYST) Received: from 187.33.33.158 (proxying for 10.125.134.158) (SquirrelMail authenticated user aservin) by www.lacnic.net.uy with HTTP; Thu, 6 Dec 2012 23:59:11 -0200 (UYST) Message-ID: <56627.187.33.33.158.1354845551.squirrel@www.lacnic.net.uy> In-Reply-To: References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <50C1222F.5080309@lacnic.net> Date: Thu, 6 Dec 2012 23:59:11 -0200 (UYST) From: aservin@lacnic.net To: "Eric Osterweil" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 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, 07 Dec 2012 01:59:17 -0000 Inline. > > On Dec 6, 2012, at 5:54 PM, Arturo Servin wrote: > >> Eric >> >> Chris said much better than me. Hosted rpki is like the "go-daddy" of >> RPKI. It is intended as a bootstraping solution to take rpki up. > > Maybe you can help me answer the questions I posed in my last email then? > :-P > I tried, but may be I was not clear. >> The hosted solution is not aimed to everybody, it is aimed to >> small/medium operators that otherwise would struggle to sign their >> resources, run a CA, and run a repository. > > How do they get their private keys from you? This is important to think > through _now_ before it becomes an operational blackhole... "If a hosted ISP wants to go to up/down and run their own CA they can do that with a key-rollover and a "make before break" strategy." In other words, you cannot. You can generate your own and make-before-break by publishing your new shiny cert with your own CA and then revoking the old one. >Also, what > happens if you get DDoS'ed and I need your services? In DNS, there are a > lot of registrars to choose from, and no single point of failure... There could be more hosted providers. RIRs are by not means the only ones. In fact, it would be very similar to the registry-registar model. >The > RIRs are not as plentiful in numbers as them, so you are a higher value > target this way... The whole scenario does not seem to different to me if you host your DNS services and your registrar/hosted are DDoSed and you cannot change your NS records. And in the same fashion to DNS hosted solutions, RPKI-hosted are aimed to specific organizations. If you want to be independent from any hosted solution, run your own DNS servers or your own CA. The fact that hosted solutions are not DDoS resistant today does not mean that they cannot be in the future. > >> Large operators DO NOT need to use the hosted solution, they can if >> they want but they can run their own CAs and they should. > > Anyone who uses you would need these services, it seems like it would be > worth working out the ``what ifs,'' no? This (RPKI in general, repositories, hosted solution) is very new and still evolving. I take your concerns very seriously and a value input for improvement. > >> About the EE certs for router I didn't explain correctly. Hosted >> solution do not have it now because they haven't been defined yet (we >> are still arguing about BGPSEC specs). However, in the moment that the >> specs are ready router certs will be supported. > > If we've enshrined operations and practices (i.e. the hosted/HSM model) > because we didn't think through the complexities, and that later impedes > our needs, then we have been negligent. This seems like a pretty serious > problem and it ought to be worked out now before we decide people should > be doing the hosted anything. I found a bit hard to engineer a system without specs. I thought that this thread was about precisely about BGPSEC specs. Once we have the specs, then hosted-rpki solutions can incorporate them. > > Eric Regards, /as From aservin@lacnic.net Thu Dec 6 18:09: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 D41C221F86CE for ; Thu, 6 Dec 2012 18:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 BfH5ZjKZkm4a for ; Thu, 6 Dec 2012 18:09: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 4017E21F86B7 for ; Thu, 6 Dec 2012 18:09:17 -0800 (PST) Received: from www.lacnic.net.uy (localhost [IPv6:::1]) by mail.lacnic.net.uy (Postfix) with ESMTP id C3B8E30843C; Fri, 7 Dec 2012 00:09:06 -0200 (UYST) Received: from 187.33.33.158 (proxying for 10.125.134.158) (SquirrelMail authenticated user aservin) by www.lacnic.net.uy with HTTP; Fri, 7 Dec 2012 00:09:06 -0200 (UYST) Message-ID: <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> In-Reply-To: <50C12BA5.70503@riw.us> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> <50C12BA5.70503@riw.us> Date: Fri, 7 Dec 2012 00:09:06 -0200 (UYST) From: aservin@lacnic.net To: "Russ White" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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 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, 07 Dec 2012 02:09:17 -0000 Russ, I think you are twisting the facts on your own convenience. RPKI != RPKI-hosted solutions. And RPKI is not dependant on the RPKI-hosted solutions in the same way that DNS is not dependant in the DNS-hosted solutions. Regards, .as > >> And it's not really true that you have to crawl the whole tree before >> you can do anything. If you have a partial tree, then you can validate >> part of the ROAs. Especially if you crawl intelligently, e.g., trying >> to avoid missing links in a cert chain. I believe that RPSTIR does >> something like this. > > The simplest way to explain this is that you've created a three way > dependency here --the routing system is dependent on the RPKI, which is > in turn dependent on the hosting service, which is in turn dependent on > the routing system, but you have the third interaction with the RPKI > itself. > > You've gone from three moving parts on the protocol side to three, which > makes it more complex. On the human side, you've added the complexity of > yet another contractural relationship, which makes things more complex > there, adding more places to make mistakes. > > So adding another moving piece makes things more complex, which will > make an already fragile system more fragile. > > :-) > > Russ > > > -- > <>< > riwhite@verisign.com > russw@riw.us > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From eosterweil@verisign.com Thu Dec 6 19:03: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 6CA2721F8792 for ; Thu, 6 Dec 2012 19:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.695, 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 DEo5kAfkKSWj for ; Thu, 6 Dec 2012 19:03:19 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9217221F86FC for ; Thu, 6 Dec 2012 19:03:19 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUMFcc2VK8k20vIqtlDwG/7wIk9i8hJbM@postini.com; Thu, 06 Dec 2012 19:03:19 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 qB733CJu022886; Thu, 6 Dec 2012 22:03:15 -0500 Received: from [10.100.1.42] ([10.100.1.42]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Dec 2012 22:03:12 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil X-Priority: 5 In-Reply-To: Date: Thu, 6 Dec 2012 22:03:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Dec 2012 03:03:12.0104 (UTC) FILETIME=[64A63680:01CDD427] 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, 07 Dec 2012 03:03:20 -0000 On Dec 6, 2012, at 7:00 PM, Montgomery, Douglas wrote: >=20 > On 12/6/12 5:57 PM, "Eric Osterweil" wrote: >>=20 >> Uh... big difference. DNSSEC doesn't require you to care about = anything >> before you need it (on demand). RPKI is prefetching... I can't = really >> outline the architectural difference better than that. >=20 > So this seems to be about sub-system behavior in various transient = states. > Cold start of a relying party, when there are no other "hot" instances = in > contact. While some will argue that one can engineer redundant = systems, > and smart RPs (e.g., that initialize with last running check-pointed = state > at boot), still I will admit that one could envisions firing up a new = RP, > just out of the box, for the first time and it taking time to load its > initial state. I was hoping we could all see from my quoted text above that this latest = discussion is about the _architectural_ difference between the on-demand = soft-state DNS system, and the prefetching replicated state machine of = RPKI. These two are fundamentally very different architectural models. = Your comments about boot states are interesting, but somewhat off topic = to this post, imho. > Won't a demand driven system will experience something very similar = when > first fired up and and a full table dump comes across the wire in BGP? Ask any of the operators on this list how they feel about full table = dumps and routers refreshing table state, configs, etc when coming = online. If you're saying that RPKI is just like that, I think you just = sank your position. > If a demand driven system wasn't smart enough to use a hot standby = with > significant cached state, it too will suffer the latency of pulling a > significant portion of the data it needs instantly. Again, we were discussing the architectural difference, not polishing = the chrome on the titanic. :) > While I see the architectural differences in those two, it is not = clear to > me that the end result to a running BGP system that uses them is all = that > different. Hmm.. Well, re: my comment above, we have very different opinions. I = (literally) defer to operators to answer my above question, and if I'm = rebuffed on that, then so be it. > Once either approach has achieved steady state, assuming there was = some > caching done in the demand based system, if the cache holding time of > demand queries was the same as the poling interval of the RP, do you = think > the responsive ness of a change of authoritative info is all that > different? I honestly have to say that I don't know how I could tell at this point. = I think it would be good for someone to put forward a model, do some = simulation/measurements and present some analysis. I don't know when = BGP is in ``steady state'' or what you might mean by that, but it seems = like a good time for us to be more quantitative and less qualitative. > Or do you not assume there will be any caching in a demand based = system? > And if so, would you be concerned about the peers * full_table number = of > queries that would result from a router reboot? I honestly don't understand this last part, but I'm hoping my comments = and questions (above) address it? Eric= From eosterweil@verisign.com Thu Dec 6 19:10: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 8805E21F8643 for ; Thu, 6 Dec 2012 19:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.658 X-Spam-Level: X-Spam-Status: No, score=-5.658 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, J_CHICKENPOX_42=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 CbBI6xjcmMBC for ; Thu, 6 Dec 2012 19:10:09 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4080B21F858E for ; Thu, 6 Dec 2012 19:10:07 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUMFeDkiX2cUxQaYwMyyA84jpfNYh8M41@postini.com; Thu, 06 Dec 2012 19:10:09 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 qB73A2Dt023079; Thu, 6 Dec 2012 22:10:02 -0500 Received: from [10.100.1.42] ([10.100.1.42]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Dec 2012 22:10:02 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil X-Priority: 3 (Normal) In-Reply-To: <56627.187.33.33.158.1354845551.squirrel@www.lacnic.net.uy> Date: Thu, 6 Dec 2012 22:10:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45AF8CD6-C785-4055-B07D-A3880A2174F5@verisign.com> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <50C1222F.5080309@lacnic.net> <56627.187.33.33.158.1354845551.squirrel@www.lacnic.net.uy> To: X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Dec 2012 03:10:02.0180 (UTC) FILETIME=[5912D840:01CDD428] 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, 07 Dec 2012 03:10:10 -0000 > There could be more hosted providers. RIRs are by not means the only = ones. > In fact, it would be very similar to the registry-registar model. Well, I am more partial to your first comment (not just RIRs), but I = think it is very _very_ different than the registrant, registrar, = registry model. > The whole scenario does not seem to different to me if you host your = DNS > services and your registrar/hosted are DDoSed and you cannot change = your > NS records. If _your_ registrar gets DDoS'ed, but _mine_ does not, I'll be fine. = THe interface between registrars and the registry is not open for others = to bang on. It's out there, but the front door is not in broad view of = the street. > And in the same fashion to DNS hosted solutions, RPKI-hosted are aimed = to > specific organizations. If you want to be independent from any hosted > solution, run your own DNS servers or your own CA. Actually, this was my point. > The fact that hosted solutions are not DDoS resistant today does not = mean > that they cannot be in the future. The fact that we're painting the floor doesn't mean we'll paint = ourselves into a corner either. Yet, if we aren't careful... > This (RPKI in general, repositories, hosted solution) is very new and > still evolving. I take your concerns very seriously and a value input = for > improvement. Thanks, I appreciate that. > I found a bit hard to engineer a system without specs. I thought that = this > thread was about precisely about BGPSEC specs. Once we have the specs, > then hosted-rpki solutions can incorporate them. Well, we _ought_ to be talking about requirements, and that ought to = shape the specs. That said, I think it is plain to all that BGPsec is = planning to put router EE certs into the RPKI, and that caches will need = to fetch them. The rest... well, that's a separate thread about = requirements. :) Eric= From ttauber@1-4-5.net Thu Dec 6 20:17: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 4A07111E80D2 for ; Thu, 6 Dec 2012 20:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 3U-DFHPKSc15 for ; Thu, 6 Dec 2012 20:17:24 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A752211E80AE for ; Thu, 6 Dec 2012 20:17:24 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so73911obc.31 for ; Thu, 06 Dec 2012 20:17:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Gf/OcM48e3vKK0cYVdfZgs52KMKFz0yMIIa3Sw9RiSo=; b=KZ/dIBV9/3/NZzKtjubUHbwj4mSeIryxqA5GcaUjB4I6CqrGBqexPYpyGoq+ogsy3D pIjXPy+n1Crl7o0wUojOPKud7eM8idQSJqUyjqVVNUOxxpE0DwDNMafw0NQ0BJZZf78K 8P+RBnlL3dLWrYBnzCqxksGRSieJUCvvNoJSXHo63xVN2MwX8xXCBXRayoFMrDL0R4Om ktWgATmc3ah+bAziPoaHt8omuuNL5UJgXimNdPwFaGGULfIILxmiPYKY73NYKbUnxvBO LJPXboZhW10bs3ZMno5V/WTDFSpi5M48AX/0TO1a5s4a5gRXeFFoYMy82CI575vaUTjt 20pA== MIME-Version: 1.0 Received: by 10.60.1.42 with SMTP id 10mr2498922oej.125.1354853844134; Thu, 06 Dec 2012 20:17:24 -0800 (PST) Received: by 10.76.153.99 with HTTP; Thu, 6 Dec 2012 20:17:23 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> References: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> Date: Thu, 6 Dec 2012 23:17:23 -0500 Message-ID: From: Tony Tauber To: Eric Osterweil Content-Type: multipart/alternative; boundary=e89a8fb1fe181a2a4a04d03b7e02 X-Gm-Message-State: ALoCoQnVXquwsgKh0qs6k25QiFOVjnzwiNNNKMiXzcJSw6UVKutYQ17X18Y39f2LlwqvZpKUeay/ 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, 07 Dec 2012 04:17:25 -0000 --e89a8fb1fe181a2a4a04d03b7e02 Content-Type: text/plain; charset=ISO-8859-1 Hello, Joe Operator here. I don't want to interrupt the tiresome food-fight, but would like to more clearly understand how this alternative system would work. I may have lost the thread in the roiling sea of presumptions that's got this discussion bouncing hither, yon, and back again. I didn't change the subject line, but feel free to do so if needed. Tony > > Won't a demand driven system will experience something very similar when > > first fired up and and a full table dump comes across the wire in BGP? > > Ask any of the operators on this list how they feel about full table dumps > and routers refreshing table state, configs, etc when coming online. If > you're saying that RPKI is just like that, I think you just sank your > position. > > > If a demand driven system wasn't smart enough to use a hot standby with > > significant cached state, it too will suffer the latency of pulling a > > significant portion of the data it needs instantly. > > Again, we were discussing the architectural difference, not polishing the > chrome on the titanic. :) > > > While I see the architectural differences in those two, it is not clear > to > > me that the end result to a running BGP system that uses them is all that > > different. > > Hmm.. Well, re: my comment above, we have very different opinions. I > (literally) defer to operators to answer my above question, and if I'm > rebuffed on that, then so be it. > --e89a8fb1fe181a2a4a04d03b7e02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

Joe Operator here.

I don't want to interrupt the = tiresome food-fight, but would like to more clearly understand how this alt= ernative system would work.
I may have lost the thread in the roiling se= a of presumptions that's got this discussion bouncing hither, yon, and = back again.

I didn't change the subject line, but feel free to do so if needed.=

Tony

=A0
> Won't a demand driven system will experience something very simila= r when
> first fired up and and a full table dump comes across the wire in BGP?=

Ask any of the operators on this list how they feel about full table = dumps and routers refreshing table state, configs, etc when coming online. = =A0If you're saying that RPKI is just like that, I think you just sank = your position.

> If a demand driven system wasn't smart enough to use a hot standby= with
> significant cached state, it too will suffer the latency of pulling a<= br> > significant portion of the data it needs instantly.

Again, we were discussing the architectural difference, not polishing= the chrome on the titanic. :)

> While I see the architectural differences in those two, it is not clea= r to
> me that the end result to a running BGP system that uses them is all t= hat
> different.

Hmm.. Well, re: my comment above, we have very different opinions. = =A0I (literally) defer to operators to answer my above question, and if I&#= 39;m rebuffed on that, then so be it.
--e89a8fb1fe181a2a4a04d03b7e02-- From enkechen@cisco.com Thu Dec 6 20:18: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 DD3B311E80D2 for ; Thu, 6 Dec 2012 20:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fz2ZmAZPIKzn for ; Thu, 6 Dec 2012 20:18:29 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 14FDC11E80AE for ; Thu, 6 Dec 2012 20:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=810; q=dns/txt; s=iport; t=1354853909; x=1356063509; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=T1cAPNMNNvuWOFEbPfbLDtTVX0pe5rY5QhuzhCBLcWo=; b=ANgOjTTy5/HLcDpsd8tCiFligOfmQ36hRFFwqIjp/+gkaRxZErR0upAq UzdBFb6trNkREExJ/nYXiRguCwDVZ8cPAg28a43723sc0SCrzzIdd9aTx a3GED5eX/ADrlhLDcsuTb+HvH3jU0qeJDcSVPWuFS1JJkp5dYz+jQH569 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="63364452" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Dec 2012 04:18:29 +0000 Received: from [10.21.115.140] (sjc-vpn2-908.cisco.com [10.21.115.140]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB74ISvn031144; Fri, 7 Dec 2012 04:18:28 GMT Message-ID: <50C16E14.7050306@cisco.com> Date: Thu, 06 Dec 2012 20:18:28 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Enke Chen Subject: [sidr] BGP capability in draft-ietf-sidr-bgpsec-protocol-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 04:18:30 -0000 Hi, folks: Just noticed that two capabilities are defined in the draft. They actually can and should be combined into one, something like: 0 1 2 3 4 5 6 7 +---------------------------------------+ | Version | S R Reserved| +---------------------------------------+ | | | AFI | | | +---------------------------------------+ where S is for sending, and R for receiving. As you know, the number space for the capability code is only one byte. There is no need to waste. Thanks. -- Enke From dougm@nist.gov Thu Dec 6 20:20: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 B837C11E80DE for ; Thu, 6 Dec 2012 20:20: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=[AWL=0.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 JUuFydDWZB97 for ; Thu, 6 Dec 2012 20:20:35 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB411E80D7 for ; Thu, 6 Dec 2012 20:20:35 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 6 Dec 2012 23:19:43 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 6 Dec 2012 23:20:11 -0500 From: "Montgomery, Douglas" To: Eric Osterweil Importance: low X-Priority: 5 Date: Thu, 6 Dec 2012 23:20:02 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3UMcMYW9VqsMHvSKGYyqoQcZ3VqA== Message-ID: In-Reply-To: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 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, 07 Dec 2012 04:20:36 -0000 On 12/6/12 10:03 PM, "Eric Osterweil" wrote: > >On Dec 6, 2012, at 7:00 PM, Montgomery, Douglas wrote: > >> >> On 12/6/12 5:57 PM, "Eric Osterweil" wrote: >>> >>> Uh... big difference. DNSSEC doesn't require you to care about >>>anything >>> before you need it (on demand). RPKI is prefetching... I can't really >>> outline the architectural difference better than that. >> >> So this seems to be about sub-system behavior in various transient >>states. >> Cold start of a relying party, when there are no other "hot" instances >>in >> contact. While some will argue that one can engineer redundant systems, >> and smart RPs (e.g., that initialize with last running check-pointed >>state >> at boot), still I will admit that one could envisions firing up a new >>RP, >> just out of the box, for the first time and it taking time to load its >> initial state. > >I was hoping we could all see from my quoted text above that this latest >discussion is about the _architectural_ difference between the on-demand >soft-state DNS system, and the prefetching replicated state machine of >RPKI. These two are fundamentally very different architectural models. >Your comments about boot states are interesting, but somewhat off topic >to this post, imho. IMHO they address the architectural issue, by pointing out that while the there are architecturally different in the abstract, for the purpose they are being designed/discussed, this architectural difference makes very little difference in performance. > >> Won't a demand driven system will experience something very similar when >> first fired up and and a full table dump comes across the wire in BGP? > >Ask any of the operators on this list how they feel about full table >dumps and routers refreshing table state, configs, etc when coming >online. If you're saying that RPKI is just like that, I think you just >sank your position. No you completely missed my point, what I am saying is that when a demand based system (say DNS) first comes on line with no cached state, and a router with a full BGP table, it will need to do O(500K) queries immediately. Lets say DNS is the model for a query based system. O(10s to 100s msec) per query? Lets look at a range of a reverse DNS query (with DNSSEC?) taking from 10msec (very optimistic) to 500msec. That means a cold starting DNS based system would take between 1.4 hours and 69 hours to gather enough origin mappings to support a running DFZ router. Note that is dangerous not to have all the state necessary to verify a full RIB because of "prefer valid" like policies, where the relative validity state of multiple entries in the RIB matter. I.e., you better stall the BGP decision process until you have the validation state for all entries. So if the query model takes 69 hours to gain enough state to be useful, why is it architecturally interesting that it did that through 500K individual queries instead of batch downloads? > >> If a demand driven system wasn't smart enough to use a hot standby with >> significant cached state, it too will suffer the latency of pulling a >> significant portion of the data it needs instantly. > >Again, we were discussing the architectural difference, not polishing the >chrome on the titanic. :) Not sure the pithy digs with smilies helps the clarity of these discussions ... But OK I will give it a shot... Just because the Spruce Goose's architecture did not sink, it is not clear to me it was any better suited for the job it was designed for that the Titanic. :^) .... Nah, I still don't think these help. > >> While I see the architectural differences in those two, it is not clear >>to >> me that the end result to a running BGP system that uses them is all >>that >> different. > >Hmm.. Well, re: my comment above, we have very different opinions. I >(literally) defer to operators to answer my above question, and if I'm >rebuffed on that, then so be it. Seem my comment above. I suspect their behavior relative to the architectural differences you point out ... Will be of no operational significance in the application they are designed to support. > >> Once either approach has achieved steady state, assuming there was some >> caching done in the demand based system, if the cache holding time of >> demand queries was the same as the poling interval of the RP, do you >>think >> the responsive ness of a change of authoritative info is all that >> different? > >I honestly have to say that I don't know how I could tell at this point. >I think it would be good for someone to put forward a model, do some >simulation/measurements and present some analysis. I don't know when BGP >is in ``steady state'' or what you might mean by that, but it seems like >a good time for us to be more quantitative and less qualitative. I was talking about when the systems designed to support the distribution of authorization information (e.g., RP/RPKI or some DNS based system?) were in steady state ... I.e., they have booted up and done their initial data loads. > >> Or do you not assume there will be any caching in a demand based system? >> And if so, would you be concerned about the peers * full_table number of >> queries that would result from a router reboot? > >I honestly don't understand this last part, but I'm hoping my comments >and questions (above) address it? If you don't locally cache the results of querying some system for each prefix origin pair from a neighbor ... You will have to multiply the time to query 500K such lookups for each peering session that gives you a full table. If you do cache them for some amount of time. Set the polling interval of a batch pull based system to that same time span. Now, how fast do each react to changes in the authoritative data? > >Eric Dougm From randy@psg.com Thu Dec 6 20:47: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 F07071F0C70 for ; Thu, 6 Dec 2012 20:47:28 -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 NJPaZOjdcFII for ; Thu, 6 Dec 2012 20:47:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 95A891F0C59 for ; Thu, 6 Dec 2012 20:47:28 -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 1TgpqR-0006pr-4I; Fri, 07 Dec 2012 04:47:27 +0000 Date: Fri, 07 Dec 2012 13:47:25 +0900 Message-ID: From: Randy Bush To: Enke Chen In-Reply-To: <50C16E14.7050306@cisco.com> References: <50C16E14.7050306@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] BGP capability in draft-ietf-sidr-bgpsec-protocol-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 04:47:29 -0000 > Just noticed that two capabilities are defined in the draft. They > actually can and should be combined into one, something like: > > 0 1 2 3 4 5 6 7 > +---------------------------------------+ > | Version | S R Reserved| > +---------------------------------------+ > | | > | AFI | > | | > +---------------------------------------+ > > where S is for sending, and R for receiving. > > As you know, the number space for the capability code is only one byte. > There is no need to waste. [ confeesion: enke, matt, and i discussed this offline and matt and i have asked to push to list ] matt pointed out that, in amsterdam, we went from one cap to two because sra said don't create cases you do not want to handle, namely the above with S=R=0 the suggestion now is that it is worth saving the code point and to just treat that case as if the cap was not received. what do folk think? randy From enkechen@cisco.com Thu Dec 6 20:55: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 D6DAC1F0C70 for ; Thu, 6 Dec 2012 20:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OrC2HL2nLZAb for ; Thu, 6 Dec 2012 20:55:28 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 569C41F0C59 for ; Thu, 6 Dec 2012 20:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1483; q=dns/txt; s=iport; t=1354856119; x=1356065719; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=U648acRqNxu8s757yLgdT50UQ4nZ7YU0nc9knnMP/K8=; b=OQmvKLu1kjiRSBvK2vupwSqVCSkLSu4KFFKtTb9zgKGhxHZ41YxXfYd6 llwZ3oBwcM884jGHULNGcdfkUBj7Fq6FDjTWEk09IHcLsBJJtWur/zf5q 6O8CgzqaCoUPWioMZJhPJOl5JCQKjpbcWVDblCXOoLMky8DU4du/PIVBs k=; X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="65940931" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 07 Dec 2012 04:55:19 +0000 Received: from [10.21.115.140] (sjc-vpn2-908.cisco.com [10.21.115.140]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB74tI1Q025768; Fri, 7 Dec 2012 04:55:19 GMT Message-ID: <50C176B6.1070904@cisco.com> Date: Thu, 06 Dec 2012 20:55:18 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Randy Bush References: <50C16E14.7050306@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Enke Chen , sidr@ietf.org Subject: Re: [sidr] BGP capability in draft-ietf-sidr-bgpsec-protocol-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 04:55:29 -0000 Randy, I suggest that the case of S=R=0 be treated as if the cap were not received. It's a good deal to save a capability number by a very short sentence! -- Enke On 12/6/12 8:47 PM, Randy Bush wrote: >> Just noticed that two capabilities are defined in the draft. They >> actually can and should be combined into one, something like: >> >> 0 1 2 3 4 5 6 7 >> +---------------------------------------+ >> | Version | S R Reserved| >> +---------------------------------------+ >> | | >> | AFI | >> | | >> +---------------------------------------+ >> >> where S is for sending, and R for receiving. >> >> As you know, the number space for the capability code is only one byte. >> There is no need to waste. > [ confeesion: enke, matt, and i discussed this offline and matt and i > have asked to push to list ] > > matt pointed out that, in amsterdam, we went from one cap to two because > sra said don't create cases you do not want to handle, namely the above > with S=R=0 > > the suggestion now is that it is worth saving the code point and to just > treat that case as if the cap was not received. > > what do folk think? > > randy From jakob.heitz@ericsson.com Thu Dec 6 21:17: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 4890B1F0C70 for ; Thu, 6 Dec 2012 21:17:19 -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=[AWL=0.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 N27TVjm+6w2d for ; Thu, 6 Dec 2012 21:17:18 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B81811F0C7F for ; Thu, 6 Dec 2012 21:17:18 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qB75HHUi005479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Dec 2012 23:17:17 -0600 Received: from EUSAAHC008.ericsson.se (147.117.188.96) by eusaamw0707.eamcs.ericsson.se (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 7 Dec 2012 00:17:16 -0500 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 00:17:16 -0500 From: Jakob Heitz To: Randy Bush Thread-Topic: [sidr] BGP capability in draft-ietf-sidr-bgpsec-protocol-06 Thread-Index: AQHN1DHs4/8rQumSJE6/4lfd7hRHNpgNF1WA//+0hR4= Date: Fri, 7 Dec 2012 05:17:16 +0000 Message-ID: References: <50C16E14.7050306@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Enke Chen , "sidr@ietf.org" Subject: Re: [sidr] BGP capability in draft-ietf-sidr-bgpsec-protocol-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 05:17:19 -0000 capability codes will soon be in short supply. Use a bit set in your capabi= lity to indicate the "sub capabilities". -- Jakob Heitz. On Dec 6, 2012, at 8:47 PM, "Randy Bush" wrote: >> Just noticed that two capabilities are defined in the draft. They=20 >> actually can and should be combined into one, something like: >>=20 >> 0 1 2 3 4 5 6 7 >> +---------------------------------------+ >> | Version | S R Reserved| >> +---------------------------------------+ >> | | >> | AFI | >> | | >> +---------------------------------------+ >>=20 >> where S is for sending, and R for receiving. >>=20 >> As you know, the number space for the capability code is only one byte. = =20 >> There is no need to waste. >=20 > [ confeesion: enke, matt, and i discussed this offline and matt and i > have asked to push to list ] >=20 > matt pointed out that, in amsterdam, we went from one cap to two because > sra said don't create cases you do not want to handle, namely the above > with S=3DR=3D0 >=20 > the suggestion now is that it is worth saving the code point and to just > treat that case as if the cap was not received. >=20 > what do folk think? >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Thu Dec 6 21:34: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 0D9BB1F0C80 for ; Thu, 6 Dec 2012 21:34: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=[AWL=0.000, 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+vfuDeHU0vq for ; Thu, 6 Dec 2012 21:34:41 -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 B0CEC1F0C7F for ; Thu, 6 Dec 2012 21:34:40 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so43316eaa.31 for ; Thu, 06 Dec 2012 21:34:39 -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=RkROwbZKW+dDOnUGWMLbqdWso91JNFcN79MUe8pTork=; b=Oh4m9hliB3SRZdVCyfQzBghxNGRf3vjjX/q8c7eoj0vOqHfamULTCdvbCSpLUdYlTZ J6mPPmi4/r40kCdnIiKeU9H85BE1K5+ufORgKlSmAVTKQzFInLVoUUY5hC84CVpHRgmV fcbV8M/ZrXyDa+aAozNdA0lxWT/o6iAQiRycKVBp1Rbo5lVqCkMeNoKVD31lQ9t+7SbG /cmhD01J9TtS/ltMt3aya0C3ErR1l67hycKKGh1Oew+GfD3WX+AMGhuwPh4hk8vCZS6n h5oux8o7hJqixMD2m7q3t85mpfmkcylBgamOl3mdiEk2qM4W7mFwFMOCs9jUJL/jqGWA jc4w== MIME-Version: 1.0 Received: by 10.14.202.3 with SMTP id c3mr13029104eeo.4.1354858479893; Thu, 06 Dec 2012 21:34:39 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Thu, 6 Dec 2012 21:34:39 -0800 (PST) In-Reply-To: References: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> Date: Fri, 7 Dec 2012 00:34:39 -0500 X-Google-Sender-Auth: 4QISQbq3k1ZpIJVnlIaCu7y6EJE Message-ID: From: Christopher Morrow To: "Montgomery, Douglas" Content-Type: text/plain; charset=ISO-8859-1 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, 07 Dec 2012 05:34:42 -0000 On Thu, Dec 6, 2012 at 11:20 PM, Montgomery, Douglas wrote: > I was talking about when the systems designed to support the distribution > of authorization information (e.g., RP/RPKI or some DNS based system?) > were in steady state ... I.e., they have booted up and done their initial > data loads. somewhere along the train my comment about dns got moved to 'just like dnssec' (which I was intentionally not referring to, maybe I should have used email as an example instead). Then in this part of the messages I think my DNS comment got moved into 'if you distribute the rpki data via dns instead of up/down/left/right/a-b/a-b... the repository -> cache protocol'. I didn't mean it in that sense either :( I think somewhere 5-8 messages back Arturo's note that: 1) hosted model is just a crutch 2) hosted model isn't intended for everyone to use 3) most large ISP or large operations groups are expected to run their own CA coupled with eric's notes that: 1) hosted seems fragile for lots of operations 2) people should think long and hard about using the hosted model of controlling their own fate gets the general gist of my point: "If you use the hosted model you are equivalently outsourcing your Mail/SMTP infrastructure to another person, be sure you want to do that..." apologies for the confusing example :( -chris From russw@riw.us Fri Dec 7 04:25: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 5D9D921F88C1 for ; Fri, 7 Dec 2012 04:25:34 -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 ygYEtrjsdZIy for ; Fri, 7 Dec 2012 04:25:33 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id D146A21F8878 for ; Fri, 7 Dec 2012 04:25:33 -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 1Tgwzk-0005Tg-RJ; Fri, 07 Dec 2012 04:25:32 -0800 Message-ID: <50C1E03B.1040802@riw.us> Date: Fri, 07 Dec 2012 07:25:31 -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: aservin@lacnic.net References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> <50C12BA5.70503@riw.us> <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> In-Reply-To: <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> 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, 07 Dec 2012 12:25:34 -0000 > I think you are twisting the facts on your own convenience. No, I am merely pointing out that adding a hosted service to an already complex system increases it's complexity. I don't see how that's "twisting facts." Would you care to explain which fact I've twisted, and how? > RPKI != RPKI-hosted solutions. And RPKI is not dependant on the > RPKI-hosted solutions in the same way that DNS is not dependant in the > DNS-hosted solutions. So you're saying that the hosted RPKI system is not reliant on routing? That it can be reached no matter whether or not routing is available? There was, just recently, a large amount of discussion over the problems with a DNS based system to provide origin authentication because "DNS relies on routing, and now you're making routing rely on DNS!" Ignoring the dependence of virtually _any_ distribution system on routing to one degree or another, how can the same criticism not apply to a hosted RPKI system, and the customer's ability to reach that system? And how does adding another system that relies on the system it's supposed to be protecting reduce (or even "not add") complexity? Or am I "twisting facts to my convenience" again? :-) Russ From dougm@nist.gov Fri Dec 7 04:56: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 8542B21F84D7 for ; Fri, 7 Dec 2012 04:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=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 wepnQwM4+q2n for ; Fri, 7 Dec 2012 04:56:51 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 734D021F84B6 for ; Fri, 7 Dec 2012 04:56:50 -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; Fri, 7 Dec 2012 07:56:57 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 7 Dec 2012 07:53:41 -0500 From: "Montgomery, Douglas" To: Christopher Morrow Importance: low X-Priority: 5 Date: Fri, 7 Dec 2012 07:56:14 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3UeeJlDjlTlngkTFWhz+6Zw4zlSQ== 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.5.121010 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, 07 Dec 2012 12:56:52 -0000 I just want to point out that I was on a different train. Discussing the supposition that query&cahce arch's behave differently that batch pull archs in either startup or steady state performance. I was not commenting on the whole trust/business model discussion. I was replying to Eric's suggestion that DNS-like systems are an example of the on-demand architectural choice. On 12/6/12 10:03 PM, "Eric Osterweil" wrote: > >I was hoping we could all see from my quoted text above that this latest >discussion is about the _architectural_ difference between the on-demand >soft-state DNS system, and the prefetching replicated state machine of >RPKI. These two are fundamentally very different architectural models. >Your comments about boot states are interesting, but somewhat off topic >to this post, imho. Those two choices seem moot from a back of the envelope performance / behavior perspective (although I would like to run some tests on a 500K query of a signed reverse DNS ... I don't expect my estimates to get better) ... With either you had better engineer well with redundant "gatherers/resolvers", that don't fate share infrastructure, etc ... Otherwise the hour glass is going to spin for a long time when a DFZ router tries to validate its RIBs. Now I return you to your trust/business model discussion ... Dougm On 12/7/12 12:34 AM, "Christopher Morrow" wrote: >On Thu, Dec 6, 2012 at 11:20 PM, Montgomery, Douglas >wrote: >> I was talking about when the systems designed to support the >>distribution >> of authorization information (e.g., RP/RPKI or some DNS based system?) >> were in steady state ... I.e., they have booted up and done their >>initial >> data loads. > >somewhere along the train my comment about dns got moved to 'just like >dnssec' (which I was intentionally not referring to, maybe I should >have used email as an example instead). Then in this part of the >messages I think my DNS comment got moved into 'if you distribute the >rpki data via dns instead of up/down/left/right/a-b/a-b... the >repository -> cache protocol'. I didn't mean it in that sense either >:( > >I think somewhere 5-8 messages back Arturo's note that: > 1) hosted model is just a crutch > 2) hosted model isn't intended for everyone to use > 3) most large ISP or large operations groups are expected to run their >own CA > >coupled with eric's notes that: > 1) hosted seems fragile for lots of operations > 2) people should think long and hard about using the hosted model of >controlling their own fate > >gets the general gist of my point: "If you use the hosted model you >are equivalently outsourcing your Mail/SMTP infrastructure to another >person, be sure you want to do that..." > >apologies for the confusing example :( >-chris From carlosm3011@gmail.com Fri Dec 7 05:21: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 6E50521F8689 for ; Fri, 7 Dec 2012 05:21:33 -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 5-tWha8NGcTm for ; Fri, 7 Dec 2012 05:21:32 -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 AA6AF21F862C for ; Fri, 7 Dec 2012 05:21:32 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id r1so72471ggn.31 for ; Fri, 07 Dec 2012 05:21:32 -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=JKMrWLU7rU8KplsJKDEYOHsq/h39ZnjcDUpLlkNHVFg=; b=yhKZSFkp/IngBtP6N/W2w9HWXk0+wp94H1duqxf0s6ZapLwUMMO7rZK71yen1xBcR2 fGFgWvRKVnY8Bipn1+y4riWV9qu6yral32aLQr+KySKV8iy8ToVCH/6uHajyNJsff6JE kwwjDfmnHDLV5+Zp7WseT2IsZrwTQGgqaaMvco9X7N1QggVcsEp8fetFb+X7sfCbAe2v HIH/vdRPdiNhfNkoYibmwuyo8MFvF2hdcxKmYIEsJdY7Bb+QNuZgTZl4QvZbf6b9VWfd EvqSXgWUo6Ig0PBHSCCBjg0264680A/5i4G4JbBTy6zEo7OVY7RlY6nZIOS3w1rPvHYl 4FoQ== Received: by 10.101.136.15 with SMTP id o15mr2121286ann.26.1354886492234; Fri, 07 Dec 2012 05:21:32 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:2128:8424:4d78:75b3:bafb? ([2001:13c7:7001:2128:8424:4d78:75b3:bafb]) by mx.google.com with ESMTPS id u49sm13472256yhd.18.2012.12.07.05.21.28 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 05:21:30 -0800 (PST) Message-ID: <50C1ED59.5040009@gmail.com> Date: Fri, 07 Dec 2012 11:21:29 -0200 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Russ White References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> <50C12BA5.70503@riw.us> <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> <50C1E03B.1040802@riw.us> In-Reply-To: <50C1E03B.1040802@riw.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 07 Dec 2012 13:21:33 -0000 Hello R. On 12/07/2012 10:25 AM, Russ White wrote: > >> I think you are twisting the facts on your own convenience. > > So you're saying that the hosted RPKI system is not reliant on routing? > That it can be reached no matter whether or not routing is available? > If by 'hosted RPKI' you are referring to the 'web page', well, the system does need the webpage to function. All repository generation and upkeep will still be running even if the webpage is DDoSed. True, you lose the ability to introduce changes while this supposed DDoS is operating, but routing will not get plastered. All hosted RPKI implementations implement a split system were this upkeep is run by servers not exposed directly to the Internet. If by 'hosted RPKI' you are referring to repository operators hosting all crypto material, yes, you are depending on routing. But, then, if you host your own CA RPs still depend on routing to fetch objects from your repo. If you put objects in the DNS, you depend on routing AND on the DNS to fetch them (that's two dependencies instead of one). RPKI repo fetch could be made fully independent from DNS by adopting something like multiple-pub-points. RPKI repositories could be massively cached by CDNs by adopting HTTP as an additional repository fetching protocol. Yet all of these depend on routing up to some point, it doesn't matter if the repos are hosted by third parties or hosted by the end users themselves. If you have a design for a distribution system which in no way depends on routing and doesn't involve the UPS guy, that'd be awesome ;) > There was, just recently, a large amount of discussion over the problems > with a DNS based system to provide origin authentication because "DNS > relies on routing, and now you're making routing rely on DNS!" Ignoring > the dependence of virtually _any_ distribution system on routing to one > degree or another, how can the same criticism not apply to a hosted RPKI > system, and the customer's ability to reach that system? > > And how does adding another system that relies on the system it's > supposed to be protecting reduce (or even "not add") complexity? > > Or am I "twisting facts to my convenience" again? > I think you're describing a dependency which is not critical and presenting it as if it were. > :-) > > Russ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From carlosm3011@gmail.com Fri Dec 7 05:31: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 1BE0221F84FC for ; Fri, 7 Dec 2012 05:31:58 -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 MNVf3gD9G4db for ; Fri, 7 Dec 2012 05:31:57 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8975E21F84B6 for ; Fri, 7 Dec 2012 05:31:57 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id z22so74893ghb.31 for ; Fri, 07 Dec 2012 05:31: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TNQcMgj4ZsV7xWkjcveUf4Cw0WqV74R58rS/bHucNXU=; b=MNrzBV7Xh3Z0zyjCQgBngCqFMw3pK7d/FIvl7iZvy1iGyycyDqM2csk0EcSLD7xIoC Zm1SWloTIH1PCar56kyIr2gnVrM1hLbdb0IKEXajJDBJk8jKcCgXmuCsk1QAFGiwy3jv ITuH5I+5BJm9flMyWBzLQmIcEv9fB1WkKctEkgvgJCjwj274e+hVvswLpCqkiMMXOuB3 hftE2gGiDAkVK9lY0UVkgh1g4EBzYXP4tgTsCDDQNerBwUHUWT5+oERl9BJmNCtpDyDa P4jc7TGROAZ45cqLcGALprvXBvwW0uBvGQNuXJMmT2N+0X0MG7/pYJ6z7vJ8e2mS8Uq7 25ug== Received: by 10.236.119.146 with SMTP id n18mr7424333yhh.18.1354887117143; Fri, 07 Dec 2012 05:31:57 -0800 (PST) Received: from ?IPv6:2001:13c7:7001:2128:8424:4d78:75b3:bafb? ([2001:13c7:7001:2128:8424:4d78:75b3:bafb]) by mx.google.com with ESMTPS id s1sm12476892anj.1.2012.12.07.05.31.54 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 05:31:55 -0800 (PST) Message-ID: <50C1EFCB.3050208@gmail.com> Date: Fri, 07 Dec 2012 11:31:55 -0200 From: "Carlos M. martinez" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Christopher Morrow References: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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, 07 Dec 2012 13:31:58 -0000 Hey Chris et al, On 12/07/2012 03:34 AM, Christopher Morrow wrote: ... snip ... > I think somewhere 5-8 messages back Arturo's note that: > 1) hosted model is just a crutch > 2) hosted model isn't intended for everyone to use > 3) most large ISP or large operations groups are expected to run their own CA > The hosted model is just about right for probably around ~80% of the routing participants out there. I don't think it's just a crutch, I think it answers a real community (or should I rather say, market) demand. It might have started as one, but IMO it hit a nail in the head. Let's face it: Most sites out there are not as technology-literate as we might light them to be. The dangers of screwing their own CA, losing their keys and mismanaging their publications are much higher if their host their own than if they trust a specialized third party. Hosted fills a gap. Sure, I don't think France Telecom, Verizon or Telmex should use hosted, they can do better. But the folk holding one AS, a /48 and a couple of IPv4 /22s, well, they are mostly better off using hosted. The good thing here is that hosted is _optional_ (I think we are forgetting about this fact in all of this discussion). If you don't want it and want to get your feet wet, please go up/down. > coupled with eric's notes that: > 1) hosted seems fragile for lots of operations > 2) people should think long and hard about using the hosted model of > controlling their own fate > > gets the general gist of my point: "If you use the hosted model you > are equivalently outsourcing your Mail/SMTP infrastructure to another > person, be sure you want to do that..." Agree, people are still responsible for making conscious decisions. Then, taking your example, how many small ops right now host their own email? Probably not many. Warm regards, ~Carlos From russw@riw.us Fri Dec 7 06:11: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 6054521F8985 for ; Fri, 7 Dec 2012 06:11: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 Sq0mCDbWHJx2 for ; Fri, 7 Dec 2012 06:11:02 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id EFBC921F8983 for ; Fri, 7 Dec 2012 06:11:01 -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 1Tgydn-0007Kd-AO; Fri, 07 Dec 2012 06:10:59 -0800 Message-ID: <50C1F8F2.6000202@riw.us> Date: Fri, 07 Dec 2012 09:10:58 -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: "Carlos M. martinez" References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> <50C12BA5.70503@riw.us> <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> <50C1E03B.1040802@riw.us> <50C1ED59.5040009@gmail.com> In-Reply-To: <50C1ED59.5040009@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 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, 07 Dec 2012 14:11:02 -0000 > Yet all of these depend on routing up to some point, it doesn't matter > if the repos are hosted by third parties or hosted by the end users > themselves. If you have a design for a distribution system which in no > way depends on routing and doesn't involve the UPS guy, that'd be awesome ;) There was once a system proposed.... But that was a long time ago, in a galaxy far away. > I think you're describing a dependency which is not critical and > presenting it as if it were. I was presenting a dependency which exists. The question isn't whether or not it's critical, it's whether or not it adds complexity. In other words, even if you classify it as "non-critical" (which I'm not certain I agree with without a lot more thought on the matter), I would still argue that the non-critical parts of a system still add complexity. In fact, to go farther, it is generally true that the non-critical parts of a system add more complexity than the critical ones, particularly in routing. So, I'm still looking for this poor "fact," I've left twisted and horribly abused on the floor. :-) Russ From eosterweil@verisign.com Fri Dec 7 07:28: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 8780321F8AEA for ; Fri, 7 Dec 2012 07:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.617, 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 TegyRJ1KATPF for ; Fri, 7 Dec 2012 07:28:47 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9D621F8799 for ; Fri, 7 Dec 2012 07:28:47 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUMILLLWTFHghwEmYL2x12kyikxZ55xZa@postini.com; Fri, 07 Dec 2012 07:28:47 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 qB7FSeD8021983; Fri, 7 Dec 2012 10:28:43 -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, 7 Dec 2012 10:28:40 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil X-Priority: 5 In-Reply-To: Date: Fri, 7 Dec 2012 10:28:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <651F19EA-5D9F-4684-A1EF-073596A8A52E@verisign.com> References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Dec 2012 15:28:40.0605 (UTC) FILETIME=[88E9D4D0:01CDD48F] 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, 07 Dec 2012 15:28:48 -0000 > IMHO they address the architectural issue, by pointing out that while = the > there are architecturally different in the abstract, for the purpose = they > are being designed/discussed, this architectural difference makes very > little difference in performance. Seriously Doug, this totally misses the point. If there is a = fundamental difference, all the engineering in the world will only be = masking the fact that the architecture is different, has different = scaling properties, different usage models that it is suited for, etc. = Can a model that is inapt for certain requirements be buffed up to = service them anyway? Sure. Does that make it ideal? Doubtful, but = ymmv... > No you completely missed my point, what I am saying is that when a = demand > based system (say DNS) first comes on line with no cached state, and a > router with a full BGP table, it will need to do O(500K) queries > immediately. Lets say DNS is the model for a query based system. = O(10s > to 100s msec) per query? Lets look at a range of a reverse DNS query > (with DNSSEC?) taking from 10msec (very optimistic) to 500msec. That > means a cold starting DNS based system would take between 1.4 hours = and 69 > hours to gather enough origin mappings to support a running DFZ = router. > Note that is dangerous not to have all the state necessary to verify a > full RIB because of "prefer valid" like policies, where the relative > validity state of multiple entries in the RIB matter. I.e., you = better > stall the BGP decision process until you have the validation state for = all > entries. >=20 > So if the query model takes 69 hours to gain enough state to be = useful, > why is it architecturally interesting that it did that through 500K > individual queries instead of batch downloads? I think I see the disconnect here... I don't know why you'd presume = that _I_ think loading a router's RIB from DNS queries is a good idea. = I certainly don't recall saying that, and I am certainly not advocating = that. > Not sure the pithy digs with smilies helps the clarity of these > discussions ... But OK I will give it a shot... Just because the = Spruce > Goose's architecture did not sink, it is not clear to me it was any = better > suited for the job it was designed for that the Titanic. :^) .... = Nah, > I still don't think these help. But the Spruce Goose was killed by yellow journalism, and the Titanic = just couldn't manage the open seas with such a tiny rudder (point, = iceberg)... ;-} > Seem my comment above. I suspect their behavior relative to the > architectural differences you point out ... Will be of no operational > significance in the application they are designed to support. *sigh* Apparently, this will just be a point where we have to agree to = disagree. I feel that (as engineers) we should strive to find the right = tool for the right job, but ymmv. > I was talking about when the systems designed to support the = distribution > of authorization information (e.g., RP/RPKI or some DNS based system?) > were in steady state ... I.e., they have booted up and done their = initial > data loads. Right, and my response was that (even though I have not done any = specific analysis on this, in this context), BGP tends to defy the = notion of being in steady state, so without a precise comment like the = above, it is hard to agree. Also, I'd argue that after a router boots, = I've _heard_ they tend to face a lot of churn that isn't steady. I was = suggesting a study be done, but that's just my 0.02. > If you don't locally cache the results of querying some system for = each > prefix origin pair from a neighbor ... You will have to multiply the = time > to query 500K such lookups for each peering session that gives you a = full > table. If you do cache them for some amount of time. Set the = polling > interval of a batch pull based system to that same time span. Now, = how > fast do each react to changes in the authoritative data? Yes, caching is good, but I also think the model that the caching is = overlaid on matters. Eric= From eosterweil@verisign.com Fri Dec 7 07:30: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 B2D6521F8AEA for ; Fri, 7 Dec 2012 07:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.723 X-Spam-Level: X-Spam-Status: No, score=-5.723 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, J_CHICKENPOX_33=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 0CHBPrcubn1k for ; Fri, 7 Dec 2012 07:30:16 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id C1C2321F8799 for ; Fri, 7 Dec 2012 07:30:15 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUMILhShgue4L7ehsVO5Ghl5gwNFGrxLG@postini.com; Fri, 07 Dec 2012 07:30:15 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 qB7FUCfF022035; Fri, 7 Dec 2012 10:30:12 -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, 7 Dec 2012 10:30:12 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 7 Dec 2012 10:30:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <209760E4-E6DA-4F67-8176-A192034020ED@verisign.com> References: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Dec 2012 15:30:12.0436 (UTC) FILETIME=[BFA62140:01CDD48F] 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, 07 Dec 2012 15:30:16 -0000 On Dec 7, 2012, at 12:34 AM, Christopher Morrow wrote: > On Thu, Dec 6, 2012 at 11:20 PM, Montgomery, Douglas = wrote: >> I was talking about when the systems designed to support the = distribution >> of authorization information (e.g., RP/RPKI or some DNS based = system?) >> were in steady state ... I.e., they have booted up and done their = initial >> data loads. >=20 > somewhere along the train my comment about dns got moved to 'just like > dnssec' (which I was intentionally not referring to, maybe I should > have used email as an example instead). Then in this part of the > messages I think my DNS comment got moved into 'if you distribute the > rpki data via dns instead of up/down/left/right/a-b/a-b... the > repository -> cache protocol'. I didn't mean it in that sense either > :( >=20 > I think somewhere 5-8 messages back Arturo's note that: > 1) hosted model is just a crutch > 2) hosted model isn't intended for everyone to use > 3) most large ISP or large operations groups are expected to run = their own CA I totally agree, and I hope I was clear in ack'ing that this was = something that I agreed with. > coupled with eric's notes that: > 1) hosted seems fragile for lots of operations > 2) people should think long and hard about using the hosted model of > controlling their own fate >=20 > gets the general gist of my point: "If you use the hosted model you > are equivalently outsourcing your Mail/SMTP infrastructure to another > person, be sure you want to do that..." Yup. Agreed. Eric= From tim@ripe.net Fri Dec 7 07:30: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 9AC2521F8AEA for ; Fri, 7 Dec 2012 07:30:58 -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 wu3rw+930wX9 for ; Fri, 7 Dec 2012 07:30:57 -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 16BE121F8799 for ; Fri, 7 Dec 2012 07:30:57 -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 1Tgzt8-0004K0-Re; Fri, 07 Dec 2012 16:30:56 +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 1Tgzt8-0007HJ-Dh; Fri, 07 Dec 2012 16:30:54 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Bruijnzeels In-Reply-To: <50C1EFCB.3050208@gmail.com> Date: Fri, 7 Dec 2012 16:30:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D81CAF7-C46D-4C24-AC36-17AA915F1443@ripe.net> References: <3D98FE32-B8E5-49FD-81E8-DE46F6C1BD3E@verisign.com> <50C1EFCB.3050208@gmail.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121207 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 -0.0 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] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07196f84cc62043102811fc0a7b58b6255d7 Cc: "sidr@ietf.org 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, 07 Dec 2012 15:30:58 -0000 Hey all, On Dec 7, 2012, at 2:31 PM, "Carlos M. martinez" = wrote: > Hey Chris et al, >=20 > On 12/07/2012 03:34 AM, Christopher Morrow wrote: > ... snip ... >=20 >> I think somewhere 5-8 messages back Arturo's note that: >> 1) hosted model is just a crutch >> 2) hosted model isn't intended for everyone to use >> 3) most large ISP or large operations groups are expected to run = their own CA >>=20 >=20 Hosted model is ambiguous. Please differentiate between hosted CAs and centralised repository = server. Some people, like Carlos wrt UI vs publishing, do, but not = everywhere in this thread.. The pros and cons for hosted CAs and 'hosted' repositories are = different. Current hosted solutions combine the two, but this is not necessarily = the case in future. E.g. an organisation might choose to run their own = non-hosted CA, but publish in one, or more (yeay..) central = repositories. > The hosted model is just about right for probably around ~80% of the > routing participants out there. I don't think it's just a crutch, I > think it answers a real community (or should I rather say, market) > demand. It might have started as one, but IMO it hit a nail in the = head. +1 from our experience rolling this out. > Let's face it: Most sites out there are not as technology-literate as = we > might light them to be. The dangers of screwing their own CA, losing > their keys and mismanaging their publications are much higher if their > host their own than if they trust a specialized third party. >=20 > Hosted fills a gap. Sure, I don't think France Telecom, Verizon or > Telmex should use hosted, they can do better. But the folk holding one > AS, a /48 and a couple of IPv4 /22s, well, they are mostly better off > using hosted. >=20 In a way people are used to this. Lots of sites are already used to = 'hosted' whois, IRR etc. > The good thing here is that hosted is _optional_ (I think we are > forgetting about this fact in all of this discussion). If you don't = want > it and want to get your feet wet, please go up/down. Non-hosted is an option in our pilot, but so-far we say very little = demand for it. We have four members playing with non-hosted in our pilot = environment vs 1200+ using the the hosted model in production. This = includes big organisations. >> coupled with eric's notes that: >> 1) hosted seems fragile for lots of operations >> 2) people should think long and hard about using the hosted model of >> controlling their own fate >>=20 >> gets the general gist of my point: "If you use the hosted model you >> are equivalently outsourcing your Mail/SMTP infrastructure to another >> person, be sure you want to do that..." >=20 > Agree, people are still responsible for making conscious decisions. > Then, taking your example, how many small ops right now host their own > email? Probably not many. Benefits of non-hosted CA: - you have your own keys =3D> in hosted a security breach can in principle let others do things = with your keys like issue/revoke ROAs - little risk of *your* ui being DDoS-ed Benefit of hosted: - low cost, easy to enable, no need to run your own (complex) systems @Erik's remark regarding hosted HSMs. As Carlos said: we would also = allow people to migrate between hosted and non-hosted: temporarily = signing certs to both CAs, just for the time of transition. Non-hosted CA management may well pick up one day, but imho this depends = on uptake of RPKI for secure routing, and the availability of = easy-to-use non-hosted solutions. Present day the benefit of doing this = yourself is not clear enough to warrant the cost. If benefit goes up and = cost goes down this might change. Comparing to the DNSSec world, imagine = appliance boxes that network operators can put in a rack that let them = do this.. Without this I seriously doubt there will be significant = uptake of non-hosted. And without uptake of hosted I see no business = case for vendors to build these things.. With regards to non-hosted publication=85. In the current RPKI & sidr model (and I haven't seen a comprehensive = alternative -- echo comment by Tony Tauber) objects will have to be = downloaded. Having many small self-managed repositories does not seem = the best way forward to me. It's difficult for relying party tools, it's = likely that many of them will be poorly run and/or easy targets for more = localised attacks. I see more in having a number of large repositories and allowing CAs to = publish in more than one place to mitigate the risks of one of them = being unavailable. Plus of course a set of 2.0 repository standards that = give these repositories a fighting chance to achieve high-availability = without having to re-invent the wheel here, and roll out 10s-100s of = rsync servers across the globe. Think using tested and proven industry = technology.. Like using immutable data, http, CDNs etc. When is the last = time your googlebookcnnbbc website was completely unreachable? Tim > Warm regards, >=20 > ~Carlos > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From eosterweil@verisign.com Fri Dec 7 07:32: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 19D2B21F8997 for ; Fri, 7 Dec 2012 07:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, J_CHICKENPOX_55=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 kTqc0ABMVe55 for ; Fri, 7 Dec 2012 07:32:10 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0821F860F for ; Fri, 7 Dec 2012 07:32:10 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUMIL+KRTnrLJozJl5REwLXztZhRtNDY8@postini.com; Fri, 07 Dec 2012 07:32:10 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 qB7FW7ww022111; Fri, 7 Dec 2012 10:32:07 -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, 7 Dec 2012 10:32:07 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil X-Priority: 5 In-Reply-To: Date: Fri, 7 Dec 2012 10:32:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Montgomery, Douglas" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Dec 2012 15:32:07.0565 (UTC) FILETIME=[04456BD0:01CDD490] 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, 07 Dec 2012 15:32:11 -0000 On Dec 7, 2012, at 7:56 AM, Montgomery, Douglas wrote: > I just want to point out that I was on a different train. Discussing = the > supposition that query&cahce arch's behave differently that batch pull > archs in either startup or steady state performance. I was not = commenting > on the whole trust/business model discussion. >=20 >=20 > I was replying to Eric's suggestion that DNS-like systems are an = example > of the on-demand architectural choice. Doug, this is getting silly. If you have a system that _requires_ full = state of all data producers in the entire world before it can begin, = then you are talking about a _much_ different architecture than one that = only queries for _relevant_ information when it becomes relevant. If = you use the latter for the former's goals, or the former for the = latter's goals then so be it, but they are designed with different = precepts. Eric= From andy@arin.net Fri Dec 7 08:47: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 CF44821F8690 for ; Fri, 7 Dec 2012 08:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=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 nLpdfj1ixln9 for ; Fri, 7 Dec 2012 08:47:46 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4E71F21F8643 for ; Fri, 7 Dec 2012 08:47:46 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id E7429165540; Fri, 7 Dec 2012 11:47:36 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 5E79D16553D; Fri, 7 Dec 2012 11:47:36 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 7 Dec 2012 11:47:08 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.120]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0318.004; Fri, 7 Dec 2012 11:47:30 -0500 From: Andy Newton To: Eric Osterweil Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: AQHN1JqLGTgHoyf8DUqZKiyOFzfTKA== Date: Fri, 7 Dec 2012 16:47:28 +0000 Message-ID: In-Reply-To: <6CEBEA58-8F12-4B1B-8669-B159E4F5AC02@verisign.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: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <37D1E30779125B48ADDC09C6379EF8CC@corp.arin.net> Content-Transfer-Encoding: quoted-printable 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, 07 Dec 2012 16:47:46 -0000 On 12/6/12 5:57 PM, "Eric Osterweil" wrote: > Nope, it doesn't. It actually points out that hosting's myopic benefits >are fools-gold, and they come with a > much more dangerous price tag. Your choice of dreamhost is a _choice_, >not a mandate from a set of 5 > options. Fundamentally different. Just because the RIRs are the only organization offering hosting services, doesn't mean that they are the only ones that can offer hosting services. Certainly an enterprising Internet company with DDOS mitigation services could offer RPKI CA hosting or simply hosting of RPKI repositories for DDOS mitigation. On 12/6/12 6:03 PM, "Eric Osterweil" wrote: > How do they get their private keys from you? This is important to think >through _now_ before it becomes > an operational blackhole... Also, what happens if you get DDoS'ed and I >need your services? In DNS, > there are a lot of registrars to choose from, and no single point of >failure... The RIRs are not as > plentiful in numbers as them, so you are a higher value target this >way... Just to reiterate the points Carlos made regarding DDOS of RPKI repositories (which is the issue, not the hosting services): 1) if DDOS of the repositories is in question, we should look at the multiple-publication points proposal, and 2) switching to an HTTP fetching protocol would broaden the available base of organizations that might wish to distribute RPKI repositories. -andy From alexey.melnikov@isode.com Fri Dec 7 08:53: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 80CCD21F86F7 for ; Fri, 7 Dec 2012 08:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 kVdaI3v+ubCL for ; Fri, 7 Dec 2012 08:53:49 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id AA3F221F86CD for ; Fri, 7 Dec 2012 08:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1354899228; d=isode.com; s=selector; i=@isode.com; bh=X8cK9yDZ0fI03v9A0meIhbpMN4/mup0J3bQjmCpDUm8=; 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=v+rzUCm+SPoR6c+XMtfFfdTIV7Wgnrjjqw0as+9L0z2uZKRvKR2GV8nm5WqUB3IapT8UcU qXFXkXbAZyoxiOqmd0HZjwZMe54efJn9s5XAJPsga1cQo9TJnk3siV/ipaRvPOnjjkizu2 tOyguDV7PfX+opT4p+Ez5uAbhQzL0os=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 7 Dec 2012 16:53:48 +0000 Message-ID: <50C21F2E.6000708@isode.com> Date: Fri, 07 Dec 2012 16:54:06 +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] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 16:53:50 -0000 Hi, Sorry for procrastinating on this for so long. Here are questions I would like to ask WG participants. At this point I would like to ask people to review the questions and let me know if you think they are contradictory. If they are clear, I will poll the WG early next week. Comments on the mailing list or sent directly to WG chairs are welcome. ---------------- 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02 actually a problem that the WG needs to address? (Answer: yes or no. Additional information is welcomed, but I don't want people to repeat the whole discussion.) 2) If you answered "yes" to the question #1, please also answer the following question: Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to become a WG document? Please choose one of the following: a) Ready for Adoption (whether or not you have some specific issues with it. Also, this answer is unrelated to whether this should be a separate draft or a part of an existing draft). b) Needs more work BEFORE Adoption c) Should not be adopted. In particular this mean that you don't believe any amount of work on the proposed draft will address your issues. So any solution to this problem should be a new draft written from scratch. d) Abstain/don't care 3) If you answered "a" or "b" above, please also answer the following question: Does this need to be in a standalone draft, or can it be incorporated into another existing WG draft? When answering this question please only base your answer on technical reasons, in particular please leave the decision on who is going to edit the document (if it is standalone) to WG chairs. From eosterweil@verisign.com Fri Dec 7 09:01: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 9458321F8B9D for ; Fri, 7 Dec 2012 09:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.256 X-Spam-Level: X-Spam-Status: No, score=-4.256 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_00=-2.599, J_CHICKENPOX_43=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 GBwkSSFcVFSW for ; Fri, 7 Dec 2012 09:01:34 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3F21F8B2B for ; Fri, 7 Dec 2012 09:01:27 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUMIg5VyF9ZzKGSMAyT+0l1L4Zt9MWkbD@postini.com; Fri, 07 Dec 2012 09:01:27 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 qB7H1M1d030063; Fri, 7 Dec 2012 12:01:25 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 12:01:22 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 7 Dec 2012 12:01:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Newton X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Dec 2012 17:01:22.0539 (UTC) FILETIME=[7C159BB0:01CDD49C] 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, 07 Dec 2012 17:01:34 -0000 > Just because the RIRs are the only organization offering hosting = services, > doesn't mean that they are the only ones that can offer hosting = services. > Certainly an enterprising Internet company with DDOS mitigation = services > could offer RPKI CA hosting or simply hosting of RPKI repositories for > DDOS mitigation. Yeah, while I'm not proposing that, my whole point was triggered off the = assertion that there will be 5 repos, and that the hosted model fits the = eventual needs. That thinking ignored too much grey area for me. > Just to reiterate the points Carlos made regarding DDOS of RPKI > repositories (which is the issue, not the hosting services): 1) if = DDOS of > the repositories is in question, we should look at the > multiple-publication points proposal, and 2) switching to an HTTP = fetching > protocol would broaden the available base of organizations that might = wish > to distribute RPKI repositories. For 1) I think considering the results of DDoS'ing the repos should be = part of the thinking. For 2) I (personally) haven't thought that = through enough to adopt a position. Eric= From eosterweil@verisign.com Fri Dec 7 09:05: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 0B9CE21F8B9A for ; Fri, 7 Dec 2012 09:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.613, 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 4fS4bJyFi3Gp for ; Fri, 7 Dec 2012 09:05:14 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8F621F8B2B for ; Fri, 7 Dec 2012 09:04:55 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUMIhthf5CAVHJY5kLaaJlA7/Exj83RRo@postini.com; Fri, 07 Dec 2012 09:04:55 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 qB7H4rsd030180; Fri, 7 Dec 2012 12:04:53 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 12:04:53 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 7 Dec 2012 12:04:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Newton X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Dec 2012 17:04:53.0686 (UTC) FILETIME=[F9F01560:01CDD49C] Cc: "sidr@ietf.org 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, 07 Dec 2012 17:05:15 -0000 On Dec 7, 2012, at 12:01 PM, Eric Osterweil wrote: > Yeah, while I'm not proposing that, my whole point was triggered off = the assertion that there will be 5 repos, and that the hosted model fits = the eventual needs. That thinking ignored too much grey area for me. Sorry, meant to say fits the eventual needs _of_everyone_...= From brian.peter.dickson@gmail.com Fri Dec 7 09:32: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 0212E21F8575 for ; Fri, 7 Dec 2012 09:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 ixQxr4nXSIhX for ; Fri, 7 Dec 2012 09:32:05 -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 9BED421F8562 for ; Fri, 7 Dec 2012 09:32:04 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so479429eek.31 for ; Fri, 07 Dec 2012 09:32:03 -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=IM3YsvAuOlYZal3gc8U94GSCWz527j0lO99207kYm5o=; b=NSO8jQ2Gd73jQZfKasT5B/ug/21IYezAiZEIpEKJQO5rkjey+I2B+30DSYP2EJNg/O GMu0U/OSBOBhdL5GnFkOd9TQLD7BqqJVIodVXGzD/cS8NqBaF6WpxyuBFG6SvHJ6cOSh /6Vj9gN03PT/1zSdXjYjZM1quqHkHs39ScJPgO0pfHwx/R8ZDJEmg3hbGjL6qJs2lIGS gSlxJR4Gizi6Cvh0c8dDo7V3PuoO+SthCEBX3AH+i+OyVasCSDIWGegW0uFSAVMzxXgE gSr4nro83vG1V/0zjn4nVCCfMPJmpGPQO120Qf14AiEPt1JQ0y1AA3gtJ0ni8fhJ4Ql0 pDbg== MIME-Version: 1.0 Received: by 10.14.208.137 with SMTP id q9mr18835747eeo.28.1354901523694; Fri, 07 Dec 2012 09:32:03 -0800 (PST) Received: by 10.223.173.199 with HTTP; Fri, 7 Dec 2012 09:32:03 -0800 (PST) In-Reply-To: <50C21F2E.6000708@isode.com> References: <50C21F2E.6000708@isode.com> Date: Fri, 7 Dec 2012 12:32:03 -0500 Message-ID: From: Brian Dickson To: Alexey Melnikov Content-Type: multipart/alternative; boundary=047d7b621d160684ae04d0469891 Cc: sidr wg Subject: Re: [sidr] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 17:32:06 -0000 --047d7b621d160684ae04d0469891 Content-Type: text/plain; charset=ISO-8859-1 Top-reply for convenience: (This is strictly my opinion/observation and does not represent the viewpoint of any organization per se) 1. Yes, there is a problem alluded to that might need to be solved. 2. C - no, this draft is not the place to solve the problem. The root of the problem, is limitations imposed by the design of RFC 3779 for how resources are delegated. The routing system uses "longest match wins". The RPKI needs to accommodate the exclusivity of prefixes that are both routed (as less-specific) and delegated-and-routed (as more-specific). Specifically, when a resource has some portion of it "forked" (either by the resource holder, or by any parent of the resource holder), the encoding of the resource needs to have that "fork" encoded. The "fork" needs to be "tied" to the resource, in such a way as to prevent the same resource being available for certification by more than one party. So, the place to do this is in RFC3779-bis, and inherit the changes (possibly involving modifications) in the rest of the document suite of SIDR. Brian P.S. Here is a worked example to illustrate this concept: Suppose the initial state of affairs is as follows: 10.0.0.0/8 is delegated by IANA to RIR "A". RIR "A" does not route any portion of this block, but only doles out portions of it. 10.1.0.0/16 is delegated by RIR "A" to LIR "A1". Again, not routed. 10.1.0.0/20 is delegated by LIR "A1" to ISP "B". ISP B routes this prefix. 10.1.15.0/24 is delegated by ISP "B" to customer "C". C routes this prefix, which is more-specific and preferred over 10.1.0.0/20. Now add to the above, that ISP "B" goes out of business. The proposed way of directly assigning the 10.1.15.0/24 to "C" would be to have the delegation done directly to "C" by RIR "A", or by LIR "A1". (Or by IANA, only included for completeness, i.e. this would likely never happen.) And, in order to continue to assure the uniqueness of the assignment, the corresponding delegations would need to explicitly call out the NON-delegation of 10.1.15.0/24, attached to the delegation chain starting wherever the fork occurred. So, if the direct delegation is done by LIR "A1", the new delegations by A1 would be: 10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B" (which is defunct, presumably, but whose assets might be sold to another party)) 10.1.15.0/24 (to "C" directly) Or if the direct delegation is done by RIR "A", the delegations would be: 10.1.0.0/16 minus 10.1.15.0/24 (from RIR "A" to LIR "A1") 10.1.15.0/24 (from RIR "A" to end-user "C") 10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B") The "minus foo" would need to be attached to any delegation covering "foo", throughout the delegation hierarchy, once such a "fork" occurs. ROA validation would need to check this, but the logic is quite simple. On Fri, Dec 7, 2012 at 11:54 AM, Alexey Melnikov wrote: > Hi, > Sorry for procrastinating on this for so long. > > Here are questions I would like to ask WG participants. At this point I > would like to ask people to review the questions and let me know if you > think they are contradictory. If they are clear, I will poll the WG early > next week. Comments on the mailing list or sent directly to WG chairs < > sidr-chairs@tools.ietf.org> are welcome. > > ---------------- > > 1) Is the problem described/solved by draft-ymbk-rpki-**grandparenting-02 > actually a problem that the WG needs to address? (Answer: yes or no. > Additional information is welcomed, but I don't want people to repeat the > whole discussion.) > > 2) If you answered "yes" to the question #1, please also answer the > following question: > > Is draft-ymbk-rpki-**grandparenting-02 a reasonable starting point to > become a WG document? Please choose one of the following: > > > a) Ready for Adoption (whether or not you have some specific issues with > it. Also, this answer is unrelated to whether this should be a separate > draft or a part of an existing draft). > > b) Needs more work BEFORE Adoption > > c) Should not be adopted. In particular this mean that you don't believe > any amount of work on the proposed draft will address your issues. So any > solution to this problem should be a new draft written from scratch. > > d) Abstain/don't care > > > 3) If you answered "a" or "b" above, please also answer the following > question: > > Does this need to be in a standalone draft, or can it be incorporated into > another existing WG draft? When answering this question please only base > your answer on technical reasons, in particular please leave the decision > on who is going to edit the document (if it is standalone) to WG chairs. > > > ______________________________**_________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/**listinfo/sidr > --047d7b621d160684ae04d0469891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Top-reply for convenience:
(This is strictly my opinion/observation and= does not represent the viewpoint of any organization per se)
1. Yes, there is a problem alluded to that might need to be sol= ved.
2. C - no, this draft is not the place to solve the problem.

The root of the problem, is limitations imposed by the desi= gn of RFC 3779 for how resources are delegated.

The routing system uses "longest match wins".
The RPKI = needs to accommodate the exclusivity of prefixes that are both routed (as l= ess-specific) and delegated-and-routed (as more-specific).

Specifically, when a resource has some portion of it "forke= d" (either by the resource holder, or by any parent of the resource ho= lder), the encoding of the resource needs to have that "fork" enc= oded.

The "fork" needs to be "tied" to th= e resource, in such a way as to prevent the same resource being available f= or certification by more than one party.

So, the p= lace to do this is in RFC3779-bis, and inherit the changes (possibly involv= ing modifications) in the rest of the document suite of SIDR.

Brian

P.S. Here is a worked ex= ample to illustrate this concept:

Suppose the init= ial state of affairs is as follows:
10.0.0.0/8 is delegated by IANA to RIR "A". RIR "A"= ; does not route any portion of this block, but only doles out portions of = it.
10.1.0.0/16 is delegated by RIR &qu= ot;A" to LIR "A1". Again, not routed.
10.1.0.0/20 is delegated by LIR "A1" to IS= P "B". ISP B routes this prefix.
10.1.15.0/24 is delegated by ISP &= quot;B" to customer "C". C routes this prefix, which is more= -specific and preferred over 10.1.0.0/20= .

Now add to the above, that ISP "B" goes out o= f business.

The proposed way of directly assigning= the 10.1.15.0/24 to "C" woul= d be to have the delegation done directly to "C" by RIR "A&q= uot;, or by LIR "A1".
(Or=A0by IANA, only included for completeness, i.e. this would likely = never happen.)

And, in order to continue to assure= the uniqueness of the assignment, the corresponding delegations would need= to explicitly call out the NON-delegation of 10.1.15.0/24, attached to the delegation chain starting wherever the= fork occurred.

So, if the direct delegation is done by LIR "A1&qu= ot;, the new delegations by A1 would be:
10.1.15.0/24 (to "C" dir= ectly)

Or if the direct delegation is done by RIR = "A", the delegations would be:
10.1.15.0/24 (from RIR "A&quo= t; to end-user "C")
10.1= .0.0/20 minus 10.1.15.0/24 (from LI= R "A1" to ISP "B")

The "minus foo" would need to be attached to = any delegation covering "foo", throughout the delegation hierarch= y, once such a "fork" occurs.
ROA validation would need= to check this, but the logic is quite simple.

On Fri, Dec 7, 2012 at 11:54 AM, Alexey Meln= ikov <alexey.melnikov@isode.com> wrote:
Hi,
Sorry for procrastinating on this for so long.

Here are questions I would like to ask WG participants. At this point I wou= ld like to ask people to review the questions and let me know if you think = they are contradictory. If they are clear, I will poll the WG early next we= ek. Comments on the mailing list or sent directly to WG chairs <sidr-chairs@tools.= ietf.org> are welcome.

----------------

1) Is the problem described/solved by draft-ymbk-rpki-grandparenting= -02 actually a problem that the WG needs to address? (Answer: yes or no. Ad= ditional information is welcomed, but I don't want people to repeat the= whole discussion.)

2) If you answered "yes" to the question #1, please also answer t= he following question:

Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to = become a WG document? Please choose one of the following:


a) Ready for Adoption (whether or not you have some specific issues with it= . Also, this answer is unrelated to whether this should be a separate draft= or a part of an existing draft).

b) Needs more work BEFORE Adoption

c) Should not be adopted. In particular this mean that you don't believ= e any amount of work on the proposed draft will address your issues. So any= solution to this problem should be a new draft written from scratch.

d) Abstain/don't care


3) If you answered "a" or "b" above, please also answer= the following question:

Does this need to be in a standalone draft, or can it be incorporated into = another existing WG draft? When answering this question please only base yo= ur answer on technical reasons, in particular please leave the decision on = who is going to edit the document (if it is standalone) to WG chairs.


_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--047d7b621d160684ae04d0469891-- From dougm@nist.gov Fri Dec 7 09:35: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 5771821F8A94 for ; Fri, 7 Dec 2012 09:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_55=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 fgb49gqN1shk for ; Fri, 7 Dec 2012 09:35:17 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 8867E21F85DA for ; Fri, 7 Dec 2012 09:35:17 -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, 7 Dec 2012 12:34:47 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 7 Dec 2012 12:32:29 -0500 From: "Montgomery, Douglas" To: Eric Osterweil Importance: low X-Priority: 5 Date: Fri, 7 Dec 2012 12:28:09 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3UoNTtbvqjtM3DRy6yk1ZWO/oo2w== 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.5.121010 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, 07 Dec 2012 17:35:18 -0000 On 12/7/12 10:32 AM, "Eric Osterweil" wrote: > >On Dec 7, 2012, at 7:56 AM, Montgomery, Douglas wrote: > >> I just want to point out that I was on a different train. Discussing >>the >> supposition that query&cahce arch's behave differently that batch pull >> archs in either startup or steady state performance. I was not >>commenting >> on the whole trust/business model discussion. >> >> >> I was replying to Eric's suggestion that DNS-like systems are an example >> of the on-demand architectural choice. > >Doug, this is getting silly. If you have a system that _requires_ full >state of all data producers in the entire world before it can begin, then >you are talking about a _much_ different architecture than one that only >queries for _relevant_ information when it becomes relevant. If you use >the latter for the former's goals, or the former for the latter's goals >then so be it, but they are designed with different precepts. What is silly is our failure to communicate. If the initial immediate requirement of a demand driven system is to individually query for 90%+ of the total information in the system, how is that different that pre-fetching it all? DFZ Router with 500K unique routes needs to validate its RIB using a demand-based validator that just came up. How would you like the demand system to perform those resolutions? What is your time estimate for how long the cold started demand driven "validator" will take to validate all of those entries? You are right that they are different architectural models. No argument there. Their use for the problem we are discussing, will result in that difference being moot from a performance scaling perspective. No argument that the architectures are different. We seem to differ on that difference is important ... And probably on which would scale better. dougm From dougm@nist.gov Fri Dec 7 09:35: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 9A97221F8AD3 for ; Fri, 7 Dec 2012 09:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 rlMDFjY-bapM for ; Fri, 7 Dec 2012 09:35:58 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B70EC21F8A94 for ; Fri, 7 Dec 2012 09:35:57 -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; Fri, 7 Dec 2012 12:36:25 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 7 Dec 2012 12:33:09 -0500 From: "Montgomery, Douglas" To: Eric Osterweil Importance: low X-Priority: 5 Date: Fri, 7 Dec 2012 12:35:45 -0500 Thread-Topic: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system Thread-Index: Ac3UoO0V/T63DkO9QiqUZAz02/K2HQ== Message-ID: In-Reply-To: <651F19EA-5D9F-4684-A1EF-073596A8A52E@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 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, 07 Dec 2012 17:35:58 -0000 On 12/7/12 10:28 AM, "Eric Osterweil" wrote: > >> IMHO they address the architectural issue, by pointing out that while >>the >> there are architecturally different in the abstract, for the purpose >>they >> are being designed/discussed, this architectural difference makes very >> little difference in performance. > >Seriously Doug, this totally misses the point. If there is a fundamental >difference, all the engineering in the world will only be masking the >fact that the architecture is different, has different scaling >properties, different usage models that it is suited for, etc. Can a >model that is inapt for certain requirements be buffed up to service them >anyway? Sure. Does that make it ideal? Doubtful, but ymmv... > >> No you completely missed my point, what I am saying is that when a >>demand >> based system (say DNS) first comes on line with no cached state, and a >> router with a full BGP table, it will need to do O(500K) queries >> immediately. Lets say DNS is the model for a query based system. >>O(10s >> to 100s msec) per query? Lets look at a range of a reverse DNS query >> (with DNSSEC?) taking from 10msec (very optimistic) to 500msec. That >> means a cold starting DNS based system would take between 1.4 hours and >>69 >> hours to gather enough origin mappings to support a running DFZ router. >> Note that is dangerous not to have all the state necessary to verify a >> full RIB because of "prefer valid" like policies, where the relative >> validity state of multiple entries in the RIB matter. I.e., you better >> stall the BGP decision process until you have the validation state for >>all >> entries. >> >> So if the query model takes 69 hours to gain enough state to be useful, >> why is it architecturally interesting that it did that through 500K >> individual queries instead of batch downloads? > >I think I see the disconnect here... I don't know why you'd presume that >_I_ think loading a router's RIB from DNS queries is a good idea. I >certainly don't recall saying that, and I am certainly not advocating >that. The rest we have beaten to death so I won't try again. I was not suggesting/discussing loading a RIB from DNS queries. I was thought we were discussing information systems that might allow me to validate the origin of an router's RIB. That problem is O(500K) at time zero. > >> Not sure the pithy digs with smilies helps the clarity of these >> discussions ... But OK I will give it a shot... Just because the Spruce >> Goose's architecture did not sink, it is not clear to me it was any >>better >> suited for the job it was designed for that the Titanic. :^) .... >>Nah, >> I still don't think these help. > >But the Spruce Goose was killed by yellow journalism, and the Titanic >just couldn't manage the open seas with such a tiny rudder (point, >iceberg)... ;-} Actually the Spruce Goose floated fine, but was completely ill designed / engineered to fly. The Titanic sank because of the poor, under spec metal quality used in its rivets. A NIST metallurgist proved this some number of years back and got a lot of press for it. > >> Seem my comment above. I suspect their behavior relative to the >> architectural differences you point out ... Will be of no operational >> significance in the application they are designed to support. > >*sigh* Apparently, this will just be a point where we have to agree to >disagree. I feel that (as engineers) we should strive to find the right >tool for the right job, but ymmv. > >> I was talking about when the systems designed to support the >>distribution >> of authorization information (e.g., RP/RPKI or some DNS based system?) >> were in steady state ... I.e., they have booted up and done their >>initial >> data loads. > >Right, and my response was that (even though I have not done any specific >analysis on this, in this context), BGP tends to defy the notion of being >in steady state, so without a precise comment like the above, it is hard >to agree. Also, I'd argue that after a router boots, I've _heard_ they >tend to face a lot of churn that isn't steady. I was suggesting a study >be done, but that's just my 0.02. > >> If you don't locally cache the results of querying some system for each >> prefix origin pair from a neighbor ... You will have to multiply the >>time >> to query 500K such lookups for each peering session that gives you a >>full >> table. If you do cache them for some amount of time. Set the polling >> interval of a batch pull based system to that same time span. Now, how >> fast do each react to changes in the authoritative data? > >Yes, caching is good, but I also think the model that the caching is >overlaid on matters. > >Eric From aservin@lacnic.net Fri Dec 7 09:42: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 B822D21F85F4 for ; Fri, 7 Dec 2012 09:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_SORBS_DUL=0.877] 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 tION9KwY0AuE for ; Fri, 7 Dec 2012 09:42:35 -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 649DF21F85E1 for ; Fri, 7 Dec 2012 09:42:35 -0800 (PST) Received: from MiniR2D2.local (r200-40-240-99.su-static.anteldata.net.uy [200.40.240.99]) by mail.lacnic.net.uy (Postfix) with ESMTP id CCCBF30844C; Fri, 7 Dec 2012 15:42:19 -0200 (UYST) Message-ID: <50C22A7A.2090000@lacnic.net> Date: Fri, 07 Dec 2012 15:42:18 -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: Russ White References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> <50C12BA5.70503@riw.us> <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> <50C1E03B.1040802@riw.us> In-Reply-To: <50C1E03B.1040802@riw.us> X-Enigmail-Version: 1.4.6 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 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, 07 Dec 2012 17:42:36 -0000 You are twisting the fact when you are mixing hosted-rpiki and rpki-repositories as the same thing. On 07/12/2012 10:25, Russ White wrote: > >> I think you are twisting the facts on your own convenience. > > No, I am merely pointing out that adding a hosted service to an already > complex system increases it's complexity. I don't see how that's > "twisting facts." Would you care to explain which fact I've twisted, and > how? > >> RPKI != RPKI-hosted solutions. And RPKI is not dependant on the >> RPKI-hosted solutions in the same way that DNS is not dependant in the >> DNS-hosted solutions. > > So you're saying that the hosted RPKI system is not reliant on routing? No, I am saying that rpki hosted (the web interface) is not critical for RPKI. > That it can be reached no matter whether or not routing is available? > > There was, just recently, a large amount of discussion over the problems > with a DNS based system to provide origin authentication because "DNS > relies on routing, and now you're making routing rely on DNS!" Ignoring > the dependence of virtually _any_ distribution system on routing to one > degree or another, how can the same criticism not apply to a hosted RPKI > system, and the customer's ability to reach that system? > > And how does adding another system that relies on the system it's > supposed to be protecting reduce (or even "not add") complexity? > > Or am I "twisting facts to my convenience" again? A bit, you are (in my understanding) are still mixing hosted-rpiki and rpki-repositories. ;-) Now, how to make the rpki-repositories more robust, there are people already working on that. > > :-) > > Russ > Regards, as From russw@riw.us Fri Dec 7 10:24: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 38E2721F8798 for ; Fri, 7 Dec 2012 10:24:08 -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 tBoR6o159cep for ; Fri, 7 Dec 2012 10:24:07 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id C05D821F85E1 for ; Fri, 7 Dec 2012 10:24:07 -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 1Th2al-0001W8-5h; Fri, 07 Dec 2012 10:24:07 -0800 Message-ID: <50C23444.6090608@riw.us> Date: Fri, 07 Dec 2012 13:24:04 -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: Arturo Servin References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> <50C12BA5.70503@riw.us> <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> <50C1E03B.1040802@riw.us> <50C22A7A.2090000@lacnic.net> In-Reply-To: <50C22A7A.2090000@lacnic.net> 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, 07 Dec 2012 18:24:08 -0000 > You are twisting the fact when you are mixing hosted-rpiki and > rpki-repositories as the same thing. Please feel free to point to the place in any message when I actually said they are the same thing. They are part of the same system, not the same thing --and I don't think I ever claimed otherwise. > No, I am saying that rpki hosted (the web interface) is not critical > for RPKI. Depends on who's ox is being gored, I suppose. For the provider/RIR, it's not so crucial. For the customer, it seems like it might be (depending on the customer, etc.). I would think that if I were losing x million of dollars per minute because my site is unreachable, I might consider being able to reach the services required to bring my site back onto the web to be somewhat important... Along with the time required to propagate information through that system, etc. > A bit, you are (in my understanding) are still mixing hosted-rpiki and > rpki-repositories. ;-) No... There is an entire ecosystem here, not just one "thing." There is the certificate structure, four or five kinds of certificates themselves, the data replication service (possibly multiples), a set of protocols for getting the information between the replicating server and the router, and now, from what I understand, a hosted service as well... The point Eric was making is that each piece of the system adds complexity. The counter was, "what complexity?" My answer is --each and every piece adds complexity, no matter whether each particular piece is considered "crucial," etc. More moving parts == more complexity Sometimes internal complexity is a good tradeoff for external simplicity, but that doesn't make the complexity issues, along with the brittleness, ossification, and systemic dependencies go away, it just hides them. :-) Russ From Sandra.Murphy@sparta.com Fri Dec 7 11:38: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 041AC21F86D5 for ; Fri, 7 Dec 2012 11:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 BmV0bGSIVb+o for ; Fri, 7 Dec 2012 11:38:17 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id F168421F8615 for ; Fri, 7 Dec 2012 11:38:16 -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 qB7JcFeu027456 for ; Fri, 7 Dec 2012 11:38:15 -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 qB7JcFJC004785 for ; Fri, 7 Dec 2012 11:38: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; Fri, 7 Dec 2012 14:38:18 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: about "beaconing" and the bgspec-protoocol Thread-Index: Ac3UrndrVbkOg59YQBGCQbRWvaQqTw== Date: Fri, 7 Dec 2012 19:38:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@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] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 19:38:18 -0000 >From comments made at the mike in the last IETG sidr session after the disc= ussion of key rollover techniques, I think there might be a bit of confusio= n about beaconing.=0A= =0A= An Expire Time was a feature of the bgpsec protocol in versions 00-01. The= purpose of the Expire Time was to prevent replay and ensure freshness. T= he effect of this feature was to require periodic readvertisements of all p= refixes, hence the name "beaconing".=0A= =0A= Based on wg discussions, "beaconing" was removed from the bgpsec protocol i= n versions 02 (Mar 12) forward.=0A= =0A= Protection against human time scale replay, e.g., from neighbor relationshi= ps that change, was suggested to be possible through the use of key rollove= r.=0A= =0A= --Sandy, speaking as co-chair= From christopher.morrow@gmail.com Fri Dec 7 13:54: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 8E72E21F87E3 for ; Fri, 7 Dec 2012 13:54:37 -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 txGt0UhuIUW0 for ; Fri, 7 Dec 2012 13:54: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 B00AB21F87E1 for ; Fri, 7 Dec 2012 13:54:36 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so601646eek.31 for ; Fri, 07 Dec 2012 13:54: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=t4/Ohhsxs35nKV/RFCv3B09FTWPlDQeN4/NUzaTh8SY=; b=hcm2R33f3TVpfjxoXbxU+t+FGyPEU0eVcxEB966QReozEhYED9UchT9YrRgVbwgx2q CNp1/RK3mVl98Y8UwO8iZWW1pfb9r+kUTPgNX6jUv3NsVc9NiZXDm1qtXPQlPTYhwTs9 AKQfeXQxsM467sUZpbUa2oCgM0uyn80Uow6sTb1q9bWeyhObr3hgUranq3VxSnctHyQG FXR6YjrVhdKuFa2sO5pKVmyFj6zgmCtpQhzXVt2YIBop5eECkeGFsdlB/v0V42yotV3h Wy3vNeyFcXFNHbfWVE9C4uEkDJ389aY/uTI+XtWVGsnZ4TfjnkxBuGgXugAIo37ISmx+ RzOg== MIME-Version: 1.0 Received: by 10.14.184.131 with SMTP id s3mr21107870eem.38.1354917275949; Fri, 07 Dec 2012 13:54:35 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Fri, 7 Dec 2012 13:54:35 -0800 (PST) In-Reply-To: References: <651F19EA-5D9F-4684-A1EF-073596A8A52E@verisign.com> Date: Fri, 7 Dec 2012 16:54:35 -0500 X-Google-Sender-Auth: npyj_47_ggDfRXvHdSaX_XTez88 Message-ID: From: Christopher Morrow To: "Montgomery, Douglas" Content-Type: text/plain; charset=ISO-8859-1 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, 07 Dec 2012 21:54:37 -0000 On Fri, Dec 7, 2012 at 12:35 PM, Montgomery, Douglas wrote: > suggesting/discussing loading a RIB from DNS queries. I was thought we > were discussing information systems that might allow me to validate the > origin of an router's RIB. That problem is O(500K) at time zero. backing up a bit in the thread, and I hope/think setting some things up a bit better for the conversation... or attempting to :) If we look at the whole system (or a bunch of it) in SIDR/BGPSEC/RPKI, there are likely these moving parts: o RPKI repositories (some number, let's say 1/ASN for simple numbers) o RPKI TAL/TA/'Root' bits (say 5 today, hopefully 1 tomorrow which then lets you walk down the tree to find all the actors) o network operators running networks (again 1/ASN) o gathering hosts/systems at each of the above would talk to all repositories and gather the content for local use/distribution (again 1/ASN at least, probably safe to assume 2/ASN at least) o cache systems inside each ASN, more than 1, less than 1/router seems sane? In the end, the last item is completely up to the AS operator in question. They may choose to run 1 cache/router, or one for their ASN, they are responsible (according to the docs) to keep their cache's semi-coherent, or as close to coherent as they can. So, looking at timing information there's a base time for: "Make a ROA/EE/etc change to the local repository", that timing is almost up to the local operator, then things beyond that are about automatic... first gatherers get data, then local-caches will get sync'd and distribute to the routers the updates required. It's important to note that a smart solution would only pass updates to the caches, or rather the caches would update from some point-in-time that the gatherers kept. (again, this is likely dependent upon the local operator's timing requirements/design). One point that's brought up a bunch on the thread so far is 'cold start'. There are many forms of this: o for a router o for a cache o for a gatherer o for an ASN I think for some the answer is 'easy', and the timings are 'fast'. For others though the timing is longer. For instance, a router cold-start (presuming no special knob request) is: 1) boot 2) load-os/config 3) prefer internal/igp 4) load cache-data 5) bring up bgp (e and i) sessions (it's probably harder to determine if 3 and/or 5 happen before 4 today, but that seems like a vendor tweak to me) Loading the cache data should be essentially lan-speed limited... or at least limited by the cache deployment that the operator picks. A gatherer cold-start is: "Fetch all objects from all remote repositories" and is likely bounded by times calculated in eric's paper... or similar. 1/asn links with X average time to connect/download/digest... An ASN cold-start is ... actually pretty simple, except that they rely upon everyone else finding them, so they are likely bounded on start by the time it takes all remote-asns to walk the system and find them (call it 4hrs based on the timings in the ops-docs?). I think the discussion so far has centered around 'all' of the system, but has variously talked about only 1-2 parts (really) when it comes to timings. Could we think about the problem-space and timings in the above framework? or alter the above to something we can all agree upon? -Chris From christopher.morrow@gmail.com Fri Dec 7 13:56: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 94A1521F851B for ; Fri, 7 Dec 2012 13:56:37 -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 p1MCuZM-63fU for ; Fri, 7 Dec 2012 13:56: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 1DF7821F881E for ; Fri, 7 Dec 2012 13:56:35 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so602369eek.31 for ; Fri, 07 Dec 2012 13:56:35 -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=57n8L56qE9E40rqgHdA+oY0XVIvtUJZMqezIWhqbtSs=; b=Y09Uf3DFuexRngJhy8v7Y1MDRJYulWw+JLhC43ccoJwM6huheBJ9jtVM4zOl2Avuue LhscpnvBBMVhdSge28HvOWOZfMA6jl2bN60Y6IogwiVbND/cnwhH2efYu14jM6EpUFs6 btOF+6yHGykb4Lybqsd0ZldDpXnSCnsTfJGrfzGas17nIjdQSTqb8LuHh1cD95W9OfKy LV/cGNIaitczYuDITJeo4ZwmOz8ZyML78QEjWCDAuIDeZ1wdgf5HoLM1uI46GwWC468w 5YeuDHI1ionvZQJweZ6PjHN0NFxweKQeg7zNPb98RwsV1oiPlQxkBML7WSDobAOq4lTf aOJA== MIME-Version: 1.0 Received: by 10.14.178.196 with SMTP id f44mr21448186eem.14.1354917395325; Fri, 07 Dec 2012 13:56:35 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Fri, 7 Dec 2012 13:56:34 -0800 (PST) In-Reply-To: <50C23444.6090608@riw.us> References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <8DE41D7E-E6DD-4A23-85DB-D801057A4ADB@bbn.com> <00F64686-1EBE-4A87-A151-ECCABAC2816F@verisign.com> <5F100FF1-D124-4641-9856-96440A3EA0EF@bbn.com> <3A2C1E29-B262-478D-8644-A7B90F38460A@verisign.com> <3886DF1F-3AF7-48F9-BCF5-1731FC1E8209@bbn.com> <50C12BA5.70503@riw.us> <33192.187.33.33.158.1354846146.squirrel@www.lacnic.net.uy> <50C1E03B.1040802@riw.us> <50C22A7A.2090000@lacnic.net> <50C23444.6090608@riw.us> Date: Fri, 7 Dec 2012 16:56:34 -0500 X-Google-Sender-Auth: 6tfajzE3cRlXasbnvu738pEWErY Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 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, 07 Dec 2012 21:56:37 -0000 On Fri, Dec 7, 2012 at 1:24 PM, Russ White wrote: > >> You are twisting the fact when you are mixing hosted-rpiki and >> rpki-repositories as the same thing. (*note quoting russ's message, but not actually aiming at russ in particular) could we focus a bit of the conversation on the issues of scaling and timing and not on this one particular bit of the puzzle which is optional anyway? (hosted repositories) I don't think it helps to focus on 'to host or not' since really the problem of timing is not about where the repository is (as much, corner cases aside) as that there is a repository. thanks! -chris From christopher.morrow@gmail.com Fri Dec 7 14:17: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 0D7B821F8BC1 for ; Fri, 7 Dec 2012 14:17:58 -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 D5mpZsAs6oqH for ; Fri, 7 Dec 2012 14:17: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 3BFDF21F8706 for ; Fri, 7 Dec 2012 14:17:56 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so377875eaa.31 for ; Fri, 07 Dec 2012 14:17:54 -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=45d0VS+N2S3lSY1WWC3K7wJKPrUmOGwtmtwEvB1ywMs=; b=SaA3SEfiugrYV/Eubwb/6SpUnNZLab50228xmDkZ/CLTxjRm2/+J1Ji6Y5vbcSAbo9 fxfurt3jLoWOmEfzAA/5WY9/S9NNRdoQx2QwhmqF2hljkdQfsNGrLKBpoAuUjT/gWpzJ fqomtbGL0Xm1y6WQg4pBMlS5MngqA2hqeAH0wlsRvy0WWqdwKiB3e+XGwPfMjrHDtuqH BZHsdsm1+btPk5BCbItmNQoSu8TL4kKWCybrCjITchfEoaBeTxeBsf4RBP+ppm/++THS 5TCHtDueXypv81SKQwZXd2W2kimigE8doGXD0hD8xT98o68QRrqzWVs17/tdcr8MlMz9 /1XQ== MIME-Version: 1.0 Received: by 10.14.202.3 with SMTP id c3mr21710739eeo.4.1354918674263; Fri, 07 Dec 2012 14:17:54 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.177.5 with HTTP; Fri, 7 Dec 2012 14:17:54 -0800 (PST) In-Reply-To: References: <50C21F2E.6000708@isode.com> Date: Fri, 7 Dec 2012 17:17:54 -0500 X-Google-Sender-Auth: RXl22lcAUBSxO8vs5jFK38-6qe4 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg Subject: Re: [sidr] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 22:17:58 -0000 clarifying question in your example... On Fri, Dec 7, 2012 at 12:32 PM, Brian Dickson wrote: > P.S. Here is a worked example to illustrate this concept: > > Suppose the initial state of affairs is as follows: > 10.0.0.0/8 is delegated by IANA to RIR "A". RIR "A" does not route any > portion of this block, but only doles out portions of it. > 10.1.0.0/16 is delegated by RIR "A" to LIR "A1". Again, not routed. > 10.1.0.0/20 is delegated by LIR "A1" to ISP "B". ISP B routes this prefix. > 10.1.15.0/24 is delegated by ISP "B" to customer "C". C routes this prefix, > which is more-specific and preferred over 10.1.0.0/20. > > Now add to the above, that ISP "B" goes out of business. > > The proposed way of directly assigning the 10.1.15.0/24 to "C" would be to > have the delegation done directly to "C" by RIR "A", or by LIR "A1". > (Or by IANA, only included for completeness, i.e. this would likely never > happen.) > > And, in order to continue to assure the uniqueness of the assignment, the > corresponding delegations would need to explicitly call out the > NON-delegation of 10.1.15.0/24, attached to the delegation chain starting > wherever the fork occurred. you mean a CRL would be updated with the previous certificate for 10.1.15.0/24 ? So, you are essentially saying: "Grandparenting == re-delegation + break-old-delegation-cert" ? (seems ok to me...) > So, if the direct delegation is done by LIR "A1", the new delegations by A1 > would be: > 10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B" (which is defunct, > presumably, but whose assets might be sold to another party)) > 10.1.15.0/24 (to "C" directly) > > Or if the direct delegation is done by RIR "A", the delegations would be: > 10.1.0.0/16 minus 10.1.15.0/24 (from RIR "A" to LIR "A1") > 10.1.15.0/24 (from RIR "A" to end-user "C") > 10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B") > > The "minus foo" would need to be attached to any delegation covering "foo", > throughout the delegation hierarchy, once such a "fork" occurs. > ROA validation would need to check this, but the logic is quite simple. or just adhere to the crl, right? > On Fri, Dec 7, 2012 at 11:54 AM, Alexey Melnikov > wrote: >> >> Hi, >> Sorry for procrastinating on this for so long. >> >> Here are questions I would like to ask WG participants. At this point I >> would like to ask people to review the questions and let me know if you >> think they are contradictory. If they are clear, I will poll the WG early >> next week. Comments on the mailing list or sent directly to WG chairs >> are welcome. >> >> ---------------- >> >> 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02 >> actually a problem that the WG needs to address? (Answer: yes or no. >> Additional information is welcomed, but I don't want people to repeat the >> whole discussion.) >> >> 2) If you answered "yes" to the question #1, please also answer the >> following question: >> >> Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to become >> a WG document? Please choose one of the following: >> >> >> a) Ready for Adoption (whether or not you have some specific issues with >> it. Also, this answer is unrelated to whether this should be a separate >> draft or a part of an existing draft). >> >> b) Needs more work BEFORE Adoption >> >> c) Should not be adopted. In particular this mean that you don't believe >> any amount of work on the proposed draft will address your issues. So any >> solution to this problem should be a new draft written from scratch. >> >> d) Abstain/don't care >> >> >> 3) If you answered "a" or "b" above, please also answer the following >> question: >> >> Does this need to be in a standalone draft, or can it be incorporated into >> another existing WG draft? When answering this question please only base >> your answer on technical reasons, in particular please leave the decision on >> who is going to edit the document (if it is standalone) to WG chairs. >> >> >> _______________________________________________ >> 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 danny@tcb.net Fri Dec 7 15:24: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 885D921F87C5 for ; Fri, 7 Dec 2012 15:24:03 -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 P9L198v7iSvN for ; Fri, 7 Dec 2012 15:24:02 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7F19F21F8BA6 for ; Fri, 7 Dec 2012 15:24:02 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 1113E2444 for ; Fri, 7 Dec 2012 23:24:02 +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 6394D23FA; Fri, 7 Dec 2012 16:24:01 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> Date: Fri, 7 Dec 2012 18:24:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Fri Dec 7 16:24: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: 50c27a91199631821520456 X-DSPAM-Factors: 27, the+#+#+#+by, 0.01000, 2012+#+2, 0.01000, On+#+7, 0.01000, in+BGP, 0.01000, in+BGP, 0.01000, to+#+this, 0.01000, a+#+#+I, 0.01000, Murphy+Sandra, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+#+#+to, 0.01000, to+#+#+#+that, 0.01000, this+is, 0.01000, as+well, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, and+#+the, 0.01000, Cc*ietf.org+sidr, 0.01000, to+#+#+and, 0.01000, 7+#+at, 0.01000, and+#+them, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, to+#+#+#+in, 0.01000, routing+system, 0.01000, routing+system, 0.01000 Cc: "sidr@ietf.org" Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 07 Dec 2012 23:24:03 -0000 On Dec 7, 2012, at 2:38 PM, Murphy, Sandra wrote: > =46rom comments made at the mike in the last IETG sidr session after = the discussion of key rollover techniques, I think there might be a bit = of confusion about beaconing. >=20 > An Expire Time was a feature of the bgpsec protocol in versions 00-01. = The purpose of the Expire Time was to prevent replay and ensure = freshness. The effect of this feature was to require periodic = readvertisements of all prefixes, hence the name "beaconing". >=20 > Based on wg discussions, "beaconing" was removed from the bgpsec = protocol in versions 02 (Mar 12) forward. >=20 > Protection against human time scale replay, e.g., from neighbor = relationships that change, was suggested to be possible through the use = of key rollover. I'm pretty sure the captured proceedings for "Discussion of Key Rollover = Mechanisms for Replay-Attack Protection" [!=3Dbeacon?] mentions "beacon" = at least eleven times. Additionally, "BGPSEC router key rollover" was = about periodic updates (aka "beacons") as well. Folks can name them periodic updates, or beacons, or even stretch and = call them triggered updates if you want. Adding new attributes to = standards-track BGP that require a "refresh" function through *some* new = attribute by the origin AND independently by each transit AS (and = perhaps each BGPSEC-enabled BGP router therein) under the auspices of = "key rollover" rather than "freshness" is, well, still pretty much the = same thing functionally - they're still periodic updates in a soft state = protocol that don't exist in BGP today. I still contend that doing anything to introduce periodic updates in the = global inter-domain routing system is a terrible idea and is something = we should avoid altogether. Even [ripv1-rfc1058] provides some hints as = to why this is a bad idea. I know we're focusing on hyper-deduced stuff here, but the combinatorial = effects of orders of magnitude larger updates in BGP through BGPSEC = proposals, breaking and effectively disabling the ability for BGP update = packing anywhere, considerable added churn through origination and = transit node-triggered "beacons", and added processing overhead for = cryptographic functions for signing and validation, all in today's BGP, = sure makes me real concern about our goals and if the reward outweighs = the risk here. I highly recommend that these documents be experimental and people = playing with this stuff in BGP do so in closed environments, not on = routers attached to the global routing system; it's fragile enough as = is. -danny [!=3Dbeacon?] = http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf [ripv1-1058] http://tools.ietf.org/html/rfc1058 From internet-drafts@ietf.org Fri Dec 7 23:06: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 D1F5D21F8472; Fri, 7 Dec 2012 23:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 8Sn5X1DJux5n; Fri, 7 Dec 2012 23:06:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB621F86C3; Fri, 7 Dec 2012 23:06:37 -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: <20121208070637.9560.20235.idtracker@ietfa.amsl.com> Date: Fri, 07 Dec 2012 23:06:37 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 07:06:38 -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 : BGP Prefix Origin Validation State Extended Community Author(s) : Pradosh Mohapatra Keyur Patel John Scudder David Ward Randy Bush Filename : draft-ietf-sidr-origin-validation-signaling-02.txt Pages : 6 Date : 2012-12-07 Abstract: As part of the origination AS validation process, it can be desirable to automatically consider the validation state of routes in the BGP decision process. The purpose of this document is to provide a specification for doing so. The document also defines a new BGP opaque extended community to carry the validation state inside an autonomous system to influence the decision process of the IBGP speakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-validation-signal= ing-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kotikalapudi.sriram@nist.gov Sat Dec 8 06:28: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 2B45621F86D5 for ; Sat, 8 Dec 2012 06:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 OUgOmpRWUjRA for ; Sat, 8 Dec 2012 06:28:49 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3933421F867B for ; Sat, 8 Dec 2012 06:28:48 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 8 Dec 2012 09:27:55 -0500 Received: from MBCLUSTER.xchange.nist.gov ([2002:8106:125b::8106:125b]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sat, 8 Dec 2012 09:28:04 -0500 From: "Sriram, Kotikalapudi" To: Danny McPherson , "Murphy, Sandra" Date: Sat, 8 Dec 2012 09:25:14 -0500 Thread-Topic: [sidr] about "beaconing" and the bgspec-protoocol Thread-Index: Ac3U0ZDFa1YhdJjLQTiulpMktwaN+QAd01/T Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 08 Dec 2012 14:28:50 -0000 >> From comments made at the mike in the last IETG sidr session after the d= iscussion of key rollover techniques, I think there might be a bit of confu= sion about beaconing. >> >> An Expire Time was a feature of the bgpsec protocol in versions 00-01. = The purpose of the Expire Time was to prevent replay and ensure freshness.= The effect of this feature was to require periodic readvertisements of al= l prefixes, hence the name "beaconing". > > I'm pretty sure the captured proceedings for "Discussion of Key Rollover = Mechanisms for Replay-Attack Protection" [!=3Dbeacon?] mentions "beacon" at= least eleven times. Additionally, "BGPSEC router key rollover" was about = periodic updates (aka "beacons") as well. Semantically, Beaconing =3D Periodic re-origination of prefixes Beaconing (i.e., periodic re-origination) was an attribute of the explicit = Expire Time method,=20 and it IS an attribute of the periodic key rollover (PKR) method as well. However, beaconing (periodic re-origination) IS NOT an attribute of the Eve= nt-driven Key Rollover (EKR) method.=20 This is all fairly well documented in [draft-sriram-replay-protection-desig= n-discussion]: =20 http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion= -00=20 and also in my presentation slides from the Atlanta IETF SIDR session: =20 http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf Periodic key rollover (PKR) is currently recommended in [draft-ietf-sidr-bg= psec-rollover]=20 as evident from the following quote (from Section 4.2): =93For this reason, it is recommended that routers in this scenario been provisioned with two certificates: one to sign BGP UPDATES in transit and a second one to sign BGP UPDATE for prefixes originated in its AS. Only the second certificate (for prefixes originated in its AS) should be rolled-over frequently as a means of limiting replay attach windows. The transit BGPSEC certificate is expected to be longer living than the origin BGPSEC certificate.=94 In the PKR method, the "current" origination cert (and key pair) expires at= periodic intervals=20 and updates are re-originated signed by the "next" origination cert. No CRLs need to propagate; the cert expiry is automated by setting NotValid= After time, and the "next" cert is always pre-provisioned well in advance.=20 None of it is tied to human scale intervention -- it can all be automated. In the same section (section 4.2) , the authors also observed: =93Advantage of Re-keying as replay attack protection mechanism: 1. Does not require beaconing=94 However, that advantage #1 is not correct for the periodic key rollover met= hod, which is currently recommended.=20 > > considerable added churn through origination and transit node-triggered "= beacons", and added processing overhead for cryptographic functions for sig= ning and validation,=20 > Just to clarify, *transit* prefixes are not beaconed (i.e., not "periodical= ly" re-propagated) by *transit routers* in any of the key rollover methods. The PKR method has periodic re-origination of origination prefixes only=20 (i.e., each eBGP router periodically re-originates its origination prefixes= ). The EKR method by definition is event-driven, hence does not entail any per= iodic re-originations.=20 The events (topology changes, etc.) are presumably rare/infrequent.=20 Sriram From Sandra.Murphy@sparta.com Mon Dec 10 06:38:09 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 A7CEE21F8467 for ; Mon, 10 Dec 2012 06:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 S9WdTlxlv-J8 for ; Mon, 10 Dec 2012 06:38:09 -0800 (PST) Received: from Uther.sparta.com (uther.sparta.com [157.185.0.2]) by ietfa.amsl.com (Postfix) with ESMTP id D508E21F845E for ; Mon, 10 Dec 2012 06:38:08 -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 qBAEc7xM012504; Mon, 10 Dec 2012 06:38:07 -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 qBAEc7Bf011328; Mon, 10 Dec 2012 06:38:07 -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, 10 Dec 2012 09:38:07 -0500 From: "Murphy, Sandra" To: Danny McPherson Thread-Topic: [sidr] about "beaconing" and the bgspec-protoocol Thread-Index: Ac3UrndrVbkOg59YQBGCQbRWvaQqTwATWE0AAHhw5Ec= Date: Mon, 10 Dec 2012 14:38:05 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E560E@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@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 Cc: "sidr@ietf.org" Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 10 Dec 2012 14:38:09 -0000 >I'm pretty sure the captured proceedings for "Discussion of Key Rollover M= echanisms for=20 >Replay-Attack Protection" [!=3Dbeacon?] mentions "beacon" at least eleven = times. And hence the confusion. Sriram's presentation was about strategies of doing key rollover, not a pro= tocol feature. >Adding new attributes to standards-track BGP that require a "refresh" func= tion through *some*=20 >new attribute by the origin AND independently by each transit AS (and perh= aps each=20 >BGPSEC-enabled BGP router therein) under the auspices of "key rollover" ra= ther than=20 >"freshness" is, well, still pretty much the same thing functionally - they= 're still periodic updates >in a soft state protocol that don't exist in BGP today. One of the strategies Sriram mentioned involved key rollover at regular int= ervals. The other strategies do not change keys regularly. The new attribute does not have a required refresh function. It uses crypt= o and any use of crypto requires the ability to change keys. =20 The strategy for changing the crypto keys is an individual decision of the = ISPs, not a protocol feature. ISPs may decide to change keys at regular pe= riods, or they may not. (And reports of current ISP behavior wrt TCP MD5 ke= ys seems to be that they currently decide never to change keys at all, iron= ically.) No one knows what ISPs will decide, so it is incorrect to describ= e the system effects of this one strategy out of many key rollover strategi= es as a feature of the protocol. >I still contend that doing anything to introduce periodic updates in the g= lobal inter-domain routing system=20 >is a terrible idea and is something we should avoid altogether. Even [rip= v1-rfc1058] provides some=20 >hints as to why this is a bad idea. Periodic updates are not introduced in this wg. Periodic updates are not a= feature of the protocol. Periodic updates could arise only if everyone ch= ose the regular interval key rollover strategy. There is nothing in this si= dr work that forces that choice. The strategy for changing keys is a func= tion of the *individual* *independent* decisions by the ISPs. Perhaps you would prefer it if the ops document discouraged the ISPs from c= hoosing that particular key rollover strategy. --Sandy, speaking as co-chair ________________________________________ From: Danny McPherson [danny@tcb.net] Sent: Friday, December 07, 2012 6:24 PM To: Murphy, Sandra Cc: sidr@ietf.org Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol On Dec 7, 2012, at 2:38 PM, Murphy, Sandra wrote: > From comments made at the mike in the last IETG sidr session after the di= scussion of key rollover techniques, I think there might be a bit of confus= ion about beaconing. > > An Expire Time was a feature of the bgpsec protocol in versions 00-01. T= he purpose of the Expire Time was to prevent replay and ensure freshness. = The effect of this feature was to require periodic readvertisements of all= prefixes, hence the name "beaconing". > > Based on wg discussions, "beaconing" was removed from the bgpsec protocol= in versions 02 (Mar 12) forward. > > Protection against human time scale replay, e.g., from neighbor relations= hips that change, was suggested to be possible through the use of key rollo= ver. I'm pretty sure the captured proceedings for "Discussion of Key Rollover Me= chanisms for Replay-Attack Protection" [!=3Dbeacon?] mentions "beacon" at l= east eleven times. Additionally, "BGPSEC router key rollover" was about pe= riodic updates (aka "beacons") as well. Folks can name them periodic updates, or beacons, or even stretch and call = them triggered updates if you want. Adding new attributes to standards-tra= ck BGP that require a "refresh" function through *some* new attribute by th= e origin AND independently by each transit AS (and perhaps each BGPSEC-enab= led BGP router therein) under the auspices of "key rollover" rather than "f= reshness" is, well, still pretty much the same thing functionally - they're= still periodic updates in a soft state protocol that don't exist in BGP to= day. I still contend that doing anything to introduce periodic updates in the gl= obal inter-domain routing system is a terrible idea and is something we sho= uld avoid altogether. Even [ripv1-rfc1058] provides some hints as to why t= his is a bad idea. I know we're focusing on hyper-deduced stuff here, but the combinatorial ef= fects of orders of magnitude larger updates in BGP through BGPSEC proposals= , breaking and effectively disabling the ability for BGP update packing any= where, considerable added churn through origination and transit node-trigge= red "beacons", and added processing overhead for cryptographic functions fo= r signing and validation, all in today's BGP, sure makes me real concern ab= out our goals and if the reward outweighs the risk here. I highly recommend that these documents be experimental and people playing = with this stuff in BGP do so in closed environments, not on routers attache= d to the global routing system; it's fragile enough as is. -danny [!=3Dbeacon?] http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pd= f [ripv1-1058] http://tools.ietf.org/html/rfc1058= From randy@psg.com Mon Dec 10 09:17: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 D57EB21F8557 for ; Mon, 10 Dec 2012 09:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 IZM3vNoc4qNV for ; Mon, 10 Dec 2012 09:17:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5421F8552 for ; Mon, 10 Dec 2012 09:17:59 -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 1Ti6zN-0009Jj-H5; Mon, 10 Dec 2012 17:17:57 +0000 Date: Tue, 11 Dec 2012 02:17:56 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E560E@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@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] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 10 Dec 2012 17:17:59 -0000 > reports of current ISP behavior wrt TCP MD5 keys seems to be that they > currently decide never to change keys at all, ironically. currently, you would have to synch simultaneous config changes at both ends of the wire, not reasonable. and, instead of vendors doing the simple hack of rfc 4808, we've been waiting five+ years for the promised nirvana of tcp-ao. a kewpie doll for the first person who can cite a real deployed tcp-ao implementation. randy From danny@tcb.net Mon Dec 10 11:51: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 1502221F85EA for ; Mon, 10 Dec 2012 11:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.328 X-Spam-Level: X-Spam-Status: No, score=-100.328 tagged_above=-999 required=5 tests=[AWL=0.109, 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 EbjhK8b2Hyg1 for ; Mon, 10 Dec 2012 11:51:27 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id EA20C21F861F for ; Mon, 10 Dec 2012 11:51:26 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id C5D08300035 for ; Mon, 10 Dec 2012 19:51:25 +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 8F88F30003D for ; Mon, 10 Dec 2012 12:51:25 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E560E@Hermes.columbia.ads.sparta.com> Date: Mon, 10 Dec 2012 14:51:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <574E280B-9B0E-45B4-8312-7F13A6AFE2EC@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F63C1E560E@Hermes.columbia.ads.sparta.com> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Dec 10 12:51: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: 50c63d3d199631369610597 X-DSPAM-Factors: 27, to+#+#+in, 0.01000, to+#+this, 0.01000, in+#+routing, 0.01000, Murphy+Sandra, 0.01000, wrote+I, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+system, 0.01000, wrote+#+#+#+that, 0.01000, 2012+#+#+#+AM, 0.01000, this+is, 0.01000, is+#+#+#+and, 0.01000, that+#+#+is, 0.01000, Murphy+#+#+I, 0.01000, 2012+at, 0.01000, the+routing, 0.01000, BGP+#+that, 0.01000, To*list+#+ietf.org, 0.01000, On+Dec, 0.01000, to+#+#+#+in, 0.01000, routing+system, 0.01000, routing+system, 0.01000, Mime-Version*Apple+#+framework, 0.01000, the+#+#+#+routing, 0.01000, AM+#+#+wrote, 0.01000, the+#+#+is, 0.01000, a+#+#+#+is, 0.01000, are+not, 0.01000 Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 10 Dec 2012 19:51:30 -0000 On Dec 10, 2012, at 9:38 AM, Murphy, Sandra wrote: >>=20 >> I still contend that doing anything to introduce periodic updates in = the global inter-domain routing system=20 >> is a terrible idea and is something we should avoid altogether. Even = [ripv1-rfc1058] provides some=20 >> hints as to why this is a bad idea. >=20 > Periodic updates are not introduced in this wg. Sandy,=20 The very fact that this WG is putting forth new architectures that = change BGP such that "key rollover" will need to be reflected in some = manner directly in the routing system is indeed solely on this WG. = That's an architectural thing that does NOT exist today. -danny From danny@tcb.net Mon Dec 10 11:58: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 E63A921F861E for ; Mon, 10 Dec 2012 11:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.338 X-Spam-Level: X-Spam-Status: No, score=-100.338 tagged_above=-999 required=5 tests=[AWL=0.099, 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 ICb2X21zN4jH for ; Mon, 10 Dec 2012 11:58:56 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 817A221F8510 for ; Mon, 10 Dec 2012 11:58:56 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 3D0B6300036 for ; Mon, 10 Dec 2012 19:58:56 +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 06A20300035 for ; Mon, 10 Dec 2012 12:58:55 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Mon, 10 Dec 2012 14:58:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2B50E83D-F79D-4B6E-A44F-0D44148DFCBF@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Dec 10 12:58:56 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50c63f00199632350549292 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, Mime-Version*Message+#+v1283, 0.01000, To*wg+#+sidr, 0.01000, 2012+at, 0.01000, would+#+to, 0.01000, at+#+#+PM, 0.01000, the+#+danny, 0.01000, for+a, 0.01000, have+to, 0.01000, To*list+#+ietf.org, 0.01000, Bush+wrote, 0.01000, On+Dec, 0.01000, for+the, 0.01000, for+the, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Randy+Bush, 0.01000, at+#+#+of, 0.01000, the+#+#+of, 0.01000, the+#+#+of, 0.01000, Dec+#+#+at, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, To*wg+#+#+ietf.org, 0.01000, Dec+#+2012, 0.01000, Mime-Version*1.0+#+Message, 0.01000, that+#+#+#+in, 0.01000, To*sidr+ietf.org, 0.01000 Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 10 Dec 2012 19:58:57 -0000 On Dec 10, 2012, at 12:17 PM, Randy Bush wrote: >> reports of current ISP behavior wrt TCP MD5 keys seems to be that = they >> currently decide never to change keys at all, ironically. >=20 > currently, you would have to synch simultaneous config changes at both > ends of the wire, not reasonable. and, instead of vendors doing the > simple hack of rfc 4808, we've been waiting five+ years for the = promised > nirvana of tcp-ao. a kewpie doll for the first person who can cite a > real deployed tcp-ao implementation. And that's between adjacent BGP speaking routers for a single transport = connection! I can't wait until my prefix doesn't make it 'n' AS hops through the = Internet because I used an origin or forward signing key in BGPSEC = secure path bits and an RP (BGP router) upstream didn't have that = particular validation key in their onboard state 'at the ready. =20 -danny= From Sandra.Murphy@sparta.com Mon Dec 10 12:22: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 6266221F8643 for ; Mon, 10 Dec 2012 12:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 c1X6vLRaiYQy for ; Mon, 10 Dec 2012 12:22:45 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id BB2EB21F8641 for ; Mon, 10 Dec 2012 12:22:44 -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 qBAKMgDv017776; Mon, 10 Dec 2012 14:22:42 -0600 Received: from Hermes.columbia.ads.sparta.com ([10.62.56.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qBAKMW6X009902; Mon, 10 Dec 2012 14:22:32 -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; Mon, 10 Dec 2012 15:22:32 -0500 From: "Murphy, Sandra" To: Danny McPherson , sidr wg list Thread-Topic: [sidr] about "beaconing" and the bgspec-protoocol Thread-Index: Ac3UrndrVbkOg59YQBGCQbRWvaQqTwATWE0AAHhw5EcAEaYIAAAFn02A//+xhJ4= Date: Mon, 10 Dec 2012 20:22:32 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E57C7@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> , <2B50E83D-F79D-4B6E-A44F-0D44148DFCBF@tcb.net> In-Reply-To: <2B50E83D-F79D-4B6E-A44F-0D44148DFCBF@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 Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 10 Dec 2012 20:22:45 -0000 wrt:=0A= =0A= >I can't wait until my prefix doesn't make it 'n' AS hops through the Inter= net =0A= >because I used an origin or forward signing key in BGPSEC secure path bits= =0A= >and an RP (BGP router) upstream didn't have that particular validation key= =0A= >in their onboard state 'at the ready. =0A= =0A= Keys on routers are not required for origin validation.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh= erson [danny@tcb.net]=0A= Sent: Monday, December 10, 2012 2:58 PM=0A= To: sidr wg list=0A= Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol=0A= =0A= On Dec 10, 2012, at 12:17 PM, Randy Bush wrote:=0A= =0A= >> reports of current ISP behavior wrt TCP MD5 keys seems to be that they= =0A= >> currently decide never to change keys at all, ironically.=0A= >=0A= > currently, you would have to synch simultaneous config changes at both=0A= > ends of the wire, not reasonable. and, instead of vendors doing the=0A= > simple hack of rfc 4808, we've been waiting five+ years for the promised= =0A= > nirvana of tcp-ao. a kewpie doll for the first person who can cite a=0A= > real deployed tcp-ao implementation.=0A= =0A= And that's between adjacent BGP speaking routers for a single transport con= nection!=0A= =0A= I can't wait until my prefix doesn't make it 'n' AS hops through the Intern= et because I used an origin or forward signing key in BGPSEC secure path bi= ts and an RP (BGP router) upstream didn't have that particular validation k= ey in their onboard state 'at the ready.=0A= =0A= -danny=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From danny@tcb.net Mon Dec 10 14:20: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 C42E521F86A4 for ; Mon, 10 Dec 2012 14:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.346 X-Spam-Level: X-Spam-Status: No, score=-100.346 tagged_above=-999 required=5 tests=[AWL=0.091, 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 2Bo88Kw5G-tI for ; Mon, 10 Dec 2012 14:20:36 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id EA2B421F86A2 for ; Mon, 10 Dec 2012 14:20:34 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id E8A18300036 for ; Mon, 10 Dec 2012 22:20:33 +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 90F51300035; Mon, 10 Dec 2012 15:20:33 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E57C7@Hermes.columbia.ads.sparta.com> Date: Mon, 10 Dec 2012 17:20:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <83045CB7-6D8C-46D2-B652-DEC85ACEE500@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> , <2B50E83D-F79D-4B6E-A44F-0D44148DFCBF@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63C1E57C7@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Dec 10 15:20: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: 50c66031199636861318287 X-DSPAM-Factors: 27, to+#+the, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, 2012+#+3, 0.01000, Murphy+Sandra, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+route, 0.01000, Subject*Re+#+#+beaconing, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, to+#+in, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, Subject*Re+#+#+#+and, 0.01000, Subject*sidr+#+#+#+the, 0.01000, Subject*beaconing+and, 0.01000, On+Dec, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, for+#+#+the, 0.01000, for+#+of, 0.01000, Mime-Version*Apple+#+framework, 0.01000, that+#+#+#+be, 0.01000, To*Sandra+#+sparta.com, 0.01000, Subject*beaconing+#+#+bgspec-protoocol, 0.01000, I+#+#+#+the, 0.01000, are+not, 0.01000, Subject*Re+#+about, 0.01000, Murphy+#+wrote, 0.01000 Cc: sidr wg list Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 10 Dec 2012 22:20:37 -0000 On Dec 10, 2012, at 3:22 PM, Murphy, Sandra wrote: > Keys on routers are not required for origin validation. They are required for validation of the origin ASes Signature Segment in = the Signature_Block in the BGPSEC_Path attribute, no? I.e., such that = the SKI can be used by the recipients of the route advertisement to = identify the proper certificate to use in verifying the signature? And to be clear, we're talking about BGPSEC here, not "origin = validation" as currently supported by the rpki-rtr protocol (that has no = crypto machinery, just 'prefix,origin' bindings). -danny > --Sandy, speaking as regular ol' member From danny@tcb.net Mon Dec 10 16:48: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 62FFE21F86F9 for ; Mon, 10 Dec 2012 16:48:36 -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 iBvQLzpxQUA1 for ; Mon, 10 Dec 2012 16:48:35 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id D6F5B21F86DD for ; Mon, 10 Dec 2012 16:48:35 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 7B79C300036 for ; Tue, 11 Dec 2012 00:48:35 +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 0F8D4300035; Mon, 10 Dec 2012 17:48:34 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Danny McPherson In-Reply-To: Date: Mon, 10 Dec 2012 19:48:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com>, To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Dec 10 17:48: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: 50c682e3199631764018020 X-DSPAM-Factors: 27, 2012+#+#+25, 0.01000, to+#+the, 0.01000, 8+#+at, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, and+#+#+#+these, 0.01000, all+the, 0.01000, the+#+#+#+I, 0.01000, the+#+#+#+I, 0.01000, in+BGP, 0.01000, in+BGP, 0.01000, of+#+#+#+i, 0.01000, Mime-Version*Message+#+v1283, 0.01000, and+#+#+#+to, 0.01000, is+#+#+in, 0.01000, 2012+#+#+#+AM, 0.01000, be+#+#+#+the, 0.01000, Subject*Re+#+#+beaconing, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, have+#+the, 0.01000, and+#+the, 0.01000, Cc*sidr+wg, 0.01000, and+#+and, 0.01000, we+can, 0.01000, Subject*Re+#+#+#+and, 0.01000, Subject*sidr+#+#+#+the, 0.01000, it+is, 0.01000 Cc: sidr wg list Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 11 Dec 2012 00:48:36 -0000 On Dec 8, 2012, at 9:25 AM, Sriram, Kotikalapudi wrote: >=20 > Periodic key rollover (PKR) is currently recommended in = [draft-ietf-sidr-bgpsec-rollover]=20 > as evident from the following quote (from Section 4.2): >=20 > =93For this reason, it is recommended that routers in this scenario = been > provisioned with two certificates: one to sign BGP UPDATES in = transit > and a second one to sign BGP UPDATE for prefixes originated in its > AS. Only the second certificate (for prefixes originated in its AS) > should be rolled-over frequently as a means of limiting replay = attach > windows. The transit BGPSEC certificate is expected to be longer > living than the origin BGPSEC certificate.=94 Note: There are two grammatical errors / typos in _that text fragment. That said,=20 > In the PKR method, the "current" origination cert (and key pair) = expires at periodic intervals=20 > and updates are re-originated signed by the "next" origination cert. OK, this IS _the new added churn I was referring to. This doesn't occur = in BGP today. > Just to clarify, *transit* prefixes are not beaconed (i.e., not = "periodically" re-propagated) > by *transit routers* in any of the key rollover methods. > The PKR method has periodic re-origination of origination prefixes = only=20 > (i.e., each eBGP router periodically re-originates its origination = prefixes). > The EKR method by definition is event-driven, hence does not entail = any periodic re-originations.=20 You're introducing a new "event" here that has an periodic expiry = attribute, this IS _the new added churn I was referring to. This = doesn't occur in BGP today. > The events (topology changes, etc.) are presumably rare/infrequent.=20 "presumably rare/infrequent" !=3D "does not occur".=20 To that, how was it determined that "Transit cert can have a very large = NotValidAter time", what requirement led to this?=20 Again, we can repurpose and reapply terms for = beacon/periodic/triggered/event-driven words all we want, but if an = intermediate AS needs to retransmit an advertisement because it's = forwarding signing "Transit cert" rollover; solely because of some = refresh or expiry action related to key rollover then that's something = that doesn't occur in BGP today, and yet another place where = combinatorial effects of all these "capabilities" give me concern, and = represent _the new added churn I was referring to. This doesn't occur = in BGP today. Given, leaving the attack window larger for "transit certs" reduces = churn, but it should lead one to question the broader objectives and = implications. Finally, all these options mean relying parties (i.e., BGPSEC routers) = must have all the old and new (and future?) certificates onboard and = know which to use at what time for validating which origin_as or transit = signature blocks at what times. As Randy points out, we have a hard = enough time rolling keys between adjacent BGP speaking routers for = transport connection protections. What you're proposing gives me some = real concern... -danny From Sandra.Murphy@sparta.com Tue Dec 11 09:33: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 4AEC221F86FD for ; Tue, 11 Dec 2012 09:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 mo8hy9rOaAdO for ; Tue, 11 Dec 2012 09:33:48 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6810621F8574 for ; Tue, 11 Dec 2012 09:33:48 -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 qBBHXjF0022081; Tue, 11 Dec 2012 11:33:46 -0600 Received: from Hermes.columbia.ads.sparta.com ([10.62.56.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id qBBHXeDM028361; Tue, 11 Dec 2012 11:33:40 -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, 11 Dec 2012 12:33:40 -0500 From: "Murphy, Sandra" To: Danny McPherson Thread-Topic: [sidr] about "beaconing" and the bgspec-protoocol Thread-Index: Ac3UrndrVbkOg59YQBGCQbRWvaQqTwATWE0AAHhw5EcAEaYIAAAFn02A//+xhJ6AAHYNAIAA6phu Date: Tue, 11 Dec 2012 17:33:38 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E597A@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> , <2B50E83D-F79D-4B6E-A44F-0D44148DFCBF@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F63C1E57C7@Hermes.columbia.ads.sparta.com>, <83045CB7-6D8C-46D2-B652-DEC85ACEE500@tcb.net> In-Reply-To: <83045CB7-6D8C-46D2-B652-DEC85ACEE500@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] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 11 Dec 2012 17:33:49 -0000 >They are required for validation of the origin ASes Signature Segment=0A= =0A= Apologies, I misunderstood your comment. I read "an origin or forward sign= ing key" as "(an origin) or (forward signing key)". oops.=0A= =0A= >And to be clear, we're talking about BGPSEC here, not "origin validation"= =0A= =0A= Yep. Glad to be clear.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= ________________________________________=0A= From: Danny McPherson [danny@tcb.net]=0A= Sent: Monday, December 10, 2012 5:20 PM=0A= To: Murphy, Sandra=0A= Cc: sidr wg list=0A= Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol=0A= =0A= On Dec 10, 2012, at 3:22 PM, Murphy, Sandra wrote:=0A= =0A= > Keys on routers are not required for origin validation.=0A= =0A= They are required for validation of the origin ASes Signature Segment in th= e Signature_Block in the BGPSEC_Path attribute, no? I.e., such that the SK= I can be used by the recipients of the route advertisement to identify the = proper certificate to use in verifying the signature?=0A= =0A= And to be clear, we're talking about BGPSEC here, not "origin validation" a= s currently supported by the rpki-rtr protocol (that has no crypto machiner= y, just 'prefix,origin' bindings).=0A= =0A= -danny=0A= =0A= =0A= > --Sandy, speaking as regular ol' member=0A= =0A= From danny@tcb.net Tue Dec 11 15:49: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 1839D21E80A9 for ; Tue, 11 Dec 2012 15:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.863 X-Spam-Level: X-Spam-Status: No, score=-98.863 tagged_above=-999 required=5 tests=[AWL=-1.574, BAYES_00=-2.599, DATE_IN_PAST_96_XX=1.69, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 kBWdShxgmpkV for ; Tue, 11 Dec 2012 15:49:22 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id AC9ED21E80A1 for ; Tue, 11 Dec 2012 15:49:22 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 4C6AA300022 for ; Tue, 11 Dec 2012 23:49:22 +0000 (UTC) Received: from new-host-7.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 601E730001F; Tue, 11 Dec 2012 16:49:21 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/html; charset=us-ascii X-Apple-Base-Url: x-msg://306/ X-Apple-Mail-Plain-Text-Draft: yes From: Danny McPherson X-Apple-Mail-Remote-Attachments: NO In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> X-Apple-Windows-Friendly: 1 Date: Fri, 7 Dec 2012 17:50:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7CDD1203-F8FA-44C3-BE04-030A0F8EA7CE@tcb.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com> X-Uniform-Type-Identifier: com.apple.mail-draft To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Dec 11 16:49:22 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50c7c682199632810319894 X-DSPAM-Factors: 27, 2012+#+2, 0.01000, On+#+7, 0.01000, Murphy+Sandra, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+#+#+to, 0.01000, Subject*Re+#+#+beaconing, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Cc*ietf.org+sidr, 0.01000, to+#+#+and, 0.01000, Subject*Re+#+#+#+and, 0.01000, Subject*sidr+#+#+#+the, 0.01000, Subject*beaconing+and, 0.01000, 7+#+at, 0.01000, was+a, 0.01000, On+Dec, 0.01000, To*Sandra+Sandra.Murphy, 0.01000, key+rollover, 0.01000, key+rollover, 0.01000, purpose+of, 0.01000, Mime-Version*Apple+#+framework, 0.01000, 7+#+#+2, 0.01000, To*Sandra+#+sparta.com, 0.01000, the+#+in, 0.01000, be+a, 0.01000 Cc: "sidr@ietf.org" Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 11 Dec 2012 23:49:23 -0000
On Dec 7, 2012, at 2:38 PM, Murphy, Sandra = wrote:

=46rom comments made at the mike = in the last IETG sidr session after the discussion of key rollover = techniques, I think there might be a bit of confusion about = beaconing.

An Expire Time = was a feature of the bgpsec protocol in versions 00-01.  The = purpose of the Expire Time  was to prevent replay and ensure = freshness.  The effect of this feature was to require periodic = readvertisements of all prefixes, hence the name = "beaconing".

Based on wg = discussions, "beaconing" was removed from the bgpsec protocol in = versions 02 (Mar 12) forward.

Protection = against human time scale replay, e.g., from neighbor relationships that = change, was suggested to be possible through the use of key = rollover.




= From bje@apnic.net Tue Dec 11 20:48: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 2DD1521E80BE for ; Tue, 11 Dec 2012 20:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 BMQjelS6Fnsn for ; Tue, 11 Dec 2012 20:48:58 -0800 (PST) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 8455321E80BA for ; Tue, 11 Dec 2012 20:48:53 -0800 (PST) Received: from IAMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 12 Dec 2012 14:46:35 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Wed, 12 Dec 2012 14:48:42 +1000 From: Byron Ellacott To: Alexey Melnikov Thread-Topic: [sidr] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02 Thread-Index: AQHN1JuKCN3qJcxTsUiiFTXDmlj7rJgT9w+A Date: Wed, 12 Dec 2012 04:48:42 +0000 Message-ID: <80B399CE-2539-43D5-832B-A5607BB23444@apnic.net> References: <50C21F2E.6000708@isode.com> In-Reply-To: <50C21F2E.6000708@isode.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:dc0:a000:4:6071:2e8e:1049:c42e] Content-Type: text/plain; charset="us-ascii" Content-ID: <25618822EE705F4CAC5D8CCBD3844F13@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 12 Dec 2012 04:48:59 -0000 Hi Alexey, These questions seem reasonable to me. Did you want answers now, too? Byron On 08/12/2012, at 2:54 AM, Alexey Melnikov wrot= e: > Hi, > Sorry for procrastinating on this for so long. >=20 > Here are questions I would like to ask WG participants. At this point I w= ould like to ask people to review the questions and let me know if you thin= k they are contradictory. If they are clear, I will poll the WG early next = week. Comments on the mailing list or sent directly to WG chairs are welcome. >=20 > ---------------- >=20 > 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02 a= ctually a problem that the WG needs to address? (Answer: yes or no. Additio= nal information is welcomed, but I don't want people to repeat the whole di= scussion.) >=20 > 2) If you answered "yes" to the question #1, please also answer the follo= wing question: >=20 > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to becom= e a WG document? Please choose one of the following: >=20 >=20 > a) Ready for Adoption (whether or not you have some specific issues with = it. Also, this answer is unrelated to whether this should be a separate dra= ft or a part of an existing draft). >=20 > b) Needs more work BEFORE Adoption >=20 > c) Should not be adopted. In particular this mean that you don't believe = any amount of work on the proposed draft will address your issues. So any s= olution to this problem should be a new draft written from scratch. >=20 > d) Abstain/don't care >=20 >=20 > 3) If you answered "a" or "b" above, please also answer the following que= stion: >=20 > Does this need to be in a standalone draft, or can it be incorporated int= o another existing WG draft? When answering this question please only base = your answer on technical reasons, in particular please leave the decision o= n who is going to edit the document (if it is standalone) to WG chairs. >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From alexey.melnikov@isode.com Wed Dec 12 11:56: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 7C9E421E80F4 for ; Wed, 12 Dec 2012 11:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 ZkQMB0O+0uzO for ; Wed, 12 Dec 2012 11:56:33 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6021E808D for ; Wed, 12 Dec 2012 11:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355342192; d=isode.com; s=selector; i=@isode.com; bh=vy/7AsqKosfwDGGxw8lhOYsMaWeepmzGzqcczbhG3d0=; 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=XWoq13omDkGpzMt4146bUiDkEUABeByZb/XdK3UZ57AIxnwlpKAjjpnjw7WpPrBcQU2xLK fsK86EcdBqgbml166UbyeCocRyreINkdJv9P5Qfv/YjJ8Dvcn73e1MlufqGkTtxF9QJHvK xOh7NmKzjhvlpebUc9ZdS22RpK+VjWs=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Dec 2012 19:56:32 +0000 Message-ID: <50C8E17D.3090507@isode.com> Date: Wed, 12 Dec 2012 19:56:45 +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] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 12 Dec 2012 19:56:34 -0000 Dear WG participants, I would like to initiate 2+ weeks poll (ending on December 31st 2012) regarding acceptance of draft-ymbk-rpki-grandparenting-02.txt. Please reply to questions listed below. Send your replies to the mailing list or directly to WG chairs . I would like to avoid extended discussions of technical issues at this time, as I think people already made up their minds. However including pointers to earlier discussions is fine. Alexey, on behald of SIDR chairs. ---------------- 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02 actually a problem that the WG needs to address? (Answer: yes or no. Additional information is welcomed, but I don't want people to repeat the whole discussion.) 2) If you answered "yes" to the question #1, please also answer the following question: Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to become a WG document? Please choose one of the following: a) Ready for Adoption (whether or not you have some specific issues with it. Also, this answer is unrelated to whether this should be a separate draft or a part of an existing draft). b) Needs more work BEFORE Adoption c) Should not be adopted. In particular this mean that you don't believe any amount of work on the proposed draft will address your issues. So any solution to this problem should be a new draft written from scratch. d) Abstain/don't care 3) If you answered "a" or "b" above, please also answer the following question: Does this need to be in a standalone draft, or can it be incorporated into another existing WG draft? When answering this question please only base your answer on technical reasons, in particular please leave the decision on who is going to edit the document (if it is standalone) to WG chairs. From alexey.melnikov@isode.com Wed Dec 12 12:05: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 0891211E80BF for ; Wed, 12 Dec 2012 12:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 7azDDNdR1AyN for ; Wed, 12 Dec 2012 12:05:29 -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 6952E11E80D7 for ; Wed, 12 Dec 2012 12:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355342723; d=isode.com; s=selector; i=@isode.com; bh=FDreGHVdZEwLuScGMyucoWyBUSp5cy6PcV/UUgsK6kE=; 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=uuDVHl1lUbW8aI0dDnk5J83aX/ql0uAT9SSGQgbr11SswHrzo+EHSv7Zb/7Pqw5evHC0wW yHy5tLiQeSP4oAVX2DsIoXND5P4oyTz9bK1nX3In3h4WDWF8QEsm2AZEpeJq6jomYtEZYY LTIE2jNPK5X4SKaG8w1Zy1qF08W/K5Y=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 12 Dec 2012 20:05:22 +0000 Message-ID: <50C8E390.5040002@isode.com> Date: Wed, 12 Dec 2012 20:05:36 +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 References: <50C8E17D.3090507@isode.com> In-Reply-To: <50C8E17D.3090507@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 12 Dec 2012 20:05:30 -0000 On 12/12/2012 19:56, Alexey Melnikov wrote: > Dear WG participants, > > I would like to initiate 2+ weeks poll (ending on December 31st 2012) BTW, if people think that this date should be postponed due to holiday season, that would be fine with me. > regarding acceptance of draft-ymbk-rpki-grandparenting-02.txt. [...] From warren@kumari.net Wed Dec 12 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 CAB8021F8936 for ; Wed, 12 Dec 2012 13:08:34 -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 x67GvJN9c2fK for ; Wed, 12 Dec 2012 13:08:34 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451FD21F8925 for ; Wed, 12 Dec 2012 13:08:34 -0800 (PST) Received: from [192.168.1.38] (unknown [66.84.81.123]) by vimes.kumari.net (Postfix) with ESMTPSA id B394B1B405E4; Wed, 12 Dec 2012 16:08:33 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <50C8E17D.3090507@isode.com> Date: Wed, 12 Dec 2012 16:08:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50C8E17D.3090507@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1499) Cc: sidr wg Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 12 Dec 2012 21:08:34 -0000 On Dec 12, 2012, at 2:56 PM, Alexey Melnikov = wrote: > Dear WG participants, >=20 > I would like to initiate 2+ weeks poll (ending on December 31st 2012) = regarding acceptance of draft-ymbk-rpki-grandparenting-02.txt. Please = reply to questions listed below. Send your replies to the mailing list = or directly to WG chairs . I would like to = avoid extended discussions of technical issues at this time, as I think = people already made up their minds. However including pointers to = earlier discussions is fine. >=20 > Alexey, > on behald of SIDR chairs. >=20 > ---------------- >=20 > 1) Is the problem described/solved by = draft-ymbk-rpki-grandparenting-02 actually a problem that the WG needs = to address? (Answer: yes or no. Additional information is welcomed, but = I don't want people to repeat the whole discussion.) Yes, it is a problem that I believe the WG should address=85. I don't think it is the most important issue on our plate but I do think = it is worth addressing. > 2) If you answered "yes" to the question #1, please also answer the = following question: >=20 > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to = become a WG document? Please choose one of the following: >=20 >=20 > a) Ready for Adoption (whether or not you have some specific issues = with it. Also, this answer is unrelated to whether this should be a = separate draft or a part of an existing draft). A. I believe that 1: starting from somewhere is useful (and this is = somewhere) and 2: once the WG owns the doc it can make whatever changes = it wants (well, is able to reach consensus on :-P) >=20 > b) Needs more work BEFORE Adoption >=20 > c) Should not be adopted. In particular this mean that you don't = believe any amount of work on the proposed draft will address your = issues. So any solution to this problem should be a new draft written = from scratch. >=20 > d) Abstain/don't care >=20 >=20 > 3) If you answered "a" or "b" above, please also answer the following = question: >=20 > Does this need to be in a standalone draft, or can it be incorporated = into another existing WG draft? When answering this question please only = base your answer on technical reasons, in particular please leave the = decision on who is going to edit the document (if it is standalone) to = WG chairs. What? There is no "Abstain/don't care" option for 3? ;-) W > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 --=20 "Does Emacs have the Buddha nature? Why not? It has bloody well = everything else..." From kotikalapudi.sriram@nist.gov Wed Dec 12 17:19: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 DBE9421F89CB for ; Wed, 12 Dec 2012 17:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 QhtD+gC0d+Kj for ; Wed, 12 Dec 2012 17:19:09 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id BC6DB21F89AE for ; Wed, 12 Dec 2012 17:19:08 -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; Wed, 12 Dec 2012 20:19:01 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 12 Dec 2012 20:19:07 -0500 From: "Sriram, Kotikalapudi" To: Danny McPherson Date: Wed, 12 Dec 2012 20:19:04 -0500 Thread-Topic: [sidr] about "beaconing" and the bgspec-protoocol Thread-Index: Ac3XONaXyarQv7P2QdGzKDjE1JTRWABhSeJw Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F63C1E544A@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] about "beaconing" and the bgspec-protoocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 13 Dec 2012 01:19:10 -0000 >> "For this reason, it is recommended that routers in this scenario been >> provisioned with two certificates: one to sign BGP UPDATES in transit >> and a second one to sign BGP UPDATE for prefixes originated in its >> AS. Only the second certificate (for prefixes originated in its AS) >> should be rolled-over frequently as a means of limiting replay attach >> windows. The transit BGPSEC certificate is expected to be longer >> living than the origin BGPSEC certificate." > >Note: There are two grammatical errors / typos in _that text fragment. The quote was from [draft-ietf-sidr-bgpsec-rollover] which is authored by Roque/Keyur/BrianW. Hopefully, they will make note of your comment. > >> In the PKR method, the "current" origination cert (and key pair) >> expires at periodic intervals and updates are re-originated signed by the "next" >origination cert. > >OK, this IS _the new added churn I was referring to. This doesn't occur in BGP >today. > >> Just to clarify, *transit* prefixes are not beaconed (i.e., not >> "periodically" re-propagated) by *transit routers* in any of the key rollover >methods. >> The PKR method has periodic re-origination of origination prefixes >> only (i.e., each eBGP router periodically re-originates its origination prefixes). >> The EKR method by definition is event-driven, hence does not entail any >periodic re-originations. > >You're introducing a new "event" here that has an periodic expiry attribute, this >IS _the new added churn I was referring to. This doesn't occur in BGP today. > >> The events (topology changes, etc.) are presumably rare/infrequent. > > >"presumably rare/infrequent" != "does not occur". > >To that, how was it determined that "Transit cert can have a very large >NotValidAter time", what requirement led to this? The taxonomy and details & design rationale of the different key rollover methods are fairly well explained in [draft-sriram-replay-protection-design-discussion] in Section 5. > >Again, we can repurpose and reapply terms for >beacon/periodic/triggered/event-driven words all we want, but if an >intermediate AS needs to retransmit an advertisement because it's forwarding >signing "Transit cert" rollover; solely because of some refresh or expiry action >related to key rollover then that's something that doesn't occur in BGP today, >and yet another place where combinatorial effects of all these "capabilities" >give me concern, and represent _the new added churn I was referring to. This >doesn't occur in BGP today. > >Given, leaving the attack window larger for "transit certs" reduces churn, but it >should lead one to question the broader objectives and implications. Here you have the benefit of decent descriptions of the different methods, their pros/cons etc. in [draft-sriram-replay-protection-design-discussion]. The churn is reasonably well modeled/quantified in my Atlanta presentation (slides 8 thru 11): http://www.ietf.org/proceedings/85/slides/slides-85-sidr-4.pdf Please let me know if you have specific questions about the analysis/data on churn after taking another look at slides 8-11. Please keep in mind that the churn triggered by an event such as a topology change or a policy change happens even today in BGP-4. So that type of churn is not new. As for the *new* background churn in BGPSEC with *PKR*, we have shown that it is nearly two orders of magnitude less compared to today's BGP (when peak seconds are compared) as shown in slide 8 for a 24 hour replay-attack vulnerability window (in PKR). So the additional churn in BGP due to the background churn of BGPSEC with *PKR* is practically negligible (see slide 8 - note that the y-axis is logarithmic scale.) Again, in [draft-sriram-replay-protection-design-discussion] we are not advocating any specific choice of key rollover. It is a discussion document and a companion to [draft-ietf-sidr-bgpsec-rollover]. The latter is planned to be a BCP and authored by Roque/Keyur/BrianW. > >Finally, all these options mean relying parties (i.e., BGPSEC routers) must have >all the old and new (and future?) certificates onboard and know which to use at >what time for validating which origin_as or transit signature blocks at what >times. There should be no such confusion. Receiving router does not need to do any timing in this context. At the signing router, the "next" cert becomes "current" cert when a key rollover happens. The "current" cert becomes a previous cert. The updates are always signed by the "current" cert. The "staging", "twilight" etc. w.r.t to "current" and "next" certs propagation are streamlined (see Section 3.1 of [draft-ietf-sidr-bgpsec-rollover]). Also, please take a look at [draft-ymbk-rpki-rtr-keys] https://datatracker.ietf.org/doc/draft-ymbk-rpki-rtr-keys/?include_text=1 RPKI cache sends {ASN, SKI, PubKey} data for all valid certs to RP routers, and withdraws the same for any revoked/expired certs. The updates carry ASN and SKI corresponding each signature. The {ASN, SKI} combination maps uniquely to a router's PubKey. So a BGPSEC router would be able to unambiguously pick the exact right PubKey needed to verify each signature in an update. Assume the router has two updates - the signature in one update is signed using "current" cert of a router R1 and the signature in the second update is signed using "previous" cert of the same router (R1). If both "current" and "previous" certs of the signing router (R1) happen to be valid at that time, the router can unambiguously find the correct PubKey to verify either signature. Eventually, the "previous" cert would be revoked or would expire, and then the second update would be invalid. Sriram From bje@apnic.net Wed Dec 12 18:55: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 4D4C521F8540 for ; Wed, 12 Dec 2012 18:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.557 X-Spam-Level: X-Spam-Status: No, score=0.557 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994] 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 FSilynt7KuXN for ; Wed, 12 Dec 2012 18:55:29 -0800 (PST) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 9FA3421F8566 for ; Wed, 12 Dec 2012 18:55:27 -0800 (PST) Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 13 Dec 2012 12:55:21 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by IAMDA1.org.apnic.net ([fe80::d35:7ac6:ff34:45a%19]) with mapi id 14.01.0421.002; Thu, 13 Dec 2012 12:55:21 +1000 From: Byron Ellacott To: Alexey Melnikov Thread-Topic: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 Thread-Index: AQHN2KLQNFsDPT+wmkqsEIdYrKUXupgVYaoA Date: Thu, 13 Dec 2012 02:55:20 +0000 Message-ID: References: <50C8E17D.3090507@isode.com> In-Reply-To: <50C8E17D.3090507@isode.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:dc0:a000:4:6078:8acf:678b:b25e] Content-Type: multipart/signed; boundary="Apple-Mail=_0559025F-2323-42CD-BD20-E0B8981BFB60"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 13 Dec 2012 02:55:31 -0000 --Apple-Mail=_0559025F-2323-42CD-BD20-E0B8981BFB60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alexey & WG, On 13/12/2012, at 5:56 AM, Alexey Melnikov = wrote: > 1) Is the problem described/solved by = draft-ymbk-rpki-grandparenting-02 actually a problem that the WG needs = to address? (Answer: yes or no. Additional information is welcomed, but = I don't want people to repeat the whole discussion.) No (with a 'but' under q.2). The draft itself points out why the problem does not need to be = addressed by the WG: "Managing RPKI data in such relationships is = simple, but should be done carefully." RPKI reflects records of current = INR holdings. If a CA recognises that INR holdings have changed, they = may issue certificates to reflect that. If they do not recognise = changed INR holdings, they may not issue certificates (RFC 6484 4.2.2.) = Thus, if there is a business practice to recognise grandchildrens' = rights to use resources, the RPKI can already match that practice. IOW, there IS a problem, but it's not one for a technical working group = to resolve, it's one for bilateral business relationships to resolve. Hopefully that falls under 'additional information' rather than = 'repeating the whole discussion'. :-) > 2) If you answered "yes" to the question #1, please also answer the = following question: >=20 > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to = become a WG document? Please choose one of the following: >=20 > a) Ready for Adoption (whether or not you have some specific issues = with it. Also, this answer is unrelated to whether this should be a = separate draft or a part of an existing draft). >=20 > b) Needs more work BEFORE Adoption >=20 > c) Should not be adopted. In particular this mean that you don't = believe any amount of work on the proposed draft will address your = issues. So any solution to this problem should be a new draft written = from scratch. >=20 > d) Abstain/don't care (c) While I answered 'No' for (1), recognising the "carefully" part above = may allow for a draft describing where in their CPS a CA can provide = assurance to both children and grandchildren that they will act = responsibly around these relationships, such as grace periods on = revocation. It would be possible to convert the current draft to do = that, but the amount of change would make that effectively a new draft, = I think. > 3) If you answered "a" or "b" above, please also answer the following = question: >=20 > Does this need to be in a standalone draft, or can it be incorporated = into another existing WG draft? When answering this question please only = base your answer on technical reasons, in particular please leave the = decision on who is going to edit the document (if it is standalone) to = WG chairs. n/a Thanks, Byron --Apple-Mail=_0559025F-2323-42CD-BD20-E0B8981BFB60 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBTCCBAEw ggLpoAMCAQICCA5KjJwOGD2FMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTEyMTEyMTAyMzQyMloXDTEz MTEyMTAyMzQyMlowgZExEzARBgoJkiaJk/IsZAEBDANiamUxFzAVBgNVBAMMDkJ5cm9uIEVsbGFj b3R0MQ4wDAYDVQQqDAVCeXJvbjERMA8GA1UEBAwIRWxsYWNvdHQxDzANBgNVBAsMBlBlb3BsZTEW MBQGA1UECgwNQVBOSUMgUHR5IEx0ZDEVMBMGCgmSJomT8ixkARkWBXN0YWZmMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0p0keF9Y9C0tD4BCneQHJ+6SinV7uAA0r4krfNvhkzIuRSb2 WHmGQ/xq7SwnAOGC12Duf0YhrKIPvSuUNm8CZFfYMxbpXf8snN3wJmuY9XN1Xk+eSO6hJjSdF4Bl lYyhsQKu8BEE5JxYJiVVKovL9wcTOsdOhki/a24Dec1HqPMrnCVPFv2y7StbFC58ORsMYjYGAJv8 ORXvkN7fPKIwXe0R4Eo2pUc41STJBYEsfDy+3f5U7+dWP4tPhacYIspEHXFe+jNoIGQM/vDfnlJY ZzFvLJ4ZZWSOSQ0BsnoFeRE2ga+Ny3F8rc6AwLjma/A4dHDCDZzPAO/V8COjoHKuCQIDAQABo3ow eDAdBgNVHQ4EFgQUV6PpqFcNaJv1hHbxobdrnWzz/T0wDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAW gBTgPbeSW+4uo7I+edtFqzBCLwFLrDAOBgNVHQ8BAf8EBAMCAfIwGAYDVR0RBBEwD4ENYmplQGFw bmljLm5ldDANBgkqhkiG9w0BAQUFAAOCAQEAhvN+YGyp51fHUed08dfU2JMnf0xNUxgpj4KG6egk atoCLuHp77aQwYR/B4R/vUX9gFAoLsRCgNYwQjCpLd6VufSTTV32DJVTADwNAEYhDuGlIlg/Ri5n vTOoxK6iYb1OG/PNDJ4ig5dhRzdKRnONpO7vQDATGy/Fwd8WqIsCGzQa7dY+REQjk1lbJO17rjv9 lwa+2VWa7tac7mZfbDQyvy5yeTQ//sGh7/iCq8/rrt5gEzcoc2se+lY0grvxzF6NM4lDp6UoPU4d S6TXBbDFDO/uNY0qxzOwLfeqS8dTwwB4WhMOyipxIiG12Kr+KDPrXIqidshr6jHDWhnXuBIUzDGC Ay0wggMpAgEBMH8wczERMA8GA1UEAwwIc3RhZmYtY2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQG A1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwIQnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJj YTELMAkGA1UEBhMCQVUCCA5KjJwOGD2FMAkGBSsOAwIaBQCgggGDMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTIxMzAyNTUyMFowIwYJKoZIhvcNAQkEMRYEFBYs AT8yfRSQqGgWFfTAYpTGVhVHMIGPBgkrBgEEAYI3EAQxgYEwfzBzMREwDwYDVQQDDAhzdGFmZi1j YTESMBAGA1UECwwJVGVjaG5pY2FsMRYwFAYDVQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhC cmlzYmFuZTESMBAGCgmSJomT8ixkARkWAmNhMQswCQYDVQQGEwJBVQIIDkqMnA4YPYUwgZEGCyqG SIb3DQEJEAILMYGBoH8wczERMA8GA1UEAwwIc3RhZmYtY2ExEjAQBgNVBAsMCVRlY2huaWNhbDEW MBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwIQnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZ FgJjYTELMAkGA1UEBhMCQVUCCA5KjJwOGD2FMA0GCSqGSIb3DQEBAQUABIIBAMv1kkBdmAj9RqDU Qdu7VCvCyPUh8UpwchzRrnXUL+mYwibbj9I+ofcIZ+Cmzi8Q3iclEZSItomTZuX6//Cse/hSIPgh 566f5b/sR5tlXrZHzDLPIivRLUeFw/qURbKHGsyAn/VqNDuo8X6KS3wgI09kEcfrbLfg1zlnhBtN JmWTv/SvYcnzDWzaXwZqsPqbehLTZEVEpWOnJWQfdeF/GrIfK+VaKsziSArW6trAS4pSG16KL2Ib MraohcjXWKCMd+ZIDesytwGKaPefdnZCC4+L1cxo23LqOgilx5uGX5JOTcI+5pKd28Qu8Toje8s4 J37CM6RWQTVAo2aBqeRZDZwAAAAAAAA= --Apple-Mail=_0559025F-2323-42CD-BD20-E0B8981BFB60-- From terry.manderson@icann.org Wed Dec 12 21:51: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 2C1B821F87AC for ; Wed, 12 Dec 2012 21:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 DoOZnsenXz65 for ; Wed, 12 Dec 2012 21:51:34 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 10A8F21F8792 for ; Wed, 12 Dec 2012 21:51:33 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 12 Dec 2012 21:51:32 -0800 From: Terry Manderson To: Alexey Melnikov , sidr wg Date: Wed, 12 Dec 2012 21:51:30 -0800 Thread-Topic: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 Thread-Index: Ac3Yotej/vDb5HhjRsuF37ZPJcUP4wAUw5M9 Message-ID: In-Reply-To: <50C8E17D.3090507@isode.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3438258690_1493327" MIME-Version: 1.0 Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 13 Dec 2012 05:51:35 -0000 --B_3438258690_1493327 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Alexey and WG, On 13/12/12 5:56 AM, "Alexey Melnikov" wrote: > Dear WG participants, > > I would like to initiate 2+ weeks poll (ending on December 31st 2012) I think you should extend this by 2 weeks. > > 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02 > actually a problem that the WG needs to address? (Answer: yes or no. > Additional information is welcomed, but I don't want people to repeat > the whole discussion.) Yes. > > 2) If you answered "yes" to the question #1, please also answer the > following question: > > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to > become a WG document? Please choose one of the following: No. > > > a) Ready for Adoption (whether or not you have some specific issues with > it. Also, this answer is unrelated to whether this should be a separate > draft or a part of an existing draft). > > b) Needs more work BEFORE Adoption > > c) Should not be adopted. In particular this mean that you don't believe > any amount of work on the proposed draft will address your issues. So > any solution to this problem should be a new draft written from scratch. > C. Happy holidays and best wishes for the new year! Cheers Terry --B_3438258690_1493327 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUFqwU2CqBSkQn42Hsz+py2aLUmuAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMjEzMDU1MTMwWjANBgkqhkiG 9w0BAQEFAASCAQCauEd7pgi4LeIogt1wyUKeCyT8K87RMFRetedVY3pMwCLtH1InCh58vzwy npVuMbU1ynZ2E7Gi3aNyljX/SZW/1ccmJASSmn5NtfvR2eCxKM0+v2/HGTIc6T50mH+QatT4 KZcXvDbKgcBn2gdwKk2Cctpa64TT4X5rfO+ln2Bp8hbxDqZIG7edI8ZvPZYCICidP3GOhbYe CMgWLFKAE9zCKJK0Up5tIAh6+14hPjjCP/gsT1uB1dCNv/t9Yv/Q2ZbDywrSAA6sFqZxf0ER InBkWI208q8uS7EChiiA8Q9kM5oCnuWF7CTN07O8YM4274cHADgNhh+/BNoHkh7d+2+Z --B_3438258690_1493327-- From kent@bbn.com Thu Dec 13 12:14: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 43F2321F8A7B for ; Thu, 13 Dec 2012 12:14:16 -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=[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 wyTtUKfiIwq9 for ; Thu, 13 Dec 2012 12:14:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B349A21F8A53 for ; Thu, 13 Dec 2012 12:14:15 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41560 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TjFAZ-0007Vx-QK for sidr@ietf.org; Thu, 13 Dec 2012 15:14:15 -0500 Message-ID: <50CA3713.2030303@bbn.com> Date: Thu, 13 Dec 2012 15:14:11 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <50C8E17D.3090507@isode.com> In-Reply-To: <50C8E17D.3090507@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 13 Dec 2012 20:14:16 -0000 > ---------------- > > 1) Is the problem described/solved by > draft-ymbk-rpki-grandparenting-02 actually a problem that the WG needs > to address? (Answer: yes or no. Additional information is welcomed, > but I don't want people to repeat the whole discussion.) yes. > > 2) If you answered "yes" to the question #1, please also answer the > following question: > > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to > become a WG document? Please choose one of the following: > > > a) Ready for Adoption (whether or not you have some specific issues > with it. Also, this answer is unrelated to whether this should be a > separate draft or a part of an existing draft). NO > > b) Needs more work BEFORE Adoption X > > c) Should not be adopted. In particular this mean that you don't > believe any amount of work on the proposed draft will address your > issues. So any solution to this problem should be a new draft written > from scratch. > > d) Abstain/don't care > > > 3) If you answered "a" or "b" above, please also answer the following > question: > > Does this need to be in a standalone draft, or can it be incorporated > into another existing WG draft? When answering this question please > only base your answer on technical reasons, in particular please leave > the decision on who is going to edit the document (if it is > standalone) to WG chairs. I don't recall another, extant WG draft with which this might be combined. Steve From iesg-secretary@ietf.org Fri Dec 14 04:08: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 A6BE721F84C7; Fri, 14 Dec 2012 04:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 wRIHA0yfN0PK; Fri, 14 Dec 2012 04:08:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E5C21F847B; Fri, 14 Dec 2012 04:08:29 -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: <20121214120829.16624.30581.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 04:08:29 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Definitions of Managed Objects for the RPKI-Router Protocol) 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, 14 Dec 2012 12:08:29 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Definitions of Managed Objects for the RPKI-Router Protocol' 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 2013-01-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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib/ballot/ No IPR declarations have been submitted directly on this I-D. From carlosm3011@gmail.com Fri Dec 14 09:07: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 B43A521F8952 for ; Fri, 14 Dec 2012 09:07:07 -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 MfupGk2z3FpA for ; Fri, 14 Dec 2012 09:07:07 -0800 (PST) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id C6CE021F89C0 for ; Fri, 14 Dec 2012 09:07:06 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id s35so812118yhf.27 for ; Fri, 14 Dec 2012 09:07:06 -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=4nmTlHUGCC5HdKaA2/j1uknV5uvSkdWRyLdHQCYs7eo=; b=DKsl8ZQU3jNEyzDlphLYwLCyaM6ih3ihr58v9owq8PhNM8akMThu45iHsqoy/T80da gXEiajAspVeduNQ1degqD16VcmqabGAh2FrDk6TzQorEFDfnvTpVvr3xvbNa1GPA6aKZ woQkxofD1PmZ+yXOEvnRzoJBpUUw0zrge0iWDgw90aGJAr86d3Yl0wSqpijlifZ2aUXg XmzTX3GIqeKdFVGmSo+XUwNvxA2K2aq/VEMrRC1uv1bLxHdTZPuANwuVPHuaNhi3UEmV x85XTOKWnUtm6KgSV44jLkaeeSw6jS3n02GWb5wWjRfki1kyR7S8EFM3l1xFB/y2fzUs v3Gw== Received: by 10.236.143.131 with SMTP id l3mr6267393yhj.108.1355504826438; Fri, 14 Dec 2012 09:07:06 -0800 (PST) Received: from europa.local ([2001:13c7:7001:5128:3821:bac1:7ea4:26ad]) by mx.google.com with ESMTPS id s21sm5118875yhb.5.2012.12.14.09.07.04 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 09:07:05 -0800 (PST) Message-ID: <50CB5CDB.804@gmail.com> Date: Fri, 14 Dec 2012 15:07:39 -0200 From: "Carlos M. Martinez" 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: sidr@ietf.org References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> <50C0F31A.4040400@lacnic.net> <50C0F53A.7090408@riw.us> In-Reply-To: <50C0F53A.7090408@riw.us> 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: Fri, 14 Dec 2012 17:07:07 -0000 Hi Russ, On 12/6/12 5:42 PM, Russ White wrote: > >> Yes, the hosted keep your private key, but you can modify your ROAs >> anytime you want. At least the hosted systems that I know provide a web >> interface to do that. The ROA would be published immediately or a few >> minute/hours later, depending of the rpki-operator (my personal view and >> with my network operator hat on is that it should be immediately or in >> minutes). > > Modulo the propagation time... True, but that's hardly the fault of the hosted model IMO. It's the whole architecture. > > But isn't it bad to allow automated changes to a certificate that's > designed to operate "at human speeds," (based on other conversations on > this list), and is so critical to the operation of the routing system? > Aren't we just adding to the total attack surface available against the > routing system by allowing users to go into a web page and change what's > advertised into the ROA system? Maybe. But that doesn't disqualify hosted mode as a viable model for some users. The key resides in balancing risks and benefits. As I said in an earlier email, I am convinced that hosted RPKI provides just what a large slice of the community needs. This doesn't mean hosted is perfect, or even that it's the 'best' for everyone. > > I know --it takes that bit of the problem out of the actual BGP space, > and moves it into another space altogether, but... I don't see banking > as being "more secure" because you can do all your banking on line > --it's more convenient, but I think there's a clear tradeoff in security > and convenience here, right? There definitely is and I can live with it :) Taking your example, banking is probably more insecure now that you can bank online, but who's parting with the convenience ? I think tradeoffs are everywhere and dealing with them appropriately is part of doing good system design. Again, if you are small / medium, hosted is probably right for you. If you are a large ISP, definitely it is not. And, the good thing above all, hosted is optional. If you are small / medium but still want to take the matter into your own hands, you are more than welcome. > > If this is the type of system that's envisioned, shouldn't the risks > involved be documented someplace? > By all means. But, regarding the whole system, what personally worries me the most is the full fetch model... I think we need to work on that. Hosted really doesn't bother me at all. > Russ > ~Carlos From internet-drafts@ietf.org Mon Dec 17 08:12:13 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 B5CD421F8B7A; Mon, 17 Dec 2012 08:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 YrtJ6OP4SK+Z; Mon, 17 Dec 2012 08:12:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3C821F8B6B; Mon, 17 Dec 2012 08:12:13 -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.37 Message-ID: <20121217161213.17814.88596.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 08:12:13 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 16:12:13 -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 : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-09.txt Pages : 30 Date : 2012-12-17 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-algorithm-agility-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eosterweil@verisign.com Mon Dec 17 11:35: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 7FC0021F8891 for ; Mon, 17 Dec 2012 11:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-2.519, BAYES_50=0.001, J_CHICKENPOX_53=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 2+ZwNnDAW-QM for ; Mon, 17 Dec 2012 11:35:43 -0800 (PST) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 40E2421F887B for ; Mon, 17 Dec 2012 11:35:43 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUM90Du9GHFh6wUv7rPTjScjr4djwinS5@postini.com; Mon, 17 Dec 2012 11:35:43 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 qBHJZdT5012437 for ; Mon, 17 Dec 2012 14:35:42 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.11]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Dec 2012 14:35:39 -0500 From: Eric Osterweil Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-27--491380325 Date: Mon, 17 Dec 2012 14:35:41 -0500 In-Reply-To: To: "sidr wg list (sidr@ietf.org)" References: <08EB6152-FE13-46FF-B3E7-E1D581263B8F@verisign.com> Message-Id: <418C0B16-E157-4068-A14C-F4F824402388@verisign.com> X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 17 Dec 2012 19:35:39.0101 (UTC) FILETIME=[B18E60D0:01CDDC8D] 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: Mon, 17 Dec 2012 19:35:44 -0000 --Apple-Mail-27--491380325 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I mentioned in an earlier email that we have been preparing a rather = major revision to our initial sizing tech note. As we mentioned in this = thread, and in the tech note itself, we are very much interested in = feedback,. To that end, a number of comments from people (on and off = list) were very helpful in correcting some of our thinking, and = informing some of our analyses, thank you! With apologies for the protracted delay, the new tech note is now = available at: = http://techreports.verisignlabs.com/tr-lookup.cgi?trid=3D1120005&rev=3D2 Some of the more substantial changes are: - Our core formulation for estimating the number of objects changed = according to feedback from people on the list. - We added a treatise on ``deadline'' scheduling (i.e. what do things = look like if RPKI crawls have to be done in $t$ seconds). - We removed the x2 factor from our introduction and conclusions (as = people on the list felt that this was not well supported). - We broach the almost doubling of time estimates that the RPKI will = undergo during algorithm rollover periods (``months or years'' in = duration). - We summarized our findings a bit more. There are other changes throughout, but we continue to feel that a = living document like this one is critical to understanding the way in = which a global RPKI may be likely to perform, and informing the = community. Ultimately, with the measurements that we have seen today, we still = calculate crawl times taking between about 15 and 30 days. The section = on deadline scheduling essentially finds that if we are to be able to = reliably count on crawls from all RP caches (throughout the Internet) = being done by 24 hours, the average repository in the global RPKI has to = be orders of magnitude faster than the measurements we have seen. =20 Thanks, Eric PS - In the spirit of full transparency, I have attached the = _incredibly_ complicated script that generated our Figure 1... ;) --Apple-Mail-27--491380325 Content-Disposition: attachment; filename=rpki-calc.pl Content-Type: text/x-perl-script; name="rpki-calc.pl" Content-Transfer-Encoding: 7bit #!/usr/bin/perl -w # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT # LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT # HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT # LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON # ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE # USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. use strict; sub _usage { print("rpki-calc-2.pl [, <...> ] ]> [ ] | -h\n"); } my $iObjCount = shift; my $iRouterObjCount = shift; my $sRepoCount = shift; my $fSecObj = shift; my $sPrint = shift; if (!defined($iObjCount)) { warn("No Object count specified."); _usage(); } elsif ("-h" eq $iObjCount) { _usage(); } elsif (!defined($iRouterObjCount)) { warn("No RouterObj count specified."); _usage(); } elsif (!defined($sRepoCount)) { warn("No Repo count specified."); _usage(); } elsif (!defined($fSecObj)) { warn("No seconds/obj defined"); _usage(); } else { my $sTmpFile = "-"; if (defined($sPrint)) { $sTmpFile = "./tmp-rpki-sizing-" . time() . ".out"; } if (!open(OUT, "> $sTmpFile")) { warn("Unable to open output '$sTmpFile': $!"); } else { my @lRepoCount = split(/,/, $sRepoCount); foreach my $iRepoCount (@lRepoCount) { my $iTmpObjCount = $iObjCount + $iRepoCount; my $iTime = ($iTmpObjCount + $iRepoCount) * $fSecObj; my $fDays = $iTime / 86400; print(OUT "$iRepoCount $iTmpObjCount $iTime $fDays "); $iTmpObjCount += $iRouterObjCount; $iTime = ($iTmpObjCount + $iRepoCount) * $fSecObj; $fDays = $iTime / 86400; print(OUT "$iTmpObjCount $iTime $fDays\n"); } if ("-" ne $sTmpFile) { close(OUT); my $sCmd = " set term pdf fsize 9 linewidth 3.0 set out '$sPrint' set key left top set ylabel 'Days (without Router Certs)' set y2label 'Days (with Router Certs)' set xlabel 'Global Number of Repositories' set grid set y2tics plot '$sTmpFile' u 1:4 title 'Without Router Certs' w lp lw 3,'' u 1:7 title 'With Router Certs' axes x1y2 w lp lw 3 "; system("echo \"$sCmd\" | gnuplot"); unlink($sTmpFile); } } } --Apple-Mail-27--491380325-- From randy@psg.com Tue Dec 18 11: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 02CF821F89ED for ; Tue, 18 Dec 2012 11:48:04 -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 OdjJOkmmzmh4 for ; Tue, 18 Dec 2012 11:48:03 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF8D21F87C8 for ; Tue, 18 Dec 2012 11:48: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 1Tl390-000Bim-81 for sidr@ietf.org; Tue, 18 Dec 2012 19:48:02 +0000 Date: Tue, 18 Dec 2012 14:48:02 -0500 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] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Dec 2012 19:48:04 -0000 I am trying to understand why our fellow engineers at Verisign are obsessed with global propagation of RPKI data on the order of a few minutes. Then a friend hit me with the clue by four. It's about third party DDoS (and other attack) mitigation. When an NTT (just an example) customer is attacked, the customer can request that their upstream sink and scrub the traffic as it naturally passes through NTT. NTT passes the scrubbed traffic on to the customer, and that's that. But, when the customer's upstream does not provide such services, or the customer has other reasons for not using the upstream service, they can buy the scrubbing service from a third party, e.g. Verisign. Verisign will announce the customer's prefix(es) from a Verisign AS, receive the traffic, scrub it clean, and send the cleaned traffic to the customer, often via a tunnel. Well and good, except Verisign is announcing someone else's prefix, a basic violation of BGP origination validation. Naturally, the customer who contracts to Verisign for this service issues a ROA for the prefix(es) to the Verisign AS, and it is not a violation, all is serene. But what if Verisign wants to take on a new customer in panic "Help, I am being attacked and will pay you a lot of money to fix this?" The time for the fix is dependent on how quickly a new ROA for the victim's prefix(es) can propagate. Alternatively, the victim could pull their normal ROA(s) for their prefix(es) and the world would get NotFound and believe Verisign's announcement(s). But this too relies on quick propagation of RPKI data. Observe that this is a problem in origin validation, i.e. what is being deployed today. The RFCs are published, the code is in the routers, ... the horse has left the barn. Yet another item to go into the display case of security vs. utility. Ah well. But I sympathize with Verisign's business case and have no desire to whack it. And I assume others think similarly. There is this little problem. Today, the Internet has no technology for reliable global fast distribution of a database. No, DNS is not the answer. But please have that argument on a different thread. The only thing of which I am aware is Google's Spanner [0], which is a brilliant piece of work. But it is not lightweight (e.g. True Time), is proprietary, is likely considered very secret sauce, and even Google lists it as research as opposed to beta :) IMIHO, this is a *really* interesting area for research, though I suspect sidr is not the place to conduct it. But it's research, not something we can paint on today. So we are left with propagation on the order of a very few hours, AKA 'human time', and our discussions of how to reduce load on CAs so we can query them more frequently. randy --- [0] - http://research.google.com/archive/spanner.html From oliver.borchert@nist.gov Tue Dec 18 12:29: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 3B26921F85DA for ; Tue, 18 Dec 2012 12:29:37 -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 JLu630qJMad8 for ; Tue, 18 Dec 2012 12:29:36 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 477BB21F85D8 for ; Tue, 18 Dec 2012 12:29:35 -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.328.9; Tue, 18 Dec 2012 15:29:31 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 18 Dec 2012 15:29:31 -0500 From: "Borchert, Oliver" To: Randy Bush , sidr wg list Date: Tue, 18 Dec 2012 15:29:29 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3dWJtqxOvI9o2IS+K7PHktYMrSqQABObJQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Dec 2012 20:29:37 -0000 One solution here is that the mitigator either prepends the victims AS (works with "origin only") including the downside that the path is one hop longer. But hey, better than nothing. For origin + path validation the victim creates a bgpsec peering with the mitigator and signs the path. This can be done pretty easily I guess. This might not be the most effective solution but IMHO it works ;-) Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Tuesday, December 18, 2012 2:48 PM To: sidr wg list Subject: [sidr] the need for speed I am trying to understand why our fellow engineers at Verisign are obsessed with global propagation of RPKI data on the order of a few minutes. Then a friend hit me with the clue by four. It's about third party DDoS (and other attack) mitigation. When an NTT (just an example) customer is attacked, the customer can request that their upstream sink and scrub the traffic as it naturally passes through NTT. NTT passes the scrubbed traffic on to the customer, and that's that. But, when the customer's upstream does not provide such services, or the customer has other reasons for not using the upstream service, they can buy the scrubbing service from a third party, e.g. Verisign. Verisign will announce the customer's prefix(es) from a Verisign AS, receive the traffic, scrub it clean, and send the cleaned traffic to the customer, often via a tunnel. Well and good, except Verisign is announcing someone else's prefix, a basic violation of BGP origination validation. Naturally, the customer who contracts to Verisign for this service issues a ROA for the prefix(es) to the Verisign AS, and it is not a violation, all is serene. But what if Verisign wants to take on a new customer in panic "Help, I am being attacked and will pay you a lot of money to fix this?" The time for the fix is dependent on how quickly a new ROA for the victim's prefix(es) can propagate. Alternatively, the victim could pull their normal ROA(s) for their prefix(es) and the world would get NotFound and believe Verisign's announcement(s). But this too relies on quick propagation of RPKI data. Observe that this is a problem in origin validation, i.e. what is being deployed today. The RFCs are published, the code is in the routers, ... the horse has left the barn. Yet another item to go into the display case of security vs. utility. Ah well. But I sympathize with Verisign's business case and have no desire to whack it. And I assume others think similarly. There is this little problem. Today, the Internet has no technology for reliable global fast distribution of a database. No, DNS is not the answer. But please have that argument on a different thread. The only thing of which I am aware is Google's Spanner [0], which is a brilliant piece of work. But it is not lightweight (e.g. True Time), is proprietary, is likely considered very secret sauce, and even Google lists it as research as opposed to beta :) IMIHO, this is a *really* interesting area for research, though I suspect sidr is not the place to conduct it. But it's research, not something we can paint on today. So we are left with propagation on the order of a very few hours, AKA 'human time', and our discussions of how to reduce load on CAs so we can query them more frequently. randy --- [0] - http://research.google.com/archive/spanner.html _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From dy243@hermes.cam.ac.uk Tue Dec 18 13:24: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 D299821E8045 for ; Tue, 18 Dec 2012 13:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0Owd2NtOG4ou for ; Tue, 18 Dec 2012 13:24:34 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 518BE21E803C for ; Tue, 18 Dec 2012 13:24:34 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from mail-oa0-f41.google.com ([209.85.219.41]:64580) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:465) with esmtpsa (PLAIN:dy243) (TLSv1:RC4-SHA:128) id 1Tl4eP-0006CM-Wp (Exim 4.72) for sidr@ietf.org (return-path ); Tue, 18 Dec 2012 21:24:33 +0000 Received: by mail-oa0-f41.google.com with SMTP id k14so1255807oag.14 for ; Tue, 18 Dec 2012 13:24:29 -0800 (PST) Received: by 10.60.171.201 with SMTP id aw9mr2879240oec.126.1355865869071; Tue, 18 Dec 2012 13:24:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.125.100 with HTTP; Tue, 18 Dec 2012 13:24:09 -0800 (PST) In-Reply-To: References: From: Dongting Yu Date: Tue, 18 Dec 2012 13:24:09 -0800 Message-ID: To: Randy Bush Content-Type: text/plain; charset=UTF-8 Sender: Dongting Yu Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Dec 2012 21:24:35 -0000 [apologies if I am sending this multiple times, having trouble with replying] A concept that could be borrowed from DNS side is the ability for anyone to go from the top and skip the cache(s) on an ad hoc basis. Perhaps we need a similar capability here, for anyone to query from the top. This way, a new announcement can (for example) carry a flag that says "this may look invalid but if you skip the cache you will see that it is", and suggests the receiving party to validate it from the top. Of course, two things will soon follow: some will always ask others to skip the cache, which would defeat the purpose of caching (but I would argue that it is not hard to figure out who are wasting others' bandwidth and cpu, by comparing the non-cached versions as requested and the cached versions), and this mechanism itself can be used to launch a DDoS (to which I would argue the RIRs already has enough resources to handle it, or some tricks can be perhaps applied to make this problem less significant in the first place). Dongting From christopher.morrow@gmail.com Tue Dec 18 13:52: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 9406321F88CE for ; Tue, 18 Dec 2012 13:52:16 -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 Ecmx8jj1HJSH for ; Tue, 18 Dec 2012 13:52:15 -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 91D4421F88B7 for ; Tue, 18 Dec 2012 13:52:15 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so664731eek.31 for ; Tue, 18 Dec 2012 13:52: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=rWCZf9zYZ4fALKXZ2CuptSR+9iZe+LG4LGfCVGs9SrI=; b=jmnHX4cA3/nFONhLJ6f6DUG5gKMH1gEsdAxJUnmd91aRkvmBSX3yiSyJmwjmyFckZA FROto/e98+plhcoLkT2AAkNxD79l8g0c5YVg466h33waNdm44+/SRKmEcpTLEhcY8FGC TzF4J7P4g37SsevyPTuJmnXeCSuL0c5RB9ho9nEgoIPy5B6Z9tB57eD5680Tq0AGEGzL 4oBaXjnQXX0qG0gfPl51NQCH6oeIbAYUA5Ss6h21+82sSWtaE2jBe411/tb5sfeEQQHp kYRV5fbcO7T2ZjoX+VrcK53nxKFj/RUfnjobVbyRpKmH1o3NFJQ/BBAIByfThK4Bz89p c+OQ== MIME-Version: 1.0 Received: by 10.14.214.132 with SMTP id c4mr9100813eep.18.1355867534600; Tue, 18 Dec 2012 13:52:14 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Tue, 18 Dec 2012 13:52:14 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Dec 2012 16:52:14 -0500 X-Google-Sender-Auth: GJlhaGiCtAx_AnAr7e-1CNj5OIc Message-ID: From: Christopher Morrow To: Dongting Yu Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Dec 2012 21:52:16 -0000 On Tue, Dec 18, 2012 at 4:24 PM, Dongting Yu wrote: > [apologies if I am sending this multiple times, having trouble with replying] > > A concept that could be borrowed from DNS side is the ability for > anyone to go from the top and skip the cache(s) on an ad hoc basis. stop... no. The architecture as laid out is, from 'roa creator' to 'roa consumer', roughly: A publication point (nominally one per roa-creator) B gatherers (nominally one per roa-consumer) C internal-cache-systems (some number per roa-consumer) D routers (yes, there is the iana->rir part of the tree yes, there are are more than just ROAs in the repositories) So, the part that Randy and Danny and Eric are talking about is, as far as the global system, is the A -> B conversation. Once you get beyond B (to C and D) the problem is entirely inside some operator's network and nothing on the outside matters. Essentially the problem here is distribution of 10k of data to ~40k endpoints (today, it'll grow tomorrow, fine) in ~2 mins time (or 5 mins or 10 mins or ... someone draw a line in the sand so we know what the target is) > Perhaps we need a similar capability here, for anyone to query from > the top. This way, a new announcement can (for example) carry a flag > that says "this may look invalid but if you skip the cache you will > see that it is", and suggests the receiving party to validate it from > the top. at the router? no, don't do that. > > Of course, two things will soon follow: some will always ask others to > skip the cache, which would defeat the purpose of caching (but I would once you have QOS, everything is EF! > argue that it is not hard to figure out who are wasting others' > bandwidth and cpu, by comparing the non-cached versions as requested > and the cached versions), and this mechanism itself can be used to > launch a DDoS (to which I would argue the RIRs already has enough > resources to handle it, or some tricks can be perhaps applied to make do they? > this problem less significant in the first place). > > Dongting > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Tue Dec 18 14:03: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 4F7AA21E803C for ; Tue, 18 Dec 2012 14:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 E+KiNy38O0-e for ; Tue, 18 Dec 2012 14:03:01 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B9E1D21E8039 for ; Tue, 18 Dec 2012 14:03:01 -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.328.9; Tue, 18 Dec 2012 17:02:57 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 18 Dec 2012 17:03:01 -0500 From: "Sriram, Kotikalapudi" To: "Borchert, Oliver" , Randy Bush , sidr wg list Date: Tue, 18 Dec 2012 17:03:00 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3dWJtqxOvI9o2IS+K7PHktYMrSqQABObJQAAMO+Yw= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Dec 2012 22:03:02 -0000 Adding to Oliver's suggestion, it will be even more effective if, in the "o= rigin only" case,=20 the mitigator announces a slightly more specific (e.g., two /17s for a /16= )=20 if the maxlength of the victim's existing ROA permits it (of course, victim= =92s AS is inserted=20 as the origin AS as suggested).=20 More specific wins, so the downside of one hop longer path length goes away= . =20 And in the full path validation case, the victim forward signs a more speci= fic=20 (if permissible by existing ROA) to the mitigator. The victim also sets pCo= unt =3D 0 for this update. Sriram > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Borchert= , Oliver [oliver.borchert@nist.gov] > One solution here is that the mitigator either prepends the victims AS (w= orks with "origin only") including the downside that the path is one hop lo= nger. But hey, better than nothing. For origin + path validation the victim= creates a bgpsec peering with the mitigator and signs the path. This can b= e done pretty easily I guess. From danny@tcb.net Tue Dec 18 14:09: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 CF9F221F8578 for ; Tue, 18 Dec 2012 14:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.289 X-Spam-Level: X-Spam-Status: No, score=-100.289 tagged_above=-999 required=5 tests=[AWL=0.148, 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 jetDtogfOt2d for ; Tue, 18 Dec 2012 14:09:46 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id E486F21F84FD for ; Tue, 18 Dec 2012 14:09:45 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 651FB300034 for ; Tue, 18 Dec 2012 22:09:41 +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 013C1300021 for ; Tue, 18 Dec 2012 15:09:40 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Tue, 18 Dec 2012 17:09:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Dec 18 15:09: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: 50d0e9a5199631178020335 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, from+a, 0.01000, from+a, 0.01000, all+#+#+to, 0.01000, Subject*sidr+#+#+for, 0.01000, have+no, 0.01000, have+no, 0.01000, how+to, 0.01000, to+#+#+in, 0.01000, lot+of, 0.01000, that+operators, 0.01000, 2012+#+2, 0.01000, to+#+to, 0.01000, to+#+to, 0.01000, to+#+#+#+is, 0.01000, through+the, 0.01000, and+network, 0.01000, all+the, 0.01000, all+the, 0.01000, RPKI+and, 0.01000, to+#+this, 0.01000, about+this, 0.01000, with+#+#+of, 0.01000, with+#+#+of, 0.01000, wrote+I, 0.01000, a+#+#+#+that, 0.01000, the+#+with, 0.01000 Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Dec 2012 22:09:47 -0000 On Dec 18, 2012, at 2:48 PM, Randy Bush wrote: > I am trying to understand why our fellow engineers at Verisign are > obsessed with global propagation of RPKI data on the order of a few > minutes. Then a friend hit me with the clue by four. It's about = third > party DDoS (and other attack) mitigation. It's not just about this, that's certainly AN example. Operators can = envision lots of reasons why it'd be a good idea for the routing system = to converge rapidly. How many do you need? > When an NTT (just an example) customer is attacked, the customer can > request that their upstream sink and scrub the traffic as it naturally > passes through NTT. NTT passes the scrubbed traffic on to the = customer, > and that's that. >=20 > But, when the customer's upstream does not provide such services, or = the > customer has other reasons for not using the upstream service, they = can > buy the scrubbing service from a third party, e.g. Verisign. Verisign > will announce the customer's prefix(es) from a Verisign AS, receive = the > traffic, scrub it clean, and send the cleaned traffic to the customer, > often via a tunnel. Thanks for the explanation, I'm glad you took the time to _listen to = operators about some of the ways of doing this. > Well and good, except Verisign is announcing someone else's prefix, a > basic violation of BGP origination validation. =20 Actually, it's not a violation of anything - it's their intent - which = is what this all boils down to. It's only a violation if your system = doesn't model intent and assumes it knows something is a violation... = It's the same policy that's reflected in your ROA, I'm just not captive = to that today. It's also by default how routing works today, as you well know... > Naturally, the customer > who contracts to Verisign for this service issues a ROA for the > prefix(es) to the Verisign AS, and it is not a violation, all is = serene. >=20 > But what if Verisign wants to take on a new customer in panic "Help, I > am being attacked and will pay you a lot of money to fix this?" The > time for the fix is dependent on how quickly a new ROA for the = victim's > prefix(es) can propagate. Actually, it's not. We don't know or care about ROAs today on the = Internet. > Alternatively, the victim could pull their normal ROA(s) for their > prefix(es) and the world would get NotFound and believe Verisign's > announcement(s). But this too relies on quick propagation of RPKI = data. And opens the floodgates for downgrade attacks in this very heavy system = you've been envisioning for over a decade, downgrade attacks that all = the folks building these systems don't really seem to care about. "Just fail open, you're no worse off than you are today" -- except that = I have a bunch of new dependencies with 10x spend on routers and network = engineers to debug RPKI and BGPSEC in order to route things - all for = not. =20 Tell a bank that - you've upgraded you security system and it costs 10x, = but if there's a problem, just fail open, folks can still get money. > Observe that this is a problem in origin validation, i.e. what is = being > deployed today. The RFCs are published, the code is in the routers, = ... > the horse has left the barn. Hah, nice.. Glad you're considering the requirements now that your = gerbil has left the barn! > Yet another item to go into the display case of security vs. utility. Right, you've designed something that doesn't even fix leaks - which = many operators believe are an operational security problem and they = happen by default (e.g., the last big routing security snafu we've seen, = and go read GROW if you disagree), slows routing convergence on the = Internet to hours or days at the least (from double digit seconds = today), introduces lots of new external system dependencies (e.g., RIRs, = whom YOU say have no operational clue), removes all the scaling = properties of BGP over the past 2 decades (adds periodic updates, breaks = packing, order magnitude larger updates, etc..), and you say if there's = problems, just fail open (i.e., downgrade attacks). You just admitted = that operators can't change keys on two ends of a transport connection, = and in the next breath you tell me how an Internet-scale system that = requires global coherency for verification objects for every prefix in = the entire system across every BGP router and RPKI is going to work, all = on the backbone of rsync? > Ah well. But I sympathize with Verisign's business case and have no > desire to whack it. And I assume others think similarly. How kind of you... > There is this little problem. Today, the Internet has no technology = for > reliable global fast distribution of a database. No, DNS is not the > answer. But please have that argument on a different thread. The = only > thing of which I am aware is Google's Spanner [0], which is a = brilliant > piece of work. But it is not lightweight (e.g. True Time), is > proprietary, is likely considered very secret sauce, and even Google > lists it as research as opposed to beta :) Right, so we should bolt PKI into your heap of rsync cruft onto the = routing system to solve what problem? Yet another item to go into the = "and Randy Bush came down from the mountain, with two tablets in hand, = to graciously bestow again upon all the operational monkeys clue from a = superior galaxy far away, under the auspices of operator but funded by = the USG, with a new system aimed to control what's routed on the = Internet, how operators route and configure their networks and what = external entities they're captive to - who cares if it's routed = securely!, he proclaimed, I WILL EMPLOY RSYNC AND BOLT PKI ON BGP, it = will be my legacy, youngsters, I WON, so take your requirements to the = university, this is the iRBtf!" The Internet was sad. > IMIHO, this is a *really* interesting area for research, though I > suspect sidr is not the place to conduct it. But it's research, not > something we can paint on today. So we are left with propagation on = the > order of a very few hours, AKA 'human time', and our discussions of = how > to reduce load on CAs so we can query them more frequently. Requirements require research, indeed... It would have been good if we = started here, rather than with SBGP-renamed and slamming RPKI directly = into routers, it's just plain silly. You should visit the work in GROW = on why IRRs are challenged, or why leaks ARE operational AND security = problems. I think if you built general purpose Internet number resource = certification and considered why things like the IRRs have had = challenges, and why there should be autonomy in today's Internet = operations, you'd be a lot better off... Instead, you built routed = resource certification through an RPKI introducing new control points = and made RIPv1 scale look like a panacea compared to RPKI-enabled = BGPSEC, and muddied it all with the likes of random subjects, and then = fixed with ghostbusters records, and grandparenting for more control = points, and snail-paced convergence where relying parties have to = discover everything new in a global system with potentially tens of = thousands of publication points, and and increased attack surfaces and = inter-domain churn orders or magnitude - and you couldn't even fix = leaks, which happen by default, and which you're still going to need to = fix with IRRs... Randy, you've done a fine job socially engineering this work through the = IETF, I'll give you that! -danny EVIL_OPERATOR: Just waiting for a call from one of the RIRs to engage us = in mitigating DDoS attacks to their repositories; or for the opportunity = to operationalize an overly complex system that folks are captive to - = wohoo! From rossjanderson@googlemail.com Tue Dec 18 14:10: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 DB27F21E8051 for ; Tue, 18 Dec 2012 14:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 RTdCU2SWs251 for ; Tue, 18 Dec 2012 14:10:29 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4303721E8045 for ; Tue, 18 Dec 2012 14:10:29 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c12so1710427ieb.37 for ; Tue, 18 Dec 2012 14:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I3SR/kBSwqXLFMng2cUGRqSNgJ6sx5EAtHhTVG3dmgU=; b=qTMzi0VVRIm2Q4sdf1E/vJa96pQfmMZWXFGKV09De24OulBaQFIg/GuHpH09a8NNkv Yl6qx0GQ84cf3Ozwxae+dKSolkMABbvGuh/BQpPR0yM59nbQXJIMTzhZXYPRmKQkBFlp waGIrfcKh25hv8kpL3QWtkwH00dGGs/cg2nz0MYYWtCMZMJoQHRs4AjDu/olvDTTESb1 8ou2Td4rGicKvKitDp9Sg+vT+EgTfD+6H3uKUFy9KUDOxMqUNL1VBdAowdIqY4f7PrWn A66zUqJ7tF0t4Ar4cByp8q2bjwSk1i/Rg5owzV7Nt8UOMK+wTTVlwZEuio7/+f2tZ2Gb ctOg== MIME-Version: 1.0 Received: by 10.50.1.200 with SMTP id 8mr64605igo.76.1355868628742; Tue, 18 Dec 2012 14:10:28 -0800 (PST) Sender: rossjanderson@googlemail.com Received: by 10.50.57.98 with HTTP; Tue, 18 Dec 2012 14:10:28 -0800 (PST) In-Reply-To: References: Date: Tue, 18 Dec 2012 22:10:28 +0000 X-Google-Sender-Auth: 9VbyPWGlntOkPy1fXrEDyYwJu5c Message-ID: From: Ross Anderson To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ross.Anderson@cl.cam.ac.uk List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 22:10:30 -0000 So to mitigate an attack you conduct another one ... Ross On 18/12/2012, Sriram, Kotikalapudi wrote: > Adding to Oliver's suggestion, it will be even more effective if, in the > "origin only" case, > the mitigator announces a slightly more specific (e.g., two /17s for a /= 16) > > if the maxlength of the victim's existing ROA permits it (of course, > victim=92s AS is inserted > as the origin AS as suggested). > More specific wins, so the downside of one hop longer path length goes aw= ay. > > > And in the full path validation case, the victim forward signs a more > specific > (if permissible by existing ROA) to the mitigator. The victim also sets > pCount =3D 0 for this update. > > Sriram > >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Borcher= t, >> Oliver [oliver.borchert@nist.gov] >> One solution here is that the mitigator either prepends the victims AS >> (works with "origin only") including the downside that the path is one h= op >> longer. But hey, better than nothing. For origin + path validation the >> victim creates a bgpsec peering with the mitigator and signs the path. >> This can be done pretty easily I guess. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From danny@tcb.net Tue Dec 18 14:18: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 EECE621F8602 for ; Tue, 18 Dec 2012 14:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[AWL=0.138, 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 kpylsqhEKXUz for ; Tue, 18 Dec 2012 14:18:17 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6122F21F8578 for ; Tue, 18 Dec 2012 14:18:17 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 1F3BD300034 for ; Tue, 18 Dec 2012 22:18: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 DAC8E300021 for ; Tue, 18 Dec 2012 15:18:16 -0700 (MST) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Dec 2012 17:18:15 -0500 References: <20121218212120.10416.36465.idtracker@ietfa.amsl.com> To: sidr wg list Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Dec 18 15:18: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: 50d0eba9199635248513161 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, Mime-Version*Message+#+v1283, 0.01000, To*wg+#+sidr, 0.01000, mailing+list, 0.01000, To*list+#+ietf.org, 0.01000, and+#+in, 0.01000, routing+system, 0.01000, for+this, 0.01000, purpose+of, 0.01000, Mime-Version*Apple+#+framework, 0.01000, is+#+#+the, 0.01000, which+are, 0.01000, are+#+#+in, 0.01000, Shane+Amante, 0.01000, of+this, 0.01000, Mime-Version*1.0+Apple, 0.01000, and+#+#+the, 0.01000, To*wg+#+#+ietf.org, 0.01000, and+#+#+#+this, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Url*org/html/draft, 0.01000, To*sidr+ietf.org, 0.01000, a+#+#+#+of, 0.01000, the+#+of, 0.01000, in+the, 0.01000, this+#+is, 0.01000, this+#+is, 0.01000 Subject: [sidr] Fwd: I-D Action: draft-grow-irr-routing-policy-considerations-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: Tue, 18 Dec 2012 22:18:18 -0000 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: = draft-grow-irr-routing-policy-considerations-00.txt > Date: December 18, 2012 4:21:20 PM EST > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : IRR & Routing Policy Configuration = Considerations > Author(s) : Danny McPherson > Shane Amante > Eric Osterweil > Larry J. Blunk > Filename : = draft-grow-irr-routing-policy-considerations-00.txt > Pages : 15 > Date : 2012-12-18 >=20 > Abstract: > The purpose of this document is to catalog past issues influencing > the efficacy of Internet Routing Registries (IRR) for inter-domain > routing policy specification and application in the global routing > system over the past two decades. Additionally, it provides a > discussion regarding which of these issues are still problematic in > practice, and which are simply artifacts that are no longer > applicable but continue to stifle inter-provider policy-based > filtering adoption and IRR utility to this day. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-grow-irr-routing-policy-considerati= ons >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-grow-irr-routing-policy-considerations-00= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From danny@tcb.net Tue Dec 18 14:18: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 7ACDC21E805D for ; Tue, 18 Dec 2012 14:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.308 X-Spam-Level: X-Spam-Status: No, score=-100.308 tagged_above=-999 required=5 tests=[AWL=0.129, 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 44TNpH0Jpj-4 for ; Tue, 18 Dec 2012 14:18:20 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id C45D021E805A for ; Tue, 18 Dec 2012 14:18:20 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 82C84300034 for ; Tue, 18 Dec 2012 22:18:20 +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 4A6DB300021 for ; Tue, 18 Dec 2012 15:18:20 -0700 (MST) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Dec 2012 17:18:20 -0500 References: <20121218212251.10414.51820.idtracker@ietfa.amsl.com> To: sidr wg list Message-Id: Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Dec 18 15:18:20 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50d0ebac199631385499363 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, Url*leak, 0.01000, Internet+#+#+or, 0.01000, Mime-Version*Message+#+v1283, 0.01000, order+to, 0.01000, Url*help, 0.01000, To*wg+#+sidr, 0.01000, mailing+list, 0.01000, in+order, 0.01000, This+#+#+#+very, 0.01000, To*list+#+ietf.org, 0.01000, as+#+to, 0.01000, routing+security, 0.01000, is+#+to, 0.01000, It+is, 0.01000, for+this, 0.01000, This+#+#+a, 0.01000, Mime-Version*Apple+#+framework, 0.01000, to+#+a, 0.01000, is+#+#+the, 0.01000, to+the, 0.01000, Shane+Amante, 0.01000, RPKI+#+BGPSEC, 0.01000, Mime-Version*1.0+Apple, 0.01000, To*wg+#+#+ietf.org, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Url*org/html/draft, 0.01000 Subject: [sidr] Fwd: I-D Action: draft-grow-simple-leak-attack-bgpsec-no-help-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: Tue, 18 Dec 2012 22:18:21 -0000 Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: = draft-grow-simple-leak-attack-bgpsec-no-help-00.txt > Date: December 18, 2012 4:22:51 PM EST > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Route Leaks & MITM Attacks Against BGPSEC > Author(s) : Danny McPherson > Shane Amante > Eric Osterweil > Filename : = draft-grow-simple-leak-attack-bgpsec-no-help-00.txt > Pages : 7 > Date : 2012-12-18 >=20 > Abstract: > This document describes a very simple attack vector that illustrates > how RPKI-enabled BGPSEC machinery as currently defined can be easily > circumvented in order to launch a Man In The Middle (MITM) attack = via > BGP. It is meant to serve as input to the IETF's Secure = Inter-Domain > Routing working group during routing security requirements > discussions and subsequent specification. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-grow-simple-leak-attack-bgpsec-no-h= elp >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-grow-simple-leak-attack-bgpsec-no-help-00= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From kotikalapudi.sriram@nist.gov Tue Dec 18 15: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 A9CD621F8732 for ; Tue, 18 Dec 2012 15:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 MEMNbGULfAJT for ; Tue, 18 Dec 2012 15:24:16 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DC05E21F8711 for ; Tue, 18 Dec 2012 15:24:15 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 18 Dec 2012 18:24:08 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 18 Dec 2012 18:24:11 -0500 From: "Sriram, Kotikalapudi" To: "Ross.Anderson@cl.cam.ac.uk" Date: Tue, 18 Dec 2012 18:24:10 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3dbIAmkFF41JiJQk68b7cBw8ot0gAAVRWL Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Dec 2012 23:24:16 -0000 Since the intent is good, it is not an =93attack=94 (at least as far as the= mitigator and the victim are concerned).=20 In BGPSEC (i.e. the path validation case), the proposed solution (below) is= clearly not even an apparent attack.=20 The victim (customer) is intentionally propagating a signed update to a ser= vice provider (the mitigator).=20 The DDoS mitigation works (continues to work like it does today) without ha= ving to create/propagate new RPKI objects. =20 Sriram ________________________________________ From: rossjanderson@googlemail.com [rossjanderson@googlemail.com] On Behalf= Of Ross Anderson [Ross.Anderson@cl.cam.ac.uk] Sent: Tuesday, December 18, 2012 5:10 PM To: Sriram, Kotikalapudi Cc: Borchert, Oliver; Randy Bush; sidr wg list Subject: Re: [sidr] the need for speed So to mitigate an attack you conduct another one ... Ross On 18/12/2012, Sriram, Kotikalapudi wrote: > Adding to Oliver's suggestion, it will be even more effective if, in the > "origin only" case, > the mitigator announces a slightly more specific (e.g., two /17s for a /= 16) > > if the maxlength of the victim's existing ROA permits it (of course, > victim=92s AS is inserted > as the origin AS as suggested). > More specific wins, so the downside of one hop longer path length goes aw= ay. > > > And in the full path validation case, the victim forward signs a more > specific > (if permissible by existing ROA) to the mitigator. The victim also sets > pCount =3D 0 for this update. > > Sriram > >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Borcher= t, >> Oliver [oliver.borchert@nist.gov] >> One solution here is that the mitigator either prepends the victims AS >> (works with "origin only") including the downside that the path is one h= op >> longer. But hey, better than nothing. For origin + path validation the >> victim creates a bgpsec peering with the mitigator and signs the path. >> This can be done pretty easily I guess. > From russw@riw.us Tue Dec 18 16:10: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 80FC221E805F for ; Tue, 18 Dec 2012 16:10: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=[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 RIc5XxJQfIqv for ; Tue, 18 Dec 2012 16:10:33 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0421E8045 for ; Tue, 18 Dec 2012 16:10:33 -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 1Tl7F2-0002w2-Id for sidr@ietf.org; Tue, 18 Dec 2012 16:10:32 -0800 Message-ID: <50D105F9.5020101@riw.us> Date: Tue, 18 Dec 2012 19:10:33 -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: 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 speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 00:10:33 -0000 > I am trying to understand why our fellow engineers at Verisign are > obsessed with global propagation of RPKI data on the order of a few > minutes. Then a friend hit me with the clue by four. It's about third > party DDoS (and other attack) mitigation. In other words, when you can't provide a technical argument, it's easiest just to jump to the ad hominem attacks... > Observe that this is a problem in origin validation, i.e. what is being > deployed today. The RFCs are published, the code is in the routers, ... > the horse has left the barn. The horse that leaves the barn too soon will quickly find itself on cobblestones. Let me turn this around for you. That you think security should not mirror the table at the speed of the table tells me that you're not really interested in what should happen --which needs to lead what actually happens to be a useful piece of information-- but in what has happened. So, should we imply from this what your business case is, where you intend to make money off of this work, and attack you for that implication? Or what the RIR's business case is, and where they make their money? Or should we stick to technical problems and realistic solutions? Most effective security, as I said above, tells me about intent --which means that notification of changes in intent must run as fast as intent changes. In routing, intent changes as fast as the table changes, not much slower. It's not so much that humans move quickly, it's that there are so many of them moving at one time that is the bothersome piece of this problem --and the piece that the current design doesn't even attempt to take into consideration. Russ -- <>< riwhite@verisign.com russw@riw.us From eosterweil@verisign.com Tue Dec 18 16:15: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 C068521F8621 for ; Tue, 18 Dec 2012 16:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.855 X-Spam-Level: X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=0.744, 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 iWDae8fLcrou for ; Tue, 18 Dec 2012 16:15:32 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6A23D21F861A for ; Tue, 18 Dec 2012 16:15:27 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUNEHHpWURTVJZOTTD/CG1nimEW3keNHb@postini.com; Tue, 18 Dec 2012 16:15:32 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 qBJ0FLqv023551; Tue, 18 Dec 2012 19:15:23 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Dec 2012 19:15:21 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Eric Osterweil In-Reply-To: Date: Tue, 18 Dec 2012 19:15:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 19 Dec 2012 00:15:21.0868 (UTC) FILETIME=[EF4724C0:01CDDD7D] Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 00:15:32 -0000 On Dec 18, 2012, at 6:24 PM, Sriram, Kotikalapudi wrote: > Since the intent is good, it is not an =93attack=94 (at least as far = as the mitigator and the victim are concerned).=20 > In BGPSEC (i.e. the path validation case), the proposed solution = (below) is clearly not even an apparent attack.=20 > The victim (customer) is intentionally propagating a signed update to = a service provider (the mitigator).=20 > The DDoS mitigation works (continues to work like it does today) = without having to create/propagate new RPKI objects. So.... how, exactly, do we know it is not an attack? Is the ``intent = bit'' set on all the updates? Eric= From randy@psg.com Tue Dec 18 16:40: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 4CE1121E803A for ; Tue, 18 Dec 2012 16:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 dZJFCcWvCuiA for ; Tue, 18 Dec 2012 16:40:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C7D4921F860A for ; Tue, 18 Dec 2012 16:40:37 -0800 (PST) Received: from [166.205.48.18] (helo=[10.20.97.171]) by psg.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tl7i8-000BiM-Hi; Wed, 19 Dec 2012 00:40:36 +0000 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <6ACBD16B-F33E-42CD-A99C-BBF030C4C881@psg.com> X-Mailer: iPhone Mail (10A525) From: Randy Bush Date: Tue, 18 Dec 2012 19:40:34 -0500 To: "Sriram, Kotikalapudi" Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 00:40:41 -0000 Forget a out kink with longer prefixes etc. victim withdraws.=20 randy, on a stinkin' iPoop On Dec 18, 2012, at 6:24 PM, "Sriram, Kotikalapudi" wrote: > Since the intent is good, it is not an =E2=80=9Cattack=E2=80=9D (at least a= s far as the mitigator and the victim are concerned).=20 > In BGPSEC (i.e. the path validation case), the proposed solution (below) i= s clearly not even an apparent attack.=20 > The victim (customer) is intentionally propagating a signed update to a se= rvice provider (the mitigator).=20 > The DDoS mitigation works (continues to work like it does today) without h= aving to create/propagate new RPKI objects. >=20 > Sriram > ________________________________________ > From: rossjanderson@googlemail.com [rossjanderson@googlemail.com] On Behal= f Of Ross Anderson [Ross.Anderson@cl.cam.ac.uk] > Sent: Tuesday, December 18, 2012 5:10 PM > To: Sriram, Kotikalapudi > Cc: Borchert, Oliver; Randy Bush; sidr wg list > Subject: Re: [sidr] the need for speed >=20 > So to mitigate an attack you conduct another one ... >=20 > Ross >=20 >=20 > On 18/12/2012, Sriram, Kotikalapudi wrote: >> Adding to Oliver's suggestion, it will be even more effective if, in the >> "origin only" case, >> the mitigator announces a slightly more specific (e.g., two /17s for a /= 16) >>=20 >> if the maxlength of the victim's existing ROA permits it (of course, >> victim=E2=80=99s AS is inserted >> as the origin AS as suggested). >> More specific wins, so the downside of one hop longer path length goes aw= ay. >>=20 >>=20 >> And in the full path validation case, the victim forward signs a more >> specific >> (if permissible by existing ROA) to the mitigator. The victim also sets >> pCount =3D 0 for this update. >>=20 >> Sriram >>=20 >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Borcher= t, >>> Oliver [oliver.borchert@nist.gov] >>> One solution here is that the mitigator either prepends the victims AS >>> (works with "origin only") including the downside that the path is one h= op >>> longer. But hey, better than nothing. For origin + path validation the >>> victim creates a bgpsec peering with the mitigator and signs the path. >>> This can be done pretty easily I guess. >=20 From kotikalapudi.sriram@nist.gov Tue Dec 18 16:45: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 398CA21F86D4 for ; Tue, 18 Dec 2012 16:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 EZwE2s8OwD7D for ; Tue, 18 Dec 2012 16:45:05 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD3821F86CD for ; Tue, 18 Dec 2012 16:45:05 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 18 Dec 2012 19:45:00 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 18 Dec 2012 19:45:04 -0500 From: "Sriram, Kotikalapudi" To: Eric Osterweil Date: Tue, 18 Dec 2012 19:45:03 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3dffXa/psn6OO4S/yOl5R02+XVoAAAgMgy Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 00:45:06 -0000 Update is signed from the victim (customer) to the mitigator. If somone other than the customer signs that customer's prefix to the mitig= ator (or to anyone else for that matter), then that update will fail validatatio= n. There is no need for an intent bit. I hope I understood your question correctly. Sriram ________________________________________ From: Eric Osterweil [eosterweil@verisign.com] Sent: Tuesday, December 18, 2012 7:15 PM To: Sriram, Kotikalapudi Cc: Ross.Anderson@cl.cam.ac.uk; sidr wg list Subject: Re: [sidr] the need for speed On Dec 18, 2012, at 6:24 PM, Sriram, Kotikalapudi wrote: > Since the intent is good, it is not an =93attack=94 (at least as far as t= he mitigator and the victim are concerned). > In BGPSEC (i.e. the path validation case), the proposed solution (below) = is clearly not even an apparent attack. > The victim (customer) is intentionally propagating a signed update to a s= ervice provider (the mitigator). > The DDoS mitigation works (continues to work like it does today) without = having to create/propagate new RPKI objects. So.... how, exactly, do we know it is not an attack? Is the ``intent bit''= set on all the updates? Eric From danny@tcb.net Tue Dec 18 18:34: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 5F9B221E8045 for ; Tue, 18 Dec 2012 18:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.262 X-Spam-Level: X-Spam-Status: No, score=-100.262 tagged_above=-999 required=5 tests=[AWL=0.175, 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 5aLBZnnOgEss for ; Tue, 18 Dec 2012 18:34:05 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9F89A21E8034 for ; Tue, 18 Dec 2012 18:34:05 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 3D53B30000D for ; Wed, 19 Dec 2012 02:34:05 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-71-171-117-166.clppva.fios.verizon.net [71.171.117.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id DFE6E30000C for ; Tue, 18 Dec 2012 19:34:04 -0700 (MST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: Danny McPherson In-Reply-To: Date: Tue, 18 Dec 2012 21:34:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: , To: sidr wg list X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Dec 18 19:34:05 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50d1279d199636668818697 X-DSPAM-Factors: 27, To*sidr+wg, 0.01000, Subject*sidr+#+#+for, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, to+#+#+in, 0.01000, of+#+problem, 0.01000, the+leak, 0.01000, is+that, 0.01000, to+#+this, 0.01000, the+#+here, 0.01000, with+#+#+of, 0.01000, a+#+#+#+that, 0.01000, the+full, 0.01000, 18+2012, 0.01000, the+#+with, 0.01000, Mime-Version*Message+#+v1283, 0.01000, the+#+#+#+to, 0.01000, and+#+#+#+to, 0.01000, the+route, 0.01000, 5+#+PM, 0.01000, To*wg+#+sidr, 0.01000, as+well, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, are+#+#+#+the, 0.01000, to+#+in, 0.01000 Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 02:34:06 -0000 On Dec 18, 2012, at 5:03 PM, Sriram, Kotikalapudi wrote: > Adding to Oliver's suggestion, it will be even more effective if, in = the "origin only" case,=20 > the mitigator announces a slightly more specific (e.g., two /17s for = a /16)=20 > if the maxlength of the victim's existing ROA permits it (of course, = victim=92s AS is inserted=20 > as the origin AS as suggested).=20 While I appreciate your consideration, this won't work. There are lots = of practical reasons why, e.g., diverting a /17 worth of traffic through = a DDoS mitigation service is a bad idea when only a subset (e.g., a /32 = or /24) is under attack. Being as surgical as possible is important, = for lots of operational and financial reasons.=20 FWIW, I can do "origin validation" with access/filter lists and IRRs = today, I don't need other parties to control how my prefixes are routed = everywhere on the Internet, like folks appear to be aiming to "help me = with" here. And Randy, longer prefixes from "mitigator" with victim withdrawing = (i.e., what I think you were trying to convey with "Forget a out kink = with longer prefixes etc. victim withdraws.") would leave you with no = place to deliver the legitimate "scrubbed" traffic, and that might well = be a problem, unless you were intending to effectively complete the = attack. > More specific wins, so the downside of one hop longer path length goes = away.=20 More specifics override longer prefixes? Spoofed origins circumvent = "origin validation"? Meh. We knew this already, and I suspect we're = not the only ones... =20 > And in the full path validation case, the victim forward signs a more = specific=20 > (if permissible by existing ROA) to the mitigator. The victim also = sets pCount =3D 0 for this update. Assuming they're capable of "forward signing" and distributing an update = to the "mitigator"'s BGP speakers -- something I definitely wouldn't = count on with the scale and virulence of attacks today. YMMV... That said, in an RPKI-enabled BGPSEC world I suppose the mitigator could = "leak" the route with some degree of impact, as you point out. As could = attackers, of course, thereby allowing the leak itself to trigger the = DoS on the target, but we've been there as well already. Additionally, as Chris keeps pointing out, it'd be trivial these days = for an attacker to drop 10 or 20 or 100G of packet love on an RIR and = just break the targets routing via RPKI DDoS - that's an attack vector I = don't have to worry about today (beyond the SIDR work). Or with a = fully functional RPKI-enabled BGPSEC simply "leak" their route and = blackhole the traffic, molest selectively, or "other"), but again, we = know this... I guess the point here is that I really don't need you to solve this = problem for me Sriram, I just don't want you to add a bunch of baggage = that introduces more vulnerabilities and fragility, breaks my agility, = and yet solves very little of any problem I actually care about as an = operator. BTW: Is there's some actual bound on the number of use cases (i.e., = actual operational engineering objectives and techniques employed today) = such as this where changes to "policy" in the RPKI may need to occur and = be propagated to all RPs in less than hrmm... many hours[?]. Perhaps = we should hit up the NOG lists and ask folks about their requirements = for making changes, or learn from systems impacted from just this in the = past (e.g., IRRs). Of course, I suspect it's largely futile given Randy's comments about = horses and barns et al.., and he really was serious about "running code = and running away!". Problem is, people have to deal with the residue; = Randy is usually on the unhappy side of this equation... -danny= From shane@castlepoint.net Tue Dec 18 18:35: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 AFAAC21E8053 for ; Tue, 18 Dec 2012 18:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.159 X-Spam-Level: X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[AWL=0.278, 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 nUmPQd2JnH+s for ; Tue, 18 Dec 2012 18:35:41 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 446D821E8049 for ; Tue, 18 Dec 2012 18:35:41 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D70F130000D for ; Wed, 19 Dec 2012 02:35:40 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 08F3C30000C; Tue, 18 Dec 2012 19:35:39 -0700 (MST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Tue, 18 Dec 2012 19:35:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> References: , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Dec 18 19:35: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: 50d127fc199635472150313 X-DSPAM-Factors: 27, from+a, 0.01000, Subject*sidr+#+#+for, 0.01000, lot+of, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, 2012+#+3, 0.01000, Mime-Version*OS+X, 0.01000, is+that, 0.01000, the+full, 0.01000, 18+2012, 0.01000, From*Amante+shane, 0.01000, is+#+#+#+and, 0.01000, that+#+#+is, 0.01000, mailing+list, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, 2012+at, 0.01000, Mime-Version*Mail+#+1499, 0.01000, at+#+#+PM, 0.01000, and+#+the, 0.01000, Cc*sidr+wg, 0.01000, for+a, 0.01000, the+#+#+a, 0.01000, the+#+#+a, 0.01000, On+Dec, 0.01000, a+#+#+and, 0.01000, to+#+#+it, 0.01000, Mime-Version*6.2+1499, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 02:35:41 -0000 On Dec 18, 2012, at 3:03 PM, "Sriram, Kotikalapudi" = wrote: > Adding to Oliver's suggestion, it will be even more effective if, in = the "origin only" case,=20 > the mitigator announces a slightly more specific (e.g., two /17s for = a /16)=20 > if the maxlength of the victim's existing ROA permits it (of course, = victim=92s AS is inserted=20 > as the origin AS as suggested).=20 > More specific wins, so the downside of one hop longer path length goes = away. =20 Sound fine in theory, but will not work in practice. *When* the = original announcement is a (IPv4) /24 and all providers filter on = announcements > /24 ... you're, umm, up a creek without a paddle if you = don't have an ability to [immediately] originate the same /24 from a = "proxy" AS. Remember, there's a *lot* of "legitimate" more specifics out there = already, primarily for the purposes of Traffic Engineering (TE). -shane > And in the full path validation case, the victim forward signs a more = specific=20 > (if permissible by existing ROA) to the mitigator. The victim also = sets pCount =3D 0 for this update. >=20 > Sriram >=20 >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of = Borchert, Oliver [oliver.borchert@nist.gov] >> One solution here is that the mitigator either prepends the victims = AS (works with "origin only") including the downside that the path is = one hop longer. But hey, better than nothing. For origin + path = validation the victim creates a bgpsec peering with the mitigator and = signs the path. This can be done pretty easily I guess. >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From danny@tcb.net Tue Dec 18 18:36: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 9C90321E8063 for ; Tue, 18 Dec 2012 18:36:16 -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.157, 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 PQLdCkWmx7X9 for ; Tue, 18 Dec 2012 18:36:16 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 40CEA21E8034 for ; Tue, 18 Dec 2012 18:36:16 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id F41F430000E for ; Wed, 19 Dec 2012 02:36:15 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-71-171-117-166.clppva.fios.verizon.net [71.171.117.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 6AD2A30000C; Tue, 18 Dec 2012 19:36:15 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Tue, 18 Dec 2012 21:36:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <43BD9CBC-8DEC-4DB3-A0E2-0E8E26096782@tcb.net> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Dec 18 19:36:15 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50d1281f199639150420360 X-DSPAM-Factors: 27, Subject*Re+#+the, 0.01000, Subject*sidr+#+#+for, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, to+#+this, 0.01000, 18+2012, 0.01000, Mime-Version*Message+#+v1283, 0.01000, 2012+#+4, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, On+Dec, 0.01000, Subject*for+speed, 0.01000, Mime-Version*Apple+#+framework, 0.01000, PM+#+Morrow, 0.01000, Subject*Re+#+#+need, 0.01000, Christopher+#+wrote, 0.01000, Subject*the+need, 0.01000, To*Christopher+Morrow, 0.01000, Cc*wg+#+sidr, 0.01000, Dec+#+#+at, 0.01000, or+#+#+can, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, Subject*sidr+the, 0.01000, Dec+#+2012, 0.01000, Mime-Version*1.0+#+Message, 0.01000, Cc*sidr+#+list, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 02:36:16 -0000 On Dec 18, 2012, at 4:52 PM, Christopher Morrow wrote: >> (to which I would argue the RIRs already has enough >> resources to handle it, or some tricks can be perhaps applied to make >=20 > do they? Heh, fine question Chris.. If they don't, they'd better get busy = increasing fees and putting business cases together, I hear it's not = cheap - I sure hope my RIR fees don't go up to justify this... -danny From danny@tcb.net Tue Dec 18 18:37: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 3F25621E8045 for ; Tue, 18 Dec 2012 18:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.294 X-Spam-Level: X-Spam-Status: No, score=-100.294 tagged_above=-999 required=5 tests=[AWL=0.143, 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 nhmQ4zcED2oE for ; Tue, 18 Dec 2012 18:37:07 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id D2EAF21F8597 for ; Tue, 18 Dec 2012 18:37:07 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 913BD30000D for ; Wed, 19 Dec 2012 02:37:07 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-71-171-117-166.clppva.fios.verizon.net [71.171.117.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 0906030000C; Tue, 18 Dec 2012 19:37:06 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Danny McPherson In-Reply-To: <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> Date: Tue, 18 Dec 2012 21:37:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <43798C43-8E3A-45B4-93A3-7A11E49AE680@tcb.net> References: , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1283) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Dec 18 19:37: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: 50d12853199631046510185 X-DSPAM-Factors: 27, Subject*Re+#+the, 0.01000, from+a, 0.01000, Subject*sidr+#+#+for, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, I+#+that, 0.01000, 18+2012, 0.01000, Mime-Version*Message+#+v1283, 0.01000, is+#+#+#+and, 0.01000, 2012+at, 0.01000, at+#+#+PM, 0.01000, Cc*sidr+wg, 0.01000, PM+Shane, 0.01000, On+Dec, 0.01000, a+#+#+and, 0.01000, Subject*for+speed, 0.01000, Mime-Version*Apple+#+framework, 0.01000, Subject*Re+#+#+need, 0.01000, a+#+#+a, 0.01000, the+#+#+is, 0.01000, PM+#+Amante, 0.01000, Subject*the+need, 0.01000, Cc*wg+#+sidr, 0.01000, Shane+Amante, 0.01000, Dec+#+#+at, 0.01000, PM+#+#+wrote, 0.01000, Mime-Version*1.0+Apple, 0.01000, Subject*sidr+the, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 02:37:08 -0000 On Dec 18, 2012, at 9:35 PM, Shane Amante wrote: > Sound fine in theory, but will not work in practice. *When* the = original announcement is a (IPv4) /24 and all providers filter on = announcements > /24 ... you're, umm, up a creek without a paddle if you = don't have an ability to [immediately] originate the same /24 from a = "proxy" AS. Good point Shane, I forgot that one... -danny From shane@castlepoint.net Tue Dec 18 19:12: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 2EEB611E8099 for ; Tue, 18 Dec 2012 19:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.558 X-Spam-Level: X-Spam-Status: No, score=0.558 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_05=-1.11, 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 tiYjSsWRRR1T for ; Tue, 18 Dec 2012 19:12:16 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1274821F85D9 for ; Tue, 18 Dec 2012 19:12:16 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id BE04530000D for ; Wed, 19 Dec 2012 03:12:15 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id D4D3030000C; Tue, 18 Dec 2012 20:12:13 -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: Tue, 18 Dec 2012 20:12:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F612F58-7F6C-4A0E-8C19-80D3D26EAC76@castlepoint.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Dec 18 20:12:15 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50d1308f199631290258625 X-DSPAM-Factors: 27, Subject*Re+#+the, 0.01000, Subject*sidr+#+#+for, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, Mime-Version*OS+X, 0.01000, with+#+#+of, 0.01000, wrote+I, 0.01000, 18+2012, 0.01000, that+#+it, 0.01000, From*Amante+shane, 0.01000, to+#+#+for, 0.01000, and+#+a, 0.01000, be+#+#+#+the, 0.01000, 2012+at, 0.01000, Mime-Version*Mail+#+1499, 0.01000, at+#+#+PM, 0.01000, and+#+the, 0.01000, Cc*sidr+wg, 0.01000, the+#+to, 0.01000, cases+where, 0.01000, the+#+#+a, 0.01000, com+wrote, 0.01000, be+#+to, 0.01000, On+Dec, 0.01000, a+#+that, 0.01000, for+#+#+the, 0.01000, Subject*for+speed, 0.01000, to+#+#+#+in, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 03:12:17 -0000 On Dec 18, 2012, at 12:48 PM, Randy Bush wrote: > I am trying to understand why our fellow engineers at Verisign are > obsessed with global propagation of RPKI data on the order of a few > minutes. Then a friend hit me with the clue by four. It's about = third > party DDoS (and other attack) mitigation. Right, that's one reason[1] ... but, in the spirit of full disclosure = here, since you didn't say "for example" in the case of Verisign ... = there are other companies *aside* from Verisign that offer third-party = DDoS scrubbing and attack mitigation services: = https://www.google.com/#hl=3Den&tbo=3Dd&sclient=3Dpsy-ab&q=3Dddos%20scrubb= ing%20service&oq=3D&gs_l=3D&pbx=3D1&bav=3Don.2,or.r_gc.r_pw.r_qf.&bvm=3Dbv= .1355534169,d.aWM&fp=3Da7e118819f5e1e5b&bpcl=3D40096503&biw=3D1209&bih=3D7= 66&pf=3Dp&pdl=3D300 = http://www.bing.com/search?q=3DDDos+scrubbing+services&qs=3Dn&form=3DQBRE&= pq=3Dddos+scrubbing+services&sc=3D0-14&sp=3D-1&sk=3D Quite frankly, the Google ads (at the top and to the right) are more = useful in this particular instance than the actual search results. = Sigh. (Although, I find the ads for Residential Cleaning and "Merry = Maids" to be quite humorous in a list of ads results for "DDoS = scrubbing" ... good job Google! :-). -shane [1] I'd also note there are legitimate cases where customers may be = unable to serve traffic for their content/service/application, (think: = unexpected, but legitimate flash crowds/traffic combined with = under-provisioned tail circuit capacity). In that case, it may be far = easier for the customer to temporarily give up, say, a /24 that their = content/service/application was being served out of and allow a third = party to announce it out of the SP's AS (while still serving the same = content/service/application off servers moved to or X-connect'ed to a = new 'higher bandwidth' location), until the "storm passed" ...= From kotikalapudi.sriram@nist.gov Wed Dec 19 05:21: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 36A2021F8B2F for ; Wed, 19 Dec 2012 05:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 xxbA7MPBw1eY for ; Wed, 19 Dec 2012 05:21:16 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51921F8B30 for ; Wed, 19 Dec 2012 05:21:16 -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.328.9; Wed, 19 Dec 2012 08:21:10 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 19 Dec 2012 08:21:15 -0500 From: "Sriram, Kotikalapudi" To: Shane Amante Date: Wed, 19 Dec 2012 08:21:14 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3dkYoLew0UqbFUQgmFLLEQUxyptAAWP0vX Message-ID: References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> In-Reply-To: <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 13:21:17 -0000 > > On Dec 18, 2012, at 3:03 PM, "Sriram, Kotikalapudi" wrote: >> Adding to Oliver's suggestion, it will be even more effective if, in the= "origin only" case, >> the mitigator announces a slightly more specific (e.g., two /17s for a = /16) >> if the maxlength of the victim's existing ROA permits it (of course, vic= tim=92s AS is inserted >> as the origin AS as suggested). >> More specific wins, so the downside of one hop longer path length goes a= way. > > Sound fine in theory, but will not work in practice. *When* the original= announcement is=20 > a (IPv4) /24 and all providers filter on announcements > /24 ... you're, = umm, up a creek=20 > without a paddle if you don't have an ability to [immediately] originate = the same /24 from a "proxy" AS. > > Remember, there's a *lot* of "legitimate" more specifics out there alread= y, primarily for the purposes of Traffic Engineering (TE). The proposed solution would work fine in practice as well.=20 Whichever prefix (or more specific of it) that the mitigator and the victim= decide to=20 propagate (via the mitigator) for DDoS mitigation today in BGP, the same pr= efix can also=20 be propagated with BGPSEC (and more securely).=20 If =93all providers filter on announcements > /24=94 as you say,=20 then that is a constraint for the DDoS mitigation method under discussion=20 regardless of whether it is in BGP or BGPSEC. Sriram =20 From russw@riw.us Wed Dec 19 05:47: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 493B121F8548 for ; Wed, 19 Dec 2012 05:47: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=[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 3hBUQzXbmak7 for ; Wed, 19 Dec 2012 05:47:04 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id ABAF421F850D for ; Wed, 19 Dec 2012 05:47: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 1TlJzE-0002cK-4M for sidr@ietf.org; Wed, 19 Dec 2012 05:47:04 -0800 Message-ID: <50D1C55C.9010305@riw.us> Date: Wed, 19 Dec 2012 08:47:08 -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: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 13:47:05 -0000 > The proposed solution would work fine in practice as well. > Whichever prefix (or more specific of it) that the mitigator and the victim decide to > propagate (via the mitigator) for DDoS mitigation today in BGP, the same prefix can also > be propagated with BGPSEC (and more securely). How long will it take a BGPSEC update to traverse the network, end-to-end? Remember that the update must be re-signed at every hop, take into account the normal speed of BGP operations, and don't forget the processing, serialization, and memory delay load of adding a signature... Just thought I'd bring us back to the original subject line --this isn't about solving the problem for "perfect security," but for real world use. And no, "it'll be fast enough once we've gone a generation or two of routers into the future," isn't a good enough answer. The only way to know what the Internet will look like in ten years is to stop innovation and growth in their tracks --I know a lot of folks would really like this solution, but... BTW, BGPSEC isn't even close to "perfect security." In fact, I don't think BGPSEC actually solves much of anything at all at this point --other than allowing you to point fingers at the "guilty party" much more effectively than in the past. I can't seem to find that particular requirement in any requirements document, though. Russ -- <>< riwhite@verisign.com russw@riw.us From shane@castlepoint.net Wed Dec 19 05:50: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 350D421F8732 for ; Wed, 19 Dec 2012 05:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=0.412, 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 v-G3z5OF69L9 for ; Wed, 19 Dec 2012 05:50:27 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7C721F8711 for ; Wed, 19 Dec 2012 05:50:26 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id E99B4300010 for ; Wed, 19 Dec 2012 13:50:25 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id CAE0930000D; Wed, 19 Dec 2012 06:50:24 -0700 (MST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Wed, 19 Dec 2012 06:50:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Dec 19 06:50: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: 50d1c621199631899517271 X-DSPAM-Factors: 27, Subject*Re+#+the, 0.01000, don't+#+#+#+to, 0.01000, from+a, 0.01000, Sriram+Kotikalapudi, 0.01000, Sriram+Kotikalapudi, 0.01000, Subject*sidr+#+#+for, 0.01000, don't+have, 0.01000, lot+of, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, from+#+#+AS, 0.01000, to+#+to, 0.01000, 2012+#+3, 0.01000, in+BGP, 0.01000, in+BGP, 0.01000, a+#+AS, 0.01000, Mime-Version*OS+X, 0.01000, also+be, 0.01000, 18+2012, 0.01000, and+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, 2012+#+#+#+AM, 0.01000, the+new, 0.01000, is+#+#+#+and, 0.01000, their+#+to, 0.01000, you+#+#+an, 0.01000, as+well, 0.01000, the+#+#+the, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 13:50:28 -0000 On Dec 19, 2012, at 6:21 AM, "Sriram, Kotikalapudi" = wrote: >> On Dec 18, 2012, at 3:03 PM, "Sriram, Kotikalapudi" = wrote: >>> Adding to Oliver's suggestion, it will be even more effective if, in = the "origin only" case, >>> the mitigator announces a slightly more specific (e.g., two /17s = for a /16) >>> if the maxlength of the victim's existing ROA permits it (of course, = victim=92s AS is inserted >>> as the origin AS as suggested). >>> More specific wins, so the downside of one hop longer path length = goes away. >>=20 >> Sound fine in theory, but will not work in practice. *When* the = original announcement is=20 >> a (IPv4) /24 and all providers filter on announcements > /24 ... = you're, umm, up a creek=20 >> without a paddle if you don't have an ability to [immediately] = originate the same /24 from a "proxy" AS. >>=20 >> Remember, there's a *lot* of "legitimate" more specifics out there = already, primarily for the purposes of Traffic Engineering (TE). >=20 > The proposed solution would work fine in practice as well. In who's world? ;-) > Whichever prefix (or more specific of it) that the mitigator and the = victim decide to=20 > propagate (via the mitigator) for DDoS mitigation today in BGP, the = same prefix can also=20 > be propagated with BGPSEC (and more securely).=20 I thought we were just talking about _Origin_ Validation, not BGPSEC? > If =93all providers filter on announcements > /24=94 as you say,=20 > then that is a constraint for the DDoS mitigation method under = discussion=20 > regardless of whether it is in BGP or BGPSEC. Not true. There are a variety of techniques available today, which will = fail with Origin Validation. By way of a couple of examples, here they = are. First, "Proxy AS" originates same /24 as "Victim AS". 1) "Victim AS" then withdraws their /24 and falls back on an existing, = covering aggregate, e.g.: /23, /20, etc. for delivery of the scrubbed = traffic. 2) "Victim AS" performs AS_PATH prepending of their /24 to make it less = preferred compared to the new, shorter AS_PATH length "Proxy AS" = origination. 3) "Victim AS" uses their SP's BGP "Traffic Engineering" Communities to = signal to their Service Provider(s) to lower LOCAL_PREF of the Victim's = /24, inside their SP(s) AS, compared to the /24 being announced from = "Proxy AS". It's all about intent ... -shane= From kotikalapudi.sriram@nist.gov Wed Dec 19 06:42: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 6BD4721F84FF for ; Wed, 19 Dec 2012 06:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ezlzqVNqxBjw for ; Wed, 19 Dec 2012 06:42:19 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A09F421F84ED for ; Wed, 19 Dec 2012 06:42:19 -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.328.9; Wed, 19 Dec 2012 09:42:14 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 19 Dec 2012 09:42:18 -0500 From: "Sriram, Kotikalapudi" To: Danny McPherson , sidr wg list Date: Wed, 19 Dec 2012 09:42:17 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3dkXX7M9GEmU0OQuWSYHiGFCiqIAAYrymn Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 14:42:20 -0000 >> Adding to Oliver's suggestion, it will be even more effective if, in the= "origin only" case, >> the mitigator announces a slightly more specific (e.g., two /17s for a = /16) >> if the maxlength of the victim's existing ROA permits it (of course, vic= tim=92s AS is inserted >> as the origin AS as suggested). > > While I appreciate your consideration, this won't work. There are lots o= f practical reasons why, e.g., diverting a /17 worth of traffic through a D= DoS mitigation service is a bad idea when only a subset (e.g., a /32 or /24= ) is under attack. Being as surgical as possible is important, for lots of= operational and financial reasons. > With the proposed solution (in BGPSEC), it is possible to announce (for the= DDoS mitigation)=20 any /17 or /22 or /24 that the mitigator needs to announce. =20 The victim has to have set the maxlength long enough in anticipation of thi= s (for coordination=20 with the mitigator). Shane pointed out perhaps =93all providers filter on = announcements > /24=94.=20 That is a constraint for the DDoS mitigation method under discussion=20 regardless of whether it is in BGP or BGPSEC. > > And Randy, longer prefixes from "mitigator" with victim withdrawing (i.e.= , what I think you were trying to convey with "Forget a out kink with longe= r prefixes etc. victim withdraws.") would leave you with no place to delive= r the legitimate "scrubbed" traffic, and that might well be a problem, unle= ss you were intending to effectively complete the attack. > I am curious, if the mitigator announces a more specific (longer length) pr= efix,=20 then how do they leave a path open to deliver the scrubbed traffic back to = the victim=92s server=20 residing in that more specific prefix? All the ASes around the mitigator wo= uld be directing=20 any traffic for the victim=92s server towards the mitigator and not towards= the victim.=20 Well, may be the victim has an alternate server in the address space not im= pacted=20 by the announcement of the more specific? Or, there is a back channel (like= a VPN)=20 to deliver the scrubbed data back to the victim? =20 =20 >> More specific wins, so the downside of one hop longer path length goes a= way. > > More specifics override longer prefixes? =20 Not sure what you mean. More specific and longer prefix mean the same thing= .=20 > >> And in the full path validation case, the victim forward signs a more sp= ecific >> (if permissible by existing ROA) to the mitigator. The victim also sets = pCount =3D 0 for this update. > -- snip -- > That said, in an RPKI-enabled BGPSEC world I suppose the mitigator could = "leak" the route with some degree of impact, as you point out. As could at= tackers, of course, thereby allowing the leak itself to trigger the DoS on = the target, but we've been there as well already. > If you mean the DoS attacker is also leaking the more specific route announ= ced=20 by the mitigaor, then he (the DoS attacker) would be quite a fool, isn=92t = it?=20 It would seem he is then conducting DoS on his own router (in the data plan= e). =20 Sriram From kotikalapudi.sriram@nist.gov Wed Dec 19 07:25: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 553CE21F8A67 for ; Wed, 19 Dec 2012 07:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 jaaEu4aiqIFx for ; Wed, 19 Dec 2012 07:25:25 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5921421F8A61 for ; Wed, 19 Dec 2012 07:25: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.328.9; Wed, 19 Dec 2012 10:25:16 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 19 Dec 2012 10:25:20 -0500 From: "Sriram, Kotikalapudi" To: Shane Amante Date: Wed, 19 Dec 2012 10:25:20 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3d780s4h/sB6CDR1qFnoab9bJp0gACfO2B Message-ID: References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> In-Reply-To: <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 15:25:29 -0000 >> Whichever prefix (or more specific of it) that the mitigator and the vic= tim decide to >> propagate (via the mitigator) for DDoS mitigation today in BGP, the same= prefix can also >> be propagated with BGPSEC (and more securely). > > I thought we were just talking about _Origin_ Validation, not BGPSEC? Well, we were talking about both. But we can talk one at a time. It is well known that origin_only_validation has limitations in general=20 (e.g., spoofed origin, subprefix hijack with spoofed origin, etc.). In fact, the DDoS mitigation being discussed here is taking advantage of=20 those limitations in the origin_only_validation case. BGPSEC overcomes the limitations of origin_only_validation, and works quite cleanly (IMHO) in this DDoS mitigation scenario for the benefit of=20 the victim and the mitigator. > >> If =93all providers filter on announcements > /24=94 as you say, >> then that is a constraint for the DDoS mitigation method under discussio= n >> regardless of whether it is in BGP or BGPSEC. > > Not true. There are a variety of techniques available today, which will = fail with Origin Validation. By way of a couple of examples, here they are= . First, "Proxy AS" originates same /24 as "Victim AS". > 1) "Victim AS" then withdraws their /24 and falls back on an existing, c= overing aggregate, e.g.: /23, /20, etc. for delivery of the scrubbed traffi= c. > 2) "Victim AS" performs AS_PATH prepending of their /24 to make it less = preferred compared to the new, shorter AS_PATH length "Proxy AS" originatio= n. > 3) "Victim AS" uses their SP's BGP "Traffic Engineering" Communities to = signal to their Service Provider(s) to lower LOCAL_PREF of the Victim's /24= , inside their SP(s) AS, compared to the /24 being announced from "Proxy AS= ". > > It's all about intent ... I read what you described above quite carefully twice. =20 But it is not clear to me how origin_only_validation fails or interferes=20 in any of the methods you outlined above. I am sure you recognize by now that with origin_only_validation in place, in the proposed solution, the mitigator needs to spoof the victim=92s origi= n in order to pass ROA validation. (Again, if we advance to path validation, then the proposed solution in BGP= SEC does not require the origin spoofing etc. ... we have already gone over tha= t.) =20 Sriram From wesley.george@twcable.com Wed Dec 19 08:08: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 3993421F8598 for ; Wed, 19 Dec 2012 08:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 y5x7jxSfiZB0 for ; Wed, 19 Dec 2012 08:08:48 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A22D621F8586 for ; Wed, 19 Dec 2012 08:08:48 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,318,1355115600"; d="scan'208";a="670053" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Dec 2012 11:08:43 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 19 Dec 2012 11:08:47 -0500 From: "George, Wes" To: Alexey Melnikov , sidr wg Date: Wed, 19 Dec 2012 11:08:55 -0500 Thread-Topic: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 Thread-Index: Ac3YpKthvwn2V5zSS+2VimnbjmekHAFXOhZQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033A3B3E2B@PRVPEXVS15.corp.twcable.com> References: <50C8E17D.3090507@isode.com> In-Reply-To: <50C8E17D.3090507@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 Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 16:08:49 -0000 > > 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02 > actually a problem that the WG needs to address? (Answer: yes or no. > Additional information is welcomed, but I don't want people to repeat > the whole discussion.) [WEG] yes, but I tend to agree that it's not a technical problem. > > 2) If you answered "yes" to the question #1, please also answer the > following question: > > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to > become a WG document? Please choose one of the following: > > > a) Ready for Adoption (whether or not you have some specific issues with > it. Also, this answer is unrelated to whether this should be a separate > draft or a part of an existing draft). > > b) Needs more work BEFORE Adoption > > c) Should not be adopted. In particular this mean that you don't believe > any amount of work on the proposed draft will address your issues. So > any solution to this problem should be a new draft written from scratch. > > d) Abstain/don't care [WEG] b. The text itself is ok, but we need to resolve #3 before adoption. > > > 3) If you answered "a" or "b" above, please also answer the following > question: > > Does this need to be in a standalone draft, or can it be incorporated > into another existing WG draft? When answering this question please only > base your answer on technical reasons, in particular please leave the > decision on who is going to edit the document (if it is standalone) to > WG chairs. [WEG] It needs to be incorporated into an existing draft. This text is covering a very specific gotcha with some helpful recommendati= ons and no actual requirements. It currently reads like an orphaned section= of another draft, probably the operational considerations (origin-ops) dra= ft. 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 tim@ripe.net Wed Dec 19 08:23: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 8FA2A21F8B20 for ; Wed, 19 Dec 2012 08:23:01 -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 AV6rMguT0XgQ for ; Wed, 19 Dec 2012 08:23:00 -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 55F0E21F8B1E for ; Wed, 19 Dec 2012 08:23:00 -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 1TlMQ2-0008Qp-6d; Wed, 19 Dec 2012 17:22:55 +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 1TlMQ2-0000bi-3e; Wed, 19 Dec 2012 17:22:54 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Bruijnzeels In-Reply-To: Date: Wed, 19 Dec 2012 17:22:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <487F9F23-F609-48A2-BE67-6361291BDFCF@ripe.net> References: To: Danny McPherson , sidr wg list X-Mailer: Apple Mail (2.1499) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20121219 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 -0.0 T_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] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07194672e44f91ed1d154237503a8a10aeff Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 16:23:01 -0000 Hi Danny, WG, People have mentioned that if the security was somehow part of the = updates themselves, then you could have security at the speed of = updates. I don't see how this could work, it would have to be a = completely different set of standards from what's currently being worked = on. Most likely this would result in lots of cycles on routers, but = without any concrete proposals on this there really isn't much more I = can sensibly say about this approach here.. So for the sake of argument let me just stick to the model that we have = now where the RPKI is an external system, separate from the BGP updates. This means that when operators make changes in BGP, they will also need = to edit part of the RPKI.=20 Chris described a path from roa (or any rpki object) creator to = consumer: On Dec 18, 2012, at 10:52 PM, Christopher Morrow = wrote: > The architecture as laid out is, from 'roa creator' to 'roa consumer', = roughly: > A publication point (nominally one per roa-creator) > B gatherers (nominally one per roa-consumer) > C internal-cache-systems (some number per roa-consumer) > D routers Strictly speaking there is a step before A: creating the new objects. = Dependent on the system (and especially if a remote pub server is used) = there may be a short delay before the objects are actually published. But the basic model is right in my opinion. So following Chris's line of = thought: > (yes, there is the iana->rir part of the tree > yes, there are are more than just ROAs in the repositories) >=20 > So, the part that Randy and Danny and Eric are talking about is, as > far as the global system, is the A -> B conversation. Once you get > beyond B (to C and D) the problem is entirely inside some operator's > network and nothing on the outside matters. >=20 > Essentially the problem here is distribution of 10k of data to ~40k > endpoints (today, it'll grow tomorrow, fine) in ~2 mins time (or 5 > mins or 10 mins or ... someone draw a line in the sand so we know what > the target is) I would really like to echo Chris's last paragraph here. What do you = think is a reasonable time to propagate from an operator editing the = RPKI (A) -> 99.9% of Bs? I understand that half a day is way too long. Instantaneous is = theoretically impossible when BGP and RPKI are separate. But is there = really no reasonable pragmatic indication of what would be 'good enough' = for the real world? E.g. if we can come up with a structure that enables = repositories to support 100k RP tools ('B', assuming 2 gatherers per = ASN) getting their *updates* (full dump separate thread please) every 10 = minutes, is that good enough? Cheers Tim= From shane@castlepoint.net Wed Dec 19 08:23: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 84B2021F8449 for ; Wed, 19 Dec 2012 08:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.037 X-Spam-Level: X-Spam-Status: No, score=0.037 tagged_above=-999 required=5 tests=[AWL=0.474, 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 q03WOqfdnaE7 for ; Wed, 19 Dec 2012 08:23:27 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id CEE3321F8445 for ; Wed, 19 Dec 2012 08:23:27 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id BBCB8300013 for ; Wed, 19 Dec 2012 16:23:25 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id F3836300010; Wed, 19 Dec 2012 09:23:24 -0700 (MST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Wed, 19 Dec 2012 09:23:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Dec 19 09:23: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: 50d1e9fd199632090964881 X-DSPAM-Factors: 27, Subject*Re+#+the, 0.01000, and+#+#+#+the, 0.01000, 2012+#+#+25, 0.01000, Sriram+Kotikalapudi, 0.01000, Subject*sidr+#+#+for, 0.01000, the+#+I, 0.01000, them+into, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, have+no, 0.01000, a+#+#+with, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, from+#+#+AS, 0.01000, BGPSEC+router, 0.01000, to+#+to, 0.01000, to+#+to, 0.01000, the+#+only, 0.01000, To*Kotikalapudi+#+nist.gov, 0.01000, would+not, 0.01000, in+BGP, 0.01000, in+BGP, 0.01000, a+#+AS, 0.01000, a+#+AS, 0.01000, Mime-Version*OS+X, 0.01000, and+or, 0.01000, not+be, 0.01000, not+be, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 16:23:28 -0000 Sriram, On Dec 19, 2012, at 8:25 AM, "Sriram, Kotikalapudi" = wrote: >>> Whichever prefix (or more specific of it) that the mitigator and the = victim decide to >>> propagate (via the mitigator) for DDoS mitigation today in BGP, the = same prefix can also >>> be propagated with BGPSEC (and more securely). >>=20 >> I thought we were just talking about _Origin_ Validation, not BGPSEC? >=20 > Well, we were talking about both. But we can talk one at a time. > It is well known that origin_only_validation has limitations in = general=20 > (e.g., spoofed origin, subprefix hijack with spoofed origin, etc.). > In fact, the DDoS mitigation being discussed here is taking advantage = of=20 > those limitations in the origin_only_validation case. > BGPSEC overcomes the limitations of origin_only_validation, and works > quite cleanly (IMHO) in this DDoS mitigation scenario for the benefit = of=20 > the victim and the mitigator. I'm not sure I'd agree with your assessment, but see below for why. >>> If =93all providers filter on announcements > /24=94 as you say, >>> then that is a constraint for the DDoS mitigation method under = discussion >>> regardless of whether it is in BGP or BGPSEC. >>=20 >> Not true. There are a variety of techniques available today, which = will fail with Origin Validation. By way of a couple of examples, here = they are. First, "Proxy AS" originates same /24 as "Victim AS". >> 1) "Victim AS" then withdraws their /24 and falls back on an = existing, covering aggregate, e.g.: /23, /20, etc. for delivery of the = scrubbed traffic. >> 2) "Victim AS" performs AS_PATH prepending of their /24 to make it = less preferred compared to the new, shorter AS_PATH length "Proxy AS" = origination. >> 3) "Victim AS" uses their SP's BGP "Traffic Engineering" Communities = to signal to their Service Provider(s) to lower LOCAL_PREF of the = Victim's /24, inside their SP(s) AS, compared to the /24 being announced = from "Proxy AS". >>=20 >> It's all about intent ... >=20 > I read what you described above quite carefully twice. =20 > But it is not clear to me how origin_only_validation fails or = interferes=20 > in any of the methods you outlined above. > I am sure you recognize by now that with origin_only_validation in = place, > in the proposed solution, the mitigator needs to spoof the victim=92s = origin > in order to pass ROA validation. There are still a few problems with your proposal: 1) Spoofing the Origin ASN means you will always have a longer AS_PATH = length ("Spoofed Origin ASN + Proxy AS") vs. just originating the IP = prefix from the "Proxy AS". Yes, you can _try_ to workaround that using = some of the 'tricks' I outlined above, but in thinking about this more = I'm not sure all of those techniques I mentioned could be used. In the = proposals for Origin Validation (only), it's suggested that SP's will = either: a) Drop IP prefixes with Invalid Origin (Proxy AS) altogether -- = maybe not now, but that's the _goal_, eventually, right? This would = obviously outright ban "Proxy AS" from originating the IP prefix from = that AS for the purposes of DDoS attack mitigation or other reasons. b) Lower LOCAL_PREF of "Invalid" Origin vs. Valid Origin (per, = draft-ietf-sidr-origin-ops) ... perhaps for the foreseeable future. So, = in this case, even AS_PATH prepending by the "Victim AS" would not be = effective, because the higher LOCAL_PREF of the Valid Origin/ROA of = "Victim AS" will override the lower LOCAL_PREF of an Invalid Origin/ROA = of the "Proxy AS". =20 ... Does the above make it more clear how origin_only validation fails = or interferes with all of the methods I've outlined above? 2) I'm sure you realize that there may not be HW, (routers), available = to perform spoofing of the Origin AS you propose. For example, in the = case where capacity to a customer's site in undersized, it's possible = for me to [quickly] extend a X-connect from my PE router to their L2 = switch, (or plug their servers/switches into my L2 switches connected to = my PE router). In that case, my PE router has one, and only one, global = ASN configured on it. I have no choice *but* to originate that prefix = from my ASN, (the "Proxy ASN" if you will). 3) Since you seem to want to venture into BGPSEC, I'm unclear how = you're proposing to -- again, in an emergency -- get BGPSEC router (or, = AS?) keys to the "Proxy AS" to allow forward-signing of "Spoofed Origin = AS -> Proxy AS". Given the victim is under DDoS attack, transmission of = private (?) signing keys and uploading them into the 3rd-party DDoS = mitigators routers to allow the spoofed Origin AS to forward sign BGP = announcements seems, umm, a bit hazardous (and time-consuming)? = Particularly in the case where the Victim AS was using a per-AS signing = key, not a per-router+per-AS signing key. That's going to open up the = Victim AS to a potentially wider attack surface for the duration of = having the DDoS mitigation service spoof the Origin AS, behind their = "Transit AS", and/or the period of time for the Victim AS to publish and = roll-over to new BGPSEC per-AS or per-router-per-AS signing keys, no? > (Again, if we advance to path validation, then the proposed solution = in BGPSEC > does not require the origin spoofing etc. ... we have already gone = over that.) =20 I'm not following your logic here.=20 -shane= From pmohapat@cisco.com Wed Dec 19 09:33: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 A1CD321F853E for ; Wed, 19 Dec 2012 09:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xt+zFNHjF6ec for ; Wed, 19 Dec 2012 09:33:57 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 68CC121F859C for ; Wed, 19 Dec 2012 09:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=948; q=dns/txt; s=iport; t=1355938435; x=1357148035; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=H/I5fllr8hZzS4ZC0voqwrdh5i6L+rXiFCinwLMJRi4=; b=Sv+sTMs83wkByqUNZwpWM8r7RkGXOkZaTTi54IPdmqUqt9sD1iEm/18I Rs/L2a1gVQJmKq6Tu3rC60bgdiOKHZXZEEozaVt8LMKPtv9+U4jGVIrV+ 1n+BoXZveIPYI5JM+3MHQbn1zuQfcv4wTdLztPOI9w3EjzlD+oZLJipE/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALb50VCtJXG9/2dsb2JhbABEvgcWc4IgAQQ6OAcSAQgiFEIlAgQBDQ2IC7gokC9hA6ZSgnSBZCQa X-IronPort-AV: E=Sophos;i="4.84,318,1355097600"; d="scan'208";a="154719927" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 19 Dec 2012 17:33:55 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBJHXtTG026352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Dec 2012 17:33:55 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 11:33:54 -0600 From: "Pradosh Mohapatra (pmohapat)" To: Shane Amante , Randy Bush Thread-Topic: [sidr] the need for speed Thread-Index: AQHN3ViaNVhAUn1P2USyaDp95JTZgZgf1yyAgABqoQA= Date: Wed, 19 Dec 2012 17:33:54 +0000 Message-ID: In-Reply-To: <3F612F58-7F6C-4A0E-8C19-80D3D26EAC76@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.148.26] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E6249F505C86548B36F19908EE501BA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 17:33:57 -0000 >[1] I'd also note there are legitimate cases where customers may be >unable to serve traffic for their content/service/application, (think: >unexpected, but legitimate flash crowds/traffic combined with >under-provisioned tail circuit capacity). In that case, it may be far >easier for the customer to temporarily give up, say, a /24 that their >content/service/application was being served out of and allow a third >party to announce it out of the SP's AS (while still serving the same >content/service/application off servers moved to or X-connect'ed to a new >'higher bandwidth' location), until the "storm passed" ... In these use cases, what breaks if we allow two ROAs to co-exist in the system (one authorizing the customer AS and one authorizing the proxy AS to originate the prefix) _much before_ the attack (or storm) takes place? After all, this is a valid business relationship. Choose your pill wisely. - Pradosh From christopher.morrow@gmail.com Wed Dec 19 10:00: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 1B88421F8775 for ; Wed, 19 Dec 2012 10:00:14 -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=[AWL=0.000, 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 VOW5ea8wX-nA for ; Wed, 19 Dec 2012 10:00:13 -0800 (PST) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBD921F8750 for ; Wed, 19 Dec 2012 10:00:13 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id d13so957203eaa.35 for ; Wed, 19 Dec 2012 10:00:12 -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=APzz42lwcZAJBMwm9FxNGCssDh7snm/RM6US5arG2Yo=; b=yssNxaNe8Zf6xeGPaWxj0dq0jSr8/QMQZMrITR/9KoT2NXObzfzdGa7c8GGbSXWC6X xYFXwFr8QYCuK/3+E5Bv+YKZ5lh1f0KeMR/mRLvY8rgulFqjD6fI+TYJFnUwGMB/rAxV RsqlCo6MWdj9+lSgv7f5EofkfZSapOJvJjODsNiO+Mib227i7PqHwt5AmsPHPc/CDZp7 OAHWydebRFWcj0zgoGC27ilGrFqBD0o/13RTCLuQDJ6FeY/70LlAyc+YHMUB0jhqi7w8 HTFymvzmEvuAwhphc8EYn0/HQIRHegkYMj69Jpeho/EhGkMknhrYe2pJ0LhwH9E5KpaW yOcA== MIME-Version: 1.0 Received: by 10.14.214.132 with SMTP id c4mr16011062eep.18.1355940012352; Wed, 19 Dec 2012 10:00:12 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Wed, 19 Dec 2012 10:00:12 -0800 (PST) In-Reply-To: References: <3F612F58-7F6C-4A0E-8C19-80D3D26EAC76@castlepoint.net> Date: Wed, 19 Dec 2012 13:00:12 -0500 X-Google-Sender-Auth: DmMOa_biSJzASwE1_FkgkWI9Fso Message-ID: From: Christopher Morrow To: "Pradosh Mohapatra (pmohapat)" Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 18:00:14 -0000 On Wed, Dec 19, 2012 at 12:33 PM, Pradosh Mohapatra (pmohapat) wrote: > In these use cases, what breaks if we allow two ROAs to co-exist in the > system (one authorizing the customer AS and one authorizing the proxy AS the system already permits multiple ROA's for the same prefix, right? > to originate the prefix) _much before_ the attack (or storm) takes place? > After all, this is a valid business relationship. Choose your pill wisely. the concern, for the dos-mitigation and really for the flashcrowds as well (same thing in the end, "Oops, server go boom, move service to more-servers-r-us!"), is the lack of prior relationship and thus lack of existence of a new ROA. -chris (course, I could have missed your question entirely) From randy@psg.com Wed Dec 19 10:13: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 E2DE821F8A05 for ; Wed, 19 Dec 2012 10:13:07 -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 0hqD9g7XBdNz for ; Wed, 19 Dec 2012 10:13:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB021F89E8 for ; Wed, 19 Dec 2012 10:13:07 -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 1TlO8g-000FM2-QA for sidr@ietf.org; Wed, 19 Dec 2012 18:13:06 +0000 Date: Wed, 19 Dec 2012 13:13:06 -0500 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 18:13:08 -0000 [ apologies for having the attention span of a chihuahua, but i am being eaten by airplanes and relatives ] i was trying to make only two points o there is a useful poster child for the need for O(minutes) rpki (or perhaps just roa) propagation. as folk have repeatedly said, we need concrete examples and goals. o unfortunately, there is no internet technology today to completely, accurately, and securely maintain a globally distributed database (e.g. at every non-trivial pop) with time constraints on the order of a minute. it's a research problem. and a *really* interesting one. i am confident that the folk providing third-party mitigation services are clever enough to figure out their own hacks around this problem, and we do not need to second guess what might best work for them. and my apologies to anyone who is offended by my using ntt, verisign, and whoever as examples. the subject has been sufficiently clouded by indirection, hand-waving, and conjecture. concrete examples are good, and they're ones i know. oh, and apologies to chihuahuas, i guess :) randy From carlosm3011@gmail.com Wed Dec 19 10:18: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 DD28E21F87F4 for ; Wed, 19 Dec 2012 10:18: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 jAJjt9xfNCMe for ; Wed, 19 Dec 2012 10:18:23 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5751E21F8558 for ; Wed, 19 Dec 2012 10:18:23 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id j15so4568190qaq.11 for ; Wed, 19 Dec 2012 10:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bar9gXrnCI8HV7cCerLyfw2yviKykbMGZdkehalo2VQ=; b=paYyYoyl42r7DJ1wf0SYnCNhS9tC5wYas+6KcdCBvj93yxz8V1lQlF2IegjI2BzZOJ g0+Ikc0bFBR8BCE9c20huXNY4N1reu9us+DVTk2zdp7/kFpSnMNd4A7ohJF2MI7U1mAP TbwcxXAV2xow8/475y6C2AEvbISeYw32ycMB55ngFGsyiAnzQAQ24YAR59HMxSnbAZsX WlVIMI1+WGEtw2eHkCp1fB8nbAQrgoZWeALXzO3EmexHbf7YDUqr31HDmmyf0+Yc5GSl PYP0Cgv1XxI8dSEsXDnTvSHEFKkehQyOdMHsAwtvEg7qGxf2pObw9ZhqiF7vyBC9rNaE JnYA== X-Received: by 10.49.74.10 with SMTP id p10mr3686290qev.35.1355941102847; Wed, 19 Dec 2012 10:18:22 -0800 (PST) Received: from europa.local ([2001:13c7:7001:5128:511e:b203:1516:ac43]) by mx.google.com with ESMTPS id ou3sm1035964qeb.0.2012.12.19.10.18.20 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 10:18:21 -0800 (PST) Message-ID: <50D204EA.3050602@gmail.com> Date: Wed, 19 Dec 2012 16:18:18 -0200 From: "Carlos M. Martinez" 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: "Pradosh Mohapatra (pmohapat)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 18:18:24 -0000 On 12/19/12 3:33 PM, Pradosh Mohapatra (pmohapat) wrote: >> [1] I'd also note there are legitimate cases where customers may be ... > > In these use cases, what breaks if we allow two ROAs to co-exist in the > system (one authorizing the customer AS and one authorizing the proxy AS > to originate the prefix) _much before_ the attack (or storm) takes place? > After all, this is a valid business relationship. Choose your pill wisely. Is't this already allowed ? I don't think we need to change anything for this to work. > > - Pradosh ~Carlos > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From rbarnes@bbn.com Wed Dec 19 10:24: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 6875621F8795 for ; Wed, 19 Dec 2012 10:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.256 X-Spam-Level: X-Spam-Status: No, score=-106.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 KpuwVzmjn0RY for ; Wed, 19 Dec 2012 10:24:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8221F8765 for ; Wed, 19 Dec 2012 10:24:41 -0800 (PST) Received: from dhcp-192-1-255-192.col.bbn.com ([192.1.255.192]:56367) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TlOJr-000MYC-EU; Wed, 19 Dec 2012 13:24:39 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Richard Barnes In-Reply-To: <50D204EA.3050602@gmail.com> Date: Wed, 19 Dec 2012 13:24:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <34C173D3-9AB5-4F6E-AD4E-88D355B59F54@bbn.com> References: <50D204EA.3050602@gmail.com> To: Carlos M. Martinez X-Mailer: Apple Mail (2.1499) Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 18:24:52 -0000 >> In these use cases, what breaks if we allow two ROAs to co-exist in = the >> system (one authorizing the customer AS and one authorizing the proxy = AS >> to originate the prefix) _much before_ the attack (or storm) takes = place? >> After all, this is a valid business relationship. Choose your pill = wisely. >=20 > Is't this already allowed ? I don't think we need to change anything = for > this to work. I think that's the point. Going back to Randy's original message, the point is that if you can = plan ahead, then there's no issue here. The only problem arises if you = need to authorize someone at the last minute, which, as Randy points = out, is not really a solved problem. --Richard= From pmohapat@cisco.com Wed Dec 19 10:54: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 5B58B21F862D for ; Wed, 19 Dec 2012 10:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] 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 tTHR6OvQA+YM for ; Wed, 19 Dec 2012 10:54:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9F21F85FC for ; Wed, 19 Dec 2012 10:54:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=497; q=dns/txt; s=iport; t=1355943281; x=1357152881; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ru7D1/54HS+kl7UBTjdv1QCoI6TMhZ8kk316xEDFaYc=; b=XFkQ17F/rmozyqICFVqELwJ22lpnxNDodsEn4N0vMqS0XefdC3iryLhL 1q3N7cb1m/vpdRiI/JPfk7GC4Tq7ivEYF86PiTSW0TqkfzDyb6dVezdKS qOMvnK5jU7vS9AQrDjZUBNKQse4An3dv3xFzq1CEesNa0jntEU7+SdCtA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIIM0lCtJV2Y/2dsb2JhbABEvX0Wc4IgAQQ6OAcSAQgOFBRCJQIEAQ0NiAu4MpAvYQOmUoJ0giI X-IronPort-AV: E=Sophos;i="4.84,318,1355097600"; d="scan'208";a="151764195" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 19 Dec 2012 18:54:40 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBJIseLn031804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Dec 2012 18:54:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 12:54:39 -0600 From: "Pradosh Mohapatra (pmohapat)" To: Richard Barnes , "Carlos M. Martinez" Thread-Topic: [sidr] the need for speed Thread-Index: AQHN3ViaNVhAUn1P2USyaDp95JTZgZgf1yyAgABqoQCAAJKHAIAAAcaA//9/WYA= Date: Wed, 19 Dec 2012 18:54:39 +0000 Message-ID: In-Reply-To: <34C173D3-9AB5-4F6E-AD4E-88D355B59F54@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.90.224] Content-Type: text/plain; charset="us-ascii" Content-ID: <91F3B9486504114AA1C6C4543C292A07@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 18:54:41 -0000 >>> >>>In these use cases, what breaks if we allow two ROAs to co-exist in the >>> system (one authorizing the customer AS and one authorizing the proxy >>>AS >>> to originate the prefix) _much before_ the attack (or storm) takes >>>place? >>> After all, this is a valid business relationship. Choose your pill >>>wisely. >>=20 >> Is't this already allowed ? I don't think we need to change anything for >> this to work. > >I think that's the point. Yes, exactly. - Pradosh From pmohapat@cisco.com Wed Dec 19 10:54: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 2DE1421F8750 for ; Wed, 19 Dec 2012 10:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 r-vFzTJcG62z for ; Wed, 19 Dec 2012 10:54:44 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BA3CB21F8742 for ; Wed, 19 Dec 2012 10:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=991; q=dns/txt; s=iport; t=1355943283; x=1357152883; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+Ju4LE7EQQuqCnNw2yYe9sEiVyuoS8aJkgew5jsBB/Q=; b=e00YL27bjWlyB6faWKztbM6yasG+TDxa6obdZ8+mU4Mi3MWk2zrGxAdU y1VxeSITEz7qiYDoRnb+PpuIqiuZJtBRmcKTR7ODjaXF1zJMYbou/oRar DhD+VtGzubteBBduyicEZbUEKGY2aPPqFlWSgfWU0kSqyHAf5ho2E/3We M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACgN0lCtJXHA/2dsb2JhbABEvX0Wc4IgAQQ6OAcSAQgiFEIlAgQODYgLuDSQL2EDplKCdIIi X-IronPort-AV: E=Sophos;i="4.84,318,1355097600"; d="scan'208";a="154796392" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 19 Dec 2012 18:54:43 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBJIsh9J003669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Dec 2012 18:54:43 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.245]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 12:54:43 -0600 From: "Pradosh Mohapatra (pmohapat)" To: Christopher Morrow Thread-Topic: [sidr] the need for speed Thread-Index: AQHN3ViaNVhAUn1P2USyaDp95JTZgZgf1yyAgABqoQCAAI14AP//h5kA Date: Wed, 19 Dec 2012 18:54:42 +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.5.121010 x-originating-ip: [10.21.90.224] 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] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 18:54:45 -0000 >>In these use cases, what breaks if we allow two ROAs to co-exist in the >> system (one authorizing the customer AS and one authorizing the proxy AS > >the system already permits multiple ROA's for the same prefix, right? Yes (e.g. multihoming) and hence the question of why we can't use that framework. >>to originate the prefix) _much before_ the attack (or storm) takes place? >> After all, this is a valid business relationship. Choose your pill >>wisely. > >the concern, for the dos-mitigation and really for the flashcrowds as >well (same thing in the end, "Oops, server go boom, move service to >more-servers-r-us!"), is the lack of prior relationship and thus lack >of existence of a new ROA. > >-chris >(course, I could have missed your question entirely) No, thanks for clarifying. For DDoS mitigation at least, I thought there would be a prior business relationship. I am not familiar with on-the-fly relationship building process. - Pradosh From christopher.morrow@gmail.com Wed Dec 19 11:01: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 9F43621F862D for ; Wed, 19 Dec 2012 11:01:17 -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 kMzv8yqwebZQ for ; Wed, 19 Dec 2012 11:01:16 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6D521F84D1 for ; Wed, 19 Dec 2012 11:01:12 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id k11so987772eaa.37 for ; Wed, 19 Dec 2012 11:01:11 -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=ZXXdL6cMu30QUTqKlps8W5cpVwzaUKnXqv5RXw/B1zY=; b=QTmQ5WIFgnqy/MyQqelF75Yvf9Bl101OK9evbNhSN/bc35ievqKBBIdCOl1NDobPVd OYiz9YSRznLk6HwsnnBCHfksUYxtufxgRC/WdyCc9Erqv8CqJnGFHUen847yaiwQdawy liKMGEQKx+rFtcLrhaF11a61W2epJ+ppBmsnB5qQZoytMZA9bEl+z2lg5z66Yrq+aIlL SUnLkhZfjanH6JVnZe5IiRUa5IDrcRy2MV2nMOYPBkMbV/PmPzpln4qW9q67eq2rj31h 54P1ZZiis+BU5dg7dW8r+U7uUkaeQu/De1naY54x5SfCCw090xcGIUtiYU2yE5gB33ZT 9n7A== MIME-Version: 1.0 Received: by 10.14.208.137 with SMTP id q9mr16217880eeo.28.1355943671343; Wed, 19 Dec 2012 11:01:11 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Wed, 19 Dec 2012 11:01:11 -0800 (PST) In-Reply-To: References: Date: Wed, 19 Dec 2012 14:01:11 -0500 X-Google-Sender-Auth: -0WqFaNRFK9k4NxWonG-SSRl3vs Message-ID: From: Christopher Morrow To: "Pradosh Mohapatra (pmohapat)" Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 19:01:17 -0000 On Wed, Dec 19, 2012 at 1:54 PM, Pradosh Mohapatra (pmohapat) wrote: > No, thanks for clarifying. For DDoS mitigation at least, I thought there > would be a prior business relationship. I am not familiar with on-the-fly > relationship building process. for that case, and shane's (and probably a few more) the 'new relationship' could exist for: 1) a short period of time 2) immediately upon close of a phone call so, some extra churn in the rpki system as well as routing-system data changes. I think one of the points to haggle about is 'how quick' do they need to happen. From kotikalapudi.sriram@nist.gov Wed Dec 19 13:12: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 DE7B121F865B for ; Wed, 19 Dec 2012 13:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_43=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 nZ0lCYbtHKQC for ; Wed, 19 Dec 2012 13:12:28 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id C48CF21F85EE for ; Wed, 19 Dec 2012 13:12:27 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 19 Dec 2012 16:12:21 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 19 Dec 2012 16:12:25 -0500 From: "Sriram, Kotikalapudi" To: Shane Amante Date: Wed, 19 Dec 2012 16:12:22 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3eBSz6O3B/vHuoSFuD0te8HidCcgAJkiWw Message-ID: References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> In-Reply-To: <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 21:12:29 -0000 > >There are still a few problems with your proposal: >1) Spoofing the Origin ASN means you will always have a longer AS_PATH >length ("Spoofed Origin ASN + Proxy AS") vs. just originating the IP prefix from >the "Proxy AS". Yes, you can _try_ to workaround that using some of the 'tricks' >I outlined above, but in thinking about this more I'm not sure all of those >techniques I mentioned could be used. In the proposals for Origin Validation >(only), it's suggested that SP's will either: This has been said before but worth a repeat -- Talking about the spoofed origin ASN solution, the concern about path length increase by one hop really goes away because, as Danny has also pointed out, the mitigator wants to be rather surgical and hence announces a more specific (longer length) prefix in most cases. Thus, the mitigator is drawing towards itself the traffic that is DDoS'ing the victim's server but minimizes drawing traffic destined to other unaffected parts of the victim's address space. Due to the spoofed origin ASN, the proxy AS's BGP update is always Valid (in terms of the origin-only-validation outcome). I feel that none of the workaround tricks you mention are necessary considering that the BGP announcement from the proxy AS is for a more specific prefix (most of the time) and it is always Valid > a) Drop IP prefixes with Invalid Origin (Proxy AS) altogether -- maybe not now, >but that's the _goal_, eventually, right? This would obviously outright ban >"Proxy AS" from originating the IP prefix from that AS for the purposes of DDoS >attack mitigation or other reasons. This concern goes away per explanation provided above. > b) Lower LOCAL_PREF of "Invalid" Origin vs. Valid Origin (per, draft-ietf-sidr- >origin-ops) ... perhaps for the foreseeable future. So, in this case, even AS_PATH >prepending by the "Victim AS" would not be effective, because the higher >LOCAL_PREF of the Valid Origin/ROA of "Victim AS" will override the lower >LOCAL_PREF of an Invalid Origin/ROA of the "Proxy AS". This concern also goes away per explanation provided above. >... Does the above make it more clear how origin_only validation fails or >interferes with all of the methods I've outlined above? As I have explained above, we can eliminate the possibility of failure or interference by two means: (1) Proxy AS spoofs origin AS; (2) Proxy AS announces a more specific prefix (in most cases of DDoS mitigation). > >2) I'm sure you realize that there may not be HW, (routers), available to >perform spoofing of the Origin AS you propose. For example, in the case where >capacity to a customer's site in undersized, it's possible for me to [quickly] >extend a X-connect from my PE router to their L2 switch, (or plug their >servers/switches into my L2 switches connected to my PE router). In that case, >my PE router has one, and only one, global ASN configured on it. I have no >choice *but* to originate that prefix from my ASN, (the "Proxy ASN" if you will). > Is this that much different from AS prepending? Instead of inserting multiple times the PE router's ASN (in the prepending case), it inserts once the DDoS-mitigation customer's ASN in the path. Alternatively, the victim can set up a BGP session to the mitigator and inject the route (no spoofing by proxy AS in that case). But then I am not a developer/implementer ;) >3) Since you seem to want to venture into BGPSEC, I'm unclear how you're >proposing to -- again, in an emergency -- get BGPSEC router (or, AS?) keys to the >"Proxy AS" to allow forward-signing of "Spoofed Origin AS -> Proxy AS". Given >the victim is under DDoS attack, transmission of private (?) signing keys and >uploading them into the 3rd-party DDoS mitigators routers to allow the spoofed >Origin AS to forward sign BGP announcements seems, umm, a bit hazardous >(and time-consuming)? Particularly in the case where the Victim AS was using a >per-AS signing key, not a per-router+per-AS signing key. That's going to open up >the Victim AS to a potentially wider attack surface for the duration of having the >DDoS mitigation service spoof the Origin AS, behind their "Transit AS", and/or >the period of time for the Victim AS to publish and roll-over to new BGPSEC per- >AS or per-router-per-AS signing keys, no? > The solution that Oliver and I suggested does not have any of the complications that you mention above: http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html The victim AS does not need to transfer any router keys to the proxy AS. Instead the victim AS provides a signed update (with pCount=0) to the proxy AS (by creating a BGPSEC peering session or by other suitable means). Sriram From oliver.borchert@nist.gov Wed Dec 19 14:37: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 5806A21F85E6 for ; Wed, 19 Dec 2012 14:37:00 -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 Q7amvlUYRmOb for ; Wed, 19 Dec 2012 14:36:59 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id BC9BF21F85CD for ; Wed, 19 Dec 2012 14:36:59 -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.328.9; Wed, 19 Dec 2012 17:36:51 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 19 Dec 2012 17:36:56 -0500 From: "Borchert, Oliver" To: "Pradosh Mohapatra (pmohapat)" , Shane Amante , Randy Bush Date: Wed, 19 Dec 2012 17:36:55 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: AQHN3ViaNVhAUn1P2USyaDp95JTZgZgf1yyAgABqoQCAAHO5gA== Message-ID: References: <3F612F58-7F6C-4A0E-8C19-80D3D26EAC76@castlepoint.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 22:37:00 -0000 > In these use cases, what breaks if we allow two ROAs to co-exist in the system (one authorizing the customer AS and one authorizing the proxy AS to originate the prefix) _much before_ the attack (or storm) takes place? After all, this is a valid business relationship. Choose your pill wisely. Nothing will break, just think of multi-homing where two service providers announce the prefix out of their AS. Or just before a ROA expires a replacement should be installed beforehand to prevent ending up with an "invalid" during the origin validation. Again, I think it is worthwhile to mention that it takes only one ROA to declare the origin validation as valid. Oliver _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From shane@castlepoint.net Wed Dec 19 15:16: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 34BBA21F8991 for ; Wed, 19 Dec 2012 15:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[AWL=0.442, 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 CLUjEEPCNE99 for ; Wed, 19 Dec 2012 15:16:53 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7B68121F895C for ; Wed, 19 Dec 2012 15:16:53 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 83F9C30001E for ; Wed, 19 Dec 2012 23:16:47 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id D5DED30001C; Wed, 19 Dec 2012 16:16:46 -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, 19 Dec 2012 16:16:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Dec 19 16:16: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: 50d24adf199635450453591 X-DSPAM-Factors: 27, Subject*Re+#+the, 0.01000, to+#+#+#+to, 0.01000, and+#+#+#+the, 0.01000, Sriram+Kotikalapudi, 0.01000, Subject*sidr+#+#+for, 0.01000, them+into, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, prefix+from, 0.01000, prefix+from, 0.01000, AS+#+#+a, 0.01000, AS+#+#+a, 0.01000, have+no, 0.01000, a+#+#+with, 0.01000, the+#+#+#+by, 0.01000, 2012+#+2, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, from+#+#+AS, 0.01000, BGPSEC+router, 0.01000, to+#+to, 0.01000, To*Kotikalapudi+#+nist.gov, 0.01000, the+#+#+#+I, 0.01000, Cc*Borchert+#+oliver.borchert, 0.01000, a+#+AS, 0.01000, Mime-Version*OS+X, 0.01000, and+or, 0.01000, and+or, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Dec 2012 23:16:55 -0000 On Dec 19, 2012, at 2:12 PM, "Sriram, Kotikalapudi" = wrote: [--snip--] FWIW, I disagree with your assertions, but am cutting to the chase, = because I think you're still failing to understand why/when it's not = possible to "spoof" the Victim's AS. >> 2) I'm sure you realize that there may not be HW, (routers), = available to >> perform spoofing of the Origin AS you propose. For example, in the = case where >> capacity to a customer's site in undersized, it's possible for me to = [quickly] >> extend a X-connect from my PE router to their L2 switch, (or plug = their >> servers/switches into my L2 switches connected to my PE router). In = that case, >> my PE router has one, and only one, global ASN configured on it. I = have no >> choice *but* to originate that prefix from my ASN, (the "Proxy ASN" = if you will). >>=20 >=20 > Is this that much different from AS prepending? Instead of inserting = multiple > times the PE router's ASN (in the prepending case), it inserts once = the > DDoS-mitigation customer's ASN in the path. Alternatively, the victim = can > set up a BGP session to the mitigator and inject the route=20 > (no spoofing by proxy AS in that case). > But then I am not a developer/implementer ;)=20 There is no PE <-> CE eBGP session where one can originate the IP Prefix = from the "Victim AS". There is just this: ISP Proxy-AS Victim IP prefix AS1 +------+ +-------------------------------------+ | PE-1 |=3D=3D=3D=3D=3D=3D| Victim's L2 switches and/or servers | +------+ +-------------------------------------+ ^ | +---- This is not a CE router On the router PE-1, in the ISP AS (AS1), I am originating a BGP = announcement for a _directly_connected_ prefix, where the victim's = server/network/service is located. I am not aware of a capability in = any implementation that I'm familiar with where I can originate that = directly connected IP prefix for the Victim's network and have it appear = to be from the Victim's Original AS. When I originate an IP prefix on = PE-1, the Origin-AS of that IP prefix is AS1, the "Proxy AS", not the = "Victim's AS". Then again, perhaps I have not looked hard enough at = existing implementations ... Quite frankly, *not* having the capability in router implementations to = Originate an IP prefix with any random Origin_AS, (e.g.: PE-1), is = possibly one of the more effective deterrents /against/ mis-originating = an IP prefix from the 'intended'/correct Origin AS -- ooooh, there's = that word "intent" again. >> 3) Since you seem to want to venture into BGPSEC, I'm unclear how = you're >> proposing to -- again, in an emergency -- get BGPSEC router (or, AS?) = keys to the >> "Proxy AS" to allow forward-signing of "Spoofed Origin AS -> Proxy = AS". Given >> the victim is under DDoS attack, transmission of private (?) signing = keys and >> uploading them into the 3rd-party DDoS mitigators routers to allow = the spoofed >> Origin AS to forward sign BGP announcements seems, umm, a bit = hazardous >> (and time-consuming)? Particularly in the case where the Victim AS = was using a >> per-AS signing key, not a per-router+per-AS signing key. That's = going to open up >> the Victim AS to a potentially wider attack surface for the duration = of having the >> DDoS mitigation service spoof the Origin AS, behind their "Transit = AS", and/or >> the period of time for the Victim AS to publish and roll-over to new = BGPSEC per- >> AS or per-router-per-AS signing keys, no? >>=20 >=20 > The solution that Oliver and I suggested does not have any of the = complications > that you mention above:=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html=20 > The victim AS does not need to transfer any router keys to the proxy = AS. > Instead the victim AS provides a signed update (with pCount=3D0) to = the > proxy AS (by creating a BGPSEC peering session or by other suitable = means). Awesome. So, now we've got a recommendation to: a) Spoof the Victim's Origin AS; and, b) Use pCount =3D 0 to avoid validating the AS_PATH signatures I'm failing to see what the group is trying to accomplish here if these = are the recommendations. One has to question what value there is in = deploying Origin Validation & BGPSEC if the answer when it can't = accommodate a operationally viable scenarios is to effectively "turn it = off". -shane= From stbryant@cisco.com Thu Dec 20 04:16: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 9938E21F8753 for ; Thu, 20 Dec 2012 04:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.61 X-Spam-Level: X-Spam-Status: No, score=-110.61 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Ga18YxKZfAdj for ; Thu, 20 Dec 2012 04:16:58 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CE00121F874B for ; Thu, 20 Dec 2012 04:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8672; q=dns/txt; s=iport; t=1356005818; x=1357215418; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=apZivqs+FbZ4GVYdn0FAxLE3V4aZr0Hm8r1fNv6QQcI=; b=EeFczGQaibcm02BBtnetJfG4GVHR6K8W5N40FzyriaiRZjNmqu4nLHdq m8zH8Z6MK6uaa3YJcz3Lr1BlOs43nv2Ai/xNxYKBSTwyW1IPwwkLLor8g bSJgxgaRKx+zLUQ1eP5v6qxwMgmjB4z66kZG+7Zyo1LxFLkX3Q26fCqdO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsILAMMA01CQ/khR/2dsb2JhbABEMYMXiFGxUxZzgh4BAQEDAQEBAWsKAQwEHAMBAgEJFgQLCQMCAQIBFR8HAggTAQUCAQGICQYMuRiMUoRDA5YLgRyPLIJ0 X-IronPort-AV: E=Sophos;i="4.84,322,1355097600"; d="scan'208,217";a="148602047" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 20 Dec 2012 12:16:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBKCGr6K013848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 12:16:53 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBKCGnxC013625; Thu, 20 Dec 2012 12:16:49 GMT Message-ID: <50D301C2.1080103@cisco.com> Date: Thu, 20 Dec 2012 12:17:06 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: draft-ietf-sidr-algorithm-agility@tools.ietf.org References: <37ADFDF9-912A-470E-BE5E-DC561659E2D9@verisign.com> In-Reply-To: <37ADFDF9-912A-470E-BE5E-DC561659E2D9@verisign.com> X-Forwarded-Message-Id: <37ADFDF9-912A-470E-BE5E-DC561659E2D9@verisign.com> Content-Type: multipart/alternative; boundary="------------040602060003040905000609" Cc: "sidr-chairs@tools.ietf.org" , sidr wg list Subject: [sidr] Fwd: Re: 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: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 12:16:59 -0000 This is a multi-part message in MIME format. --------------040602060003040905000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This late comment regarding draft-ietf-sidr-algorithm-agility was posted to the IETF list in response to the IETF LC. Not everyone looks at the main IETF list so I am relaying it to the SIDR list. Stewart -------- Original Message -------- Subject: Re: [sidr] Last Call: (Algorithm Agility Procedure for RPKI.) to Proposed Standard Date: Mon, 17 Dec 2012 16:42:16 -0500 From: Eric Osterweil To: IETF Disgust All, Sorry for the late reply. I realize these comments come after the 12/14 deadline, but it is my hope that they can still inform any active decision processes. I'd like to mention that some of us have calculated that the global RPKI will take a significant amount of time to crawl [1], and the algorithm agility draft (as it is currently proposed) will almost double that time, because it will necessarily almost double the number of objects in the global RPKI. I personally worry a lot about this approach, as I feel it will likely lead to an operationally unviable standard, in which routing will be unable to adapt to changes in configuration for days, weeks, or even months, because of this design (described in [1]). The lateness of this message is simply a consequence of the fact that our analyses have taken longer than we planned, and I do apologize for that. Thanks, Eric [ 1 ] http://techreports.verisignlabs.com/tr-lookup.cgi?trid=1120005&rev=2 On Nov 30, 2012, at 10:38 AM, The IESG wrote: > > 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. > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr . --------------040602060003040905000609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This late comment regarding draft-ietf-sidr-algorithm-agility was posted to the IETF list in response to the IETF LC. Not everyone looks at the main IETF list so I am relaying it to the SIDR list.

Stewart


-------- Original Message --------
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-algorithm-agility-08.txt> (Algorithm Agility Procedure for RPKI.) to Proposed Standard
Date: Mon, 17 Dec 2012 16:42:16 -0500
From: Eric Osterweil <eosterweil@verisign.com>
To: IETF Disgust <ietf@ietf.org> 


All,

Sorry for the late reply.  I realize these comments come after the 12/14 deadline, but it is my hope that they can still inform any active decision processes.

I'd like to mention that some of us have calculated that the global RPKI will take a significant amount of time to crawl [1], and the algorithm agility draft (as it is currently proposed) will almost double that time, because it will necessarily almost double the number of objects in the global RPKI.  I personally worry a lot about this approach, as I feel it will likely lead to an operationally unviable standard, in which routing will be unable to adapt to changes in configuration for days, weeks, or even months, because of this design (described in [1]).

The lateness of this message is simply a consequence of the fact that our analyses have taken longer than we planned, and I do apologize for that.

Thanks,

Eric

[ 1 ] http://techreports.verisignlabs.com/tr-lookup.cgi?trid=1120005&rev=2

On Nov 30, 2012, at 10:38 AM, The IESG wrote:

> 
> The IESG has received a request from the Secure Inter-Domain Routing WG
> (sidr) to consider the following document:
> - 'Algorithm Agility Procedure for RPKI.'
>  <draft-ietf-sidr-algorithm-agility-08.txt> 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.
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

.


--------------040602060003040905000609-- From eosterweil@verisign.com Thu Dec 20 06:34: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 9892A21F88C1 for ; Thu, 20 Dec 2012 06:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.438 X-Spam-Level: X-Spam-Status: No, score=-4.438 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MANGLED_TOOL=2.3, 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 d+hEqYBO7BN8 for ; Thu, 20 Dec 2012 06:34:56 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 59E4621F88F1 for ; Thu, 20 Dec 2012 06:34:55 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUNMiDf9MRx/XpVO+hu4etx2bmY/+L4Cm@postini.com; Thu, 20 Dec 2012 06:34:55 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 qBKEYq3k031213; Thu, 20 Dec 2012 09:34:52 -0500 Received: from [10.100.0.14] ([10.100.0.14]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Dec 2012 09:34:51 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 20 Dec 2012 09:34:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@verisign.com> References: To: Randy Bush X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 20 Dec 2012 14:34:51.0400 (UTC) FILETIME=[2B870080:01CDDEBF] Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 14:34:56 -0000 On Dec 19, 2012, at 1:13 PM, Randy Bush wrote: > o there is a useful poster child for the need for O(minutes) rpki (or > perhaps just roa) propagation. as folk have repeatedly said, we > need concrete examples and goals. I really think these should feed requirements analysis too [1]. I think = there are a few other easy examples of this type of use case, but for = requirements, maybe we need just one good one? > o unfortunately, there is no internet technology today to completely, > accurately, and securely maintain a globally distributed database > (e.g. at every non-trivial pop) with time constraints on the order > of a minute. it's a research problem. and a *really* interesting > one. I feel _this_ is where a lot of our group's false-logic starts. This = (and similar) statement(s) assume that we must deploy a global = replicated state machine, which has a complete and coherent image of a = globally distributed set of resource holders' states, at all RPs at all = times in order for validation to succeed. Moreover, the state of this = global replicated state machine has no semantic for data authorities to = inform or influence the coherence of replicated data held by RPs (in = caches, etc). It is true that this model is mandated by the current = _design_, but I don't see that this is motivated by any real engineering = _requirement_. Why do we need to crawl all repos, for all resource = holders in order to route? What motivates _this_ as the only way to = accomplish routing security? In the spirit of sound engineering: since this aspect of BGPSEC is not = derived from a requirement, and it is limiting us from reaching other = required goals (see above), it ought to be reconsidered/thrown out. = afaik, RPKI+BGPSEC (note the BGPSEC part, not just RPKI) is something of = an outlier in the field of Internet-scale systems, in that it requires = everyone to have this full globally consistent cryptographic state = maintained reliably at all RPs. I point this out just to underscore the = notion that we should all be circumspect in our optimistic appraisals of = this design's operational viability. I feel this design element needs to be challenged, and if it cannot be = supported by requirement it should be removed from the design. Eric [1] http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html= From kotikalapudi.sriram@nist.gov Thu Dec 20 07:39: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 5486721F8932 for ; Thu, 20 Dec 2012 07:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 Yk6gzDwLE9Pk for ; Thu, 20 Dec 2012 07:39:10 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 41F0821F892F for ; Thu, 20 Dec 2012 07:39:10 -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.328.9; Thu, 20 Dec 2012 10:39:00 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 20 Dec 2012 10:39:07 -0500 From: "Sriram, Kotikalapudi" To: Shane Amante Date: Thu, 20 Dec 2012 10:39:06 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3ePuzO3GNddmA1TsKxyr7+b1S8gAAfHAs9 Message-ID: References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 15:39:11 -0000 > > FWIW, I disagree with your assertions, but am cutting to the chase, becau= se I think you're still failing to understand why/when it's not possible to= "spoof" the Victim's AS. > Sorry, I tried my best to try to understand your point but well =85 But thanks very much indeed for your patience. I guess this particular point ( i.e. why/when it's not possible to "spoof" = the Victim's AS)=20 needs some paper and pencil (or white board) discussion. Hopefully, we can do that when we meet in person (at NANOG in Feb?).=20 >> --snip--=20 > > There is no PE <-> CE eBGP session where one can originate the IP Prefix = from the "Victim AS". There is just this: > > ISP > Proxy-AS Victim IP prefix > AS1 > +------+ +-------------------------------------+ > | PE-1 |=3D=3D=3D=3D=3D=3D| Victim's L2 switches and/or servers | > +------+ +-------------------------------------+ > > ^ > | > +---- This is not a CE router > > On the router PE-1, in the ISP AS (AS1), I am originating a BGP announcem= ent for a _directly_connected_ prefix, where the victim's server/network/se= rvice is located. I am not aware of a capability in any implementation tha= t I'm familiar with where I can originate that directly connected IP prefix= for the Victim's network and have it appear to be from the Victim's Origin= al AS. When I originate an IP prefix on PE-1, the Origin-AS of that IP pre= fix is AS1, the "Proxy AS", not the "Victim's AS". Then again, perhaps I h= ave not looked hard enough at existing implementations ... Thanks for the nice figure and the explanation. But I think there is a way. I assume the ISP (Proxy AS) is the DDoS mitigator. Is the L2 connection (1) an existing business relationship between the two = parties, or=20 (2) is being established in emergency after the victim came under attack an= d=20 made a panic phone call to the DDoS mitigator (Proxy AS1)? If it is case (1), then a ROA can be created well in advance (of any emerge= ncy) permitting=20 the victim=92s prefix to be announced from AS1. Right? If it is case (2), then for what purpose is the L2 connection being set up?= =20 It appears to me that it is for the Proxy AS1 to channel the scrubbed traff= ic=20 back to the victim=92s network. True? So the question is, in case (2) how does Proxy AS1 inject a route into the = Internet=20 showing victim AS as the origin AS. The proxy AS1 already has a route for=20 the victim=92s prefix from updates it got from one or more of its (AS1=92s)= neighbors.=20 (Note that Proxy AS1 does not need to have a direct BGP peering with victim= AS=20 although it can establish one if needed over a multi-hop TCP, but we don=92= t need that here).=20 Let us say, the path that AS1 has for victim=92s AS (or prefix) is AS6 AS9 = AS2,=20 where AS2 is the victim=92s ASN and AS9 and AS6 are some ASes in the middle= .=20 All that the Proxy AS1 needs to do is modify the path and reduce it simply = to AS2.=20 This is a simple path modification (MITM). Pilosov-Kapela successfully demo= ed=20 a more complex BGP MITM back in 2008 on the live real Internet at Defcon.=20 By comparison, the path modification that the mitigator (proxy AS1) needs t= o do=20 seems feasible and simpler. Agree? =20 > >> >> The solution that Oliver and I suggested does not have any of the compli= cations >> that you mention above: >> http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html >> http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html >> The victim AS does not need to transfer any router keys to the proxy AS. >> Instead the victim AS provides a signed update (with pCount=3D0) to the >> proxy AS (by creating a BGPSEC peering session or by other suitable mean= s). > > Awesome. So, now we've got a recommendation to: > a) Spoof the Victim's Origin AS; and, The mitigator is *benevolently hijacking* the victim=92s prefix (or subpref= ix) today=20 to provide DDoS mitigation. Spoofing of victim=92s AS may be used in the sa= me vein,=20 keeping mitigator=92s update =93Valid=94 when origin-only-validation is in = use.=20 Your use of =93and,=94 above is incorrect. It should be =93or=94.=20 Spoofing the Victim's Origin AS is applicable in the origin-validation-only= case,=20 not but in the path validation case (i.e. BGPSEC). =20 > b) Use pCount =3D 0 to avoid validating the AS_PATH signatures Err=85 No. Where did you get that from? =20 pCount represents the AS prepend count (there is a pCount associated with e= ach AS). pCount =3D 0 (in BGPSEC) simply means that the corresponding ASN must not b= e=20 counted in the path length count. Verifying the path signatures is still a = must.=20 Recall that pCount =3D 0 was introduced originally to accommodate=20 transparent router servers (IXP). In the present case, pCount =3D 0 helps w= ith=20 not increasing the path length when victim=92s ASN is to be included in the= AS path.=20 But pCount =3D 1 can also be used if you don=92t care about the +1 incremen= t=20 to the path length of the Proxy AS=92s (mitigator=92s) announcement. =20 > I'm failing to see what the group is trying to accomplish here if these a= re the recommendations. One has to question what value there is in deployi= ng Origin Validation & BGPSEC if the answer when it can't accommodate a ope= rationally viable scenarios is to effectively "turn it off". With pCount =3D 0 misunderstanding removed, I hope you now see that the=20 proposed solution is not simplistic as you might have thought.=20 The proposed solution is helping the DDoS mitigator announce/propagate=20 the victim=92s prefix and stay =93Valid=94, while also avoiding having to c= reate/propagate=20 new RPKI objects in the emergency situation. That=92s the goal, right? =20 Sriram= From brweber2@yahoo.com Thu Dec 20 07:51: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 554E921F8B11 for ; Thu, 20 Dec 2012 07:51:06 -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 CZLGWdqY2vpZ for ; Thu, 20 Dec 2012 07:51:05 -0800 (PST) Received: from nm14-vm1.bullet.mail.ne1.yahoo.com (nm14-vm1.bullet.mail.ne1.yahoo.com [98.138.91.38]) by ietfa.amsl.com (Postfix) with ESMTP id E87B921F8A90 for ; Thu, 20 Dec 2012 07:51:04 -0800 (PST) Received: from [98.138.90.52] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 20 Dec 2012 15:50:50 -0000 Received: from [98.138.226.132] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 20 Dec 2012 15:50:50 -0000 Received: from [127.0.0.1] by smtp219.mail.ne1.yahoo.com with NNFMP; 20 Dec 2012 15:50:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356018650; bh=LYmyOs10Y6DVUqaCNL8oUR2rtrDqh45pujiXgtWdOPY=; 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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=t1awNs7cdVMuVyvz1hWjapOV4HJAVqfjwBibv2cHmX8U2DdKir9+gc23RbwGTAlDIterZP5t+7SyTvWL6NJAqDw/xdT8r09tH8kas9EGyn4Crnm9m5KU7zp0fbgq+sGWCMViIegMbpQ4Wuu9680XusxIQdT8ZVXG9EmDkOcoEOI= X-Yahoo-Newman-Id: 277023.96511.bm@smtp219.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: iUT._yoVM1ngBZfcZzJUa6rlLpKnc8uIxT3OEDLcdbI0MsJ xR_J3bYsaKK1ycfomh8wONY30ILWgSRX_6wyHPdCyxOuOH5H0zezXR.2wjrW uLler6A4rz1WuFfZlfxQTBpz5a1W6REftHLON9X4nDHB0.0lQPXnBnK_EsU5 fZ6VpJu9oTP1yMjYnard9YgQ3JCVokDz4NJlDEvMRajBAdVdJ72pQC7IGgfQ lPnPBBrB0lhZz0p6mPhZ4ioL9iBepAbultda5PO0hg4nL2cuKQvFYDysiOaU m6DwrnVCg12X8ySt9N8fPBATvU1LbG_dvFXyZSvWG_zamo56ryxLpwNhyzmQ _ZAi1_l2I_P0PaSeUldIMYf62D8JIySGRyjiIxScj3ySUUEGU3uk_NRHYzuc HiWQwo6u.FemQHxf8kk58_qoz1jac4CyjpBPc_uqgoqQhjNu2TvojaAAoJF4 PBGmz2ro- X-Yahoo-SMTP: f4ZrQXCswBB5jGYwSTd4wDs0ZJPe Received: from [192.168.1.11] (brweber2@68.100.90.3 with plain) by smtp219.mail.ne1.yahoo.com with SMTP; 20 Dec 2012 07:50:50 -0800 PST Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Bryan Weber In-Reply-To: Date: Thu, 20 Dec 2012 10:50:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4475CDA3-9B6F-449B-874A-C6C1C830E4DF@yahoo.com> References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1499) Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 15:51:07 -0000 I agree with your comment about a conversation at Nanog in February, = sounds like a great idea. Comments inline below. Thanks, Bryan On Dec 20, 2012, at 10:39 AM, "Sriram, Kotikalapudi" = wrote: >>=20 >> FWIW, I disagree with your assertions, but am cutting to the chase, = because I think you're still failing to understand why/when it's not = possible to "spoof" the Victim's AS. >>=20 >=20 > Sorry, I tried my best to try to understand your point but well =85 > But thanks very much indeed for your patience. > I guess this particular point ( i.e. why/when it's not possible to = "spoof" the Victim's AS)=20 > needs some paper and pencil (or white board) discussion. > Hopefully, we can do that when we meet in person (at NANOG in Feb?).=20= >=20 >>>=20 > --snip--=20 >>=20 >> There is no PE <-> CE eBGP session where one can originate the IP = Prefix from the "Victim AS". There is just this: >>=20 >> ISP >> Proxy-AS Victim IP prefix >> AS1 >> +------+ +-------------------------------------+ >> | PE-1 |=3D=3D=3D=3D=3D=3D| Victim's L2 switches and/or servers | >> +------+ +-------------------------------------+ >>=20 >> ^ >> | >> +---- This is not a CE router >>=20 >> On the router PE-1, in the ISP AS (AS1), I am originating a BGP = announcement for a _directly_connected_ prefix, where the victim's = server/network/service is located. I am not aware of a capability in = any implementation that I'm familiar with where I can originate that = directly connected IP prefix for the Victim's network and have it appear = to be from the Victim's Original AS. When I originate an IP prefix on = PE-1, the Origin-AS of that IP prefix is AS1, the "Proxy AS", not the = "Victim's AS". Then again, perhaps I have not looked hard enough at = existing implementations ... >=20 > Thanks for the nice figure and the explanation. But I think there is a = way. > I assume the ISP (Proxy AS) is the DDoS mitigator. > Is the L2 connection (1) an existing business relationship between the = two parties, or=20 > (2) is being established in emergency after the victim came under = attack and=20 > made a panic phone call to the DDoS mitigator (Proxy AS1)? >=20 > If it is case (1), then a ROA can be created well in advance (of any = emergency) permitting=20 > the victim=92s prefix to be announced from AS1. Right? >=20 > If it is case (2), then for what purpose is the L2 connection being = set up?=20 > It appears to me that it is for the Proxy AS1 to channel the scrubbed = traffic=20 > back to the victim=92s network. True? >=20 > So the question is, in case (2) how does Proxy AS1 inject a route into = the Internet=20 > showing victim AS as the origin AS. The proxy AS1 already has a route = for=20 > the victim=92s prefix from updates it got from one or more of its = (AS1=92s) neighbors.=20 > (Note that Proxy AS1 does not need to have a direct BGP peering with = victim AS=20 > although it can establish one if needed over a multi-hop TCP, but we = don=92t need that here).=20 > Let us say, the path that AS1 has for victim=92s AS (or prefix) is AS6 = AS9 AS2,=20 > where AS2 is the victim=92s ASN and AS9 and AS6 are some ASes in the = middle.=20 > All that the Proxy AS1 needs to do is modify the path and reduce it = simply to AS2.=20 > This is a simple path modification (MITM). Pilosov-Kapela successfully = demoed=20 > a more complex BGP MITM back in 2008 on the live real Internet at = Defcon.=20 > By comparison, the path modification that the mitigator (proxy AS1) = needs to do=20 > seems feasible and simpler. Agree? >=20 Sure, but isn't Eric's point that there is no ROA in this case (#2) and = if propagation times are too large (days or weeks) then it doesn't = really help with the DDoS mitigation? I am also curious about AS's that are direct peers of AS2. They might = not necessarily select the mitigating AS because they are also one hop = away and the tie breaking criteria will be used, no? >>=20 >>>=20 >>> The solution that Oliver and I suggested does not have any of the = complications >>> that you mention above: >>> http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html >>> http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html >>> The victim AS does not need to transfer any router keys to the proxy = AS. >>> Instead the victim AS provides a signed update (with pCount=3D0) to = the >>> proxy AS (by creating a BGPSEC peering session or by other suitable = means). >>=20 >> Awesome. So, now we've got a recommendation to: >> a) Spoof the Victim's Origin AS; and, >=20 > The mitigator is *benevolently hijacking* the victim=92s prefix (or = subprefix) today=20 > to provide DDoS mitigation. Spoofing of victim=92s AS may be used in = the same vein,=20 > keeping mitigator=92s update =93Valid=94 when origin-only-validation = is in use.=20 >=20 > Your use of =93and,=94 above is incorrect. It should be =93or=94.=20 > Spoofing the Victim's Origin AS is applicable in the = origin-validation-only case,=20 > not but in the path validation case (i.e. BGPSEC). >=20 >> b) Use pCount =3D 0 to avoid validating the AS_PATH signatures >=20 > Err=85 No. Where did you get that from? =20 > pCount represents the AS prepend count (there is a pCount associated = with each AS). > pCount =3D 0 (in BGPSEC) simply means that the corresponding ASN must = not be=20 > counted in the path length count. Verifying the path signatures is = still a must.=20 > Recall that pCount =3D 0 was introduced originally to accommodate=20 > transparent router servers (IXP). In the present case, pCount =3D 0 = helps with=20 > not increasing the path length when victim=92s ASN is to be included = in the AS path.=20 > But pCount =3D 1 can also be used if you don=92t care about the +1 = increment=20 > to the path length of the Proxy AS=92s (mitigator=92s) announcement. >=20 >> I'm failing to see what the group is trying to accomplish here if = these are the recommendations. One has to question what value there is = in deploying Origin Validation & BGPSEC if the answer when it can't = accommodate a operationally viable scenarios is to effectively "turn it = off". >=20 > With pCount =3D 0 misunderstanding removed, I hope you now see that = the=20 > proposed solution is not simplistic as you might have thought.=20 > The proposed solution is helping the DDoS mitigator announce/propagate=20= > the victim=92s prefix and stay =93Valid=94, while also avoiding having = to create/propagate=20 > new RPKI objects in the emergency situation. That=92s the goal, right? >=20 > Sriram > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From brweber2@yahoo.com Thu Dec 20 07:55: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 B761021F888F for ; Thu, 20 Dec 2012 07:55:18 -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 ufWRUhfIH-T1 for ; Thu, 20 Dec 2012 07:55:16 -0800 (PST) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4C21F8BB3 for ; Thu, 20 Dec 2012 07:55:14 -0800 (PST) Received: from [98.139.212.144] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2012 15:55:14 -0000 Received: from [98.139.213.14] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 20 Dec 2012 15:55:14 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 20 Dec 2012 15:55:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356018914; bh=dQ3Hqek/nVk5rEXska+s9XMhLlzY1q32YoymAbLknLc=; 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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=VGnwRXF6c0unekp1g/edyIsz9vwfPGJXfMLwbl4DnZf0gPl/JwBykp/p1Io6VEq4Xb40rV4Q/t6PYoHUAm9oxGXoE9IYemXh/lTF4nNtKHYr//ENkO8S++flUD6zXjsNE4T8mGl/pHn8fh/otA8VE6zXm2CenSaagZe2y147FDg= X-Yahoo-Newman-Id: 105724.42030.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: O65H3zkVM1k9bsqtl6Y34WAvZPQ_ObQ8O85Hlydw1mQnE9n lz6Ok5MEc0DkJD_j6VEPQai9rvMYLXbRl2W9cwGkUX_R0jpwGq2j0egwurn7 JPN7SF1gMI6fVmPWxtn.RROLizzs.kxW6ehgG5SE6DodVzGX8xQbZihKYvIE xYjfkXZL1Ur_K2QK7u1WtZ6YLrxzzkwX2RGYEI0jkAoCGKBRG8_uv.ywep2U cjCJFOyv0r3hDBzs4Fc4UiEG.QtMQ46YPyBSqfQb58uSiX6KALWIOJJDDDk2 uUl_ErvksBL9VpFB9Z8JbZHiubU7WAWePrGgv0pU0MxGsxES81ieIr06nUaX aIz4uuO7NMgPv976S3yqJQaRO.bhMzU389UQCDiTQPALEjTPqo7Hv67hiQxZ 4hBHakvsObqBA8oYeOCt3v8OpMlBuNVh46UXAXxwtA6Va6hQr2Ca.c7zgwwo STBhKydID X-Yahoo-SMTP: f4ZrQXCswBB5jGYwSTd4wDs0ZJPe Received: from [192.168.1.11] (brweber2@68.100.90.3 with plain) by smtp114.mail.bf1.yahoo.com with SMTP; 20 Dec 2012 07:55:13 -0800 PST Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Bryan Weber In-Reply-To: <4475CDA3-9B6F-449B-874A-C6C1C830E4DF@yahoo.com> Date: Thu, 20 Dec 2012 10:55:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4CFDE89C-394C-48B8-9A48-B597890B6061@yahoo.com> References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> , <4475CDA3-9B6F-449B-874A-C6C1C830E4DF@yahoo.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1499) Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 15:55:19 -0000 Excuse me. I misunderstood. In either case, the prefix originates out of = AS2 so the existing ROA would be valid and you would just have to worry = about tie breaking factors anywhere that the AS path length was 2. Thanks, Bryan On Dec 20, 2012, at 10:50 AM, Bryan Weber wrote: > I agree with your comment about a conversation at Nanog in February, = sounds like a great idea. >=20 > Comments inline below. >=20 > Thanks, > Bryan >=20 >=20 > On Dec 20, 2012, at 10:39 AM, "Sriram, Kotikalapudi" = wrote: >=20 >>>=20 >>> FWIW, I disagree with your assertions, but am cutting to the chase, = because I think you're still failing to understand why/when it's not = possible to "spoof" the Victim's AS. >>>=20 >>=20 >> Sorry, I tried my best to try to understand your point but well =85 >> But thanks very much indeed for your patience. >> I guess this particular point ( i.e. why/when it's not possible to = "spoof" the Victim's AS)=20 >> needs some paper and pencil (or white board) discussion. >> Hopefully, we can do that when we meet in person (at NANOG in Feb?).=20= >>=20 >>>>=20 >> --snip--=20 >>>=20 >>> There is no PE <-> CE eBGP session where one can originate the IP = Prefix from the "Victim AS". There is just this: >>>=20 >>> ISP >>> Proxy-AS Victim IP prefix >>> AS1 >>> +------+ +-------------------------------------+ >>> | PE-1 |=3D=3D=3D=3D=3D=3D| Victim's L2 switches and/or servers | >>> +------+ +-------------------------------------+ >>>=20 >>> ^ >>> | >>> +---- This is not a CE router >>>=20 >>> On the router PE-1, in the ISP AS (AS1), I am originating a BGP = announcement for a _directly_connected_ prefix, where the victim's = server/network/service is located. I am not aware of a capability in = any implementation that I'm familiar with where I can originate that = directly connected IP prefix for the Victim's network and have it appear = to be from the Victim's Original AS. When I originate an IP prefix on = PE-1, the Origin-AS of that IP prefix is AS1, the "Proxy AS", not the = "Victim's AS". Then again, perhaps I have not looked hard enough at = existing implementations ... >>=20 >> Thanks for the nice figure and the explanation. But I think there is = a way. >> I assume the ISP (Proxy AS) is the DDoS mitigator. >> Is the L2 connection (1) an existing business relationship between = the two parties, or=20 >> (2) is being established in emergency after the victim came under = attack and=20 >> made a panic phone call to the DDoS mitigator (Proxy AS1)? >>=20 >> If it is case (1), then a ROA can be created well in advance (of any = emergency) permitting=20 >> the victim=92s prefix to be announced from AS1. Right? >>=20 >> If it is case (2), then for what purpose is the L2 connection being = set up?=20 >> It appears to me that it is for the Proxy AS1 to channel the scrubbed = traffic=20 >> back to the victim=92s network. True? >>=20 >> So the question is, in case (2) how does Proxy AS1 inject a route = into the Internet=20 >> showing victim AS as the origin AS. The proxy AS1 already has a route = for=20 >> the victim=92s prefix from updates it got from one or more of its = (AS1=92s) neighbors.=20 >> (Note that Proxy AS1 does not need to have a direct BGP peering with = victim AS=20 >> although it can establish one if needed over a multi-hop TCP, but we = don=92t need that here).=20 >> Let us say, the path that AS1 has for victim=92s AS (or prefix) is = AS6 AS9 AS2,=20 >> where AS2 is the victim=92s ASN and AS9 and AS6 are some ASes in the = middle.=20 >> All that the Proxy AS1 needs to do is modify the path and reduce it = simply to AS2.=20 >> This is a simple path modification (MITM). Pilosov-Kapela = successfully demoed=20 >> a more complex BGP MITM back in 2008 on the live real Internet at = Defcon.=20 >> By comparison, the path modification that the mitigator (proxy AS1) = needs to do=20 >> seems feasible and simpler. Agree? >>=20 >=20 > Sure, but isn't Eric's point that there is no ROA in this case (#2) = and if propagation times are too large (days or weeks) then it doesn't = really help with the DDoS mitigation? >=20 > I am also curious about AS's that are direct peers of AS2. They might = not necessarily select the mitigating AS because they are also one hop = away and the tie breaking criteria will be used, no? >=20 >=20 >>>=20 >>>>=20 >>>> The solution that Oliver and I suggested does not have any of the = complications >>>> that you mention above: >>>> http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html >>>> http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html >>>> The victim AS does not need to transfer any router keys to the = proxy AS. >>>> Instead the victim AS provides a signed update (with pCount=3D0) to = the >>>> proxy AS (by creating a BGPSEC peering session or by other suitable = means). >>>=20 >>> Awesome. So, now we've got a recommendation to: >>> a) Spoof the Victim's Origin AS; and, >>=20 >> The mitigator is *benevolently hijacking* the victim=92s prefix (or = subprefix) today=20 >> to provide DDoS mitigation. Spoofing of victim=92s AS may be used in = the same vein,=20 >> keeping mitigator=92s update =93Valid=94 when origin-only-validation = is in use.=20 >>=20 >> Your use of =93and,=94 above is incorrect. It should be =93or=94.=20 >> Spoofing the Victim's Origin AS is applicable in the = origin-validation-only case,=20 >> not but in the path validation case (i.e. BGPSEC). >>=20 >>> b) Use pCount =3D 0 to avoid validating the AS_PATH signatures >>=20 >> Err=85 No. Where did you get that from? =20 >> pCount represents the AS prepend count (there is a pCount associated = with each AS). >> pCount =3D 0 (in BGPSEC) simply means that the corresponding ASN must = not be=20 >> counted in the path length count. Verifying the path signatures is = still a must.=20 >> Recall that pCount =3D 0 was introduced originally to accommodate=20 >> transparent router servers (IXP). In the present case, pCount =3D 0 = helps with=20 >> not increasing the path length when victim=92s ASN is to be included = in the AS path.=20 >> But pCount =3D 1 can also be used if you don=92t care about the +1 = increment=20 >> to the path length of the Proxy AS=92s (mitigator=92s) announcement. >>=20 >>> I'm failing to see what the group is trying to accomplish here if = these are the recommendations. One has to question what value there is = in deploying Origin Validation & BGPSEC if the answer when it can't = accommodate a operationally viable scenarios is to effectively "turn it = off". >>=20 >> With pCount =3D 0 misunderstanding removed, I hope you now see that = the=20 >> proposed solution is not simplistic as you might have thought.=20 >> The proposed solution is helping the DDoS mitigator = announce/propagate=20 >> the victim=92s prefix and stay =93Valid=94, while also avoiding = having to create/propagate=20 >> new RPKI objects in the emergency situation. That=92s the goal, = right? >>=20 >> Sriram >> _______________________________________________ >> 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 randy@psg.com Thu Dec 20 08:03: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 AF04821F84F1 for ; Thu, 20 Dec 2012 08:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=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 bYodx5iFeqvS for ; Thu, 20 Dec 2012 08:03:53 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4A23721F85D0 for ; Thu, 20 Dec 2012 08:03:53 -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 1TlibA-000Jgd-Mt; Thu, 20 Dec 2012 16:03:52 +0000 Date: Thu, 20 Dec 2012 11:03:52 -0500 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@verisign.com> References: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@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 speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 16:03:53 -0000 > I feel _this_ is where a lot of our group's false-logic starts. This > (and similar) statement(s) assume that we must deploy a global > replicated state machine, which has a complete and coherent image of a > globally distributed set of resource holders' states, at all RPs at > all times in order for validation to succeed. Moreover, the state of > this global replicated state machine has no semantic for data > authorities to inform or influence the coherence of replicated data > held by RPs (in caches, etc). It is true that this model is mandated > by the current _design_, but I don't see that this is motivated by any > real engineering _requirement_. Why do we need to crawl all repos, > for all resource holders in order to route? What motivates _this_ as > the only way to accomplish routing security? > > In the spirit of sound engineering: since this aspect of BGPSEC is not > derived from a requirement, and it is limiting us from reaching other > required goals (see above), it ought to be reconsidered/thrown out. > afaik, RPKI+BGPSEC (note the BGPSEC part, not just RPKI) is something > of an outlier in the field of Internet-scale systems, in that it > requires everyone to have this full globally consistent cryptographic > state maintained reliably at all RPs. I point this out just to > underscore the notion that we should all be circumspect in our > optimistic appraisals of this design's operational viability. > > I feel this design element needs to be challenged, and if it cannot be > supported by requirement it should be removed from the design. bgpsec+rpki does not have the highly globally synced requirement. your application does. you are tryin to add the requirement. i agree with you that it should not be added. thanks for understanding. randy From eosterweil@verisign.com Thu Dec 20 08:19: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 5F2BC21F8990 for ; Thu, 20 Dec 2012 08:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, J_CHICKENPOX_64=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 Kn3Fbgo-9MZ2 for ; Thu, 20 Dec 2012 08:19:49 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 82D2C21F8936 for ; Thu, 20 Dec 2012 08:19:49 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUNM6o+XxGNxy67B38iQo0iq1a4Aw21Y3@postini.com; Thu, 20 Dec 2012 08:19:49 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 qBKGJil3002261; Thu, 20 Dec 2012 11:19:47 -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); Thu, 20 Dec 2012 11:19:44 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 20 Dec 2012 11:19:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <96A2541E-9497-44EF-86F8-2958E21DE465@verisign.com> References: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@verisign.com> To: Randy Bush X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 20 Dec 2012 16:19:44.0485 (UTC) FILETIME=[D27F9150:01CDDECD] Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 16:19:50 -0000 On Dec 20, 2012, at 11:03 AM, Randy Bush wrote: > bgpsec+rpki does not have the highly globally synced requirement. =20 So, in bgpsec, you (as an RP) don't need to know ROAs a priori in order = to validate routes as they arrive in updates? > your > application does. you are tryin to add the requirement. i agree with > you that it should not be added. =20 bgpsec (as currently outlined in the requirement-free draft) implicitly = requires full replication of the rpki in order to make correct routing = decisions. _That_ system has this flaw, but I don't claim to own it. ;) > thanks for understanding. Clever! :-P Eric= From randy@psg.com Thu Dec 20 08:30: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 26F0621F8634 for ; Thu, 20 Dec 2012 08:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_64=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 ElBLQM75x9aW for ; Thu, 20 Dec 2012 08:30:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C049821F8586 for ; Thu, 20 Dec 2012 08:30:20 -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 1Tlj0W-000JyB-0Q; Thu, 20 Dec 2012 16:30:04 +0000 Date: Thu, 20 Dec 2012 11:30:03 -0500 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: <96A2541E-9497-44EF-86F8-2958E21DE465@verisign.com> References: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@verisign.com> <96A2541E-9497-44EF-86F8-2958E21DE465@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 speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 16:30:21 -0000 >> bgpsec+rpki does not have the highly globally synced requirement. > So, in bgpsec, you (as an RP) don't need to know ROAs a priori in > order to validate routes as they arrive in updates? see "highly synched" above. as a rp, an hour or three loose synch is fine. > bgpsec (as currently outlined in the requirement-free draft) damn! and i thought i had writted a reqs draft, which does need updating. let's try to limit the slinging. and your problem is with origin validation as currntly implemented and deployed. it ain't bgpsec. > implicitly requires full replication of the rpki in order to make > correct routing decisions. diff between loose time constraint and what is replicated. > _That_ system has this flaw, but I don't claim to own it. ;) are you willing to rent it out? :) you have a product which places a currently unachievable time constrains on pretty much any mechanism which provides prefix origination security. randy, heading for more airports From arturo.servin@gmail.com Thu Dec 20 08:36: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 5484321F8843 for ; Thu, 20 Dec 2012 08:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_64=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 2ME8ZigLU-ak for ; Thu, 20 Dec 2012 08:36:58 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0CE21F86B4 for ; Thu, 20 Dec 2012 08:36:50 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id cr7so5456909qab.16 for ; Thu, 20 Dec 2012 08:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=F8iLdCHR/nQNA1WCQwSF4CpMs24/5jfxrF0sa3aeeDw=; b=zE8J12s11wmVdCRzUmyxWTfCMspcFiN2c9SV6i5xq0VBzQ+HrTivqiifCqwPJLtyYJ LMtJdjNTpLWzEx/tlab1PXpZ/wkwlL96UGb8DUbuAQRpftmRqDrUraL5LOSDc30i143x XEEaQnpBcsyyABG+2L/EPHSDON3GuTIR4eE2dI5brf1eN2JaXKiyHC1LP3g6OVag825B 6e6/lFR008/L/JkS3s9punobnZzvhX6KU9e7IxZc+UMW18jr8z8/ui0zWHn38lSeGLqg SN9BgeJfeZiV5zuzVGh0aW56ZhiDJYQAo0tgM61kIs3Ap091963KOZBbetqxHnC9bHg1 xBDw== X-Received: by 10.224.185.141 with SMTP id co13mr4923839qab.33.1356021409529; Thu, 20 Dec 2012 08:36:49 -0800 (PST) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:a5b7:528c:af5e:c3f0]) by mx.google.com with ESMTPS id cy2sm1549867qeb.9.2012.12.20.08.36.46 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 08:36:48 -0800 (PST) Message-ID: <50D33E9B.6000606@gmail.com> Date: Thu, 20 Dec 2012 14:36:43 -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: sidr@ietf.org References: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@verisign.com> <96A2541E-9497-44EF-86F8-2958E21DE465@verisign.com> In-Reply-To: <96A2541E-9497-44EF-86F8-2958E21DE465@verisign.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 16:36:59 -0000 On 20/12/2012 14:19, Eric Osterweil wrote: > On Dec 20, 2012, at 11:03 AM, Randy Bush wrote: > >> > bgpsec+rpki does not have the highly globally synced requirement. > So, in bgpsec, you (as an RP) don't need to know ROAs a priori in order to validate routes as they arrive in updates? > Your RP does, but you do not need all the RPs to have it in order to rpki+bgpsec to work. /as From kotikalapudi.sriram@nist.gov Thu Dec 20 08:42: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 D37CF21F892D for ; Thu, 20 Dec 2012 08:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 kI90mj6DLvSb for ; Thu, 20 Dec 2012 08:42:18 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A03E121F8923 for ; Thu, 20 Dec 2012 08:42:12 -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.328.9; Thu, 20 Dec 2012 11:42:05 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 20 Dec 2012 11:42:07 -0500 From: "Sriram, Kotikalapudi" To: Bryan Weber Date: Thu, 20 Dec 2012 11:42:06 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3eymc5M/bjXR12RbKjzKQm+Gz8BAAAfzzN Message-ID: References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> , <4475CDA3-9B6F-449B-874A-C6C1C830E4DF@yahoo.com>, <4CFDE89C-394C-48B8-9A48-B597890B6061@yahoo.com> In-Reply-To: <4CFDE89C-394C-48B8-9A48-B597890B6061@yahoo.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 Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 16:42:21 -0000 >Excuse me. I misunderstood. In either case, the prefix originates out of AS2 so the existing ROA would be valid and you would just have to worry about tie breaking factors anywhere that the AS path length was 2. That is right about case (#2) -- the case that we are more interested in. But in my more mundane case (#1), it is an existing (long term) business relationship between the two parties. So a 2nd ROA can be created proactively for the Proxy AS (AS1). > > I agree with your comment about a conversation at Nanog in February, sounds like a great idea. Sure, thanks. I'll look forward to it. > Sure, but isn't Eric's point that there is no ROA in this case (#2) and if propagation times are too large (days or weeks) then it doesn't really help with the DDoS mitigation? As you have acknowledged already, the RPKI propagation delays do not come into picture for the proposal we are examining. Just as an aside, you may take a look at my estimates/comments also about the RPKI delays: http://www.nist.gov/itl/antd/upload/rpki-rsync-delay-technote.pdf Sriram From eosterweil@verisign.com Thu Dec 20 08:45: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 ECE4A21F8923 for ; Thu, 20 Dec 2012 08:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.575 X-Spam-Level: X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, J_CHICKENPOX_64=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 VoJQu4nNRsaE for ; Thu, 20 Dec 2012 08:45:29 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id E85FE21F88C5 for ; Thu, 20 Dec 2012 08:45:28 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUNNAqMl1x/eoacImB02lvvKp5gR5Ao2B@postini.com; Thu, 20 Dec 2012 08:45:29 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 qBKGjOWT003057; Thu, 20 Dec 2012 11:45:27 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Dec 2012 11:45:24 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 20 Dec 2012 11:45:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <423585F6-ADE8-4895-86FE-2BA48C762989@verisign.com> References: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@verisign.com> <96A2541E-9497-44EF-86F8-2958E21DE465@verisign.com> To: Randy Bush X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 20 Dec 2012 16:45:24.0144 (UTC) FILETIME=[6834E300:01CDDED1] Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 16:45:30 -0000 On Dec 20, 2012, at 11:30 AM, Randy Bush wrote: >>> bgpsec+rpki does not have the highly globally synced requirement. =20= >> So, in bgpsec, you (as an RP) don't need to know ROAs a priori in >> order to validate routes as they arrive in updates? >=20 > see "highly synched" above. as a rp, an hour or three loose synch is > fine. No, you've got that wrong again. In order for the system that _you_ = designed to meet the requirements of those who are using and operating = the Internet, it must be able to perform faster than your design can = realistically manage. That's a design flaw that came from ignoring = requirements analysis. >> bgpsec (as currently outlined in the requirement-free draft) >=20 > damn! and i thought i had writted a reqs draft, which does need > updating. =20 Well, afaict, the requirements in your draft have not been accepted by = the group, in general. Therefore, the fact that you have a reqs draft, = does not mean the designs in the other drafts meet the group's = requirements. You can't just write reqs and run away if you want people = to take them seriously. ;) > let's try to limit the slinging. Gotcha... Stay focused on engineering. Ack... > and your problem is with origin validation as currntly implemented and > deployed. it ain't bgpsec. Umm... what? Right now, what's deployed ain't bgpsec... What = implementation are you talking about? >> implicitly requires full replication of the rpki in order to make >> correct routing decisions. >=20 > diff between loose time constraint and what is replicated. There is a requirement of data freshness. It is not realistic = _in_your_design_. That makes your design a poor fit, and we need = another approach. >> _That_ system has this flaw, but I don't claim to own it. ;) >=20 > are you willing to rent it out? :) I'm confused... Are you ``slinging'' here? So, that's back on again? = kewl... ;) > you have a product which places a currently unachievable time = constrains > on pretty much any mechanism which provides prefix origination = security. No no no... Sorry Randy, that's not how engineering works... You see, = we have a requirement... If your suggested design cannot meet it, we = need to go from _there_ (your design cannot meet a requirement). Your = assumption that it is ``unachievable'' is silly. Have you explored the = _entire_ solution space? Have you gotten consensus on what problem(s) = we are even solving here? No, you haven't. As an engineer, ymbk... > randy, heading for more airports gtk, Eric= From aservin@lacnic.net Thu Dec 20 09:00: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 5ABFE21F88C1 for ; Thu, 20 Dec 2012 09:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 teBG3nd1qD0n for ; Thu, 20 Dec 2012 08:59:54 -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 74AB221F859A for ; Thu, 20 Dec 2012 08:59:54 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.161]) by mail.lacnic.net.uy (Postfix) with ESMTP id D805F308432 for ; Thu, 20 Dec 2012 14:59:48 -0200 (UYST) Message-ID: <50D34405.8080807@lacnic.net> Date: Thu, 20 Dec 2012 14:59:49 -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: sidr@ietf.org References: <487F9F23-F609-48A2-BE67-6361291BDFCF@ripe.net> In-Reply-To: <487F9F23-F609-48A2-BE67-6361291BDFCF@ripe.net> X-Enigmail-Version: 1.4.6 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] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 17:00:00 -0000 I keep hearing: "this is not fast enough" "we have a requirement to make it faster" etc. But nobody has answered Tim: "> I would really like to echo Chris's last paragraph here. What do you >think is a reasonable time to propagate from an operator editing the >RPKI (A) -> 99.9% of Bs? > > I understand that half a day is way too long. Instantaneous is >theoretically impossible when BGP and RPKI are separate. But is there >really no reasonable pragmatic indication of what would be 'good >enough' for the real world? E.g. if we can come up with a structure >that enables repositories to support 100k RP tools ('B', assuming 2 >gatherers per ASN) getting their *updates* (full dump separate thread >please) every 10 minutes, is that good enough? > So, instead of continuing a futile discussion, why not better start working on a workable requirement? I have read in this list some interesting approaches to make the repositories more reliable and giving a reasonable indication of your expectations as operators I think it would be a good start. /as On 19/12/2012 14:22, Tim Bruijnzeels wrote: > Hi Danny, WG, > > People have mentioned that if the security was somehow part of the updates themselves, then you could have security at the speed of updates. I don't see how this could work, it would have to be a completely different set of standards from what's currently being worked on. Most likely this would result in lots of cycles on routers, but without any concrete proposals on this there really isn't much more I can sensibly say about this approach here.. > > So for the sake of argument let me just stick to the model that we have now where the RPKI is an external system, separate from the BGP updates. > > This means that when operators make changes in BGP, they will also need to edit part of the RPKI. > > Chris described a path from roa (or any rpki object) creator to consumer: > > On Dec 18, 2012, at 10:52 PM, Christopher Morrow wrote: >> The architecture as laid out is, from 'roa creator' to 'roa consumer', roughly: >> A publication point (nominally one per roa-creator) >> B gatherers (nominally one per roa-consumer) >> C internal-cache-systems (some number per roa-consumer) >> D routers > > Strictly speaking there is a step before A: creating the new objects. Dependent on the system (and especially if a remote pub server is used) there may be a short delay before the objects are actually published. > > But the basic model is right in my opinion. So following Chris's line of thought: >> (yes, there is the iana->rir part of the tree >> yes, there are are more than just ROAs in the repositories) >> >> So, the part that Randy and Danny and Eric are talking about is, as >> far as the global system, is the A -> B conversation. Once you get >> beyond B (to C and D) the problem is entirely inside some operator's >> network and nothing on the outside matters. >> >> Essentially the problem here is distribution of 10k of data to ~40k >> endpoints (today, it'll grow tomorrow, fine) in ~2 mins time (or 5 >> mins or 10 mins or ... someone draw a line in the sand so we know what >> the target is) > > > I would really like to echo Chris's last paragraph here. What do you think is a reasonable time to propagate from an operator editing the RPKI (A) -> 99.9% of Bs? > > I understand that half a day is way too long. Instantaneous is theoretically impossible when BGP and RPKI are separate. But is there really no reasonable pragmatic indication of what would be 'good enough' for the real world? E.g. if we can come up with a structure that enables repositories to support 100k RP tools ('B', assuming 2 gatherers per ASN) getting their *updates* (full dump separate thread please) every 10 minutes, is that good enough? > > > Cheers > Tim > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From eosterweil@verisign.com Thu Dec 20 09:35: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 C182221F8A42 for ; Thu, 20 Dec 2012 09:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.707, 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 KjZG5qzYHODP for ; Thu, 20 Dec 2012 09:35:53 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id DA84921F89A6 for ; Thu, 20 Dec 2012 09:35:49 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKUNNMdfsSbMMuZTviBk1KhGt1FcDTsPOU@postini.com; Thu, 20 Dec 2012 09:35:53 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 qBKHZkLV004570; Thu, 20 Dec 2012 12:35:46 -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); Thu, 20 Dec 2012 12:35:45 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50D34405.8080807@lacnic.net> Date: Thu, 20 Dec 2012 12:35:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <22421E49-82E5-4BEE-A3E3-BEE6C8BFEA3C@verisign.com> References: <487F9F23-F609-48A2-BE67-6361291BDFCF@ripe.net> <50D34405.8080807@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 20 Dec 2012 17:35:45.0758 (UTC) FILETIME=[713A97E0:01CDDED8] Cc: sidr@ietf.org Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 17:35:53 -0000 On Dec 20, 2012, at 11:59 AM, Arturo Servin wrote: > "> I would really like to echo Chris's last paragraph here. What do = you >> think is a reasonable time to propagate from an operator editing the >> RPKI (A) -> 99.9% of Bs? >>=20 >> I understand that half a day is way too long. Instantaneous is >> theoretically impossible when BGP and RPKI are separate. But is there >> really no reasonable pragmatic indication of what would be 'good >> enough' for the real world? E.g. if we can come up with a structure >> that enables repositories to support 100k RP tools ('B', assuming 2 >> gatherers per ASN) getting their *updates* (full dump separate thread >> please) every 10 minutes, is that good enough? >>=20 >=20 > So, instead of continuing a futile discussion, why not better = start > working on a workable requirement? I think a number of us in this ``futile'' argument have been pushing = pretty hard to start (or some may claim revive) the requirements = process. The very fact that we are even talking about freshness and = liveliness of data is a result of a few of us having to = request/re-request/write drafts/do formal analysis on existing = measurement/swrite tech notes/re-request again/etc. imho, the only = reason anyone is _now_ saying, ``half a day is way too long'' is because = it has taken this long to get traction from the group. My 0.02 about the above is that the first part of Tim's para talks about = finding a requirement, but the 2nd part presumes the existence of a = design (repos and structures)... Let's talk about requirements first. = If we need use cases and threat models before that, then let's go = _there_ first, and then on to requirements. I feel like your comments = above take for granted the fact that several of us have had to work very = hard to get to this stage. Eric= From eosterweil@verisign.com Thu Dec 20 09:38: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 4760421F8945 for ; Thu, 20 Dec 2012 09:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_64=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 xHoUFTqsuDXu for ; Thu, 20 Dec 2012 09:38:05 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id ED6D621F8939 for ; Thu, 20 Dec 2012 09:38:03 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUNNM+pLcN78K3A+nrah33mm3AcWeVLbh@postini.com; Thu, 20 Dec 2012 09:38:04 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 qBKHc28p004633; Thu, 20 Dec 2012 12:38:02 -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); Thu, 20 Dec 2012 12:38:01 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50D33E9B.6000606@gmail.com> Date: Thu, 20 Dec 2012 12:38:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <70B45046-E3C3-4DB0-B539-E209DF4845A8@verisign.com> References: <87C4782F-89FE-496D-A91D-DDC3E27DCF14@verisign.com> <96A2541E-9497-44EF-86F8-2958E21DE465@verisign.com> <50D33E9B.6000606@gmail.com> To: Arturo Servin X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 20 Dec 2012 17:38:01.0762 (UTC) FILETIME=[C24B2820:01CDDED8] Cc: sidr@ietf.org Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 17:38:06 -0000 On Dec 20, 2012, at 11:36 AM, Arturo Servin wrote: >=20 >=20 > On 20/12/2012 14:19, Eric Osterweil wrote: >> On Dec 20, 2012, at 11:03 AM, Randy Bush wrote: >>=20 >>>> bgpsec+rpki does not have the highly globally synced requirement. =20= >> So, in bgpsec, you (as an RP) don't need to know ROAs a priori in = order to validate routes as they arrive in updates? >>=20 >=20 > Your RP does, but you do not need all the RPs to have it in = order to > rpki+bgpsec to work. If I want my prefixes to be validated and accepted throughout the = routing system (i.e. any eBGP speaker), I need to be sure they all have = the full RPKI repo. These RPs _also_ need all of router keys in the = whole world, so that they can verify the path signatures of any update = they might see. In this design, you can't be a little bit pregnant. :) Eric= From shane@castlepoint.net Thu Dec 20 10:06:12 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 E8CB521F8732 for ; Thu, 20 Dec 2012 10:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.407 X-Spam-Level: ** X-Spam-Status: No, score=2.407 tagged_above=-999 required=5 tests=[AWL=2.845, 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 IR1xNgptC2Ex for ; Thu, 20 Dec 2012 10:06:11 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id DC2CB21F8920 for ; Thu, 20 Dec 2012 10:06:10 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 64DE830003D for ; Thu, 20 Dec 2012 18:06:10 +0000 (UTC) Received: from mbp.castlepoint.net (216-160-173-97.hlrn.qwest.net [216.160.173.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 2530530003B; Thu, 20 Dec 2012 11:06:09 -0700 (MST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Thu, 20 Dec 2012 11:06:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <373494A2-B03A-40D4-8E32-D85B2071D817@castlepoint.net> References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Thu Dec 20 11:06:10 2012 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50d35392199631381220600 X-DSPAM-Factors: 27, Subject*Re+#+the, 0.01000, a+#+#+#+with, 0.01000, and+#+#+#+the, 0.01000, Sriram+Kotikalapudi, 0.01000, Subject*sidr+#+#+for, 0.01000, don't+have, 0.01000, think+that, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, prefix+from, 0.01000, prefix+from, 0.01000, for+#+#+is, 0.01000, AS+#+#+a, 0.01000, have+no, 0.01000, to+#+#+in, 0.01000, to+#+#+in, 0.01000, that+#+#+does, 0.01000, DDoS+#+service, 0.01000, a+#+#+not, 0.01000, a+#+#+with, 0.01000, a+#+#+with, 0.01000, Cc*sidr+#+#+#+ietf.org, 0.01000, as+#+#+AS, 0.01000, from+#+#+AS, 0.01000, from+#+#+AS, 0.01000, even+though, 0.01000, to+#+to, 0.01000 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 18:06:12 -0000 On Dec 20, 2012, at 8:39 AM, "Sriram, Kotikalapudi" = wrote: >> FWIW, I disagree with your assertions, but am cutting to the chase, = because I think you're still failing to understand why/when it's not = possible to "spoof" the Victim's AS. >>=20 >=20 > Sorry, I tried my best to try to understand your point but well =85 > But thanks very much indeed for your patience. > I guess this particular point ( i.e. why/when it's not possible to = "spoof" the Victim's AS)=20 > needs some paper and pencil (or white board) discussion. > Hopefully, we can do that when we meet in person (at NANOG in Feb?).=20= I don't have plans to be at NANOG in February, so perhaps IETF in March? > --snip--=20 >>=20 >> There is no PE <-> CE eBGP session where one can originate the IP = Prefix from the "Victim AS". There is just this: >>=20 >> ISP >> Proxy-AS Victim IP prefix >> AS1 >> +------+ +-------------------------------------+ >> | PE-1 |=3D=3D=3D=3D=3D=3D| Victim's L2 switches and/or servers | >> +------+ +-------------------------------------+ >>=20 >> ^ >> | >> +---- This is not a CE router >>=20 >> On the router PE-1, in the ISP AS (AS1), I am originating a BGP = announcement for a _directly_connected_ prefix, where the victim's = server/network/service is located. I am not aware of a capability in = any implementation that I'm familiar with where I can originate that = directly connected IP prefix for the Victim's network and have it appear = to be from the Victim's Original AS. When I originate an IP prefix on = PE-1, the Origin-AS of that IP prefix is AS1, the "Proxy AS", not the = "Victim's AS". Then again, perhaps I have not looked hard enough at = existing implementations ... >=20 > Thanks for the nice figure and the explanation. But I think there is a = way. > I assume the ISP (Proxy AS) is the DDoS mitigator. > Is the L2 connection (1) an existing business relationship between the = two parties, or=20 Assume the answer is: No. > (2) is being established in emergency after the victim came under = attack and=20 > made a panic phone call to the DDoS mitigator (Proxy AS1)? Yes. > If it is case (1), then a ROA can be created well in advance (of any = emergency) permitting=20 > the victim=92s prefix to be announced from AS1. Right? Theoretically, yes. /Assuming/ they planned ahead. However, I would note that the use case I've outlined above is more = broad than 'just' DDoS attack. Specifically, think of "natural or = man-made disasters". In the latter case, it's often the case that a = customer's primary DataCenter is taken offline and, although they [may] = have a secondary/backup DataCenter, they hadn't adequately provisioned = capacity into it. In those cases, the answer is, generally, to bypass = the undersized physical equipment/tail-circuit/whatever in order to = restore service as quickly as possible. In the example diagram I've = highlighted above, this could involve removing an undersized CE router = from the physical path between my PE and their server farm, (because = it's physical interfaces, processing power, whatever are not adequately = sized). Although you would think that with the recent natural/man-made disasters = we've witnessed (Hurricane Sandy being the most recent), people would = get better at "planning ahead", but unfortunately that doesn't seem to = be panning out. > If it is case (2), then for what purpose is the L2 connection being = set up?=20 > It appears to me that it is for the Proxy AS1 to channel the scrubbed = traffic=20 > back to the victim=92s network. True? In the case of DDoS mitigation, yes. In the case, where I am helping = restore service *after* a natural/man-made disaster or flash = crowd/traffic, that's not the case. I'm just sinking/sourcing traffic = to them to get them back online as quickly as possible. > So the question is, in case (2) how does Proxy AS1 inject a route into = the Internet=20 > showing victim AS as the origin AS. The proxy AS1 already has a route = for=20 > the victim=92s prefix from updates it got from one or more of its = (AS1=92s) neighbors.=20 > (Note that Proxy AS1 does not need to have a direct BGP peering with = victim AS=20 > although it can establish one if needed over a multi-hop TCP, but we = don=92t need that here).=20 > Let us say, the path that AS1 has for victim=92s AS (or prefix) is AS6 = AS9 AS2,=20 > where AS2 is the victim=92s ASN and AS9 and AS6 are some ASes in the = middle.=20 > All that the Proxy AS1 needs to do is modify the path and reduce it = simply to AS2.=20 > This is a simple path modification (MITM). Pilosov-Kapela successfully = demoed=20 > a more complex BGP MITM back in 2008 on the live real Internet at = Defcon.=20 > By comparison, the path modification that the mitigator (proxy AS1) = needs to do=20 > seems feasible and simpler. Agree? I disagree. As I stated previously, commercial routers *DO NOT* allow = me to originate the Victim's IP prefix from the Victim's AS. My router = (AS1) only allows me to originate IP prefixes from AS1. My router (AS1) = does not allow me to originate an IP prefix from some random AS: AS2, = etc. As I also stated, I firmly believe that's a *security* feature, = not a "bug". >>> The solution that Oliver and I suggested does not have any of the = complications >>> that you mention above: >>> http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html >>> http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html >>> The victim AS does not need to transfer any router keys to the proxy = AS. >>> Instead the victim AS provides a signed update (with pCount=3D0) to = the >>> proxy AS (by creating a BGPSEC peering session or by other suitable = means). >>=20 >> Awesome. So, now we've got a recommendation to: >> a) Spoof the Victim's Origin AS; and, >=20 > The mitigator is *benevolently hijacking* the victim=92s prefix (or = subprefix) today=20 > to provide DDoS mitigation. Spoofing of victim=92s AS may be used in = the same vein,=20 > keeping mitigator=92s update =93Valid=94 when origin-only-validation = is in use.=20 Hrm, "benevolently" implies _intent_ ... yes? I thought "intent" was = strictly verboten in this WG? So, how will third-parties in a BGPSEC = world know that the intent is "benevolent" vs. "malevolent" hijacking? > Your use of =93and,=94 above is incorrect. It should be =93or=94.=20 > Spoofing the Victim's Origin AS is applicable in the = origin-validation-only case,=20 > not but in the path validation case (i.e. BGPSEC). Why? >> b) Use pCount =3D 0 to avoid validating the AS_PATH signatures >=20 > Err=85 No. Where did you get that from? =20 > pCount represents the AS prepend count (there is a pCount associated = with each AS). > pCount =3D 0 (in BGPSEC) simply means that the corresponding ASN must = not be=20 > counted in the path length count. Verifying the path signatures is = still a must.=20 > Recall that pCount =3D 0 was introduced originally to accommodate=20 > transparent router servers (IXP). In the present case, pCount =3D 0 = helps with=20 > not increasing the path length when victim=92s ASN is to be included = in the AS path.=20 > But pCount =3D 1 can also be used if you don=92t care about the +1 = increment=20 > to the path length of the Proxy AS=92s (mitigator=92s) announcement. OK, my apologies for the misunderstanding. But, this leads me back to the question you never answered in one of my = previous e-mails on this topic. =20 =20 Let me draw a little picture to make that question more clear. Again, = I'm going with the scenario that you envision is theoretically possible = (under duress), which is that there is the following topology. (Note, = this is not applicable to the other scenario I outlined above where no = CE router exists during restoration of service after a natural/man-made = disaster). After a DDoS attack has started to occur, the Victim has = called up a DDoS scrubbing service provider and said "Help", with no = prior business relationship in place. In this case, let's assume the = DDoS scrubbing provider already has a "CE-1" router, located in the DDoS = scrubbing provider's DataCenter(s), sitting idle which will benevolently = stand in on behalf of the "Victim AS" and will be used to inject the = Victim's IP prefix(es) with the correct, original Origin_AS. In this = case, "PE-1" is owned/operated by the DDoS scrubbing provider and has = "Proxy AS". IOW, you can think of "Proxy AS" as a brand-new "Transit = Provider" to the "Victim AS". Again, since there was no prior business = relationships and time is of the essence, you have to use the HW already = deployed in the diagram below. I agree that, strictly from the PoV of = Origin Validation, CE-1 can originate the Victim IP prefix with the = correct Origin_AS and Origin Validation will work OK -- even though, in = this case, everyone will have no idea if that's what is intended or not. = However, my question above is really about Path Validation, specific to = BGPSEC. In this case, how does the "Victim AS" get their (private?) = signing keys deployed /within/ CE-1 of the DDoS scrubbing provider? = Isn't that required in order for CE-1 to properly sign the AS_PATH = Signature before transmittal to PE-1, in order that receivers of this = BGP UPDATE will observe a valid BGP AS_PATH Signature? DDoS Scrubbing Provider "Proxy AS" "Vicim AS" AS1 AS2 +------+ +------+ | PE-1 |-------| CE-1 | +------+ +------+ >> I'm failing to see what the group is trying to accomplish here if = these are the recommendations. One has to question what value there is = in deploying Origin Validation & BGPSEC if the answer when it can't = accommodate a operationally viable scenarios is to effectively "turn it = off". >=20 > With pCount =3D 0 misunderstanding removed, I hope you now see that = the=20 > proposed solution is not simplistic as you might have thought.=20 I'm still not here, yet. > The proposed solution is helping the DDoS mitigator announce/propagate=20= > the victim=92s prefix and stay =93Valid=94, while also avoiding having = to create/propagate=20 > new RPKI objects in the emergency situation. That=92s the goal, right? Yes. -shane= From aservin@lacnic.net Thu Dec 20 10:27: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 683F921F8A4D for ; Thu, 20 Dec 2012 10:27: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 rY1L4gCf99Rw for ; Thu, 20 Dec 2012 10:27:42 -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 89B0B21F86B0 for ; Thu, 20 Dec 2012 10:27:42 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:a5b7:528c:af5e:c3f0]) by mail.lacnic.net.uy (Postfix) with ESMTP id 18C37308427; Thu, 20 Dec 2012 16:27:29 -0200 (UYST) Message-ID: <50D35892.5080402@lacnic.net> Date: Thu, 20 Dec 2012 16:27:30 -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: Eric Osterweil References: <487F9F23-F609-48A2-BE67-6361291BDFCF@ripe.net> <50D34405.8080807@lacnic.net> <22421E49-82E5-4BEE-A3E3-BEE6C8BFEA3C@verisign.com> In-Reply-To: <22421E49-82E5-4BEE-A3E3-BEE6C8BFEA3C@verisign.com> X-Enigmail-Version: 1.4.6 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 Cc: sidr@ietf.org Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 18:27:43 -0000 On 20/12/2012 15:35, Eric Osterweil wrote: > > On Dec 20, 2012, at 11:59 AM, Arturo Servin wrote: > >> "> I would really like to echo Chris's last paragraph here. What do you >>> think is a reasonable time to propagate from an operator editing the >>> RPKI (A) -> 99.9% of Bs? >>> >>> I understand that half a day is way too long. Instantaneous is >>> theoretically impossible when BGP and RPKI are separate. But is there >>> really no reasonable pragmatic indication of what would be 'good >>> enough' for the real world? E.g. if we can come up with a structure >>> that enables repositories to support 100k RP tools ('B', assuming 2 >>> gatherers per ASN) getting their *updates* (full dump separate thread >>> please) every 10 minutes, is that good enough? >>> >> >> So, instead of continuing a futile discussion, why not better start >> working on a workable requirement? > > I think a number of us in this ``futile'' argument have been pushing pretty hard to start (or some may claim revive) the requirements process. The very fact that we are even talking about freshness and liveliness of data is a result of a few of us having to request/re-request/write drafts/do formal analysis on existing measurement/swrite tech notes/re-request again/etc. imho, the only reason anyone is _now_ saying, ``half a day is way too long'' is because it has taken this long to get traction from the group. > That's is not true. We have seen some challenges in the current architecture since long ago and some are trying to address them: https://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points/ https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-delta-protocol/ https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-validation-local-cache/ > My 0.02 about the above is that the first part of Tim's para talks about finding a requirement, but the 2nd part presumes the existence of a design (repos and structures)... Yes. That is what we have now. If you have a better way I would like to hear a proposal. Let's talk about requirements first. If we need use cases and threat models before that, then let's go _there_ first, and then on to requirements. I feel like your comments above take for granted the fact that several of us have had to work very hard to get to this stage. > Let's talk about requirements, what do you think is a reasonable time to propagate? > Eric > Regards, as From eosterweil@verisign.com Thu Dec 20 10:53: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 E8E1721F84F2 for ; Thu, 20 Dec 2012 10:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.622 X-Spam-Level: X-Spam-Status: No, score=-5.622 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, J_CHICKENPOX_46=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 f563X0RHJffg for ; Thu, 20 Dec 2012 10:53:44 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 42BA621F84E9 for ; Thu, 20 Dec 2012 10:53:41 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUNNetUUyDeftKYJT4T/DVdaNllbj3Ear@postini.com; Thu, 20 Dec 2012 10:53:43 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 qBKIrbCa026095; Thu, 20 Dec 2012 13:53:37 -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); Thu, 20 Dec 2012 13:53:37 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50D35892.5080402@lacnic.net> Date: Thu, 20 Dec 2012 13:53:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <931B485F-D061-4C05-8C95-7920995A85CE@verisign.com> References: <487F9F23-F609-48A2-BE67-6361291BDFCF@ripe.net> <50D34405.8080807@lacnic.net> <22421E49-82E5-4BEE-A3E3-BEE6C8BFEA3C@verisign.com> <50D35892.5080402@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 20 Dec 2012 18:53:37.0206 (UTC) FILETIME=[51A0FD60:01CDDEE3] Cc: sidr@ietf.org Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 18:53:45 -0000 On Dec 20, 2012, at 1:27 PM, Arturo Servin wrote: > That's is not true. We have seen some challenges in the current > architecture since long ago and some are trying to address them: >=20 > = https://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-= points/ >=20 > = https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-delta-protocol/ >=20 > = https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-validation-local-= cache/ I totally appreciate the efforts behind these design enhancements, and I = am trying impugn the work that has clearly gone into them (or the people = who did the work). However, my concern is that without requirements = analysis around the core of the architecture that these enhancements = speak to, how do you know that you're not just building on a = shaky/unstable foundation, or trying to overcome fundamental flaws in = its architecture? We haven't taken the time to outline what bgpsec = needs to do in order for us to be protected by it. Therefore, we can't = describe when we've met our goals. Note: a lot of the above work (I believe) surrounds just the RPKI, and = bgpsec's requirements on _it_ may change dramatically in the face of = what bgpsec ultimately needs to do. I am becoming increasingly = convinced that it is important to make the rpki vs. rpki+bgpsec = distinction crystal clear. >> My 0.02 about the above is that the first part of Tim's para talks = about finding a requirement, but the 2nd part presumes the existence of = a design (repos and structures)... =20 >=20 > Yes. That is what we have now. If you have a better way I would like = to > hear a proposal. So, despite my suggestions to start with requirements, you're asking for = a design? :) Throwing something together in a tit-for-tat would be reckless, as we = don't have a solid agreement of _what_ we are trying to protect against, = and therefore, we don't know _how_ we want to protect ourselves from it. = Admittedly, opinions in this group seem to vary, but we do not have a = reasonable/accepted draft. I am so glad meatspace bridges aren't built this way... We'd be driving = down the road trying to convince ourselves that a 1,000 meter wide gorge = up ahead was really just 900 meters of meaningful danger, and the 900 = meter bridge that we built part of the way across it is good enough. > Let's talk about requirements, what do you think is a reasonable time = to > propagate? I'm happy to have the requirements discussion, but it starts with higher = level questions like: what (specifically) are we trying to accomplish? = What are we trying to protect ourselves against? What is the nature of = that danger? How do we address it? etc. Then we can go to lower level = requirements that may come out of that, like freshness. Without = understanding the high level requirements, I would worry that deciding = we need to enshrine a specific deadline, and then choosing a value could = be as dangerous as presuming we don't need one at all. Eric= From eosterweil@verisign.com Thu Dec 20 11:02: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 4524A21F84F9 for ; Thu, 20 Dec 2012 11:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[AWL=-0.836, 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 uMdGyEify-5L for ; Thu, 20 Dec 2012 11:02:14 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id DD23A21F84F5 for ; Thu, 20 Dec 2012 11:02:12 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUNNgrQX9zBRMNh3rBdM2hSAaBS6EWCo2@postini.com; Thu, 20 Dec 2012 11:02:14 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 qBKJ22ll026343; Thu, 20 Dec 2012 14:02:02 -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); Thu, 20 Dec 2012 14:02:01 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <931B485F-D061-4C05-8C95-7920995A85CE@verisign.com> Date: Thu, 20 Dec 2012 14:02:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <536553C9-EADA-4D69-B8C0-38A81BA2A1A2@verisign.com> References: <487F9F23-F609-48A2-BE67-6361291BDFCF@ripe.net> <50D34405.8080807@lacnic.net> <22421E49-82E5-4BEE-A3E3-BEE6C8BFEA3C@verisign.com> <50D35892.5080402@lacnic.net> <931B485F-D061-4C05-8C95-7920995A85CE@verisign.com> To: Arturo Servin X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 20 Dec 2012 19:02:01.0641 (UTC) FILETIME=[7E4BA990:01CDDEE4] Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Dec 2012 19:02:45 -0000 On Dec 20, 2012, at 1:53 PM, Eric Osterweil wrote: >=20 > On Dec 20, 2012, at 1:27 PM, Arturo Servin wrote: >=20 >> That's is not true. We have seen some challenges in the current >> architecture since long ago and some are trying to address them: >>=20 >> = https://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-= points/ >>=20 >> = https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-delta-protocol/ >>=20 >> = https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-validation-local-= cache/ >=20 > I totally appreciate the efforts behind these design enhancements, and = I am trying impugn the work that has clearly gone into them (or the = people who did the work). However, my concern is that without = requirements analysis around the core of the architecture that these = enhancements speak to, how do you know that you're not just building on = a shaky/unstable foundation, or trying to overcome fundamental flaws in = its architecture? We haven't taken the time to outline what bgpsec = needs to do in order for us to be protected by it. Therefore, we can't = describe when we've met our goals. Err... *_not_ trying to impugn sorry. :) Eric= From andy@arin.net Fri Dec 21 07:44: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 0DC6C21F87B3 for ; Fri, 21 Dec 2012 07:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 OWfJUtK++Iub for ; Fri, 21 Dec 2012 07:44:07 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 303B721F8866 for ; Fri, 21 Dec 2012 07:44:06 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id D11E81652BC; Fri, 21 Dec 2012 10:44:05 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 5057D1652B1; Fri, 21 Dec 2012 10:44:05 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 21 Dec 2012 10:43:43 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0328.009; Fri, 21 Dec 2012 10:44:04 -0500 From: Andy Newton To: Alexey Melnikov , sidr wg Thread-Topic: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 Thread-Index: AQHN2KLM3f/nnoS0IkuLdXXUmdVtzJgjcriA Date: Fri, 21 Dec 2012 15:44:03 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E57898D42A@CHAXCH01.corp.arin.net> In-Reply-To: <50C8E17D.3090507@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <082AAE07F49D8D4C9EE2EC20894C13D9@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 21 Dec 2012 15:44:08 -0000 On 12/12/12 2:56 PM, "Alexey Melnikov" wrote: >1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02 >actually a problem that the WG needs to address? (Answer: yes or no. >Additional information is welcomed, but I don't want people to repeat >the whole discussion.) At present, I think not. While this is interesting, I don't think the IETF is the venue for this document as the subject is not technical. >3) If you answered "a" or "b" above, please also answer the following >question: > >Does this need to be in a standalone draft, or can it be incorporated >into another existing WG draft? When answering this question please only >base your answer on technical reasons, in particular please leave the >decision on who is going to edit the document (if it is standalone) to >WG chairs. Should it be adopted, I think it should be standalone. -andy From shares@ndzh.com Fri Dec 21 14:34: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 2F8C021F879E for ; Fri, 21 Dec 2012 14:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.127 X-Spam-Level: ** X-Spam-Status: No, score=2.127 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_20=-0.74, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 iVP0btdfpN+K for ; Fri, 21 Dec 2012 14:34:18 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DABEB21F859D for ; Fri, 21 Dec 2012 14:34:17 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: Date: Fri, 21 Dec 2012 17:34:08 -0500 Message-ID: <007b01cddfcb$4ac6f380$e054da80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01CDDFA1.61F3F8C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3fyzzWQhnaZBtSTO+8P0lDxosB0g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "John G. Scudder" , Christopher Morrow , Sandra.Murphy@sparta.com Subject: [sidr] Requesting a SIDR review of draft-ietf-idr-as-private-reservation-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 22:34:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007C_01CDDFA1.61F3F8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alexey, Sandy, and Chris: We request that the SIDR WG review draft-ietf-idr-as-private-reservation-02.txt? (http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/) Since it modifies RFC 1930, a BCP, it is likely to be a BCP. Here's a few questions we'd like answered: 1. Is SIDR concerned about the expansion of the Private Use ASN into the 4-byte AS space? 2. Will the 4-byte Private USE ASNs impact any of the prefix-AS bindings you wish to track? 3. Will this Private USE space ASNs impact any AS_PATH security work you are doing? We welcome any comments regarding the security issue for BGP in this draft. This draft has had substantial IDR debate which is (of course) online. Thank you, John and Sue ------=_NextPart_000_007C_01CDDFA1.61F3F8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alexey, = Sandy, and Chris:

 

We request = that the SIDR WG review =  draft-ietf-idr-as-private-reservation-02.txt?   (http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservat= ion/)

 

Since it = modifies RFC 1930, a BCP, it is likely to be a BCP. =

 

Here’s = a few questions we’d like answered:

 

1.     Is SIDR = concerned about the expansion of the Private Use ASN into the 4-byte AS = space? 

2.     Will the = 4-byte Private USE ASNs impact any of the prefix-AS bindings you wish to = track?

3.     Will this = Private USE space ASNs impact any AS_PATH security work you are doing? =

 

We welcome = any comments regarding the security issue for BGP in this draft. =

 

This draft = has had substantial IDR debate which is (of course) = online.

 

Thank you, =

 

John and Sue =

 

------=_NextPart_000_007C_01CDDFA1.61F3F8C0-- From shares@ndzh.com Fri Dec 21 18:43: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 CD29F21F84C9 for ; Fri, 21 Dec 2012 18:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.932 X-Spam-Level: * X-Spam-Status: No, score=1.932 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_05=-1.11, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 FTs769MKB39u for ; Fri, 21 Dec 2012 18:43:48 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3521F8422 for ; Fri, 21 Dec 2012 18:43:47 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: In-Reply-To: Date: Fri, 21 Dec 2012 21:43:39 -0500 Message-ID: <001901cddfee$263b1870$72b14950$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01CDDFC4.3D670C40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/ywgnPu+nEbJMl2jL8rvN/7u225bARhkg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: "John G. Scudder" , Christopher Morrow , Sandra.Murphy@sparta.com Subject: Re: [sidr] Requesting a SIDR review of draft-ietf-idr-as-private-reservation-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 02:43:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001A_01CDDFC4.3D670C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reposting with time of 2 weeks (1/4/2013). Alexey, Sandy, and Chris: We request that the SIDR WG review draft-ietf-idr-as-private-reservation-02.txt? (http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/) Since it modifies RFC 1930, a BCP, it is likely to be a BCP. Here's a few questions we'd like answered: 1. Is SIDR concerned about the expansion of the Private Use ASN into the 4-byte AS space? 2. Will the 4-byte Private USE ASNs impact any of the prefix-AS bindings you wish to track? 3. Will this Private USE space ASNs impact any AS_PATH security work you are doing? We welcome any comments regarding the security issue for BGP in this draft by 1/4/2013. This draft has had substantial IDR debate which is (of course) online. Thank you, John and Sue ------=_NextPart_000_001A_01CDDFC4.3D670C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reposting = with time of 2 weeks (1/4/2013).

 

Alexey, = Sandy, and Chris:

 

We request = that the SIDR WG review =  draft-ietf-idr-as-private-reservation-02.txt?   (http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservat= ion/)

 

Since it = modifies RFC 1930, a BCP, it is likely to be a BCP. =

 

Here’s = a few questions we’d like answered:

 

1.     Is SIDR = concerned about the expansion of the Private Use ASN into the 4-byte AS = space? 

2.     Will the = 4-byte Private USE ASNs impact any of the prefix-AS bindings you wish to = track?

3.     Will this = Private USE space ASNs impact any AS_PATH security work you are doing? =

 

We welcome = any comments regarding the security issue for BGP in this draft by 1/4/2013.

 

This draft = has had substantial IDR debate which is (of course) = online.

 

Thank you, =

 

John and Sue =

 

------=_NextPart_000_001A_01CDDFC4.3D670C40-- From randy@psg.com Fri Dec 21 19:52: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 912C921E803A for ; Fri, 21 Dec 2012 19:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOYiZDXSKozY for ; Fri, 21 Dec 2012 19:52:31 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2D82221E8030 for ; Fri, 21 Dec 2012 19:52:31 -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 1TmG8S-00033v-Qt; Sat, 22 Dec 2012 03:52:29 +0000 Date: Fri, 21 Dec 2012 22:52:28 -0500 Message-ID: From: Randy Bush To: Susan Hares In-Reply-To: <007b01cddfcb$4ac6f380$e054da80$@ndzh.com> References: <007b01cddfcb$4ac6f380$e054da80$@ndzh.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] Requesting a SIDR review of draft-ietf-idr-as-private-reservation-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 03:52:31 -0000 my personal take, for the little it is worth is that, from the pov of the sidr work, it is no different from the private ASs already in play. randy From joelja@bogus.com Mon Dec 24 16:32: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 9B23921F8AF4 for ; Mon, 24 Dec 2012 16:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 MCCOqBunoOn4 for ; Mon, 24 Dec 2012 16:32:24 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA321F8ADA for ; Mon, 24 Dec 2012 16:32:23 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qBP0WMTn041336 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 25 Dec 2012 00:32:22 GMT (envelope-from joelja@bogus.com) Message-ID: <50D8F410.1090202@bogus.com> Date: Mon, 24 Dec 2012 16:32:16 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: 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 (nagasaki.bogus.com [147.28.0.81]); Tue, 25 Dec 2012 00:32:23 +0000 (UTC) Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 25 Dec 2012 00:32:24 -0000 On 12/18/12 11:48 AM, Randy Bush wrote: > I am trying to understand why our fellow engineers at Verisign are > obsessed with global propagation of RPKI data on the order of a few > minutes. Then a friend hit me with the clue by four. It's about third > party DDoS (and other attack) mitigation. > > When an NTT (just an example) customer is attacked, the customer can > request that their upstream sink and scrub the traffic as it naturally > passes through NTT. NTT passes the scrubbed traffic on to the customer, > and that's that. > > But, when the customer's upstream does not provide such services, or the > customer has other reasons for not using the upstream service, they can > buy the scrubbing service from a third party, e.g. Verisign. Verisign > will announce the customer's prefix(es) from a Verisign AS, receive the > traffic, scrub it clean, and send the cleaned traffic to the customer, > often via a tunnel. > > Well and good, except Verisign is announcing someone else's prefix, a > basic violation of BGP origination validation. Naturally, the customer > who contracts to Verisign for this service issues a ROA for the > prefix(es) to the Verisign AS, and it is not a violation, all is serene. > > But what if Verisign wants to take on a new customer in panic "Help, I > am being attacked and will pay you a lot of money to fix this?" The > time for the fix is dependent on how quickly a new ROA for the victim's > prefix(es) can propagate. The alternative approach assuming you've planned ahead is to orginate a more specific with the same origin but verisign as the transit AS... therefore the origin validation works fine. if you do the same with the covering prefix you're going to have to either make your other providers less desirable, or withdrawal the prefix. the backhaul from your dos protection provider is done with a tunnel or ideally with a private interconnect. > Alternatively, the victim could pull their normal ROA(s) for their > prefix(es) and the world would get NotFound and believe Verisign's > announcement(s). But this too relies on quick propagation of RPKI data. > > Observe that this is a problem in origin validation, i.e. what is being > deployed today. The RFCs are published, the code is in the routers, ... > the horse has left the barn. > > Yet another item to go into the display case of security vs. utility. > Ah well. But I sympathize with Verisign's business case and have no > desire to whack it. And I assume others think similarly. > > There is this little problem. Today, the Internet has no technology for > reliable global fast distribution of a database. No, DNS is not the > answer. But please have that argument on a different thread. The only > thing of which I am aware is Google's Spanner [0], which is a brilliant > piece of work. But it is not lightweight (e.g. True Time), is > proprietary, is likely considered very secret sauce, and even Google > lists it as research as opposed to beta :) > > IMIHO, this is a *really* interesting area for research, though I > suspect sidr is not the place to conduct it. But it's research, not > something we can paint on today. So we are left with propagation on the > order of a very few hours, AKA 'human time', and our discussions of how > to reduce load on CAs so we can query them more frequently. > > randy > > --- > > [0] - http://research.google.com/archive/spanner.html > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kotikalapudi.sriram@nist.gov Wed Dec 26 09:37: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 0DF4021F8C98 for ; Wed, 26 Dec 2012 09:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 GIbFu1y+bVZx for ; Wed, 26 Dec 2012 09:37:28 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B012D21F8C7A for ; Wed, 26 Dec 2012 09:37:27 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 26 Dec 2012 12:37:09 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 26 Dec 2012 12:37:25 -0500 From: "Sriram, Kotikalapudi" To: Shane Amante Date: Wed, 26 Dec 2012 12:37:24 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3e3Lmfp0225YMMSGu1OK1LBPeYUAEsVdRQ Message-ID: References: , , <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> , <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> , , <373494A2-B03A-40D4-8E32-D85B2071D817@castlepoint.net> In-Reply-To: <373494A2-B03A-40D4-8E32-D85B2071D817@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 Dec 2012 17:37:29 -0000 > I don't have plans to be at NANOG in February, so perhaps IETF in March? Yes, I plan to attend the IETF in March. > --snip-- >> (2) is being established in emergency after the victim came under attack= and >> made a panic phone call to the DDoS mitigator (Proxy AS1)? > > Yes. > > >> If it is case (1), then a ROA can be created well in advance (of any eme= rgency) permitting >> the victim=92s prefix to be announced from AS1. Right? > > Theoretically, yes. /Assuming/ they planned ahead. > > However, I would note that the use case I've outlined above is more broad= than 'just' DDoS attack. Specifically, think of "natural or man-made disa= sters". In the latter case, it's often the case that a customer's primary = DataCenter is taken offline and, although they [may] have a secondary/backu= p DataCenter, they hadn't adequately provisioned capacity into it. In thos= e cases, the answer is, generally, to bypass the undersized physical equipm= ent/tail-circuit/whatever in order to restore service as quickly as possibl= e. In the example diagram I've highlighted above, this could involve remov= ing an undersized CE router from the physical path between my PE and their = server farm, (because it's physical interfaces, processing power, whatever = are not adequately sized). > Would it be possible to leave the BGP session intact from their CE to your = PE? If not, can a new BGP session (possibly over a TCP session that may go over= multiple physical hops if necessary) be set up between your PE and the cus= tomer? Customer could even use a simple PC emulating a BGP router to do thi= s. Then they can originate their own prefix and directly pass the announcem= ent to your PE; the update could be unsigned (when there is origin-only val= idation) or signed in the future (when there is path validation).=20 > > >> If it is case (2), then for what purpose is the L2 connection being set = up? >> It appears to me that it is for the Proxy AS1 to channel the scrubbed tr= affic >> back to the victim=92s network. True? > > In the case of DDoS mitigation, yes. In the case, where I am helping res= tore service *after* a natural/man-made disaster or flash crowd/traffic, th= at's not the case. I'm just sinking/sourcing traffic to them to get them b= ack online as quickly as possible. > > >> So the question is, in case (2) how does Proxy AS1 inject a route into t= he Internet >> showing victim AS as the origin AS. The proxy AS1 already has a route fo= r >> the victim=92s prefix from updates it got from one or more of its (AS1= =92s) neighbors. >> (Note that Proxy AS1 does not need to have a direct BGP peering with vic= tim AS >> although it can establish one if needed over a multi-hop TCP, but we don= =92t need that here). >> Let us say, the path that AS1 has for victim=92s AS (or prefix) is AS6 A= S9 AS2, >> where AS2 is the victim=92s ASN and AS9 and AS6 are some ASes in the mid= dle. >> All that the Proxy AS1 needs to do is modify the path and reduce it simp= ly to AS2. >> This is a simple path modification (MITM). Pilosov-Kapela successfully d= emoed >> a more complex BGP MITM back in 2008 on the live real Internet at Defcon= . >> By comparison, the path modification that the mitigator (proxy AS1) need= s to do >> seems feasible and simpler. Agree? > > I disagree. As I stated previously, commercial routers *DO NOT* allow me= to originate the Victim's IP prefix from the Victim's AS. My router (AS1)= only allows me to originate IP prefixes from AS1. My router (AS1) does no= t allow me to originate an IP prefix from some random AS: AS2, etc. As I a= lso stated, I firmly believe that's a *security* feature, not a "bug". > Please see my comment below with you new example. > > >> >> The mitigator is *benevolently hijacking* the victim=92s prefix (or subp= refix) today >> to provide DDoS mitigation. Spoofing of victim=92s AS may be used in the= same vein, >> keeping mitigator=92s update =93Valid=94 when origin-only-validation is = in use. > > Hrm, "benevolently" implies _intent_ ... yes? I thought "intent" was str= ictly verboten in this WG? So, how will third-parties in a BGPSEC world kn= ow that the intent is "benevolent" vs. "malevolent" hijacking? > In the ROA, there is an expression of intent, but still origin-only-validat= ion leaves door open for faked origin announcements. Third party would alwa= ys treat that type of announcement as Valid provided maxlength is not viola= ted (in the origin-only-validation case). It is the victim who knows it was= a =93benevolent=94 act by their mitigator, and therefore does not raise an= alarm. This discussion is moot in the path validation case. =09 > >> Your use of =93and,=94 above is incorrect. It should be =93or=94. >> Spoofing the Victim's Origin AS is applicable in the origin-validation-o= nly case, >> not but in the path validation case (i.e. BGPSEC). > > Why? When there is path validation, obviously the mitigator cannot spoof the vic= tim=92s AS; it is not possible. The mitigator can only rely on receiving a = signed update from the victim; please see more elaborate comment below. > > >>> b) Use pCount =3D 0 to avoid validating the AS_PATH signatures >> >> Err=85 No. Where did you get that from? >> pCount represents the AS prepend count (there is a pCount associated wit= h each AS). >> pCount =3D 0 (in BGPSEC) simply means that the corresponding ASN must no= t be >> counted in the path length count. Verifying the path signatures is still= a must. >> Recall that pCount =3D 0 was introduced originally to accommodate >> transparent router servers (IXP). In the present case, pCount =3D 0 help= s with >> not increasing the path length when victim=92s ASN is to be included in = the AS path. >> But pCount =3D 1 can also be used if you don=92t care about the +1 incre= ment >> to the path length of the Proxy AS=92s (mitigator=92s) announcement. > > OK, my apologies for the misunderstanding. > > But, this leads me back to the question you never answered in one of my p= revious e-mails on this topic. > > Let me draw a little picture to make that question more clear. Again, I'= m going with the scenario that you envision is theoretically possible (unde= r duress), which is that there is the following topology. (Note, this is n= ot applicable to the other scenario I outlined above where no CE router exi= sts during restoration of service after a natural/man-made disaster). Afte= r a DDoS attack has started to occur, the Victim has called up a DDoS scrub= bing service provider and said "Help", with no prior business relationship = in place. In this case, let's assume the DDoS scrubbing provider already h= as a "CE-1" router, located in the DDoS scrubbing provider's DataCenter(s),= sitting idle which will benevolently stand in on behalf of the "Victim AS"= and will be used to inject the Victim's IP prefix(es) with the correct, or= iginal Origin_AS. In this case, "PE-1" is owned/operated by the DDoS scrub= bing provider and has "Proxy AS". IOW, you can think of "Proxy AS" as a br= and-new "Transit Provider" to the "Victim AS". Again, since there was no p= rior business relationships and time is of the essence, you have to use the= HW already deployed in the diagram below. I agree that, strictly from the= PoV of Origin Validation, CE-1 can originate the Victim IP prefix with the= correct Origin_AS and Origin Validation will work OK -- even though, in th= is case, everyone will have no idea if that's what is intended or not. How= ever, my question above is really about Path Validation, specific to BGPSEC= . In this case, how does the "Victim AS" get their (private?) signing keys= deployed /within/ CE-1 of the DDoS scrubbing provider? Isn't that require= d in order for CE-1 to properly sign the AS_PATH Signature before transmitt= al to PE-1, in order that receivers of this BGP UPDATE will observe a valid= BGP AS_PATH Signature? > > DDoS > Scrubbing > Provider > "Proxy AS" "Vicim AS" > AS1 AS2 > +------+ +------+ > | PE-1 |-------| CE-1 | > +------+ +------+ > > The WG has generally held the opinion that one organization handing its pri= vate key to another is not a good practice. So I think the solution has to = be of a different nature. We have to ask if it would be possible (as part o= f the mitigation /service recovery strategy) to quickly set up a BGPSEC ses= sion between the mitigator and the victim in cases when one did not exist a= lready? This BGPSEC session does not have to be over a single physical hop;= it can be set up over a TCP session that goes over multiple physical hops.= The equipment on the victim=92s side can simply be a PC that emulates a BG= PSEC router or it could be their CE. Do you think this is workable? Sriram From christopher.morrow@gmail.com Wed Dec 26 09:49: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 8327B21F8769 for ; Wed, 26 Dec 2012 09:49:02 -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=[AWL=0.000, 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 RRbBBQ6wEk1p for ; Wed, 26 Dec 2012 09:49:02 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF021F8756 for ; Wed, 26 Dec 2012 09:49:00 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id i12so3525014eaa.24 for ; Wed, 26 Dec 2012 09:48:59 -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=/sZwmFUIn0Cxe+lnH+ibGo75vOCKehWmV1pXSMYnc8g=; b=TZukTNygULqC6CelZbN+fCZe+twHP9tuMhQnU2jdCsVXW7pDa/avK4F+4uEgxrdyv9 DT9xtE1ADVxccZXD7k/WYjoQESIlb0TelqiqQCcIW5xE4kg8TNvRfc8fV0lazQasv19D FxnQGBaYT938M7QthwVYjzibpX7ISmhQcG0kqXphvHR7hyz7H5+Sf4p50tNDTLtRh/8O 17wkrdg/yI3VHls/aqaf4BNtI/pfm+5Zpqgj1VNrAlkq37QhcfOff2PicpB0YHTQrpu8 UIyatQ1kVMWde+kIeaGQn+cz1BmvZVy3tVmRxUr4jTa+lyyMgkgnSd37mId4YBFJl1UX 2rrw== MIME-Version: 1.0 Received: by 10.14.214.132 with SMTP id c4mr71360659eep.18.1356544139322; Wed, 26 Dec 2012 09:48:59 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Wed, 26 Dec 2012 09:48:58 -0800 (PST) In-Reply-To: References: <83B9BC06-F638-4DC5-B26A-A2C790915B90@castlepoint.net> <6758A118-D93F-4959-BB8F-BF0B578DD1D6@castlepoint.net> <2017A1C7-54B2-4A9F-8845-A4FCA737180B@castlepoint.net> <373494A2-B03A-40D4-8E32-D85B2071D817@castlepoint.net> Date: Wed, 26 Dec 2012 12:48:58 -0500 X-Google-Sender-Auth: lheD2HTYMlLQbyoeV-VI8Hm1ISk Message-ID: From: Christopher Morrow To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 Dec 2012 17:49:02 -0000 On Wed, Dec 26, 2012 at 12:37 PM, Sriram, Kotikalapudi wrote: >> >> However, I would note that the use case I've outlined above is more broa= d than 'just' DDoS attack. Specifically, think of "natural or man-made dis= asters". In the latter case, it's often the case that a customer's primary= DataCenter is taken offline and, although they [may] have a secondary/back= up DataCenter, they hadn't adequately provisioned capacity into it. In tho= se cases, the answer is, generally, to bypass the undersized physical equip= ment/tail-circuit/whatever in order to restore service as quickly as possib= le. In the example diagram I've highlighted above, this could involve remo= ving an undersized CE router from the physical path between my PE and their= server farm, (because it's physical interfaces, processing power, whatever= are not adequately sized). >> > > Would it be possible to leave the BGP session intact from their CE to you= r PE? > If not, can a new BGP session (possibly over a TCP session that may go ov= er multiple physical hops if necessary) be set up between your PE and the c= ustomer? Customer could even use a simple PC emulating a BGP router to do t= his. Then they can originate their own prefix and directly pass the announc= ement to your PE; the update could be unsigned (when there is origin-only v= alidation) or signed in the future (when there is path validation). > >> I don't know that solving the many examples with many different solutions one at a time is helping here... In general: 1) there are cases where some relationship exists before the 'event', whatever that event may be 2) there are cases where no relationship exists before the 'event'. In both cases there are a myriad of solutions in place today, some of which will be complicated in a more 'bgpsec' world (or a more RPKI world). Making the potential new world be as nimble as the old seems to be what Shane/Danny are aiming for, right? Ratholing on the 12 sins of christmas doesn't seem helpful to the overall goal. -chris From david.black@emc.com Fri Dec 28 12:26: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 C73BF21F8E15; Fri, 28 Dec 2012 12:26: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=1.060, BAYES_00=-2.599, GB_I_LETTER=-2, 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 7TwTLXQ4+d-t; Fri, 28 Dec 2012 12:26:28 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D653521F8E14; Fri, 28 Dec 2012 12:26:27 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSKQKWv000647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Dec 2012 15:26:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 28 Dec 2012 15:26:00 -0500 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBSKPxgX012649; Fri, 28 Dec 2012 15:26:00 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Fri, 28 Dec 2012 15:25:59 -0500 From: "Black, David" To: "rogaglia@cisco.com" , Stephen Kent , Sean Turner , "gen-art@ietf.org" Date: Fri, 28 Dec 2012 15:25:47 -0500 Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: Ac3lOYUa+SMuJHJqQnWqMAKs4+qaRg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {2EE00D5C-0E52-4397-B700-FAB3D89CF142} x-cr-hashedpuzzle: EDy+ HCD/ PqAl WOGp ayJy b2ru hjd7 lJ1f rcct s40t vlnj w84h zYJu 3D3+ AAfVJA== AAoJ2g==; 6; ZwBlAG4ALQBhAHIAdABAAGkAZQB0AGYALgBvAHIAZwA7AGsAZQBuAHQAQABiAGIAbgAuAGMAbwBtADsAcgBvAGcAYQBnAGwAaQBhAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBzAGkAZAByAEAAaQBlAHQAZgAuAG8AcgBnADsAcwB0AGIAcgB5AGEAbgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0AOwB0AHUAcgBuAGUAcgBzAEAAaQBlAGMAYQAuAGMAbwBtAA==; Sosha1_v1; 7; {2EE00D5C-0E52-4397-B700-FAB3D89CF142}; ZABhAHYAaQBkAC4AYgBsAGEAYwBrAEAAZQBtAGMALgBjAG8AbQA=; Fri, 28 Dec 2012 20:25:47 GMT; RwBlAG4ALQBBAFIAVAAgAHIAZQB2AGkAZQB3ACAAbwBmACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHMAaQBkAHIALQBhAGwAZwBvAHIAaQB0AGgAbQAtAGEAZwBpAGwAaQB0AHkALQAwADkA acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Black, David" , "sidr@ietf.org" Subject: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Dec 2012 20:26:28 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sidr-algorithm-agility-09 Reviewer: David L. Black Review Date: December 28, 2012 IETF LC End Date: December 14, 2012 Summary: This draft is on the right track but has open issues, described in the revi= ew. I apologize for the tardy arrival of this review after the end of IETF Last Call for this draft - the last few months have been a rather busy time for = me. This draft specifies the algorithm transition process for RPKI, which entails coordinated issuance of new certificates and other signed products across the collection of RPKI CAs in a fashion that ensures that at least one set of signed products is usable at all times. The draft is generally well-written and clear, but has an unfortunate nomenclature change problem that is the primary open issue[*]. Major issues: [*] Section 4.7 changes the meaning of the algorithm suite names (A, B and C) from prior sections. This also affects Sections 6 and 7. I have classified this as a major issue as I believe it introduces severe lack of clarity (and potential ambiguity) into the following two paragraphs in Section 7:=20 During Phase 1, a CA that revokes a certificate under Suite A SHOULD revoke the corresponding certificate under Suite B, if that certificate exists. During Phase 4, a CA that revokes a certificate under Suite A SHOULD revoke the corresponding certificate under Suite C, if that certificate exists. During Phase 1, a CA may revoke certificates under Suite B without revoking them under Suite A, since the Suite B products are for test purposes. During Phase 4 a CA may revoke certificates issued under Suite C without revoking them under Suite A, since Suite C products are being deprecated. Despite the use of three letters (A, B and C), there are only two algorithm suites involved, and different instances of Suite A refer to different algorithm suites. In each paragraph, the first instance of "Suite A" refers to the same algorithm suite as "Suite C", and the second instance of "Suite A" refers to the same algorithm suite as "Suite B". It would be much better and clearer to not change the meaning of the=20 algorithm suite names until the EOL date. In addition, this change should enable removal of the Suite C concept from this draft. I strongly recommend removing the Suite C concept, as the C-A-B chronological order of suite introduction dates seems counter-intuitive. Minor issues: Starting in Section 4.3.1, there are a number of uses of "will be" (future tense) in the milestone and phase descriptions. All of these uses of "will be" should be reviewed to determine whether "MUST be" is appropriate, e.g., as appears to be the case for this sentence in 4.3.1: Additionally, the new algorithm transition timeline document will be published with the following information: When "MUST be" is not appropriate, present tense (i.e., "is") is preferable. Nits/editorial: Abstract: The following two sentences don't quite line up: The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. =20 Also, section 4.2 indicates that a multi-year transition timeframe is expected, which suggests that "months" is not appropriate in the abstract. Suggested rephrasing: The time available to complete the transition process is expected to be several years. Consequently, no emergency transition process is specified. Section 2. Introduction: The first sentence in the last paragraph mentions a forthcoming BCP on transition timetable. The rest of that paragraph implies that the BCP is for a single transition, as opposed to being a BCP for transitions in general. It would be helpful to clarify that at the start of the paragraph, e.g., by adding "For each algorithm transition," to the start of the paragraph. Section 3 Definitions: Is there any concern about possible confusion of the use of "Suite B" in this draft with NSA Suite B? The draft is clear on what Suite B means for RPKI, but I suspect that RPKI Suite B and NSA Suite B are unlikely to match, if ever. Describing Phase 0 as both the steady state of the RPKI and the first phase of transition is confusing (e.g., in 4.3). It would be clearer if Phase 0 began with publication of the updated RPKI algorithm document (Milestone 1) and that the activities that are unchanged from steady state were described as not changing in phase 0. Starting near the end of section 4.3, the three characters |-> are used in figures to represent an RPKI hierarchy relationship; that relationship should be defined and/or explained before it is used. For clarity, I'd suggest swapping the order of the two paragraphs above that figure in 4.3 and making the following change at the end of the paragraph that is moved down (addition of the word "certificate" is the important change): OLD and shows the relationship between three CAs (X, Y, and Z) that form a chain. NEW and shows the relationships among the three CAs (X, Y, and Z) that participate in a certificate chain. Subsequent uses of |-> seemed clear to me. Section 4.5 Phase 2 says that Suite B product SHOULD be stored at independent publication points, but does not make it clear that this recommendation applies beyond phase 2. I suggest adding text to make that clear - a reference to Section 9 (which is clear about this) may be useful as part of that text. In Section 6, please expand the ROA acronym on first use and consider whether it should be defined in Section 3. I'm also assuming that the ASN acronym is intended to refer to ASN.1 content; if not, that acronym also needs attention. idnits 2.12.13 found a couple of minor nits: ** There is 1 instance of too long lines in the document, the longest one being 23 characters in excess of 72. =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword= , but does not include the phrase in its RFC 2119 key words list. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From kent@bbn.com Mon Dec 31 11:34: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 1ABE921F878A; Mon, 31 Dec 2012 11:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 XK5DhhqNgzfp; Mon, 31 Dec 2012 11:34:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1203921F8738; Mon, 31 Dec 2012 11:34:44 -0800 (PST) Received: from dhcp89-089-242.bbn.com ([128.89.89.242]:50892) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tpl8C-000BIp-TZ; Mon, 31 Dec 2012 14:34:40 -0500 Message-ID: <50E1E8D0.5010204@bbn.com> Date: Mon, 31 Dec 2012 14:34:40 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gen-art@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Dec 2012 19:34:45 -0000 David, > The draft is generally well-written and clear, but has an unfortunate > nomenclature change problem that is the primary open issue[*]. > > Major issues: > > [*] Section 4.7 changes the meaning of the algorithm suite names (A, B > and C) from prior sections. I have deleted all references to Alg Suite C throughout the doc, and revised the text accordingly. > This also affects Sections 6 and 7. > I have classified this as a major issue as I believe it introduces > severe lack of clarity (and potential ambiguity) into the following > two paragraphs in Section 7: > > During Phase 1, a CA that revokes a certificate under Suite A SHOULD > revoke the corresponding certificate under Suite B, if that > certificate exists. During Phase 4, a CA that revokes a certificate > under Suite A SHOULD revoke the corresponding certificate under Suite > C, if that certificate exists. > > During Phase 1, a CA may revoke certificates under Suite B without > revoking them under Suite A, since the Suite B products are for test > purposes. During Phase 4 a CA may revoke certificates issued under > Suite C without revoking them under Suite A, since Suite C products > are being deprecated. fixed. > Despite the use of three letters (A, B and C), there are only two > algorithm suites involved, and different instances of Suite A refer to > different algorithm suites. In each paragraph, the first instance of > "Suite A" refers to the same algorithm suite as "Suite C", and the > second instance of "Suite A" refers to the same algorithm suite > as "Suite B". > > It would be much better and clearer to not change the meaning of the > algorithm suite names until the EOL date. In addition, this change > should enable removal of the Suite C concept from this draft. fixed > I > strongly recommend removing the Suite C concept, as the C-A-B > chronological order of suite introduction dates seems counter-intuitive. Done. > > Minor issues: > > Starting in Section 4.3.1, there are a number of uses of "will be" > (future tense) in the milestone and phase descriptions. All of > these uses of "will be" should be reviewed to determine whether > "MUST be" is appropriate, e.g., as appears to be the case for > this sentence in 4.3.1: > > Additionally, the new algorithm transition timeline document will be > published with the following information: I agree that "will be" needs to be changed to "MUST be" in a few places, starting on page 5 (Section 2) where the need to update the CP and to publish an alg transition timetable are first mentioned. An examination of the rest of the doc shows that this change need be applied only when the alg transition doc is mentioned. > When "MUST be" is not appropriate, present tense (i.e., "is") is > preferable. fixed. > > Nits/editorial: > > Abstract: The following two sentences don't quite line up: > > The process > is expected to be completed in a time scale of months or years. > Consequently, no emergency transition is specified. > > Also, section 4.2 indicates that a multi-year transition timeframe > is expected, which suggests that "months" is not appropriate in > the abstract. Suggested rephrasing: > > The time available to complete the transition process > is expected to be several years. > Consequently, no emergency transition process is specified. fixed. > Section 2. Introduction: The first sentence in the last paragraph > mentions a forthcoming BCP on transition timetable. The rest of > that paragraph implies that the BCP is for a single transition, as > opposed to being a BCP for transitions in general. It would be > helpful to clarify that at the start of the paragraph, e.g., > by adding "For each algorithm transition," to the start of the > paragraph. fixed. > Section 3 Definitions: Is there any concern about possible > confusion of the use of "Suite B" in this draft with NSA Suite B? > The draft is clear on what Suite B means for RPKI, but I suspect > that RPKI Suite B and NSA Suite B are unlikely to match, if ever. We defined what "Suite B" is in the terminology section, so I think no further clarification is required here. > Describing Phase 0 as both the steady state of the RPKI and the first > phase of transition is confusing (e.g., in 4.3). It would be clearer > if Phase 0 began with publication of the updated RPKI algorithm > document (Milestone 1) and that the activities that are unchanged > from steady state were described as not changing in phase 0. we need to be able to refer to steady state, separate from the first milestone in the transition process, but I agree that referring to it as the first phase of the transition process is confusing. I have changed the text accordingly. > Starting near the end of section 4.3, the three characters > |-> are used in figures to represent an RPKI hierarchy relationship; > that relationship should be defined and/or explained before it is used. > For clarity, I'd suggest swapping the order of the two paragraphs > above that figure in 4.3 and making the following change at the end > of the paragraph that is moved down (addition of the word > "certificate" is the important change): > > OLD > and shows the relationship between three CAs (X, Y, and Z) that form > a chain. > NEW > and shows the relationships among the three CAs (X, Y, and Z) > that participate in a certificate chain. > > Subsequent uses of |-> seemed clear to me. I'll defer to Roque here, as the repository representation is his design. > Section 4.5 Phase 2 says that Suite B product SHOULD be stored at > independent publication points, but does not make it clear that this > recommendation applies beyond phase 2. I suggest adding text to > make that clear - a reference to Section 9 (which is clear about > this) may be useful as part of that text. I have added a forward pointer to Section 9 here. > In Section 6, please expand the ROA acronym on first use and consider > whether it should be defined in Section 3. I'm also assuming that the > ASN acronym is intended to refer to ASN.1 content; if not, that > acronym also needs attention. ASN = Autonomous System Number. I expended the acronym as it appears only here. I added a ROA definition to Section 3. > idnits 2.12.13 found a couple of minor nits: > > ** There is 1 instance of too long lines in the document, the longest one > being 23 characters in excess of 72. I'll let Roque address this issue. > > == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but > does not include the phrase in its RFC 2119 key words list. fixed. From david.black@emc.com Mon Dec 31 11:58: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 0532421F8798; Mon, 31 Dec 2012 11:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.686 X-Spam-Level: X-Spam-Status: No, score=-103.686 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, GB_I_LETTER=-2, 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 YEkM6i6jwr30; Mon, 31 Dec 2012 11:58:21 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id ECCA021F8781; Mon, 31 Dec 2012 11:58:20 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBVJwDtx018582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Dec 2012 14:58:13 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 31 Dec 2012 14:58:00 -0500 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBVJvvne002947; Mon, 31 Dec 2012 14:57:59 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Mon, 31 Dec 2012 14:57:58 -0500 From: "Black, David" To: Stephen Kent Date: Mon, 31 Dec 2012 14:57:57 -0500 Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: Ac3njf3a/Rf0YVKgRU+J2U5oHDjWLQAANeIA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <50E1E8D0.5010204@bbn.com> In-Reply-To: <50E1E8D0.5010204@bbn.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-EMM-MHVC: 1 Cc: "gen-art@ietf.org" , "sidr@ietf.org" , "Black, David" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Dec 2012 19:58:22 -0000 Steve, This all looks good; thanks for the quick response. > > [*] Section 4.7 changes the meaning of the algorithm suite names (A, B > > and C) from prior sections. > I have deleted all references to Alg Suite C throughout the doc, and > revised the text accordingly. Magnificent - that'll be a significant improvement. > > Starting in Section 4.3.1, there are a number of uses of "will be" > > (future tense) in the milestone and phase descriptions. All of > > these uses of "will be" should be reviewed to determine whether > > "MUST be" is appropriate, e.g., as appears to be the case for > > this sentence in 4.3.1: > > > > Additionally, the new algorithm transition timeline document will b= e > > published with the following information: > I agree that "will be" needs to be changed to "MUST be" in a few places, > starting on page 5 (Section 2) where the need to update the CP and to pub= lish an > alg transition timetable are first mentioned. An examination of the rest = of the > doc shows that this change need be applied only when the alg transition d= oc is > mentioned. That sounds reasonable. > > Section 3 Definitions: Is there any concern about possible > > confusion of the use of "Suite B" in this draft with NSA Suite B? > > The draft is clear on what Suite B means for RPKI, but I suspect > > that RPKI Suite B and NSA Suite B are unlikely to match, if ever. > > We defined what "Suite B" is in the terminology section, so I > think no further clarification is required here. That's ok with me, but I thought it was worth asking. Thanks, --David > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, December 31, 2012 2:35 PM > To: Black, David > Cc: rogaglia@cisco.com; Sean Turner; gen-art@ietf.org; sidr@ietf.org; Ste= wart > Bryant > Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >=20 > David, >=20 > > The draft is generally well-written and clear, but has an unfortunate > > nomenclature change problem that is the primary open issue[*]. > > > > Major issues: > > > > [*] Section 4.7 changes the meaning of the algorithm suite names (A, B > > and C) from prior sections. >=20 > I have deleted all references to Alg Suite C throughout the doc, and > revised the text accordingly. >=20 > > This also affects Sections 6 and 7. > > I have classified this as a major issue as I believe it introduces > > severe lack of clarity (and potential ambiguity) into the following > > two paragraphs in Section 7: > > > > During Phase 1, a CA that revokes a certificate under Suite A SHOUL= D > > revoke the corresponding certificate under Suite B, if that > > certificate exists. During Phase 4, a CA that revokes a certificat= e > > under Suite A SHOULD revoke the corresponding certificate under Sui= te > > C, if that certificate exists. > > > > During Phase 1, a CA may revoke certificates under Suite B without > > revoking them under Suite A, since the Suite B products are for tes= t > > purposes. During Phase 4 a CA may revoke certificates issued under > > Suite C without revoking them under Suite A, since Suite C products > > are being deprecated. > fixed. > > Despite the use of three letters (A, B and C), there are only two > > algorithm suites involved, and different instances of Suite A refer to > > different algorithm suites. In each paragraph, the first instance of > > "Suite A" refers to the same algorithm suite as "Suite C", and the > > second instance of "Suite A" refers to the same algorithm suite > > as "Suite B". > > > > It would be much better and clearer to not change the meaning of the > > algorithm suite names until the EOL date. In addition, this change > > should enable removal of the Suite C concept from this draft. > fixed > > I > > strongly recommend removing the Suite C concept, as the C-A-B > > chronological order of suite introduction dates seems counter-intuitive= . > Done. > > > > Minor issues: > > > > Starting in Section 4.3.1, there are a number of uses of "will be" > > (future tense) in the milestone and phase descriptions. All of > > these uses of "will be" should be reviewed to determine whether > > "MUST be" is appropriate, e.g., as appears to be the case for > > this sentence in 4.3.1: > > > > Additionally, the new algorithm transition timeline document will b= e > > published with the following information: > I agree that "will be" needs to be changed to "MUST be" in a few places, > starting on page 5 (Section 2) where the need to update the CP and to > publish an > alg transition timetable are first mentioned. An examination of the rest > of the > doc shows that this change need be applied only when the alg transition > doc is > mentioned. > > When "MUST be" is not appropriate, present tense (i.e., "is") is > > preferable. > fixed. > > > > Nits/editorial: > > > > Abstract: The following two sentences don't quite line up: > > > > The process > > is expected to be completed in a time scale of months or years. > > Consequently, no emergency transition is specified. > > > > Also, section 4.2 indicates that a multi-year transition timeframe > > is expected, which suggests that "months" is not appropriate in > > the abstract. Suggested rephrasing: > > > > The time available to complete the transition process > > is expected to be several years. > > Consequently, no emergency transition process is specified. > fixed. > > Section 2. Introduction: The first sentence in the last paragraph > > mentions a forthcoming BCP on transition timetable. The rest of > > that paragraph implies that the BCP is for a single transition, as > > opposed to being a BCP for transitions in general. It would be > > helpful to clarify that at the start of the paragraph, e.g., > > by adding "For each algorithm transition," to the start of the > > paragraph. > fixed. > > Section 3 Definitions: Is there any concern about possible > > confusion of the use of "Suite B" in this draft with NSA Suite B? > > The draft is clear on what Suite B means for RPKI, but I suspect > > that RPKI Suite B and NSA Suite B are unlikely to match, if ever. > We defined what "Suite B" is in the terminology section, so I > think no further clarification is required here. > > Describing Phase 0 as both the steady state of the RPKI and the first > > phase of transition is confusing (e.g., in 4.3). It would be clearer > > if Phase 0 began with publication of the updated RPKI algorithm > > document (Milestone 1) and that the activities that are unchanged > > from steady state were described as not changing in phase 0. > we need to be able to refer to steady state, separate from the > first milestone in the transition process, but I agree that referring to > it as the first phase of the transition process is confusing. I have > changed the text accordingly. > > Starting near the end of section 4.3, the three characters > > |-> are used in figures to represent an RPKI hierarchy relationship; > > that relationship should be defined and/or explained before it is used. > > For clarity, I'd suggest swapping the order of the two paragraphs > > above that figure in 4.3 and making the following change at the end > > of the paragraph that is moved down (addition of the word > > "certificate" is the important change): > > > > OLD > > and shows the relationship between three CAs (X, Y, and Z) that for= m > > a chain. > > NEW > > and shows the relationships among the three CAs (X, Y, and Z) > > that participate in a certificate chain. > > > > Subsequent uses of |-> seemed clear to me. > I'll defer to Roque here, as the repository representation is his design. > > Section 4.5 Phase 2 says that Suite B product SHOULD be stored at > > independent publication points, but does not make it clear that this > > recommendation applies beyond phase 2. I suggest adding text to > > make that clear - a reference to Section 9 (which is clear about > > this) may be useful as part of that text. > I have added a forward pointer to Section 9 here. > > In Section 6, please expand the ROA acronym on first use and consider > > whether it should be defined in Section 3. I'm also assuming that the > > ASN acronym is intended to refer to ASN.1 content; if not, that > > acronym also needs attention. > ASN =3D Autonomous System Number. I expended the acronym as it appears > only here. I added a ROA definition to Section 3. > > idnits 2.12.13 found a couple of minor nits: > > > > ** There is 1 instance of too long lines in the document, the longes= t one > > being 23 characters in excess of 72. > I'll let Roque address this issue. > > > > =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 ke= yword, > but > > does not include the phrase in its RFC 2119 key words list. > fixed. >=20