From kent@bbn.com Thu Feb 3 07:50:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672EF3A69E5 for ; Thu, 3 Feb 2011 07:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE2isgU0Hfwk for ; Thu, 3 Feb 2011 07:50:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 801053A69E4 for ; Thu, 3 Feb 2011 07:50:15 -0800 (PST) Received: from dhcp89-089-123.bbn.com ([128.89.89.123]:49199) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pl1V3-000O9I-FF; Thu, 03 Feb 2011 10:53:37 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> References: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> Date: Thu, 3 Feb 2011 10:47:27 -0500 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:50:16 -0000 At 11:57 PM -0500 1/29/11, Danny McPherson wrote: >... > >That said, I do hope we don't assume that discussions of path security in a >routing protocol should be constrained by the RPKI architecture itself. > >-danny Danny, I'm a bit puzzled by your final comment above. Path secruity includes the origin AS, and the RPKI is the mechanism adopted by SIDR to validate the origin AS assertion for an AS path. So, in that sense, more extensive path secruity approaches will rely on the RPKI, at least for the origin AS. I have assumed that folks planned to take advantage of the ASN assertions in RPKI certs in support of path security mechanisms, in some form. (For origin AS verification we need only the address assertions in certs, but we have always described the RPKI as encompassing both address and ASN allocations.) I think reliance on the RPKI for validated assertions re both types of resources is appropriate for path secruity, irrespective of the mechanisms used to verify As path info. Steve From danny@tcb.net Thu Feb 3 07:56:09 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FE63A67F7 for ; Thu, 3 Feb 2011 07:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjVZz3vWh8bL for ; Thu, 3 Feb 2011 07:56:08 -0800 (PST) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id C0F663A697B for ; Thu, 3 Feb 2011 07:56:08 -0800 (PST) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id p13FsQ1X018438; Thu, 3 Feb 2011 10:54:26 -0500 Received: from DUL1WNEXMB06.vcorp.ad.vrsn.com ([10.170.12.250]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 10:59:28 -0500 Received: from dul1dmchper-m1.vcorp.ad.vrsn.com ([10.100.0.9]) by DUL1WNEXMB06.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 10:59:28 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Thu, 3 Feb 2011 10:59:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1EFD7809-67E8-45F8-85C6-95A12680870B@tcb.net> References: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 03 Feb 2011 15:59:28.0320 (UTC) FILETIME=[563B0400:01CBC3BB] Cc: sidr@ietf.org Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:56:09 -0000 On Feb 3, 2011, at 10:47 AM, Stephen Kent wrote: >=20 > I'm a bit puzzled by your final comment above. >=20 > Path secruity includes the origin AS, and the RPKI is the mechanism = adopted by SIDR to validate the origin AS assertion for an AS path. So, = in that sense, more extensive path secruity approaches will rely on the = RPKI, at least for the origin AS. >=20 > I have assumed that folks planned to take advantage of the ASN = assertions in RPKI certs in support of path security mechanisms, in some = form. (For origin AS verification we need only the address assertions in = certs, but we have always described the RPKI as encompassing both = address and ASN allocations.) >=20 > I think reliance on the RPKI for validated assertions re both types of = resources is appropriate for path secruity, irrespective of the = mechanisms used to verify As path info. I agree with everything you say in the text above - I'm merely referring = to the WG charter issues that quelled previous discussions of path = _anything on this mailing list and in this working group in the past. I = trust I don't need to provide references.. -danny= From christopher.morrow@gmail.com Thu Feb 3 08:35:35 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DE63A6A1E for ; Thu, 3 Feb 2011 08:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiHO5nLhvzr0 for ; Thu, 3 Feb 2011 08:35:35 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D2A1F3A6A15 for ; Thu, 3 Feb 2011 08:35:34 -0800 (PST) Received: by ewy8 with SMTP id 8so808796ewy.31 for ; Thu, 03 Feb 2011 08:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SoS2xc5DApnku2eBLx+gJZMXcIWDPmUDYzhCEOYIfS4=; b=jUkhb4rPYZCRA3x9WH3bq3ppGbDvoGssnNfJTB6ml/4ZRUDVu1mm9WDP7PPo6u+SyU e01/B+Ip3kmuqUvLtIXtFthOPXLl6ViNafTRRAMXnOyb76dVR2oxoJUfksN0uFr/jkbu kqNYJ26+eUJVJjhvqp9VBGEuLc5kAh6QaR1kg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vdYarLHpI3o+lUP5fv1dLetPV2wB/y9YxS+4IYum3IbRycXrqDXYy5850BY6trVkg8 cYeLw8KoVR8Z1BbpRqoy3hUMweOjwicnL6Wll805MYAAivZYxkHiGFO+DbCLWbTgZOE+ 8LauoL1f/R2/WKy5WyrO566SawhDzXVKw9098= MIME-Version: 1.0 Received: by 10.213.33.80 with SMTP id g16mr13665607ebd.88.1296751136818; Thu, 03 Feb 2011 08:38:56 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.213.113.6 with HTTP; Thu, 3 Feb 2011 08:38:56 -0800 (PST) In-Reply-To: <1EFD7809-67E8-45F8-85C6-95A12680870B@tcb.net> References: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> <1EFD7809-67E8-45F8-85C6-95A12680870B@tcb.net> Date: Thu, 3 Feb 2011 11:38:56 -0500 X-Google-Sender-Auth: OUs97iPUzjUY8R1ui3Hnzp_Imsc Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:35:35 -0000 On Thu, Feb 3, 2011 at 10:59 AM, Danny McPherson wrote: > > On Feb 3, 2011, at 10:47 AM, Stephen Kent wrote: >> >> I'm a bit puzzled by your final comment above. >> >> Path secruity includes the origin AS, and the RPKI is the mechanism adop= ted by SIDR to validate the origin AS assertion for an AS path. So, in that= sense, more extensive path secruity approaches will rely on the RPKI, at l= east for the origin AS. >> >> I have assumed that folks planned to take advantage of the ASN assertion= s in RPKI certs in support of path security mechanisms, in some form. (For = origin AS verification we need only the address assertions in certs, but we= have always described the RPKI as encompassing both address and ASN alloca= tions.) >> >> I think reliance on the RPKI for validated assertions re both types of r= esources is appropriate for path secruity, irrespective of the mechanisms u= sed to verify As path info. > > I agree with everything you say in the text above - I'm merely referring = to the WG charter issues that quelled previous discussions of path _anythin= g on this mailing list and in this working group in the past. =A0I trust I = don't need to provide references.. and if the charter is amended to include 'hey, we also should try to secure the path, eh?' that'd bring this to a close, yes? (noting that I do think path verification/validation/security is important and I think we should address it in SIDR) -chris From Sandra.Murphy@cobham.com Thu Feb 3 08:40:51 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A561F3A6A19 for ; Thu, 3 Feb 2011 08:40:51 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoDD1VvBboVI for ; Thu, 3 Feb 2011 08:40:50 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B6FC33A6A18 for ; Thu, 3 Feb 2011 08:40:50 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p13GiCht011676; Thu, 3 Feb 2011 10:44:12 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p13GiClX014476; Thu, 3 Feb 2011 10:44:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Feb 2011 11:35:22 -0500 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03A9C4B9@nemo.columbia.ads.sparta.com> In-Reply-To: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] new draft Thread-Index: AcvAOjGiREQBkRoPSDenCad86XHRgwDhcNeQ References: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> From: "Murphy, Sandra" To: "Danny McPherson" , Cc: "Murphy, Sandra" Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 16:40:51 -0000 The working group charter does not currently address path security. But there is always the possibility of modification of the charter, particularly as we seem to have finally managed to achieve consensus on a lot of our current work. --Sandy > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Danny McPherson > Sent: Saturday, January 29, 2011 11:57 PM > To: sidr@ietf.org > Subject: Re: [sidr] new draft >=20 >=20 > On Jan 27, 2011, at 12:16 PM, Stephen Kent wrote: >=20 > > > > I'd like SIDR to consider adopting a threat model for BGP path secruity > > as a WG item, and offer this as a starting point for the discussion (if > > the WG agrees to pursue this topic). >=20 >=20 > Thanks Steve for posting this, as many have noted path security > is necessary and very important to secure inter-domain routing. >=20 > For the chairs, > As a point of order, are we agreeing now that the WG is going to address > path security? In resource certification repositories? or routing > protocols > themselves? Given that my _comments previously were constrained by > this, I do hope we agree addressing path security will now be in charter > and > within scope of the WG - or perhaps we create a new WG that works on items > beyond resource certification and RPKI and focuses on routing protocols > - or if they're attempting to adapt current protocols (e.g., BGP) then the > extensions be performed in those respective working groups (e.g., IDR)? >=20 > That said, I do hope we don't assume that discussions of path security in > a > routing protocol should be constrained by the RPKI architecture itself. >=20 > -danny >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Thu Feb 3 13:50:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B093A6A4F for ; Thu, 3 Feb 2011 13:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vjt2mVKtJYh for ; Thu, 3 Feb 2011 13:50:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 560C83A6A4A for ; Thu, 3 Feb 2011 13:50:36 -0800 (PST) Received: from dhcp89-089-123.bbn.com ([128.89.89.123]:49209) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pl77n-000Jxb-5S; Thu, 03 Feb 2011 16:53:59 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <1EFD7809-67E8-45F8-85C6-95A12680870B@tcb.net> References: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> <1EFD7809-67E8-45F8-85C6-95A12680870B@tcb.net> Date: Thu, 3 Feb 2011 16:50:23 -0500 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 21:50:37 -0000 At 10:59 AM -0500 2/3/11, Danny McPherson wrote: >... > >I agree with everything you say in the text above - I'm merely >referring to the WG charter issues that quelled previous discussions >of path _anything on this mailing list and in this working group in >the past. I trust I don't need to provide references.. > >-danny Danny, I agree that the charter issue needs to be addressed. I was just replying to your comment re reliance on the RPKI. Steve From christopher.morrow@gmail.com Thu Feb 3 18:26:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DCE3A67A4 for ; Thu, 3 Feb 2011 18:26:45 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvd7yF2ORy6N for ; Thu, 3 Feb 2011 18:26:44 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 598713A679F for ; Thu, 3 Feb 2011 18:26:43 -0800 (PST) Received: by eyd10 with SMTP id 10so1144529eyd.31 for ; Thu, 03 Feb 2011 18:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=e6NKhnywnXhZElT9Jx9XgbfOPVeimxjYu0kFOdCaEsI=; b=e/PA+07nSXPMUlsVS+GIstE3f5V3YCN73qE80ccniQZwfz/bJ3WyipEz5SJUAIClmT J4bUe9nXyP1trXa9mihZJU3aMQKGWf45Av1tuLUjFdSZ3S9wQIFCOQTqpY2E5QJWocDW oAcgJScGFJUuzulMXfJScfjbCnj2LF59m8Mh8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=v7C8yp5TSNWzRYdwORsUotU2nXNun3v7eDHZnA+5r+wZUCel7BFMzPL88rXFTYs3x6 ih5DhDLdUF2gOW+i+Cy3ipgMBgPqzv2lE7TQxKnhp06xyqDYgiUR6kanMDuuFdK761uJ ywi70UcSFfhYh+fiz3LEfiMQFT0TUTMiommz8= MIME-Version: 1.0 Received: by 10.213.35.3 with SMTP id n3mr4584855ebd.36.1296786607020; Thu, 03 Feb 2011 18:30:07 -0800 (PST) Received: by 10.213.113.6 with HTTP; Thu, 3 Feb 2011 18:30:06 -0800 (PST) Date: Thu, 3 Feb 2011 21:30:06 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] regarding the status of: draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 02:26:45 -0000 Howdy SIDR folk, So, apparently I (at least) had thought this was taken care of sometime after the Maastricht in-person meeting where I believe Terry said he'd write this doc, in that the WG had already decided there was a need for IANA registries and some guidance to the IANA function about how to deal with the registries (what sort of requests they may receive and such). Apparently this sat in a dark email-hole until Mr Bryant piped up with a 'what is up with this doc? Why is it not a WG Doc already and on it's merry way to IESG/AD review?' So, in keeping with that set of ideals, in 48 hrs if no one complains on-list otherwise this doc is a WC doc. We'll get Terry to re-spin the name and then start WGLC. Thanks! -Chris From christopher.morrow@gmail.com Thu Feb 3 18:29:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B403A6801 for ; Thu, 3 Feb 2011 18:29:29 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5APkJRIWNvOo for ; Thu, 3 Feb 2011 18:29:29 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B6B7A3A679F for ; Thu, 3 Feb 2011 18:29:28 -0800 (PST) Received: by eyd10 with SMTP id 10so1145050eyd.31 for ; Thu, 03 Feb 2011 18:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=QllZ1dMWtXISPTWgNzgCq9jEyUQfEc+cYfvsO2X52Vg=; b=vP7VwG3xGXjfB0ocjnHNspWcqvRnHnzKBXEA71AwbZkN7io2CtiJaNt0nJk8RhJPz5 IqTNmws+9c3Ua/b3ZY7kP3XGffqHL3jeYX2SI7sXLgHbK8QhNnDMKZN6W+rt3IL3GXqs 9hdE+x0iZ2sqMU+eEtbi5pDx33RsbEGpjrJ6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=KtF9IGsa4qUpuCModeH4szOVtLqJmF559TxcvKQVW4trRg4ae7WwpOTKSZgayBws0W uA8a4K1hZCHoom7tA8Djc85h+VBSuRkorO/gH+8+mpQOAlua2lRSQp+YrNSekr+ZQAFw woGgvXU2A1sstFF7Rr+TdquvTJ2q9j+oksP6g= MIME-Version: 1.0 Received: by 10.213.27.68 with SMTP id h4mr14490138ebc.10.1296786771995; Thu, 03 Feb 2011 18:32:51 -0800 (PST) Received: by 10.213.113.6 with HTTP; Thu, 3 Feb 2011 18:32:51 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Feb 2011 21:32:51 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sidr] regarding the status of: draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 02:29:30 -0000 Oh, actually I'm confused, the timeline on the doc is the same, only this is advice to IANA about what kind of objects (RPKI Objects) the IANA is to create/generate in support of RPKI. >From the summary: "The signed objects described here that IANA will issue are the unallocated, reserved, special use IPv4 and IPv6 address blocks, and reserved Autonomous System numbers. These number resources are managed by IANA for the IETF, and thus IANA bears the responsibility of issuing the corresponding RPKI objects. " -Chris On Thu, Feb 3, 2011 at 9:30 PM, Christopher Morrow wrote: > Howdy SIDR folk, > > So, apparently I (at least) had thought this was taken care of > sometime after the Maastricht in-person meeting where I believe Terry > said he'd write this doc, in that the WG had already decided there was > a need for IANA registries and some guidance to the IANA function > about how to deal with the registries (what sort of requests they may > receive and such). Apparently this sat in a dark email-hole until Mr > Bryant piped up with a 'what is up with this doc? Why is it not a WG > Doc already and on it's merry way to IESG/AD review?' > > So, in keeping with that set of ideals, in 48 hrs if no one complains > on-list otherwise this doc is a WC doc. We'll get Terry to re-spin the > name and then start WGLC. > > Thanks! > -Chris > > From terry.manderson@icann.org Thu Feb 3 18:33:50 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D86E3A67B1 for ; Thu, 3 Feb 2011 18:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okYVJlXi78aF for ; Thu, 3 Feb 2011 18:33:49 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 36B933A67AF for ; Thu, 3 Feb 2011 18:33:49 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 3 Feb 2011 18:37:12 -0800 From: Terry Manderson To: Christopher Morrow , "sidr@ietf.org" Date: Thu, 3 Feb 2011 18:37:10 -0800 Thread-Topic: [sidr] regarding the status of: draft-manderson-iana-objects-03.txt Thread-Index: AcvEE+EY6pqbo4KqRGK+Cn90xp/X2AAAIrhi Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] regarding the status of: draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 02:33:50 -0000 ... so Chris is moving faster than I am :) I'll have the public -00 uploaded in a few minutes. Cheers Terry On 4/02/11 12:32 PM, "Christopher Morrow" wrote: > Oh, actually I'm confused, the timeline on the doc is the same, only > this is advice to IANA about what kind of objects (RPKI Objects) the > IANA is to create/generate in support of RPKI. >=20 > From the summary: > "The signed objects described here that IANA will issue are the > unallocated, reserved, special use IPv4 and IPv6 address blocks, and > reserved Autonomous System numbers. These number resources are > managed by IANA for the IETF, and thus IANA bears the responsibility > of issuing the corresponding RPKI objects. " >=20 > -Chris > >=20 > On Thu, Feb 3, 2011 at 9:30 PM, Christopher Morrow > wrote: >> Howdy SIDR folk, >> >> So, apparently I (at least) had thought this was taken care of >> sometime after the Maastricht in-person meeting where I believe Terry >> said he'd write this doc, in that the WG had already decided there was >> a need for IANA registries and some guidance to the IANA function >> about how to deal with the registries (what sort of requests they may >> receive and such). Apparently this sat in a dark email-hole until Mr >> Bryant piped up with a 'what is up with this doc? Why is it not a WG >> Doc already and on it's merry way to IESG/AD review?' >>=20 >> So, in keeping with that set of ideals, in 48 hrs if no one complains >> on-list otherwise this doc is a WC doc. We'll get Terry to re-spin the >> name and then start WGLC. >>=20 >> Thanks! >> -Chris >> >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Thu Feb 3 18:38:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74033A6984 for ; Thu, 3 Feb 2011 18:38:18 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6JnZuzgcwx3 for ; Thu, 3 Feb 2011 18:38:18 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 2EDFE3A68E7 for ; Thu, 3 Feb 2011 18:38:18 -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; Thu, 3 Feb 2011 18:41:42 -0800 From: Terry Manderson To: Christopher Morrow , "sidr@ietf.org" Date: Thu, 3 Feb 2011 18:41:40 -0800 Thread-Topic: [sidr] regarding the status of: draft-manderson-iana-objects-03.txt Thread-Index: AcvEE+EY6pqbo4KqRGK+Cn90xp/X2AAAIrhiAAAoO5I= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] regarding the status of: draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 02:38:19 -0000 -00 indv. draft available at http://www.ietf.org/id/draft-manderson-iana-objects-00.txt ..T On 4/02/11 12:37 PM, "Terry Manderson" wrote: > ... so Chris is moving faster than I am :) >=20 > I'll have the public -00 uploaded in a few minutes. >=20 > Cheers > Terry >=20 >=20 > On 4/02/11 12:32 PM, "Christopher Morrow" > wrote: >=20 >> Oh, actually I'm confused, the timeline on the doc is the same, only >> this is advice to IANA about what kind of objects (RPKI Objects) the >> IANA is to create/generate in support of RPKI. >>=20 >> From the summary: >> "The signed objects described here that IANA will issue are the >> unallocated, reserved, special use IPv4 and IPv6 address blocks, and >> reserved Autonomous System numbers. These number resources are >> managed by IANA for the IETF, and thus IANA bears the responsibility >> of issuing the corresponding RPKI objects. " >>=20 >> -Chris >> >>=20 >> On Thu, Feb 3, 2011 at 9:30 PM, Christopher Morrow >> wrote: >>> Howdy SIDR folk, >>> >>> So, apparently I (at least) had thought this was taken care of >>> sometime after the Maastricht in-person meeting where I believe Terry >>> said he'd write this doc, in that the WG had already decided there was >>> a need for IANA registries and some guidance to the IANA function >>> about how to deal with the registries (what sort of requests they may >>> receive and such). Apparently this sat in a dark email-hole until Mr >>> Bryant piped up with a 'what is up with this doc? Why is it not a WG >>> Doc already and on it's merry way to IESG/AD review?' >>>=20 >>> So, in keeping with that set of ideals, in 48 hrs if no one complains >>> on-list otherwise this doc is a WC doc. We'll get Terry to re-spin the >>> name and then start WGLC. >>>=20 >>> Thanks! >>> -Chris >>> >>>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Fri Feb 4 06:29:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D0F3A68E9 for ; Fri, 4 Feb 2011 06:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg02OE2vtL5G for ; Fri, 4 Feb 2011 06:29:38 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 36AD33A68F8 for ; Fri, 4 Feb 2011 06:29:37 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p14EX2Th024984 for ; Fri, 4 Feb 2011 08:33:02 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p14EX1MT017096 for ; Fri, 4 Feb 2011 08:33:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC478.4623CAF4" Date: Fri, 4 Feb 2011 09:31:55 -0500 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03A9C674@nemo.columbia.ads.sparta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cleanup actions Thread-Index: AcvEeEXUoDdoM+0PTzK2LeakYZLLrg== From: "Murphy, Sandra" To: Cc: "Murphy, Sandra" Subject: [sidr] cleanup actions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:29:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC478.4623CAF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You'll soon be seeing a small number of cleanup actions - two drafts whose consensus was never officially called and reminders to some authors that new versions of their draft are needed to address on list comments. Look for the consensus calls on the list here shortly and for the author reminders privately thereafter. =20 --Sandra Murphy, speaking as wg co-chair, appropriate ceremonial wg garb donned ------_=_NextPart_001_01CBC478.4623CAF4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You’ll soon be seeing a small number of cleanup actions – two drafts whose consensus was never officially called = and reminders to some authors that new versions of their draft are needed to address = on list comments.  Look for the consensus calls on the list here shortly = and for the author reminders privately thereafter.

 

--Sandra Murphy, speaking as wg co-chair, appropriate ceremonial wg garb donned

------_=_NextPart_001_01CBC478.4623CAF4-- From Sandra.Murphy@cobham.com Fri Feb 4 06:42:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0AB3A693A for ; Fri, 4 Feb 2011 06:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TM-LaL3hdHn for ; Fri, 4 Feb 2011 06:42:41 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B72A03A6930 for ; Fri, 4 Feb 2011 06:42:41 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p14Ek6oq025227 for ; Fri, 4 Feb 2011 08:46:06 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p14Ek3x5017748 for ; Fri, 4 Feb 2011 08:46:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Feb 2011 09:37:54 -0500 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03A9C676@nemo.columbia.ads.sparta.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LC for draft-ietf-sidr-signed-object-01 Thread-Index: AcvEeRt4HKQTQaFuTX6gyucHI5ggRQ== References: From: "Murphy, Sandra" To: Cc: "Murphy, Sandra" Subject: Re: [sidr] WG LC for draft-ietf-sidr-signed-object-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:42:42 -0000 The WGLC period concluded long ago. The authors submitted a new version on 31 Dec 2010, which addressed the remaining comments. I am satisfied that the working group consensus is that the new draft is worthy of publication and I have started the process for publication. Sorry for the delayed notice to the group. --Sandy, speaking with wg co-chair snood on > -----Original Message----- > From: Murphy, Sandra > Sent: Friday, November 05, 2010 4:12 PM > To: sidr@ietf.org > Subject: WG LC for draft-ietf-sidr-signed-object-01 >=20 > The authors of draft-ietf-sidr-signed-object-01 > (http://tools.ietf.org/html/draft-ietf-sidr-signed-object-01) have > requested a working group last call. >=20 > The chairs ask the working group to consider this draft and decide if it > is worthy of publication. >=20 > This draft has not been through a last call before and next week is the > IETF week, so the last call will end on 26 November. >=20 > --Sandy From Sandra.Murphy@cobham.com Fri Feb 4 06:42:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0993A6930 for ; Fri, 4 Feb 2011 06:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2AyoTGrSBwk for ; Fri, 4 Feb 2011 06:42:41 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7D8E03A68E9 for ; Fri, 4 Feb 2011 06:42:40 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p14Ek5B6025223 for ; Fri, 4 Feb 2011 08:46:05 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p14Ek3x3017748 for ; Fri, 4 Feb 2011 08:46:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Feb 2011 09:37:43 -0500 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03A9C675@nemo.columbia.ads.sparta.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LC for draft-ietf-sidr-roa-validation-10 Thread-Index: AcvEeRT4QC6hg+EfTQmQVV47h6Jx2w== References: From: "Murphy, Sandra" To: Cc: "Murphy, Sandra" Subject: Re: [sidr] WG LC for draft-ietf-sidr-roa-validation-10 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:42:42 -0000 There was a short intense discussion of the intended RFC status of this draft and the draft draft-ietf-sidr-pfx-validate: Informational or Standards. As wg chair, I saw several opinions expressed (one of them mine as wg member), none agreeing. A query went to a handful of potential customers of this work (implementers and operators), asking that if this issue mattered to them they express their opinion on the list. No opinion was expressed. The on-list opinions varied too much to call wg consensus for change in this matter. Therefore no change in status is necessary in this draft or in draft-ietf-sidr-pfx-validate. The WGLC period concluded long ago. I am satisfied that the working group consensus is that the draft is worthy of publication. I have started the process of advancing the draft for publication. Sorry for the delayed notice to the group. --Sandy, speaking with wg co-chair snood on > -----Original Message----- > From: Murphy, Sandra > Sent: Thursday, November 18, 2010 12:02 AM > To: sidr@ietf.org > Subject: WG LC for draft-ietf-sidr-roa-validation-10 >=20 >=20 > Geoff Huston has requested a WG LC for draft "Validation of Route > Origination using the Resource Certificate PKI and ROAs". >=20 > The document and the draft version history are available at > http://tools.ietf.org/wg/sidr/draft-ietf-sidr-roa-validation. >=20 > The Last Call will end Wed, 1 Dec 2010 (AOE). >=20 > As usual, please address all comments to the WG mailing list, and > please be clear in your comments to this last call if you are > supporting the document's submission to the IESG or if you are > opposed. If you are opposed, please indicate why. >=20 > --Sandy, speaking with wg chair turban on From iesg-secretary@ietf.org Mon Feb 7 08:14:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7293A6E31; Mon, 7 Feb 2011 08:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFKO6S9tVOTY; Mon, 7 Feb 2011 08:14:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FF73A6E02; Mon, 7 Feb 2011 08:14:05 -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: 3.12 Message-ID: <20110207161405.21298.54142.idtracker@localhost> Date: Mon, 07 Feb 2011 08:14:05 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (An Infrastructure to Support Secure Internet Routing) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 07 Feb 2011 16:14:06 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'An Infrastructure to Support Secure Internet Routing' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-21. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ The following IPR Declarations may be related to this I-D: /ipr/1204/ From iesg-secretary@ietf.org Mon Feb 7 08:16:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348783A6E37; Mon, 7 Feb 2011 08:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNu90XSUhLv0; Mon, 7 Feb 2011 08:16:51 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793F13A6E18; Mon, 7 Feb 2011 08:16:51 -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: 3.12 Message-ID: <20110207161651.21361.65102.idtracker@localhost> Date: Mon, 07 Feb 2011 08:16:51 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Certificate Policy (CP) for the Resource PKI (RPKI) to BCP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 07 Feb 2011 16:16:52 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Certificate Policy (CP) for the Resource PKI (RPKI' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-21. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-cp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-cp/ The following IPR Declarations may be related to this I-D: /ipr/1204/ From iesg-secretary@ietf.org Mon Feb 7 08:40:17 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0273A6E14; Mon, 7 Feb 2011 08:40:17 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn+H3v4wCfUp; Mon, 7 Feb 2011 08:40:17 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 364F73A6D6E; Mon, 7 Feb 2011 08:40:17 -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: 3.12 Message-ID: <20110207164017.28617.88833.idtracker@localhost> Date: Mon, 07 Feb 2011 08:40:17 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (A Profile for X.509 PKIX Resource Certificates) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 07 Feb 2011 16:40:18 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'A Profile for X.509 PKIX Resource Certificates' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-21. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ Please note that this document contains a downref to RFC 2986 No IPR declarations have been submitted directly on this I-D. From Sandra.Murphy@cobham.com Mon Feb 7 09:39:09 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB9B3A6E4C for ; Mon, 7 Feb 2011 09:39:09 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKwAWdseofxg for ; Mon, 7 Feb 2011 09:39:08 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 32FBD3A6E47 for ; Mon, 7 Feb 2011 09:39:07 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p17HdBld031103 for ; Mon, 7 Feb 2011 11:39:11 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p17HdBng028591 for ; Mon, 7 Feb 2011 11:39:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Feb 2011 12:37:25 -0500 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03A9C871@nemo.columbia.ads.sparta.com> In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC03A9C675@nemo.columbia.ads.sparta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LC for draft-ietf-sidr-roa-validation-10 Thread-Index: AcvEeRT4QC6hg+EfTQmQVV47h6Jx2wCcxA9A References: <5ABE30CE099A524CBF95C715D37BCACC03A9C675@nemo.columbia.ads.sparta.com> From: "Murphy, Sandra" To: "Murphy, Sandra" , Cc: "Murphy, Sandra" Subject: Re: [sidr] WG LC for draft-ietf-sidr-roa-validation-10 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:39:09 -0000 I have had two requests for clarification of what I said below. The roa-validation draft is currently "Intended status: Informational". There will be no change, so it stays Informational. The pfx-validate draft is currently "Intended status: Standards Track". There will be no change, so it stays Standards Track. Is that clearer? --Sandy > -----Original Message----- > From: Murphy, Sandra > Sent: Friday, February 04, 2011 9:38 AM > To: sidr@ietf.org > Cc: Murphy, Sandra > Subject: RE: WG LC for draft-ietf-sidr-roa-validation-10 >=20 > There was a short intense discussion of the intended RFC status of this > draft and the draft draft-ietf-sidr-pfx-validate: Informational or > Standards. As wg chair, I saw several opinions expressed (one of them > mine as wg member), none agreeing. >=20 > A query went to a handful of potential customers of this work > (implementers and operators), asking that if this issue mattered to them > they express their opinion on the list. >=20 > No opinion was expressed. >=20 > The on-list opinions varied too much to call wg consensus for change in > this matter. >=20 > Therefore no change in status is necessary in this draft or in draft-ietf- > sidr-pfx-validate. >=20 > The WGLC period concluded long ago. I am satisfied that the working group > consensus is that the draft is worthy of publication. I have started the > process of advancing the draft for publication. Sorry for the delayed > notice to the group. >=20 > --Sandy, speaking with wg co-chair snood on >=20 > > -----Original Message----- > > From: Murphy, Sandra > > Sent: Thursday, November 18, 2010 12:02 AM > > To: sidr@ietf.org > > Subject: WG LC for draft-ietf-sidr-roa-validation-10 > > > > > > Geoff Huston has requested a WG LC for draft "Validation of Route > > Origination using the Resource Certificate PKI and ROAs". > > > > The document and the draft version history are available at > > http://tools.ietf.org/wg/sidr/draft-ietf-sidr-roa-validation. > > > > The Last Call will end Wed, 1 Dec 2010 (AOE). > > > > As usual, please address all comments to the WG mailing list, and > > please be clear in your comments to this last call if you are > > supporting the document's submission to the IESG or if you are > > opposed. If you are opposed, please indicate why. > > > > --Sandy, speaking with wg chair turban on From randy@psg.com Mon Feb 7 10:33:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D29D3A6E42 for ; Mon, 7 Feb 2011 10:33: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGTmtIMD6M8z for ; Mon, 7 Feb 2011 10:33:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5C0173A6A2F for ; Mon, 7 Feb 2011 10:33:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PmVtl-000IgT-15; Mon, 07 Feb 2011 18:33:17 +0000 Date: Mon, 07 Feb 2011 10:33:20 -0800 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC03A9C871@nemo.columbia.ads.sparta.com> References: <5ABE30CE099A524CBF95C715D37BCACC03A9C675@nemo.columbia.ads.sparta.com> <5ABE30CE099A524CBF95C715D37BCACC03A9C871@nemo.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] WG LC for draft-ietf-sidr-roa-validation-10 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:33:16 -0000 > I have had two requests for clarification of what I said below. > > The roa-validation draft is currently "Intended status: Informational". > There will be no change, so it stays Informational. > > The pfx-validate draft is currently "Intended status: Standards Track". > There will be no change, so it stays Standards Track. > > Is that clearer? quite. :) thank you. makes sense to me. randy From Internet-Drafts@ietf.org Mon Feb 7 13:45:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8963A6ABD; Mon, 7 Feb 2011 13:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40lnxbV4lhcn; Mon, 7 Feb 2011 13:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B083A6A0B; Mon, 7 Feb 2011 13:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207214501.1183.71403.idtracker@localhost> Date: Mon, 07 Feb 2011 13:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-pfx-validate-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGP Prefix Origin Validation Author(s) : P. Mohapatra, et al. Filename : draft-ietf-sidr-pfx-validate-01.txt Pages : 11 Date : 2011-02-07 To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-pfx-validate-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-07134130.I-D@ietf.org> --NextPart-- From christopher.morrow@gmail.com Mon Feb 7 17:12:00 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49683A69FB for ; Mon, 7 Feb 2011 17:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6GloMASdHnD for ; Mon, 7 Feb 2011 17:11:59 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 9144D3A69D3 for ; Mon, 7 Feb 2011 17:11:59 -0800 (PST) Received: by ewy8 with SMTP id 8so2982946ewy.31 for ; Mon, 07 Feb 2011 17:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e4u8vf7TvdtGtQip0xgkOxCXfPfQnJ2oUlGNtSXGHbU=; b=t3Hrgi8V4EbozQuo3hZVTBwramcFgfk8ayagOg14gsXFJO9sD/3jN1gewJh5b2ypEh XCrti3aNLOkazq/VpGeheJ1ndoMNbiYPzFcUDzLAOn/pBHCKYe0tsb6HtbEuxnhpX2Bj 9uuoBtQlgvXWpYNYr0ZoZB6hbi+XkxbET+bZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cO/Jkp7efUTZl6AU+n51SPwcCwf3kmouy1kJGS3G4eY8HwvImyG05EUvMMfRXKU+84 q+w/hgW4aOdVA2oOD5m+CirN88UYy0mQBYHrkvNHew7+1Cy6J6T3y+7UfaKrdlfLTmx9 kfs/DswpE6c0AsVhxqdTMZfv/ZnlUFKDUsJAM= MIME-Version: 1.0 Received: by 10.213.10.194 with SMTP id q2mr1299551ebq.8.1297127523445; Mon, 07 Feb 2011 17:12:03 -0800 (PST) Received: by 10.213.106.11 with HTTP; Mon, 7 Feb 2011 17:12:03 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Feb 2011 20:12:03 -0500 Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] regarding the status of: draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 01:12:00 -0000 Helo, 3 days on and... no commentary, so: o this is now a WG doc (http://www.ietf.org/id/draft-manderson-iana-objects-00.txt) o terry ought to change the title and resubmit o shortly we'll make some WGLC motions for this as well (like tomorrow 2/9/2011 so terry has time from down-under to read/post) thanks! -Chris On Thu, Feb 3, 2011 at 9:37 PM, Terry Manderson wrote: > ... so Chris is moving faster than I am :) > > I'll have the public -00 uploaded in a few minutes. > > Cheers > Terry > > > On 4/02/11 12:32 PM, "Christopher Morrow" > wrote: > >> Oh, actually I'm confused, the timeline on the doc is the same, only >> this is advice to IANA about what kind of objects (RPKI Objects) the >> IANA is to create/generate in support of RPKI. >> >> From the summary: >> "The signed objects described here that IANA will issue are the >> =A0 =A0unallocated, reserved, special use IPv4 and IPv6 address blocks, = and >> =A0 =A0reserved Autonomous System numbers. =A0These number resources are >> =A0 =A0managed by IANA for the IETF, and thus IANA bears the responsibil= ity >> =A0 =A0of issuing the corresponding RPKI objects. =A0" >> >> -Chris >> >> >> On Thu, Feb 3, 2011 at 9:30 PM, Christopher Morrow >> wrote: >>> Howdy SIDR folk, >>> >>> So, apparently I (at least) had thought this was taken care of >>> sometime after the Maastricht in-person meeting where I believe Terry >>> said he'd write this doc, in that the WG had already decided there was >>> a need for IANA registries and some guidance to the IANA function >>> about how to deal with the registries (what sort of requests they may >>> receive and such). Apparently this sat in a dark email-hole until Mr >>> Bryant piped up with a 'what is up with this doc? Why is it not a WG >>> Doc already and on it's merry way to IESG/AD review?' >>> >>> So, in keeping with that set of ideals, in 48 hrs if no one complains >>> on-list otherwise this doc is a WC doc. We'll get Terry to re-spin the >>> name and then start WGLC. >>> >>> Thanks! >>> -Chris >>> >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > From terry.manderson@icann.org Mon Feb 7 17:46:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F403A6D6C for ; Mon, 7 Feb 2011 17:46:06 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlzxtzWQFt4e for ; Mon, 7 Feb 2011 17:46:05 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 168EB3A6A32 for ; Mon, 7 Feb 2011 17:46:05 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 7 Feb 2011 17:46:10 -0800 From: Terry Manderson To: sidr Date: Mon, 7 Feb 2011 17:46:07 -0800 Thread-Topic: new draft draft-manderson-sidr-geo Thread-Index: AcvHMfPul1P4EM8iNUCWtxxIZIKR4g== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] new draft draft-manderson-sidr-geo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 01:46:06 -0000 All, I have uploaded a new draft at http://www.ietf.org/id/draft-manderson-sidr-geo-00.txt The co-authors and I would appreciate your review and feedback. I expect to be able to present this document in Prague and ask for WG adoption at that stage. Cheers Terry From Internet-Drafts@ietf.org Tue Feb 8 07:00:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1113A659A; Tue, 8 Feb 2011 07:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8zVXaTDCGhv; Tue, 8 Feb 2011 07:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21D53A67B0; Tue, 8 Feb 2011 07:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208150001.29835.15477.idtracker@localhost> Date: Tue, 08 Feb 2011 07:00:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-iana-objects-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI Objects issued by IANA Author(s) : T. Manderson, et al. Filename : draft-ietf-sidr-iana-objects-00.txt Pages : 18 Date : 2011-02-07 This document provides specific direction to IANA as to the RPKI objects it should issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-iana-objects-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-iana-objects-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08065158.I-D@ietf.org> --NextPart-- From kent@bbn.com Tue Feb 8 16:41:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4773A6857 for ; Tue, 8 Feb 2011 16:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHTfuATa3BDE for ; Tue, 8 Feb 2011 16:41:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 790753A6824 for ; Tue, 8 Feb 2011 16:41:41 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40615 helo=[69.168.220.97]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pmy7v-000KuG-Ie for sidr@ietf.org; Tue, 08 Feb 2011 19:41:49 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 8 Feb 2011 19:41:41 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 00:41:42 -0000 I concur with Geoff re the desirability of the staging period. I disagree with Rob's suggestion that the staging period is at the wrong place in the document, or in the phased approach to key rollover. From my perspective, the fundamental rationale for the staring period is two-fold: - we want a delimited interval after which a CA can have reasonable confidence that all RPs will have retrieved the new CA key, before transiting to a new CA key and subordinate, signed products. - we also want a delimited interval for RPs so that they can acquire a new CA key prior to the transition to that key for subordinate signed products. Because of the naming conventions adopted by the repository design, most of these new products overwrite old ones, so we want to maximize the likelihood that an RP gets a consistent set of data. I agree with Rob that there is no delimited period that will guarantee that both CAs and RPs are in sync re a CA key transition. But, that does not mean that we ought not select and publish such a period, consistent with the other time intervals that we have published, e.g., the frequency at which RPs SHOULD query the repository. As a compromise, we could re-phrase the staging period discussion to RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not just you, Rob, :-)) feels strongly. I also agree that, as Roque noted, in the case of an emergency rekey, the 24-hour staging period may be inappropriate. But an emergency rekey is not the same as a planned key rollover. I suggest that we note this difference up front and say that, in case of an emergency, the CA re-issuing the cert which is being re-keyed SHOULD consider the impact on routing of a quicker transition to a new cert+key, and behave as it sees fit, given the circumstances surrounding the rekey. Geoff, would you be comfortable with this rewording for emergency rekey, and with the MUST->RECOMMEND, if Sandy determines that there is WG consensus for that change? Steve From gih@apnic.net Tue Feb 8 22:13:31 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E527D3A690B for ; Tue, 8 Feb 2011 22:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.005 X-Spam-Level: X-Spam-Status: No, score=-101.005 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMt6G+X9PjMC for ; Tue, 8 Feb 2011 22:13:31 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4C04F3A690A for ; Tue, 8 Feb 2011 22:13:30 -0800 (PST) Received: from dhcp75.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4F845B637D; Wed, 9 Feb 2011 16:13:36 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 9 Feb 2011 17:13:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <682C1A5E-E2CD-4842-8BC8-26B61E7B01B9@apnic.net> References: To: Stephen Kent X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org Subject: Re: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 06:13:32 -0000 On 09/02/2011, at 11:41 AM, Stephen Kent wrote: > I concur with Geoff re the desirability of the staging period. I = disagree with Rob's suggestion that the staging period is at the wrong = place in the document, or in the phased approach to key rollover. >=20 > =46rom my perspective, the fundamental rationale for the staring = period is two-fold: >=20 > - we want a delimited interval after which a CA can have = reasonable confidence that all RPs will have retrieved the new CA key, = before transiting to a new CA key and subordinate, signed products. >=20 > - we also want a delimited interval for RPs so that they can = acquire a new CA key prior to the transition to that key for subordinate = signed products. > Because of the naming conventions adopted by the repository design, = most of these new products overwrite old ones, so we want to maximize = the likelihood that an RP gets a consistent set of data. >=20 > I agree with Rob that there is no delimited period that will guarantee = that both CAs and RPs are in sync re a CA key transition. But, that does = not mean that we ought not select and publish such a period, consistent = with the other time intervals that we have published, e.g., the = frequency at which RPs SHOULD query the repository. >=20 > As a compromise, we could re-phrase the staging period discussion to = RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not just = you, Rob, :-)) feels strongly. >=20 > I also agree that, as Roque noted, in the case of an emergency rekey, = the 24-hour staging period may be inappropriate. But an emergency rekey = is not the same as a planned key rollover. I suggest that we note this = difference up front and say that, in case of an emergency, the CA = re-issuing the cert which is being re-keyed SHOULD consider the impact = on routing of a quicker transition to a new cert+key, and behave as it = sees fit, given the circumstances surrounding the rekey. >=20 > Geoff, would you be comfortable with this rewording for emergency = rekey, and with the MUST->RECOMMEND, if Sandy determines that there is = WG consensus for that change? sure! Geoff= From russ@cisco.com Wed Feb 9 09:41:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1F13A67A5 for ; Wed, 9 Feb 2011 09:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EakkgeuoiVsS for ; Wed, 9 Feb 2011 09:41:47 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BAD333A69EC for ; Wed, 9 Feb 2011 09:41:46 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAFhUk1AZnwM/2dsb2JhbAClSHOgc5sohVwEhH+GcYMy Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2011 17:41:56 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p19Hfu0u008806; Wed, 9 Feb 2011 17:41:56 GMT Message-ID: <4D52D1EF.2030200@cisco.com> Date: Wed, 09 Feb 2011 12:42:07 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D4454AE.6070304@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig333B491B5F58512BF96CB080" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:41:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig333B491B5F58512BF96CB080 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> 3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple >> NLRIs in a single UPDATE, given the impossibility of splitting a >> signed message while preserving the signature. >> >> I'm not certain why this would be in a requirements document. Can >> anyone explain how this directly relates to the security of BGP? IE, >> what is the direct relationship between stating that packing is no >> longer needed in BGP, and improving the security of BGP itself? >=20 > note the 'need not.' it does not say 'must not'. the point is that, i= f > there is a signature over the bundled nlri, that signature can not > survive the next bgp peer, who will unpack the nlris due to their > routing policy not sending the whole bundle to their next peer. > i.e. imagine R0 sends a bundle to its customer R1, and R1 selects some,= > but not all, routes from R0 and others from elsewhere to send to its > customer, R2. I understand the reasoning, but I'm not certain why this should be addressed as a "requirement." I could see something saying, "any proposed system should not decrease performance by x%," let people discuss what x should be. To say that a specific mechanism that will impact performance is acceptable as a "requirement," no matter what the impact is, because the authors are convinced that it "won't hurt anything," is presuming on the entire set of possible environments, and putting the requirement in a "backwards" way. Some other system may decrease performance in a different way, but the WG is not open to discussing such tradeoffs the way this is currently written. >> 3.14 A BGPsec design MUST NOT require operators to reveal proprietary >> data. This includes peering, customer, and provider relationships, an= >> ISP's internal infrastructure, etc. Though it is understood that some >> data are revealed to the savvy seeker by BGP, traceroute, etc. today. >> >> What sense does it make to say the only system which may be deployed >> is one that protects information already publicly available? This is a= >> non-requirement, and must not be included in the requirements list. >=20 > this is an absolute from many operators. It's an absolute must that information already revealed publicly in one context not be revealed in another. Interesting... It would be better to have an actual list here. I've asked, for years, for specific instances --use cases-- where specific information should not be revealed. Thus far, the only ones I've actually been given are, "we don't want a peer to know we're breaking the contract we have with them." I don't find these sorts of reasons convincing. What a requirements document should have, it seems to me, is a list of information that the operator community has determined cannot be revealed and a reason for each one. > [ and note that backup paths are not very visible in bgp or traceroute = ] Okay, so you're suggesting two things: 1. The list of the AS' a given AS is peered to should not be collated into a conveniently available list. You expect people to be forced to work for this information. 2. Backup connections should not be advertised unless they are used. In other words, only connections through which prefixes are actually being advertised should be collectable from the system at large. > bottom line: when i recieve an update for prefix P with path D C B A, i= > want firm assurance that A passed P to B, B to C, C to D, and D to me. > firm, verifiable, assurance. The question that needs to be answered here is simple: Are you trying to have verifiable proof for a court case, or are you trying to validate that the destination given actually exists through the advertising peer to the extent possible within the protocol itself. To say that one thing is "more assured," than another is to assume the answer to the question, "more assured in what terms?" > that some database says that *some* prefixes are allowed from A to B to= > C to D to me does not mean *all* are. there are vast differences in ho= w > different prefixes are handled by each hop on the route. think peer, > provider, customer relationships. First, you're assuming that in this network: A--B--C A can verify the policy between B and C somehow for a specific prefix or reachable destination. BGP simply isn't built this way. Second, you're assuming that the only way to verify things on a per prefix basis is by signing the updates. Making assumptions about a given solution set within a requirements document is a "bad thing." Don't do it= =2E Explain the requirements, not the solution. >> What does "proving the AS Path the update has traversed," prove, >> precisely? Does receiving an update through a specific path prove >> traffic sent to that destination will traverse the path listed? >=20 > no, see security section. locking down the data plane is the next high= > mountain. one at a time. You've not explained what you mean when you say you want to "lock down" the control plane. Again, what are you trying to prove? That an update passed along a certain path? Does that provide you with policy assurance? Does it prove the destination indicated exists and is reachable along the path indicated? Does it prove packets transmitted to the destination will follow this path? Or, again, are you mostly interested in proving what a peer sent to you for contract enforcement? These are all legitimate concerns, but you need to indicate which one you're actually trying to address. > of course if you have a solution which locks down both the control plan= e > and the data plane, i *extremely eagerly* await your i-d. It's called circuit switching, rather than packet switching. >> Does receiving an update prove that all destinations listed are >> reachable along the path listed? Does receiving an update prove that >> every AS along that path has agreed to forward traffic transmitted to >> the destination indicated? >=20 > yes, agreed to. of course, we can not yet guarantee that they do not Um, no it doesn't. Simply receiving an update does not prove it is "within policy" for the receiver to send traffic along the path specified to the destination specified. In fact, you can't prove this unless you expose the peering pairwise policy of every connected pair of AS' in the path. And you can't prove it unless you remove aggregation from the routing system. >> 4.3 Replay of BGP UPDATE messages need not be completely prevented, >> but a BGPsec design MUST provide a mechanism to control the window of >> exposure to replay attacks. >> >> Again, this is an assumption which I completely and totally disagree >> with. What is the window size allowed in terms of time? Is it minutes,= >> hours, days, weeks, months, or years? >=20 > tunable, i hope. i am not much worried about my research prefixes bein= g > replayed. root name servers may be. This isn't a requirement. Put a number in there, so we can discuss it. > i will be in your area 8-12 feb. glad to chat face to face. I'm in RTP, not SJ. :-) Russ --------------enig333B491B5F58512BF96CB080 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1S0fIACgkQER27sUhU9OS3kgCgh0wYRhxfPZrb4EGRkBG+Mv4s 6/4AoIfuGBuatAWtTrB3t/IVtaTtV5Nc =NWWa -----END PGP SIGNATURE----- --------------enig333B491B5F58512BF96CB080-- From christopher.morrow@gmail.com Wed Feb 9 16:38:26 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55843A67AD for ; Wed, 9 Feb 2011 16:38:26 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwF3WS8Rr9+E for ; Wed, 9 Feb 2011 16:38:26 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C175C3A672F for ; Wed, 9 Feb 2011 16:38:25 -0800 (PST) Received: by eyd10 with SMTP id 10so526020eyd.31 for ; Wed, 09 Feb 2011 16:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=tAB4P8h/rr5oxLB/CwrdWIs0G1wvPzSTxh9lKaOhYNY=; b=GmB44C25Fiyw/UNakEwZ6U92LL62U3jU36G0RNehoZChh8LlGvtxpzEdlLuyP2mRVt 3tVZB9aRqU5/tYSlEvVaT3Q/QR8xIG3edPpMW/aJu6yNsgQUey7gyG9y1v04Z9bfyJj/ z2X3TTRYgJ+0hXoxSSekkx5efHbOF4gPdLfRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=W/8ThlmcYIKR70sUoL3EN/Pui1EEm3PVfF1fixZi/vwWD2HClQN/D8anWM259SeS0g 14V5hh4ENhAhcaHnPdD/MrZN3e+Wr6Hl7HwL9TIOQOBB3NVHSQnoMxt4LP5NITkLzlM6 8Xu69rJBvLHmu8DlKTqFQA5Ma+ZwhEFGa9uNw= MIME-Version: 1.0 Received: by 10.213.36.15 with SMTP id r15mr2740929ebd.86.1297298315811; Wed, 09 Feb 2011 16:38:35 -0800 (PST) Received: by 10.213.106.11 with HTTP; Wed, 9 Feb 2011 16:38:35 -0800 (PST) Date: Wed, 9 Feb 2011 19:38:35 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org, Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] WGLC - draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:38:26 -0000 Since no one else spoke up, let's make this quick: WGLC, to end Feb 11 2011 23:59 UTC please make your feelings known quickly, this seems like a non-controversial document, so quick reaction/turn-around would be helpful. -Chris From randy@psg.com Wed Feb 9 18:41:10 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705A93A680C for ; Wed, 9 Feb 2011 18:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5scJ13HKR-4K for ; Wed, 9 Feb 2011 18:41:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 183953A67FA for ; Wed, 9 Feb 2011 18:41:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PnMT5-0003Fy-Uv; Thu, 10 Feb 2011 02:41:16 +0000 Date: Wed, 09 Feb 2011 18:41:16 -0800 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4D52D1EF.2030200@cisco.com> References: <4D4454AE.6070304@cisco.com> <4D52D1EF.2030200@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:41:10 -0000 hi russ, >>> 3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple >>> NLRIs in a single UPDATE, given the impossibility of splitting a >>> signed message while preserving the signature. >>> >>> I'm not certain why this would be in a requirements document. Can >>> anyone explain how this directly relates to the security of BGP? IE, >>> what is the direct relationship between stating that packing is no >>> longer needed in BGP, and improving the security of BGP itself? >> >> note the 'need not.' it does not say 'must not'. the point is that, if >> there is a signature over the bundled nlri, that signature can not >> survive the next bgp peer, who will unpack the nlris due to their >> routing policy not sending the whole bundle to their next peer. >> i.e. imagine R0 sends a bundle to its customer R1, and R1 selects some, >> but not all, routes from R0 and others from elsewhere to send to its >> customer, R2. > > I understand the reasoning, but I'm not certain why this should be > addressed as a "requirement." once again, note the 'need not.' it relaxing the nlri packing requirement. as such, it is probably wise to be in a requirements statement, but is not itself a new requirement. if pdus/attributes are signed (not a given), a signed pdu with multiple nlris cannot be split into separate pdus. since splitting is normal -- due to local policy or perhaps better routing advertisements for that prefix but not others in the pdu -- it follows that a bgpsec speaker cannot accept any advertisement where a signature covers more than one prefix. otherwise, it will become something such as, "a bgpsec receiver who gets a message with a single signature over multiple nlris may have to discard the signature if routing policy will separate the nlri before sending them onward." and i suspect that both you and i might find this too prescriptive and detailed. > I could see something saying, "any proposed system should not decrease > performance by x%," let people discuss what x should be. To say that a > specific mechanism that will impact performance is acceptable as a > "requirement," no matter what the impact is, because the authors are > convinced that it "won't hurt anything," is presuming on the entire > set of possible environments, and putting the requirement in a > "backwards" way. relaxing nlri packing is not a performance issue. it is that s-bgp was broken in that it thought it could sign a packed pdu which had multiple nlris, not thinking through that the next router would break apart the nlris under local policy and thus break any aggregated signature. > Some other system may decrease performance in a different way, but the > WG is not open to discussing such tradeoffs the way this is currently > written. red herring. this is not about performance at all, but about security. >>> 3.14 A BGPsec design MUST NOT require operators to reveal proprietary >>> data. This includes peering, customer, and provider relationships, an >>> ISP's internal infrastructure, etc. Though it is understood that some >>> data are revealed to the savvy seeker by BGP, traceroute, etc. today. >>> >>> What sense does it make to say the only system which may be deployed >>> is one that protects information already publicly available? This is a >>> non-requirement, and must not be included in the requirements list. >> >> this is an absolute from many operators. > > It's an absolute must that information already revealed publicly in one > context not be revealed in another. Interesting... and common in the infosec world. as an infosec geek just said to me, saying it in another context can prove (in a loose sense, i presume) that something is true. see (for an otherwise appalling example) the us military on wikileaks. > It would be better to have an actual list here. I've asked, for years, > for specific instances --use cases-- where specific information should > not be revealed. Thus far, the only ones I've actually been given are, > "we don't want a peer to know we're breaking the contract we have with > them." I don't find these sorts of reasons convincing. i have not heard that quote. amusing stalking horse. excuse if i ignore it. > What a requirements document should have, it seems to me, is a list of > information that the operator community has determined cannot be > revealed and a reason for each one. sorry. what was unclear about "This includes peering, customer, and provider relationships, an ISP's internal infrastructure, etc.?" it's not our problem or prerogative; operators, who will choose to deploy or not, have made their requirement clear. is it really our prerogative to tell the operators what and how they have to justify to us? >> [ and note that backup paths are not very visible in bgp or traceroute ] > > Okay, so you're suggesting two things: > > 1. The list of the AS' a given AS is peered to should not be collated > into a conveniently available list. You expect people to be forced to > work for this information. indeed > 2. Backup connections should not be advertised unless they are used. nope. i did not say that. i said that backup paths are usualy not visible in analyses of public routing data. this is due to bgp's best path choices not propagating the less-preffered paths, and preserves today's properties. bgp is one of the world's best information hiding protocols :). paths that are actually used are disclosed to the parties on that path and to those to whom their policy *chooses* to leak the path. operators like this. otoh, researchers trying to generate AS topology graphs from public data hate this (see our paper in submission, http://archive.psg.com/101216.TenLessons.pdf). of course, the origin of a backup path is the same as that of a primary, and likely the more widely propagated, path. so the roa is the same. > In other words, only connections through which prefixes are actually > being advertised should be collectable from the system at large. not should be. are. see endless research papers on bgp analyses based on route views and ris. >> bottom line: when i recieve an update for prefix P with path D C B A, i >> want firm assurance that A passed P to B, B to C, C to D, and D to me. >> firm, verifiable, assurance. > > The question that needs to be answered here is simple: Are you trying to > have verifiable proof for a court case, or are you trying to validate > that the destination given actually exists through the advertising peer > to the extent possible within the protocol itself. "destination exists through the advertising peer" is a new and novel phrasing. i can see why it would be confusing. it sure confuses me, which i admit is a low bar. can we stick to bgp annoucements, please? > To say that one thing is "more assured," than another is to assume the > answer to the question, "more assured in what terms?" sorry, i missed where i said "more assured." >> that some database says that *some* prefixes are allowed from A to B to >> C to D to me does not mean *all* are. there are vast differences in how >> different prefixes are handled by each hop on the route. think peer, >> provider, customer relationships. > > First, you're assuming that in this network: > > A--B--C > > A can verify the policy between B and C somehow for a specific prefix or > reachable destination. BGP simply isn't built this way. no. current bgp is not built this way. if it was, we would not need to discuss bgp-level security. as to per-prefix verifiability, you may want to look at what steve kent's s-bgp proposals were trying to achieve. though operationally broken, they were very much per-prefix. > Second, you're assuming that the only way to verify things on a per > prefix basis is by signing the updates. Making assumptions about a given > solution set within a requirements document is a "bad thing." Don't do it. > > Explain the requirements, not the solution. actually, the document does. it is the conversation which has drifted a bit 4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally determine that the UPDATE has traversed the AS path indicated in the UPADTE. Note that this is more stringent than showing that the path is merely not impossible. >>> What does "proving the AS Path the update has traversed," prove, >>> precisely? Does receiving an update through a specific path prove >>> traffic sent to that destination will traverse the path listed? >> >> no, see security section. locking down the data plane is the next high >> mountain. one at a time. > > You've not explained what you mean when you say you want to "lock down" > the control plane. Again, what are you trying to prove? That an update > passed along a certain path? Does that provide you with policy > assurance? Does it prove the destination indicated exists and is > reachable along the path indicated? Does it prove packets transmitted to > the destination will follow this path? Or, again, are you mostly > interested in proving what a peer sent to you for contract enforcement? > These are all legitimate concerns, but you need to indicate which one > you're actually trying to address. how about something like "formally determine that the UPDATE has traversed the AS path indicated in the UPADTE?" >> of course if you have a solution which locks down both the control plane >> and the data plane, i *extremely eagerly* await your i-d. > > It's called circuit switching, rather than packet switching. so we can move on and consider this a red herring for the nonce. >>> Does receiving an update prove that all destinations listed are >>> reachable along the path listed? Does receiving an update prove that >>> every AS along that path has agreed to forward traffic transmitted to >>> the destination indicated? >> >> yes, agreed to. of course, we can not yet guarantee that they do not > > Um, no it doesn't. Simply receiving an update does not prove it is > "within policy" for the receiver to send traffic along the path > specified to the destination specified. one does not send traffic along a path. one sends it to a next hop. and R0 receiving a bgp announcement of prefix P from R1 does indeed state that it is "within policy" for R0 to send data toward P to R1. > In fact, you can't prove this unless you expose the peering pairwise > policy of every connected pair of AS' in the path. And you can't prove > it unless you remove aggregation from the routing system. actually, this is quite untrue. this is still stuck in the peering database model. the hope is that BGPsec does not need to 'expose' anyone's policies any more than bgp announcements do now. folk may choose to inject aggregated prefixes *into* the routing system, and we encourage them to do so. but there is effectively no aggregation *within* the inter-provider routing system. see the actual measurements discussed on nanog etc. >>> 4.3 Replay of BGP UPDATE messages need not be completely prevented, >>> but a BGPsec design MUST provide a mechanism to control the window of >>> exposure to replay attacks. >>> >>> Again, this is an assumption which I completely and totally disagree >>> with. What is the window size allowed in terms of time? Is it minutes, >>> hours, days, weeks, months, or years? >> >> tunable, i hope. i am not much worried about my research prefixes being >> replayed. root name servers may be. > > This isn't a requirement. Put a number in there, so we can discuss it. what is not clear about o needs vary, and o it should be tunable? just for example, for my research prefixes, i am not much worried about replay attacks, and would be happy with O(days). i imagine root name servers might s/days/hours/ but really should not speak for them. >> i will be in your area 8-12 feb. glad to chat face to face. > I'm in RTP, not SJ. well, i am usually in tokyo, so do call when you come by and i can wander over to the dreaded rappongi where the cisco offices are. but, this week, i am in sjc playing operator and architect working with vendors on this very subject. sorry we could not get together. email is not the best communication medium. we now have route origin validation pretty much nailed down, the documents are leaving sidr for the iesg, adn we have running code in routers. imiho, it would be really good to not go around these old overly well-traveled negative circles and to finally move bgp as-path security forward. constructive work from you and others would be a real step. thanks. randy From russ@cisco.com Wed Feb 9 19:01:11 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3267C3A67FA for ; Wed, 9 Feb 2011 19:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHIjCIZCRJ43 for ; Wed, 9 Feb 2011 19:01:09 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9B4C83A683F for ; Wed, 9 Feb 2011 19:01:09 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAETkUk1AZnwN/2dsb2JhbAClanOfaZsrhVwEhH+GcYMy X-IronPort-AV: E=Sophos;i="4.60,449,1291593600"; d="asc'?scan'208";a="213902928" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Feb 2011 03:01:20 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1A31Keo014844; Thu, 10 Feb 2011 03:01:20 GMT Message-ID: <4D535509.8000109@cisco.com> Date: Wed, 09 Feb 2011 22:01:29 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D4454AE.6070304@cisco.com> <4D52D1EF.2030200@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig708192C084FA4788B9F6C011" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 03:01:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig708192C084FA4788B9F6C011 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> I understand the reasoning, but I'm not certain why this should be >> addressed as a "requirement." >=20 > once again, note the 'need not.' it relaxing the nlri packing > requirement. as such, it is probably wise to be in a requirements > statement, but is not itself a new requirement. Once again, the requirement should be for no more than "x%" performance hit, not specific implementation points. >> It's an absolute must that information already revealed publicly in on= e >> context not be revealed in another. Interesting... >=20 > and common in the infosec world. as an infosec geek just said to me, > saying it in another context can prove (in a loose sense, i presume) > that something is true. see (for an otherwise appalling example) the u= s > military on wikileaks. Sorry, I don't buy it. >> What a requirements document should have, it seems to me, is a list of= >> information that the operator community has determined cannot be >> revealed and a reason for each one. >=20 > sorry. what was unclear about "This includes peering, customer, and > provider relationships, an ISP's internal infrastructure, etc.?" it's > not our problem or prerogative; operators, who will choose to deploy or= > not, have made their requirement clear. is it really our prerogative t= o > tell the operators what and how they have to justify to us? Everything. Again, a list, with use cases to back the list up. >> 1. The list of the AS' a given AS is peered to should not be collated >> into a conveniently available list. You expect people to be forced to >> work for this information. >=20 > indeed And somehow you expect making people work for it will make it more secure= =2E >> 2. Backup connections should not be advertised unless they are used. >=20 > nope. i did not say that. i said that backup paths are usualy not > visible in analyses of public routing data. this is due to bgp's best > path choices not propagating the less-preffered paths, and preserves > today's properties. bgp is one of the world's best information hiding > protocols :). So you're saying that backup paths should be able to be hidden until they are actually used? Can you put together a list of the specific information you think needs to be hidden, and back it up with use cases? >> In other words, only connections through which prefixes are actually >> being advertised should be collectable from the system at large. >=20 > not should be. are. see endless research papers on bgp analyses based= > on route views and ris. So then list this as a requirement. It's something that many different options can provide for, of course, not just S-BGP. > "destination exists through the advertising peer" is a new and novel > phrasing. i can see why it would be confusing. it sure confuses me, > which i admit is a low bar. can we stick to bgp annoucements, please? No, we cannot. BGP announces _something_. Are you trying to secure the something, or are you trying to secure the announcements? These are two completely different problems. >> To say that one thing is "more assured," than another is to assume the= >> answer to the question, "more assured in what terms?" >=20 > sorry, i missed where i said "more assured." You said so in your email. >> First, you're assuming that in this network: >> >> A--B--C >> >> A can verify the policy between B and C somehow for a specific prefix = or >> reachable destination. BGP simply isn't built this way. >=20 > no. current bgp is not built this way. if it was, we would not need t= o > discuss bgp-level security. as to per-prefix verifiability, you may > want to look at what steve kent's s-bgp proposals were trying to > achieve. though operationally broken, they were very much per-prefix. So you are stating that what you are trying to add is that A can validate the policy between B and C? > actually, the document does. it is the conversation which has drifted = a > bit No, the document explains a solution, not requirements. 1. There is no list of information operators expect to be hidden. 2. There is no idea of an acceptable performance degradation. 3. There is no statement of what is you're actually trying to achieve. >>> no, see security section. locking down the data plane is the next hi= gh >>> mountain. one at a time. To "lock down the data plane," there are only two options: 1. Circuit switching. 2. End to end encryption, which is outside the scope of BGP or any other routing protocol. > how about something like "formally determine that the UPDATE has > traversed the AS path indicated in the UPADTE?" How about explaining what this proves? >> Um, no it doesn't. Simply receiving an update does not prove it is >> "within policy" for the receiver to send traffic along the path >> specified to the destination specified.=20 >=20 > one does not send traffic along a path. one sends it to a next hop. > and R0 receiving a bgp announcement of prefix P from R1 does indeed > state that it is "within policy" for R0 to send data toward P to R1. Exactly. So, again, what are you proving by showing what the policy between two peers multiple hops away is? >> In fact, you can't prove this unless you expose the peering pairwise >> policy of every connected pair of AS' in the path. And you can't prove= >> it unless you remove aggregation from the routing system. >=20 > actually, this is quite untrue. this is still stuck in the peering > database model. the hope is that BGPsec does not need to 'expose' > anyone's policies any more than bgp announcements do now. Actually, it is quite true. Simply put, BGP doesn't contain the information about more than connected policy; you can't secure information you don't have. Further, as long as I can underclaim, or aggregate legally to bury a prefix I don't want you to know about, you can't prove anything about the path beyond the next immediate hop. So, which is it --you can, or cannot validate anything beyond the next ho= p? >> This isn't a requirement. Put a number in there, so we can discuss it.= >=20 > what is not clear about > o needs vary, and > o it should be tunable? Because that's not what the doc says. It says "replays are acceptable." Again, put a number in there. > we now have route origin validation pretty much nailed down, the > documents are leaving sidr for the iesg, adn we have running code in > routers. imiho, it would be really good to not go around these old > overly well-traveled negative circles and to finally move bgp as-path > security forward. constructive work from you and others would be a rea= l > step. thanks. When you are going the wrong way, the most constructive step you can take is to turn around. But this isn't about your modifications to S-BGP. You might have noticed I've not mentioned any specific protocol modification _once_. This is about a requirements document that is, essentially, specifying a protocol, rather than specifying requirements. If you want to go down a road, then let's figure out where it is we want to go, rather than just plowing ahead on any random road, and hoping we get someplace useful. Russ --------------enig708192C084FA4788B9F6C011 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1TVQ8ACgkQER27sUhU9OSuxgCg+qj1J1VAQtCl/kFbjudPsMu8 xXMAn0AKkrDdXEtbXF0hBF6kBAtVPwTi =pfrk -----END PGP SIGNATURE----- --------------enig708192C084FA4788B9F6C011-- From randy@psg.com Wed Feb 9 21:00:50 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC12A3A6881 for ; Wed, 9 Feb 2011 21:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bwvs-ar9MdWd for ; Wed, 9 Feb 2011 21:00:49 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 187E83A687E for ; Wed, 9 Feb 2011 21:00:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PnOeI-0003VT-Tr; Thu, 10 Feb 2011 05:00:59 +0000 Date: Wed, 09 Feb 2011 21:00:58 -0800 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4D535509.8000109@cisco.com> References: <4D4454AE.6070304@cisco.com> <4D52D1EF.2030200@cisco.com> <4D535509.8000109@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 05:00:51 -0000 >>> I understand the reasoning, but I'm not certain why this should be >>> addressed as a "requirement." >> >> once again, note the 'need not.' it relaxing the nlri packing >> requirement. as such, it is probably wise to be in a requirements >> statement, but is not itself a new requirement. > > Once again, the requirement should be for no more than "x%" performance > hit, not specific implementation points. and once again, the nlri packing issue is not about performance at all. it is about security, security, and security. please actually read the prior email. >>> It's an absolute must that information already revealed publicly in one >>> context not be revealed in another. Interesting... >> >> and common in the infosec world. as an infosec geek just said to me, >> saying it in another context can prove (in a loose sense, i presume) >> that something is true. see (for an otherwise appalling example) the us >> military on wikileaks. > > Sorry, I don't buy it. not a problem. you don't have to. >>> What a requirements document should have, it seems to me, is a list of >>> information that the operator community has determined cannot be >>> revealed and a reason for each one. >> >> sorry. what was unclear about "This includes peering, customer, and >> provider relationships, an ISP's internal infrastructure, etc.?" it's >> not our problem or prerogative; operators, who will choose to deploy or >> not, have made their requirement clear. is it really our prerogative to >> tell the operators what and how they have to justify to us? > > Everything. Again, a list, with use cases to back the list up. did that two emails ago. >>> 1. The list of the AS' a given AS is peered to should not be collated >>> into a conveniently available list. You expect people to be forced to >>> work for this information. >> >> indeed > > And somehow you expect making people work for it will make it more > secure. yep. that is the infosec model. read previous email. >>> 2. Backup connections should not be advertised unless they are used. >> >> nope. i did not say that. i said that backup paths are usualy not >> visible in analyses of public routing data. this is due to bgp's best >> path choices not propagating the less-preffered paths, and preserves >> today's properties. bgp is one of the world's best information hiding >> protocols :). > > So you're saying that backup paths should be able to be hidden until > they are actually used? Can you put together a list of the specific > information you think needs to be hidden, and back it up with use > cases? no i am not. read the paragraph you just quoted above. >>> In other words, only connections through which prefixes are actually >>> being advertised should be collectable from the system at large. >> >> not should be. are. see endless research papers on bgp analyses based >> on route views and ris. > > So then list this as a requirement. It's something that many different > options can provide for, of course, not just S-BGP. that bgp only advertises best path is in rfc 4271. apologies that it is not a reference in the draft. we'll fix that in the next draft. >> "destination exists through the advertising peer" is a new and novel >> phrasing. i can see why it would be confusing. it sure confuses me, >> which i admit is a low bar. can we stick to bgp annoucements, please? > > No, we cannot. BGP announces _something_. Are you trying to secure the > something, or are you trying to secure the announcements? These are two > completely different problems. if the abstract does not make this clear enough, please suggest wording. This document describes requirements for a future BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. >>> To say that one thing is "more assured," than another is to assume the >>> answer to the question, "more assured in what terms?" >> >> sorry, i missed where i said "more assured." > > You said so in your email. not in the ascii. perhaps in the ebcdic translation. >>> First, you're assuming that in this network: >>> >>> A--B--C >>> >>> A can verify the policy between B and C somehow for a specific prefix or >>> reachable destination. BGP simply isn't built this way. >> >> no. current bgp is not built this way. if it was, we would not need to >> discuss bgp-level security. as to per-prefix verifiability, you may >> want to look at what steve kent's s-bgp proposals were trying to >> achieve. though operationally broken, they were very much per-prefix. > > So you are stating that what you are trying to add is that A can > validate the policy between B and C? no. >> actually, the document does. it is the conversation which has drifted a >> bit > > No, the document explains a solution, not requirements. that is an assertion which is a bit hard to substantiate. > 1. There is no list of information operators expect to be hidden. 3.14 A BGPsec design MUST NOT require operators to reveal proprietary data. This includes peering, customer, and provider relationships, an ISP's internal infrastructure, etc. Though it is understood that some data are revealed to the savvy seeker by BGP, traceroute, etc. today. > 2. There is no idea of an acceptable performance degradation. nope. do you have a suggestion? > 3. There is no statement of what is you're actually trying to achieve. funny, most folk find the abstract and intro pretty clear on that. but if you have more complete wording, do send text. >>>> no, see security section. locking down the data plane is the next high >>>> mountain. one at a time. > > To "lock down the data plane," there are only two options: > > 1. Circuit switching. > 2. End to end encryption, which is outside the scope of BGP or any other > routing protocol. i am not sure these are the only ways to do so. but this is pretty irrelevant as the draft pretty clearly says 3.4 A BGPsec design need not prevent attacks on data plane traffic. It need not assure that the data plane even follows the control plane. so what exactly is your point here? >> how about something like "formally determine that the UPDATE has >> traversed the AS path indicated in the UPADTE?" > > How about explaining what this proves? i have tried. sorry if it does not make it clear to you. > When you are going the wrong way, the most constructive step you can > take is to turn around. good advice. bye. randy From housley@vigilsec.com Wed Feb 9 22:37:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68F33A68AB for ; Wed, 9 Feb 2011 22:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzYpSQrJ2p8P for ; Wed, 9 Feb 2011 22:37:24 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id AD8903A68A7 for ; Wed, 9 Feb 2011 22:37:21 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 41EF19A47CE; Thu, 10 Feb 2011 01:37:44 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 8kW5zHxD5RXw; Thu, 10 Feb 2011 01:37:26 -0500 (EST) Received: from [10.71.1.108] (unknown [69.168.220.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1A0479A474D; Thu, 10 Feb 2011 01:37:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <4D535509.8000109@cisco.com> Date: Thu, 10 Feb 2011 01:37:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <21D27669-706D-48ED-8882-2013D53E719E@vigilsec.com> References: <4D4454AE.6070304@cisco.com> <4D52D1EF.2030200@cisco.com> <4D535509.8000109@cisco.com> To: Russ White X-Mailer: Apple Mail (2.1082) Cc: IETF SIDR Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:37:26 -0000 Russ: >>> 2. Backup connections should not be advertised unless they are used. >>=20 >> nope. i did not say that. i said that backup paths are usualy not >> visible in analyses of public routing data. this is due to bgp's = best >> path choices not propagating the less-preffered paths, and preserves >> today's properties. bgp is one of the world's best information = hiding >> protocols :). >=20 > So you're saying that backup paths should be able to be hidden until > they are actually used? Can you put together a list of the specific > information you think needs to be hidden, and back it up with use = cases? No. I hear that it is not a requirement to disclose them ahead of time. = The ASes along the path just need to be able to determine that it is = valid before it is accepted. Russ= From russ@cisco.com Thu Feb 10 05:04:00 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E6D3A6984 for ; Thu, 10 Feb 2011 05:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPhBO9k0XF0f for ; Thu, 10 Feb 2011 05:03:56 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 71C9E3A69A6 for ; Thu, 10 Feb 2011 05:03:56 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOVwU01AZnwN/2dsb2JhbAClaXOeb5syhVwEhQGGeIMy X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="asc'?scan'208";a="213822698" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2011 13:04:08 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AD48i7016326; Thu, 10 Feb 2011 13:04:08 GMT Message-ID: <4D53E253.7050106@cisco.com> Date: Thu, 10 Feb 2011 08:04:19 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Russ Housley References: <4D4454AE.6070304@cisco.com> <4D52D1EF.2030200@cisco.com> <4D535509.8000109@cisco.com> <21D27669-706D-48ED-8882-2013D53E719E@vigilsec.com> In-Reply-To: <21D27669-706D-48ED-8882-2013D53E719E@vigilsec.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig22E0658E18DB1EA161B4B2C6" Cc: IETF SIDR Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 13:04:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig22E0658E18DB1EA161B4B2C6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> So you're saying that backup paths should be able to be hidden until >> they are actually used? Can you put together a list of the specific >> information you think needs to be hidden, and back it up with use case= s? >=20 > No. I hear that it is not a requirement to disclose them ahead of time= =2E The ASes along the path just need to be able to determine that it is= valid before it is accepted. Then why doesn't the "requirements document" actually state this? Again, my argument has been, and still is, that the "requirements document," as presented, isn't requirements. If this is a requirement, then list it. I'm not arguing for any particular system, which is where the argument always tends to flow, but only that a requirements document actually list requirements. The only thing I get out of reading this document is, "S-BGP is acceptable and required." Russ --------------enig22E0658E18DB1EA161B4B2C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1T4lcACgkQER27sUhU9OTx9ACfRDrr+SFqvJGLGLCCHmnd3BfO 0IYAoIPvvo26Lv2C9qGyScj8F3FugFf9 =WH0u -----END PGP SIGNATURE----- --------------enig22E0658E18DB1EA161B4B2C6-- From kent@bbn.com Thu Feb 10 10:38:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B8E3A6987 for ; Thu, 10 Feb 2011 10:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD3MxLYhQrAt for ; Thu, 10 Feb 2011 10:38:05 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D690D3A6824 for ; Thu, 10 Feb 2011 10:38:05 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:50936 helo=[132.249.64.39]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PnbPG-000NbI-38; Thu, 10 Feb 2011 13:38:18 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 10 Feb 2011 13:32:00 -0500 To: Christopher Morrow From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] WGLC - draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:38:06 -0000 At 7:38 PM -0500 2/9/11, Christopher Morrow wrote: > >Since no one else spoke up, let's make this quick: > >WGLC, to end Feb 11 2011 23:59 UTC > >please make your feelings known quickly, this seems like a >non-controversial document, so quick reaction/turn-around would be >helpful. > >-Chris > I'm in favor (but, then, I'm a co-author ...). Steve From terry.manderson@icann.org Thu Feb 10 15:30:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95F23A6B09 for ; Thu, 10 Feb 2011 15:30:39 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkoA8uLOtyW7 for ; Thu, 10 Feb 2011 15:30:39 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 264023A6B02 for ; Thu, 10 Feb 2011 15:30:39 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 10 Feb 2011 15:30:51 -0800 From: Terry Manderson To: Christopher Morrow , "sidr@ietf.org" Date: Thu, 10 Feb 2011 15:30:50 -0800 Thread-Topic: WGLC - draft-manderson-iana-objects-03.txt Thread-Index: AcvIuufRja32NLoKRi2B/nMFI+Y+BwAv6U/G Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC - draft-manderson-iana-objects-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:30:39 -0000 with author hat stylishly tilted to one side. The doc can be found at: http://tools.ietf.org/html/draft-ietf-sidr-iana-objects-00 Cheers Terry On 10/02/11 10:38 AM, "Christopher Morrow" wrote: > > Since no one else spoke up, let's make this quick: >=20 > WGLC, to end Feb 11 2011 23:59 UTC >=20 > please make your feelings known quickly, this seems like a > non-controversial document, so quick reaction/turn-around would be > helpful. >=20 > -Chris > From turners@ieca.com Thu Feb 10 17:31:17 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CDC3A6A8F for ; Thu, 10 Feb 2011 17:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdtUjbBjXfLG for ; Thu, 10 Feb 2011 17:31:16 -0800 (PST) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by core3.amsl.com (Postfix) with SMTP id 4D9743A6B37 for ; Thu, 10 Feb 2011 17:31:16 -0800 (PST) Received: from [98.139.91.65] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 01:31:30 -0000 Received: from [98.139.91.13] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 01:31:30 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 01:31:30 -0000 X-Yahoo-Newman-Id: 132608.66808.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 68980 invoked from network); 11 Feb 2011 01:31:29 -0000 Received: from thunderfish.local (turners@96.231.115.153 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 10 Feb 2011 17:31:29 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: pBkhIA4VM1kIbc79y_iPmy4WHxDnMWb8sInCwDeXO81098s ciivSrc8rWoybxJ4oh_oDrddswzB4gfCuWAypH45lvf7zfKU.Leajl0fKwwG qKIz7_haJm7DRbF4zTRAfgCJyTKdiN4PLPK5MgIaR1MwdtgakJQSY1HeoBvC E9PsxefP74pUtIUOH29X42YexYP0ot_.x.AeUIlfiKE2e.ASadYafx8C6uwU kyy2n18tWhK5wTpHvkvUP8pvEbVYP0oP85_IyABJA3199guc9WGyIYVKd1UE aMsO7OfWEgrTRH8BXkdaCEUKOpCMh_ORVr48- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D549170.6000308@ieca.com> Date: Thu, 10 Feb 2011 20:31:28 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christopher Morrow , "sidr@ietf.org" Subject: [sidr] WGLC comments: draft-sidr-iana-objects-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 01:31:17 -0000 Lots of hats in this WG... With my nit-noid checker hat on ;) - Should this be a BCP or standards track? - Expand RPKI in abstract and introduction - Sec 2: r/description od/description of - Sec 3: r/, [I-D.ietf-sidr-rpki-manifests]./ , and [I-D.ietf-sidr-rpki-manifests]. - Add informative references to IPv4 [RFC793] and IPv6 [RFC2460] either in Section 2 or 4. [RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, September 1981. [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998. - It might be worth noting why this draft uses non-RFC 3849/5735/5771 compliant addresses. It'll stop somebody who uses the nit checker from asking the question and possibly slowing down publication (think genart, secdir, or IESG member). From the nit checker: == There are 2 instances of lines with non-RFC5735-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. - Sec 5: Missing some periods: r/[RFC5735]/[RFC5735]. r/routed/routed. r/[RFC3068]/[RFC3068]. - Sec 5: r/IANA should/IANA SHOULD - Sec 6/7/8: Should "IANA MUST refrain" be "IANA MUST NOT"? - Sec 7: r/[RFC5180]/[RFC5180]. - Sec 10: If IANA is going to stand up the CA it's going to need to write the CPS that says how it does all the things the CP says it needs to. spt On 2/10/11 6:30 PM, Terry Manderson wrote: > with author hat stylishly tilted to one side. > > The doc can be found at: > > http://tools.ietf.org/html/draft-ietf-sidr-iana-objects-00 > > Cheers > Terry > > > On 10/02/11 10:38 AM, "Christopher Morrow" > wrote: > >> >> Since no one else spoke up, let's make this quick: >> >> WGLC, to end Feb 11 2011 23:59 UTC >> >> please make your feelings known quickly, this seems like a >> non-controversial document, so quick reaction/turn-around would be >> helpful. >> >> -Chris >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From terry.manderson@icann.org Thu Feb 10 18:14:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56193A67F6 for ; Thu, 10 Feb 2011 18: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StKoDY-1JDls for ; Thu, 10 Feb 2011 18:14:15 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id E14063A676A for ; Thu, 10 Feb 2011 18:14:15 -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; Thu, 10 Feb 2011 18:14:29 -0800 From: Terry Manderson To: Sean Turner Date: Thu, 10 Feb 2011 18:14:27 -0800 Thread-Topic: WGLC comments: draft-sidr-iana-objects-00.txt Thread-Index: AcvJi3dzhBN+hoHZS8e2lw9Udo2yUwABfEDP Message-ID: In-Reply-To: <4D549170.6000308@ieca.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Christopher Morrow , "sidr@ietf.org" Subject: Re: [sidr] WGLC comments: draft-sidr-iana-objects-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 02:14:16 -0000 Hi Sean, Thank you for your careful review. On 11/02/11 11:31 AM, "Sean Turner" wrote: > Lots of hats in this WG... With my nit-noid checker hat on ;) >=20 > - Should this be a BCP or standards track? To me this sits in BCP space, it really describes the best action IANA should follow for dealing with issuing RPKI objects for the unallocated, reserved, and special use blocks. It doesn't define or redefine any existin= g RPKI structures. >=20 > - Expand RPKI in abstract and introduction >=20 > - Sec 2: r/description od/description of >=20 > - Sec 3: r/, [I-D.ietf-sidr-rpki-manifests]./ > , and [I-D.ietf-sidr-rpki-manifests]. Thanks, Will fix. >=20 > - Add informative references to IPv4 [RFC793] and IPv6 [RFC2460] either > in Section 2 or 4. >=20 > [RFC791] Postel, J. (ed.), "Internet Protocol - DARPA Internet > Program Protocol Specification", RFC 791, September 1981. >=20 > [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version > 6 (IPv6) Specification," RFC 2460, December 1998. Thanks, will add. >=20 > - It might be worth noting why this draft uses non-RFC 3849/5735/5771 > compliant addresses. It'll stop somebody who uses the nit checker from > asking the question and possibly slowing down publication (think genart, > secdir, or IESG member). From the nit checker: >=20 > =3D=3D There are 2 instances of lines with non-RFC5735-compliant IPv4 > addresses in the document. If these are example addresses, they > should be changed. >=20 > =3D=3D There are 4 instances of lines with multicast IPv4 addresses in = the > document. If these are generic example addresses, they should be > changed to use the 233.252.0.x range defined in RFC 5771 >=20 > =3D=3D There are 1 instance of lines with non-RFC3849-compliant IPv6 > addresses in the document. If these are example addresses, they > should be changed. None of the addresses are example addresses. They are specific to the resources and the expected RPKI objects in question. >=20 > - Sec 5: Missing some periods: > r/[RFC5735]/[RFC5735]. > r/routed/routed. > r/[RFC3068]/[RFC3068]. Thanks. Will fix. >=20 > - Sec 5: r/IANA should/IANA SHOULD >=20 > - Sec 6/7/8: Should "IANA MUST refrain" be "IANA MUST NOT"? >=20 > - Sec 7: r/[RFC5180]/[RFC5180]. Thanks. Will fix. >=20 > - Sec 10: If IANA is going to stand up the CA it's going to need to > write the CPS that says how it does all the things the CP says it needs t= o. Correct. Although my take on that is it's an acquired effort of running the RPKI Unallocated/reserved/special-use CA and need not be specified here. I also didn't see the need to refer to one of the CPS templates. Is my thinking misaligned here? Apart from the last open item, would you be ok if I made the changes prior to IESG submission instead of cutting another revision. Cheers Terry >=20 > spt >=20 > On 2/10/11 6:30 PM, Terry Manderson wrote: >> with author hat stylishly tilted to one side. >>=20 >> The doc can be found at: >>=20 >> http://tools.ietf.org/html/draft-ietf-sidr-iana-objects-00 >>=20 >> Cheers >> Terry >>=20 >>=20 >> On 10/02/11 10:38 AM, "Christopher Morrow" >> wrote: >>=20 >>> >>> Since no one else spoke up, let's make this quick: >>>=20 >>> WGLC, to end Feb 11 2011 23:59 UTC >>>=20 >>> please make your feelings known quickly, this seems like a >>> non-controversial document, so quick reaction/turn-around would be >>> helpful. >>>=20 >>> -Chris >>> >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 From turners@ieca.com Fri Feb 11 07:39:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5845E3A6983 for ; Fri, 11 Feb 2011 07:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2jXJeVk4TGe for ; Fri, 11 Feb 2011 07:39:44 -0800 (PST) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by core3.amsl.com (Postfix) with SMTP id 5E3403A688F for ; Fri, 11 Feb 2011 07:39:44 -0800 (PST) Received: from [98.139.91.69] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 15:39:59 -0000 Received: from [98.139.91.16] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 15:39:59 -0000 Received: from [127.0.0.1] by omp1016.mail.sp2.yahoo.com with NNFMP; 11 Feb 2011 15:39:59 -0000 X-Yahoo-Newman-Id: 713658.60278.bm@omp1016.mail.sp2.yahoo.com Received: (qmail 283 invoked from network); 11 Feb 2011 15:39:58 -0000 Received: from thunderfish.local (turners@96.231.115.153 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 11 Feb 2011 07:39:57 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: AEyOaoEVM1n8SK4dfyV.Oc.xsaCLo230qWTqcgcLMtvbw_S 6SOL_sx3yN2bryQ3U5XE5EX5KCGIwSgEAvcahzpqL.i2PmcHvQkiFZlTT1QW FKHFAFxJXlg6eMEDprFNiQT_KvUJ5gpfA1IdN.MfbytItK.j7dpkgI1XBOI0 tCCpgw9sLjOfaklmNxSojZqA3iiLCWWph2SuR9izGYTuDcCZKt9yxpDk7T3T IT7CSCeNJBwgKLWLqeibKzu2ImCo7ZLryESmiHFJsUqjvy1ePjCwaihpDHtG 7wFExFfW8L6193A3aliQzpvHo7GbvV6YMs6U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D55584B.3020704@ieca.com> Date: Fri, 11 Feb 2011 10:39:55 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christopher Morrow , "sidr@ietf.org" Subject: Re: [sidr] WGLC comments: draft-sidr-iana-objects-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:39:45 -0000 On 2/10/11 9:14 PM, Terry Manderson wrote: > Hi Sean, > > Thank you for your careful review. Purely selfish on my part ;) Turns out to be less email now rather than later. > On 11/02/11 11:31 AM, "Sean Turner" wrote: > >> Lots of hats in this WG... With my nit-noid checker hat on ;) >> >> - Should this be a BCP or standards track? > > To me this sits in BCP space, it really describes the best action IANA > should follow for dealing with issuing RPKI objects for the unallocated, > reserved, and special use blocks. It doesn't define or redefine any existing > RPKI structures. ack - second para of 2026. ..snip >> - It might be worth noting why this draft uses non-RFC 3849/5735/5771 >> compliant addresses. It'll stop somebody who uses the nit checker from >> asking the question and possibly slowing down publication (think genart, >> secdir, or IESG member). From the nit checker: >> >> == There are 2 instances of lines with non-RFC5735-compliant IPv4 >> addresses in the document. If these are example addresses, they >> should be changed. >> >> == There are 4 instances of lines with multicast IPv4 addresses in the >> document. If these are generic example addresses, they should be >> changed to use the 233.252.0.x range defined in RFC 5771 >> >> == There are 1 instance of lines with non-RFC3849-compliant IPv6 >> addresses in the document. If these are example addresses, they >> should be changed. > > None of the addresses are example addresses. They are specific to the > resources and the expected RPKI objects in question. Yep that's my point. If you put something in like: NOTE: The addresses used in this document are not example addresses therefore they are not compliant with RFC 3849, 5735, and 5771. This is intentional as the practices described in this document affect real world addresses. Or something like that. But then again maybe that's clear to everybody and I'm in the rough. ..snip >> - Sec 10: If IANA is going to stand up the CA it's going to need to >> write the CPS that says how it does all the things the CP says it needs to. > > Correct. Although my take on that is it's an acquired effort of running the > RPKI Unallocated/reserved/special-use CA and need not be specified here. I > also didn't see the need to refer to one of the CPS templates. > > Is my thinking misaligned here? Yeah I was just trying to complete the list of things they'd need to do, but I guess that list is quite long and when complying with the CP they'll need to do a CPS. Since the CP reference is already in there then there's probably nothing more that needs to be added about the CPS. > Apart from the last open item, would you be ok if I made the changes prior > to IESG submission instead of cutting another revision. That's fine by me. spt > Cheers > Terry > >> >> spt >> >> On 2/10/11 6:30 PM, Terry Manderson wrote: >>> with author hat stylishly tilted to one side. >>> >>> The doc can be found at: >>> >>> http://tools.ietf.org/html/draft-ietf-sidr-iana-objects-00 >>> >>> Cheers >>> Terry >>> >>> >>> On 10/02/11 10:38 AM, "Christopher Morrow" >>> wrote: >>> >>>> >>>> Since no one else spoke up, let's make this quick: >>>> >>>> WGLC, to end Feb 11 2011 23:59 UTC >>>> >>>> please make your feelings known quickly, this seems like a >>>> non-controversial document, so quick reaction/turn-around would be >>>> helpful. >>>> >>>> -Chris >>>> >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> > > From shane@castlepoint.net Fri Feb 11 07:51:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46493A69D2 for ; Fri, 11 Feb 2011 07:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgL3ZhuKJoKu for ; Fri, 11 Feb 2011 07:51:17 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id D22563A6974 for ; Fri, 11 Feb 2011 07:51:17 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E4A3E2684EA; Fri, 11 Feb 2011 08:51:32 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-254-35.hlrn.qwest.net [65.101.254.35]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 11 Feb 2011 08:51:32 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.254.35; client-port=56347; syn-fingerprint=65535:56:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Fri, 11 Feb 2011 08:51:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> References: <4D4454AE.6070304@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org, Russ White Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 15:51:18 -0000 Randy, On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >> 3.3 As cryptographic payloads and loading on routers are likely to >> seriously increase, a BGPsec design may require use of new hardware. >> It must be possible to build routers that do BGPsec with within >> acceptable (to operators) bounds of cost and performance. >>=20 >> This should be left out of any requirements document, and various >> proposed system compared based on their costs and deployment >> difficulty. >=20 > i take your point. the intent was that compatibility with current > hardware abilities is not a requirement that this document imposes on = a > solution. it is quite likely that provider routers will need crypto > assist and more ram. though one hope that the stub customer edge will > not. Whoa there. I couldn't disagree more wrt the above. First, let's start with the most fundamental question. Why is it that = routers MUST sign, pass around and verify _in-band_ in the control plane = various contents/PDU's _within_ BGP? Note my very careful use of the = work _in-band_. By that I mean inside the BGP session itself, not on a = side-band channel like RPKI and/or IRR is used today. While I have = grave concerns over in-band signing & verification, I am [much] less = concerned about the latter for several reasons. With respect to = in-band: 1) I'm extremely concerned over dependencies of automatically = "trusting" signed data in-band within the control plane and not being = able to reach servers (RP's?) to verify the contents of the PDU's are = legitimate. At least with prefix-filters and/or AS_PATH filters, it's = very easy for me to manually disable some or all filtering for = particular destinations in order to, say, get reachability to servers = (RP's) to verify the authenticity of data. 2) Related to point #1, we really should go back to first principles = ask ourselves if we're really intending to conflate the _transport_ = method (BGP) with the requirement to verify the data _inside_ of BGP. = If so, what is the reason? Is it solely for convenience, (because BGP = transport is already there), or other reasons? 3) I really, really don't like the idea of "will need crypto assist and = more ram" on my RE/RP's for several reasons, namely: a) It's one more set of variables that my already over-worked = Capacity Planning and NOC groups need to keep track of and attempt to = stay ahead of. b) It's extremely costly to upgrade RE/RP's, because said RE/RP's = are only available from one source -- equipment vendors. And, the = upgrade paths typically don't buy you much in terms of more CPU, etc., = because vendors are obligated to source "established" components they = know they'll be able to acquire for several years into the future. And, = worst of all, the cycle to get those RE/RP's into the network is = extremely long when you start to consider the budgeting, testing of new = code, physical installation, customer disruption during maintenance = windows, etc. ... at least with respect to (b), if I were able to use offboard CPU = (i.e.: Intel/AMD servers, like in the RPKI/IRR world), then I have a = much larger selection of HW to choose from and I can upgrade those in = the network much, much more quickly. At least with respect to #1 and #2, I don't see any discussion of the = above in the current draft (although maybe I missed it?). But, IMHO, = those are _fundamental_ requirements that need to be discussed among the = WG. Before touching on any of the other points in Russ White's e-mails = in this thread, (which I agree with), I think it's important to get back = to basics. > and the operators with whom we discussed (note that i am an operator, > not a vendor with a bad habit of speaking for operators) this thought > that this needed to be said from both ends of the scale. we did not > want the future security constrained by a 7200, nor did we want an > explosion in costs. as dollars are the bottom line in our capitalist > culture, constraining them seems quite reasonable. It wasn't discussed with me. :-) -shane= From ttauber@1-4-5.net Fri Feb 11 08:41:27 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590493A69D1 for ; Fri, 11 Feb 2011 08:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZFiJ9zeP4HY for ; Fri, 11 Feb 2011 08:41:26 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id C42BA3A6989 for ; Fri, 11 Feb 2011 08:41:25 -0800 (PST) Received: by vws7 with SMTP id 7so1853187vws.31 for ; Fri, 11 Feb 2011 08:41:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.185.197 with SMTP id cp5mr876293vcb.56.1297442499190; Fri, 11 Feb 2011 08:41:39 -0800 (PST) Received: by 10.220.187.138 with HTTP; Fri, 11 Feb 2011 08:41:39 -0800 (PST) X-Originating-IP: [128.223.156.9] In-Reply-To: <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> Date: Fri, 11 Feb 2011 11:41:39 -0500 Message-ID: From: Tony Tauber To: Randy Bush , Shane Amante Content-Type: multipart/alternative; boundary=90e6ba53ad7447e01b049c045f18 Cc: Russ White , sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 16:41:27 -0000 --90e6ba53ad7447e01b049c045f18 Content-Type: text/plain; charset=ISO-8859-1 I'm also wondering on which provider routers Randy's seeing the need for crypto and other HW upgrades. If it's every router that carries full routes or terminates an external BGP session, that can be a pretty big nut to swallow. Why don't we work on getting someone on board with a working something before getting down the garden path which leads people to throw up their hands about non-starters and stuff. Tony On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante wrote: > Randy, > > On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: > >> 3.3 As cryptographic payloads and loading on routers are likely to > >> seriously increase, a BGPsec design may require use of new hardware. > >> It must be possible to build routers that do BGPsec with within > >> acceptable (to operators) bounds of cost and performance. > >> > >> This should be left out of any requirements document, and various > >> proposed system compared based on their costs and deployment > >> difficulty. > > > > i take your point. the intent was that compatibility with current > > hardware abilities is not a requirement that this document imposes on a > > solution. it is quite likely that provider routers will need crypto > > assist and more ram. though one hope that the stub customer edge will > > not. > > Whoa there. I couldn't disagree more wrt the above. > > First, let's start with the most fundamental question. Why is it that > routers MUST sign, pass around and verify _in-band_ in the control plane > various contents/PDU's _within_ BGP? Note my very careful use of the work > _in-band_. By that I mean inside the BGP session itself, not on a side-band > channel like RPKI and/or IRR is used today. While I have grave concerns > over in-band signing & verification, I am [much] less concerned about the > latter for several reasons. With respect to in-band: > 1) I'm extremely concerned over dependencies of automatically "trusting" > signed data in-band within the control plane and not being able to reach > servers (RP's?) to verify the contents of the PDU's are legitimate. At > least with prefix-filters and/or AS_PATH filters, it's very easy for me to > manually disable some or all filtering for particular destinations in order > to, say, get reachability to servers (RP's) to verify the authenticity of > data. > 2) Related to point #1, we really should go back to first principles ask > ourselves if we're really intending to conflate the _transport_ method (BGP) > with the requirement to verify the data _inside_ of BGP. If so, what is the > reason? Is it solely for convenience, (because BGP transport is already > there), or other reasons? > 3) I really, really don't like the idea of "will need crypto assist and > more ram" on my RE/RP's for several reasons, namely: > a) It's one more set of variables that my already over-worked Capacity > Planning and NOC groups need to keep track of and attempt to stay ahead of. > b) It's extremely costly to upgrade RE/RP's, because said RE/RP's are > only available from one source -- equipment vendors. And, the upgrade paths > typically don't buy you much in terms of more CPU, etc., because vendors are > obligated to source "established" components they know they'll be able to > acquire for several years into the future. And, worst of all, the cycle to > get those RE/RP's into the network is extremely long when you start to > consider the budgeting, testing of new code, physical installation, customer > disruption during maintenance windows, etc. > ... at least with respect to (b), if I were able to use offboard CPU (i.e.: > Intel/AMD servers, like in the RPKI/IRR world), then I have a much larger > selection of HW to choose from and I can upgrade those in the network much, > much more quickly. > > At least with respect to #1 and #2, I don't see any discussion of the above > in the current draft (although maybe I missed it?). But, IMHO, those are > _fundamental_ requirements that need to be discussed among the WG. Before > touching on any of the other points in Russ White's e-mails in this thread, > (which I agree with), I think it's important to get back to basics. > > > > and the operators with whom we discussed (note that i am an operator, > > not a vendor with a bad habit of speaking for operators) this thought > > that this needed to be said from both ends of the scale. we did not > > want the future security constrained by a 7200, nor did we want an > > explosion in costs. as dollars are the bottom line in our capitalist > > culture, constraining them seems quite reasonable. > > It wasn't discussed with me. :-) > > -shane > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --90e6ba53ad7447e01b049c045f18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm also wondering on which provider routers Randy's seeing the nee= d for crypto and other HW upgrades.
If it's every router that carrie= s full routes or terminates an external BGP session, that can be a pretty b= ig nut to swallow.

Why don't we work on getting someone on board with a working someth= ing before getting down the garden path which leads people to throw up thei= r hands about non-starters and stuff.

Tony

On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante <shane@castlepoint.net> wro= te:
Randy,

On Jan 30, 2011, at 20:40 MST, Randy Bush wrote:
>> 3.3 As cryptographic payloads and loading on routers are likely to=
>> seriously increase, a BGPsec design may require use of new hardwar= e.
>> It must be possible to build routers that do BGPsec with within >> acceptable (to operators) bounds of cost and performance.
>>
>> This should be left out of any requirements document, and various<= br> >> proposed system compared based on their costs and deployment
>> difficulty.
>
> i take your point. =A0the intent was that compatibility with current > hardware abilities is not a requirement that this document imposes on = a
> solution. =A0it is quite likely that provider routers will need crypto=
> assist and more ram. =A0though one hope that the stub customer edge wi= ll
> not.

Whoa there. =A0I couldn't disagree more wrt the above.

First, let's start with the most fundamental question. =A0Why is it tha= t routers MUST sign, pass around and verify _in-band_ in the control plane = various contents/PDU's _within_ BGP? =A0Note my very careful use of the= work _in-band_. =A0By that I mean inside the BGP session itself, not on a = side-band channel like RPKI and/or IRR is used today. =A0While I have grave= concerns over in-band signing & verification, I am [much] less concern= ed about the latter for several reasons. =A0With respect to in-band:
1) =A0I'm extremely concerned over dependencies of automatically "= trusting" signed data in-band within the control plane and not being a= ble to reach servers (RP's?) to verify the contents of the PDU's ar= e legitimate. =A0At least with prefix-filters and/or AS_PATH filters, it= 9;s very easy for me to manually disable some or all filtering for particul= ar destinations in order to, say, get reachability to servers (RP's) to= verify the authenticity of data.
2) =A0Related to point #1, we really should go back to first principles ask= ourselves if we're really intending to conflate the _transport_ method= (BGP) with the requirement to verify the data _inside_ of BGP. =A0If so, w= hat is the reason? =A0Is it solely for convenience, (because BGP transport = is already there), or other reasons?
3) =A0I really, really don't like the idea of "will need crypto as= sist and more ram" on my RE/RP's for several reasons, namely:
=A0 =A0a) =A0It's one more set of variables that my already over-worke= d Capacity Planning and NOC groups need to keep track of and attempt to sta= y ahead of.
=A0 =A0b) =A0It's extremely costly to upgrade RE/RP's, because sai= d RE/RP's are only available from one source -- equipment vendors. =A0A= nd, the upgrade paths typically don't buy you much in terms of more CPU= , etc., because vendors are obligated to source "established" com= ponents they know they'll be able to acquire for several years into the= future. =A0And, worst of all, the cycle to get those RE/RP's into the = network is extremely long when you start to consider the budgeting, testing= of new code, physical installation, customer disruption during maintenance= windows, etc.
... at least with respect to (b), if I were able to use offboard CPU (i.e.:= Intel/AMD servers, like in the RPKI/IRR world), then I have a much larger = selection of HW to choose from and I can upgrade those in the network much,= much more quickly.

At least with respect to #1 and #2, I don't see any discussion of the a= bove in the current draft (although maybe I missed it?). =A0But, IMHO, thos= e are _fundamental_ requirements that need to be discussed among the WG. = =A0Before touching on any of the other points in Russ White's e-mails i= n this thread, (which I agree with), I think it's important to get back= to basics.


> and the operators with whom we discussed (note that i am an operator,<= br> > not a vendor with a bad habit of speaking for operators) this thought<= br> > that this needed to be said from both ends of the scale. =A0we did not=
> want the future security constrained by a 7200, nor did we want an
> explosion in costs. =A0as dollars are the bottom line in our capitalis= t
> culture, constraining them seems quite reasonable.

It wasn't discussed with me. =A0:-)

-shane
__________________________________= _____________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--90e6ba53ad7447e01b049c045f18-- From russ@cisco.com Fri Feb 11 09:02:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547C13A69D2 for ; Fri, 11 Feb 2011 09:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Azf9HKq1HFGz for ; Fri, 11 Feb 2011 09:02:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6F6F23A6784 for ; Fri, 11 Feb 2011 09:02:02 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM/6VE1AZnwM/2dsb2JhbACldHOfTZs3hV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,456,1291593600"; d="asc'?scan'208";a="214568029" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2011 17:02:17 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BH2H6n029717; Fri, 11 Feb 2011 17:02:17 GMT Message-ID: <4D556BA7.6040501@cisco.com> Date: Fri, 11 Feb 2011 12:02:31 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tony Tauber References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig49940F7DC3AE63D5FF6C124D" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 17:02:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig49940F7DC3AE63D5FF6C124D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Why don't we work on getting someone on board with a working something > before getting down the garden path which leads people to throw up thei= r > hands about non-starters and stuff. It would be _terrific_ to have a requirements document built and supported on the provider side --possibly with some various government folks (will they have different requirements? Don't know) thrown in for good measure. I'd really prefer this to a vendor or research based set of requirements to work from. :-) Russ --------------enig49940F7DC3AE63D5FF6C124D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Va6oACgkQER27sUhU9ORPbgCg5bL6NBwNBTu/jnFXBHH6aCzj p7EAniF2ZjTYS4oNQ5fZsHJWRlsFL9we =RM3y -----END PGP SIGNATURE----- --------------enig49940F7DC3AE63D5FF6C124D-- From Donald.Smith@qwest.com Fri Feb 11 09:29:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549D73A6860 for ; Fri, 11 Feb 2011 09:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ggVvUyeuXQ3 for ; Fri, 11 Feb 2011 09:29:36 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 1FD623A67DA for ; Fri, 11 Feb 2011 09:29:36 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p1BHTMCv027541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Feb 2011 11:29:23 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A3A0D1E0175; Fri, 11 Feb 2011 10:21:42 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 703701E0A52; Fri, 11 Feb 2011 10:21:42 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p1BHLb14010367; Fri, 11 Feb 2011 11:21:41 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Fri, 11 Feb 2011 10:21:09 -0700 From: "Smith, Donald" To: "'Shane Amante'" , "'Randy Bush'" Date: Fri, 11 Feb 2011 10:21:08 -0700 Thread-Topic: [sidr] bgpsec-reqs-00 Thread-Index: AcvKA5HT9Q0MuOzIQMKb515p006s1QAC1dbQ Message-ID: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> In-Reply-To: <4C8FBB30-474A-410A-B384-B6F775EAA1E9@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Russ White' , "'sidr@ietf.org'" Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 17:29:37 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On > Behalf Of Shane Amante > Sent: Friday, February 11, 2011 8:51 AM > To: Randy Bush > Cc: sidr@ietf.org; Russ White > Subject: Re: [sidr] bgpsec-reqs-00 > > Randy, > > On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: > >> 3.3 As cryptographic payloads and loading on routers are likely to > >> seriously increase, a BGPsec design may require use of new > hardware. > >> It must be possible to build routers that do BGPsec with within > >> acceptable (to operators) bounds of cost and performance. > >> > >> This should be left out of any requirements document, and various > >> proposed system compared based on their costs and deployment > >> difficulty. > > > > i take your point. the intent was that compatibility with current > > hardware abilities is not a requirement that this document > imposes on a > > solution. it is quite likely that provider routers will need crypto > > assist and more ram. though one hope that the stub > customer edge will > > not. Adding crypto engines and more ram is going to be expensive not just from a= hardware pov but from power and heat. We (ISPs) budget those items too. If all of my routers suddenly needed 20% = more of either of those its going to affect our bottom line (cost of transp= ort goes up):) > > Whoa there. I couldn't disagree more wrt the above. I could disagree more but Shane does a pretty good job here of stating why = this is an issue. (thanks Shane). > > First, let's start with the most fundamental question. Why > is it that routers MUST sign, pass around and verify > _in-band_ in the control plane various contents/PDU's > _within_ BGP? Note my very careful use of the work > _in-band_. By that I mean inside the BGP session itself, not > on a side-band channel like RPKI and/or IRR is used today. > While I have grave concerns over in-band signing & > verification, I am [much] less concerned about the latter for > several reasons. With respect to in-band: > 1) I'm extremely concerned over dependencies of > automatically "trusting" signed data in-band within the > control plane and not being able to reach servers (RP's?) to > verify the contents of the PDU's are legitimate. At least > with prefix-filters and/or AS_PATH filters, it's very easy > for me to manually disable some or all filtering for > particular destinations in order to, say, get reachability to > servers (RP's) to verify the authenticity of data. Route filters in many ISPs are created and validated nightly and pushed to = routers if a filter change is needed. That isn't usually done in real time. It is almost always done on COTS hard= ware (not on the router it's self). > 2) Related to point #1, we really should go back to first > principles ask ourselves if we're really intending to > conflate the _transport_ method (BGP) with the requirement to > verify the data _inside_ of BGP. If so, what is the reason? > Is it solely for convenience, (because BGP transport is > already there), or other reasons? > 3) I really, really don't like the idea of "will need crypto > assist and more ram" on my RE/RP's for several reasons, namely: > a) It's one more set of variables that my already > over-worked Capacity Planning and NOC groups need to keep > track of and attempt to stay ahead of. > b) It's extremely costly to upgrade RE/RP's, because > said RE/RP's are only available from one source -- equipment > vendors. And, the upgrade paths typically don't buy you much > in terms of more CPU, etc., because vendors are obligated to > source "established" components they know they'll be able to > acquire for several years into the future. And, worst of > all, the cycle to get those RE/RP's into the network is > extremely long when you start to consider the budgeting, > testing of new code, physical installation, customer > disruption during maintenance windows, etc. > ... at least with respect to (b), if I were able to use > offboard CPU (i.e.: Intel/AMD servers, like in the RPKI/IRR > world), then I have a much larger selection of HW to choose exactly! > from and I can upgrade those in the network much, much more quickly. > > At least with respect to #1 and #2, I don't see any > discussion of the above in the current draft (although maybe > I missed it?). But, IMHO, those are _fundamental_ > requirements that need to be discussed among the WG. Before > touching on any of the other points in Russ White's e-mails > in this thread, (which I agree with), I think it's important > to get back to basics. > > > > and the operators with whom we discussed (note that i am an > operator, > > not a vendor with a bad habit of speaking for operators) > this thought > > that this needed to be said from both ends of the scale. we did not > > want the future security constrained by a 7200, nor did we want an > > explosion in costs. as dollars are the bottom line in our > capitalist > > culture, constraining them seems quite reasonable. > > It wasn't discussed with me. :-) > > -shane > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From christopher.morrow@gmail.com Fri Feb 11 12:37:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD223A6997 for ; Fri, 11 Feb 2011 12:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY6dG4LnwQs7 for ; Fri, 11 Feb 2011 12:37:00 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4044E3A6925 for ; Fri, 11 Feb 2011 12:37:00 -0800 (PST) Received: by wyf23 with SMTP id 23so3077411wyf.31 for ; Fri, 11 Feb 2011 12:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ijOpzPZ97NwGmUjeT/G+0S8W+TKQ8MWeokuktneDhEA=; b=sTLMH5oqCM++KYM6TmaDpqfcylGoU5zASRD+Nze+N4XvcPjCu3dDMJKC6Ctx5X9Par UqRVnUcHvLPyCv8NGS9z3lbzu3Sh/EYEByX7Bc+Laabc5GOogi+I/tlA1t2wnBqWnjFV cmA+NyN19tmSAPM4PmH7p8xRqvHabRTCz/hrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=N3rPvl6EG6eNyfP6/KnFXs6NliDqy4xtgTvye+Vltv2yul+ssQK463Fls5md7kvenc a7pCYJGsNFmGANxoWw2NAFyya9x7NODCIHwbGnG7DJuvjgWxOtUqxtrWkphwwdAKJcmD KiPP3szw4BSz3W1F6vv4otGOYtzm6U5XezLkw= MIME-Version: 1.0 Received: by 10.216.160.84 with SMTP id t62mr909879wek.69.1297456632910; Fri, 11 Feb 2011 12:37:12 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Fri, 11 Feb 2011 12:37:12 -0800 (PST) In-Reply-To: <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> Date: Fri, 11 Feb 2011 15:37:12 -0500 X-Google-Sender-Auth: a86LQx-DV6_4jGvMfVKiLodJ0v0 Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Russ White , sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:37:02 -0000 (no hats today!) On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante wrot= e: > Randy, > > On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >>> 3.3 As cryptographic payloads and loading on routers are likely to >>> seriously increase, a BGPsec design may require use of new hardware. >>> It must be possible to build routers that do BGPsec with within >>> acceptable (to operators) bounds of cost and performance. >>> >>> This should be left out of any requirements document, and various >>> proposed system compared based on their costs and deployment >>> difficulty. >> >> i take your point. =A0the intent was that compatibility with current >> hardware abilities is not a requirement that this document imposes on a >> solution. =A0it is quite likely that provider routers will need crypto >> assist and more ram. =A0though one hope that the stub customer edge will >> not. > > Whoa there. =A0I couldn't disagree more wrt the above. > > First, let's start with the most fundamental question. =A0Why is it that = routers MUST sign, pass > around and verify _in-band_ in the control plane various contents/PDU's _= within_ BGP? =A0Note my > very careful use of the work _in-band_. =A0By that I mean inside the BGP = session itself, not on a (note this probably strays a tad from 'requirements', I think there's also some utlity coming from the RPKI that's NOT necesarily ) One way I looked at this was that if the router that originates a route today slaps an ASN on, no one is the wiser as to where/what originated the actual route. A router in the middle of AS701 can announce a route origined AS7018... if you look closely the route looks 'odd' but other than that it's all good. Signing, in the case of origin validation, the route on the origin router (or from the origin ASN border router(s) ) means that you can say with some certainty that: 1) the route was originated by the owner of the certificate for that ASN 2) the owner of that ASN cert lost his/her private key :( Hopefully it's more 1 than 2... and hopefully if 2, the owner CRL's the cert 'quickly'. Regardless downstream ASN's can say: "Yes, I see that route is origined by AS701, she signed the route for us, w00t!" Ideally with origin-validation + prefix-lists and as-path filters you have better assurance that the route you see is really from that origin. With the addition of RPKI data you should be able to query the IRR, join that against the RPKI and create a concise prefix-list that doesn't include legacy data users never cleaned out :( For some period of time the best part of this should be the RPKI data for use in making the prefix-list stuff better/faster/cleaner. I think what's also missed some in the discussions is that prefix-list + as-path filters (+ other things you already do as a provider to protect yourself from naughty customer devices) will continue to live on. > side-band channel like RPKI and/or IRR is used today. =A0While I have gra= ve concerns over in-band > signing & verification, I am [much] less concerned about the latter for s= everal reasons. =A0With > respect to in-band: > > 1) =A0I'm extremely concerned over dependencies of automatically "trustin= g" signed data in-band > within the control plane and not being able to reach servers (RP's?) to v= erify the contents of the > PDU's are legitimate. =A0At least with prefix-filters and/or AS_PATH filt= ers, it's very easy for me to > manually disable some or all filtering for particular destinations in ord= er to, say, get reachability to > servers (RP's) to verify the authenticity of data. The architecture should provide, or the design includes the provision, to have the data as close to your router(s) as you think is relevant. It also includes the ability to NOT validate, or decide to do nothing with the validation state info. Additionally, the routers keep a local cache of the data that the RPKI global system contains (minus some skew perhaps)... In a fresh-boot scenario you most certainly won't have rpki data to use, you'll just not-validate data from your customers until you have that data. Keep in mind though that the RPKI data has helped you to build prefix-list/as-path filters so hopefully it's not all sunk :) you can accept what prefixes you should expect from your customer(s) and pass those along as normal. Later, once security-data is available to you, you can start verifying that the announcements you see are valid. some more discussion of cold-start is necessary, and some ideas in the -ops doc(s) will be helpful surrounding this (cold-start) and placement of caches inside a network. (outlining the tradeoffs of distance from the router who needs to use the cache) > > 2) =A0Related to point #1, we really should go back to first principles a= sk ourselves if we're really > intending to conflate the _transport_ method (BGP) with the requirement t= o verify the data > _inside_ of BGP. =A0If so, what is the reason? =A0Is it solely for conven= ience, (because BGP transport > is already there), or other reasons? I think, that today you receive a route in BGP, you believe it's proper and pass it on. you have no real way to tell if the route was originated by the ASN in the first (last? right-most) AS hop, you have no real assurance that the prefix-list you used to fllter the route is actually correct, and you have no understanding of the path seen in the as-path aside from what the text says. (see pilosov/kopella) > > 3) =A0I really, really don't like the idea of "will need crypto assist an= d more ram" on my RE/RP's for > several reasons, namely: > =A0 =A0a) =A0It's one more set of variables that my already over-worked C= apacity Planning and NOC > groups need to keep track of and attempt to stay ahead of. > =A0 =A0b) =A0It's extremely costly to upgrade RE/RP's, because said RE/RP= 's are only available from one > source -- equipment vendors. =A0And, the upgrade paths typically don't bu= y you much in terms of > more CPU, etc., because vendors are obligated to source "established" com= ponents they know > they'll be able to acquire for several years into the future. =A0And, wor= st of all, the cycle to get those > RE/RP's into the network is extremely long when you start to consider the= budgeting, testing of > new code, physical installation, customer disruption during maintenance w= indows, etc. > ... at least with respect to (b), if I were able to use offboard CPU (i.e= .: Intel/AMD servers, like in > the RPKI/IRR world), then I have a much larger selection of HW to choose = from and I can > upgrade those in the network much, much more quickly. Some of the 'more ram, 64-bit os, faster-cpu, crypto-offload' non-worry for me was that both large vendors stated: "We are working toward 64-bit OS, ability to have much more RAM on board and faster CPU's. If you think crypto-offload is helpful, we can add that as well in the right rev of device/card/etc" I am under the impression that if we believe the ability of SIDR output (rpki + protocol changes) to be used in ~7-10 years, I think we made this timeline based on normal cycle times for routers in larger networks. I hope that in the next rev or so of gear everyone buys we'll see capacity for RAM increase, crypto-help (* if necessary) and faster/more cpu. I believe both large vendors are on track to provide 64-bit OS's soonish as well. > At least with respect to #1 and #2, I don't see any discussion of the abo= ve in the current draft > (although maybe I missed it?). =A0But, IMHO, those are _fundamental_ requ= irements that need to > be discussed among the WG. =A0Before touching on any of the other points = in Russ White's e-mails > in this thread, (which I agree with), I think it's important to get back = to basics. what would you add to the reqs draft? (some example/short text to be fleshed out, bullets?) >> and the operators with whom we discussed (note that i am an operator, >> not a vendor with a bad habit of speaking for operators) this thought >> that this needed to be said from both ends of the scale. =A0we did not >> want the future security constrained by a 7200, nor did we want an >> explosion in costs. =A0as dollars are the bottom line in our capitalist >> culture, constraining them seems quite reasonable. > > It wasn't discussed with me. =A0:-) wanna discuss it now? -Chris > > -shane > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Fri Feb 11 12:39:38 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C25F3A6925 for ; Fri, 11 Feb 2011 12:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWb5ipcouBPP for ; Fri, 11 Feb 2011 12:39:37 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 217DA3A67B3 for ; Fri, 11 Feb 2011 12:39:36 -0800 (PST) Received: by wyf23 with SMTP id 23so3079516wyf.31 for ; Fri, 11 Feb 2011 12:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T8MFIvdsjKmJxarjVkjgENMFqvdC2anJD2Js8BhvEc0=; b=Tqiv5wtGVowEdyWxuiHx0DLConXbKjpygkFOLa3KudXXM/KtT13o2EIr0pEFLAWEK4 B8JmUKv1UIvo5Q9Jt+36sTQzNAo3jpTuIfsxxzsuj4KILKBef/p5TPmurZfLQXIyMgHW TzGNdPl1K0shB3zFCbTtWMu47Q+4mHRb/EHa0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qhyRkLsSU3n5rTK++W3e9V/Jm/y3QcpRbshd6434JSd/Po+TEnPD0mzImgro84hdd/ C5VU/GkJ5LpTVG08cnJivBMJQcJumQosAjH0Iceeu2BGAw+GJc2Z67VVJIOm5kBoa/6o Lb8d0Pz6GWJLqG3mTr4VaHFecSInjIqi3kD7Q= MIME-Version: 1.0 Received: by 10.216.158.21 with SMTP id p21mr918691wek.99.1297456788943; Fri, 11 Feb 2011 12:39:48 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Fri, 11 Feb 2011 12:39:48 -0800 (PST) In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> Date: Fri, 11 Feb 2011 15:39:48 -0500 X-Google-Sender-Auth: EU2prIRYQVf_4dXmz99ZfrV_YAc Message-ID: From: Christopher Morrow To: Tony Tauber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org, Russ White Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:39:38 -0000 On Fri, Feb 11, 2011 at 11:41 AM, Tony Tauber wrote: > I'm also wondering on which provider routers Randy's seeing the need for > crypto and other HW upgrades. > If it's every router that carries full routes or terminates an external B= GP > session, that can be a pretty big nut to swallow. if this happens in the normal course of upgrades, over the next 4-7 years... is it still a big deal? > Why don't we work on getting someone on board with a working something > before getting down the garden path which leads people to throw up their > hands about non-starters and stuff. > > Tony > > On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante > wrote: >> >> Randy, >> >> On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >> >> 3.3 As cryptographic payloads and loading on routers are likely to >> >> seriously increase, a BGPsec design may require use of new hardware. >> >> It must be possible to build routers that do BGPsec with within >> >> acceptable (to operators) bounds of cost and performance. >> >> >> >> This should be left out of any requirements document, and various >> >> proposed system compared based on their costs and deployment >> >> difficulty. >> > >> > i take your point. =A0the intent was that compatibility with current >> > hardware abilities is not a requirement that this document imposes on = a >> > solution. =A0it is quite likely that provider routers will need crypto >> > assist and more ram. =A0though one hope that the stub customer edge wi= ll >> > not. >> >> Whoa there. =A0I couldn't disagree more wrt the above. >> >> First, let's start with the most fundamental question. =A0Why is it that >> routers MUST sign, pass around and verify _in-band_ in the control plane >> various contents/PDU's _within_ BGP? =A0Note my very careful use of the = work >> _in-band_. =A0By that I mean inside the BGP session itself, not on a sid= e-band >> channel like RPKI and/or IRR is used today. =A0While I have grave concer= ns >> over in-band signing & verification, I am [much] less concerned about th= e >> latter for several reasons. =A0With respect to in-band: >> 1) =A0I'm extremely concerned over dependencies of automatically "trusti= ng" >> signed data in-band within the control plane and not being able to reach >> servers (RP's?) to verify the contents of the PDU's are legitimate. =A0A= t >> least with prefix-filters and/or AS_PATH filters, it's very easy for me = to >> manually disable some or all filtering for particular destinations in or= der >> to, say, get reachability to servers (RP's) to verify the authenticity o= f >> data. >> 2) =A0Related to point #1, we really should go back to first principles = ask >> ourselves if we're really intending to conflate the _transport_ method (= BGP) >> with the requirement to verify the data _inside_ of BGP. =A0If so, what = is the >> reason? =A0Is it solely for convenience, (because BGP transport is alrea= dy >> there), or other reasons? >> 3) =A0I really, really don't like the idea of "will need crypto assist a= nd >> more ram" on my RE/RP's for several reasons, namely: >> =A0 =A0a) =A0It's one more set of variables that my already over-worked = Capacity >> Planning and NOC groups need to keep track of and attempt to stay ahead = of. >> =A0 =A0b) =A0It's extremely costly to upgrade RE/RP's, because said RE/R= P's are >> only available from one source -- equipment vendors. =A0And, the upgrade= paths >> typically don't buy you much in terms of more CPU, etc., because vendors= are >> obligated to source "established" components they know they'll be able t= o >> acquire for several years into the future. =A0And, worst of all, the cyc= le to >> get those RE/RP's into the network is extremely long when you start to >> consider the budgeting, testing of new code, physical installation, cust= omer >> disruption during maintenance windows, etc. >> ... at least with respect to (b), if I were able to use offboard CPU >> (i.e.: Intel/AMD servers, like in the RPKI/IRR world), then I have a muc= h >> larger selection of HW to choose from and I can upgrade those in the net= work >> much, much more quickly. >> >> At least with respect to #1 and #2, I don't see any discussion of the >> above in the current draft (although maybe I missed it?). =A0But, IMHO, = those >> are _fundamental_ requirements that need to be discussed among the WG. >> =A0Before touching on any of the other points in Russ White's e-mails in= this >> thread, (which I agree with), I think it's important to get back to basi= cs. >> >> >> > and the operators with whom we discussed (note that i am an operator, >> > not a vendor with a bad habit of speaking for operators) this thought >> > that this needed to be said from both ends of the scale. =A0we did not >> > want the future security constrained by a 7200, nor did we want an >> > explosion in costs. =A0as dollars are the bottom line in our capitalis= t >> > culture, constraining them seems quite reasonable. >> >> It wasn't discussed with me. =A0:-) >> >> -shane >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From christopher.morrow@gmail.com Fri Feb 11 12:40:59 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD703A6A3C for ; Fri, 11 Feb 2011 12:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwla8K1HCgI1 for ; Fri, 11 Feb 2011 12:40:59 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CD82C3A6A53 for ; Fri, 11 Feb 2011 12:40:58 -0800 (PST) Received: by wwa36 with SMTP id 36so2952243wwa.13 for ; Fri, 11 Feb 2011 12:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oNqSVS1DITu4Z2M57eiZsOrSMDulXup7zSfWEDPY+dM=; b=rOaS8kyr4VmhPhnHjSrSCRtTKAlxqB8/rQ5flF/becae4CFHizpTOu213QqGZReMoO pdntvZZmE9A/livCS+XyqN/hh+/ZbTaToYtOYpIlSzkHucpr7iAAE9yADiApDEIffIJ+ EADzOlmrEkh7sBN+L4xQrAD25svIeWzWNdYO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Hg1xoGHjT1AP3ti0E19N7xgAhhLxn9I3Q/A9aLQiK0FyDClrsxRa8wAIFQYwBCyoBl V2ePDiNDHyUgJVkT3bOdoDdWvsO1W+G3fDuboEr/ufOzoB1fFdpB7Gkkruwer1VGTfKA sAcMNNIPPwGK4ruULxChwXGJwB9es7vyj+xWo= MIME-Version: 1.0 Received: by 10.216.154.136 with SMTP id h8mr922962wek.84.1297456873959; Fri, 11 Feb 2011 12:41:13 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Fri, 11 Feb 2011 12:41:13 -0800 (PST) In-Reply-To: <4D556BA7.6040501@cisco.com> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D556BA7.6040501@cisco.com> Date: Fri, 11 Feb 2011 15:41:13 -0500 X-Google-Sender-Auth: P3V4mF4Ag5Wi89eyGGbFD_iOhiI Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:40:59 -0000 On Fri, Feb 11, 2011 at 12:02 PM, Russ White wrote: > >> Why don't we work on getting someone on board with a working something >> before getting down the garden path which leads people to throw up their >> hands about non-starters and stuff. > > It would be _terrific_ to have a requirements document built and > supported on the provider side --possibly with some various government there have been some provider side folks involved actually... which is one of the reasons for some of the requirements and assumptions. From christopher.morrow@gmail.com Fri Feb 11 12:43:51 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F48E3A6925 for ; Fri, 11 Feb 2011 12:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMeQxxSxQrgH for ; Fri, 11 Feb 2011 12:43:50 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 43FBF3A6878 for ; Fri, 11 Feb 2011 12:43:50 -0800 (PST) Received: by wwa36 with SMTP id 36so2954601wwa.13 for ; Fri, 11 Feb 2011 12:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=j2ow4Bu3DRZ94ZtX/X58RQKnbMMWcTYjOgw4N0ZIdME=; b=muOqYZyNriuQfGBjm577EScQ/qh9MLQvU6vx0jxbGz22dNIQmSgfAKzU42OOSBhaoj COMMrbxrVivpi1Ce5p0J4F14gZbEGD+z8BN/DgtJEaGskjXxdmDN+XxPrPFWNCwifdnA gLK3qJps92FUzYU5+hJoEGtsZmfUAB+B+J13o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=IIr+1O+MEtUtD0VlegJMMlPkRuXraFkzqC2tHHMZm8b1ZTJ3vGBN/lMxDqd0AbZP7d VKPqyhA0nRfzno5kJ6BAp8tT82r25DSaI7rEJoMdtCTiQxxXYJ2v9qnlU+rpVgpeqDEp 0DLFzxJaU9EBTzcxu3D79Oihw+ATRqX9pyO6U= MIME-Version: 1.0 Received: by 10.216.179.133 with SMTP id h5mr931972wem.69.1297457045334; Fri, 11 Feb 2011 12:44:05 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Fri, 11 Feb 2011 12:44:05 -0800 (PST) In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> Date: Fri, 11 Feb 2011 15:44:05 -0500 X-Google-Sender-Auth: UATRU_bwTPUSqyck8AMJdLzcYgM Message-ID: From: Christopher Morrow To: "Smith, Donald" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" , Russ White Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 20:43:51 -0000 On Fri, Feb 11, 2011 at 12:21 PM, Smith, Donald wrote: > Route filters in many ISPs are created and validated nightly and pushed to routers if a filter change is needed. > That isn't usually done in real time. It is almost always done on COTS hardware (not on the router it's self). > agreed, there's some cycle to update filters... the problem is that the source of the filter data is ... horrendous. there's no way to validate what you THINK should be there vs what IS there. there is no way to mechanically keep this data updated, to disqualify bad data and to use quality data. Auto-adding routes because your customer announces you a route is ... not a good plan. auto-adding these to the IRR which is then globally available and not-fixable by the actual origin is also 'bad'. we can do better, rpki provides a path to making that better. rpki is not all of the sidr work though. From jared@puck.nether.net Fri Feb 11 13:02:49 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFAD3A69DE for ; Fri, 11 Feb 2011 13:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMrpw34y2dxk for ; Fri, 11 Feb 2011 13:02:48 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 1F9553A6A5A for ; Fri, 11 Feb 2011 13:02:47 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.12.9) with ESMTP id p1BL2oel048983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Feb 2011 16:02:50 -0500 (EST) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> Date: Fri, 11 Feb 2011 16:02:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <879C5C16-4EA6-4CF6-BD2F-6F223A35ECB2@puck.nether.net> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 11 Feb 2011 16:02:51 -0500 (EST) Cc: Russ White , sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 21:02:49 -0000 On Feb 11, 2011, at 10:51 AM, Shane Amante wrote: > Randy, >=20 > On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >>> 3.3 As cryptographic payloads and loading on routers are likely to >>> seriously increase, a BGPsec design may require use of new hardware. >>> It must be possible to build routers that do BGPsec with within >>> acceptable (to operators) bounds of cost and performance. >>>=20 >>> This should be left out of any requirements document, and various >>> proposed system compared based on their costs and deployment >>> difficulty. >>=20 >> i take your point. the intent was that compatibility with current >> hardware abilities is not a requirement that this document imposes on = a >> solution. it is quite likely that provider routers will need crypto >> assist and more ram. though one hope that the stub customer edge = will >> not. >=20 > Whoa there. I couldn't disagree more wrt the above. >=20 > First, let's start with the most fundamental question. Why is it that = routers MUST sign, pass around and verify _in-band_ in the control plane = various contents/PDU's _within_ BGP? Note my very careful use of the = work _in-band_. By that I mean inside the BGP session itself, not on a = side-band channel like RPKI and/or IRR is used today. While I have = grave concerns over in-band signing & verification, I am [much] less = concerned about the latter for several reasons. With respect to = in-band: > 1) I'm extremely concerned over dependencies of automatically = "trusting" signed data in-band within the control plane and not being = able to reach servers (RP's?) to verify the contents of the PDU's are = legitimate. At least with prefix-filters and/or AS_PATH filters, it's = very easy for me to manually disable some or all filtering for = particular destinations in order to, say, get reachability to servers = (RP's) to verify the authenticity of data. > 2) Related to point #1, we really should go back to first principles = ask ourselves if we're really intending to conflate the _transport_ = method (BGP) with the requirement to verify the data _inside_ of BGP. = If so, what is the reason? Is it solely for convenience, (because BGP = transport is already there), or other reasons? Because it's the easiest place to do it. i once had someone tell me = that something should be carried in BGP because it was "easier" than = duplicating all the code for a new network protocol to do the data = copying/replication. As a non-professional implementer, I considered = their opinion valuable. > 3) I really, really don't like the idea of "will need crypto assist = and more ram" on my RE/RP's for several reasons, namely: > a) It's one more set of variables that my already over-worked = Capacity Planning and NOC groups need to keep track of and attempt to = stay ahead of. > b) It's extremely costly to upgrade RE/RP's, because said RE/RP's = are only available from one source -- equipment vendors. And, the = upgrade paths typically don't buy you much in terms of more CPU, etc., = because vendors are obligated to source "established" components they = know they'll be able to acquire for several years into the future. And, = worst of all, the cycle to get those RE/RP's into the network is = extremely long when you start to consider the budgeting, testing of new = code, physical installation, customer disruption during maintenance = windows, etc. > ... at least with respect to (b), if I were able to use offboard CPU = (i.e.: Intel/AMD servers, like in the RPKI/IRR world), then I have a = much larger selection of HW to choose from and I can upgrade those in = the network much, much more quickly. I think there's a few things here that are certainly valid concerns. = I'd like to refresh them into the following based on my observations: 1) The transport core of the network where all these control-plane = messages currently happen is growing and requires dense-high bandwidth = routers 2) when you upgrade the router/fabric/whatnot you typically need some = new routing-engine, rsp, cpu, etc. that is typically "faster". Maybe = not fast enough for some, but they tend to be "faster". 3) As a percentage cost of an overall upgrade (take t640 -> t1600) the = RE component is not the most expensive part by far 4) Cisco/Juniper have some products that are certainly long in the tooth = and honestly are too underpowered for even their own aggressive cpu = consumption/growth. It's so bad in cases they don't realize the = performance is poor on the older hardware as the labs typically have (on = average) newer hardware than in the core provider networks. As of today, crypto can be expensive if you don't have something = designed to accelerate it (eg: hardware assist for SSL on some = platforms). Just because it can be, doesn't mean it is catastrophic. = I'd rather cisco stop leaking memory when processing bgp attributes, but = 6 months of the TAC staring at the problem didn't seem to help them. (Or = juniper to stop dying due to ipv6 bgp attributes on 4-byte routes). I don't necessarily trust anyone in this arena. There's a lot of = potential for harm. I don't want my routers to require on some external = device. You may be willing to live with that, but I can not. I can not = allow my network to be constrained by some COTS PC where the vendors are = unwilling to support it, or decide that it's cheaper to just refund the = entire cost than fix/replace it (As is happening with HP/Dell on some = devices now - google 'sandy bridge' and/or 'cougar point'). While an = ECO is something painful for anyone, I would rather it be on something = where the vendor is going to stand behind it, vs people who can't trust = you to plug in anything (optics, another vendors bgp speaking device, = etc) and have their devices operate properly. There needs to be some built-in inherent trust, and as an operator = here's the things i look at/for: - Ability to simulate something, eg: sidr/roa checks, as_path = validation, etc in the cli=20 - ability to soft-fail items (appropriate logging/data import and = export) - ability to bootstrap devices - ability to hard-fail items (above) - ability to properly log anything! (developers are really bad about this, either they dump a full raw hex = item, or a worthless message that describes an error condition that is = not decipherable as they don't realize they are part of a full system vs = their individual zone of importance/ego) > At least with respect to #1 and #2, I don't see any discussion of the = above in the current draft (although maybe I missed it?). But, IMHO, = those are _fundamental_ requirements that need to be discussed among the = WG. Before touching on any of the other points in Russ White's e-mails = in this thread, (which I agree with), I think it's important to get back = to basics. >=20 >=20 >> and the operators with whom we discussed (note that i am an operator, >> not a vendor with a bad habit of speaking for operators) this thought >> that this needed to be said from both ends of the scale. we did not >> want the future security constrained by a 7200, nor did we want an >> explosion in costs. as dollars are the bottom line in our capitalist >> culture, constraining them seems quite reasonable. >=20 > It wasn't discussed with me. :-) I like the fact that Randy has talked about if you do the validation, = how much incremental cpu time it takes vs processing a = prefix-list/as-paths, etc. True comparision/data. I'm sure he can = provide you links showing that the "puny" cpus can keep up, and you = don't need a 52-way cpu system to process the bgp messages. (i am also frustrated that too few of my colleagues/peers have time to = participate in this stuff, and also that it takes so much time away from = my family.. then again, i'm sure i'm some sort of a tech addict as = well). - Jared= From christopher.morrow@gmail.com Fri Feb 11 18:19:00 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF973A6A0C for ; Fri, 11 Feb 2011 18:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmO2N7ROnLTk for ; Fri, 11 Feb 2011 18:19:00 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DF1EA3A69EE for ; Fri, 11 Feb 2011 18:18:59 -0800 (PST) Received: by wwa36 with SMTP id 36so3177260wwa.13 for ; Fri, 11 Feb 2011 18:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5bJ4OusAZBuy7yNhCff17aOlz0lBERl3JaWOSCeAKSM=; b=BELaohQAALCPHI9GxmsIJm28ApQWSGHp0QGOEckWWoiJ+toolhe33XMOFlqc7CySdn 1dGU3L/toe/RS//hrmcsILkMpbH9JEekZCowzYl/yxYTi1Z0rToae8h2qHc9gYwrCaoZ DKXZA9dg5gKGjIs43U8KeTlc5vRyqY6jBOcjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IuFbRmxhdzjM5hU4zVFGvHVDvNvNPE/g7Zx/d28tTSpnBiinhzpFtCBd81BIUoL5Bc TZKuFbK3ygwmcayT25qTr8tHY0oD/e1RtsbTKeuofVvbsniFi8fILVAJPiXV+D9ln/q2 6+fAQSDB9r7AX98blPoDcXf+YOein5jcV+TCs= MIME-Version: 1.0 Received: by 10.216.14.147 with SMTP id d19mr1224798wed.84.1297477155281; Fri, 11 Feb 2011 18:19:15 -0800 (PST) Received: by 10.216.1.197 with HTTP; Fri, 11 Feb 2011 18:19:15 -0800 (PST) In-Reply-To: <4D55584B.3020704@ieca.com> References: <4D55584B.3020704@ieca.com> Date: Fri, 11 Feb 2011 21:19:15 -0500 Message-ID: From: Christopher Morrow To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC comments: draft-sidr-iana-objects-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 02:19:00 -0000 On Fri, Feb 11, 2011 at 10:39 AM, Sean Turner wrote: > On 2/10/11 9:14 PM, Terry Manderson wrote: >> Apart from the last open item, would you be ok if I made the changes prior >> to IESG submission instead of cutting another revision. > > That's fine by me. alright... so once these changes are done I think we're out of WGLC, eh? (I presume terry sends a sample set back to sean, but that's hidden from us, and fine). Terry/Sean please let us know when the sausage is made? -Chris From randy@psg.com Sat Feb 12 03:18:54 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2303A695C for ; Sat, 12 Feb 2011 03:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g86+mA4jsNI for ; Sat, 12 Feb 2011 03:18:53 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id B6B463A68F4 for ; Sat, 12 Feb 2011 03:18:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=client65-171.sdsc.edu.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PoDVM-000Bkr-Fn; Sat, 12 Feb 2011 11:19:08 +0000 Date: Sat, 12 Feb 2011 03:19:08 -0800 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 11:18:54 -0000 >> Route filters in many ISPs are created and validated nightly and >> pushed to routers if a filter change is needed. >> That isn't usually done in real time. It is almost always done on >> COTS hardware (not on the router it's self). > > agreed, there's some cycle to update filters... the problem is that > the source of the filter data is ... horrendous. there's no way to > validate what you THINK should be there vs what IS there. there is no > way to mechanically keep this data updated, to disqualify bad data and > to use quality data. > > Auto-adding routes because your customer announces you a route is ... > not a good plan. auto-adding these to the IRR which is then globally > available and not-fixable by the actual origin is also 'bad'. > > we can do better, rpki provides a path to making that better. rpki is > not all of the sidr work though. actually, at the request of a rather large provider, the rpki data are faked into a pseudo-irr instance which those who base filters on irr (for example, the verio/ntt) can use. e.g. rair.local:/Users/randy> whois -h whois.rpki.net 198.180.152.0/24 route: 198.180.152.0/24 descr: 198.180.152.0/24-24 origin: AS4128 notify: irr-hack@rpki.net mnt-by: MAINT-RPKI changed: irr-hack@rpki.net 20100914 source: RPKI randy From randy@psg.com Sat Feb 12 03:34:28 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2CC3A6960 for ; Sat, 12 Feb 2011 03:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XABLuq+JR4SG for ; Sat, 12 Feb 2011 03:34:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C7BFD3A695C for ; Sat, 12 Feb 2011 03:34:27 -0800 (PST) Received: from localhost ([127.0.0.1] helo=client65-171.sdsc.edu.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PoDkS-000Bn4-5I; Sat, 12 Feb 2011 11:34:44 +0000 Date: Sat, 12 Feb 2011 03:34:43 -0800 Message-ID: From: Randy Bush To: Jared Mauch In-Reply-To: <879C5C16-4EA6-4CF6-BD2F-6F223A35ECB2@puck.nether.net> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <879C5C16-4EA6-4CF6-BD2F-6F223A35ECB2@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 11:34:29 -0000 > I think there's a few things here that are certainly valid concerns. > I'd like to refresh them into the following based on my observations: > > 1) The transport core of the network where all these control-plane > messages currently happen is growing and requires dense-high bandwidth > routers > 2) when you upgrade the router/fabric/whatnot you typically need some > new routing-engine, rsp, cpu, etc. that is typically "faster". Maybe > not fast enough for some, but they tend to be "faster". > 3) As a percentage cost of an overall upgrade (take t640 -> t1600) the > RE component is not the most expensive part by far > 4) Cisco/Juniper have some products that are certainly long in the > tooth and honestly are too underpowered for even their own aggressive > cpu consumption/growth. It's so bad in cases they don't realize the > performance is poor on the older hardware as the labs typically have > (on average) newer hardware than in the core provider networks. > > As of today, crypto can be expensive if you don't have something > destheigned to accelerate it (eg: hardware assist for SSL on some > platforms). crypto assist is getting pretty cheap and will continue to get cheaper. as a vendor friend said, we're gonna be upgrading in the 3-5 year time-frame anyway to get routers that can forward ipv6 at the same rate as ipv4. :( we have been talking in circles about securing inter-domain routing for over a decade. if we lay out a plan and start actually moving forward, our 'natural' core hardware upgrade cycle is on the order of half that time. or we can explain to the wsj why we still have no plan when the next youtube accident occurs. randy From yb@oob.anycats.net Sat Feb 12 06:29:20 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B3E3A6995 for ; Sat, 12 Feb 2011 06:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo-g0+LcOhSL for ; Sat, 12 Feb 2011 06:29:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BA7F43A6A0B for ; Sat, 12 Feb 2011 06:29:18 -0800 (PST) Received: from modemcable088.194-200-24.mc.videotron.ca ([24.200.194.88] helo=[10.0.1.2]) by psg.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PoGTf-000FXG-Kb; Sat, 12 Feb 2011 14:29:35 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Yann Berthier In-Reply-To: Date: Sat, 12 Feb 2011 09:29:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 14:29:20 -0000 On 2011-02-12, at 6:19 AM, Randy Bush wrote: > actually, at the request of a rather large provider, the rpki data are > faked into a pseudo-irr instance which those who base filters on irr > (for example, the verio/ntt) can use. e.g. >=20 > rair.local:/Users/randy> whois -h whois.rpki.net 198.180.152.0/24 Cool ! Are you mirroring the rirs and others' rpkis ? I suppose the code to slurp them and shoehorn the result into a local = irrd is avail, so we could deploy that alongside our internal irrd ? - y= From christopher.morrow@gmail.com Sat Feb 12 07:38:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B4D3A6A0F for ; Sat, 12 Feb 2011 07:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMGx+vQFHqNx for ; Sat, 12 Feb 2011 07:38:50 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 745AF3A69BD for ; Sat, 12 Feb 2011 07:38:50 -0800 (PST) Received: by wyf23 with SMTP id 23so3660020wyf.31 for ; Sat, 12 Feb 2011 07:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rEKiyq42gOcX3T7Em+vZK92QWUtvqduYGTq/B68S68A=; b=Lb7EJzWhsYB8KA+QlW0+qfwjEAoNCpLwWc3jcmrC8f+pS/4ZT8EsECzDbn3hRmoUdy wxSXRoYKsPXM4YpF2T9Q53OLN+7IxEiSnbNeEsod0rcnqxprSoHXTn2qG8scTcfYC+3J WkD40aA0v/b6Kar7EW6/cl+eHeqChObYkEGRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nWDN2FD/IPNvqsnWLHqbFi9qwkxzMpVt18TXXjmRIUU7d273Gu7YrNGI+sqXoOx+T0 0tb0XKnXf63PiOFi1RUkL0qBhKzvD6I1L186rqlURqQVb+eDdwVjcLddG5UDOzqqup+C bOHdSoeeSmMRKQYjIIedkMUZKQdVJoSKNsq/A= MIME-Version: 1.0 Received: by 10.216.158.21 with SMTP id p21mr1632446wek.99.1297525146257; Sat, 12 Feb 2011 07:39:06 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Sat, 12 Feb 2011 07:39:05 -0800 (PST) In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> Date: Sat, 12 Feb 2011 10:39:05 -0500 X-Google-Sender-Auth: 1cjtWED7RbnWl4JSQGoutPvEGJE Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 15:38:52 -0000 On Sat, Feb 12, 2011 at 6:19 AM, Randy Bush wrote: >>> Route filters in many ISPs are created and validated nightly and >>> pushed to routers if a filter change is needed. >>> That isn't usually done in real time. It is almost always done on >>> COTS hardware (not on the router it's self). >> >> agreed, there's some cycle to update filters... the problem is that >> the source of the filter data is ... horrendous. there's no way to >> validate what you THINK should be there vs what IS there. there is no >> way to mechanically keep this data updated, to disqualify bad data and >> to use quality data. >> >> Auto-adding routes because your customer announces you a route is ... >> not a good plan. auto-adding these to the IRR which is then globally >> available and not-fixable by the actual origin is also 'bad'. >> >> we can do better, rpki provides a path to making that better. rpki is >> not all of the sidr work though. > > actually, at the request of a rather large provider, the rpki data are > faked into a pseudo-irr instance which those who base filters on irr > (for example, the verio/ntt) can use. =A0e.g. > > =A0 =A0rair.local:/Users/randy> whois -h whois.rpki.net 198.180.152.0/24 > =A0 =A0route: =A0 =A0 =A0198.180.152.0/24 > =A0 =A0descr: =A0 =A0 =A0198.180.152.0/24-24 > =A0 =A0origin: =A0 =A0 AS4128 oh lookie, someone did the join for me :) From randy@psg.com Sat Feb 12 09:26:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E373A6AD2 for ; Sat, 12 Feb 2011 09:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACN9Ym5m4+-i for ; Sat, 12 Feb 2011 09:26:44 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id F3DC63A6AD4 for ; Sat, 12 Feb 2011 09:26:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=client65-171.sdsc.edu.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PoJFM-000CNY-G1; Sat, 12 Feb 2011 17:27:00 +0000 Date: Sat, 12 Feb 2011 09:27:00 -0800 Message-ID: From: Randy Bush To: Yann Berthier In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 17:26:45 -0000 >> rair.local:/Users/randy> whois -h whois.rpki.net 198.180.152.0/24 > Are you mirroring the rirs and others' rpkis ? it is from a rcynic rpki cache, i.e. the transitive cone under the best trust anchors we can glean today > I suppose the code to slurp them and shoehorn the result into a local > irrd is avail, so we could deploy that alongside our internal irrd ? you are looking at an irrd instance, so yes, of course randy From randy@psg.com Sat Feb 12 09:44:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73033A69F9 for ; Sat, 12 Feb 2011 09:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9vySmiIP17w for ; Sat, 12 Feb 2011 09:44:04 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BCCBD3A69A7 for ; Sat, 12 Feb 2011 09:44:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=client65-171.sdsc.edu.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PoJW9-000CQM-Ak; Sat, 12 Feb 2011 17:44:21 +0000 Date: Sat, 12 Feb 2011 09:44:21 -0800 Message-ID: From: Randy Bush To: Yann Berthier In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 17:44:05 -0000 >>> rair.local:/Users/randy> whois -h whois.rpki.net 198.180.152.0/24 >> Are you mirroring the rirs and others' rpkis ? > it is from a rcynic rpki cache, i.e. the transitive cone under the best > trust anchors we can glean today >> I suppose the code to slurp them and shoehorn the result into a local >> irrd is avail, so we could deploy that alongside our internal irrd ? > you are looking at an irrd instance, so yes, of course btw, way back when, kurtis and i asked ripe and apnic for this. we got told to submit policy proposals. we did. they sat for a year+. one day i asked rob austein for it. we had it late the same day. within a month, ripe had invented it. it seems that the way to get rirs to do things is to give them something to [re-]invent and plant their flag on it. whatever. randy From yb@oob.anycats.net Sat Feb 12 17:24:32 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00C93A6A6F for ; Sat, 12 Feb 2011 17:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ESrbo49cuv5 for ; Sat, 12 Feb 2011 17:24:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A547B3A6A51 for ; Sat, 12 Feb 2011 17:24:27 -0800 (PST) Received: from modemcable088.194-200-24.mc.videotron.ca ([24.200.194.88] helo=[10.0.1.2]) by psg.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PoQhh-000LAv-RJ; Sun, 13 Feb 2011 01:24:45 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Yann Berthier In-Reply-To: Date: Sat, 12 Feb 2011 20:24:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 01:24:32 -0000 On 2011-02-12, at 12:27 PM, Randy Bush wrote: >=20 >> I suppose the code to slurp them and shoehorn the result into a local >> irrd is avail, so we could deploy that alongside our internal irrd ? >=20 > you are looking at an irrd instance, so yes, of course just in time for valentine's day is there any doco to get started, or is this a matter of running = something like rcynic + = http://subvert-rpki.hactrn.net/scripts/roa-to-irr.py ?= From randy@psg.com Sat Feb 12 17:33:51 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563623A6A51 for ; Sat, 12 Feb 2011 17:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf6GzPHtukXn for ; Sat, 12 Feb 2011 17:33:49 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A18843A6839 for ; Sat, 12 Feb 2011 17:33:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=client65-171.sdsc.edu.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PoQqk-000Dk3-Ur; Sun, 13 Feb 2011 01:34:07 +0000 Date: Sat, 12 Feb 2011 17:34:06 -0800 Message-ID: From: Randy Bush To: Yann Berthier In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 01:33:51 -0000 > is there any doco to get started, or is this a matter of running > something like rcynic + > http://subvert-rpki.hactrn.net/scripts/roa-to-irr.py ? you've got the recipe for building your own from open source randy From russ@cisco.com Sun Feb 13 04:21:09 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34EC3A6B7C for ; Sun, 13 Feb 2011 04:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h56qTafTQDfd for ; Sun, 13 Feb 2011 04:21:09 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 178663A6B7B for ; Sun, 13 Feb 2011 04:21:09 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAANbV02rR7Ht/2dsb2JhbACmAXOeQJoxhV4EhQSGe4My X-IronPort-AV: E=Sophos;i="4.60,464,1291593600"; d="asc'?scan'208";a="262751098" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2011 12:21:28 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1DCLRDn019219; Sun, 13 Feb 2011 12:21:28 GMT Message-ID: <4D57CCD6.3020606@cisco.com> Date: Sun, 13 Feb 2011 07:21:42 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D556BA7.6040501@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68CF85D8EE2CDBC49728489B" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 12:21:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68CF85D8EE2CDBC49728489B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > there have been some provider side folks involved actually... which is > one of the reasons for some of the requirements and assumptions. I had always thought the idea of the IETF process was to bring the assumptions out to the light of day, not to build them into the drafts (?)... IE, put the assumptions on the table. There are some actual requirements coming out of this thread --why not record them in the document, so they can be discussed in the open, rather than "assuming" th= em? :-) Russ --------------enig68CF85D8EE2CDBC49728489B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1XzNoACgkQER27sUhU9OR2gACggADS5UnH+iGqZbcW4Gct5ANS HPQAoIEPIAQxyCmog2Yqs46Kd6fzT6oI =5BMX -----END PGP SIGNATURE----- --------------enig68CF85D8EE2CDBC49728489B-- From russ@cisco.com Sun Feb 13 04:33:14 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6DC3A6B7A for ; Sun, 13 Feb 2011 04:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE0FEO5zNh3S for ; Sun, 13 Feb 2011 04:33:11 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6A26D3A6B79 for ; Sun, 13 Feb 2011 04:33:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIdeV01AZnwN/2dsb2JhbACmAXOeNZoyhV4EhQSGe4My X-IronPort-AV: E=Sophos;i="4.60,464,1291593600"; d="asc'?scan'208";a="215071862" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2011 12:33:31 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1DCXU9u028155; Sun, 13 Feb 2011 12:33:30 GMT Message-ID: <4D57CFA7.9060301@cisco.com> Date: Sun, 13 Feb 2011 07:33:43 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jared Mauch References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <879C5C16-4EA6-4CF6-BD2F-6F223A35ECB2@puck.nether.net> In-Reply-To: <879C5C16-4EA6-4CF6-BD2F-6F223A35ECB2@puck.nether.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF98DBB9C26B47B0631F7C42E" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 12:33:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF98DBB9C26B47B0631F7C42E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Because it's the easiest place to do it. i once had someone tell me th= at something should be carried in BGP because it was "easier" than duplic= ating all the code for a new network protocol to do the data copying/repl= ication. As a non-professional implementer, I considered their opinion v= aluable. I don't agree... It might be easy enough to use the same transport, but to carry in the same session --eventually you get to the point where you have everything being carried across one protocol. Is it working well to carry real time and streaming voice, real time and streaming video, ftp type data files, text, and a ton of other stuff in HTTP? How do you build QoS around this? Deep packet inspection? TRILL used IS-IS, but put it in a different process. There's a lot to be said for reusing code and ideas, and a lot to be said for splitting up failure domains, databases, and transport instances. > I think there's a few things here that are certainly valid concerns. I= 'd like to refresh them into the following based on my observations: >=20 > 1) The transport core of the network where all these control-plane mess= ages currently happen is growing and requires dense-high bandwidth router= s > 2) when you upgrade the router/fabric/whatnot you typically need some n= ew routing-engine, rsp, cpu, etc. that is typically "faster". Maybe not = fast enough for some, but they tend to be "faster". > 3) As a percentage cost of an overall upgrade (take t640 -> t1600) the = RE component is not the most expensive part by far > 4) Cisco/Juniper have some products that are certainly long in the toot= h and honestly are too underpowered for even their own aggressive cpu con= sumption/growth. It's so bad in cases they don't realize the performance= is poor on the older hardware as the labs typically have (on average) ne= wer hardware than in the core provider networks. "Underpowered" is a matter of opinion. A netbook is "underpowered" for some things, and perfectly powered for others. So is an iPad, and I don't see lot of people carrying around 6TB is drive space and 8GB of main memory with a quad core processor in their pockets --and yet people don't seem to complain about underpowered smart phones. If you're going to change a router into a fast compute platform with a lot of disk and processing requirements, it's going to take a while to make the proper adjustments. > I don't necessarily trust anyone in this arena. There's a lot of poten= tial for harm. I don't want my routers to require on some external devic= e. You may be willing to live with that, but I can not. I can not allow= my network to be constrained by some COTS PC where the vendors are unwil= ling to support it, or decide that it's cheaper to just refund the entire= cost than fix/replace it (As is happening with HP/Dell on some devices n= ow - google 'sandy bridge' and/or 'cougar point'). While an ECO is somet= hing painful for anyone, I would rather it be on something where the vend= or is going to stand behind it, vs people who can't trust you to plug in = anything (optics, another vendors bgp speaking device, etc) and have thei= r devices operate properly. But you're making the assumption that whatever security device exists must be "plugged in" to the router physically. This is a bad assumption, IMHO. There is a market for firewall code in routers. There is a market for firewalls that are independent of routers. Again, this is part of the problem with the document --assumptions like this are buried under the covers. Bring them into the light of day, so we can discuss them. > I like the fact that Randy has talked about if you do the validation, h= ow much incremental cpu time it takes vs processing a prefix-list/as-path= s, etc. True comparision/data. I'm sure he can provide you links showin= g that the "puny" cpus can keep up, and you don't need a 52-way cpu syste= m to process the bgp messages. But Randy has already said that those parts of the draft have nothing to do with performance, but security only... > (i am also frustrated that too few of my colleagues/peers have time to = participate in this stuff, and also that it takes so much time away from = my family.. then again, i'm sure i'm some sort of a tech addict as well).= OTOH, this is going to have a major impact on your operations in the next few years. You need to think carefully about: 1. What is it you're trying to accomplish --what problem are you trying to solve? 2. Where do you want this complexity? 3. Do you want to assume BGP is where it should be for the next 20 years, or do you think we need to put security within a plan for pushing BGP along to something newer and better? One of my underlying assumptions is there won't ever be a "flag day," for BGP, so whatever we do for security now, we must either work around to push BGP forward, or we must live with permanently. :-) Russ --------------enigF98DBB9C26B47B0631F7C42E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Xz60ACgkQER27sUhU9OQQpgCgqzZDDuI5YQGeIX4q/azyE4d2 aS0AnjZuQQVSC4jQF0M+LZgbLZkJoGo1 =GMQ7 -----END PGP SIGNATURE----- --------------enigF98DBB9C26B47B0631F7C42E-- From russ@cisco.com Sun Feb 13 04:48:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DAC13A69B9 for ; Sun, 13 Feb 2011 04:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d75WLlGzMRV for ; Sun, 13 Feb 2011 04:48:40 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4EF023A6962 for ; Sun, 13 Feb 2011 04:48:40 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAApiV01AZnwM/2dsb2JhbACmAXOeKZoxhV4EhQSGe4My X-IronPort-AV: E=Sophos;i="4.60,464,1291593600"; d="asc'?scan'208";a="215073888" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2011 12:49:00 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1DCn075016688; Sun, 13 Feb 2011 12:49:00 GMT Message-ID: <4D57D34B.1000303@cisco.com> Date: Sun, 13 Feb 2011 07:49:15 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29F032D90EA04A55899F390D" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 12:48:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig29F032D90EA04A55899F390D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I think, that today you receive a route in BGP, you believe it's > proper and pass it on. you have no real way to tell if the route was Isn't this what NO_EXPORT is for? Is the entire point of this exercise to encrypt one community? > originated by the ASN in the first (last? right-most) AS hop, you have > no real assurance that the prefix-list you used to fllter the route is > actually correct, and you have no understanding of the path seen in > the as-path aside from what the text says. (see pilosov/kopella) What sort of policy do you want to infer from the as path beyond the first hop? This is what needs to be in the requirements draft. Come'on, you're a provider! Don't think about what you want the protocol to look like, think about what you want the protocol to accomplish! You stated one thing above, but that really needs some clarity around it --what policies do you think you can infer from the AS Path? For instance, given this: A---------B | | +---C-----+ Is the point for B to be able to control whether or not A accepts routes from C? In other words, is the point to control A's policy towards C, or to inform A of your policy towards C? Can you actually inform A of your policy towards C without telling A what your policy towards C is? :-) Russ --------------enig29F032D90EA04A55899F390D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1X004ACgkQER27sUhU9OSKaACgrHCAkwiObpqe2JfVnyhB0kcF BZYAn0T30X12cS/AI80chONKQsxFY7ag =cmba -----END PGP SIGNATURE----- --------------enig29F032D90EA04A55899F390D-- From christopher.morrow@gmail.com Sun Feb 13 10:01:12 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C613A6A1C for ; Sun, 13 Feb 2011 10:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.072 X-Spam-Level: X-Spam-Status: No, score=-103.072 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWgXBTPxBS58 for ; Sun, 13 Feb 2011 10:01:10 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DD3F63A6A15 for ; Sun, 13 Feb 2011 10:01:08 -0800 (PST) Received: by wwa36 with SMTP id 36so4124154wwa.13 for ; Sun, 13 Feb 2011 10:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QjN0rx6azU0WskJp05ZGiiroknCYMwezRbIi5h81F1A=; b=Dk/7q+sRktqRiLApfEZMkOscWLc63pnpsgAHpBceI5RJuD8xBWjRJPNx/tZ9gAB7CX 3QxQpxCrSJzMoLOJOgfnk7fuEXuZhDewvjIodqz4tnouvMfTKnGcpijFnGpy1rQkBNdj /9LXVAdZ+FBOZ9kgZl+nkjtskWElpxKF8dVYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=uMdARaLMOzziw61lbHAj8A7vhpVAf/bMniNYarHzLD38vQspUC2UvyjQzY59yl5uDJ ywyY/h4y9QQCMecitfm4ONgcjfHAPe4V6dBmlOyaVr6pwqMObVYkAk6EAIg/1MPFyXuj AWBfYvuZ0MqYWkdPCq15Vt0GH4DZMKWbWBRHw= MIME-Version: 1.0 Received: by 10.216.39.196 with SMTP id d46mr2345611web.114.1297620087902; Sun, 13 Feb 2011 10:01:27 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Sun, 13 Feb 2011 10:01:27 -0800 (PST) In-Reply-To: <4D57D34B.1000303@cisco.com> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> Date: Sun, 13 Feb 2011 13:01:27 -0500 X-Google-Sender-Auth: -wBN-iO_hPIeB_H3xpUzN8ZeTgY Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 18:01:12 -0000 On Sun, Feb 13, 2011 at 7:49 AM, Russ White wrote: > >> I think, that today you receive a route in BGP, you believe it's >> proper and pass it on. you have no real way to tell if the route was > > Isn't this what NO_EXPORT is for? Is the entire point of this exercise > to encrypt one community? huh? no, the first (right-most) asn in the path, is that who actually originated the route? Are they permitted to originate that route by the netblock 'owner'? these are the questions, I think, origin validation should solve. > >> originated by the ASN in the first (last? right-most) AS hop, you have >> no real assurance that the prefix-list you used to fllter the route is >> actually correct, and you have no understanding of the path seen in >> the as-path aside from what the text says. (see pilosov/kopella) > > What sort of policy do you want to infer from the as path beyond the > first hop? This is what needs to be in the requirements draft. I thought it was ... req 3.12 covers what you'd want to do with the as-path security information. (or really says you can influence the addition to the RIB of a route based on it's security information/state) > Come'on, you're a provider! Don't think about what you want the protocol > to look like, think about what you want the protocol to accomplish! You sure, 'tell me if the path I see is a lie' (in rough terms)... in more complex terms: "verify, with a high degree of certainty, that each hop on the supposed path actually saw this copy of this route. Verify, with a high degree of certainty, that the origin of this route is authorized to make this announcement." Ideally, with that information I should be able to better inform my route selection process. > stated one thing above, but that really needs some clarity around it > --what policies do you think you can infer from the AS Path? if something like: happens, do not accept the affected routes. Sure, if the provider(s) to the customer doing this all did prefix and as-path filtering we wouldn't require much else... except that almost no 'Tier-1' to 'tier-1' isp peerings are filtered in a meaningful way. > For instance, given this: > > A---------B > | =A0 =A0 =A0 =A0 | > +---C-----+ > > Is the point for B to be able to control whether or not A accepts routes > from C? In other words, is the point to control A's policy towards C, or nope. > to inform A of your policy towards C? Can you actually inform A of your > policy towards C without telling A what your policy towards C is? > nope. The point is to see if along the path a-b-c if the routes C originates C is supposed to be able to originate (rpki helps here), and if B has changed the basica data about the prefixes C sent it, and to make sure that we don't suddenly start accepting routes with paths like: a-b-d-c a-b-d-e-f-c since d, e, f can't sign the paths... unless of course they suddenly do appear in the path and are properly signing things. I don't think it's helpful to tell people what your policy is, nor to control external entities by hoping to infer their policy. I do think there is some sense in knowing that the route I see is originated by an authorized party and that no unauthorized parties are showing up in the paths I see. I may chose to do nothing with the information as I receive it, or I may chose to prefer 'valid' routes over 'invalid' (or even 'unknown') routes... that's purely a local operator decision. -Chris From christopher.morrow@gmail.com Sun Feb 13 10:02:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7F63A6A00 for ; Sun, 13 Feb 2011 10:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.322 X-Spam-Level: X-Spam-Status: No, score=-103.322 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvINq2zoPeZj for ; Sun, 13 Feb 2011 10:02:46 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B2BCF3A67BD for ; Sun, 13 Feb 2011 10:02:45 -0800 (PST) Received: by wwa36 with SMTP id 36so4125013wwa.13 for ; Sun, 13 Feb 2011 10:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BMSWHR/nlnJmV1BDXG9G+ZCILdUfLv43yo+bRVWFhYI=; b=fzVXyF84vZiBb37UzrTNvV3KRoZrtJpwA0QX1/ko0Q8jL2VE5yOOYPRxq6CO3a7mCK 4qClJSBwQA/JyFnCQqwKtRaxKz8GQsgClIeX1QV5lby97q3RHosjz+iFIq4LloHsghr4 Xstbm9qHE1PpWRQPirSs4hiq5AC+VotB2Tbh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=qJkCGtdcx6A5Za9v59e6z/C7ISZ24oQNAiqC+5D4Mgm14siQafFDK5h2MfUOlNSRWo TnhS34+dzUA+PzT0otSFtuoXFeKGBpgbch4jPRU8kc1HG5rDz503FA3rZZ/nWyfPF4B1 aFCgYC2H+ojgGvmxcSiQDS9PFH3vxJP2rR/SM= MIME-Version: 1.0 Received: by 10.216.39.196 with SMTP id d46mr2346493web.114.1297620185891; Sun, 13 Feb 2011 10:03:05 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Sun, 13 Feb 2011 10:03:05 -0800 (PST) In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> Date: Sun, 13 Feb 2011 13:03:05 -0500 X-Google-Sender-Auth: d9QKf8CpT0Ev83kXQhyDfU9za04 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 18:02:46 -0000 On Sun, Feb 13, 2011 at 1:01 PM, Christopher Morrow wrote: referencing all of the messages I've sent on this topic (bgpsec-reqs-00 draft discussions) ... all said purely as a reader of the draft and participant in the sidr wg... thnx! From russ@cisco.com Sun Feb 13 11:13:09 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859C93A6AC4 for ; Sun, 13 Feb 2011 11:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kWZv9y5mHM7 for ; Sun, 13 Feb 2011 11:13:08 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1DC073A69A7 for ; Sun, 13 Feb 2011 11:13:08 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAu8V01AZnwM/2dsb2JhbACmAHOeRZoihV4EhQSGe4My X-IronPort-AV: E=Sophos;i="4.60,465,1291593600"; d="asc'?scan'208";a="214877722" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Feb 2011 19:13:28 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1DJDS4A009582; Sun, 13 Feb 2011 19:13:28 GMT Message-ID: <4D582D67.5090003@cisco.com> Date: Sun, 13 Feb 2011 14:13:43 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig19C348A287EFA13B0EA1F736" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 19:13:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig19C348A287EFA13B0EA1F736 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> I think, that today you receive a route in BGP, you believe it's >>> proper and pass it on. you have no real way to tell if the route was >> >> Isn't this what NO_EXPORT is for? Is the entire point of this exercise= >> to encrypt one community? >=20 > huh? no, the first (right-most) asn in the path, is that who actually > originated the route? Are they permitted to originate that route by > the netblock 'owner'? >=20 > these are the questions, I think, origin validation should solve. Okay, first, this document isn't about origin validation, it's about path validation. So, when you say, "you believe it's proper and you pass it on," in the context of this document, specifically, you can't be talking about the origin, but only the _other_ AS numbers listed in the AS Path. > I thought it was ... req 3.12 covers what you'd want to do with the > as-path security information. (or really says you can influence the > addition to the RIB of a route based on it's security > information/state) No, it just says you can use this information to influence what you put in your local RIB. That doesn't tell me what question you're trying to answer. It only says, "my requirement is that the path be signed, and that I can decide what I want to with that signature." It's like your customer comes to you and says, "I want you to build me a 10,000 node L2VPN." You could just say, "sure, it'll cost you x." But if you're intelligent, you'll have a design person on staff who works will sales who understands, from the outset, that this is a disaster going someplace to happen --so you ask, "what is the problem you're trying to solve?" If the customer comes back with, "I'm trying to build a 10,000 switch layer 2 network," have they answered your question? > sure, 'tell me if the path I see is a lie' (in rough terms)... in more > complex terms: "verify, with a high degree of certainty, that each hop > on the supposed path actually saw this copy of this route.=20 Why do you care if they're lying? Explain what the problem is if they are. Don't say, "I don't want you to lie to me." Say, "when someone lies to me, this is what happens, and I need to be able to prevent that from happening." > if something like: > >=20 > happens, do not accept the affected routes. Sure, if the provider(s) > to the customer doing this all did prefix and as-path filtering we > wouldn't require much else... except that almost no 'Tier-1' to > 'tier-1' isp peerings are filtered in a meaningful way. Then you want to know what the policy is in this diagram: >> A---------B >> | | >> +---C-----+ Even though you say you don't. Whether a peering relationship is tier 1 to 2, or the other way around, _is_ a policy --because the specific question here is --should C be transiting traffic to A? In other words, you're contradicting yourself --you're saying, "I don't want to infer or enforce policy," but then you go on to say, "this specific violation of policy is what I'm trying to prevent from happening= =2E" > The point is to see if along the path a-b-c if the routes C originates > C is supposed to be able to originate (rpki helps here), and if B has > changed the basica data about the prefixes C sent it, and to make sure > that we don't suddenly start accepting routes with paths like: >=20 > a-b-d-c > a-b-d-e-f-c In other words, you want to be certain that it's within C's policy to advertise the route to D, and it's not within C's policy to advertise the route to F. > I don't think it's helpful to tell people what your policy is, nor to > control external entities by hoping to infer their policy. I do think > there is some sense in knowing that the route I see is originated by > an authorized party and that no unauthorized parties are showing up in > the paths I see. But that's precisely what you're trying to do... :-) Russ --------------enig19C348A287EFA13B0EA1F736 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1YLWoACgkQER27sUhU9ORXxACfc6pdWbyDkuIMYwungDWPOmN+ GTgAoJBcspyjP938E+LyuDKT7ysJiMkx =7yPa -----END PGP SIGNATURE----- --------------enig19C348A287EFA13B0EA1F736-- From russ@cisco.com Sun Feb 13 11:19:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB9A03A6AC4 for ; Sun, 13 Feb 2011 11:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnS37a3htyvW for ; Sun, 13 Feb 2011 11:19:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E41333A6AB8 for ; Sun, 13 Feb 2011 11:19:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHO9V01AZnwM/2dsb2JhbACmAXOeRpoihV4EhQSGe4My X-IronPort-AV: E=Sophos;i="4.60,465,1291593600"; d="asc'?scan'208";a="215118163" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2011 19:19:39 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1DJJdbt012402; Sun, 13 Feb 2011 19:19:39 GMT Message-ID: <4D582EDD.1000405@cisco.com> Date: Sun, 13 Feb 2011 14:19:57 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> <4D582D67.5090003@cisco.com> In-Reply-To: <4D582D67.5090003@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig941A298A6D9EAFFC48BB8A18" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 19:19:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig941A298A6D9EAFFC48BB8A18 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> A---------B >>> | | >>> +---C-----+ >=20 > Even though you say you don't. Whether a peering relationship is tier 1= > to 2, or the other way around, _is_ a policy --because the specific > question here is --should C be transiting traffic to A? Bah --between A and B. :-) Russ --------------enig941A298A6D9EAFFC48BB8A18 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1YLt0ACgkQER27sUhU9OTkYwCeNqLLoQGbqFQuA2VXXT4J9WQS eMUAnAtxJNn1QCNeMJtfOHY+Wh+0YGRz =74nO -----END PGP SIGNATURE----- --------------enig941A298A6D9EAFFC48BB8A18-- From christopher.morrow@gmail.com Sun Feb 13 17:55:15 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774AE3A6AEF for ; Sun, 13 Feb 2011 17:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.329 X-Spam-Level: X-Spam-Status: No, score=-103.329 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a8aIeQTIVlq for ; Sun, 13 Feb 2011 17:55:13 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D96AA3A6C47 for ; Sun, 13 Feb 2011 17:55:12 -0800 (PST) Received: by wyf23 with SMTP id 23so4549086wyf.31 for ; Sun, 13 Feb 2011 17:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=66zUQPo6jn7yXZJvE+MF0SOxMguvLrMr+43GsJJ49wA=; b=Yk7GXOvL8aY3h2C24jTyn8ebO2fMBaUZAjMtcWifnbK2dVQhwIxIb66vRuHZjQYFSO AwDjFw2XiyvBva54wZd5yXbgBk6IzpBEVBghh1lAge/hHtwmes+JLdSs5CrlyLQo1tyt sr52dxevZqh3PLr+YcbKIiZmliz4iTtQUd9kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fYa40EMx1kpGl0sToUzgP+9KfXsCddkBl5k0mbZGNPwGsqm5MGXvfiZTkCtA0yKpD7 8iv+qJWZzW7j1i6oMx+0biJ7lZXs78njMMUDb6KVN9tgneZGoPt/96kF9qd+pdd7osOa 1jEdO3uWxhTrkLT8idE2xW1lwebm4220K+84c= MIME-Version: 1.0 Received: by 10.216.39.196 with SMTP id d46mr2575877web.114.1297648531741; Sun, 13 Feb 2011 17:55:31 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Sun, 13 Feb 2011 17:55:30 -0800 (PST) In-Reply-To: <4D582D67.5090003@cisco.com> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> <4D582D67.5090003@cisco.com> Date: Sun, 13 Feb 2011 20:55:30 -0500 X-Google-Sender-Auth: 8AINLZgFegl0fVIko0cEBmH-pd8 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 01:55:15 -0000 On Sun, Feb 13, 2011 at 2:13 PM, Russ White wrote: > >>>> I think, that today you receive a route in BGP, you believe it's >>>> proper and pass it on. you have no real way to tell if the route was >>> >>> Isn't this what NO_EXPORT is for? Is the entire point of this exercise >>> to encrypt one community? >> >> huh? no, the first (right-most) asn in the path, is that who actually >> originated the route? Are they permitted to originate that route by >> the netblock 'owner'? >> >> these are the questions, I think, origin validation should solve. > > Okay, first, this document isn't about origin validation, it's about yes, coffee failure. > path validation. So, when you say, "you believe it's proper and you pass > it on," in the context of this document, specifically, you can't be > talking about the origin, but only the _other_ AS numbers listed in the > AS Path. sure, they signed it, the previous as's signed their copy as it passed through. if there's an unsigned as in the path, or a miss-signed one... the path fails validity checks and I can decide something from that. >> I thought it was ... req 3.12 covers what you'd want to do with the >> as-path security information. (or really says you can influence the >> addition to the RIB of a route based on it's security >> information/state) > > No, it just says you can use this information to influence what you put > in your local RIB. That doesn't tell me what question you're trying to > answer. It only says, "my requirement is that the path be signed, and > that I can decide what I want to with that signature." yes. >> sure, 'tell me if the path I see is a lie' (in rough terms)... in more >> complex terms: "verify, with a high degree of certainty, that each hop >> on the supposed path actually saw this copy of this route. > > Why do you care if they're lying? Explain what the problem is if they > are. Don't say, "I don't want you to lie to me." Say, "when someone lies > to me, this is what happens, and I need to be able to prevent that from > happening." that's said below. 'do not accept the affected routes' You want: "Because sending traffic off on a false path causes pain/suffering/unhappy-packets" added to the reqs doc? >> if something like: >> >> >> happens, do not accept the affected routes. Sure, if the provider(s) >> to the customer doing this all did prefix and as-path filtering we >> wouldn't require much else... except that almost no 'Tier-1' to >> 'tier-1' isp peerings are filtered in a meaningful way. > > Then you want to know what the policy is in this diagram: perhaps 'policy' is overloaded here... I don't care what the bgp policy is inside someone else's network. they can choose to accept/deny/up|down-pref announcements to their hearts content. I do care that, as I said below/before, someone can't invent paths in the routing table. >>> A---------B >>> | =A0 =A0 =A0 =A0 | >>> +---C-----+ > > Even though you say you don't. Whether a peering relationship is tier 1 > to 2, or the other way around, _is_ a policy --because the specific I knew using the moniker 'tier-1' was going to bite me... "large settlement-free peers". > question here is --should C be transiting traffic to A? actually even in the case of your 3 ASN picture, I don't think we can meaningfully limit route leaks with JUST protocol fixes. We could, however, use the rpki infrastructure to put in proper prefix-filters on the peers in question. > In other words, you're contradicting yourself --you're saying, "I don't > want to infer or enforce policy," but then you go on to say, "this > specific violation of policy is what I'm trying to prevent from happening= ." > >> The point is to see if along the path a-b-c if the routes C originates >> C is supposed to be able to originate (rpki helps here), and if B has >> changed the basic data about the prefixes C sent it, and to make sure >> that we don't suddenly start accepting routes with paths like: >> >> a-b-d-c >> a-b-d-e-f-c > > In other words, you want to be certain that it's within C's policy to > advertise the route to D, and it's not within C's policy to advertise > the route to F. nope. I want to (for the 2 example paths above, applied to the diagram you created) be certain that in case 1: B is not injecting routes with origin-C and as-path that includes fictional-ASN-D case 2: B is not injecting a path with origin-C and as-path that includes the fictional ASNs D, E, F I didn't speculate on the policy of B nor C here, just that the path I see isn't signed by asn's D E nor F, so they shouldn't be used in this network. >> I don't think it's helpful to tell people what your policy is, nor to >> control external entities by hoping to infer their policy. I do think >> there is some sense in knowing that the route I see is originated by >> an authorized party and that no unauthorized parties are showing up in >> the paths I see. > > But that's precisely what you're trying to do... nope. -chris From shane@castlepoint.net Mon Feb 14 09:06:59 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBAB3A69EB for ; Mon, 14 Feb 2011 09:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXNUwSZ-kPOB for ; Mon, 14 Feb 2011 09:06:58 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 271E53A699E for ; Mon, 14 Feb 2011 09:06:58 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 564082684EA; Mon, 14 Feb 2011 10:07:21 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Feb 2011 10:07:21 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=62915; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 14 Feb 2011 10:07:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B4B5E47-B894-4BBC-A8FA-5CCAA9BAACC5@castlepoint.net> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: Russ White , sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:06:59 -0000 Chris, Rather than waste a lot of time doing a point-by-point response, let's = boil this down to the most simple question. Once we get a common = understanding on that, we can (hopefully) discuss other points. First, I understand how the current RPKI is intended to be deployed and = operationalized. I also acknowledge the present "capabilities" in the = RPKI that we knew about the time RPSEC wound down and SIDR was formed, = namely that the RPKI only contains ROA's, and associated certificate = material, that is intended to allow 3rd-parties to authenticate a given = ASN is "allowed" to originate a given prefix (or, set of prefixes, i.e.: = /16 upto /24). However, and here's the key part, in my understanding = all RPKI material (namely, ROA's and associated certificate material) is = carried around "out-of-band" amongst a hierarchy of 'commodity' servers = from IANA -> RIR's -> LIR's/ISP's. At present, there's two things SP's = may do to get that material from those servers into their routers, = (doing the actual forwarding): 1) "Pull Model": Routers can use draft-ietf-sidr-rpki-rtr-07 to pull = RPKI info from the RPKI servers and absorb it into their configuration; = or, 2) "Push Model": Operators can (re-)use their existing tool-chains, if = they so desire, to push information from the RPKI servers into their = routers using existing BGP policy-statements/route-maps applied to eBGP = sessions that have existed for several years. Either of those models will work. However, and again here's the key = point, either of the above are *not* forcing any RPKI information, (in = particular ROA's, certs, CRL's, etc.), in BGP transport sessions. IOW, = BGP continues to blindly (and, quickly) pass around forwarding = information and it's up to [very simple] policy on each router to decide = whether to accept or reject that forwarding information as "legitimate". = OTOH, if my understanding of this draft is correct, we're talking about = moving away from that and carrying not just forwarding information, but = also certs and possibly other RPKI material, etc.? Why? Or, more = importantly, why is that a MUST? Why can't additional RPKI material, = (e.g.: beyond ROA's), continue to be pulled or pushed into routers as I = outlined above, (in particular Model #2)? On Feb 11, 2011, at 13:37 MST, Christopher Morrow wrote: > On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante = wrote: >> Randy, >>=20 >> On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >>>> 3.3 As cryptographic payloads and loading on routers are likely to >>>> seriously increase, a BGPsec design may require use of new = hardware. >>>> It must be possible to build routers that do BGPsec with within >>>> acceptable (to operators) bounds of cost and performance. >>>>=20 >>>> This should be left out of any requirements document, and various >>>> proposed system compared based on their costs and deployment >>>> difficulty. >>>=20 >>> i take your point. the intent was that compatibility with current >>> hardware abilities is not a requirement that this document imposes = on a >>> solution. it is quite likely that provider routers will need crypto >>> assist and more ram. though one hope that the stub customer edge = will >>> not. >>=20 >> Whoa there. I couldn't disagree more wrt the above. >>=20 >> First, let's start with the most fundamental question. Why is it = that routers MUST sign, pass >> around and verify _in-band_ in the control plane various = contents/PDU's _within_ BGP? Note my >> very careful use of the work _in-band_. By that I mean inside the = BGP session itself, not on a -shane= From christopher.morrow@gmail.com Mon Feb 14 09:22:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19E13A6A16 for ; Mon, 14 Feb 2011 09:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.335 X-Spam-Level: X-Spam-Status: No, score=-103.335 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph9zzIoy84Zz for ; Mon, 14 Feb 2011 09:22:13 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 304B73A6D74 for ; Mon, 14 Feb 2011 09:22:11 -0800 (PST) Received: by wyf23 with SMTP id 23so5289065wyf.31 for ; Mon, 14 Feb 2011 09:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pQ23L7/lJYkYyspXXS0rtAQSCrBCErkx5uOYDd17usw=; b=YwRWeBLs+3WcLYED0+3n5UE/sr6mnNXicKF3B+OoPItQdWjXtOCHrr2KZ7IcI+NU1N /y6hZr3wCcw0jap04NZKT64UbS8c55WEw7qesiNnDyHs+zJqOyKXP7hpXQi5EIQlTnvD 44kNGoIBIRAYtaDthsuBlVTo8RkexhMhxDnvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=a1NkPOTjgNFigvPNxcF2ucDH0fQtGoZJ2cKLAkkWtufVjz/yr5P4jIaFrcZbUVR25C 30rjevK/Ca7/PnyEofkMs6IM7Qw43jVTWfCs7a9K1lwCne2Nw/gDBeAiR4xPhHkh0B4s hb8jbZPOf+PPfqWmghQK7HvGPJbooyhXp/8Xo= MIME-Version: 1.0 Received: by 10.216.179.133 with SMTP id h5mr877399wem.69.1297704153989; Mon, 14 Feb 2011 09:22:33 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Mon, 14 Feb 2011 09:22:33 -0800 (PST) In-Reply-To: <6B4B5E47-B894-4BBC-A8FA-5CCAA9BAACC5@castlepoint.net> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <6B4B5E47-B894-4BBC-A8FA-5CCAA9BAACC5@castlepoint.net> Date: Mon, 14 Feb 2011 12:22:33 -0500 X-Google-Sender-Auth: ARN0tJ3fAv30v4XIZdLh_KrMJn4 Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Russ White , sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:22:18 -0000 On Mon, Feb 14, 2011 at 12:07 PM, Shane Amante wrot= e: > Chris, > > Rather than waste a lot of time doing a point-by-point response, let's bo= il this down to the most simple question. =A0Once we get a common understan= ding on that, we can (hopefully) discuss other points. > sounds great. > First, I understand how the current RPKI is intended to be deployed and o= perationalized. =A0I also acknowledge the present "capabilities" in the RPK= I that we knew about the time RPSEC wound down and SIDR was formed, namely = that the RPKI only contains ROA's, and associated certificate material, tha= t is intended to allow 3rd-parties to authenticate a given ASN is "allowed"= to originate a given prefix (or, set of prefixes, i.e.: /16 upto /24). =A0= However, and here's the key part, in my understanding all RPKI material (na= mely, ROA's and associated certificate material) is carried around "out-of-= band" amongst a hierarchy of 'commodity' servers from IANA -> RIR's -> LIR'= s/ISP's. =A0At present, there's two things SP's may do to get that material= from those servers into their routers, (doing the actual forwarding): > 1) =A0"Pull Model": Routers can use draft-ietf-sidr-rpki-rtr-07 to pull R= PKI info from the RPKI servers and absorb it into their configuration; or, I think not 'configuration' but 'on router cache' - akin to a dns-cache... > 2) =A0"Push Model": Operators can (re-)use their existing tool-chains, if= they so desire, to push information from the RPKI servers into their route= rs using existing BGP policy-statements/route-maps applied to eBGP sessions= that have existed for several years. > yup, 'make me a prefix-list' > Either of those models will work. =A0However, and again here's the key po= int, either of the above are *not* forcing any RPKI information, (in partic= ular ROA's, certs, CRL's, etc.), in BGP transport sessions. =A0IOW, BGP con= tinues to blindly (and, quickly) pass around forwarding information and it's up to [very simple] policy on each router to decide whether to accept or reject that forwarding information as "legitimate". =A0OTOH, if my understanding of this draft is correct, we're talking about moving away from that and carrying not just forwarding information, but also certs and possibly other RPKI material, etc.? =A0Why? =A0Or, more importantly, why is that a MUST? =A0Why can't additional RPKI material, (e.g.: beyond ROA's), continue to be pulled or pushed into routers as I outlined above, (in particular Model #2)? roa's don't end up in bgp even in the case of this draft, nor do certs. 'signed updates' do. An optional-transitive attribute is one model to look at using for this, I think. I think the reasoning behind carrying a signature (well, adding a signature at each AS-hop) is so you can see that the AS in the path has actually seen this announcement. The presence of the signature data and your router checking that ends with (as the draft says) "valid" or "invalid", you can choose to do something with that in your local bgp policy, for example: route-map bloop permit 10 match validity-state valid set localpref 100 route-map bloop permit 20 match validity-state invalid set localpref 5 I don't want to see certs or roas shipped in bgp either, shipment of that data remains in the rpki 'system'. -Chris > > On Feb 11, 2011, at 13:37 MST, Christopher Morrow wrote: >> On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante w= rote: >>> Randy, >>> >>> On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >>>>> 3.3 As cryptographic payloads and loading on routers are likely to >>>>> seriously increase, a BGPsec design may require use of new hardware. >>>>> It must be possible to build routers that do BGPsec with within >>>>> acceptable (to operators) bounds of cost and performance. >>>>> >>>>> This should be left out of any requirements document, and various >>>>> proposed system compared based on their costs and deployment >>>>> difficulty. >>>> >>>> i take your point. =A0the intent was that compatibility with current >>>> hardware abilities is not a requirement that this document imposes on = a >>>> solution. =A0it is quite likely that provider routers will need crypto >>>> assist and more ram. =A0though one hope that the stub customer edge wi= ll >>>> not. >>> >>> Whoa there. =A0I couldn't disagree more wrt the above. >>> >>> First, let's start with the most fundamental question. =A0Why is it tha= t routers MUST sign, pass >>> around and verify _in-band_ in the control plane various contents/PDU's= _within_ BGP? =A0Note my >>> very careful use of the work _in-band_. =A0By that I mean inside the BG= P session itself, not on a > > -shane From shane@castlepoint.net Mon Feb 14 09:26:13 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431BD3A6A16 for ; Mon, 14 Feb 2011 09:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHENX5uyMXVz for ; Mon, 14 Feb 2011 09:26:12 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 677643A69EB for ; Mon, 14 Feb 2011 09:26:12 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id DA92F2684EA; Mon, 14 Feb 2011 10:26:35 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Feb 2011 10:26:35 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=63002; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <879C5C16-4EA6-4CF6-BD2F-6F223A35ECB2@puck.nether.net> Date: Mon, 14 Feb 2011 10:26:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0701590C-9948-44BF-B520-6466BBAEA585@castlepoint.net> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <879C5C16-4EA6-4CF6-BD2F-6F223A35ECB2@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1082) Cc: Russ White , sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:26:13 -0000 Jared, See below. On Feb 11, 2011, at 14:02 MST, Jared Mauch wrote: [--snip--] > I don't necessarily trust anyone in this arena. There's a lot of = potential for harm. I don't want my routers to require on some external = device. You may be willing to live with that, but I can not. In fact, I would say my network is the complete opposite. :-) I = already depend on external COTS servers for a variety of mission = critical functions in the network: IRR, DNS, Netflow = collection/processing, SNMP stats, syslog messages, syslog processing, = etc. (I would be shocked if other networks don't have similar = requirements for external COTS servers). > I can not allow my network to be constrained by some COTS PC where the = vendors are unwilling to support it, or decide that it's cheaper to just = refund the entire cost than fix/replace it (As is happening with HP/Dell = on some devices now - google 'sandy bridge' and/or 'cougar point'). = While an ECO is something painful for anyone, I would rather it be on = something where the vendor is going to stand behind it, vs people who = can't trust you to plug in anything (optics, another vendors bgp = speaking device, etc) and have their devices operate properly. (Sorry the following strays a bit off-topic for a technical mailing = list, but I wanted to inject the operational reality as I see it from my = vantage point). Ultimately, I understand "different strokes for different folks". My = main point is: SIDR can't (or, at the very least) should not force a = single operational or deployment model (i.e.: in-band transport in BGP = of certs, etc.) on operators. To emphasize this point further: - Different networks have different EOL replacement strategies and, more = importantly, timelines. =20 - While some networks may be limited to only sourcing network equipment = from a limited set of vendors, others are not. Requiring crypto-assist = onboard routers is likely to either take a very long time for a broader = set of vendors to implement or have them abandon the market altogether. = Both would be very bad outcomes IMHO. Thanks, -shane= From Sandra.Murphy@cobham.com Mon Feb 14 09:32:36 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB56D3A6A6D for ; Mon, 14 Feb 2011 09:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYg+wyloLYeQ for ; Mon, 14 Feb 2011 09:32:36 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C03303A69EB for ; Mon, 14 Feb 2011 09:32:35 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1EHWXt9027964; Mon, 14 Feb 2011 11:32:33 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1EHWX0l027389; Mon, 14 Feb 2011 11:32:33 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.92]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Feb 2011 12:32:33 -0500 Date: Mon, 14 Feb 2011 12:32:33 -0500 (Eastern Standard Time) From: Sandra Murphy To: Shane Amante In-Reply-To: <6B4B5E47-B894-4BBC-A8FA-5CCAA9BAACC5@castlepoint.net> Message-ID: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <6B4B5E47-B894-4BBC-A8FA-5CCAA9BAACC5@castlepoint.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Feb 2011 17:32:33.0667 (UTC) FILETIME=[29E69530:01CBCC6D] Cc: sidr@ietf.org, Russ White Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 17:32:37 -0000 On Mon, 14 Feb 2011, Shane Amante wrote: > Chris, > > Rather than waste a lot of time doing a point-by-point response, let's boil this down to the most simple question. Once we get a common understanding on that, we can (hopefully) discuss other points. > > First, I understand how the current RPKI is intended to be deployed and operationalized. I also acknowledge the present "capabilities" in the RPKI that we knew about the time RPSEC wound down and SIDR was formed, namely that the RPKI only contains ROA's, and associated certificate material, that is intended to allow 3rd-parties to authenticate a given ASN is "allowed" to originate a given prefix (or, set of prefixes, i.e.: /16 upto /24). However, and here's the key part, in my understanding all RPKI material (namely, ROA's and associated certificate material) is carried around "out-of-band" amongst a hierarchy of 'commodity' servers from IANA -> RIR's -> LIR's/ISP's. At present, there's two things SP's may do to get that material from those servers into their routers, (doing the actual forwarding): > 1) "Pull Model": Routers can use draft-ietf-sidr-rpki-rtr-07 to pull RPKI info from the RPKI servers and absorb it into their configuration; or, > 2) "Push Model": Operators can (re-)use their existing tool-chains, if they so desire, to push information from the RPKI servers into their routers using existing BGP policy-statements/route-maps applied to eBGP sessions that have existed for several years. > > Either of those models will work. However, and again here's the key point, either of the above are *not* forcing any RPKI information, (in particular ROA's, certs, CRL's, etc.), in BGP transport sessions. IOW, BGP continues to blindly (and, quickly) pass around forwarding information and it's up to [very simple] policy on each router to decide whether to accept or reject that forwarding information as "legitimate". OTOH, if my understanding of this draft is correct, we're talking about moving away from that and carrying not just forwarding information, but also certs and possibly other RPKI material, etc.? Why? Or, more importantly, why is that a MUST? Why can't additional RPKI material, (e.g.: beyond ROA's), continue to be pulled or pushed into routers as I outlined above, (in particular Model #2)? I don't believe that any requirement in this draft forces carrying certs or other RPKI data around in BGP. The current deployment out-of-band will continue to work. Please point to specific language in the requirements document that dictates changing the current sidr model. --Sandy > > On Feb 11, 2011, at 13:37 MST, Christopher Morrow wrote: >> On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante wrote: >>> Randy, >>> >>> On Jan 30, 2011, at 20:40 MST, Randy Bush wrote: >>>>> 3.3 As cryptographic payloads and loading on routers are likely to >>>>> seriously increase, a BGPsec design may require use of new hardware. >>>>> It must be possible to build routers that do BGPsec with within >>>>> acceptable (to operators) bounds of cost and performance. >>>>> >>>>> This should be left out of any requirements document, and various >>>>> proposed system compared based on their costs and deployment >>>>> difficulty. >>>> >>>> i take your point. the intent was that compatibility with current >>>> hardware abilities is not a requirement that this document imposes on a >>>> solution. it is quite likely that provider routers will need crypto >>>> assist and more ram. though one hope that the stub customer edge will >>>> not. >>> >>> Whoa there. I couldn't disagree more wrt the above. >>> >>> First, let's start with the most fundamental question. Why is it that routers MUST sign, pass >>> around and verify _in-band_ in the control plane various contents/PDU's _within_ BGP? Note my >>> very careful use of the work _in-band_. By that I mean inside the BGP session itself, not on a > > -shane > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From russ@cisco.com Mon Feb 14 14:20:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4653A6DC7 for ; Mon, 14 Feb 2011 14:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF7v-T4Diigh for ; Mon, 14 Feb 2011 14:20:17 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C15963A6997 for ; Mon, 14 Feb 2011 14:20:17 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACM5WU1AZnwM/2dsb2JhbACmC3OgQps7hV4EhQSGe4My X-IronPort-AV: E=Sophos;i="4.60,470,1291593600"; d="asc'?scan'208";a="215591914" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Feb 2011 22:20:39 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1EMKcu9024476; Mon, 14 Feb 2011 22:20:39 GMT Message-ID: <4D59AAC7.2070903@cisco.com> Date: Mon, 14 Feb 2011 17:20:55 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> <4D582D67.5090003@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig458DECD7EF4BBE82CD5CCEC8" Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 22:20:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig458DECD7EF4BBE82CD5CCEC8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > that's said below. 'do not accept the affected routes' > You want: "Because sending traffic off on a false path causes > pain/suffering/unhappy-packets" > added to the reqs doc? No, I want to know what it is you intend to accomplish, not how you intend to accomplish it. >> Then you want to know what the policy is in this diagram: >=20 > perhaps 'policy' is overloaded here... I don't care what the bgp > policy is inside someone else's network. they can choose to > accept/deny/up|down-pref announcements to their hearts content. I do > care that, as I said below/before, someone can't invent paths in the > routing table. Policy exists outside an AS, as well. When you set no_export on a route, that's a policy. When you sign a contract saying, "I will peer with you, but I will not allow you to transit my traffic," that's a policy. If you'd like to suggest a different word for contract terms that say things like, "I will peer, but not transit," then lets find the better te= rm. Let's go back to here: A---------B | | +---C-----+ > I want to (for the 2 example paths above, applied to the diagram you > created) be certain that in case 1: > B is not injecting routes with origin-C and as-path that includes > fictional-ASN-D The requirement here is that you don't want fictional AS' in the AS Path.= > case 2: > B is not injecting a path with origin-C and as-path that includes the > fictional ASNs D, E, F >=20 > I didn't speculate on the policy of B nor C here, just that the path I > see isn't signed by asn's D E nor F, so they shouldn't be used in this > network. The second point you make is that you don't care if C transits or not in this situation. If you're B, you don't care if C is supposed to transit or not, so long as C doesn't put a fake AS in the AS Path. So the only real requirement you have is that fake AS' not end up in the AS Path. Is that correct? :-) Russ --------------enig458DECD7EF4BBE82CD5CCEC8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ZqskACgkQER27sUhU9OTa8ACgqT9Xf4YcnTBjexZp4FD7EHjB axMAnAxmvnTP5Ha4ttxmxFO+7mRf/+sD =5vS9 -----END PGP SIGNATURE----- --------------enig458DECD7EF4BBE82CD5CCEC8-- From dy243@hermes.cam.ac.uk Mon Feb 14 17:25:07 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77AF33A6D9B for ; Mon, 14 Feb 2011 17:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NquKQ71kVl5k for ; Mon, 14 Feb 2011 17:25:06 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id C8B403A6A0C for ; Mon, 14 Feb 2011 17:25:05 -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-yi0-f44.google.com ([209.85.218.44]:54024) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:dy243) (TLSv1:RC4-SHA:128) id 1Pp9fU-00031r-pd (Exim 4.72) for sidr@ietf.org (return-path ); Tue, 15 Feb 2011 01:25:28 +0000 Received: by yie19 with SMTP id 19so2620574yie.31 for ; Mon, 14 Feb 2011 17:25:24 -0800 (PST) Received: by 10.100.4.14 with SMTP id 14mr1899168and.179.1297733123994; Mon, 14 Feb 2011 17:25:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.214.17 with HTTP; Mon, 14 Feb 2011 17:25:03 -0800 (PST) In-Reply-To: <4D59AAC7.2070903@cisco.com> References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> <4D582D67.5090003@cisco.com> <4D59AAC7.2070903@cisco.com> From: Dongting Yu Date: Tue, 15 Feb 2011 01:25:03 +0000 Message-ID: To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: Dongting Yu Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 01:27:17 -0000 A few questions and comments. I don't think they have been mentioned before, excuse me if they have. 3.1 A BGPsec design MUST be able to be incrementally deployed on today's Internet. Does this allow for long-term eventual coexistence of BGPsec and normal BGP without compromise of security of the BGPsec? I can imagine scenarios where incremental deployments are possible at the cost of a weaker assurance, but with the expectation that eventually at least islands will appear where BGPsec is used everywhere (and only then will BGPsec be in full power). 3.3 As cryptographic payloads and loading on routers are likely to seriously increase, a BGPsec design may require use of new hardware. It must be possible to build routers that do BGPsec with within acceptable (to operators) bounds of cost and performance. may -> MAY, must -> MUST? 4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally determine that the UPDATE has traversed the AS path indicated in the UPADTE. Note that this is more stringent than showing that the path is merely not impossible. Are we talking about absolute assurance or probabilistic (with a tunable confidence value) assurance? Is a distinction needed? 4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design MUST provide a mechanism to control the window of exposure to replay attacks. Is this control mechanism something that each AS can choose? Dongting From randy@psg.com Mon Feb 14 18:50:34 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17953A6E0F for ; Mon, 14 Feb 2011 18:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJyF4RZAJEIT for ; Mon, 14 Feb 2011 18:50:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 423F93A6C27 for ; Mon, 14 Feb 2011 18:50:32 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PpB0A-000Kn6-Ud; Tue, 15 Feb 2011 02:50:55 +0000 Date: Tue, 15 Feb 2011 10:50:53 +0800 Message-ID: From: Randy Bush To: Dongting Yu In-Reply-To: References: <4D4454AE.6070304@cisco.com> <4C8FBB30-474A-410A-B384-B6F775EAA1E9@castlepoint.net> <4D57D34B.1000303@cisco.com> <4D582D67.5090003@cisco.com> <4D59AAC7.2070903@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 02:50:34 -0000 > 3.1 A BGPsec design MUST be able to be incrementally deployed on > today's Internet. > > Does this allow for long-term eventual coexistence of BGPsec and > normal BGP without compromise of security of the BGPsec? I can imagine > scenarios where incremental deployments are possible at the cost of a > weaker assurance, but with the expectation that eventually at least > islands will appear where BGPsec is used everywhere (and only then > will BGPsec be in full power). yes. though i imagine the security assertions you can make between two BGPsec islands across a non-secured gap could be weak. interesting issue. > 3.3 As cryptographic payloads and loading on routers are likely to > seriously increase, a BGPsec design may require use of new > hardware. It must be possible to build routers that do BGPsec > with within acceptable (to operators) bounds of cost and > performance. > > may -> MAY, must -> MUST? what i have in my edit buffer is 3.3 As cryptographic payloads and memory requirements on routers are likely to increase, a BGPsec design MAY require use of new hardware. I.e. compatibility with current hardware abilities is not a requirement that this document imposes on a solution. As BGPsec will likely not be rolled out for some years, this should not be a major problem. > 4.2 A BGPsec design MUST enable the recipient of an UPDATE to > formally determine that the UPDATE has traversed the AS path > indicated in the UPADTE. Note that this is more stringent than > showing that the path is merely not impossible. > > Are we talking about absolute assurance or probabilistic the intent is absolute, as much as there are absolutes in this life > 4.3 Replay of BGP UPDATE messages need not be completely prevented, > but a BGPsec design MUST provide a mechanism to control the > window of exposure to replay attacks. > > Is this control mechanism something that each AS can choose? i believe that the intent is that the originator of the prefix would be able to choose. randy From kseo@bbn.com Tue Feb 15 09:30:27 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA373A6CAB for ; Tue, 15 Feb 2011 09:30:27 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqTaHKuwJVXy for ; Tue, 15 Feb 2011 09:30:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DA1373A6C64 for ; Tue, 15 Feb 2011 09:30:24 -0800 (PST) Received: from dhcp89-089-149.bbn.com ([128.89.89.149]:49258) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpOji-000FSr-N4; Tue, 15 Feb 2011 12:30:50 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2011 12:30:47 -0500 To: sidr@ietf.org From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 17:30:27 -0000 I support adoption of this as a WG item (assuming charter issues are addressed.) >Folks, > >I have posted an individual submission ( draft-kent-bgpsec-threats-00.txt) >as a first cut at a threat model for BGP path secruity, based on use >of the RPKI that this WG has developed, and based on the use of >digital signatures applied to AS path info in BGP update messages. >Since path secruity is the next topic that the WG is poised to >address (as we complete work on the RPKI document set) >it seemed like an appropriate time to submit a threat model of this sort. > >I'd like SIDR to consider adopting a threat model for BGP path secruity >as a WG item, and offer this as a starting point for the discussion (if >the WG agrees to pursue this topic). > > >Steve >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Tue Feb 15 13:06:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81DD3A6CB9 for ; Tue, 15 Feb 2011 13:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf+8rjCsPhpd for ; Tue, 15 Feb 2011 13:06:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A7C6B3A6C4E for ; Tue, 15 Feb 2011 13:06:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PpS6h-000O6E-MO; Tue, 15 Feb 2011 21:06:48 +0000 Date: Wed, 16 Feb 2011 05:06:46 +0800 Message-ID: From: Randy Bush To: Karen Seo In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 21:06:24 -0000 > I support adoption of this as a WG item From Internet-Drafts@ietf.org Tue Feb 15 13:15:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C02C3A6C4E; Tue, 15 Feb 2011 13:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCI91Cgrlimm; Tue, 15 Feb 2011 13:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85FD53A6ADB; Tue, 15 Feb 2011 13:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215211501.18381.89844.idtracker@localhost> Date: Tue, 15 Feb 2011 13:15:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 21:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-08.txt Pages : 21 Date : 2011-02-15 In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-15130116.I-D@ietf.org> --NextPart-- From randy@psg.com Tue Feb 15 16:39:27 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989D73A6DA5 for ; Tue, 15 Feb 2011 16:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdgKNS4WvA0o for ; Tue, 15 Feb 2011 16:39:27 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C90C13A6D63 for ; Tue, 15 Feb 2011 16:39:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PpVQu-000OzP-9Q for sidr@ietf.org; Wed, 16 Feb 2011 00:39:52 +0000 Date: Wed, 16 Feb 2011 08:39:51 +0800 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20110215211501.18381.89844.idtracker@localhost> References: <20110215211501.18381.89844.idtracker@localhost> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 00:39:27 -0000 this just cleaned up id nits randy From Internet-Drafts@ietf.org Tue Feb 15 19:45:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0363A6CD9; Tue, 15 Feb 2011 19:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B55OXiPxJ1he; Tue, 15 Feb 2011 19:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54F23A6C7E; Tue, 15 Feb 2011 19:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110216034501.11170.90820.idtracker@localhost> Date: Tue, 15 Feb 2011 19:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-iana-objects-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 03:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI Objects issued by IANA Author(s) : T. Manderson, et al. Filename : draft-ietf-sidr-iana-objects-01.txt Pages : 19 Date : 2011-02-15 This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-iana-objects-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-iana-objects-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-15194106.I-D@ietf.org> --NextPart-- From terry.manderson@icann.org Tue Feb 15 19:49:57 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859563A6CB9 for ; Tue, 15 Feb 2011 19:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUHAxa6AMTib for ; Tue, 15 Feb 2011 19:49:56 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 88E383A6C7E for ; Tue, 15 Feb 2011 19:49:56 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 15 Feb 2011 19:50:23 -0800 From: Terry Manderson To: "sidr@ietf.org" Date: Tue, 15 Feb 2011 19:50:22 -0800 Thread-Topic: [sidr] I-D Action:draft-ietf-sidr-iana-objects-01.txt Thread-Index: AcvNjALhOu/D58S/QeKrLywtcu5gGQAAJ/gP Message-ID: In-Reply-To: <20110216034501.11170.90820.idtracker@localhost> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action:draft-ietf-sidr-iana-objects-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 03:49:57 -0000 Rev'd at the WG Co-Chair's request. Contains agreed fixes during last call so that the chairs can progress shepherding using IETF tools. Cheers Terry On 16/02/11 1:45 PM, "Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working Grou= p of > the IETF. >=20 >=20 > Title : RPKI Objects issued by IANA > Author(s) : T. Manderson, et al. > Filename : draft-ietf-sidr-iana-objects-01.txt > Pages : 19 > Date : 2011-02-15 >=20 > This document provides specific direction to IANA as to the Resource > Public Key Infrastructure (RPKI) objects it should issue. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-iana-objects-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From christopher.morrow@gmail.com Tue Feb 15 20:06:10 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CE83A6CB6 for ; Tue, 15 Feb 2011 20:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK5u8Syp0UPY for ; Tue, 15 Feb 2011 20:06:09 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3B4853A6B8E for ; Tue, 15 Feb 2011 20:06:09 -0800 (PST) Received: by wyf23 with SMTP id 23so992680wyf.31 for ; Tue, 15 Feb 2011 20:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ci6h8+ydQdhjd0s2KR5eNbZ6w7BGduqx/dn0YWxVj5U=; b=J3R1k9w0PD9IxeqM1iRLetLpIpakG1M7/t0Q1hwJWnHXIifisaBacGTGcPw5Nkgs7a MA6ZVG9NnlT2TW0Ex0qfIDmp6irNwn1pqocJ5pkPuguMLV2WQ43gnCKD+4AMQMtFqImy PU7fo3jDqwsoNp0sU7L98+WtHkQL6FRF38j2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dV20H0+IF7/AzlsfF47eFz02EDw+sdZhJW8vq3yPGqgTxIM95GkVohCtFythzpp+lW bb6FmWdBE+Mg+rXKi29VV8UvZCffClVjCixpMG6YIomoelGo+qx9rVit3XqrB8JfoO1E tGgDRCx9vbmyPf1NOUydm0JDvYOaTwkY9nFsE= MIME-Version: 1.0 Received: by 10.216.39.196 with SMTP id d46mr53329web.114.1297829195042; Tue, 15 Feb 2011 20:06:35 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Tue, 15 Feb 2011 20:06:34 -0800 (PST) In-Reply-To: References: <20110216034501.11170.90820.idtracker@localhost> Date: Tue, 15 Feb 2011 23:06:34 -0500 X-Google-Sender-Auth: BWP7VB7JMajpLYfJ0HPz2YoxhzA Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action:draft-ietf-sidr-iana-objects-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 04:06:10 -0000 On Tue, Feb 15, 2011 at 10:50 PM, Terry Manderson wrote: > Rev'd at the WG Co-Chair's request. Contains agreed fixes during last cal= l > so that the chairs can progress shepherding using IETF tools. thanks much! -chris > Cheers > Terry > > > On 16/02/11 1:45 PM, "Internet-Drafts@ietf.org" > wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Secure Inter-Domain Routing Working Gro= up of >> the IETF. >> >> >> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RPKI Objects issued by IANA >> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : T. Manderson, et al. >> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-iana-objects-0= 1.txt >> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19 >> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-15 >> >> This document provides specific direction to IANA as to the Resource >> Public Key Infrastructure (RPKI) objects it should issue. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-iana-objects-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Tue Feb 15 20:31:28 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9BB3A6D2D for ; Tue, 15 Feb 2011 20:31:28 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lprHJyobFu7g for ; Tue, 15 Feb 2011 20:31:28 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D16B33A6D23 for ; Tue, 15 Feb 2011 20:31:27 -0800 (PST) Received: by wyf23 with SMTP id 23so1006673wyf.31 for ; Tue, 15 Feb 2011 20:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=WRxyRqvf2343/JFZeYZP7IPICtwbw8Mh4WJLvzHblGQ=; b=InRjbNOB3WlrK6LMpa2Bj6jxPnmSVXXG7DYS7Mlw11dTVzP8XLrayfQhP28STjAvT/ whnk53AqLkgj5gkhCHLKQKDzp9Kc2dcgTdNZ0cLx1uOEj6GEZK8u9wEtZSmRSXzfag0g KlEeg8ohlWlKOe3NjSKtS39woPwf++ZZx7iKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TSzyN+yutzcHTbappQoGg0u6/iAmmeLd6HRF91L6nFqpPbuNoD4vBevKs13N1nVm+Z agBaEjgrThJC/pWz5BCQIIhsFE4jAl0hbV4RmrBQVfxUo78FDfvSP3I05OMDHhoTDR4Y fRHeNncFYV9LPpWi2UCjh8h4MfAd8xwowm6Q4= MIME-Version: 1.0 Received: by 10.216.154.136 with SMTP id h8mr71934wek.84.1297830714543; Tue, 15 Feb 2011 20:31:54 -0800 (PST) Received: by 10.216.1.197 with HTTP; Tue, 15 Feb 2011 20:31:54 -0800 (PST) Date: Tue, 15 Feb 2011 23:31:54 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] Off to the IESG with you! -> draft-ietf-sidr-iana-objects-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 04:31:29 -0000 This is off to the IESG... or to Adrian/Stewart at least. -Chris From ietfc@btconnect.com Wed Feb 16 04:58:01 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4DCF3A6CB3 for ; Wed, 16 Feb 2011 04:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou4S-C-jxbG1 for ; Wed, 16 Feb 2011 04:58:01 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 848703A6CBF for ; Wed, 16 Feb 2011 04:57:59 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr10.btconnect.com with SMTP id BSI30207; Wed, 16 Feb 2011 12:56:20 +0000 (GMT) Message-ID: <016901cbcdcf$f270e380$4001a8c0@gateway.2wire.net> From: "t.petch" Cc: References: <20110215211501.18381.89844.idtracker@localhost> Date: Wed, 16 Feb 2011 12:45:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D5BC974.0114, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D5BC9F3.0300,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 12:58:02 -0000 Belatedly looking at this, I believe that the SSH subsystem name should be registered with IANA. Also, my experience of the IESG is that they will want more by way of security considerations. The recent draft-ietf-netconf-rfc4742bis gives exemplars of what I have in mind. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Tuesday, February 15, 2011 10:15 PM Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-08.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > > Title : The RPKI/Router Protocol > Author(s) : R. Bush, R. Austein > Filename : draft-ietf-sidr-rpki-rtr-08.txt > Pages : 21 > Date : 2011-02-15 > > In order to formally validate the origin ASes of BGP announcements, > routers need a simple but reliable mechanism to receive RPKI > [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted > cache. This document describes a protocol to deliver validated > prefix origin data to routers over ssh. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-08.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Wed Feb 16 09:53:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB87D3A6EDD; Wed, 16 Feb 2011 09:53:19 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVAVtWktQwoc; Wed, 16 Feb 2011 09:53:18 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1F2EE3A6EDA; Wed, 16 Feb 2011 09:53:17 -0800 (PST) Received: by wyf23 with SMTP id 23so1714267wyf.31 for ; Wed, 16 Feb 2011 09:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=FzJzyt82zl2Vn8GuBRIRn8iwrGcLc8kwZz30wrFmTI0=; b=EUY6NCpUNapwOlBGl8VHeNNWH+h2tmjqsm4dO0jV7dbJvlUca25Z/byJewoCtMAi9X 5rsn5HBI4rUC/ZSGzjlkx0ntzT7fnjkeFDeQJC3jxpYI1rWNT9THICcGdNHaDmmBmbvg 4HaVsDbEF2492CC/xgcEXFDxCAJZS9sbNGYuY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QzyXWOoC1NerRPS3udtjswqUfnNo0BuTg4ocbReAx8mchdD8TSzK6rBcrNYHWpk8Er VByp6xEj+h+LPnTN7IVAXHtaCjN0WcrjIUyBIULimd0TY0Z/Nym66/4QKrmLGrvUUBpn nDRCr7Cmr8HIr28txoXR63YkwPP6DMDQ05bgU= MIME-Version: 1.0 Received: by 10.216.14.147 with SMTP id d19mr756020wed.84.1297878826058; Wed, 16 Feb 2011 09:53:46 -0800 (PST) Received: by 10.216.1.197 with HTTP; Wed, 16 Feb 2011 09:53:45 -0800 (PST) Date: Wed, 16 Feb 2011 12:53:45 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org, Stewart Bryant , Adrian Farrel , sidr-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 17:53:19 -0000 Howdy, as mentioned a few weeks back we need to re-charter the WG in order to move on from simply validating origination of routing information to possibly validating path information as well, here's a strawman charter re-work, how about we discuss some on the list and have some more chat about it at the Prague meeting? = = = = = = = = = Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the route update traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta ================== -Chris From christopher.morrow@gmail.com Wed Feb 16 10:38:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7000B3A6EE5; Wed, 16 Feb 2011 10:38:52 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qxCtznuU5hP; Wed, 16 Feb 2011 10:38:51 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 363AE3A6D15; Wed, 16 Feb 2011 10:38:51 -0800 (PST) Received: by wwa36 with SMTP id 36so1708214wwa.13 for ; Wed, 16 Feb 2011 10:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=1zt8SgxGXfpFSQMr327uZg0JGXe72l3BVEKPqxx0jzo=; b=c4R+jKeLUqzQymZ4uSAwyhOdjUBuCox3QVkymwjeOtnDv096n5nR+SxquR3hrTJDbu ch6MPoA8E/1658o+q5cK+S2GDxh8NYpB+TMqycc4H8CigodK38AWI5pLTVZdfB6q16Cf E++gf4FLO+ilH6WoiDTS94ZQslWbjzxCzmKc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UeKAJa2N7OJI8ZRFgFSxrZzzCdC5BLjpCKzrAigrVvR94wJPSnV/GbgBp57NbYaluU 5kGI0uhmFiE37NwvA/VptRSwHNGZTeyuTX9LDQBJNlCLGJHUjAX6rhnrih6aUOxn5zQW xX8N4U+Uq+0RDfRU6sfvdy1b3mmD4pHG1ev+I= MIME-Version: 1.0 Received: by 10.216.160.84 with SMTP id t62mr755365wek.69.1297881559141; Wed, 16 Feb 2011 10:39:19 -0800 (PST) Received: by 10.216.1.197 with HTTP; Wed, 16 Feb 2011 10:39:19 -0800 (PST) Date: Wed, 16 Feb 2011 13:39:19 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 18:38:52 -0000 Ok folk, The rpki-rtr document: went through WGLC on version ~02, it's since had a slight mod (added a Cache-nonce added) which is here in section 4.1: "The Cache Nonce reassures the router that the serial numbers are comensurate, i.e. the cache session has not been changed." and again in 4.2: "The Cache Nonce tells the cache what instance the router expects to ensure that the serial numbers are comensurate, i.e. the cache session has not been changed." and again in 4.4: "In response to a Reset Query, the Cache Nonce tells the router the instance of the cache session for future confirmation. In response to a Serial Query, the Cache Nonce reassures the router that the serial numbers are comensurate, i.e. the cache session has not been changed." and again in 4.7: "The Cache Nonce MUST be the same as that of the corresponding Cache Response which began the, possibly null, sequence of data PDUs." There's not much meat to the actual change, and the authors identified the problem on their own. So, in the spirit of valentines day, let's decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move forward. If there are no further comments/issues I'll push this version out over the weekend to the AD's as a publication request. -Chris From Internet-Drafts@ietf.org Wed Feb 16 11:45:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97ECA3A6E8F; Wed, 16 Feb 2011 11:45:02 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3OpKVX9Vui5; Wed, 16 Feb 2011 11:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8943A6AB3; Wed, 16 Feb 2011 11:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110216194501.1755.81250.idtracker@localhost> Date: Wed, 16 Feb 2011 11:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-arch-12.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : An Infrastructure to Support Secure Internet Routing Author(s) : M. Lepinski, S. Kent Filename : draft-ietf-sidr-arch-12.txt Pages : 24 Date : 2011-02-16 This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) Numbers; and a distributed repository system for storing and disseminating the data objects that comprise the PKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-arch-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16113759.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Feb 16 12:00:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034DF3A6D2A; Wed, 16 Feb 2011 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l-itw4Ah1yo; Wed, 16 Feb 2011 12:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDDA3A6ABD; Wed, 16 Feb 2011 12:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110216200002.6424.8225.idtracker@localhost> Date: Wed, 16 Feb 2011 12:00:02 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-signed-object-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 20:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Signed Object Template for the Resource Public Key Infrastructure Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-signed-object-03.txt Pages : 12 Date : 2011-02-16 This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-signed-object-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-signed-object-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16115155.I-D@ietf.org> --NextPart-- From gih@apnic.net Wed Feb 16 16:16:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2D943A6D9E for ; Wed, 16 Feb 2011 16:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.895 X-Spam-Level: X-Spam-Status: No, score=-101.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbOFJmveB0QF for ; Wed, 16 Feb 2011 16:16:02 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 3E3493A6AF1 for ; Wed, 16 Feb 2011 16:16:01 -0800 (PST) Received: from leexp.canberra.aarnet.edu.au (joan-vista.canberra.aarnet.edu.au [202.158.221.46]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A7B11B649C; Thu, 17 Feb 2011 10:16:28 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2011 11:16:28 +1100 Message-Id: To: "sidr@ietf.org wg" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Cc: draft-ietf-sidr-repos-struct@tools.ietf.org Subject: [sidr] IANA considerations for repos-struct draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 00:16:02 -0000 I believe that the action on me is to add an IANA considerations section = to this draft stating IANA is to create a RPKI repository name scheme register. The register = is to contain the filename extensions of RPKI repository objects. The registry's contents = is to be managed by IETF Review. The initial contents of this register is to include the = following: =20 Filename extension RPKI Object .cer Certificate .crl Certificate Revocation List .mft Manifest .roa Route Origination Authorization Are there other RPKI objects that should be added into this initial = table? Geoff From turners@ieca.com Wed Feb 16 17:25:13 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7393A6EEB for ; Wed, 16 Feb 2011 17:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjrCljGzLiMz for ; Wed, 16 Feb 2011 17:25:08 -0800 (PST) Received: from nm24.bullet.mail.ac4.yahoo.com (nm24.bullet.mail.ac4.yahoo.com [98.139.52.221]) by core3.amsl.com (Postfix) with SMTP id 696E23A6DE1 for ; Wed, 16 Feb 2011 17:25:06 -0800 (PST) Received: from [98.139.52.195] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 17 Feb 2011 01:25:33 -0000 Received: from [98.139.52.132] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 17 Feb 2011 01:25:33 -0000 Received: from [127.0.0.1] by omp1015.mail.ac4.yahoo.com with NNFMP; 17 Feb 2011 01:25:33 -0000 X-Yahoo-Newman-Id: 408959.60852.bm@omp1015.mail.ac4.yahoo.com Received: (qmail 64163 invoked from network); 17 Feb 2011 01:25:32 -0000 Received: from thunderfish.local (turners@96.231.115.162 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 16 Feb 2011 17:25:32 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: SciUF80VM1n5CQ2z9Sxc4FSswfk_Tf1b.0y2EcZTt644XoL bv4Bzd.oEhCYrzVH3xCTPkyYGoWE8f1sA9QjKP9ZxuI.GDpIYITU6Y7XNNBj 7hHB69eqbqUVA5NSpS9nqGCMCCJeok1uL7PIKBYTmWguNOwFV7VEDZ0.KnzW RU9699wE9GPujj7MSZJBpn5Hv0aBpsWNJ9IcJhzskcNXr5lTvtjHD4agDtfC 13Lxc_91OwacPj23WvkijF.Xct24wlS09Ybe45RqnRdO2b_tVnwJf1.HLOfT EUEFRXdoFXV79OwsiGGmWLR7MJHV6hWbR7w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D5C78BB.5060306@ieca.com> Date: Wed, 16 Feb 2011 20:24:11 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Geoff Huston References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, "sidr@ietf.org wg" Subject: Re: [sidr] IANA considerations for repos-struct draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:25:13 -0000 Hi, .cer and .crl are already defined in RFC 2585 as part of the application/pkix-cert and application/pkix-crl registrations. Can we just point there? Do we need media type registrations for application/sidr-manifest and application/sidr-roa? spt On 2/16/11 7:16 PM, Geoff Huston wrote: > I believe that the action on me is to add an IANA considerations section to this draft stating > > IANA is to create a RPKI repository name scheme register. The register is to contain the > filename extensions of RPKI repository objects. The registry's contents is to be managed > by IETF Review. The initial contents of this register is to include the following: > > Filename extension RPKI Object > .cer Certificate > .crl Certificate Revocation List > .mft Manifest > .roa Route Origination Authorization > > > > Are there other RPKI objects that should be added into this initial table? > > Geoff > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Wed Feb 16 17:46:26 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 898F73A6F0D for ; Wed, 16 Feb 2011 17:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmMNdLYe6n7x for ; Wed, 16 Feb 2011 17:46:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id AE4FE3A6E81 for ; Wed, 16 Feb 2011 17:46:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PpsxJ-0004wo-Jf; Thu, 17 Feb 2011 01:46:53 +0000 Date: Thu, 17 Feb 2011 09:46:52 +0800 Message-ID: From: Randy Bush To: Tom Petch In-Reply-To: <016901cbcdcf$f270e380$4001a8c0@gateway.2wire.net> References: <20110215211501.18381.89844.idtracker@localhost> <016901cbcdcf$f270e380$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 01:46:26 -0000 thanks, tom > Belatedly looking at this, I believe that the SSH subsystem name should be > registered with IANA. This document requests the IANA to add an SSH Subsystem Name of rpkirtr, as defined in . > Also, my experience of the IESG is that they will want more by way of > security considerations. > > The recent draft-ietf-netconf-rfc4742bis gives exemplars of what I > have in mind. interesting. i worry that it will cycle a call. so let's wait for the iesg. cool? randy From Internet-Drafts@ietf.org Wed Feb 16 18:00:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0583D3A6F14; Wed, 16 Feb 2011 18:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeHIppGawlvO; Wed, 16 Feb 2011 18:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6BA3A6F0D; Wed, 16 Feb 2011 18:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110217020001.4791.28170.idtracker@localhost> Date: Wed, 16 Feb 2011 18:00:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 02:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-09.txt Pages : 21 Date : 2011-02-16 In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-16175233.I-D@ietf.org> --NextPart-- From randy@psg.com Wed Feb 16 23:52:40 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328833A6C68 for ; Wed, 16 Feb 2011 23:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXAufe8GIDv0 for ; Wed, 16 Feb 2011 23:52:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 38B873A6A86 for ; Wed, 16 Feb 2011 23:52:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ppyfj-00061m-RV; Thu, 17 Feb 2011 07:53:08 +0000 Date: Thu, 17 Feb 2011 15:53:06 +0800 Message-ID: From: Randy Bush To: "t.petch" In-Reply-To: <016901cbcdcf$f270e380$4001a8c0@gateway.2wire.net> References: <20110215211501.18381.89844.idtracker@localhost> <016901cbcdcf$f270e380$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 07:52:40 -0000 i have The ssh identity of the cache server MUST be verified and authenticated by the router client, and vice versa, before any data are exchanged. queued for the security section of next version randy From christopher.morrow@gmail.com Thu Feb 17 06:28:31 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114103A6CBB for ; Thu, 17 Feb 2011 06:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RigDTQcRG4Cg for ; Thu, 17 Feb 2011 06:28:30 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1CD923A6B6B for ; Thu, 17 Feb 2011 06:28:29 -0800 (PST) Received: by wwa36 with SMTP id 36so2648275wwa.13 for ; Thu, 17 Feb 2011 06:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=0skdHVr2dP6Ko1EBXmqLQbkDkCEkxCVqdFHCRfJ7fGY=; b=Y1OxtoG25JOYDvG02eGe1OFHD/3nEVLULRe5hiYU//fyTpJvz6lfgPFX72xx+YOtlv 71lbFARj2wR+SFJPnk87ggVLHpWnY30hLVMxVsZjyqIZ/W4ZtbDht5695r1/TPbxeZvD Yc0LsrU4mDoM45boBbcFEPCQZGTLSRF2fZFqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aWJ6Ws0W+EtvXa+aLF022kebz11YE/yVZa+mLYWFZckZG/nS6OKmeKxnBawZj7ix+/ hu0+lD4JD6Wfp0uOs6UQIlB/4kyuVN790gJ3wxxKCr454ePVO4cR9vCLGNE3SQGFGxkv XouZwkNmS9wZT/FZMDJthAYYLG1LsQaGLmkrY= MIME-Version: 1.0 Received: by 10.216.39.196 with SMTP id d46mr1558260web.114.1297952938946; Thu, 17 Feb 2011 06:28:58 -0800 (PST) Received: by 10.216.1.197 with HTTP; Thu, 17 Feb 2011 06:28:58 -0800 (PST) Date: Thu, 17 Feb 2011 09:28:58 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] For those following along at home: draft-ietf-sidr-iana-objects is headed for LC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 14:28:31 -0000 State changed to Last Call Requested from Publication Requested. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sidr-iana-objects/ From iesg-secretary@ietf.org Thu Feb 17 06:48:43 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294C53A6F26; Thu, 17 Feb 2011 06:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEI5Jro4Otb9; Thu, 17 Feb 2011 06:48:42 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609163A6E2A; Thu, 17 Feb 2011 06:48:42 -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: 3.12 Message-ID: <20110217144842.24990.5061.idtracker@localhost> Date: Thu, 17 Feb 2011 06:48:42 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (RPKI Objects issued by IANA) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 17 Feb 2011 14:48:43 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI Objects issued by IANA' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-03. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-iana-objects/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-iana-objects/ This draft has the following downrefs: ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-roa-validation (ref. 'I-D.ietf-sidr-roa-validation') ** Downref: Normative reference to an Informational RFC: RFC 2860 ** Downref: Normative reference to an Informational RFC: RFC 3849 ** Downref: Normative reference to an Informational RFC: RFC 5180 ** Downref: Normative reference to an Informational RFC: RFC 5736 No IPR declarations have been submitted directly on this I-D. From rogaglia@cisco.com Thu Feb 17 07:10:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D963A6E69 for ; Thu, 17 Feb 2011 07:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.181 X-Spam-Level: X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GFbqIqCrFsk for ; Thu, 17 Feb 2011 07:10:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4F7F63A6D47 for ; Thu, 17 Feb 2011 07:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=5923; q=dns/txt; s=amsiport01001; t=1297955448; x=1299165048; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=1rQo7tru/3mR8b8wDJsUAQuuFI1C0w54CPg2gcJzHJU=; b=de7aDsKE++eBMPcR/SH8fjVJTnXnBwsxx1MEXSbzf2RRvoEybx7nv0vI u2ZJMUFRYIMT0pibWjQg0SZoO4EIdAtbwn7L1f69QVHPGllQ6IvaVkNu2 3qQdRXRV/Kf/8YPPCZslRX5KvyMLzNt5Otc0Ra6ce5AJfCqZUC8RjEpFj Q=; X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsEAFLJXE2Q/khNgWdsb2JhbACmGBUBARYiJKAym1KFXgSMEA X-IronPort-AV: E=Sophos;i="4.60,486,1291593600"; d="p7s'?scan'208";a="76585049" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 17 Feb 2011 15:10:47 +0000 Received: from dhcp-10-61-107-145.cisco.com (dhcp-10-61-107-145.cisco.com [10.61.107.145]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1HFAlI3021145 for ; Thu, 17 Feb 2011 15:10:47 GMT From: Roque Gagliano Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-600--326816190; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 17 Feb 2011 16:10:47 +0100 In-Reply-To: To: "sidr@ietf.org wg" References: Message-Id: X-Mailer: Apple Mail (2.1082) Subject: Re: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 15:10:25 -0000 --Apple-Mail-600--326816190 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Geoff, would you be comfortable with this rewording for emergency = rekey, and with the MUST->RECOMMEND, if Sandy determines that there is = WG consensus for that change? >=20 +1. Roque. >=20 > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-600--326816190 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNzE1 MTA0N1owIwYJKoZIhvcNAQkEMRYEFKLYguQLMthqjTZw4ZEjAhMCS9ECMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAE404IVESjOtYee7tyYZVvSmcAIiSjePDMeUtUPmwl6S2r1tNP0r awsUXP2ap24+eUE1Bo/7oYB1YbGLniM5ojAxc4zd3thOxYlVJtlUQxy/ZDLKStV4zlEv5a9uiS+9 LJoJaj6UTpiOcOBLKP2YiGIjJ633xQYEAzt4xJISKMpfd5AevnwZiEPuV6YUc17pHmZabBGQFqwQ RT0pe3xK0eOZtqLZxq0NOzUd9p67g5Fvak0eZGOSKY6BgDbWgv0BYwgWAdut7q5r26ti0WRV6ha5 VtwnSjjsVy71sIh9EYWBgcLe+mdZ760c2uf9HimeAHb91+Y7WJvCdbJ0E5o04woAAAAAAAA= --Apple-Mail-600--326816190-- From mlepinski@bbn.com Thu Feb 17 07:46:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0993A6F2F for ; Thu, 17 Feb 2011 07:46:45 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W9SfaV4OMaz for ; Thu, 17 Feb 2011 07:46:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 572A73A6DFE for ; Thu, 17 Feb 2011 07:46:44 -0800 (PST) Received: from [128.89.253.111] (port=2365) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pq64Z-000Eb2-5V for sidr@ietf.org; Thu, 17 Feb 2011 10:47:15 -0500 Message-ID: <4D5D4312.9030805@bbn.com> Date: Thu, 17 Feb 2011 10:47:30 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Updated drafts to fix some nits X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 15:46:45 -0000 In the past 24 hours I submitted updates to: draft-ietf-sidr-arch draft-ietf-sidr-signed-object draft-ietf-sidr-roa-format All changes made were fixes to nits, with one exception: An appendix was added to ROA Format containing an ASN.1 module (as requested during that document's WGLC). - Matt Lepinski From Internet-Drafts@ietf.org Thu Feb 17 08:00:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BC53A6F44; Thu, 17 Feb 2011 08:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TuqM1AI-Qua; Thu, 17 Feb 2011 08:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701D03A6D5C; Thu, 17 Feb 2011 08:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110217160001.14172.28373.idtracker@localhost> Date: Thu, 17 Feb 2011 08:00:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-format-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Route Origin Authorizations (ROAs) Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-roa-format-10.txt Pages : 9 Date : 2011-02-17 This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-17074655.I-D@ietf.org> --NextPart-- From kent@bbn.com Thu Feb 17 11:16:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C5C3A6E4A for ; Thu, 17 Feb 2011 11:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di6yHPe3t6oJ for ; Thu, 17 Feb 2011 11:16:04 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3875E3A6DE3 for ; Thu, 17 Feb 2011 11:16:04 -0800 (PST) Received: from dhcp89-089-141.bbn.com ([128.89.89.141]:49240) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pq9L9-000I09-Ap; Thu, 17 Feb 2011 14:16:35 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 17 Feb 2011 14:16:22 -0500 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, "sidr@ietf.org wg" Subject: Re: [sidr] IANA considerations for repos-struct draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 19:16:04 -0000 At 11:16 AM +1100 2/17/11, Geoff Huston wrote: >I believe that the action on me is to add an IANA considerations >section to this draft stating > >IANA is to create a RPKI repository name scheme register. The >register is to contain the >filename extensions of RPKI repository objects. The registry's >contents is to be managed >by IETF Review. The initial contents of this register is to include >the following: > > Filename extension RPKI Object > .cer Certificate > .crl Certificate Revocation List > .mft Manifest > .roa Route Origination Authorization > > > >Are there other RPKI objects that should be added into this initial table? > >Geoff I think this list is fine. the ghostbusters doc can define the suffix for its record type. Steve From sra@hactrn.net Thu Feb 17 17:04:00 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881443A6D23 for ; Thu, 17 Feb 2011 17:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.837 X-Spam-Level: X-Spam-Status: No, score=-99.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySTJ5K4uwgIp for ; Thu, 17 Feb 2011 17:03:58 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id A33133A6C72 for ; Thu, 17 Feb 2011 17:03:57 -0800 (PST) Received: from nargothrond.hactrn.net (unknown [202.171.211.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 249EA2844C for ; Fri, 18 Feb 2011 01:04:27 +0000 (UTC) Received: from nargothrond.hactrn.net (localhost [127.0.0.1]) by nargothrond.hactrn.net (Postfix) with ESMTP id DBDBB49A769 for ; Fri, 18 Feb 2011 09:04:20 +0800 (CST) Date: Fri, 18 Feb 2011 09:04:20 +0800 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> Subject: Re: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 01:04:00 -0000 At Tue, 8 Feb 2011 19:41:41 -0500, Stephen Kent wrote: > > I concur with Geoff re the desirability of the staging period. I > disagree with Rob's suggestion that the staging period is at the > wrong place in the document, or in the phased approach to key > rollover. > > From my perspective, the fundamental rationale for the staring period > is two-fold: > > - we want a delimited interval after which a CA can have > reasonable confidence that all RPs will have retrieved the new CA > key, before transiting to a new CA key and subordinate, signed > products. I have no problem with -allowing- a CA to wait for a staging interval here. I do still object to -requiring- every CA to wait for a staging interval here. > - we also want a delimited interval for RPs so that they can > acquire a new CA key prior to the transition to that key for > subordinate signed products. Not at all obvious. So long as the new CA key is published before the subordinate signed product, either it just works or you're into the grey area of loose consistency, where there are so many ways to lose that it's almost not worth trying to enumerate them. The net could partition. One of the rsync servers could be down. Your clock could be wrong. Etc ad nausium. > Because of the naming conventions adopted by the repository design, > most of these new products overwrite old ones, so we want to maximize > the likelihood that an RP gets a consistent set of data. You appear to be assuming a model in which an RP discards old good data before fetching new bad data, thus potentially shooting itself in the foot whenever anything changes. Perhaps instead one just ought not to write one's validator that way :) Part of my issue (raised explicitly in an earlier message, not sure if you saw it) is that the justification for the staging period in the draft is very weak, and needs to be rewritten to fix this (if you can) before publication. In essence, it starts with the bad assumption that perfect consistency is possible, even though we know (long mailing list discussion) that it is not, then justifies the staging period by saying that we must maintain consistency for the benefit of hypothetical validators that operate in strange ways that require it. Given that, as far as I know, none of the existing validators do require this of consistency (and given that, as noted, such consistency is not even possible), this does not make much sense. > I agree with Rob that there is no delimited period that will > guarantee that both CAs and RPs are in sync re a CA key transition. > But, that does not mean that we ought not select and publish such a > period, consistent with the other time intervals that we have > published, e.g., the frequency at which RPs SHOULD query the > repository. If I believed in the need for the staging period, I would agree with this. > As a compromise, we could re-phrase the staging period discussion to > RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not > just you, Rob, :-)) feels strongly. I would strongly prefer MAY to either MUST or SHOULD here. That said, I would strongly prefer SHOULD to MUST. :) Part of my issue, of course, is that I already have running code which does not follow the model you're trying to mandate here, and I am reluctant to change it to suit an ex post facto specification absent stronger justification than you've provided so far. As far as I have been able to determine, what I have now works just fine, and the changes you're trying to mandate would require not just code changes but some additional complexity in the internal management operations. Right now I have two operations related to key rollover: 1) Generate a new key, ask parent to issue new cert, deprecate (but continue to maintain) old key and cert, and start issuing new product with new key and cert until everything relevant has been reissued. 2) Revoke all deprecated keys and certs. If I accept your changes, I not only need to add a third operation (start using the new key and cert), I also need to make names for the pesky things visible in the control protocol, expose those names in the user interface, etc, because somebody might restart the rollover operation during the staging period. Whole collection of new ways for operator to get confused and shoot self in foot, to no gain that I can see, because you still haven't convinced me that the staging period is necessary in the first place. > I also agree that, as Roque noted, in the case of an emergency rekey, > the 24-hour staging period may be inappropriate. But an emergency > rekey is not the same as a planned key rollover. I suggest that we > note this difference up front and say that, in case of an emergency, > the CA re-issuing the cert which is being re-keyed SHOULD consider > the impact on routing of a quicker transition to a new cert+key, and > behave as it sees fit, given the circumstances surrounding the rekey. So code has to be capable of carrying on without waiting for the staging interval. Good. From randy@psg.com Thu Feb 17 17:43:59 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E203A6C72 for ; Thu, 17 Feb 2011 17:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orVC1BKg5tUi for ; Thu, 17 Feb 2011 17:43:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 1A56D3A6C28 for ; Thu, 17 Feb 2011 17:43:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PqFOW-000A80-De; Fri, 18 Feb 2011 01:44:28 +0000 Date: Fri, 18 Feb 2011 09:44:27 +0800 Message-ID: From: Randy Bush To: Rob Austein In-Reply-To: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> References: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 01:43:59 -0000 >> - we also want a delimited interval for RPs so that they can >> acquire a new CA key prior to the transition to that key for >> subordinate signed products. > > Not at all obvious. So long as the new CA key is published before the > subordinate signed product, either it just works or you're into the > grey area of loose consistency, where there are so many ways to lose > that it's almost not worth trying to enumerate them. The net could > partition. One of the rsync servers could be down. Your clock could > be wrong. Etc ad nausium. this way lies breakage. is this new way to get things wrongly really needed? >> Because of the naming conventions adopted by the repository design, >> most of these new products overwrite old ones, so we want to maximize >> the likelihood that an RP gets a consistent set of data. > > You appear to be assuming a model in which an RP discards old good > data before fetching new bad data, thus potentially shooting itself in > the foot whenever anything changes. the rp code in the routers goes the complete opposite way. if it has good data, those data are kept until new good data are completely fetched and assured. a router can even peer with multiple sources and hang on to 42 copies of good data. > perfect consistency is possible and cash could fall from the sky. sure it is possible. and so is brownian motion moving all the air molecules in the room into one corner. >> As a compromise, we could re-phrase the staging period discussion to >> RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not >> just you, Rob, :-)) feels strongly. > > I would strongly prefer MAY to either MUST or SHOULD here. That > said, I would strongly prefer SHOULD to MUST. :) i do not see how the router rps can deal with SHOULD. maybe MIGHT. or modify 2119 to add BLUE MOON. randy From rogaglia@cisco.com Fri Feb 18 02:37:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62ED93A6EF6 for ; Fri, 18 Feb 2011 02:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.033 X-Spam-Level: X-Spam-Status: No, score=-10.033 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLyT3Fi+G9uW for ; Fri, 18 Feb 2011 02:37:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 76BA43A6DEC for ; Fri, 18 Feb 2011 02:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=12860; q=dns/txt; s=amsiport01001; t=1298025488; x=1299235088; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=lOfjBZfIEJYFpt7lpRUx0ojQMOt3Lgd3xutjGoy/1SQ=; b=MfIFFESIO5jcnVZif83vnppGMtoGpne4ud6mhfLN8/y0dkiLQ+8stj+e vpXNhYiC13AnVsGN0unrTADPC0pkdoAh0uSu4b0mcjveyeFc7yEG0i7ff 8Hg6V5WGB06g7jPIWZz1kjsTXs5JkKG+g4QqEormgwDgtSWyHve88PNVH U=; X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAF/aXU2Q/khLgWdsb2JhbACmIBUBARYiJKB+mzSFXgSMEQ X-IronPort-AV: E=Sophos;i="4.62,186,1297036800"; d="p7s'?scan'208";a="76668008" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 18 Feb 2011 10:38:07 +0000 Received: from dhcp-144-254-20-250.cisco.com (dhcp-144-254-20-250.cisco.com [144.254.20.250]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1IAc68c008882; Fri, 18 Feb 2011 10:38:06 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-30--256776848; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> Date: Fri, 18 Feb 2011 11:38:06 +0100 Message-Id: <90C5C4E4-DE5C-47D9-9BBE-506F70EF7BD6@cisco.com> References: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org Subject: Re: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 10:37:37 -0000 --Apple-Mail-30--256776848 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rob, Just to clarify my position.=20 I believe that the emergency roll-over is one use case where MUST would = not apply. I checked some existing CPS to see what do they say about = Emergency rekeying, the only mention that I could find was in the case = or RIPE's CPS that mentions that an emergency re-keying of their = off-line trust anchor was performed but not mention to the process = utilized. Referring to replace it with SHOULD or MAY, I believe that = pre-publishing keys is a good practice. However, you have a point that = if the staging period is made completely optional, you are not = "breaking" RP softwares and consistency in the database across different = RP is impossible to be enforced. One more issue to consider is that, if = you look again to what the current CPSes are saying (i.e. LACNIC CPS = section 4.7.6), you already have one business day delay since the moment = that the re-keyed certificate was generated until the time that the = re-keyed certificate shows up in the repository. If you do not have a = staging period, you are facing the problem of starting resigning objects = without your re-keyed certificate been published yet. In your email email back in Dec, 7th you proposed: "Consider what would = happen if, instead of following the process mandated by this document, a = CA simply started issuing new certificates and reissuing old ones as = fast as it reasonably could". A compromise could be to make the staging period a MAY and add text that = states what factors should be consider when defining "reasonably = could".=20 Cheers, Roque. On Feb 18, 2011, at 2:04 AM, Rob Austein wrote: > At Tue, 8 Feb 2011 19:41:41 -0500, Stephen Kent wrote: >>=20 >> I concur with Geoff re the desirability of the staging period. I=20 >> disagree with Rob's suggestion that the staging period is at the=20 >> wrong place in the document, or in the phased approach to key=20 >> rollover. >>=20 >> =46rom my perspective, the fundamental rationale for the staring = period=20 >> is two-fold: >>=20 >> - we want a delimited interval after which a CA can have=20 >> reasonable confidence that all RPs will have retrieved the new CA=20 >> key, before transiting to a new CA key and subordinate, signed=20 >> products. >=20 > I have no problem with -allowing- a CA to wait for a staging interval > here. I do still object to -requiring- every CA to wait for a staging > interval here. >=20 >> - we also want a delimited interval for RPs so that they can=20 >> acquire a new CA key prior to the transition to that key for=20 >> subordinate signed products. >=20 > Not at all obvious. So long as the new CA key is published before the > subordinate signed product, either it just works or you're into the > grey area of loose consistency, where there are so many ways to lose > that it's almost not worth trying to enumerate them. The net could > partition. One of the rsync servers could be down. Your clock could > be wrong. Etc ad nausium. >=20 >> Because of the naming conventions adopted by the repository design,=20= >> most of these new products overwrite old ones, so we want to maximize=20= >> the likelihood that an RP gets a consistent set of data. >=20 > You appear to be assuming a model in which an RP discards old good > data before fetching new bad data, thus potentially shooting itself in > the foot whenever anything changes. Perhaps instead one just ought > not to write one's validator that way :) >=20 > Part of my issue (raised explicitly in an earlier message, not sure if > you saw it) is that the justification for the staging period in the > draft is very weak, and needs to be rewritten to fix this (if you can) > before publication. In essence, it starts with the bad assumption > that perfect consistency is possible, even though we know (long > mailing list discussion) that it is not, then justifies the staging > period by saying that we must maintain consistency for the benefit of > hypothetical validators that operate in strange ways that require it. > Given that, as far as I know, none of the existing validators do > require this of consistency (and given that, as noted, such > consistency is not even possible), this does not make much sense. >=20 >> I agree with Rob that there is no delimited period that will=20 >> guarantee that both CAs and RPs are in sync re a CA key transition.=20= >> But, that does not mean that we ought not select and publish such a=20= >> period, consistent with the other time intervals that we have=20 >> published, e.g., the frequency at which RPs SHOULD query the=20 >> repository. >=20 > If I believed in the need for the staging period, I would agree with > this. >=20 >> As a compromise, we could re-phrase the staging period discussion to=20= >> RECOMMEND a 24-hour minimum (vs. using MUST here), if the WG (not=20 >> just you, Rob, :-)) feels strongly. >=20 > I would strongly prefer MAY to either MUST or SHOULD here. That > said, I would strongly prefer SHOULD to MUST. :) >=20 > Part of my issue, of course, is that I already have running code which > does not follow the model you're trying to mandate here, and I am > reluctant to change it to suit an ex post facto specification absent > stronger justification than you've provided so far. As far as I have > been able to determine, what I have now works just fine, and the > changes you're trying to mandate would require not just code changes > but some additional complexity in the internal management operations. > Right now I have two operations related to key rollover: >=20 > 1) Generate a new key, ask parent to issue new cert, deprecate (but > continue to maintain) old key and cert, and start issuing new > product with new key and cert until everything relevant has been > reissued. >=20 > 2) Revoke all deprecated keys and certs. >=20 > If I accept your changes, I not only need to add a third operation > (start using the new key and cert), I also need to make names for the > pesky things visible in the control protocol, expose those names in > the user interface, etc, because somebody might restart the rollover > operation during the staging period. Whole collection of new ways for > operator to get confused and shoot self in foot, to no gain that I can > see, because you still haven't convinced me that the staging period is > necessary in the first place. >=20 >> I also agree that, as Roque noted, in the case of an emergency rekey,=20= >> the 24-hour staging period may be inappropriate. But an emergency=20 >> rekey is not the same as a planned key rollover. I suggest that we=20= >> note this difference up front and say that, in case of an emergency,=20= >> the CA re-issuing the cert which is being re-keyed SHOULD consider=20 >> the impact on routing of a quicker transition to a new cert+key, and=20= >> behave as it sees fit, given the circumstances surrounding the rekey. >=20 > So code has to be capable of carrying on without waiting for the > staging interval. Good. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-30--256776848 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxODEw MzgwN1owIwYJKoZIhvcNAQkEMRYEFLvfQ6PiacFVGlD9S/VFcxIuF6DlMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBALtqDSPaGXCRsDirmj55ChAzecA3pNIXwx0findnl/9ysU94+GmZ cIKW2+quqy+al0cwOFfkdFrPYBbPv/rS/xqUx+bN7Vz6zEEVfsypNRf8o+JS/N03GWrKIuztwHV8 hC+9fiVaquak9AAxcRqSd/7y1xMA77I/fLsWta2jvOegPACM8qu9rFc863Fm2cik8z6cDIFlU9fI YiXaXqxfEpLaxZuIbZGnkwQZDQyuebJjHfwvPzVG1PYJboQGEwZwO7qdfl5l9ojMeT6cUMBNb6Gi ueDY5wOz3p8Bu0Oq8oFaiTQVZqDN61kWtoEeaNeSWS8n3jFaEmQ7eUl7NplBosAAAAAAAAA= --Apple-Mail-30--256776848-- From ietfc@btconnect.com Fri Feb 18 04:01:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECEB3A6C96 for ; Fri, 18 Feb 2011 04:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eSy4iHwR7c1 for ; Fri, 18 Feb 2011 04:01:36 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by core3.amsl.com (Postfix) with ESMTP id C96CA3A6C83 for ; Fri, 18 Feb 2011 04:01:35 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2bthomr09.btconnect.com with SMTP id BUN55599; Fri, 18 Feb 2011 11:59:54 +0000 (GMT) Message-ID: <015901cbcf5a$639e0de0$4001a8c0@gateway.2wire.net> From: "t.petch" Cc: References: <20110217020001.4791.28170.idtracker@localhost> Date: Fri, 18 Feb 2011 11:55:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D5E5F2D.01C7, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4D5E5FC0.002B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 12:01:37 -0000 s.6 refers to the SSH subsystem name as rpki-rtr. s.12 requests the IANA to add an SSH Subsystem Name of 'rpkirtr'. Not sure which is right; I prefer the hyphenated one. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Thursday, February 17, 2011 3:00 AM Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-09.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > > Title : The RPKI/Router Protocol > Author(s) : R. Bush, R. Austein > Filename : draft-ietf-sidr-rpki-rtr-09.txt > Pages : 21 > Date : 2011-02-16 > > In order to formally validate the origin ASes of BGP announcements, > routers need a simple but reliable mechanism to receive RPKI > [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted > cache. This document describes a protocol to deliver validated > prefix origin data to routers over ssh. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From tim@ripe.net Fri Feb 18 05:18:09 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44CD3A6F15 for ; Fri, 18 Feb 2011 05:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPjpKHoWFExO for ; Fri, 18 Feb 2011 05:18:08 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id EC5DD3A6DD0 for ; Fri, 18 Feb 2011 05:18:07 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PqQEG-0006RD-SW; Fri, 18 Feb 2011 14:18:38 +0100 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PqQEG-0006aH-Le; Fri, 18 Feb 2011 14:18:36 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> Date: Fri, 18 Feb 2011 14:18:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1082) 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: 784d7acfe6559f2a0b602ec6519a0719ecf0aa70229cbd67b73abf9518a1d07d Cc: sidr@ietf.org Subject: Re: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 13:18:09 -0000 Hi All, my 2 cents with the implementation of our 'rpkid' and (ad-hoc, = not-yet-caching) validator in mind.. On Feb 18, 2011, at 2:04 AM, Rob Austein wrote: > At Tue, 8 Feb 2011 19:41:41 -0500, Stephen Kent wrote: >>=20 >> I concur with Geoff re the desirability of the staging period. I=20 >> disagree with Rob's suggestion that the staging period is at the=20 >> wrong place in the document, or in the phased approach to key=20 >> rollover. >>=20 >> =46rom my perspective, the fundamental rationale for the staring = period=20 >> is two-fold: >>=20 >> - we want a delimited interval after which a CA can have=20 >> reasonable confidence that all RPs will have retrieved the new CA=20 >> key, before transiting to a new CA key and subordinate, signed=20 >> products. >=20 > I have no problem with -allowing- a CA to wait for a staging interval > here. I do still object to -requiring- every CA to wait for a staging > interval here. right and as stated elsewhere in case of an emergency roll the interval = may be zero. >=20 >> - we also want a delimited interval for RPs so that they can=20 >> acquire a new CA key prior to the transition to that key for=20 >> subordinate signed products. >=20 > Not at all obvious. So long as the new CA key is published before the > subordinate signed product, either it just works or you're into the > grey area of loose consistency, where there are so many ways to lose > that it's almost not worth trying to enumerate them. The net could > partition. One of the rsync servers could be down. Your clock could > be wrong. Etc ad nausium. >=20 I am in two minds about this: 1) I think in case of a *planned* roll-over the staging period may help Though I agree it's not guaranteed to give 100% consistency as mentioned = by Rob, I also believe that for the two reasons phrased by Steve it's = the best the publication side can do to try and prevent issues that RPs = may encounter. otoh: 2) For anything less than MUST, the RP software SHOULD be able to deal = with no staging period in case of emergency rolls I have some ideas about defensive coding to detect possible scenarios = like this and re-fetch, or make sure to look for a new CA cert when the = old one is revoked etc, but I still doubt that all possible corner cases = can tackled. I am happy to talk about possible approaches with other = implementers, but I think this is probably not best discussed here in = this thread. I think the bottom line is that if the draft says no staging period for = emergency rolls, as we all agree on I think, this implies that RPs have = to be able to deal with this. So one might say if you can deal with = this, then this should be okay for planned rolls as well... It's just = that I am afraid that there is still more that can go wrong here, so I = prefer to keep the staging period for *planned* rolls. So personally I favor SHOULD... > If I accept your changes, I not only need to add a third operation > (start using the new key and cert), I also need to make names for the > pesky things visible in the control protocol, expose those names in > the user interface, etc, because somebody might restart the rollover > operation during the staging period. Whole collection of new ways for > operator to get confused and shoot self in foot, to no gain that I can > see, because you still haven't convinced me that the staging period is > necessary in the first place. To keep things reasonable we decided to restrict this to one roll-over = at a time, imposed by the software. I.e. a roll-over has to be completed = before a new one may be initiated. In our case *planned* key roll-overs are managed by automated processes = (when key older than 5 years) and use a 24 hour staging period. However = in case of an emergency operators can force initiation of a roll-over at = any other time and reduce the staging period to zero. In case of a = double emergency we can do an emergency roll, and then do another.. = though I sincerely hope this will never be needed ;) >> I also agree that, as Roque noted, in the case of an emergency rekey,=20= >> the 24-hour staging period may be inappropriate. But an emergency=20 >> rekey is not the same as a planned key rollover. I suggest that we=20= >> note this difference up front and say that, in case of an emergency,=20= >> the CA re-issuing the cert which is being re-keyed SHOULD consider=20 >> the impact on routing of a quicker transition to a new cert+key, and=20= >> behave as it sees fit, given the circumstances surrounding the rekey. >=20 > So code has to be capable of carrying on without waiting for the > staging interval. Good. +1 From Sandra.Murphy@cobham.com Fri Feb 18 06:53:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86ED93A6DFD for ; Fri, 18 Feb 2011 06:53:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGbn2YZTO2j8 for ; Fri, 18 Feb 2011 06:53:55 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9A20C3A6B6C for ; Fri, 18 Feb 2011 06:53:54 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1IEsStr022490 for ; Fri, 18 Feb 2011 08:54:28 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1IEsSkJ015672 for ; Fri, 18 Feb 2011 08:54:28 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.92]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Feb 2011 09:54:27 -0500 Date: Fri, 18 Feb 2011 09:54:25 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Feb 2011 14:54:28.0048 (UTC) FILETIME=[BDAEFD00:01CBCF7B] Subject: [sidr] running idnits on working group drafts X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 14:53:56 -0000 I am speaking here as co-chair, but without a coordinated position with my co-chair, so take this as a personal position. Part of doing the shepherding document writeup for a publication request is to attest that the shepherd has personally run idnits on the draft. You may be surprised to learn that none of the drafts that were past wglc passed the idnits. The routing ADs have indicated a distaste for drafts that do not pass idnits. There are various levels of idnit-ness. The strongest objection was to references that did not have the right name, making reviewing difficult. But the distaste applied to all. For a document to be published, idnits will have to be addressed in some way at some point in the process. It is true that idnits does warn about things that are not fixable (version numbers in referenced drafts being a good example). But fixing easily fixable things saves time, messages, angst, keystrokes.... Document hygiene. An idea whose time has come. --Sandy From christopher.morrow@gmail.com Fri Feb 18 07:40:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8F23A6CCE for ; Fri, 18 Feb 2011 07:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxVp+IJ0ftdY for ; Fri, 18 Feb 2011 07:40:41 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 276B23A6CBF for ; Fri, 18 Feb 2011 07:40:40 -0800 (PST) Received: by ewy8 with SMTP id 8so1751571ewy.31 for ; Fri, 18 Feb 2011 07:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MEsTP42bYN4EBSbPA6w3fzna9/q8uXKLld64XzPd418=; b=g5VkYVCPudfrS41nQHlrLx0kJT6GKv0KDwb3ZA2jEPgUOgmmezsT2JFyFSn2v1PG9U B+/YJoj64wGV8bY4AqFnneSnnz3vByKZ2g8sFZsmrXOv3dl9IkEyoFbj84qUCyCZu3xn jIKZvwOCyHrR/LagEgApYi1uFnsRypB4VnFbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xdejyVi7HpaX9Xblp3z1rBw2uE08Nl/JpM5BxuMJrrWaYg1E+DrJo77SUFQhvhX9ak 7AFQfI6ss/YiaQksQCm7KE8Sp5xYCj0flFZKNWruCaoIu4yMbmxAr+trkubw9JryiWuB oE67nKmXJnJxB03sfJf7TIiQZMdG/27a7szMk= MIME-Version: 1.0 Received: by 10.216.18.204 with SMTP id l54mr712989wel.99.1298043674114; Fri, 18 Feb 2011 07:41:14 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 07:41:14 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Feb 2011 10:41:14 -0500 X-Google-Sender-Auth: f-cj1VAYuGm1xU20SMrpCIt-O0I Message-ID: From: Christopher Morrow To: Sandra Murphy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] running idnits on working group drafts X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 15:40:42 -0000 On Fri, Feb 18, 2011 at 9:54 AM, Sandra Murphy w= rote: > I am speaking here as co-chair, but without a coordinated position with m= y > co-chair, so take this as a personal position. i agree with the below... > Part of doing the shepherding document writeup for a publication request = is > to attest that the shepherd has personally run idnits on the draft. > > You may be surprised to learn that none of the drafts that were past wglc > passed the idnits. > > The routing ADs have indicated a distaste for drafts that do not pass > idnits. =A0There are various levels of idnit-ness. =A0The strongest objec= tion > was to references that did not have the right name, making reviewing > difficult. =A0But the distaste applied to all. > > For a document to be published, idnits will have to be addressed in some = way > at some point in the process. =A0It is true that idnits does warn about t= hings > that are not fixable (version numbers in referenced drafts being a good > example). =A0But fixing easily fixable things saves time, messages, angst= , > keystrokes.... > > Document hygiene. =A0An idea whose time has come. not JUST a good idea! :) thanks! -chris From russ@cisco.com Fri Feb 18 08:34:31 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2451C3A6AA7; Fri, 18 Feb 2011 08:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ktELLdyRN9s; Fri, 18 Feb 2011 08:34:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 38ECC3A6C6A; Fri, 18 Feb 2011 08:34:30 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="asc'?scan'208";a="217251909" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 16:35:04 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1IGZ321029286; Fri, 18 Feb 2011 16:35:04 GMT Message-ID: <4D5E9FC6.4020404@cisco.com> Date: Fri, 18 Feb 2011 11:35:18 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEEE752FC731D9F82CF768B1F" Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 16:34:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEEE752FC731D9F82CF768B1F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > * Is an Autonomous System (AS) authorized to originate an IP prefix > * Is the AS-Path represented in the route the same as the path > through which the route update traveled As we've been discussing on the list --I don't think this is a good goal. The first goal should be to determine what it is we want to show about the AS Path in relation to other things, and then work on filling that goal. Starting with the assumption that proving an update travels a specific path seems, to me, to be going about things the wrong way. :-) Russ --------------enigEEE752FC731D9F82CF768B1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1en8YACgkQER27sUhU9OSZVwCfWVvqeftiLG76zGJ41ApwGUnR 7ekAn1BGUXrQG5mg0hIquMjOIEDWUOJG =FB0+ -----END PGP SIGNATURE----- --------------enigEEE752FC731D9F82CF768B1F-- From john@jlc.net Fri Feb 18 09:11:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1053A6D16; Fri, 18 Feb 2011 09:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.784 X-Spam-Level: X-Spam-Status: No, score=-106.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFaHJnDRHi98; Fri, 18 Feb 2011 09:11:27 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id C35513A6AA6; Fri, 18 Feb 2011 09:11:20 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8C9D533C29; Fri, 18 Feb 2011 12:11:54 -0500 (EST) Date: Fri, 18 Feb 2011 12:11:54 -0500 From: John Leslie To: Russ White Message-ID: <20110218171154.GE15397@verdi> References: <4D5E9FC6.4020404@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4D5E9FC6.4020404@cisco.com> User-Agent: Mutt/1.4.1i Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:11:39 -0000 Russ White wrote: > To: Christopher Morrow >=20 >> * Is an Autonomous System (AS) authorized to originate an IP prefix >> * Is the AS-Path represented in the route the same as the path >> through which the route update traveled >=20 > As we've been discussing on the list --I don't think this is a good > goal. The first goal should be to determine what it is we want to show > about the AS Path in relation to other things, and then work on filling > that goal. The question I think we ought to care about is: Is the NLRI from this peer more or less likely than some other peer's NLRI to represent what a legitimate originator would want me to see? All I really have control over is which peer I send to (and thus which NLRI I forward to my peers). I have no control over what happens to the packets after than first forwarding step. -- John Leslie From morrowc@ops-netman.net Fri Feb 18 09:20:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72993A6CC7; Fri, 18 Feb 2011 09:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoUWktfrsHTR; Fri, 18 Feb 2011 09:20:29 -0800 (PST) Received: from neo-u2.ops-netman.net (neo-u2.OPS-NETMAN.NET [71.246.230.124]) by core3.amsl.com (Postfix) with ESMTP id 066213A6AA6; Fri, 18 Feb 2011 09:20:29 -0800 (PST) Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:21a:a0ff:fe27:86ff]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by neo-u2.ops-netman.net (Postfix) with ESMTPSA id 08B6F35C1D8; Fri, 18 Feb 2011 17:21:00 +0000 (UTC) Message-ID: <4D5EAA7B.9020007@ops-netman.net> Date: Fri, 18 Feb 2011 12:20:59 -0500 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Leslie References: <4D5E9FC6.4020404@cisco.com> <20110218171154.GE15397@verdi> In-Reply-To: <20110218171154.GE15397@verdi> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org, Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , Russ White Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:20:29 -0000 On 02/18/11 12:11, John Leslie wrote: > Russ White wrote: >> To: Christopher Morrow >> >>> * Is an Autonomous System (AS) authorized to originate an IP prefix >>> * Is the AS-Path represented in the route the same as the path >>> through which the route update traveled >> >> As we've been discussing on the list --I don't think this is a good >> goal. The first goal should be to determine what it is we want to show >> about the AS Path in relation to other things, and then work on filling >> that goal. > > The question I think we ought to care about is: > > Is the NLRI from this peer more or less likely than some other peer's NLRI > to represent what a legitimate originator would want me to see? > > All I really have control over is which peer I send to (and thus > which NLRI I forward to my peers). I have no control over what happens > to the packets after than first forwarding step. we can't (and shouldn't conflate here) packet security with routing (routing data, really) security. From christopher.morrow@gmail.com Fri Feb 18 09:22:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AC23A6D75; Fri, 18 Feb 2011 09:22:45 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3awl6hFmsCgV; Fri, 18 Feb 2011 09:22:43 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F39F53A6D71; Fri, 18 Feb 2011 09:22:42 -0800 (PST) Received: by wyf23 with SMTP id 23so4146457wyf.31 for ; Fri, 18 Feb 2011 09:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=37bNrh/V+H4uBTzUDI9Anp5y/gkOUlIuV/0OLUWIRD0=; b=eegkJT53lHfDdA2tYPq+XzDoQh3AKkYpWsC9BX5CfoRxEpdVu2XqGMIU04pvrJqXz/ xB+OGKcgAmSMDeXMU4IXJCJYwC73vpZoVwHJz/EAvBnxuf98/rt2n2yD9aa1PfhQyqEj 7yfak2tt0Jeq3n8dBHq3B3pS8jISohF2KhR9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=avWBM5mziLjys3Gyo8zf2O2LMx9dMLDySz1zJCZD+CNZcAwZC5ya2xEDGHOFNB4Lo/ J03/6oxyS+YMo+WkW/DTu+14mID+lmLNFHedlaRnh5gSTcfOT9fN15ZAIQmvMeKuHX06 tJRltK4lq9VFHENmEOmirfsPLEMEM5akyXz2Y= MIME-Version: 1.0 Received: by 10.216.158.21 with SMTP id p21mr1728200wek.99.1298049796456; Fri, 18 Feb 2011 09:23:16 -0800 (PST) Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 09:23:16 -0800 (PST) In-Reply-To: <4D5EAA7B.9020007@ops-netman.net> References: <4D5E9FC6.4020404@cisco.com> <20110218171154.GE15397@verdi> <4D5EAA7B.9020007@ops-netman.net> Date: Fri, 18 Feb 2011 12:23:16 -0500 Message-ID: From: Christopher Morrow To: Chris Morrow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org, sidr-chairs@ietf.org, Adrian Farrel , Russ White Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:22:45 -0000 (my originaly wouldn't have made it to the list... so here it is again from the right src-addr) On Fri, Feb 18, 2011 at 12:20 PM, Chris Morrow wro= te: > > > On 02/18/11 12:11, John Leslie wrote: >> Russ White wrote: >>> To: Christopher Morrow >>> >>>> * Is an Autonomous System (AS) authorized to originate an IP prefix >>>> * Is the AS-Path represented in the route the same as the path >>>> =A0 through which the route update traveled >>> >>> As we've been discussing on the list --I don't think this is a good >>> goal. The first goal should be to determine what it is we want to show >>> about the AS Path in relation to other things, and then work on filling >>> that goal. >> >> =A0 =A0The question I think we ought to care about is: >> >> Is the NLRI from this peer more or less likely than some other peer's NL= RI >> to represent what a legitimate originator would want me to see? >> >> =A0 =A0All I really have control over is which peer I send to (and thus >> which NLRI I forward to my peers). I have no control over what happens >> to the packets after than first forwarding step. > > we can't (and shouldn't conflate here) packet security with routing > (routing data, really) security. > From christopher.morrow@gmail.com Fri Feb 18 09:30:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D853A6F39; Fri, 18 Feb 2011 09:30:25 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9ELm8p7ODD5; Fri, 18 Feb 2011 09:30:24 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1A8E83A6F30; Fri, 18 Feb 2011 09:30:23 -0800 (PST) Received: by ewy8 with SMTP id 8so1834578ewy.31 for ; Fri, 18 Feb 2011 09:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mg8SBpjyVHCTF5crXMNHc/7AyK3hCb9TytdK/bGaSaU=; b=gc+vlifJYCmK+SslS37JcMfPQMKWKud75IQA5ZmjP5yXTVNAcij9r8VD+6jFFW3f1v xuwXEMGD9KN4pKlxYlVDSB7dSbTa0niVK+hnVchw3RwkioqWtPsYP74NjLRysNpLt60t bmkzNdOEM7Df3qomuLk60vexBzWfz+2BYc+Nw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Qk9mzr+b/pwp46HPGzvrD4qshm+OpUAVIP2g4TKRe04pJHIbVsD3eCnV9max1WTmT+ MVDDyzrBN0xOu97Ecqz8VGdLFgpXF6ur4aQX8WJwqm1jc/Gs2jNdk8Q5prJTkg1m/eLo INn5+AqsjbJ2WCUY/UxxZBaB4I+70O6vT18H4= MIME-Version: 1.0 Received: by 10.216.14.147 with SMTP id d19mr1737329wed.84.1298050257558; Fri, 18 Feb 2011 09:30:57 -0800 (PST) Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 09:30:57 -0800 (PST) In-Reply-To: <4D5E9FC6.4020404@cisco.com> References: <4D5E9FC6.4020404@cisco.com> Date: Fri, 18 Feb 2011 12:30:57 -0500 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:30:26 -0000 On Fri, Feb 18, 2011 at 11:35 AM, Russ White wrote: > >> =A0 =A0* Is an Autonomous System (AS) authorized to originate an IP pref= ix >> =A0 =A0* Is the AS-Path represented in the route the same as the path >> =A0 =A0 =A0 =A0 through which the route update traveled > > As we've been discussing on the list --I don't think this is a good > goal. The first goal should be to determine what it is we want to show 'this' refers to which of the two items above? > about the AS Path in relation to other things, and then work on filling > that goal. I thought I covered this (a few times?) on the list discussion of the reqs-00 draft, but I'd like to know if an update I see from a peer, if selected, is one in which a party altered the as-path in order to draw traffic to them. It's possible this happens for any number of reasons, the simplest (and easiest to point to being 'bad') is: In this case, with signing of the path at each path-hop you would be able to determine if the route announcement should be used or not (presuming a 'secure is better' policy, of course). > Starting with the assumption that proving an update travels a specific > path seems, to me, to be going about things the wrong way. propose text then? dancing around the rosemary bush is tiring, given the ideas expressed here and in the other thread you should have an idea of what the goal is, propose some text that you think moves the ball in the right direction, please. -chris From Sandra.Murphy@cobham.com Fri Feb 18 09:54:26 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D703A6D2B; Fri, 18 Feb 2011 09:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L6HpUA+IqDH; Fri, 18 Feb 2011 09:54:25 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8A7173A6CEA; Fri, 18 Feb 2011 09:54:25 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1IHsr4d025740; Fri, 18 Feb 2011 11:54:53 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1IHsr3Z025221; Fri, 18 Feb 2011 11:54:53 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.92]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Feb 2011 12:54:52 -0500 Date: Fri, 18 Feb 2011 12:54:52 -0500 (Eastern Standard Time) From: Sandra Murphy To: Russ White In-Reply-To: <4D5E9FC6.4020404@cisco.com> Message-ID: References: <4D5E9FC6.4020404@cisco.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Feb 2011 17:54:52.0995 (UTC) FILETIME=[F1DAD130:01CBCF94] Cc: sidr-chairs@ietf.org, Christopher Morrow , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 17:54:26 -0000 On Fri, 18 Feb 2011, Russ White wrote: > >> * Is an Autonomous System (AS) authorized to originate an IP prefix >> * Is the AS-Path represented in the route the same as the path >> through which the route update traveled > > As we've been discussing on the list --I don't think this is a good > goal. The first goal should be to determine what it is we want to show > about the AS Path in relation to other things, and then work on filling > that goal. > > Starting with the assumption that proving an update travels a specific > path seems, to me, to be going about things the wrong way. In my view of things, this is exactly the right way to do things. Anything else is baling wire holding some pieces together, not a solution. OK so here goes with the philosophy. Distributed protocols work because the sender and recipient are working with a common semantics of what the bits on the wire mean. The sender is supposed to set certain bits to represent some particular semantics. The recipient presumes that semantics when certain bits are set and makes decisions based on that semantics. In BGP, the semantics of the protocol are that the AS_PATH represents the AS's through with the update has traveled. This is the only reason why loop detection works. This is the reason that people make decisions based on AS_PATH length. (Yes, I know this is not the highest priority decision in the procedure, but it is something everyone uses and one of the few ways to attempt to have impact on the decision of an AS not a direct neighbor.) Munging around with the AS_PATH in ways not in the protocol makes things break. We could try to list every single one of those, and find a separate way of dealing with each new way to break things, but we would miss some, someone would think of something new, whatever. The point is to try to retain the semantics of the fields in the protocol. Suppose someone munged around with the AS_PATH so that loops were not detected. That would be a bad thing. You could invent a way to prevent that and just that. Suppose someone munged around with the AS_PATH so that it looked like there was a loop when there was not. That could be a bad thing (cue Kapela and Pilosov) You could invent a second way to prevent just that. Suppose someone made a path look shorter than it was. That could be a bad thing. You could invent a third way to prevent just that. Suppose someone inserted some unrelated AS into the AS_PATH to cause a link elsewhere to break. That would be a bad thing. (reference Steve Bellovin discussion of link-cutting attacks, cue NANOG's rant against one certain person's experiment) You could invent a fourth way to prevent just that. Suppose.... But maybe you get the idea. The fundamental problem (security geeks call this a "vulnerability") is that the AS_PATH is supposed to be constructed in a certain way, the recipients make decisions based on that assumption, and if it is possible to mess with that assumption, you've got problems. End philosophy. --Sandy > > :-) > > Russ > > > From schiller@uu.net Fri Feb 18 10:03:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15E023A6D48; Fri, 18 Feb 2011 10:03:24 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReUzXOWoppP7; Fri, 18 Feb 2011 10:03:22 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 9FFB53A6CF3; Fri, 18 Feb 2011 10:03:22 -0800 (PST) Received: from omzismtp03.vzbi.com ([unknown] [165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGT00H9RRDLGT40@firewall.verizonbusiness.com>; Fri, 18 Feb 2011 18:00:58 +0000 (GMT) Received: from omzismtp03.vzbi.com ([unknown] [127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGT00KIGRDLIO00@omzismtp03.vzbi.com>; Fri, 18 Feb 2011 18:00:57 +0000 (GMT) Received: from peermon.argfrp.us.uu.net ([unknown] [153.39.57.202]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGT00K2XRDKLS00@omzismtp03.vzbi.com>; Fri, 18 Feb 2011 18:00:57 +0000 (GMT) Date: Fri, 18 Feb 2011 13:00:56 -0500 (EST) From: Jason Schiller In-reply-to: X-X-Sender: schiller@peermon.argfrp.us.uu.net To: Christopher Morrow Message-id: Content-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1f69LSptww2O34GWkVstpw)" References: <4D5E9FC6.4020404@cisco.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) Cc: sidr@ietf.org, sidr-chairs@ietf.org, Adrian Farrel , Russ White Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:03:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_1f69LSptww2O34GWkVstpw) Content-id: Content-type: TEXT/PLAIN; CHARSET=ISO-8859-15 Content-transfer-encoding: QUOTED-PRINTABLE +1 |I thought I covered this (a few times?) on the list discussion of th= e |reqs-00 draft, but I'd like to know if an update I see from a peer, = if |selected, is one in which a party altered the as-path in order to dr= aw |traffic to them. It's possible this happens for any number of reason= s, |the simplest (and easiest to point to being 'bad') is: | | |In this case, with signing of the path at each path-hop you would be |able to determine if the route announcement should be used or not |(presuming a 'secure is better' policy, of course). In my opinion, origin validation only catches a small number of "bad"= =20 routing information. Additionally this "bad" routing information is= =20 typically the type created by fat fingering, and I would argue is the= =20 easiest to detect and get fixed. Anyone who is manipulating routing for nefarious purposes can avoid b= eing=20 caught by origin validation. These cases are more frequent, harder t= o =20 detect, and more difficult to get resolved. =20 If there is any value in securing inter-domain routing it has to vali= date=20 the AS path. __Jason =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Jason Schiller (703)886= .6648 Senior Internet Network Engineer fax:(703)886= .0512 Public IP Global Network Engineering schiller@u= u.net UUNET / Verizon jason.schiller@verizonbusines= s.com The good news about having an email address that is twice as long is = that it increases traffic on the Internet. On Fri, 18 Feb 2011, Christopher Morrow wrote: |Date: Fri, 18 Feb 2011 12:30:57 -0500 |From: Christopher Morrow |To: Russ White |Cc: sidr-chairs@ietf.org, Adrian Farrel , | sidr@ietf.org |Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validatio= n work | |On Fri, Feb 18, 2011 at 11:35 AM, Russ White wrote: |> |>> =A0 =A0* Is an Autonomous System (AS) authorized to originate an = IP prefix |>> =A0 =A0* Is the AS-Path represented in the route the same as the = path |>> =A0 =A0 =A0 =A0 through which the route update traveled |> |> As we've been discussing on the list --I don't think this is a goo= d |> goal. The first goal should be to determine what it is we want to = show | |'this' refers to which of the two items above? | |> about the AS Path in relation to other things, and then work on fi= lling |> that goal. | |I thought I covered this (a few times?) on the list discussion of th= e |reqs-00 draft, but I'd like to know if an update I see from a peer, = if |selected, is one in which a party altered the as-path in order to dr= aw |traffic to them. It's possible this happens for any number of reason= s, |the simplest (and easiest to point to being 'bad') is: | | |In this case, with signing of the path at each path-hop you would be |able to determine if the route announcement should be used or not |(presuming a 'secure is better' policy, of course). | |> Starting with the assumption that proving an update travels a spec= ific |> path seems, to me, to be going about things the wrong way. | |propose text then? dancing around the rosemary bush is tiring, given |the ideas expressed here and in the other thread you should have an |idea of what the goal is, propose some text that you think moves the |ball in the right direction, please. | |-chris |_______________________________________________ |sidr mailing list |sidr@ietf.org |https://www.ietf.org/mailman/listinfo/sidr | --Boundary_(ID_1f69LSptww2O34GWkVstpw)-- From russ@cisco.com Fri Feb 18 10:06:10 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507C23A6F32; Fri, 18 Feb 2011 10:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNUGXcS68sd9; Fri, 18 Feb 2011 10:06:09 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 50BAA3A6F2E; Fri, 18 Feb 2011 10:06:09 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF9DXk1AZnwN/2dsb2JhbACmJXOgCps0hV4EhQuHBoM6 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="asc'?scan'208";a="217058365" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2011 18:06:43 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1II6h6j022570; Fri, 18 Feb 2011 18:06:43 GMT Message-ID: <4D5EB53F.7080708@cisco.com> Date: Fri, 18 Feb 2011 13:06:55 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sandra Murphy References: <4D5E9FC6.4020404@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig318E48966A25FC50FD67840C" Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:06:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig318E48966A25FC50FD67840C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > In my view of things, this is exactly the right way to do things. > Anything else is baling wire holding some pieces together, not a soluti= on. The problem lies right here: > In BGP, the semantics of the protocol are that the AS_PATH represents > the AS's through with the update has traveled. No, it doesn't, really. Not in all cases. > The point is to try to retain the semantics of the fields in the protoc= ol. The point should be to find out what it is you're trying to secure, and then find a way to secure it. This _assumes_ the thing to secure is the current semantics of the protocol. But you're not addressing all the underlying assumptions that go with those semantics. > But maybe you get the idea. Suppose someone invented a way to prevent all of that without trying to verify what path an update followed? Let me ask you something --does IPsec try to verify the path the packet takes, or the contents of the packet? If the right solution for IPsec is to validate the content of the packet, then why is the right solution for BGP to verify the path of the packet? :-) Russ --------------enig318E48966A25FC50FD67840C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1etUEACgkQER27sUhU9OS7UQCeN9vPQdP9g+T1pglnkxzio6iA 4H8An1WhjF4s8Kx0nkww9Af3c7bEvRrt =JMYN -----END PGP SIGNATURE----- --------------enig318E48966A25FC50FD67840C-- From Sandra.Murphy@cobham.com Fri Feb 18 10:17:21 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914B43A6DF3; Fri, 18 Feb 2011 10:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7XdplUVGqhb; Fri, 18 Feb 2011 10:17:20 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9B05D3A6D36; Fri, 18 Feb 2011 10:17:20 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1IIHllN026206; Fri, 18 Feb 2011 12:17:47 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1IIHlgP026256; Fri, 18 Feb 2011 12:17:47 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.92]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Feb 2011 13:17:47 -0500 Date: Fri, 18 Feb 2011 13:17:46 -0500 (Eastern Standard Time) From: Sandra Murphy To: Russ White In-Reply-To: <4D5EB53F.7080708@cisco.com> Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Feb 2011 18:17:47.0422 (UTC) FILETIME=[2513BBE0:01CBCF98] Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:17:21 -0000 On Fri, 18 Feb 2011, Russ White wrote: > >> In my view of things, this is exactly the right way to do things. >> Anything else is baling wire holding some pieces together, not a solution. > > The problem lies right here: > >> In BGP, the semantics of the protocol are that the AS_PATH represents >> the AS's through with the update has traveled. > > No, it doesn't, really. Not in all cases. In the *protocol* this is true. Certainly people mess with configurations and implementations to get their own twisty features in, but in the protocol, that's what is supposed to happen. It is what the recipients rely on. > >> The point is to try to retain the semantics of the fields in the protocol. > > The point should be to find out what it is you're trying to secure, and > then find a way to secure it. This _assumes_ the thing to secure is the > current semantics of the protocol. > > But you're not addressing all the underlying assumptions that go with > those semantics. > >> But maybe you get the idea. > > Suppose someone invented a way to prevent all of that without trying to > verify what path an update followed? As I said, one could try to list all the ways of making bad things happen by exploiting the vulnerability (munging the semantics), but it would be hopeless. > > Let me ask you something --does IPsec try to verify the path the packet > takes, or the contents of the packet? If the right solution for IPsec is > to validate the content of the packet, then why is the right solution > for BGP to verify the path of the packet? The semantics of IP is that the source address is the host that sent the packet and the contents of the packet are as sent. Not much more. So that's what IPsec protects. That semantics. (Try to list all the bad things you can do by messing with IP packets and address each one.) The BGP protocol has a different semantics and so it has a different protection. --Sandy > > :-) > > Russ > > > From christopher.morrow@gmail.com Fri Feb 18 10:18:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB773A6DF3; Fri, 18 Feb 2011 10:18:39 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHugXm9sZ2wL; Fri, 18 Feb 2011 10:18:39 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id DB53E3A6D36; Fri, 18 Feb 2011 10:18:38 -0800 (PST) Received: by wyf23 with SMTP id 23so4204372wyf.31 for ; Fri, 18 Feb 2011 10:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UhMEs1o+C5lYLP8yvNcHFJCc0NebvSk3upcZwFq+zQ4=; b=j+CH5+2a2E7f48Bo15fJtpxQZzSoRcvpFM/NGqFHhDyOI9kJLomxjIvfzQd3Udk0/f yWnwawdo3YGjOO6d69fhae78ujhKouGfWufrRkyohDeyAT/eUoTRZs9pgobAKyAgkkrq te0noFl3H8nnWNo+9B7FNbpkgtk5D3Y/IsSQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kBuLTqZWH13QYe+EL8yIHBWvGthxCxA1jxqmq7DGzvGPjMupQvmiXH15ki46WEn3yw /kNHcGRi7ko3t4kSX9TUB65VIUZ2zEX1rAxM/0K6YkM04MzHY0R4KIYVao+YeAw94o46 ft8T8bIC02V/AN7sMEFXlgWlC+OrJNDEZhOMQ= MIME-Version: 1.0 Received: by 10.216.18.204 with SMTP id l54mr875775wel.99.1298053152297; Fri, 18 Feb 2011 10:19:12 -0800 (PST) Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 10:19:12 -0800 (PST) In-Reply-To: <4D5EB53F.7080708@cisco.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> Date: Fri, 18 Feb 2011 13:19:12 -0500 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:18:40 -0000 On Fri, Feb 18, 2011 at 1:06 PM, Russ White wrote: > Let me ask you something --does IPsec try to verify the path the packet > takes, or the contents of the packet? If the right solution for IPsec is > to validate the content of the packet, then why is the right solution > for BGP to verify the path of the packet? because with ipsec the content inside the encrypted payload (or even the content after the AH header) is not intended to be played with by anyone along the path. Detection of bit flippage in the packet is the point of ipsec. BGP requires that folk along the path adjust metrics, communities, localpref (inside their ASNs) etc. It's not appropriate to 'secure the whole of the update' since that can not be done. -chris From russ@cisco.com Fri Feb 18 10:27:33 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474DA3A6DA0; Fri, 18 Feb 2011 10:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2tVbh7AL7Ho; Fri, 18 Feb 2011 10:27:32 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3BB613A6D36; Fri, 18 Feb 2011 10:27:32 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADpJXk1AZnwN/2dsb2JhbACmJXOfbps1hV4EhQuHBoM6 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="asc'?scan'208";a="217064409" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2011 18:28:06 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1IIS5fI027824; Fri, 18 Feb 2011 18:28:06 GMT Message-ID: <4D5EBA41.1040801@cisco.com> Date: Fri, 18 Feb 2011 13:28:17 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sandra Murphy References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA1CDE4BFFC4BFEF123DB7846" Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:27:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA1CDE4BFFC4BFEF123DB7846 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> Suppose someone invented a way to prevent all of that without trying t= o >> verify what path an update followed? >=20 > As I said, one could try to list all the ways of making bad things > happen by exploiting the vulnerability (munging the semantics), but it > would be hopeless. Suppose you listed all the problems, and we found one way to resolve all of them without the underlying assumption that the only way to solve the problem is to prove the path the update took. >> Let me ask you something --does IPsec try to verify the path the packe= t >> takes, or the contents of the packet? If the right solution for IPsec = is >> to validate the content of the packet, then why is the right solution >> for BGP to verify the path of the packet? >=20 > The semantics of IP is that the source address is the host that sent th= e > packet and the contents of the packet are as sent. >=20 > Not much more. Huh? Then why is there anything such as ESP? Shouldn't we only care about the packet header, and just leave the rest of the packet unencrypte= d? No, IPsec encrypts, and protects, _much_ more than the "protocol semantic= s." :-) Russ --------------enigA1CDE4BFFC4BFEF123DB7846 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1eukQACgkQER27sUhU9OQWKwCggudCTTqOmLYML9PDXBTeydmp GvIAoNmfNTDt2EgEiPduUK2iGnvO+VqJ =2C/Y -----END PGP SIGNATURE----- --------------enigA1CDE4BFFC4BFEF123DB7846-- From russ@cisco.com Fri Feb 18 10:31:05 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD413A6DA0; Fri, 18 Feb 2011 10:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7oByAWoYtxw; Fri, 18 Feb 2011 10:31:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 644313A6D6A; Fri, 18 Feb 2011 10:31:04 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACtKXk1AZnwN/2dsb2JhbACmJXOfeZs1hV4EhQuHBoM6 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="asc'?scan'208";a="217270856" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 18:31:38 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1IIVcND028863; Fri, 18 Feb 2011 18:31:38 GMT Message-ID: <4D5EBB18.1070401@cisco.com> Date: Fri, 18 Feb 2011 13:31:52 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1F37B2EB779A8F88467F281F" Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:31:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1F37B2EB779A8F88467F281F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > because with ipsec the content inside the encrypted payload (or even > the content after the AH header) is not intended to be played with by > anyone along the path. Detection of bit flippage in the packet is the > point of ipsec. >=20 > BGP requires that folk along the path adjust metrics, communities, > localpref (inside their ASNs) etc. It's not appropriate to 'secure the > whole of the update' since that can not be done. But you're missing the point. Sandy said, "all we're trying to do is secure the existing protocol semantics." As Sandy herself said, the only "semantics" in IP are things that are contained within the header. So why not just secure the header. So the "securing the semantics" argument won't fly. Tell me what you want to secure, not how you intend to secure it. If the charter says, "we want to prove an update followed the AS Path listed in the update," then I will ask why we shouldn't prove the rest of the semantics, as well --who added what communities, who removed communities, and were they authorized to do so; who changed the next hop, and is the next hop really the correct and authorized one; etc. --these are all part of the "semantics" of BGP, as well. If you're going to say, "secure the semantics," then secure all of them. If you're going to say, "secure the data," then figure out what matters in terms of how the data looks, and secure that. :-) Russ --------------enig1F37B2EB779A8F88467F281F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1euxgACgkQER27sUhU9ORSngCgipaNaBUaCuB+8g77UjRzjK8B rycAn093zcceFycWWhWM8122mTEzZ9S9 =BJ7d -----END PGP SIGNATURE----- --------------enig1F37B2EB779A8F88467F281F-- From christopher.morrow@gmail.com Fri Feb 18 10:34:27 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977343A6DA0; Fri, 18 Feb 2011 10:34:27 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouVvDDMFNUbS; Fri, 18 Feb 2011 10:34:26 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 63FB53A6DDA; Fri, 18 Feb 2011 10:34:26 -0800 (PST) Received: by wyf23 with SMTP id 23so4222672wyf.31 for ; Fri, 18 Feb 2011 10:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RY5GIbGCMEIoF0xaypf+lquFUuvNQjLMXVLI/Uj+asA=; b=aIdMm7fd4EtsufHLvjbKCqZImHybZIE0c3rbNWvw1h32HkJ+IJ9P0J2ylSQLtZcr9J y5LnSA84uKyEbNAEOJEgJ2TNBE/MA0ao955mlE8KcmCeoBBTm8ycszggI8ufp2EwaiS4 eb3GwiKgQtZ+czz5lr4RIL0kbVChwyjTvi/j0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=h7Vv8hWt6B1V24oDPn1B4h5SuyW/KpMuV291WecL1Z9zy7td8PZGWIj3+K6Jeg7q0G Id9hMjhR3T2tJBmdSl7pvUV44GcjX51gmPtYo+r6kvbfBbW0vf1epfuGN8WVbr9d3kzf xz9BDYhGh9e0dTddkkFZJt0a/WNGeUNu6nVzw= MIME-Version: 1.0 Received: by 10.216.14.147 with SMTP id d19mr1799574wed.84.1298054099177; Fri, 18 Feb 2011 10:34:59 -0800 (PST) Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 10:34:59 -0800 (PST) In-Reply-To: <4D5EBB18.1070401@cisco.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> Date: Fri, 18 Feb 2011 13:34:59 -0500 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:34:27 -0000 On Fri, Feb 18, 2011 at 1:31 PM, Russ White wrote: > If you're going to say, "secure the semantics," then secure all of them. > If you're going to say, "secure the data," then figure out what matters > in terms of how the data looks, and secure that. what matters: AS-PATH how it looks: every AS which sees this route, and propogates it to external peers, attests to that fact. From christopher.morrow@gmail.com Fri Feb 18 10:49:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875493A6DF3 for ; Fri, 18 Feb 2011 10:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjHw+ALiB+56 for ; Fri, 18 Feb 2011 10:49:29 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 828453A6D6A for ; Fri, 18 Feb 2011 10:49:29 -0800 (PST) Received: by wyf23 with SMTP id 23so4237525wyf.31 for ; Fri, 18 Feb 2011 10:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wUcSwAB98k+ge8BZ1w9bUMRJZRQWXKjEdwnSm5e/moY=; b=jRz7yCABT12kszY5gFHL7Db4n0nmy8iyY4h2ciuzxoFGq5IfHge3mqDK523YwzpRVv 2N+ezQS029ky1heqSlhdCuWSt7wz3jFGefuj2SkjT+4mL0iIduhexDmGNKXUYqrc8ztg CekqJzchIUyiyddE7GUwB9SWwwnyvnPx/ZwNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=AeE2m3U0taMIOiv+XLxCXAuuSzF8vO00xtXDJ3wiUWEu69UWsrbkd9IC5HuzV2VHGP SdikoYlQ9G+QmhTNdCN/5GQchpG+B1mG0jndyY6vg0bKTcQau4pq1KRaeGkS87vp6vEa Aem+03+F9y9i7PD77/xZDcTYs6t/Di65B5aVc= MIME-Version: 1.0 Received: by 10.216.179.133 with SMTP id h5mr1832518wem.69.1298055001741; Fri, 18 Feb 2011 10:50:01 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 10:50:01 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Feb 2011 13:50:01 -0500 X-Google-Sender-Auth: Z5PVk8CUgwWJudPr2YotYXcsROI Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr Subject: Re: [sidr] new draft draft-manderson-sidr-geo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:49:30 -0000 On Mon, Feb 7, 2011 at 8:46 PM, Terry Manderson wrote: > All, > > I have uploaded a new draft at > http://www.ietf.org/id/draft-manderson-sidr-geo-00.txt > > The co-authors and I would appreciate your review and feedback. I expect to > be able to present this document in Prague and ask for WG adoption at that > stage. some feedback from the group here would be helpful: o does this content help/hurt/etc SIDR work? o does the content advance SIDR's goals? Could we discuss this on-list prior the meeting in Prague please? (less excitement in the in-person meeting) (I'll take a stab at reading/commenting separately) -chris From russ@cisco.com Fri Feb 18 11:20:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A7C3A6E51; Fri, 18 Feb 2011 11:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.22 X-Spam-Level: X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4r3BHCQpzyn; Fri, 18 Feb 2011 11:20:55 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 246FC3A6E27; Fri, 18 Feb 2011 11:20:55 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAONVXk1AZnwM/2dsb2JhbACmJnOfZpszhV4EhQuHBoM6 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="asc'?scan'208";a="217287256" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 19:21:29 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1IJLSc3010526; Fri, 18 Feb 2011 19:21:28 GMT Message-ID: <4D5EC6C4.5070809@cisco.com> Date: Fri, 18 Feb 2011 14:21:40 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB03B23EFB119A9223742900" Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:20:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB03B23EFB119A9223742900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > what matters: AS-PATH > how it looks: every AS which sees this route, and propogates it to > external peers, attests to that fact. Wrong. As someone who has been long involved in the writing of BGP specs, and someone who has worked, for a long time, on BGP, I can tell you that the "semantic of BGP" has never been that the AS Path is used for anything other than determining if the path is loop free. Anyone who tells you that the "BGP semantic" is that the update has traversed the path shown in the AS Path attribute simply doesn't understand BGP. A few examples showing this simply isn't the case. 1. Private AS Stripping. At certain edges, a provider may peer with an organization that does not have an AS number. In these cases, the peering organization may use a private AS Number, which is then stripped by the upstream. In all such cases, the AS Path does not --by intention-- represent the "path of the update." 2. Local AS No Prepend. In some situations, it's useful (and good) to send an update that has another AS in the path than the AS number you're peering on. This occurs, for instance, in L3VPNs, and when providers are merging two different AS numbers. If this were a real "threat" to BGP and it's operation, then this feature wouldn't have been built by any vendors --but it was created, at the request of service providers (some of whom are now arguing that the AS Path is somehow untouchable). 3. Confederations. In the case where an organization decides to break their network up into multiple administrative domains, or to combine multiple administrative domains, several autonomous systems --with public, routable AS numbers-- may be configured into a confederation. In this case, the AS Path continues to have the AS numbers through which the update passes added to the attribute. The "additional" AS numbers are stripped off at the opposite edge of the confederation. Once again, the AS Path is not anything special here, it's just another attribute, and it certainly does not represent the path the update takes through the network. 4. Wide AS'. According to RFC4893, the way in which BGP will migrate from narrow AS numbers to wide AS numbers is: For any speaker that peers with a speaker in an AS that doesn't support wide numbers, place the AS path in a community, and place a "holder" AS number in the AS Path. When receiving an update with a community containing portions of the AS Path, move these portions back into the AS Path proper. Again, the AS Path is not seen as something that "cannot be touched or changed," but rather a simple attribute designed to show one specific thing --loop freeness. There is no concept here of the AS Path showing the route the update itself, took. 5. AS Sets. If a speaker aggregates a group of NLRIs into a single advertisement, the speaker can/should build an AS Set to indicate the group of AS' from which the NLRIs represented in the aggregate were collected. Again, the AS Path doesn't have anything to do with "the path the update took through the network." I could go on giving examples, but to state, "BGP's semantic is that the AS Path represents the path through which the update has traveled," is simply untrue. :-) Russ --------------enigFB03B23EFB119A9223742900 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1exscACgkQER27sUhU9OTXpwCg3Dpf3obmEtxj9LfgeDhL6vSU XUYAoIzECVsRpIARiDMQcfL6U33XyZmK =91NZ -----END PGP SIGNATURE----- --------------enigFB03B23EFB119A9223742900-- From russ@cisco.com Fri Feb 18 11:22:23 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300AA3A6E51; Fri, 18 Feb 2011 11:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.505 X-Spam-Level: X-Spam-Status: No, score=-10.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlgGNu22hXy3; Fri, 18 Feb 2011 11:22:22 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 38CA53A6A0F; Fri, 18 Feb 2011 11:22:22 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAONVXk1AZnwN/2dsb2JhbACmJnOfZpszhV4EhQuHBoM6 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="asc'?scan'208";a="217288324" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 19:22:56 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1IJMuGn014459; Fri, 18 Feb 2011 19:22:56 GMT Message-ID: <4D5EC71E.7080706@cisco.com> Date: Fri, 18 Feb 2011 14:23:10 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" References: <9686.1298054916@x37.NIC.DTAG.DE> In-Reply-To: <9686.1298054916@x37.NIC.DTAG.DE> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCAEFA50780A829A7592F9B7F" Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:22:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCAEFA50780A829A7592F9B7F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I think the short name of the 2nd bullet is simply "authenticity of the= AS path > attribute". Having authentic AS path information seems to provide ever= ybody > with a sound base to do whatever they want to do as their policies - an= d=20 > certainly also general use rules. 1. That's not what the second bullet actually says. 2. Define what you mean when you say, "an authentic AS Path." :-) Russ --------------enigCAEFA50780A829A7592F9B7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1exx4ACgkQER27sUhU9OT2lgCgmP/HGb3NKLaYsBDOS3RIz6vo JhQAoJ3uY06qIVh7rfow6i65RGNhczkI =Deoj -----END PGP SIGNATURE----- --------------enigCAEFA50780A829A7592F9B7F-- From christopher.morrow@gmail.com Fri Feb 18 11:48:38 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E20A3A6FBF; Fri, 18 Feb 2011 11:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwHgu+m3hGp8; Fri, 18 Feb 2011 11:48:37 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 879EA3A6D16; Fri, 18 Feb 2011 11:48:32 -0800 (PST) Received: by wyf23 with SMTP id 23so4296653wyf.31 for ; Fri, 18 Feb 2011 11:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Mo9rgNPrvTF4NpzJHd517M3h/+/sGOU8N+BCpSpuHpo=; b=SeSDW5/q9OqjD5aBHTdeGuKpGdSLm0/LF8HO6IBaDjsCP42x+q9glCnzelB11lKZMz ZG7kaHKJpFr5gKZCyX6Oz9Q8wDTCKzcLP7DGwo/YBsFROAG8FBGZECWh7LNaORWbZxiX HHT2eVbOO6NrlsPUJJAPMR+rLODWQ9H3jEDtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GGwZGhEVE1MhWtVu04S2WKPq4Gx9RL8UGBZ4jdOf+DCubpvz9zY6SeX1HvvKPymgmI 7CImOzrxtULT0pDmnGwgX10fTx9ePTWtie6cgeTrTXmWV8AY6wUKrEG6upI2YMTvHZ9z mVe/Pvopaxihti6CPuwKktfytjN5Vl0EphYxw= MIME-Version: 1.0 Received: by 10.216.158.21 with SMTP id p21mr1874952wek.99.1298058546152; Fri, 18 Feb 2011 11:49:06 -0800 (PST) Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 11:49:06 -0800 (PST) In-Reply-To: <4D5EC6C4.5070809@cisco.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> Date: Fri, 18 Feb 2011 14:49:06 -0500 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:48:38 -0000 On Fri, Feb 18, 2011 at 2:21 PM, Russ White wrote: > >> what matters: AS-PATH >> how it looks: every AS which sees this route, and propogates it to >> external peers, attests to that fact. > > Wrong. As someone who has been long involved in the writing of BGP > specs, and someone who has worked, for a long time, on BGP, I can tell > you that the "semantic of BGP" has never been that the AS Path is used > for anything other than determining if the path is loop free. Anyone who i wasn't claiming anything about bgp semantics, that was sandy. I didn't disagree with her, but it wasn't central to my message. You clipped out the part of the message I replied to, which was only related to your response: " If you're going to say, "secure the semantics," then secure all of them. If you're going to say, "secure the data," then figure out what matters in terms of how the data looks, and secure that." > tells you that the "BGP semantic" is that the update has traversed the > path shown in the AS Path attribute simply doesn't understand BGP. > > A few examples showing this simply isn't the case. > > 1. Private AS Stripping. At certain edges, a provider may peer with an > organization that does not have an AS number. In these cases, the > peering organization may use a private AS Number, which is then stripped > by the upstream. In all such cases, the AS Path does not --by > intention-- represent the "path of the update." for origin validation (not this conversation, but...) the ISP here would have a ROA issued by the address-owner... so this isn't a problem. The as-path is still a clear indicator here, since the customer is a leaf... the fact that their ASN doesnt show up isn't a problem, especially since the roa/origin-validation would nicely tell us that the ASN we do so as the first (right-most) element is "ok". > 2. Local AS No Prepend. In some situations, it's useful (and good) to > send an update that has another AS in the path than the AS number you're > peering on. This occurs, for instance, in L3VPNs, and when providers are > merging two different AS numbers. If this were a real "threat" to BGP > and it's operation, then this feature wouldn't have been built by any > vendors --but it was created, at the request of service providers (some > of whom are now arguing that the AS Path is somehow untouchable). again, not a problem, presumably the AS stamped in the path is signed by the ASN Owner, whether they say: "X" but are really "Y" isn't a concern, they still have (in a possible endtime) cert issued down a tree we can validate. They are still attesting to the fact that they saw and passed along the route announcement in question. (see the second half of the sentence you are responding to here) (for all intents and purposes this looks like your next point, confeds) > > 3. Confederations. In the case where an organization decides to break > their network up into multiple administrative domains, or to combine > multiple administrative domains, several autonomous systems --with > public, routable AS numbers-- may be configured into a confederation. In (it's not required that the asn's in a confed be "public routable", routable doesn't mean anything either here, ASNs... this is a redherring though) > this case, the AS Path continues to have the AS numbers through which > the update passes added to the attribute. The "additional" AS numbers > are stripped off at the opposite edge of the confederation. Once again, > the AS Path is not anything special here, it's just another attribute, > and it certainly does not represent the path the update takes through > the network. sure, and again, on exit the autonomous system (with the distinct routing policy and administrative domain) stamps it saying: "Yup, was here." they attest to this (again in my endtime of choice) in a manner I can validate. (see the second half of the sentence you are responding to here) > 4. Wide AS'. According to RFC4893, the way in which BGP will migrate > from narrow AS numbers to wide AS numbers is: For any speaker that peers > with a speaker in an AS that doesn't support wide numbers, place the AS > path in a community, and place a "holder" AS number in the AS Path. When > receiving an update with a community containing portions of the AS Path, > move these portions back into the AS Path proper. Again, the AS Path is > not seen as something that "cannot be touched or changed," but rather a > simple attribute designed to show one specific thing --loop freeness. > There is no concept here of the AS Path showing the route the update > itself, took. yup, this issue we have talked about some, I don't recall the details, someone should think about this more... but again: "I saw this route, I am passing it along" is really what matters. (see the second half of the sentence you are responding to here) > 5. AS Sets. If a speaker aggregates a group of NLRIs into a single > advertisement, the speaker can/should build an AS Set to indicate the > group of AS' from which the NLRIs represented in the aggregate were > collected. Again, the AS Path doesn't have anything to do with "the path > the update took through the network." and because AS-Sets are opaque when it comes to security semantics (which asn in the set is responsible for what part of the aggregate?) they are excluded from the discussion, and on the road to deprecation. > I could go on giving examples, but to state, "BGP's semantic is that the > AS Path represents the path through which the update has traveled," is > simply untrue. eh... but it is. one more time around the mulberry bush? -chris > :-) > > Russ > > From russ@cisco.com Fri Feb 18 12:13:47 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7E33A6FCA; Fri, 18 Feb 2011 12:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlfLeV5KFJRl; Fri, 18 Feb 2011 12:13:47 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D5A143A6F46; Fri, 18 Feb 2011 12:13:46 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJthXk1AZnwM/2dsb2JhbACmKXOfXJs2hV4EhQuHBoM6 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="asc'?scan'208";a="217364568" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 20:14:20 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1IKEKZ9029776; Fri, 18 Feb 2011 20:14:20 GMT Message-ID: <4D5ED326.8030608@cisco.com> Date: Fri, 18 Feb 2011 15:14:30 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCCDA51FA0254D0F2F815E107" Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:13:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCCDA51FA0254D0F2F815E107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > and because AS-Sets are opaque when it comes to security semantics > (which asn in the set is responsible for what part of the aggregate?) > they are excluded from the discussion, and on the road to deprecation. The point wasn't to say, "can each of these be solved," it was to say, "the AS Path wasn't designed to bear the weight you're putting on it." >> I could go on giving examples, but to state, "BGP's semantic is that t= he >> AS Path represents the path through which the update has traveled," is= >> simply untrue. >=20 > eh... but it is. one more time around the mulberry bush? It's not. The AS Path is to prove the path is loop free. It was never intended to prove where the update went in the network. :-) Russ --------------enigCCDA51FA0254D0F2F815E107 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1e0yoACgkQER27sUhU9OTO7QCfU0MNkeXXBKq3E0Ngd7MAdRWa l+kAn2Kml8OKt9CXNdsNOAXoFRkULVGO =9t0K -----END PGP SIGNATURE----- --------------enigCCDA51FA0254D0F2F815E107-- From christopher.morrow@gmail.com Fri Feb 18 12:18:57 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2850A3A6F9B; Fri, 18 Feb 2011 12:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ppo9DVBKaIh; Fri, 18 Feb 2011 12:18:56 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1AFB93A6F7F; Fri, 18 Feb 2011 12:18:55 -0800 (PST) Received: by wyf23 with SMTP id 23so4329179wyf.31 for ; Fri, 18 Feb 2011 12:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XirnK3xPPzZzD0+5/5Y4RLO4xPFmEgAAAsNN8/3qMFI=; b=QL0x9TqMu0IleClLLJhyiTF+wbTFodfcV1UlrHH4ANurbGiMcRkcKEEKz9FgzmHK0c cEwHbBLuI3tVOKTCsqfyyzYFrQDd4q5kOlXbMOrSItMxeQKBni78wFxPeH+B+/0hdtuK V5kPrQp1X/JqzA0k1/KHWoXbtran/4B8+vThk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OveiSwHFtPcsrTUQ7dcMQapRJvs7DV41oGsMIecVRylosY7KTJt/6g6MHixT1Eq6Us WXrG5jx2V9fa9qMYpPdb3nB9XFnETMlOO+aKay8oRukmTQa8dsMCXg7EoVEmnK9LC+Ny NeZfeSVvLqHNyUtfHTZjrXpP4vtvWFACQkpQ4= MIME-Version: 1.0 Received: by 10.216.154.136 with SMTP id h8mr991500wek.84.1298060369408; Fri, 18 Feb 2011 12:19:29 -0800 (PST) Received: by 10.216.1.197 with HTTP; Fri, 18 Feb 2011 12:19:29 -0800 (PST) In-Reply-To: <4D5ED326.8030608@cisco.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> Date: Fri, 18 Feb 2011 15:19:29 -0500 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:18:57 -0000 On Fri, Feb 18, 2011 at 3:14 PM, Russ White wrote: > >>> I could go on giving examples, but to state, "BGP's semantic is that the >>> AS Path represents the path through which the update has traveled," is >>> simply untrue. >> >> eh... but it is. one more time around the mulberry bush? > > It's not. The AS Path is to prove the path is loop free. It was never > intended to prove where the update went in the network. ok, so what other tool do we have today that does this? (can tell us that an path is not fictitious) From russ@cisco.com Fri Feb 18 12:22:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABC73A6F18; Fri, 18 Feb 2011 12:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0kTFlU9ae3i; Fri, 18 Feb 2011 12:22:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BE2C13A6DF1; Fri, 18 Feb 2011 12:22:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPNjXk1AZnwN/2dsb2JhbACmKXOfXJs2hV4EhQuHBoM6 X-IronPort-AV: E=Sophos;i="4.62,189,1297036800"; d="asc'?scan'208";a="217375475" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 20:22:52 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1IKMqw5006437; Fri, 18 Feb 2011 20:22:52 GMT Message-ID: <4D5ED525.8090303@cisco.com> Date: Fri, 18 Feb 2011 15:23:01 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christopher Morrow References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B48C7DB195E407C539B08DF" Cc: sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:22:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B48C7DB195E407C539B08DF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> It's not. The AS Path is to prove the path is loop free. It was never >> intended to prove where the update went in the network. >=20 > ok, so what other tool do we have today that does this? (can tell us > that an path is not fictitious) There never was a tool intended to solve that problem --from a routing perspective, it doesn't matter where I get the information from, only that the path is actually loop free. BGP cares about policy as well, but only the policy between me and my peer, never a peer several hops away. Let me ask this --do you care if you get the certificate showing AS x is able to originate prefix y from a server in AS x, or off a web site someplace? Or are you more concerned about the certificates/etc being right --that the information is true? :-) Russ --------------enig4B48C7DB195E407C539B08DF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1e1SoACgkQER27sUhU9OThQACcDQQPNWQ8StuaM84xQYeBZHB0 vsgAn1YJeWOREH4zImz8IvMsGwpB5HVq =mIAe -----END PGP SIGNATURE----- --------------enig4B48C7DB195E407C539B08DF-- From rbarnes@bbn.com Fri Feb 18 12:22:43 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414273A6FD6 for ; Fri, 18 Feb 2011 12:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlAJyp8QuUyE for ; Fri, 18 Feb 2011 12:22:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 848DB3A6DF1 for ; Fri, 18 Feb 2011 12:22:41 -0800 (PST) Received: from [192.1.255.181] (port=55283 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PqWrC-000FBb-Fv; Fri, 18 Feb 2011 15:23:14 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 18 Feb 2011 15:23:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9A36A925-4FC0-49B6-9C5A-B99B44C36C15@bbn.com> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: sidr Subject: Re: [sidr] new draft draft-manderson-sidr-geo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:22:43 -0000 Chris, IMO, co-authors may think differently:=20 This draft is a little to the side of the main SIDR objectives. It's = not of direct use for adding security to routing. It's more like the = ghostbusters draft in that it uses RPKI signatures to associate metadata = to routing information. The main reason we thought it was appropriate = for SIDR (as opposed to GEOPRIV, the other obvious candidate) was that = this group has the expertise in evaluating proposed formats for objects = signed under the RPKI. --Richard On Feb 18, 2011, at 1:50 PM, Christopher Morrow wrote: > On Mon, Feb 7, 2011 at 8:46 PM, Terry Manderson > wrote: >> All, >>=20 >> I have uploaded a new draft at >> http://www.ietf.org/id/draft-manderson-sidr-geo-00.txt >>=20 >> The co-authors and I would appreciate your review and feedback. I = expect to >> be able to present this document in Prague and ask for WG adoption at = that >> stage. >=20 > > some feedback from the group here would be helpful: >=20 > o does this content help/hurt/etc SIDR work? > o does the content advance SIDR's goals? >=20 > Could we discuss this on-list prior the meeting in Prague please? > (less excitement in the in-person meeting) >=20 > (I'll take a stab at reading/commenting separately) > -chris > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From john@jlc.net Fri Feb 18 12:28:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7503A6F18 for ; Fri, 18 Feb 2011 12:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.763 X-Spam-Level: X-Spam-Status: No, score=-106.763 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBsuyxPReuwP for ; Fri, 18 Feb 2011 12:28:15 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id C68C53A6DF1 for ; Fri, 18 Feb 2011 12:28:15 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7529533C24; Fri, 18 Feb 2011 15:28:50 -0500 (EST) Date: Fri, 18 Feb 2011 15:28:50 -0500 From: John Leslie To: sidr@ietf.org Message-ID: <20110218202850.GG15397@verdi> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4D5ED326.8030608@cisco.com> User-Agent: Mutt/1.4.1i Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:28:16 -0000 Russ White wrote: > [Christopher Morrow wrote:] >> [Russ White wrote:] >=20 >>> I could go on giving examples, but to state, "BGP's semantic is that the >>> AS Path represents the path through which the update has traveled," is >>> simply untrue. >>=20 >> eh... but it is. one more time around the mulberry bush? >=20 > It's not. The AS Path is to prove the path is loop free. It was never > intended to prove where the update went in the network. Please try to excuse me for interrupting a perfectly good flame-war... IMHO, Russ is being careful in what he says, but Chris isn't. The plain fact is, Chris made a perfectly reasonable post: "=20 " On Fri, Feb 18, 2011 at 1:31 PM, Russ White wrote: " "> If you're going to say, "secure the semantics," then secure all of them. "> If you're going to say, "secure the data," then figure out what matters "> in terms of how the data looks, and secure that. "=20 " what matters: AS-PATH " how it looks: every AS which sees this route, and propogates it to " external peers, attests to that fact. ... alas, not being as careful as I would wish about what he wrote... I interpreted to be in response to the last two lines of Russ, and say: "=20 " What matters is the AS_PATH; it gives us every AS which sees this NLRI; " propagating it to external peers attests to this fact already. He did not say anything about how to validate that so as to place confidence in the AS_PATH for loop detection, least of all some of the other things we're looking for. Thus, I decided against responding to it right away, hoping somebody would lead the discussion in that direction... -- John Leslie From rv@x37.NIC.DTAG.DE Fri Feb 18 10:48:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8627F3A6D6A; Fri, 18 Feb 2011 10:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt7vajOJqpK8; Fri, 18 Feb 2011 10:48:15 -0800 (PST) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by core3.amsl.com (Postfix) with ESMTP id 1D9D93A6D60; Fri, 18 Feb 2011 10:48:14 -0800 (PST) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id TAA03075; Fri, 18 Feb 2011 19:48:33 +0100 (MET) To: Russ White From: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" In-Reply-To: Your message of "Fri, 18 Feb 2011 11:35:18 EST." <4D5E9FC6.4020404@cisco.com> Date: Fri, 18 Feb 2011 19:48:36 +0100 Message-ID: <9686.1298054916@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:37:31 -0000 Russ wrote > > * Is an Autonomous System (AS) authorized to originate an IP prefix > > * Is the AS-Path represented in the route the same as the path > > through which the route update traveled > > As we've been discussing on the list --I don't think this is a good > goal. The first goal should be to determine what it is we want to show > about the AS Path in relation to other things, and then work on filling > that goal. > > Starting with the assumption that proving an update travels a specific > path seems, to me, to be going about things the wrong way. oh! the second bullet seems like a perfect starting point! (and questioning the first would seem to consider rolling back the ROA work8-O) I think the short name of the 2nd bullet is simply "authenticity of the AS path attribute". Having authentic AS path information seems to provide everybody with a sound base to do whatever they want to do as their policies - and certainly also general use rules. I have trouble to believe that less than "authentic AS path info" will serve us well enough, and doing less would mean that we dilute and messup the security mechanism by some implied policies. You are welcome to suggest relations and context that help defining useful policies to evaluate with authentic AS path info (whether as general rules or for private policy definitions). Starting to look into "context" assuming and targeting that less than authentic AS path should be sufficient would seem to me like heading for rat holes... > :-) > > Russ Ruediger From oliver.borchert@nist.gov Fri Feb 18 15:11:11 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CBFE3A6CF5 for ; Fri, 18 Feb 2011 15:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.745 X-Spam-Level: X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=1.854, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIlvJ8J1URNW for ; Fri, 18 Feb 2011 15:11:06 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 0DABC3A6DA8 for ; Fri, 18 Feb 2011 15:11:05 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p1INBWRt001907 for ; Fri, 18 Feb 2011 18:11:32 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 18 Feb 2011 18:11:25 -0500 From: "Borchert, Oliver" To: "sidr@ietf.org" Date: Fri, 18 Feb 2011 18:11:24 -0500 Thread-Topic: Behavior of entities talking RPKI-Router protocol Thread-Index: AcvPwSmWE5hEM2e+Qqm1QCLCQytZNA== Message-ID: 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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: oliver.borchert@nist.gov Subject: [sidr] Behavior of entities talking RPKI-Router protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 23:11:11 -0000 While working on an implementation of the rpki-rtr protocol, some questions came up that could not be clarified using the specification draft. (A) Unexpected withdrawal of white list (WL) entries. (i) What is the routers expected behavior when it receives a withdrawal of a white list (WL) entry that does not exist? (ii) Should the router respond to (A.i) by sending a "Reset Query" or should router silently ignore such information and if so, why? (B) The RPKI Validation cache may contain ROA's whose Prefix/Origin content is identical. An example could be a ROA that is about to expire and the "follow up" ROA is generated in advance to prevent a down time. During a short period of time both would certify the Prefix/Origin content. (i) Should the server send a WL announcement for each instance or should the server reduce the information to a single WL announcement? In other words should the router see the announcement of the new one followed by the withdrawal of the old one? (ii) In case the cache sends a WL announcement for each corresponding ROA entry can we expect the cache also to sends a WL withdrawal for each expired/revoked ROA? Thanks, Oliver ---------------------------------------------------------------------------- Oliver Borchert - Computer Scientist National Institute of Standards and Technology United States Department of Commerce phone: 301-975-4856, fax: 301-975-6238 From randy@psg.com Fri Feb 18 16:34:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782CD3A6EC0 for ; Fri, 18 Feb 2011 16:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxrRrtUlW+si for ; Fri, 18 Feb 2011 16:34:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 90FBC3A6E3D for ; Fri, 18 Feb 2011 16:34:46 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pqan5-000FOe-CY; Sat, 19 Feb 2011 00:35:15 +0000 Date: Sat, 19 Feb 2011 08:35:15 +0800 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr Subject: Re: [sidr] new draft draft-manderson-sidr-geo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 00:34:48 -0000 >> http://www.ietf.org/id/draft-manderson-sidr-geo-00.txt > o does this content help/hurt/etc SIDR work? > o does the content advance SIDR's goals? no and no randy From kent@bbn.com Sun Feb 20 09:23:17 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A7A3A6CCA for ; Sun, 20 Feb 2011 09:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uiyA+o3r+55 for ; Sun, 20 Feb 2011 09:23:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2618B3A6C68 for ; Sun, 20 Feb 2011 09:23:16 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:51743 helo=[10.242.10.246]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrD0k-0007qs-5c; Sun, 20 Feb 2011 12:23:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> References: <20110218010420.DBDBB49A769@nargothrond.hactrn.net> Date: Sun, 20 Feb 2011 12:16:13 -0500 To: Rob Austein From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-913899861==_ma============" Cc: sidr@ietf.org Subject: Re: [sidr] staging period discussion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 17:23:17 -0000 --============_-913899861==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Rob, Your reply did not contain any info that would cause me to change my mind about the staging period. I think we agree that the staging period cannot guarantee that all RPs have the new CA cert before the old data is replaced. What it can do is increase the likelihood that this will happen. Your position seems to be that the staging period may cause more harm than good. I appreciate that notion, but disagree. I think that changing the MUST to a SHOULD (or to RECOMMEND), and noting that an emergency rekey is not bound by this rule is a reasonable compromise. I am not willing to go with MAY; it may encourage bad behavior. BBN does not produce CA/repository management code, so we are not arguing from a position of not wanting to change our code. We are arguing from a position of trying to minimize the likelihood of RP confusion. Your description of how your CA code works omits a few details. For example, in step 1, when you start issuing new signed products, these replace the old products, because of the naming conventions employed in the repository. Thus you seem to be creating a mixed (inconsistent) set of repository entries during this step. The staging period, as described in the keyroll doc, provides more detail about this process, and shows how to minimize the window of inconsistency. That strikes me as a fundamentally good thing to do. I acknowledge that offering an option to restart the rollover during the staging period add complexity. But, there is also added complexity for RPs who have to deal with repository fetches that yield a mix of old and new signed products. Saying that an RP will have to deal with this issue in some cases does not mean that we ought not try hard to minimize the frequency with which RPs have to do so. This seems especially true since we seem to lack a good description of how an RP should deal with this problem. I have seen no algorithmic description of how an RP is supposed to deal with repository inconsistency. Not even heuristics.) Steve P.S. BTW, no, our RP code does not discard old data before getting new data. Has your validator stopped beating its database :-)? --============_-913899861==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] staging period discussion
Rob,

Your reply did not contain any info that would cause me to change my mind
about the staging period. I think we agree that the staging period cannot
guarantee that all RPs have the new CA cert before the old data is replaced.
What it can do is increase the likelihood that this will happen.  Your position seems to be that the staging period may cause more harm than good.  I appreciate that notion, but disagree.

I think that changing the MUST to a SHOULD (or to RECOMMEND), and noting that an emergency rekey is not bound by this rule is a reasonable compromise. I am not willing to go with MAY; it may encourage bad behavior.

BBN does not produce CA/repository management code, so we are not arguing from a position of not wanting to change our code.  We are arguing from a position of trying to minimize the likelihood of RP confusion.

Your description of how your CA code works omits a few details.  For example, in step 1, when you start issuing new signed products, these replace the old products, because of the naming conventions employed in the repository. Thus you seem to be creating a mixed (inconsistent) set of repository entries during this step.  The staging period, as described in the keyroll doc, provides more detail about this process, and shows how to minimize the window of inconsistency. That strikes me as a fundamentally good thing to do.

I acknowledge that offering an option to restart the rollover during the
staging period add complexity.  But, there is also added complexity for RPs who have to deal with repository fetches that yield a mix of old and new signed products. Saying that an RP will have to deal with this issue in some cases does not mean that we ought not try hard to minimize the frequency with which RPs have to do so. This seems especially true since we seem to lack a good description of how an RP should deal with this problem. I have seen no algorithmic description of how an RP is supposed to deal with repository inconsistency. Not even heuristics.)

Steve

P.S.  BTW, no, our RP code does not discard old data before getting new data.
Has your validator stopped beating its database :-)?
--============_-913899861==_ma============-- From kent@bbn.com Sun Feb 20 09:23:22 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4253A6E02 for ; Sun, 20 Feb 2011 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ03B2RkclO4 for ; Sun, 20 Feb 2011 09:23:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E395A3A6E57 for ; Sun, 20 Feb 2011 09:23:21 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:51743 helo=[10.242.10.246]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrD0r-0007qs-5g; Sun, 20 Feb 2011 12:24:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D5E9FC6.4020404@cisco.com> References: <4D5E9FC6.4020404@cisco.com> Date: Sun, 20 Feb 2011 11:22:57 -0500 To: Russ White From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 17:23:22 -0000 At 11:35 AM -0500 2/18/11, Russ White wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enigEEE752FC731D9F82CF768B1F" > > >> * Is an Autonomous System (AS) authorized to originate an IP prefix > > * Is the AS-Path represented in the route the same as the path >> through which the route update traveled > >As we've been discussing on the list --I don't think this is a good >goal. The first goal should be to determine what it is we want to show >about the AS Path in relation to other things, and then work on filling >that goal. > >Starting with the assumption that proving an update travels a specific >path seems, to me, to be going about things the wrong way. > >:-) > >Russ Some folks have observed that ASes may make decisions about accepting updates based on AS path info. That, by itself, motivates securing the AS path info in an update, irrespective of any other motivations. Steve From kent@bbn.com Sun Feb 20 09:23:23 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EA33A6E02 for ; Sun, 20 Feb 2011 09:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2lRKedFpOeE for ; Sun, 20 Feb 2011 09:23:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 791483A6E6E for ; Sun, 20 Feb 2011 09:23:22 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:51743 helo=[10.242.10.246]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrD0r-0007qs-PK; Sun, 20 Feb 2011 12:24:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D5EB53F.7080708@cisco.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> Date: Sun, 20 Feb 2011 12:23:13 -0500 To: Russ White From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 17:23:23 -0000 At 1:06 PM -0500 2/18/11, Russ White wrote: >... >Let me ask you something --does IPsec try to verify the path the packet >takes, or the contents of the packet? If the right solution for IPsec is >to validate the content of the packet, then why is the right solution >for BGP to verify the path of the packet? > >:-) > >Russ Russ, IPsec provides end-to-end secruity services (confidentiality, integrity, data origin authentication, and optional anti-replay) between peers. It need not worry about the path taken by the traffic that is protected by IPsec. The security semantics for IPsec-protected traffic are purely end-to-end. IPsec attempts to provide security consistent with an agreed-upon notion of what IP traffic should expect in a benign environment (e.g., no passive or active wiretapping), plus a recognition of real world limitations (e.g., variable delays happen, packets are dropped or reordered, etc.). IPsec is not an appropriate analogy for the BGP security context. In BGP the recipient of an update is allowed to transform it in certain ways, and to pass it on to other routers (at its discretion). It is not an end-to-end security model of the sort that IPsec embodies. It seems that we have a major disagreement over what constitutes the semantics of routing security relative to a benign environment. You stated that "... the "semantic of BGP" has never been that the AS Path is used for anything other than determining if the path is loop free." That assertion seems to ignore the fact that routing decisions often take into account path length. Are you saying that such decisions are not part of the semantics of BGP, as interpreted by most ASes? Steve From russ@cisco.com Sun Feb 20 11:12:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FB33A6DF7 for ; Sun, 20 Feb 2011 11:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnBWES3MTK7w for ; Sun, 20 Feb 2011 11:12:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 43B7A3A6DAD for ; Sun, 20 Feb 2011 11:12:02 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMf2YE1AZnwN/2dsb2JhbACmMnOeZ5pHgxCCTgSFDYcGgzs X-IronPort-AV: E=Sophos;i="4.62,195,1297036800"; d="asc'?scan'208";a="217872396" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2011 19:12:41 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1KJCfiw006424; Sun, 20 Feb 2011 19:12:41 GMT Message-ID: <4D6167A5.3080303@cisco.com> Date: Sun, 20 Feb 2011 14:12:37 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephen Kent References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E2154A61CE7B0C6635BB8C1" Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 19:12:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E2154A61CE7B0C6635BB8C1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > "... the "semantic of BGP" has never been that the AS Path is used > for anything other than determining if the path is loop free." >=20 > That assertion seems to ignore the fact that routing decisions often > take into account path length. Are you saying that such decisions are > not part of the semantics of BGP, as interpreted by most ASes? The primary purpose of the AS list in the AS Path is to determine the loop-freeness of the path, much like a metric in an IGP is used for the same reason. The AS Path length was added to the decision process, AFAIK, in order to inject the idea of the "least cost," or shortest path, once you've arrived at a set of loop free paths. Now, if you look at the actual attributes placed in BGP in order to express policy, there are only three available (that I know of): 1. Local preference, which is only within an AS. 2. MED, which is one AS to a directly connected peer, and has always been accepted as something which can be (and most often is) overriden. 3. Communities, which are either transitive or nontransitive. The only ones I know of that actually express routing policy are nontransitive --they only impact the AS I'm peering with. In other words, the idea that in this network: A--B--C A should somehow be able to base any sort of policy on C's policy just wasn't ever there. And yet --this appears to be precisely what we are trying to inject into the protocol. Trying to set a policy that you will not prefer a route from B because it passes through C is basing the policy on potentially partial information. I know there's been a strong attempt to disconnect policy towards routing updates from forwarding policy. To this end --let me ask an open question to the list. Can anyone on list point me to a policy carried in BGP, or actually implemented by a BGP speaker, that's not designed to impact forwarding? :-) Russ --------------enig4E2154A61CE7B0C6635BB8C1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1hZ6cACgkQER27sUhU9OQ4jQCg2/Ef3hSAB/dFP0kfJf1beG63 XW8AnRUnPOQtnV3f4vdp5T1DxXQIG5+C =kFTJ -----END PGP SIGNATURE----- --------------enig4E2154A61CE7B0C6635BB8C1-- From rv@x37.NIC.DTAG.DE Sun Feb 20 16:44:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70763A6D4D for ; Sun, 20 Feb 2011 16:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJGXakVpabwt for ; Sun, 20 Feb 2011 16:44:36 -0800 (PST) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by core3.amsl.com (Postfix) with ESMTP id 1BE103A6CC3 for ; Sun, 20 Feb 2011 16:44:35 -0800 (PST) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id BAA13628; Mon, 21 Feb 2011 01:45:09 +0100 (MET) To: Russ White From: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" In-Reply-To: Your message of "Sun, 20 Feb 2011 14:12:37 EST." <4D6167A5.3080303@cisco.com> Date: Mon, 21 Feb 2011 01:45:09 +0100 Message-ID: <15345.1298249109@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 00:44:37 -0000 > > "... the "semantic of BGP" has never been that the AS Path is used > > for anything other than determining if the path is loop free." > > > > That assertion seems to ignore the fact that routing decisions often > > take into account path length. Are you saying that such decisions are > > not part of the semantics of BGP, as interpreted by most ASes? > > The primary purpose of the AS list in the AS Path is to determine the ^^^^^^^^^^^^^^^ that's already pretty a different statement from "never been .. used for anything other than determining if the path is loop free." > loop-freeness of the path, much like a metric in an IGP is used for the > same reason. The AS Path length was added to the decision process, > AFAIK, in order to inject the idea of the "least cost," or shortest > path, once you've arrived at a set of loop free paths. > > Now, if you look at the actual attributes placed in BGP in order to > express policy, there are only three available (that I know of): > > 1. Local preference, which is only within an AS. > > 2. MED, which is one AS to a directly connected peer, and has always > been accepted as something which can be (and most often is) overriden. > > 3. Communities, which are either transitive or nontransitive. The only > ones I know of that actually express routing policy are nontransitive > --they only impact the AS I'm peering with. This is an (incomplete:-) list of attributes that have immediately defined semantics for BGP route selection and propagation. This provides the primitives that a operator has to use when implementing policies. The more sophisticated operators define and implement policies (usually) using vendor specific policy languages (e.g. route-map, RPL, ...) or more abstract ones (like IETF standards track RPSL); often the operator's policy implementation provides a new signalling repertoire for their customers (to allow them additional control of usage and propagation of the customer routes etc.); usually the signalling uses community attributes (usually transitive!). The implementation of policies means evaluating attributes of routes to decide how to manipulate the attributes used for further processing and propagation (in particular by setting the input/triggers for above mentioned primitives). Simple early examples can be found in RFC1998. Please note all known serious BGP implementations as well as RPSL support AS path regular expressions in their repertoire of criteria for evaluating routes; there probably is a reason - I also hear that in some parts of the Internet AS path filters are used as the primary security measure (no, I don't!). Also note that even the examples in RFC1998 use AS path expressions that do NOT depend on just the immediate neighbor's AS... > In other words, the idea that in this network: > > A--B--C > > A should somehow be able to base any sort of policy on C's policy just > wasn't ever there. Does not seem like a relevant question. Policies are essentially internal to an AS (=black box); they relate to external input and may create specific output - and of course specifics can be communicated to other AS operators; so there is no principal problem for C signalling something to A, and A using that (assuming that B's policy did not block or distort the signal). > And yet --this appears to be precisely what we are > trying to inject into the protocol. Trying to set a policy that you will > not prefer a route from B because it passes through C is basing the > policy on potentially partial information. ?????? Can the AS path attribute fullfill it's "primary function" of loop prevention if we CAN NOT rely on it including all AS that have propagated the route? (with "abstraction" caveat for not publicly visible confederation members!) I don't see HOW (other than by miracle or additional attributes that are more reliable in this respect!) So "C" must be available in the annoucement that B propagates to A (unless B and C are members of confederation - and confederation members are only visible inside the confederation) and there is nothing "partial" in the "knowledge" that A's policy would use... > I know there's been a strong attempt to disconnect policy towards > routing updates from forwarding policy. To this end --let me ask an open > question to the list. Can anyone on list point me to a policy carried in > BGP, or actually implemented by a BGP speaker, that's not designed to > impact forwarding? Considering the wide range of applications that have occured in proposals to use BGP for distributing information in networks I would not be surprised at all if there are cases that are only very indirectly related to forwarding! > :-) :-) :-) > > Russ Ruediger Volk From kent@bbn.com Mon Feb 21 05:04:33 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2613A6F17 for ; Mon, 21 Feb 2011 05:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiX1hAn-LWAM for ; Mon, 21 Feb 2011 05:04:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A8D893A70FB for ; Mon, 21 Feb 2011 05:04:32 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40171 helo=[59.188.192.152]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrVRx-000Kbe-Va; Mon, 21 Feb 2011 08:05:14 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4D6167A5.3080303@cisco.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> Date: Mon, 21 Feb 2011 07:51:51 -0500 To: Russ White From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 13:04:33 -0000 At 2:12 PM -0500 2/20/11, Russ White wrote: > > "... the "semantic of BGP" has never been that the AS Path is used >> for anything other than determining if the path is loop free." >> >> That assertion seems to ignore the fact that routing decisions often >> take into account path length. Are you saying that such decisions are >> not part of the semantics of BGP, as interpreted by most ASes? > >The primary purpose of the AS list in the AS Path is to determine the >loop-freeness of the path, much like a metric in an IGP is used for the >same reason. The AS Path length was added to the decision process, >AFAIK, in order to inject the idea of the "least cost," or shortest >path, once you've arrived at a set of loop free paths. Whatever the primary purpose may have been initially, the fact is that path length is an important input to path selection as implemented. That justifies an effort to ensure that the path seen by a recipient is authentic. Steve From russ@cisco.com Mon Feb 21 05:12:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972D13A6F32 for ; Mon, 21 Feb 2011 05:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvF8VuwExCZI for ; Mon, 21 Feb 2011 05:12:17 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C5F573A6F27 for ; Mon, 21 Feb 2011 05:12:17 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG/zYU1AZnwM/2dsb2JhbACmLHOeX5sLhV4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,200,1297036800"; d="asc'?scan'208";a="217742824" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2011 13:12:59 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1LDCxO9020223; Mon, 21 Feb 2011 13:12:59 GMT Message-ID: <4D6264D5.70209@cisco.com> Date: Mon, 21 Feb 2011 08:12:53 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephen Kent References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC31070266E8BC9FE83B54EA5" Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 13:12:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC31070266E8BC9FE83B54EA5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Whatever the primary purpose may have been initially, the fact is that > path length is an important input to path selection as implemented. Tha= t > justifies > an effort to ensure that the path seen by a recipient is authentic. So the only security problem anyone faces, currently, is people cheating on the AS Path length? :-) Russ --------------enigC31070266E8BC9FE83B54EA5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1iZNgACgkQER27sUhU9OTBbQCdEc2KgfD6suEGXr47EQbNOWDS hrcAnRerflz5RlSkZ4ocfUhNGegIm0kJ =HB9D -----END PGP SIGNATURE----- --------------enigC31070266E8BC9FE83B54EA5-- From Sandra.Murphy@cobham.com Mon Feb 21 06:12:23 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856FF3A6EA1 for ; Mon, 21 Feb 2011 06:12: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQImT4069hlF for ; Mon, 21 Feb 2011 06:12:22 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id AC4673A6CC2 for ; Mon, 21 Feb 2011 06:12:22 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1LED08A020218; Mon, 21 Feb 2011 08:13:00 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1LECxu1012532; Mon, 21 Feb 2011 08:12:59 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([173.12.204.201]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Feb 2011 09:12:58 -0500 Date: Mon, 21 Feb 2011 09:13:00 -0500 (Eastern Standard Time) From: Sandra Murphy To: Russ White In-Reply-To: <4D6264D5.70209@cisco.com> Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Feb 2011 14:12:59.0005 (UTC) FILETIME=[71566AD0:01CBD1D1] Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 14:12:23 -0000 No, messing with an AS_PATH is the fundamental problem. Cheating on AS_PATH length is just one way to exploit that fundamental vulnerability. See other messages for other examples of ways to exploit. --Sandy On Mon, 21 Feb 2011, Russ White wrote: > >> Whatever the primary purpose may have been initially, the fact is that >> path length is an important input to path selection as implemented. That >> justifies >> an effort to ensure that the path seen by a recipient is authentic. > > So the only security problem anyone faces, currently, is people cheating > on the AS Path length? > > :-) > > Russ > > From russ@cisco.com Mon Feb 21 06:57:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6033A7110 for ; Mon, 21 Feb 2011 06:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZYH7J1Niu7E for ; Mon, 21 Feb 2011 06:57:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 042163A7089 for ; Mon, 21 Feb 2011 06:57:03 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIIMYk1AZnwM/2dsb2JhbACmLnOecZsQhV4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,200,1297036800"; d="asc'?scan'208";a="218153055" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 Feb 2011 14:57:45 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1LEvjeT029821; Mon, 21 Feb 2011 14:57:45 GMT Message-ID: <4D627D63.2080402@cisco.com> Date: Mon, 21 Feb 2011 09:57:39 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sandra Murphy References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB138588E1E05FEB88758986F" Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 14:57:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB138588E1E05FEB88758986F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > See other messages for other examples of ways to exploit. Countering these should be the requirements and the statement in the charter, not "signing the update." :-) Russ --------------enigB138588E1E05FEB88758986F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ifWYACgkQER27sUhU9OT5yACghS3NXxR60EOj1SlnIB0YdOHv dVwAoO0ynJnxKmxAhilqA8qEzi4Wj+/A =zOLV -----END PGP SIGNATURE----- --------------enigB138588E1E05FEB88758986F-- From schiller@uu.net Mon Feb 21 08:02:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9A93A6FBF for ; Mon, 21 Feb 2011 08:02:06 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpEA+QwFQ6jp for ; Mon, 21 Feb 2011 08:02:04 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 9FA933A6FD8 for ; Mon, 21 Feb 2011 08:02:04 -0800 (PST) Received: from omzismtp02.vzbi.com ([unknown] [165.122.46.167]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00K675WE3260@firewall.verizonbusiness.com> for sidr@ietf.org; Mon, 21 Feb 2011 16:02:43 +0000 (GMT) Received: from omzismtp02.vzbi.com ([unknown] [127.0.0.1]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGZ00C3F5WE4O00@omzismtp02.vzbi.com> for sidr@ietf.org; Mon, 21 Feb 2011 16:02:39 +0000 (GMT) Received: from peermon.argfrp.us.uu.net ([unknown] [153.39.57.202]) by omzismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00C7G5WD0300@omzismtp02.vzbi.com> for sidr@ietf.org; Mon, 21 Feb 2011 16:02:38 +0000 (GMT) Date: Mon, 21 Feb 2011 11:02:37 -0500 (EST) From: Jason Schiller X-X-Sender: schiller@peermon.argfrp.us.uu.net To: Russ White In-reply-to: <4D6264D5.70209@cisco.com> Message-id: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 16:02:07 -0000 On Mon, 21 Feb 2011, Russ White wrote: |So the only security problem anyone faces, currently, is people cheating |on the AS Path length? I thougth my previous post (as well as other) have been pretty clear on this topic. The Kapella style attacks are sucessful because an organization can add ASes that they are not autorized to use to the AS-path. __Jason From christopher.morrow@gmail.com Mon Feb 21 08:29:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC603A7126 for ; Mon, 21 Feb 2011 08:29:28 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0lphi+tpI87 for ; Mon, 21 Feb 2011 08:29:27 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C00F73A6FE4 for ; Mon, 21 Feb 2011 08:29:26 -0800 (PST) Received: by eye13 with SMTP id 13so78721eye.31 for ; Mon, 21 Feb 2011 08:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HPiRTllQ4O5ganRVT6MaUnpLec3lMyFGT2eth9yx8sY=; b=nGY70E9h2EE1pHDfBwgm2UIac0D32r0OHbELq/5LhDc0yPPhz29ggIe5TNQJxN3x/p Nn+tHjKSc11EJ9Nh5EhNQcni//cBzhGaz2PP258Y13SMIfj2U4g9eyVeP1gKkYZDGU4f uYBkzJNWf6erPZb3dNa1nCkz8OKZTEkAlkIuc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jAhNMHHs9g1Zcw8UcxZ0FzTsA43mH314Dl32U3T/e9mdTAbWLh1g7JzwczF80zDPmz eACUupnCsMCl1FCHViH82SlSYnzIUia6oeZo2HRyelR5AFeDhjwZh7NlnzY0NUiYQBhg CMQO+8Y/qJfcW0ChXUaMbLbriRNWsymR5aE4I= MIME-Version: 1.0 Received: by 10.213.9.66 with SMTP id k2mr1777670ebk.40.1298305807915; Mon, 21 Feb 2011 08:30:07 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.213.13.209 with HTTP; Mon, 21 Feb 2011 08:30:07 -0800 (PST) In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> Date: Mon, 21 Feb 2011 11:30:07 -0500 X-Google-Sender-Auth: QgTMtdoeKPwUFAf_ttxURXbB8gs Message-ID: From: Christopher Morrow To: Jason Schiller Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org, Russ White Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 16:29:29 -0000 On Mon, Feb 21, 2011 at 11:02 AM, Jason Schiller wrote: > On Mon, 21 Feb 2011, Russ White wrote: > > |So the only security problem anyone faces, currently, is people cheating > |on the AS Path length? > > I thougth my previous post (as well as other) have been pretty clear on > this topic. =A0The Kapella style attacks are sucessful because an > organization can add ASes that they are not autorized to use to the > AS-path. and aside from 'you are originating a route you should not be originating' this seems to be the other large class of attack, no? Russ, what other classes of attack were you thinking of? (or seen in the wild, or seen tested in labs, etc) -chris From daedulus@btconnect.com Mon Feb 21 09:27:43 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C1E3A6DDB; Mon, 21 Feb 2011 09:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqfXgFAWlKUN; Mon, 21 Feb 2011 09:27:42 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 912B73A6E10; Mon, 21 Feb 2011 09:27:41 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2beaomr10.btconnect.com with SMTP id BTW31338; Mon, 21 Feb 2011 17:28:19 +0000 (GMT) Message-ID: <000c01cbd1e3$c1036e40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "ietf" Date: Mon, 21 Feb 2011 17:23:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D62A0B3.0065, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4D62A0B6.0104,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: iesg , sidr@ietf.org Subject: Re: [sidr] Last Call: (An Infrastructure to X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 17:27:43 -0000 I find this I-D problematic. The subject matter is of crucial importance, comparable to, or perhaps more important than, IPv6, yet this I-D is not an easy read and there should be one such somewhere. sidr has produced an awesome collection of I-Ds (some now obsolete) but it is not obvious, short of spending a few months in the archives, how they fit together. Other major projects - snmp for example - produced an Introduction, acting as a starting point and a road map to the other I-Ds and I think that that should be a prerequisite for sidr. This I-D is not it (even if it could be); its Normative References include a further 80 pages of sidr I-Ds! One small example. The I-Ds have several references to RPKI and indeed, that appears in -arch; but it first appears on page 8 and is not even expanded, let alone explained. Of course you can turn to Wikipedia and you find a clear explanation of what RPKI is but you should not need Wikipedia to understand something as important as sidr. This I-D seems to be written to be understood by those who understand it:-( Tom Petch ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: Sent: Monday, February 07, 2011 5:14 PM Subject: [sidr] Last Call: (An Infrastructure to > > The IESG has received a request from the Secure Inter-Domain Routing WG > (sidr) to consider the following document: > - 'An Infrastructure to Support Secure Internet Routing' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf at ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be > sent to iesg at ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ > > > > The following IPR Declarations may be related to this I-D: > > /ipr/1204/ > From pmohapat@cisco.com Mon Feb 21 10:34:59 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505623A6FC9 for ; Mon, 21 Feb 2011 10:34:59 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KRDIhMhxe4P for ; Mon, 21 Feb 2011 10:34:58 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4F9773A6E38 for ; Mon, 21 Feb 2011 10:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=406; q=dns/txt; s=iport; t=1298313340; x=1299522940; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=zurcjG59il7qx07rPcy1EYd02WnxJqLaTJmBL1HnI+s=; b=HDz8div5HKzjVINu7pEDoSYfdI347Ohbep0Uq/AxkaHevrc+PMYe87tZ 127fturhWELCOT26Cc6hRClP/5uwmzpCA0hTJFZQMZbRolALzZ1JOhHac QAGktfjoCODNn+oAnDndy2t35mBupV7k6RqYfR2Mu820xWXg0+tGkiyrx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANY/Yk2rRN+K/2dsb2JhbACmL3OfUJtAhV4EhQ2HBg X-IronPort-AV: E=Sophos;i="4.62,201,1297036800"; d="scan'208";a="313290730" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 21 Feb 2011 18:35:23 +0000 Received: from dhcp-171-70-245-68.cisco.com (dhcp-171-70-245-68.cisco.com [171.70.245.68]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1LIZNih003484 for ; Mon, 21 Feb 2011 18:35:23 GMT From: Pradosh Mohapatra Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2011 10:36:14 -0800 Message-Id: <3CDA3E59-7F13-4655-9B55-DB22B9C10843@cisco.com> To: "sidr@ietf.org wg" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [sidr] draft-ietf-sidr-pfx-validate-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 18:34:59 -0000 The -01 version of the draft addresses the comments that were received = during the last call, most notably: http://www.ietf.org/mail-archive/web/sidr/current/msg02168.html http://www.ietf.org/mail-archive/web/sidr/current/msg02204.html Would be great to have a round of review to verify the comments were = indeed addressed and see if there are any new comments/concerns. Thanks, - Pradosh= From shane@castlepoint.net Mon Feb 21 10:39:32 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05FE43A70FD for ; Mon, 21 Feb 2011 10:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z087MHAy1yS0 for ; Mon, 21 Feb 2011 10:39:31 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 1319D3A6FEF for ; Mon, 21 Feb 2011 10:39:31 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 076142684E9; Mon, 21 Feb 2011 11:40:13 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-254-35.hlrn.qwest.net [65.101.254.35]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 21 Feb 2011 11:40:12 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.254.35; client-port=57682; syn-fingerprint=65535:56:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 21 Feb 2011 11:39:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@castlepoint.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> To: Jason Schiller X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org, Russ White Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 18:39:32 -0000 Jason, All, On Feb 21, 2011, at 09:02 MST, Jason Schiller wrote: > On Mon, 21 Feb 2011, Russ White wrote: >=20 > |So the only security problem anyone faces, currently, is people = cheating > |on the AS Path length? >=20 > I thougth my previous post (as well as other) have been pretty clear = on=20 > this topic. The Kapella style attacks are sucessful because an=20 > organization can add ASes that they are not autorized to use to the=20 > AS-path. But, who is certifying what are legitimate vs. illegitimate AS_PATH's = when the AS_PATH is greater than 2? IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing = transit from two upstream providers: AS_B and AS_C. In that case, the = originating AS, AS_A, certainly has 'authority' on who (or, what set of = AS'es) should be providing it with transit. And, I can see the origin = AS, AS_A, having something analogous to an IRR 'aut-num' object to tell = the world what AS'es it is exporting/importing routes/AS'es to/from. = Operationally, this is already done today (for those that use IRR = aut-num objects, at least). I get it. If this is where we draw a line = in the sand that we want SIDR work to go, but no farther (at least for = now), then OK. (However, I'm still not sure if REQ #4.1 in = draft-ymbk-bgpsec-reqs-00 is intended to address an origin ASN -> = transit provider's AS_PATH relationship reqm't or is restating what the = concept of ROA's do today. Can someone clarify?) However, the impression I'm getting is that folks want SIDR to go a step = beyond that. For example, AS_B and AS_C announce AS_A on to their = upstreams/peers -- and, this is where I don't get it. Let's use just = the case of transit provider AS_B. Let's say he announces AS_A onto = AS_X, AS_Y and AS_Z, so you have an AS_PATH that looks like the = following: AS_X AS_B AS_A AS_Y AS_B AS_A AS_Z AS_B AS_A At this point: a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z = ... and, just as importantly, /further beyond AS_X, Y and Z/. b) Just as importantly, there is no IANA or RIR -- currently! -- that = certifies the contractual linkage between AS_B and AS_X, Y and Z. =46rom a contractual PoV, AS_A has very little to do with _who_, beyond = his directly connected transit providers/peers (AS_B and AS_C in this = example), his routes are announced to. Instead, AS_B is contractually = obligated to announce, or not announce, AS_A's routes based on whether = AS_B's connected AS'es are peers or transit providers.[1] (Yes, there = are exceptions like AS_A tagging routes with "NO_EXPORT", but = operationally those are most likely an exception, IMO, intended to = withhold more-specifics ... not 'general' reachability/connectedness). I believe this, potentially, ties back to REQ's #3.14 and #4.2 in = draft-ymbk-bgpsec-reqs-00, which (depending on your PoV) either conflict = with each other or REQ #3.14 makes the 'assurances' people desire in REQ = #4.2 not any better than we have in BGP today at AS_PATH lengths greater = than 2. Specifically, let's assume that AS_Z is contractually a 'peer' = of AS_B and that AS_Z has suddenly gone "rogue". AS_Z is now starting = to announce AS_B, (and AS_A), on to AS_Z's __peers__ (AS_J, not = depicted)[2]. AS_Z can sign AS_B's (and, AS_A's) routes all day long = and they'll look "legitimate" from the PoV that a "recipient of an = UPDATE [will know] that that UPDATE has traversed that AS_PATH in the = update". But, and here's the key point: a recipient of routes from AS_Z = shouldn't *really* accept them, correct, because that AS_Z is breaching = their contract with AS_B? Or, to look at it in a completely different = light, what 'value' does a signature provide in this case compared to = today's non-signature based AS_PATH? In summary, an AS_PATH is more than just a series of "breadcrumbs" on = where an UPDATE has been. In reality, there's a lot of very, very = complicated 'policy' (really, dollars) on where it's _allowed_ to go, as = well, that ultimately matters if you're going to provide assurances that = it's "legitimate" or not. I highly, highly recommend the reqmt's draft = is much, much more clear on what assurances folks are attempting to make = at, for example, various AS_PATH lengths, otherwise the signatures are = likely to be, at best, meaningless. -shane [1] REQ 3.14 of draft-ymbk-bgpsec-reqs-00 states that a "BGPsec design = MUST NOT require operators to reveal proprietary data ... [that] = includes peering, customer and provider relationships". This seems to = ignore the reality that a recipient would need to know this if you're = going to understand that, for example, a peer should only be sending you = their transit customer's routes ... not their other peer's routes ... [2] For the more security-oriented folks in the room, at a very = high-level, peer's only announce their transit customer's routes to each = other. As a peer, you do not announce your other peer's routes on to = other peer's ...= From schiller@uu.net Mon Feb 21 11:01:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62573A714E for ; Mon, 21 Feb 2011 11:01:06 -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_21=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA+jLnLmWG52 for ; Mon, 21 Feb 2011 11:01:05 -0800 (PST) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by core3.amsl.com (Postfix) with ESMTP id 2E77D3A7152 for ; Mon, 21 Feb 2011 11:01:05 -0800 (PST) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ003YDE6YRM40@firewall.verizonbusiness.com> for sidr@ietf.org; Mon, 21 Feb 2011 19:01:47 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGZ000IQE6Y7V00@pdcismtp03.vzbi.com> for sidr@ietf.org; Mon, 21 Feb 2011 19:01:46 +0000 (GMT) Received: from peermon.argfrp.us.uu.net ([unknown] [153.39.57.202]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ0004YE6YE100@pdcismtp03.vzbi.com> for sidr@ietf.org; Mon, 21 Feb 2011 19:01:46 +0000 (GMT) Date: Mon, 21 Feb 2011 14:01:46 -0500 (EST) From: Jason Schiller X-X-Sender: schiller@peermon.argfrp.us.uu.net To: Shane Amante In-reply-to: <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@castlepoint.net> Message-id: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@castlepoint.net> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Cc: sidr@ietf.org, Russ White , Jason Schiller Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:01:06 -0000 On Mon, 21 Feb 2011, Shane Amante wrote: | |But, who is certifying what are legitimate vs. illegitimate AS_PATH's |when the AS_PATH is greater than 2? | |IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing |transit from two upstream providers: AS_B and AS_C. In that case, the |originating AS, AS_A, certainly has 'authority' on who (or, what set of |AS'es) should be providing it with transit. And, I can see the origin |AS, AS_A, having something analogous to an IRR 'aut-num' object to tell |the world what AS'es it is exporting/importing routes/AS'es to/from. |Operationally, this is already done today (for those that use IRR aut-num |objects, at least). I get it. If this is where we draw a line in the |sand that we want SIDR work to go, but no farther (at least for now), |then OK. (However, I'm still not sure if REQ #4.1 in |draft-ymbk-bgpsec-reqs-00 is intended to address an origin ASN -> transit |provider's AS_PATH relationship reqm't or is restating what the concept |of ROA's do today. Can someone clarify?) | | |However, the impression I'm getting is that folks want SIDR to go a step |beyond that. For example, AS_B and AS_C announce AS_A on to their |upstreams/peers -- and, this is where I don't get it. Let's use just the |case of transit provider AS_B. Let's say he announces AS_A onto AS_X, |AS_Y and AS_Z, so you have an AS_PATH that looks like the following: |AS_X AS_B AS_A |AS_Y AS_B AS_A |AS_Z AS_B AS_A | |At this point: |a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z |... and, just as importantly, /further beyond AS_X, Y and Z/. |b) Just as importantly, there is no IANA or RIR -- currently! -- that |certifies the contractual linkage between AS_B and AS_X, Y and Z. | |From a contractual PoV, AS_A has very little to do with _who_, beyond |his directly connected transit providers/peers (AS_B and AS_C in this |example), his routes are announced to. Instead, AS_B is contractually |obligated to announce, or not announce, AS_A's routes based on whether |AS_B's connected AS'es are peers or transit providers.[1] (Yes, there |are exceptions like AS_A tagging routes with "NO_EXPORT", but |operationally those are most likely an exception, IMO, intended to withhold more-specifics ... not 'general' reachability/connectedness). | In your example where AS_A buys transit from AS_B and AS_B buy transit / Peers with AS_X, AS)Y, and AS_Z... When AS_B announces AS_A's prefix to its upstreams, it is asserting two things: 1. AS_B learned the prefix from AS_A, choose it as best, and does not have policy to limit the distribution of the route. 2. That network represented as AS_B has the right to use the ASN value AS_B. -- The RIRs validate this Likewise when AS_Z propagates the prefix it makes the same claim, that it has learned the route from AS_B and that it as a network has the right to us AS_Z. __Jason From christopher.morrow@gmail.com Mon Feb 21 11:14:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F403A6F5C; Mon, 21 Feb 2011 11:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.179 X-Spam-Level: X-Spam-Status: No, score=-103.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCRSFuJdeXGB; Mon, 21 Feb 2011 11:14:41 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7A5F23A6F42; Mon, 21 Feb 2011 11:14:40 -0800 (PST) Received: by wwa36 with SMTP id 36so6590282wwa.13 for ; Mon, 21 Feb 2011 11:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5MuhdJ+F83ngQ7OV8qVoKLa/utNDp/w9ujRT8No1UUs=; b=YrxmoTM3JH12WxhoA7OFr/fDkXMiwhh6z0iLWKVmi0lI9v4y5FatTXzpMtiXTO7QTc dePh98C5ntuentKx223rmIYvzkgd2mv5UM68PUu611p2oJf4cYNhg8xLEdSDPnpUiJ/u LqDRuYE49tnqrGMLvUAyyOClxiAxIBdAV+KGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=T/9hBKs2SScAjuuZUCcLtLpQYdKjzpA/let5kfErtSAFmy4696/hAFf6E9kBK4uE7g MI5vgHlfbUFGpf3RlAwiMtRM7kfkFd7Y2E2Xvru20gsRSQIN9w+j8X5lyRs3t6t5oawI H+XUNDKzoGthmYpCG36Sxyf1l0tUkqCwowGW8= MIME-Version: 1.0 Received: by 10.216.18.204 with SMTP id l54mr1487836wel.99.1298315720728; Mon, 21 Feb 2011 11:15:20 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Mon, 21 Feb 2011 11:15:20 -0800 (PST) In-Reply-To: <000c01cbd1e3$c1036e40$4001a8c0@gateway.2wire.net> References: <000c01cbd1e3$c1036e40$4001a8c0@gateway.2wire.net> Date: Mon, 21 Feb 2011 14:15:20 -0500 X-Google-Sender-Auth: RIInaIxgoLZeRM5VT2KMSPiwODM Message-ID: From: Christopher Morrow To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org, ietf , iesg Subject: Re: [sidr] Last Call: (An Infrastructure to X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:14:42 -0000 (not speaking for the authors, just observing some... also not speaking as a co-chair) On Mon, Feb 21, 2011 at 11:23 AM, t.petch wrote: > I find this I-D problematic. =A0The subject matter is of crucial importan= ce, > comparable to, or perhaps more important than, IPv6, yet this I-D is not > an easy read and there should be one such somewhere. > I thought there was to be an overview doc as well produced, with the goal being to lay out the basic parts referring to the other drafts for further info/expansion. > sidr has produced an awesome collection of I-Ds (some now obsolete) but i= t is > not obvious, short of spending a few months in the archives, how they fit > together. =A0Other major projects - snmp for example - produced an Introd= uction, > acting as a starting point and a road map to the other I-Ds and I think t= hat > that should be a prerequisite for sidr. =A0This I-D is not it (even if it= could > be); its Normative > References include a further 80 pages of sidr I-Ds! > > One small example. =A0The I-Ds have several references to RPKI and indeed= , that > appears in -arch; but it first appears on page 8 and is not even expanded= , let eh.. that's a nit that someone should file... "hey, you can't use an acronym for the first time without actually expanding it properly!" Can you cite the proper para/page/section on this so the authors can fix it= ? -Chris > alone explained. =A0Of course you can turn to Wikipedia and you find a cl= ear > explanation of what RPKI is but you should not need Wikipedia to understa= nd > something as important as sidr. =A0This I-D seems to be written to be und= erstood > by those who understand it:-( > > Tom Petch > > > ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: > Sent: Monday, February 07, 2011 5:14 PM > Subject: [sidr] Last Call: (An Infrastructu= re to > > >> >> The IESG has received a request from the Secure Inter-Domain Routing WG >> (sidr) to consider the following document: >> - 'An Infrastructure to Support Secure Internet Routing' >> =A0 as an Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf at ietf.org mailing lists by 2011-02-21. Exceptionally, comments ma= y be >> sent to iesg at ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ >> >> >> >> The following IPR Declarations may be related to this I-D: >> >> /ipr/1204/ >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From christopher.morrow@gmail.com Mon Feb 21 11:17:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A310B3A7138; Mon, 21 Feb 2011 11:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.164 X-Spam-Level: X-Spam-Status: No, score=-103.164 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42u4d1yJvDzF; Mon, 21 Feb 2011 11:17:02 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1B97F3A6F5C; Mon, 21 Feb 2011 11:17:01 -0800 (PST) Received: by wwa36 with SMTP id 36so6592731wwa.13 for ; Mon, 21 Feb 2011 11:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HIo8r3Yct3p7v3LMpDGXv1xOpty0XLnx/+h6PU6odW8=; b=hcT0RPc6inhq4gxlu2kMIa/Tr2h+sgZWJ9DW/XH0YljaDiv3nIypR0Yoyz4b4VR9jH NqGKNRdnrpzU1N9PMNNYkybppNS0c+WoDyOaAGewrzP1n8lm5EFEOj92Lhd6sHs/NIJD AqVl6Lk09tABw1jhGGJZj6D71z0O2INQ7CV9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bnKge6oXCO06Annka6o8LWv/o9ba/g7CMD2CUCRWml8/IPhYVw30jWzRlbydRJsqLm oLMqL2d/Plpfs9e56DxM3y4FgRI8s32LjCaT3YUZwc7HqqHaldcgg38WhSoOPBHLXdwt hOQHqKnSlGgNMMxD5jFcBt/CbiAVesE0geYr4= MIME-Version: 1.0 Received: by 10.216.155.1 with SMTP id i1mr2534051wek.0.1298315862791; Mon, 21 Feb 2011 11:17:42 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Mon, 21 Feb 2011 11:17:42 -0800 (PST) In-Reply-To: References: <000c01cbd1e3$c1036e40$4001a8c0@gateway.2wire.net> Date: Mon, 21 Feb 2011 14:17:42 -0500 X-Google-Sender-Auth: efSXlYI4g-EtuSlEptcSwLJT8Qs Message-ID: From: Christopher Morrow To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org, ietf , iesg Subject: Re: [sidr] Last Call: (An Infrastructure to X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:17:03 -0000 On Mon, Feb 21, 2011 at 2:15 PM, Christopher Morrow wrote: > (not speaking for the authors, just observing some... also not > speaking as a co-chair) > > On Mon, Feb 21, 2011 at 11:23 AM, t.petch wrote: >> I find this I-D problematic. =A0The subject matter is of crucial importa= nce, >> comparable to, or perhaps more important than, IPv6, yet this I-D is not >> an easy read and there should be one such somewhere. >> > > I thought there was to be an overview doc as well produced, with the > goal being to lay out the basic parts referring to the other drafts > for further info/expansion. oh, I mentioned the overview in the note about rechartering: "The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation" -chris >> sidr has produced an awesome collection of I-Ds (some now obsolete) but = it is >> not obvious, short of spending a few months in the archives, how they fi= t >> together. =A0Other major projects - snmp for example - produced an Intro= duction, >> acting as a starting point and a road map to the other I-Ds and I think = that >> that should be a prerequisite for sidr. =A0This I-D is not it (even if i= t could >> be); its Normative >> References include a further 80 pages of sidr I-Ds! >> >> One small example. =A0The I-Ds have several references to RPKI and indee= d, that >> appears in -arch; but it first appears on page 8 and is not even expande= d, let > > eh.. that's a nit that someone should file... "hey, you can't use an > acronym for the first time without actually expanding it properly!" > > Can you cite the proper para/page/section on this so the authors can fix = it? > > -Chris > >> alone explained. =A0Of course you can turn to Wikipedia and you find a c= lear >> explanation of what RPKI is but you should not need Wikipedia to underst= and >> something as important as sidr. =A0This I-D seems to be written to be un= derstood >> by those who understand it:-( >> >> Tom Petch >> >> >> ----- Original Message ----- >> From: "The IESG" >> To: "IETF-Announce" >> Cc: >> Sent: Monday, February 07, 2011 5:14 PM >> Subject: [sidr] Last Call: (An Infrastruct= ure to >> >> >>> >>> The IESG has received a request from the Secure Inter-Domain Routing WG >>> (sidr) to consider the following document: >>> - 'An Infrastructure to Support Secure Internet Routing' >>> =A0 as an Informational RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf at ietf.org mailing lists by 2011-02-21. Exceptionally, comments m= ay be >>> sent to iesg at ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ >>> >>> >>> >>> The following IPR Declarations may be related to this I-D: >>> >>> /ipr/1204/ >>> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > From Donald.Smith@qwest.com Mon Feb 21 11:17:32 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43BB3A6F5C for ; Mon, 21 Feb 2011 11:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc0FB+qkwi1D for ; Mon, 21 Feb 2011 11:17:31 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id B60F93A6F42 for ; Mon, 21 Feb 2011 11:17:31 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p1LJHeX9000737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 13:17:40 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 44B671E0049; Mon, 21 Feb 2011 13:17:35 -0600 (CST) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 2A63A1E0032; Mon, 21 Feb 2011 13:17:35 -0600 (CST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p1LJHYlU007178; Mon, 21 Feb 2011 13:17:34 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Mon, 21 Feb 2011 12:17:33 -0700 From: "Smith, Donald" To: "'Shane Amante'" , Jason Schiller Date: Mon, 21 Feb 2011 12:17:33 -0700 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvR9snsKAEZMsu/TfuyIs2GcDuL1wABMt3Q Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@castlepoint.net> In-Reply-To: <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Russ White , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:17:32 -0000 I think your last statement missed the concept of paid peering. That is TIER 1 ISPs frequently announce TIER2 routes but consider the TIER2= "customer" as a "peer". Or am I missing something? > [2] For the more security-oriented folks in the room, at a very high- > level, peer's only announce their transit customer's routes to each > other. As a peer, you do not announce your other peer's routes on to > other peer's ... Sharing: Author's permission required. Donald.Smith@qwest.com > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Monday, February 21, 2011 11:40 AM > To: Jason Schiller > Cc: sidr@ietf.org; Russ White > Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation > work > > Jason, All, > > On Feb 21, 2011, at 09:02 MST, Jason Schiller wrote: > > On Mon, 21 Feb 2011, Russ White wrote: > > > > |So the only security problem anyone faces, currently, is people > cheating > > |on the AS Path length? > > > > I thougth my previous post (as well as other) have been pretty clear > on > > this topic. The Kapella style attacks are sucessful because an > > organization can add ASes that they are not autorized to use to the > > AS-path. > > But, who is certifying what are legitimate vs. illegitimate AS_PATH's > when the AS_PATH is greater than 2? > > IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing > transit from two upstream providers: AS_B and AS_C. In that case, the > originating AS, AS_A, certainly has 'authority' on who (or, what set of > AS'es) should be providing it with transit. And, I can see the origin > AS, AS_A, having something analogous to an IRR 'aut-num' object to tell > the world what AS'es it is exporting/importing routes/AS'es to/from. > Operationally, this is already done today (for those that use IRR aut- > num objects, at least). I get it. If this is where we draw a line in > the sand that we want SIDR work to go, but no farther (at least for > now), then OK. (However, I'm still not sure if REQ #4.1 in draft-ymbk- > bgpsec-reqs-00 is intended to address an origin ASN -> transit > provider's AS_PATH relationship reqm't or is restating what the concept > of ROA's do today. Can someone clarify?) > > > However, the impression I'm getting is that folks want SIDR to go a > step beyond that. For example, AS_B and AS_C announce AS_A on to their > upstreams/peers -- and, this is where I don't get it. Let's use just > the case of transit provider AS_B. Let's say he announces AS_A onto > AS_X, AS_Y and AS_Z, so you have an AS_PATH that looks like the > following: > AS_X AS_B AS_A > AS_Y AS_B AS_A > AS_Z AS_B AS_A > > At this point: > a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z > ... and, just as importantly, /further beyond AS_X, Y and Z/. > b) Just as importantly, there is no IANA or RIR -- currently! -- that > certifies the contractual linkage between AS_B and AS_X, Y and Z. > > From a contractual PoV, AS_A has very little to do with _who_, beyond > his directly connected transit providers/peers (AS_B and AS_C in this > example), his routes are announced to. Instead, AS_B is contractually > obligated to announce, or not announce, AS_A's routes based on whether > AS_B's connected AS'es are peers or transit providers.[1] (Yes, there > are exceptions like AS_A tagging routes with "NO_EXPORT", but > operationally those are most likely an exception, IMO, intended to > withhold more-specifics ... not 'general' reachability/connectedness). > > I believe this, potentially, ties back to REQ's #3.14 and #4.2 in > draft-ymbk-bgpsec-reqs-00, which (depending on your PoV) either > conflict with each other or REQ #3.14 makes the 'assurances' people > desire in REQ #4.2 not any better than we have in BGP today at AS_PATH > lengths greater than 2. Specifically, let's assume that AS_Z is > contractually a 'peer' of AS_B and that AS_Z has suddenly gone "rogue". > AS_Z is now starting to announce AS_B, (and AS_A), on to AS_Z's > __peers__ (AS_J, not depicted)[2]. AS_Z can sign AS_B's (and, AS_A's) > routes all day long and they'll look "legitimate" from the PoV that a > "recipient of an UPDATE [will know] that that UPDATE has traversed that > AS_PATH in the update". But, and here's the key point: a recipient of > routes from AS_Z shouldn't *really* accept them, correct, because that > AS_Z is breaching their contract with AS_B? Or, to look at it in a > completely different light, what 'value' does a signature provide in > this case compared to today > 's non-signature based AS_PATH? > > In summary, an AS_PATH is more than just a series of "breadcrumbs" on > where an UPDATE has been. In reality, there's a lot of very, very > complicated 'policy' (really, dollars) on where it's _allowed_ to go, > as well, that ultimately matters if you're going to provide assurances > that it's "legitimate" or not. I highly, highly recommend the reqmt's > draft is much, much more clear on what assurances folks are attempting > to make at, for example, various AS_PATH lengths, otherwise the > signatures are likely to be, at best, meaningless. > > -shane > > [1] REQ 3.14 of draft-ymbk-bgpsec-reqs-00 states that a "BGPsec design > MUST NOT require operators to reveal proprietary data ... [that] > includes peering, customer and provider relationships". This seems to > ignore the reality that a recipient would need to know this if you're > going to understand that, for example, a peer should only be sending > you their transit customer's routes ... not their other peer's routes > ... > [2] For the more security-oriented folks in the room, at a very high- > level, peer's only announce their transit customer's routes to each > other. As a peer, you do not announce your other peer's routes on to > other peer's ... > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From shane@castlepoint.net Mon Feb 21 11:23:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCCE3A7162 for ; Mon, 21 Feb 2011 11:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5ATCVUY3YtX for ; Mon, 21 Feb 2011 11:23:55 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 882413A7166 for ; Mon, 21 Feb 2011 11:23:55 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E68A92684EA; Mon, 21 Feb 2011 12:24:37 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-254-35.hlrn.qwest.net [65.101.254.35]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 21 Feb 2011 12:24:37 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.254.35; client-port=57916; syn-fingerprint=65535:56:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 21 Feb 2011 12:24:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <03B3BCB2-3E71-41BA-BBEC-91449776BC1C@castlepoint.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@castlepoint.net> To: Jason Schiller X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org, Russ White , Jason Schiller Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:23:56 -0000 Jason, On Feb 21, 2011, at 12:01 MST, Jason Schiller wrote: > On Mon, 21 Feb 2011, Shane Amante wrote: > When AS_B announces AS_A's prefix to its upstreams, it is asserting = two=20 > things: >=20 > 1. AS_B learned the prefix from AS_A, choose it as best, and does not = have=20 > policy to limit the distribution of the route. Ah ha, you said: "policy". What policy? NO_EXPORT community? = Contractual policy? Other? -shane > 2. That network represented as AS_B has the right to use the ASN value=20= > AS_B. >=20 > -- The RIRs validate this >=20 >=20 > Likewise when AS_Z propagates the prefix it makes the same claim, that = it=20 > has learned the route from AS_B and that it as a network has the = right to=20 > us AS_Z. >=20 >=20 > __Jason From shane@castlepoint.net Mon Feb 21 11:34:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37733A6F42 for ; Mon, 21 Feb 2011 11:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVZ4KK7-Jldh for ; Mon, 21 Feb 2011 11:34:40 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A67583A7165 for ; Mon, 21 Feb 2011 11:34:40 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 227E02684EA; Mon, 21 Feb 2011 12:35:23 -0700 (MST) Received: from mbpw.castlepoint.net (65-101-254-35.hlrn.qwest.net [65.101.254.35]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 21 Feb 2011 12:35:22 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.254.35; client-port=57940; syn-fingerprint=65535:56:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 21 Feb 2011 12:35:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DBF6968-5EFA-41AC-AEF2-A5375153AB52@castlepoint.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@castlepoint.net> To: "Smith, Donald" X-Mailer: Apple Mail (2.1082) Cc: Russ White , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:34:42 -0000 Don, On Feb 21, 2011, at 12:17 MST, Smith, Donald wrote: > I think your last statement missed the concept of paid peering. > That is TIER 1 ISPs frequently announce TIER2 routes but consider the = TIER2 "customer" as a "peer". > Or am I missing something? I purposefully glanced over paid peering, in an attempt to keep things = relatively simple (for now), in a meager attempt to figure out what are = the requirements with respect to assertions on the "data" contained in = an AS_PATH. The concept of paid-peering, etc. may have to be revisited = depending on where present conversations lead us. -shane >> [2] For the more security-oriented folks in the room, at a very high- >> level, peer's only announce their transit customer's routes to each >> other. As a peer, you do not announce your other peer's routes on to >> other peer's ... >=20 > Sharing: Author's permission required. > Donald.Smith@qwest.com >=20 >=20 >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of >> Shane Amante >> Sent: Monday, February 21, 2011 11:40 AM >> To: Jason Schiller >> Cc: sidr@ietf.org; Russ White >> Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation >> work >>=20 >> Jason, All, >>=20 >> On Feb 21, 2011, at 09:02 MST, Jason Schiller wrote: >>> On Mon, 21 Feb 2011, Russ White wrote: >>>=20 >>> |So the only security problem anyone faces, currently, is people >> cheating >>> |on the AS Path length? >>>=20 >>> I thougth my previous post (as well as other) have been pretty clear >> on >>> this topic. The Kapella style attacks are sucessful because an >>> organization can add ASes that they are not autorized to use to the >>> AS-path. >>=20 >> But, who is certifying what are legitimate vs. illegitimate AS_PATH's >> when the AS_PATH is greater than 2? >>=20 >> IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing >> transit from two upstream providers: AS_B and AS_C. In that case, = the >> originating AS, AS_A, certainly has 'authority' on who (or, what set = of >> AS'es) should be providing it with transit. And, I can see the = origin >> AS, AS_A, having something analogous to an IRR 'aut-num' object to = tell >> the world what AS'es it is exporting/importing routes/AS'es to/from. >> Operationally, this is already done today (for those that use IRR = aut- >> num objects, at least). I get it. If this is where we draw a line = in >> the sand that we want SIDR work to go, but no farther (at least for >> now), then OK. (However, I'm still not sure if REQ #4.1 in = draft-ymbk- >> bgpsec-reqs-00 is intended to address an origin ASN -> transit >> provider's AS_PATH relationship reqm't or is restating what the = concept >> of ROA's do today. Can someone clarify?) >>=20 >>=20 >> However, the impression I'm getting is that folks want SIDR to go a >> step beyond that. For example, AS_B and AS_C announce AS_A on to = their >> upstreams/peers -- and, this is where I don't get it. Let's use just >> the case of transit provider AS_B. Let's say he announces AS_A onto >> AS_X, AS_Y and AS_Z, so you have an AS_PATH that looks like the >> following: >> AS_X AS_B AS_A >> AS_Y AS_B AS_A >> AS_Z AS_B AS_A >>=20 >> At this point: >> a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z >> ... and, just as importantly, /further beyond AS_X, Y and Z/. >> b) Just as importantly, there is no IANA or RIR -- currently! -- that >> certifies the contractual linkage between AS_B and AS_X, Y and Z. >>=20 >> =46rom a contractual PoV, AS_A has very little to do with _who_, = beyond >> his directly connected transit providers/peers (AS_B and AS_C in this >> example), his routes are announced to. Instead, AS_B is = contractually >> obligated to announce, or not announce, AS_A's routes based on = whether >> AS_B's connected AS'es are peers or transit providers.[1] (Yes, = there >> are exceptions like AS_A tagging routes with "NO_EXPORT", but >> operationally those are most likely an exception, IMO, intended to >> withhold more-specifics ... not 'general' = reachability/connectedness). >>=20 >> I believe this, potentially, ties back to REQ's #3.14 and #4.2 in >> draft-ymbk-bgpsec-reqs-00, which (depending on your PoV) either >> conflict with each other or REQ #3.14 makes the 'assurances' people >> desire in REQ #4.2 not any better than we have in BGP today at = AS_PATH >> lengths greater than 2. Specifically, let's assume that AS_Z is >> contractually a 'peer' of AS_B and that AS_Z has suddenly gone = "rogue". >> AS_Z is now starting to announce AS_B, (and AS_A), on to AS_Z's >> __peers__ (AS_J, not depicted)[2]. AS_Z can sign AS_B's (and, = AS_A's) >> routes all day long and they'll look "legitimate" from the PoV that a >> "recipient of an UPDATE [will know] that that UPDATE has traversed = that >> AS_PATH in the update". But, and here's the key point: a recipient = of >> routes from AS_Z shouldn't *really* accept them, correct, because = that >> AS_Z is breaching their contract with AS_B? Or, to look at it in a >> completely different light, what 'value' does a signature provide in >> this case compared to today >> 's non-signature based AS_PATH? >>=20 >> In summary, an AS_PATH is more than just a series of "breadcrumbs" on >> where an UPDATE has been. In reality, there's a lot of very, very >> complicated 'policy' (really, dollars) on where it's _allowed_ to go, >> as well, that ultimately matters if you're going to provide = assurances >> that it's "legitimate" or not. I highly, highly recommend the = reqmt's >> draft is much, much more clear on what assurances folks are = attempting >> to make at, for example, various AS_PATH lengths, otherwise the >> signatures are likely to be, at best, meaningless. >>=20 >> -shane >>=20 >> [1] REQ 3.14 of draft-ymbk-bgpsec-reqs-00 states that a "BGPsec = design >> MUST NOT require operators to reveal proprietary data ... [that] >> includes peering, customer and provider relationships". This seems = to >> ignore the reality that a recipient would need to know this if you're >> going to understand that, for example, a peer should only be sending >> you their transit customer's routes ... not their other peer's routes >> ... >> [2] For the more security-oriented folks in the room, at a very high- >> level, peer's only announce their transit customer's routes to each >> other. As a peer, you do not announce your other peer's routes on to >> other peer's ... >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > This communication is the property of Qwest and may contain = confidential or > privileged information. Unauthorized use of this communication is = strictly > prohibited and may be unlawful. If you have received this = communication > in error, please immediately notify the sender by reply e-mail and = destroy > all copies of the communication and any attachments. From turners@ieca.com Mon Feb 21 11:58:55 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FF23A717B for ; Mon, 21 Feb 2011 11:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.455 X-Spam-Level: X-Spam-Status: No, score=-101.455 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJkNioPeyxvQ for ; Mon, 21 Feb 2011 11:58:55 -0800 (PST) Received: from nm8-vm0.bullet.mail.ac4.yahoo.com (nm8-vm0.bullet.mail.ac4.yahoo.com [98.139.52.230]) by core3.amsl.com (Postfix) with SMTP id C281E3A714D for ; Mon, 21 Feb 2011 11:58:54 -0800 (PST) Received: from [98.139.52.197] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 19:59:33 -0000 Received: from [98.139.52.177] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 19:59:33 -0000 Received: from [127.0.0.1] by omp1060.mail.ac4.yahoo.com with NNFMP; 21 Feb 2011 19:59:33 -0000 X-Yahoo-Newman-Id: 121204.85719.bm@omp1060.mail.ac4.yahoo.com Received: (qmail 79666 invoked from network); 21 Feb 2011 19:59:32 -0000 Received: from [10.13.53.182] (turners@166.137.15.89 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 21 Feb 2011 11:59:31 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: G5X4e8kVM1m0fmZDyFlLJLqd0HTxOepSJvYQRoZCfEa2SDk 2hR3WKwP2bg5rcwmwVyUFFAJWokLZDpWbUyT3qmgAF.TGqqG_Gw2iGUF6hKT UxNGyp73NCcTJI2KsMEAdimTq3TGiUP0YR9Cro5.oxp3z1SqI_ptTHbrlqii rg7_S45tNtw4YloaifzDLNLP6N45ZTjSI5okU5F9bOUo_hl4s07wjNWtt4Av WrEC5Mxlzee5dNp9DTNfzKAw4Bhpppytapn0nf9WTmxJoRsUQANFfp2udizp mcRJHBS3E3wczbK3WQELt1pfKHxxach0nxEjqCkS. X-Yahoo-Newman-Property: ymail-3 References: <000c01cbd1e3$c1036e40$4001a8c0@gateway.2wire.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <975F6DE4-FF8F-4F6A-B9D2-38884E219BFF@ieca.com> X-Mailer: iPhone Mail (8C148) From: Sean Turner Date: Mon, 21 Feb 2011 13:58:00 -0600 To: Christopher Morrow Cc: iesg , ietf , "t.petch" , "sidr@ietf.org" Subject: Re: [sidr] Last Call: (An Infrastructure to X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:58:55 -0000 On Feb 21, 2011, at 1:15 PM, Christopher Morrow wr= ote: > (not speaking for the authors, just observing some... also not > speaking as a co-chair) >=20 > On Mon, Feb 21, 2011 at 11:23 AM, t.petch wrote: >> I find this I-D problematic. The subject matter is of crucial importance= , >> comparable to, or perhaps more important than, IPv6, yet this I-D is not >> an easy read and there should be one such somewhere. >>=20 >=20 > I thought there was to be an overview doc as well produced, with the > goal being to lay out the basic parts referring to the other drafts > for further info/expansion. >=20 >> sidr has produced an awesome collection of I-Ds (some now obsolete) but i= t is >> not obvious, short of spending a few months in the archives, how they fit= >> together. Other major projects - snmp for example - produced an Introduc= tion, >> acting as a starting point and a road map to the other I-Ds and I think t= hat >> that should be a prerequisite for sidr. This I-D is not it (even if it c= ould >> be); its Normative >> References include a further 80 pages of sidr I-Ds! >>=20 >> One small example. The I-Ds have several references to RPKI and indeed, t= hat >> appears in -arch; but it first appears on page 8 and is not even expanded= , let >=20 > eh.. that's a nit that someone should file... "hey, you can't use an > acronym for the first time without actually expanding it properly!" >=20 > Can you cite the proper para/page/section on this so the authors can fix i= t? >=20 Maybe if we tweaked the last sentence in section 2: Such a PKI, which is henceforth referred to as the Resource Public Key Infra= structure (RPKI), is a central component of this architecture. Spt > -Chris >=20 >> alone explained. Of course you can turn to Wikipedia and you find a clea= r >> explanation of what RPKI is but you should not need Wikipedia to understa= nd >> something as important as sidr. This I-D seems to be written to be under= stood >> by those who understand it:-( >>=20 >> Tom Petch >>=20 >>=20 >> ----- Original Message ----- >> From: "The IESG" >> To: "IETF-Announce" >> Cc: >> Sent: Monday, February 07, 2011 5:14 PM >> Subject: [sidr] Last Call: (An Infrastructu= re to >>=20 >>=20 >>>=20 >>> The IESG has received a request from the Secure Inter-Domain Routing WG >>> (sidr) to consider the following document: >>> - 'An Infrastructure to Support Secure Internet Routing' >>> as an Informational RFC >>>=20 >>> 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 at ietf.org mailing lists by 2011-02-21. Exceptionally, comments ma= y be >>> sent to iesg at ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>>=20 >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ >>>=20 >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ >>>=20 >>>=20 >>>=20 >>> The following IPR Declarations may be related to this I-D: >>>=20 >>> /ipr/1204/ >>>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Mon Feb 21 12:12:38 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3003A6E38; Mon, 21 Feb 2011 12:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9APs6CBPuZbB; Mon, 21 Feb 2011 12:12:37 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 575033A6CCB; Mon, 21 Feb 2011 12:12:37 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1LKD81k024124; Mon, 21 Feb 2011 14:13:10 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1LKD8cm022714; Mon, 21 Feb 2011 14:13:08 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.169]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Feb 2011 15:13:07 -0500 Date: Mon, 21 Feb 2011 15:13:05 -0500 (Eastern Standard Time) From: Sandra Murphy To: Russ White In-Reply-To: <4D5ED326.8030608@cisco.com> Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Feb 2011 20:13:07.0589 (UTC) FILETIME=[C10EAB50:01CBD203] Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 20:12:38 -0000 On Fri, 18 Feb 2011, Russ White wrote: > >> and because AS-Sets are opaque when it comes to security semantics >> (which asn in the set is responsible for what part of the aggregate?) >> they are excluded from the discussion, and on the road to deprecation. > > The point wasn't to say, "can each of these be solved," it was to say, > "the AS Path wasn't designed to bear the weight you're putting on it." > >>> I could go on giving examples, but to state, "BGP's semantic is that the >>> AS Path represents the path through which the update has traveled," is >>> simply untrue. >> >> eh... but it is. one more time around the mulberry bush? > > It's not. The AS Path is to prove the path is loop free. It was never > intended to prove where the update went in the network. The AS_PATH has always been intended to represent the ASs that propagated the update. The AS_PATH can be used to detect loops ONLY because it does represent the ASs that propagated the update. --Sandy > > :-) > > Russ > > > From jmh@joelhalpern.com Mon Feb 21 12:23:15 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BA43A6E38 for ; Mon, 21 Feb 2011 12:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.54 X-Spam-Level: X-Spam-Status: No, score=-101.54 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7XNjn7tVvwr for ; Mon, 21 Feb 2011 12:23:14 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id CA9EC3A6CCB for ; Mon, 21 Feb 2011 12:23:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1D599325AEFB for ; Mon, 21 Feb 2011 12:23:57 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-187.clppva.btas.verizon.net [71.161.52.187]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 9C12A3245BC6 for ; Mon, 21 Feb 2011 12:23:56 -0800 (PST) Message-ID: <4D62C9D9.1080201@joelhalpern.com> Date: Mon, 21 Feb 2011 15:23:53 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 CC: sidr@ietf.org References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 20:23:15 -0000 I think we do need to be a little careful about what the AS path "always" meant, and what we are going to end up with it meaning if we follow the path and discussion. For example, there is long practice of adding not just ones own AS, but sometimes other AS numbers to a path for policy reasons. In that usage, it does not represent "the AS that propagated the update." It may well be that it is acceptable to eliminate that usage. An AS Set does not mean that the advertisement went through all of those AS. (Admittedly, we are probably just going to ban sets.) Folks tell all sorts of lies if they implement various kinds of multi-pathing. It is reasonable to say that we are going to give up some of the flexibility the tool has had in order to get better verifiability of certain specific properties. But we should understand that we are indeed changing the semantics when we do so. Yours, Joel On 2/21/2011 3:13 PM, Sandra Murphy wrote: ... > > The AS_PATH has always been intended to represent the ASs that > propagated the update. > > The AS_PATH can be used to detect loops ONLY because it does represent > the ASs that propagated the update. > > > --Sandy > > > >> >> :-) >> >> Russ >> >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From russ@cisco.com Mon Feb 21 13:17:54 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589053A7157; Mon, 21 Feb 2011 13:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGvvPkE3tvWR; Mon, 21 Feb 2011 13:17:53 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2D2673A7158; Mon, 21 Feb 2011 13:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1792; q=dns/txt; s=iport; t=1298323116; x=1299532716; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=uBSXkMJKhste2iHNd7eSdtLuODUB4MZ37UBfXp53GpY=; b=QQMcZp7cM9WVplVLv+1GuHFCnTFscMtFj43xhkwQHYqkmo4bVBnd4JbY sw/SgyH7RrRvmR4HPutt+XVmlwHfyUpnoSsECcarWl59BeHcbqsBk9mU+ Risua7eHqJuClbojWO0FcsA3/PgZoQNEFvCV0Ew0iID8tLzCPk0q9NzpG M=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFZlYk1AZnwN/2dsb2JhbACmP3OfLptShV4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,202,1297036800"; d="asc'?scan'208";a="217946934" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2011 21:18:35 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1LLIZEx003751; Mon, 21 Feb 2011 21:18:35 GMT Message-ID: <4D62D6A4.7040007@cisco.com> Date: Mon, 21 Feb 2011 16:18:28 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sandra Murphy References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58C486A1DA82C0D5D6041D5B" Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:17:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58C486A1DA82C0D5D6041D5B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The AS_PATH has always been intended to represent the ASs that > propagated the update. >=20 > The AS_PATH can be used to detect loops ONLY because it does represent > the ASs that propagated the update. Sorry --but I just gave 5 examples of where the AS Path is intentionally modified without causing loops. The point is the loopfreeness, not the path the update took. Let me ask this in a different way. Suppose you have the following: A---B +-C-+ Now, for whatever reason, and with C's full knowledge and consent, B decides to advertise C's routes to A without putting itself in the AS Path. Is this possible? Yes, it is --using current commercial implementations of BGP. Is it wrong? Well, it doesn't cause a loop, does it? As for policy --isn't that up to the contract between B and C? Why should BGP enforce the contract terms B and C are able to write between themselves? And yes, this situation does exist in the real world --I just happen to be helping a customer set this up in a private environment. :-) Russ --------------enig58C486A1DA82C0D5D6041D5B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1i1qcACgkQER27sUhU9OThtACeO/gpAJI5YJCUUTpAMnEngIdJ JiMAnRj25hNLEug+hmGePGQlS8QV+N7+ =gM0E -----END PGP SIGNATURE----- --------------enig58C486A1DA82C0D5D6041D5B-- From russ@cisco.com Mon Feb 21 13:26:21 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66703A7158 for ; Mon, 21 Feb 2011 13:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMR0G2GNjE8n for ; Mon, 21 Feb 2011 13:26:20 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 837493A7151 for ; Mon, 21 Feb 2011 13:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=2820; q=dns/txt; s=iport; t=1298323623; x=1299533223; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=HLY0ZYNQuLOIeyxoR6kFMjmzstz2agx8ms2t6oco3l0=; b=m6uajnV3Wf4IAVqyovItbBbR9yEAzv/mIbOodXnnSlF9GXNpTfuiQZsu /FbJeO01B8sKzHxuqnFHJZcdPVUVIxNv6yXLva8GwMISNU0D8E3h5T/AU CPrY7/euHvR5S9jdB5dujMetQvftFFpFNM9cfeVmRnxxdKawUE/Sz5ikX Y=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALJnYk1AZnwN/2dsb2JhbACmP3OfLptUgn4Sgk4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,202,1297036800"; d="asc'?scan'208";a="217949207" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2011 21:27:02 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1LLR2dJ005791; Mon, 21 Feb 2011 21:27:02 GMT Message-ID: <4D62D8A0.3000007@cisco.com> Date: Mon, 21 Feb 2011 16:26:56 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jason Schiller References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <3FA5AC1A-EAAA-4375-9F20-AB78295497DE@castlepoint.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB36260B577DCDFB73B789145" Cc: sidr@ietf.org, Jason Schiller Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:26:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB36260B577DCDFB73B789145 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > In your example where AS_A buys transit from AS_B and AS_B buy transit = / > Peers with AS_X, AS)Y, and AS_Z... >=20 > When AS_B announces AS_A's prefix to its upstreams, it is asserting two= =20 > things: >=20 > 1. AS_B learned the prefix from AS_A, choose it as best, and does not h= ave=20 > policy to limit the distribution of the route. Who's policy? I think this is where the problem really lies, isn't it? Are you trying to prove that AS_B has not restricted AS_A from sending these routes along to its peers? If so, why should AS_A's peers pay any attention to what AS_B's policy is? IE, the only person who should enforce AS_B's policy with AS_A is AS_B itself --or am I missing somethin= g? Further, is the _only_ policy anyone really cares about whether or not AS_B "authorizes" AS_A to send routes on to its peers? Are there no other policies in play here? In other words, we're going to build an entire security system around one policy that's not really contained within the protocol today? This is why I really, really, want the requirements clarified. > 2. That network represented as AS_B has the right to use the ASN value = > AS_B. This has nothing to do with signing updates, to be honest --in fact, this is something that I've been bothered about for a long long time. Do the RIR's really want to get into the "you're really who you say you are," business? If someone can fool the RIR into thinking they're Banco Rio, and get a corresponding AS claiming such through a validated certification, and I put my account information into a web site based on this information, and I lose my identity, can I sue the RIR for not doing a good job of being certain who people really are? If not, then what have I gained here? This is the larger problem we've kind-of just left under the covers, but it's bound to come popping out at some point or another. I would prefer it not come out in a court case, honestly. :-) At any rate, this second piece is well outside the scope of path validation, I think. :-) Russ --------------enigB36260B577DCDFB73B789145 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1i2KIACgkQER27sUhU9OSmDwCg1ZJNVKgmumnmCLxbIoC7QfN9 dLIAnjFs3SByCEzlg08nj5wxlpM00vwF =1Urd -----END PGP SIGNATURE----- --------------enigB36260B577DCDFB73B789145-- From rbarnes@bbn.com Mon Feb 21 13:27:56 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80A0E3A717F; Mon, 21 Feb 2011 13:27:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yigml6j2TpZO; Mon, 21 Feb 2011 13:27:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 851053A717E; Mon, 21 Feb 2011 13:27:55 -0800 (PST) Received: from [128.89.253.215] (port=53176 helo=[172.27.17.202]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PrdJ5-000OIs-Sx; Mon, 21 Feb 2011 16:28:36 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4D62D6A4.7040007@cisco.com> Date: Mon, 21 Feb 2011 16:28:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> <4D62D6A4.7040007@cisco.com> To: Russ White X-Mailer: Apple Mail (2.1082) Cc: Christopher Morrow , sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:27:56 -0000 Not to be pedantic, but the BGP spec *does* say that the AS_PATH = documents the path of an UPDATE, and that each AS must add itself: " This attribute identifies the autonomous systems through which routing = information carried in this UPDATE message has passed.=20 ... When a BGP speaker propagates a route it learned from another BGP speaker's UPDATE message, it modifies the route's AS_PATH attribute based on the location of the BGP speaker to which the route will be sent: ... 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol message). =20 " As I read this, in your example, B would not be conformant with the BGP = spec if it forwarded UPDATEs from C without appending it's own AS. It = would probably be OK to *re-originate* the routes, but that creates a = separate set of problems. --Richard On Feb 21, 2011, at 4:18 PM, Russ White wrote: >=20 >> The AS_PATH has always been intended to represent the ASs that >> propagated the update. >>=20 >> The AS_PATH can be used to detect loops ONLY because it does = represent >> the ASs that propagated the update. >=20 > Sorry --but I just gave 5 examples of where the AS Path is = intentionally > modified without causing loops. The point is the loopfreeness, not the > path the update took. >=20 > Let me ask this in a different way. Suppose you have the following: >=20 > A---B > +-C-+ >=20 > Now, for whatever reason, and with C's full knowledge and consent, B > decides to advertise C's routes to A without putting itself in the AS > Path. Is this possible? Yes, it is --using current commercial > implementations of BGP. Is it wrong? >=20 > Well, it doesn't cause a loop, does it? As for policy --isn't that up = to > the contract between B and C? Why should BGP enforce the contract = terms > B and C are able to write between themselves? And yes, this situation > does exist in the real world --I just happen to be helping a customer > set this up in a private environment. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From russ@cisco.com Mon Feb 21 13:36:11 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418D03A717A; Mon, 21 Feb 2011 13:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.525 X-Spam-Level: X-Spam-Status: No, score=-10.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2APu5TLzDt2; Mon, 21 Feb 2011 13:36:10 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E35BF3A7154; Mon, 21 Feb 2011 13:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=3928; q=dns/txt; s=iport; t=1298324213; x=1299533813; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=7IUqdg10NJKS+PEYeZxTEolnOg3Q9V5PQEyR3RDg5pI=; b=Ar+d/efSJinH9iQ/NqE7zO8dlgHOdqdw5Ccy3xtDTOrNEDAUM7QcRLnr pIhij5ZsWqHWIPVHy+DnxnB/uHI8rPXYUyl8mjsvJcggS/X+fKnRuukrD Pm8Y9hM6wa0Vy4OcWKkJ7QOzgqxYRt4T9I98lL368+RBP5/LTPhmAhS01 U=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABNqYk1AZnwN/2dsb2JhbACmP3OfPZtYhV4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,202,1297036800"; d="asc'?scan'208";a="217952392" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2011 21:36:51 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1LLapmn009021; Mon, 21 Feb 2011 21:36:51 GMT Message-ID: <4D62DAEF.9070203@cisco.com> Date: Mon, 21 Feb 2011 16:36:47 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D5EBB18.1070401@cisco.com> <4D5EC6C4.5070809@cisco.com> <4D5ED326.8030608@cisco.com> <4D62D6A4.7040007@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0448A67AE4E45CFCB3B47363" Cc: Christopher Morrow , sidr-chairs@ietf.org, Sandra Murphy , Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:36:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0448A67AE4E45CFCB3B47363 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Not to be pedantic, but the BGP spec *does* say that the AS_PATH docume= nts the path of an UPDATE, and that each AS must add itself: No, it says that's the normal mode of operation... There's no MUST in here anyplace: > This attribute identifies the autonomous systems through which routing = information carried in this UPDATE message has passed.=20 > ... > When a BGP speaker propagates a route it learned from another BGP > speaker's UPDATE message, it modifies the route's AS_PATH attribute > based on the location of the BGP speaker to which the route will be > sent: > ... > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as= > the last element of the sequence (put it in the leftmost > position with respect to the position of octets in the > protocol message). =20 > " Further, how do we then explain all the examples of the IDR WG, itself, changing the AS Path (such as narrow to wide)? > As I read this, in your example, B would not be conformant with the BGP= spec if it forwarded UPDATEs from C without appending it's own AS. It w= ould probably be OK to *re-originate* the routes, but that creates a sepa= rate set of problems. So, one point of order might be --approach IDR with this specific question. Is the AS Path in BGP intended to exactly represent --with no changes allowed-- the path through which an update has passed? Or is the primary purpose to prevent loops? Getting the answer to that question might be helpful. As a contributor to BGP, I would say it's only related to loopfreeness, not to the path the update takes --it's not a route explorer, it's a routing update. :-) Russ >=20 > --Richard >=20 >=20 >=20 > On Feb 21, 2011, at 4:18 PM, Russ White wrote: >=20 >> >>> The AS_PATH has always been intended to represent the ASs that >>> propagated the update. >>> >>> The AS_PATH can be used to detect loops ONLY because it does represen= t >>> the ASs that propagated the update. >> >> Sorry --but I just gave 5 examples of where the AS Path is intentional= ly >> modified without causing loops. The point is the loopfreeness, not the= >> path the update took. >> >> Let me ask this in a different way. Suppose you have the following: >> >> A---B >> +-C-+ >> >> Now, for whatever reason, and with C's full knowledge and consent, B >> decides to advertise C's routes to A without putting itself in the AS >> Path. Is this possible? Yes, it is --using current commercial >> implementations of BGP. Is it wrong? >> >> Well, it doesn't cause a loop, does it? As for policy --isn't that up = to >> the contract between B and C? Why should BGP enforce the contract term= s >> B and C are able to write between themselves? And yes, this situation >> does exist in the real world --I just happen to be helping a customer >> set this up in a private environment. >> >> :-) >> >> Russ >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 --------------enig0448A67AE4E45CFCB3B47363 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1i2u8ACgkQER27sUhU9OQuEACfXgmRoK/rlnmFsdf0VfI55FaB XX8An0rFmMc+rbrvqOZDbjBrN3tCY3qa =9F8I -----END PGP SIGNATURE----- --------------enig0448A67AE4E45CFCB3B47363-- From randy@psg.com Mon Feb 21 16:29:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D4C3A67AA for ; Mon, 21 Feb 2011 16:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGRbnoyAqQU8 for ; Mon, 21 Feb 2011 16:29:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 160E23A677C for ; Mon, 21 Feb 2011 16:29:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Prg8h-0008Pf-Fv; Tue, 22 Feb 2011 00:30:03 +0000 Date: Tue, 22 Feb 2011 08:30:01 +0800 Message-ID: From: Randy Bush To: Jason Schiller In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org, Russ White Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 00:29:24 -0000 > |So the only security problem anyone faces, currently, is people cheating > |on the AS Path length? > > I thougth my previous post (as well as other) have been pretty clear on > this topic. they were. you are dealing with a one man dos. do not feed the troll. randy From schiller@uu.net Mon Feb 21 18:20:17 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7253A67E3 for ; Mon, 21 Feb 2011 18:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXyWHpx+DpU6 for ; Mon, 21 Feb 2011 18:20:13 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 9FACC3A67E5 for ; Mon, 21 Feb 2011 18:20:13 -0800 (PST) Received: from pdcismtp02.vzbi.com ([unknown] [166.40.77.70]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00AJ3YITBL80@firewall.verizonbusiness.com> for sidr@ietf.org; Tue, 22 Feb 2011 02:20:54 +0000 (GMT) Received: from pdcismtp02.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with SMTP id <0LGZ00IAVYITUD00@pdcismtp02.vzbi.com> for sidr@ietf.org; Tue, 22 Feb 2011 02:20:53 +0000 (GMT) Received: from peermon.argfrp.us.uu.net ([unknown] [153.39.57.202]) by pdcismtp02.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LGZ00I14YITUK00@pdcismtp02.vzbi.com> for sidr@ietf.org; Tue, 22 Feb 2011 02:20:53 +0000 (GMT) Date: Mon, 21 Feb 2011 21:20:53 -0500 (EST) From: Jason Schiller X-X-Sender: schiller@peermon.argfrp.us.uu.net To: Randy Bush In-reply-to: Message-id: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Cc: sidr@ietf.org, Russ White , Jason Schiller Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 02:20:17 -0000 ack. understood. Was concerned that other observers on SIDR might be buying his crap. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller@uu.net UUNET / Verizon jason.schiller@verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 22 Feb 2011, Randy Bush wrote: |Date: Tue, 22 Feb 2011 08:30:01 +0800 |From: Randy Bush |To: Jason Schiller |Cc: Russ White , sidr@ietf.org |Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work | |> |So the only security problem anyone faces, currently, is people cheating |> |on the AS Path length? |> |> I thougth my previous post (as well as other) have been pretty clear on |> this topic. | |they were. you are dealing with a one man dos. do not feed the troll. | |randy | From russ@cisco.com Mon Feb 21 19:02:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20153A6802 for ; Mon, 21 Feb 2011 19:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDF-RBLpvtio for ; Mon, 21 Feb 2011 19:02:46 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1ECA93A67F8 for ; Mon, 21 Feb 2011 19:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1148; q=dns/txt; s=iport; t=1298343809; x=1299553409; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=8obOM8pz62UM8UsjR1rva+AyVE1fPkYWrYJiB5Gkv+A=; b=Cn+X1+cpP+zdSArl50XAnWDcJVVN41wBHMMIJQ+ZDC88RfMvRyStGDjN V6Ia9jRX1Ohr3dQhXp1oPIuq3RcVDi7qMRQVhg13EuvVlfY+s9AkPDd39 hcHKJaduGTVTP8B25uoT4BwAROyGU02PC1StkGVk8N7D3Nq8DdZ6RTSGD U=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADS2Yk1AZnwN/2dsb2JhbACmQnOfUZtnhV4EhQ2HBoM7 X-IronPort-AV: E=Sophos;i="4.62,204,1297036800"; d="asc'?scan'208";a="218026383" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Feb 2011 03:03:29 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1M33Six020489; Tue, 22 Feb 2011 03:03:29 GMT Message-ID: <4D632779.8080509@cisco.com> Date: Mon, 21 Feb 2011 22:03:21 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0536617F9670DB896505322" Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 03:02:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0536617F9670DB896505322 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> |So the only security problem anyone faces, currently, is people cheat= ing >> |on the AS Path length? >> >> I thougth my previous post (as well as other) have been pretty clear o= n=20 >> this topic. >=20 > they were. you are dealing with a one man dos. do not feed the troll.= One thing I've learned through the years is the first person to start calling names has lost the argument. Russ --------------enigA0536617F9670DB896505322 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1jJ3wACgkQER27sUhU9OTmjACg1aQMkTp2rpyexxfGSzZEhL8z ig8AniIZx2mbjEUGJnOPu0GHt9K/gKG8 =bKtC -----END PGP SIGNATURE----- --------------enigA0536617F9670DB896505322-- From jmh@joelhalpern.com Mon Feb 21 19:19:35 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2603A680A for ; Mon, 21 Feb 2011 19:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki4hCPc3gaxr for ; Mon, 21 Feb 2011 19:19:34 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id C7A843A6809 for ; Mon, 21 Feb 2011 19:19:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4B9723247929; Mon, 21 Feb 2011 19:20:18 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-187.clppva.btas.verizon.net [71.161.52.187]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 4484832445E9; Mon, 21 Feb 2011 19:20:17 -0800 (PST) Message-ID: <4D632B6E.6030608@joelhalpern.com> Date: Mon, 21 Feb 2011 22:20:14 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jason Schiller References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jason Schiller , Russ White , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 03:19:35 -0000 Actually, I suspect that there is a useful, but badly articulated, question underlying Russ' emails. Yours, Joel On 2/21/2011 9:20 PM, Jason Schiller wrote: > ack. > > understood. > > Was concerned that other observers on SIDR might be buying his crap. > > __Jason > > > ========================================================================== > Jason Schiller (703)886.6648 > Senior Internet Network Engineer fax:(703)886.0512 > Public IP Global Network Engineering schiller@uu.net > UUNET / Verizon jason.schiller@verizonbusiness.com > > The good news about having an email address that is twice as long is that > it increases traffic on the Internet. > > On Tue, 22 Feb 2011, Randy Bush wrote: > > |Date: Tue, 22 Feb 2011 08:30:01 +0800 > |From: Randy Bush > |To: Jason Schiller > |Cc: Russ White, sidr@ietf.org > |Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work > | > |> |So the only security problem anyone faces, currently, is people cheating > |> |on the AS Path length? > |> > |> I thougth my previous post (as well as other) have been pretty clear on > |> this topic. > | > |they were. you are dealing with a one man dos. do not feed the troll. > | > |randy > | > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Mon Feb 21 19:30:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D5E3A680A for ; Mon, 21 Feb 2011 19:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7TomePQPDvK for ; Mon, 21 Feb 2011 19:30:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 273D43A659B for ; Mon, 21 Feb 2011 19:30:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Prixr-0009Q7-Ez; Tue, 22 Feb 2011 03:31:04 +0000 Date: Tue, 22 Feb 2011 11:31:01 +0800 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: <4D632B6E.6030608@joelhalpern.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <4D632B6E.6030608@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Jason Schiller , Russ White , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 03:30:24 -0000 > Actually, I suspect that there is a useful, but badly articulated, > question underlying Russ' emails. might be. hard to tell. having lived through the slanging match of rpsec, i am not willing to spend a whole lot more time on one slanger than the other. randy From Internet-Drafts@ietf.org Mon Feb 21 20:15:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282383A67F3; Mon, 21 Feb 2011 20:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.628 X-Spam-Level: X-Spam-Status: No, score=-102.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOvTZ2IfwAFt; Mon, 21 Feb 2011 20:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696E53A63D2; Mon, 21 Feb 2011 20:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222041501.21913.54969.idtracker@localhost> Date: Mon, 21 Feb 2011 20:15:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-keyroll-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 04:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : CA Key Rollover in the RPKI Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-keyroll-06.txt Pages : 10 Date : 2011-02-21 This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for Relying Parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-keyroll-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-keyroll-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-21201431.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Feb 21 21:30:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C703A6820; Mon, 21 Feb 2011 21:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU8JNcdON7pG; Mon, 21 Feb 2011 21:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B983A681D; Mon, 21 Feb 2011 21:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222053002.8118.82908.idtracker@localhost> Date: Mon, 21 Feb 2011 21:30:02 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-repos-struct-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 05:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Resource Certificate Repository Structure Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-repos-struct-07.txt Pages : 14 Date : 2011-02-21 This document defines a profile for the structure of the Resource PKI distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the recommended object (file) naming scheme, the recommended contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-repos-struct-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-repos-struct-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-21211653.I-D@ietf.org> --NextPart-- From Sandra.Murphy@cobham.com Tue Feb 22 08:39:54 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2693A68E6 for ; Tue, 22 Feb 2011 08:39:54 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VojAZrOQuyKb for ; Tue, 22 Feb 2011 08:39:53 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3B0CC3A693F for ; Tue, 22 Feb 2011 08:39:52 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1MGeaFc002675; Tue, 22 Feb 2011 10:40:36 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1MGea7H014915; Tue, 22 Feb 2011 10:40:36 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.124]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 11:40:35 -0500 Date: Tue, 22 Feb 2011 11:40:32 -0500 (Eastern Standard Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 22 Feb 2011 16:40:36.0377 (UTC) FILETIME=[3B27E090:01CBD2AF] Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:39:54 -0000 Randy, please do not indulge in ad-hominem attacks. It does nothing to help in finding the right answer. --Sandy On Tue, 22 Feb 2011, Randy Bush wrote: >> |So the only security problem anyone faces, currently, is people cheating >> |on the AS Path length? >> >> I thougth my previous post (as well as other) have been pretty clear on >> this topic. > > they were. you are dealing with a one man dos. do not feed the troll. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From andrew.lange@alcatel-lucent.com Tue Feb 22 18:50:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34FCD3A67DA for ; Tue, 22 Feb 2011 18:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcPxyHFMwNiO for ; Tue, 22 Feb 2011 18:50:22 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AE2A53A67A8 for ; Tue, 22 Feb 2011 18:50:22 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1N2p7Np025514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Feb 2011 20:51:07 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1N2p661002374 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Feb 2011 20:51:06 -0600 Received: from neo-119.vpn.ind.alcatel.com (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 22 Feb 2011 20:51:06 -0600 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-23-147178570"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew Lange In-Reply-To: Date: Tue, 22 Feb 2011 18:50:41 -0800 Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1082) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 02:50:24 -0000 --Apple-Mail-23-147178570 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To divert the discussion a bit back into the realm of requirements. What is the current "diameter" of the Internet? =46rom my recollections = it was converging toward about 4 ASes in diameter. This would mean that = for most paths we have: AS_A <--> AS_B <--> AS_C <--> AS_D If we have already authenticated the route origin, with either offline = or online enforcement depending on your preference, we have = cryptographically bound a route object to an aut num. Okay, this is = good. This is the current scope of the work. Now it's tougher for = people to fake announcements, intentionally or otherwise. This solves a = lot of the problem. Now, next step, we're looking at cryptographically signing the AS PATH, = but as Russ points out that isn't really what we want, at least I don't = think it is. What we seem to be trying to get at is what is to vet the = relationship between the ASes in the list. For example, is AS_B really = an upstream of AS_A? And it is therefore plausible that they would = legitimately want to announce AS_A's routes.=20 Of course, as Shane points out, there is absolutely no way in BGP (nor = should their be, IMHO), of expressing the actual relationship between = AS_A and AS_B. They could be peers, confeds, paid peers, customers, = etc.=20 The requirement seems to be the ability to cryptographically sign an = object expressing the relationship between AS_A and AS_B. Is AS_B = allowed, by AS_A, to announce AS_A's routes? BGP seems impractical as a mechanism, however, we could use RPSL to do = this. We simply offer the origin AS, in this case AS_A, an option to = express it's commercial relationship with its upstreams (or vice versa). = It can say "AS_B" can announce these routes, AS_Q can announce these, = etc. Yes, this does require that we announce "confidential" = information, but, being realistic, anyone can figure most of this out by = looking at a routing table. Given the small diameter, then we've solved 90% of the problem, as we = only have to then trust the big carriers in the core. If AS_B and AS_C = are Level 3 and Verizon, we can be reasonably assured that they will get = things right more often than not. They've been doing this a while, and = tend to know what they are doing. There is strong commercial pressure = not to blow it, and become subject to an attack or a highly visible = misconfiguration.=20 Andrew On Feb 22, 2011, at 8:40 AM, Sandra Murphy wrote: > Randy, please do not indulge in ad-hominem attacks. It does nothing = to=20 > help in finding the right answer. >=20 > --Sandy >=20 > On Tue, 22 Feb 2011, Randy Bush wrote: >=20 >>> |So the only security problem anyone faces, currently, is people = cheating >>> |on the AS Path length? >>>=20 >>> I thougth my previous post (as well as other) have been pretty clear = on >>> this topic. >>=20 >> they were. you are dealing with a one man dos. do not feed the = troll. >>=20 >> randy >> _______________________________________________ >> 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 --Apple-Mail-23-147178570 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggZFMIIFLaAD AgECAhEA2STcHPwgFUjzymZ55K0wyzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA0MTQwMDAw MDBaFw0xMTA0MTQyMzU5NTlaMIHnMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEVMBMGA1UEAxMMQW5kcmV3IExhbmdlMS4wLAYJKoZIhvcNAQkBFh9hbmRyZXcu bGFuZ2VAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA zpUVaYV8lZ/sTUuCmVWLjpnZLO7Wfjs3QxQ/5bX6L8xkGdL5jhnDpuaI9ta4T+NuPO/AY07kaOUD 87n/Ze2TF4+rwLT48JXoxiJOSgY5qkuroK15qW24MpG1QT0nlodg83pqJQ7SqN8sFSSlnyWbB9/e WgAleEaJb6eNsiB0tncOslc5edI0IwEqEsIt2jhDIU7Lx3YGV/e5Z8J+tGrS7KY/WTbZXml8S6k9 RP44JI/Lrz/dbi+o9aqxTTj91StVRjj3JiboZ+oyLZmK1JEr04Deh+kZFpAHreKig4YhFreJr+lv ZMytmKdptyiFxEPn9mldZKYK2JaX5Ai1zR24awIDAQABo4ICITCCAh0wHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOupdX9c9crYS2uhB8HzOIVzTjg1MA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAqBgNVHREEIzAhgR9hbmRyZXcubGFuZ2VAYWxjYXRl bC1sdWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBO6f2sinZnDK3Vlh4lSGYGFE8YsBp8EIsA uFJQv7L4vsK9Y5DIO2pvAzjpKAaVe0gugQfyEAjmVOFnC2AvbWDaUYggZcX5WwzTP4aHHcVi8koB EQl6yEHtImNANjg67Q/twyjKtxHbt/7bdFFO/I/KwnGA1m2pu+WbQYpR/mGYc2uL/xuhMi5XfHLd WLeSLKB5pnLb30KuimuvXcNWKbSUO5wi8R4ihRHKTQo/VqUbd+qLk9lZyx2quSyjhZ5YzBkjnrey RU8WpBpQ2/1kB/iki8XVnUnkS5SyMcHz5eUpmWL08GfVqcU7phFLrGNOkQq0ztyYYh9MRrjlUG66 0VAEMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMAkGBSsOAwIaBQCgggIP MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIyMzAyNTA0Mlow IwYJKoZIhvcNAQkEMRYEFMgiEPDVHkhwY9pv/tifsY6a6V8KMIHVBgkrBgEEAYI3EAQxgccwgcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1 c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANkk 3Bz8IBVI88pmeeStMMswDQYJKoZIhvcNAQEBBQAEggEAGqfzC3HqHtpt1sCfe8ODSJXpIx2dA7PC IELfaLPIYeSfvaPrCCZk9IcsT1P3WA6tY3NcQs20bjzPte0+PaosGdGQnCbLBgjpxZQseWbfXGsu XPBfOap3wzP3rr6t1faKAhYk17klSKbu0nJH57FyGP/iHWLdRU/UStfCayLIf/KLRXQPFb3nNLAK Pqtw0YFAkPFsphBySrMJTsZ83rB+8NpWOL6K8sTLzOEIXr0rdFOO1vna9bYNF2fFZCmMNoJAbWVO 0cVAM4gl20EMpfFilFD/UyEy6t8suzFX+XEa6Comf8cm1ufw7QCNgiDodXV7ozYRGyPG1lCF0eUh h984zgAAAAAAAA== --Apple-Mail-23-147178570-- From randy@psg.com Tue Feb 22 19:07:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67603A697E for ; Tue, 22 Feb 2011 19:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAmmUWRGWB+r for ; Tue, 22 Feb 2011 19:07:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CB73F3A67FF for ; Tue, 22 Feb 2011 19:07:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ps55R-000FH7-Pq; Wed, 23 Feb 2011 03:08:22 +0000 Date: Wed, 23 Feb 2011 11:08:20 +0800 Message-ID: From: Randy Bush To: Andrew Lange In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 03:07:41 -0000 > What is the current "diameter" of the Internet? From my recollections > it was converging toward about 4 ASes in diameter. that was the mean, not the diameter. not counting prepends and other kink, the effective diameter is considerably larger. randy From randy@psg.com Tue Feb 22 19:10:27 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112A73A698A for ; Tue, 22 Feb 2011 19:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxKEi7YzLboX for ; Tue, 22 Feb 2011 19:10:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2E6EF3A6985 for ; Tue, 22 Feb 2011 19:10:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Ps589-000FIA-Rl; Wed, 23 Feb 2011 03:11:10 +0000 Date: Wed, 23 Feb 2011 11:11:08 +0800 Message-ID: From: Randy Bush To: Andrew Lange In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 03:10:27 -0000 > If we have already authenticated the route origin, with either offline > or online enforcement depending on your preference, we have > cryptographically bound a route object to an aut num. btw, the sidr work to date has not formally bound the route origin. it is informal, and easily spoofed. the sidr work to date only deals with the simple fat finger problem. randy From ggm+ietf@apnic.net Wed Feb 23 01:56:40 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D828A3A677E for ; Wed, 23 Feb 2011 01:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.935 X-Spam-Level: X-Spam-Status: No, score=-98.935 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7JsQciROyUL for ; Wed, 23 Feb 2011 01:56:40 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 6CCBE3A65A6 for ; Wed, 23 Feb 2011 01:56:39 -0800 (PST) Received: from [203.119.76.137] (unknown [203.119.76.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C57BBB6685 for ; Wed, 23 Feb 2011 19:57:23 +1000 (EST) From: George Michaelson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Feb 2011 17:57:20 +0800 Message-Id: To: sidr wg Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [sidr] PKIX Observations on CRL (and Manifest) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 09:56:41 -0000 PKIX is discussing the effect of a missing CRL at the moment. It appears some people doing relying party tests in 5280 over-interpret = the non-availability of a CRL as a hard-fail, and treat the CA products = as invalid, in a belief that 5280 requires this of them.=20 But, this is not actually required. And in like sense, it would not be = required of a manifest. There are of course certain questions regarding signed products which = become unanswerable in the face of not having a manifest, or a CRL, but = they are not hard-fails which would invalidate the entire object set, = and by extension, the sub-tree of child products ad infinitum. section 6. Local Cache Maintenance of the ARCH document does place an = onus on a cache administrator to review the CRL/Manifest products and = detect corruption, but its not presented as a strong/normative = validation issue. Can I ask relying party tool writers to consider this in their tools? = Warnings are useful, but over-aggressive pruning or de-validation would = not be good. cheers -George From tim@ripe.net Wed Feb 23 02:10:36 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6B83A67CF for ; Wed, 23 Feb 2011 02:10:36 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNUypOgLiYW3 for ; Wed, 23 Feb 2011 02:10:35 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 38E023A69CD for ; Wed, 23 Feb 2011 02:10:35 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PsBgj-0004zM-0Y; Wed, 23 Feb 2011 11:11:18 +0100 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PsBgi-0000iR-UB; Wed, 23 Feb 2011 11:11:16 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Wed, 23 Feb 2011 11:11:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <441FE1E6-E79C-4605-8E35-7888AA4EF2B8@ripe.net> References: To: George Michaelson X-Mailer: Apple Mail (2.1082) 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: 784d7acfe6559f2a0b602ec6519a07197586b851e0bef5e72bdb75c97921186a Cc: sidr wg Subject: Re: [sidr] PKIX Observations on CRL (and Manifest) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 10:10:36 -0000 Hi, On Feb 23, 2011, at 10:57 AM, George Michaelson wrote: > Can I ask relying party tool writers to consider this in their tools? = Warnings are useful, but over-aggressive pruning or de-validation would = not be good. Yes. Our current implementation is indeed over-aggressive but it's on = our list to sedate it. Cheers Tim= From tim@ripe.net Wed Feb 23 02:26:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4CF3A6832 for ; Wed, 23 Feb 2011 02:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kN01jpMaZcp for ; Wed, 23 Feb 2011 02:26:18 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 95C8A3A683E for ; Wed, 23 Feb 2011 02:26:17 -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 1PsBvw-0004zT-Re; Wed, 23 Feb 2011 11:27:02 +0100 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1PsBvw-0004O7-Kg; Wed, 23 Feb 2011 11:27:00 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <441FE1E6-E79C-4605-8E35-7888AA4EF2B8@ripe.net> Date: Wed, 23 Feb 2011 11:26:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <65358801-8D6B-4C63-B361-E09F87BF5319@ripe.net> References: <441FE1E6-E79C-4605-8E35-7888AA4EF2B8@ripe.net> To: George Michaelson X-Mailer: Apple Mail (2.1082) 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: 784d7acfe6559f2a0b602ec6519a0719316d5aeecb78c4c6885695ad5c6fe77c Cc: sidr wg Subject: Re: [sidr] PKIX Observations on CRL (and Manifest) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 10:26:19 -0000 On Feb 23, 2011, at 11:11 AM, Tim Bruijnzeels wrote: > On Feb 23, 2011, at 10:57 AM, George Michaelson wrote: >> Can I ask relying party tool writers to consider this in their tools? = Warnings are useful, but over-aggressive pruning or de-validation would = not be good. >=20 > Yes. Our current implementation is indeed over-aggressive but it's on = our list to sedate it. Having said that... yes we will sedate it, in particular with regards to = *stale* manifests and CRLs which now result in 'invalid'. Missing CRLs I = am not sure of yet, but it can be considered. Missing manifests are problematic. Manifests are required by the = res-cert draft: http://tools.ietf.org/html/draft-ietf-sidr-res-certs-21#section-4.9.8.1 In our implementation we use the manifests to do top-down validation. = I.e. for a TA we look in the manifest to find all published objects and = child CA certs. The child CA certs have manifests listing their stuff = and so on.. This is the easiest way do a recursive top-down validation. = (Note that we also pre-fetch the directory for efficiency, but we only = process the items listed on the manifest) Since the res-cert draft = requires manifests I think this should be okay. If this assumption is = wrong, please speak up.. I think, but don't know for sure, that other RP = tools are using a similar approach. Cheers Tim= From Sandra.Murphy@cobham.com Wed Feb 23 02:51:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00A073A6870 for ; Wed, 23 Feb 2011 02:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N55XkY3n+Liv for ; Wed, 23 Feb 2011 02:51:51 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id EB6F53A6859 for ; Wed, 23 Feb 2011 02:51:50 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1NAqZ5K015091; Wed, 23 Feb 2011 04:52:35 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1NAqZL3014974; Wed, 23 Feb 2011 04:52:35 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.0.106]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 05:52:34 -0500 Date: Wed, 23 Feb 2011 05:52:33 -0500 (Eastern Standard Time) From: Sandra Murphy To: Andrew Lange In-Reply-To: Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 23 Feb 2011 10:52:34.0649 (UTC) FILETIME=[C716CC90:01CBD347] Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 10:51:52 -0000 On Tue, 22 Feb 2011, Andrew Lange wrote: > To divert the discussion a bit back into the realm of requirements. > > What is the current "diameter" of the Internet? From my recollections it was converging toward about 4 ASes in diameter. This would mean that for most paths we have: > > AS_A <--> AS_B <--> AS_C <--> AS_D > > If we have already authenticated the route origin, with either offline or online enforcement depending on your preference, we have cryptographically bound a route object to an aut num. Okay, this is good. This is the current scope of the work. Now it's tougher for people to fake announcements, intentionally or otherwise. This solves a lot of the problem. > > Now, next step, we're looking at cryptographically signing the AS PATH, but as Russ points out that isn't really what we want, at least I don't think it is. What we seem to be trying to get at is what is to vet the relationship between the ASes in the list. For example, is AS_B really an upstream of AS_A? And it is therefore plausible that they would legitimately want to announce AS_A's routes. "Plausible" is a rather weak security property. Is that your recommendation of what you want out of a secure solution from this working group? --Sandy > > Of course, as Shane points out, there is absolutely no way in BGP (nor should their be, IMHO), of expressing the actual relationship between AS_A and AS_B. They could be peers, confeds, paid peers, customers, etc. > > The requirement seems to be the ability to cryptographically sign an object expressing the relationship between AS_A and AS_B. Is AS_B allowed, by AS_A, to announce AS_A's routes? > > BGP seems impractical as a mechanism, however, we could use RPSL to do this. We simply offer the origin AS, in this case AS_A, an option to express it's commercial relationship with its upstreams (or vice versa). It can say "AS_B" can announce these routes, AS_Q can announce these, etc. Yes, this does require that we announce "confidential" information, but, being realistic, anyone can figure most of this out by looking at a routing table. > > Given the small diameter, then we've solved 90% of the problem, as we only have to then trust the big carriers in the core. If AS_B and AS_C are Level 3 and Verizon, we can be reasonably assured that they will get things right more often than not. They've been doing this a while, and tend to know what they are doing. There is strong commercial pressure not to blow it, and become subject to an attack or a highly visible misconfiguration. > > Andrew > > On Feb 22, 2011, at 8:40 AM, Sandra Murphy wrote: > >> Randy, please do not indulge in ad-hominem attacks. It does nothing to >> help in finding the right answer. >> >> --Sandy >> >> On Tue, 22 Feb 2011, Randy Bush wrote: >> >>>> |So the only security problem anyone faces, currently, is people cheating >>>> |on the AS Path length? >>>> >>>> I thougth my previous post (as well as other) have been pretty clear on >>>> this topic. >>> >>> they were. you are dealing with a one man dos. do not feed the troll. >>> >>> randy >>> _______________________________________________ >>> 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 jgs@bgp.nu Wed Feb 23 07:30:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E72A3A68F3; Wed, 23 Feb 2011 07:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpaULYzgpFYI; Wed, 23 Feb 2011 07:30:28 -0800 (PST) Received: from bgp.nu (bgp.nu [216.117.214.198]) by core3.amsl.com (Postfix) with ESMTP id BF7863A689A; Wed, 23 Feb 2011 07:30:28 -0800 (PST) Received: from sa-nc-apg-254.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 59F601614755; Wed, 23 Feb 2011 10:31:14 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: Date: Wed, 23 Feb 2011 17:31:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:30:29 -0000 On Feb 16, 2011, at 7:53 PM, Christopher Morrow wrote: [...] > The purpose of the SIDR working group is to reduce vulnerabilities in > the inter-domain routing system. The two vulnerabilities that will be > addressed are: >=20 > * Is an Autonomous System (AS) authorized to originate an IP prefix > * Is the AS-Path represented in the route the same as the path > through which the route update traveled [...] I think this is a fine charter expansion. We could discuss other = variants until the cows come home (oh wait, done that) but at some point = we have to stop debating metaphysics, pick a goal and execute. This one = seems reasonable. --John= From sra@hactrn.net Wed Feb 23 10:30:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6E53A6929 for ; Wed, 23 Feb 2011 10:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 657ELMAg+DdL for ; Wed, 23 Feb 2011 10:30:14 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 2312C3A6951 for ; Wed, 23 Feb 2011 10:30:11 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 75E592844C for ; Wed, 23 Feb 2011 18:30:56 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 328A722829 for ; Wed, 23 Feb 2011 13:30:56 -0500 (EST) Date: Wed, 23 Feb 2011 13:30:56 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110223183056.328A722829@thrintun.hactrn.net> Subject: Re: [sidr] PKIX Observations on CRL (and Manifest) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 18:30:16 -0000 draft-ietf-sidr-res-certs is pretty clear about requiring the validator to check for certificate revocation, which implies that the validator cannot proceed without the relevant CRL. As Tim points out, the effective definition of an object being in the collection of a certificate's is that it is present in the manifest; the only other way of defining the product collection even with rsync is to trawl the directory, which may find other objects, including objects deliberately omitted from the manifest; with an alternative protocol such as HTTP (if people are even still thinking about that) there is no standard way of trawling the directory at all. So I do not think it makes sense to make the presence of either CRL or manifest optional in any sense here. Allowing stale CRL and manifest, sure. My validator already allows that, in fact that's the default setting, you have to add explicit configuration to get it to reject anything just because of stale CRLs or manifests. As I think I understand it, this is consistent with the advice we've gotten for years from the PKI experts. From shane@castlepoint.net Wed Feb 23 11:56:43 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1023A6A22 for ; Wed, 23 Feb 2011 11:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCIPQpiL4Phw for ; Wed, 23 Feb 2011 11:56:42 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 15CDC3A6813 for ; Wed, 23 Feb 2011 11:56:41 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 756A52684EA; Wed, 23 Feb 2011 12:57:29 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 23 Feb 2011 12:57:29 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=58046; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 23 Feb 2011 12:57:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15E88519-A211-4F6C-8CA4-CDEAAA5B1C32@castlepoint.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1082) Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 19:56:43 -0000 Randy, On Feb 22, 2011, at 20:11 MST, Randy Bush wrote: >> If we have already authenticated the route origin, with either = offline >> or online enforcement depending on your preference, we have >> cryptographically bound a route object to an aut num. >=20 > btw, the sidr work to date has not formally bound the route origin. = it > is informal, and easily spoofed. the sidr work to date only deals = with > the simple fat finger problem. Can you clarify what you mean by "the sidr work to date has not formally = bound the route origin ... and [is] easily spoofed"? I thought the entire goal of the RPKI and, more importantly, the objects = that it holds attest to the 'authorization' to originate a route? In = particular, I refer to the following in Section 3.1 of = http://tools.ietf.org/html/draft-ietf-sidr-arch-12: ---snip--- A ROA is an attestation that the holder of a set of prefixes has authorized an autonomous system to originate routes for those prefixes. A ROA is structured according to the format described in [ROA-FORM]. The validity of this authorization depends on the signer of the ROA being the holder of the prefix(es) in the ROA; this fact is asserted by an end-entity certificate from the PKI, whose corresponding private key is used to sign the ROA. ---snip--- Perhaps there's a subtle _security_ nuance that I'm missing in your = statement? Thanks, -shane= From Sandra.Murphy@cobham.com Wed Feb 23 12:25:47 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6369F3A6A5B for ; Wed, 23 Feb 2011 12:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRKS3Eiij-wU for ; Wed, 23 Feb 2011 12:25:46 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4F0EB3A6A44 for ; Wed, 23 Feb 2011 12:25:45 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p1NKQ6EG024100; Wed, 23 Feb 2011 14:26:06 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p1NKQ6fj005020; Wed, 23 Feb 2011 14:26:06 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.124]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 15:26:05 -0500 Date: Wed, 23 Feb 2011 15:26:04 -0500 (Eastern Standard Time) From: Sandra Murphy To: Shane Amante In-Reply-To: <15E88519-A211-4F6C-8CA4-CDEAAA5B1C32@castlepoint.net> Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <15E88519-A211-4F6C-8CA4-CDEAAA5B1C32@castlepoint.net> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 23 Feb 2011 20:26:06.0044 (UTC) FILETIME=[E5E0F9C0:01CBD397] Cc: Andrew Lange , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 20:25:47 -0000 On Wed, 23 Feb 2011, Shane Amante wrote: > Randy, > > On Feb 22, 2011, at 20:11 MST, Randy Bush wrote: >>> If we have already authenticated the route origin, with either offline >>> or online enforcement depending on your preference, we have >>> cryptographically bound a route object to an aut num. >> >> btw, the sidr work to date has not formally bound the route origin. it >> is informal, and easily spoofed. the sidr work to date only deals with >> the simple fat finger problem. > > Can you clarify what you mean by "the sidr work to date has not formally bound the route origin ... and [is] easily spoofed"? This is something that has been mentioned in the wg many times, so I'll answer. It is quite easy for an AS to construct an AS_PATH with the legitimate authorized origin on the origin end, without every having received such an announcement from the origin. Without the legitimate origin ever having actually made the announcement to anyone, even. That's why path validation is important. You really would like some assurance that the origin actually announced the prefix *and* announced it to the party that appears tp have propagated it onward. > > I thought the entire goal of the RPKI and, more importantly, the objects that it holds attest to the 'authorization' to originate a route? In particular, I refer to the following in Section 3.1 of http://tools.ietf.org/html/draft-ietf-sidr-arch-12: Authorization yes but not authentication. You know the origin AS is authorized to announce the prefix but you don't know that the announcement is authentic. Any other AS could produce a route that looks like the legitimate origin made the announcement when they did not. When this is pointed out, I always remind people: Even though origin authorization is not the end game, it is a vital necesary crucial important first step without which nothing else could succeed. I.e., we are not wasteing our time here. --Sandy > ---snip--- > A ROA is an attestation that the holder of a set of prefixes has > authorized an autonomous system to originate routes for those > prefixes. A ROA is structured according to the format described in > [ROA-FORM]. The validity of this authorization depends on the signer > of the ROA being the holder of the prefix(es) in the ROA; this fact > is asserted by an end-entity certificate from the PKI, whose > corresponding private key is used to sign the ROA. > ---snip--- > > Perhaps there's a subtle _security_ nuance that I'm missing in your statement? > > Thanks, > > -shane From kent@bbn.com Wed Feb 23 14:02:08 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E743A68FD for ; Wed, 23 Feb 2011 14:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOxqbGEh9HyC for ; Wed, 23 Feb 2011 14:02:07 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C6C183A67FC for ; Wed, 23 Feb 2011 14:02:07 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:46265 helo=[210.245.149.101]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsMnO-000OmR-RA; Wed, 23 Feb 2011 17:02:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 23 Feb 2011 16:55:40 -0500 To: George Michaelson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg Subject: Re: [sidr] PKIX Observations on CRL (and Manifest) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 22:02:08 -0000 At 5:57 PM +0800 2/23/11, George Michaelson wrote: >PKIX is discussing the effect of a missing CRL at the moment. > >It appears some people doing relying party tests in 5280 >over-interpret the non-availability of a CRL as a hard-fail, and >treat the CA products as invalid, in a belief that 5280 requires >this of them. > >But, this is not actually required. And in like sense, it would not >be required of a manifest. > >There are of course certain questions regarding signed products >which become unanswerable in the face of not having a manifest, or a >CRL, but they are not hard-fails which would invalidate the entire >object set, and by extension, the sub-tree of child products ad >infinitum. > >section 6. Local Cache Maintenance of the ARCH document does place >an onus on a cache administrator to review the CRL/Manifest products >and detect corruption, but its not presented as a strong/normative >validation issue. > >Can I ask relying party tool writers to consider this in their >tools? Warnings are useful, but over-aggressive pruning or >de-validation would not be good. > >cheers > >-George The BBN RP software embodies the notion of stale (vs. expired) CRLs and manifests. Mark and Andrew are authoritative on this matter, but my recollection is that we give the RP knobs to control how they choose to deal with stale items, maybe even based on te degree of staleness. Steve From andrew.lange@alcatel-lucent.com Wed Feb 23 15:16:35 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5B173A6945 for ; Wed, 23 Feb 2011 15:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZrMyiOZNOJv for ; Wed, 23 Feb 2011 15:16:34 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 8E2563A688E for ; Wed, 23 Feb 2011 15:16:33 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p1NNHLES014909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 17:17:21 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1NNHKmq008178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Feb 2011 17:17:20 -0600 Received: from neo-119.vpn.ind.alcatel.com (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 23 Feb 2011 17:17:19 -0600 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-84-220770990"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew Lange In-Reply-To: Date: Wed, 23 Feb 2011 15:17:14 -0800 Message-ID: <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1082) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 23:16:35 -0000 --Apple-Mail-84-220770990 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sandy, Reply is inline. On Feb 23, 2011, at 2:52 AM, Sandra Murphy wrote: > On Tue, 22 Feb 2011, Andrew Lange wrote: >=20 >> To divert the discussion a bit back into the realm of requirements. >>=20 >> What is the current "diameter" of the Internet? =46rom my = recollections it was converging toward about 4 ASes in diameter. This = would mean that for most paths we have: >>=20 >> AS_A <--> AS_B <--> AS_C <--> AS_D >>=20 >> If we have already authenticated the route origin, with either = offline or online enforcement depending on your preference, we have = cryptographically bound a route object to an aut num. Okay, this is = good. This is the current scope of the work. Now it's tougher for = people to fake announcements, intentionally or otherwise. This solves a = lot of the problem. >>=20 >> Now, next step, we're looking at cryptographically signing the AS = PATH, but as Russ points out that isn't really what we want, at least I = don't think it is. What we seem to be trying to get at is what is to = vet the relationship between the ASes in the list. For example, is AS_B = really an upstream of AS_A? And it is therefore plausible that they = would legitimately want to announce AS_A's routes. >=20 > "Plausible" is a rather weak security property. Is that your=20 > recommendation of what you want out of a secure solution from this = working=20 > group? Given the thread, I can understand your frustration. And, I could have = made myself more clear. I'll try: given the policies that AS_B might = be implementing, we cannot know for certain, without AS_B publishing = their policies, if AS_B should in fact be announcing which of AS_A's = routes or in what form, hence the use of the term "Plausible."=20 I agree "Plausible" is not security property, but a business/routing = policy. =46rom a work item perspective, it would be useful to have a = relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q = as legitimate connections." This information, combined with AS_A's = signed route-objects means that downstream ASes would be able to verify = that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, AS_B] or = [AS_A, AS_Q] would be AS PATHs that could be authorized. Effectively = solving the Origin + Upstream issue would solve most of the problems. = Yes, someone could then spoof an announcement of origin+upstream+self, = but then we're looking at a minimum of a 3-AS path and the likelihood of = that being best drops. We can also do this with a simple route-filter = and does not require on-system crypto calculations. Andrew > --Sandy >=20 >>=20 >> Of course, as Shane points out, there is absolutely no way in BGP = (nor should their be, IMHO), of expressing the actual relationship = between AS_A and AS_B. They could be peers, confeds, paid peers, = customers, etc. >>=20 >> The requirement seems to be the ability to cryptographically sign an = object expressing the relationship between AS_A and AS_B. Is AS_B = allowed, by AS_A, to announce AS_A's routes? >>=20 >> BGP seems impractical as a mechanism, however, we could use RPSL to = do this. We simply offer the origin AS, in this case AS_A, an option to = express it's commercial relationship with its upstreams (or vice versa). = It can say "AS_B" can announce these routes, AS_Q can announce these, = etc. Yes, this does require that we announce "confidential" = information, but, being realistic, anyone can figure most of this out by = looking at a routing table. >>=20 >> Given the small diameter, then we've solved 90% of the problem, as we = only have to then trust the big carriers in the core. If AS_B and AS_C = are Level 3 and Verizon, we can be reasonably assured that they will get = things right more often than not. They've been doing this a while, and = tend to know what they are doing. There is strong commercial pressure = not to blow it, and become subject to an attack or a highly visible = misconfiguration. >>=20 >> Andrew >>=20 >> On Feb 22, 2011, at 8:40 AM, Sandra Murphy wrote: >>=20 >>> Randy, please do not indulge in ad-hominem attacks. It does nothing = to >>> help in finding the right answer. >>>=20 >>> --Sandy >>>=20 >>> On Tue, 22 Feb 2011, Randy Bush wrote: >>>=20 >>>>> |So the only security problem anyone faces, currently, is people = cheating >>>>> |on the AS Path length? >>>>>=20 >>>>> I thougth my previous post (as well as other) have been pretty = clear on >>>>> this topic. >>>>=20 >>>> they were. you are dealing with a one man dos. do not feed the = troll. >>>>=20 >>>> randy >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >>=20 --Apple-Mail-84-220770990 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggZFMIIFLaAD AgECAhEA2STcHPwgFUjzymZ55K0wyzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA0MTQwMDAw MDBaFw0xMTA0MTQyMzU5NTlaMIHnMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEVMBMGA1UEAxMMQW5kcmV3IExhbmdlMS4wLAYJKoZIhvcNAQkBFh9hbmRyZXcu bGFuZ2VAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA zpUVaYV8lZ/sTUuCmVWLjpnZLO7Wfjs3QxQ/5bX6L8xkGdL5jhnDpuaI9ta4T+NuPO/AY07kaOUD 87n/Ze2TF4+rwLT48JXoxiJOSgY5qkuroK15qW24MpG1QT0nlodg83pqJQ7SqN8sFSSlnyWbB9/e WgAleEaJb6eNsiB0tncOslc5edI0IwEqEsIt2jhDIU7Lx3YGV/e5Z8J+tGrS7KY/WTbZXml8S6k9 RP44JI/Lrz/dbi+o9aqxTTj91StVRjj3JiboZ+oyLZmK1JEr04Deh+kZFpAHreKig4YhFreJr+lv ZMytmKdptyiFxEPn9mldZKYK2JaX5Ai1zR24awIDAQABo4ICITCCAh0wHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOupdX9c9crYS2uhB8HzOIVzTjg1MA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAqBgNVHREEIzAhgR9hbmRyZXcubGFuZ2VAYWxjYXRl bC1sdWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBO6f2sinZnDK3Vlh4lSGYGFE8YsBp8EIsA uFJQv7L4vsK9Y5DIO2pvAzjpKAaVe0gugQfyEAjmVOFnC2AvbWDaUYggZcX5WwzTP4aHHcVi8koB EQl6yEHtImNANjg67Q/twyjKtxHbt/7bdFFO/I/KwnGA1m2pu+WbQYpR/mGYc2uL/xuhMi5XfHLd WLeSLKB5pnLb30KuimuvXcNWKbSUO5wi8R4ihRHKTQo/VqUbd+qLk9lZyx2quSyjhZ5YzBkjnrey RU8WpBpQ2/1kB/iki8XVnUnkS5SyMcHz5eUpmWL08GfVqcU7phFLrGNOkQq0ztyYYh9MRrjlUG66 0VAEMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMAkGBSsOAwIaBQCgggIP MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIyMzIzMTcxNFow IwYJKoZIhvcNAQkEMRYEFE/lVFYOjOtsRSziv0f3f/wIu2bSMIHVBgkrBgEEAYI3EAQxgccwgcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1 c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANkk 3Bz8IBVI88pmeeStMMswDQYJKoZIhvcNAQEBBQAEggEADaLEuac9MIKlmkrvBuBvQ4V2IS2KDTx1 8dCqRzasZK6RZKwqzc69JaPROw1u7UIOx3PtzGWEyZaIDSdZ6bHz0V8vqk1wNS9/KJgNj6c7lXnf GhGHMHlAaLTYq/pZywHfvXbLBfj+jN+kkOpOlXIet5Cqlj4kbYKAi7/7jRPOkEHR/bOZHgeynkU3 2v7OwCmwr3tDxtQ0IF+o4rYPo+SAkXXlR6LXcw05Nun/eqw4qtMhqaU1DCEdxJ6VfnX3HuDs4D5+ QnT1WIPdpfAMO6hr+mh5dKHJSfO0XO6V7rRoYNM1tiC9MPmxfzvIy6lFeXDMOXZ8WPlHp6vjS16X HFnXxAAAAAAAAA== --Apple-Mail-84-220770990-- From robertl@apnic.net Wed Feb 23 16:08:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B34A3A6911 for ; Wed, 23 Feb 2011 16:08:42 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+pqie3HgbhQ for ; Wed, 23 Feb 2011 16:08:41 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 9BCC03A6860 for ; Wed, 23 Feb 2011 16:08:39 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:21f:5bff:fef1:8eb9] (unknown [IPv6:2001:dc0:a000:4:21f:5bff:fef1:8eb9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id BE28CB67B5; Thu, 24 Feb 2011 10:09:25 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Loomans In-Reply-To: <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> Date: Thu, 24 Feb 2011 10:09:23 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4F6C2533-005B-4FF9-9EF0-6630570A3EC7@apnic.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> To: Andrew Lange X-Mailer: Apple Mail (2.1082) Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:08:42 -0000 On 24/02/2011, at 09:17, Andrew Lange wrote: > =46rom a work item perspective, it would be useful to have a = relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q = as legitimate connections."=20 Geoff published a (now expired) draft for just such an object: = http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03 Rob --=20 Robert Loomans email: robertl@apnic.net Senior Software Engineer, APNIC sip: robertl@voip.apnic.net http://www.apnic.net/ phone: +61 7 3858 3100 From randy@psg.com Wed Feb 23 16:15:36 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEAF3A6911 for ; Wed, 23 Feb 2011 16:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKV6aOQ4YMer for ; Wed, 23 Feb 2011 16:15:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 517B03A6860 for ; Wed, 23 Feb 2011 16:15:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=96.130.dhcp.conference.apricot.net.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PsOsT-000K4e-8R; Thu, 24 Feb 2011 00:16:17 +0000 Date: Thu, 24 Feb 2011 08:16:15 +0800 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <15E88519-A211-4F6C-8CA4-CDEAAA5B1C32@castlepoint.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <15E88519-A211-4F6C-8CA4-CDEAAA5B1C32@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:15:36 -0000 > Can you clarify what you mean by "the sidr work to date has not > formally bound the route origin ... and [is] easily spoofed"? rpki has roa binding prefix P to asn A0. i run A1. i inject a route for P with as-path A1 A0. the origin, A0, is what the roa allows, but has no crypto sig. that is sidr work to date. stops fat fingers but not the simplest of path attacks. randy From gih@apnic.net Wed Feb 23 16:16:20 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34783A691A for ; Wed, 23 Feb 2011 16:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIvaLCYuwyAC for ; Wed, 23 Feb 2011 16:16:20 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8BECF3A65A5 for ; Wed, 23 Feb 2011 16:16:19 -0800 (PST) Received: from [10.0.0.33] (unknown [125.215.218.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 12DE2B6740; Thu, 24 Feb 2011 10:17:03 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4F6C2533-005B-4FF9-9EF0-6630570A3EC7@apnic.net> Date: Thu, 24 Feb 2011 08:16:58 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <4F6C2533-005B-4FF9-9EF0-6630570A3EC7@apnic.net> To: Andrew Lange X-Mailer: Apple Mail (2.1082) Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:16:20 -0000 On 24/02/2011, at 8:09 AM, Robert Loomans wrote: >=20 > On 24/02/2011, at 09:17, Andrew Lange wrote: >=20 >> =46rom a work item perspective, it would be useful to have a = relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q = as legitimate connections."=20 >=20 > Geoff published a (now expired) draft for just such an object: = http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03 >=20 and I can push it out again. Andrew, I assume you are serious in claiming that this would be useful = to have in this context. Geoff From andrew.lange@alcatel-lucent.com Wed Feb 23 17:12:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57F83A67A3 for ; Wed, 23 Feb 2011 17:12:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn7NHgIviQpD for ; Wed, 23 Feb 2011 17:12:48 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id F19DD3A679F for ; Wed, 23 Feb 2011 17:12:47 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p1O1DJp6017858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 19:13:28 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1O1DGAl017208 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Feb 2011 19:13:16 -0600 Received: from neo-119.vpn.ind.alcatel.com (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 23 Feb 2011 19:13:14 -0600 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-116-227710375"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew Lange In-Reply-To: Date: Wed, 23 Feb 2011 17:12:53 -0800 Message-ID: <5A3140DD-1358-4F65-88FD-E1B10AF991E1@alcatel-lucent.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <4F6C2533-005B-4FF9-9EF0-6630570A3EC7@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1082) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 01:12:49 -0000 --Apple-Mail-116-227710375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Geoff, Do you disagree as to its utility?=20 Andrew On Feb 23, 2011, at 4:16 PM, Geoff Huston wrote: >=20 > On 24/02/2011, at 8:09 AM, Robert Loomans wrote: >=20 >>=20 >> On 24/02/2011, at 09:17, Andrew Lange wrote: >>=20 >>> =46rom a work item perspective, it would be useful to have a = relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q = as legitimate connections."=20 >>=20 >> Geoff published a (now expired) draft for just such an object: = http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03 >>=20 >=20 > and I can push it out again. >=20 > Andrew, I assume you are serious in claiming that this would be useful = to have in this context. >=20 > Geoff >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-116-227710375 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggZFMIIFLaAD AgECAhEA2STcHPwgFUjzymZ55K0wyzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA0MTQwMDAw MDBaFw0xMTA0MTQyMzU5NTlaMIHnMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEVMBMGA1UEAxMMQW5kcmV3IExhbmdlMS4wLAYJKoZIhvcNAQkBFh9hbmRyZXcu bGFuZ2VAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA zpUVaYV8lZ/sTUuCmVWLjpnZLO7Wfjs3QxQ/5bX6L8xkGdL5jhnDpuaI9ta4T+NuPO/AY07kaOUD 87n/Ze2TF4+rwLT48JXoxiJOSgY5qkuroK15qW24MpG1QT0nlodg83pqJQ7SqN8sFSSlnyWbB9/e WgAleEaJb6eNsiB0tncOslc5edI0IwEqEsIt2jhDIU7Lx3YGV/e5Z8J+tGrS7KY/WTbZXml8S6k9 RP44JI/Lrz/dbi+o9aqxTTj91StVRjj3JiboZ+oyLZmK1JEr04Deh+kZFpAHreKig4YhFreJr+lv ZMytmKdptyiFxEPn9mldZKYK2JaX5Ai1zR24awIDAQABo4ICITCCAh0wHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOupdX9c9crYS2uhB8HzOIVzTjg1MA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAqBgNVHREEIzAhgR9hbmRyZXcubGFuZ2VAYWxjYXRl bC1sdWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBO6f2sinZnDK3Vlh4lSGYGFE8YsBp8EIsA uFJQv7L4vsK9Y5DIO2pvAzjpKAaVe0gugQfyEAjmVOFnC2AvbWDaUYggZcX5WwzTP4aHHcVi8koB EQl6yEHtImNANjg67Q/twyjKtxHbt/7bdFFO/I/KwnGA1m2pu+WbQYpR/mGYc2uL/xuhMi5XfHLd WLeSLKB5pnLb30KuimuvXcNWKbSUO5wi8R4ihRHKTQo/VqUbd+qLk9lZyx2quSyjhZ5YzBkjnrey RU8WpBpQ2/1kB/iki8XVnUnkS5SyMcHz5eUpmWL08GfVqcU7phFLrGNOkQq0ztyYYh9MRrjlUG66 0VAEMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMAkGBSsOAwIaBQCgggIP MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIyNDAxMTI1NFow IwYJKoZIhvcNAQkEMRYEFAQKyrTqvH26jFfnRzLKX2hujhbDMIHVBgkrBgEEAYI3EAQxgccwgcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1 c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANkk 3Bz8IBVI88pmeeStMMswDQYJKoZIhvcNAQEBBQAEggEAqMQjNSuOp28gE7/6devzVzbExzBnsszh oP1bnCMNlaKhOfQ8Nq7xaL+y/kQHoC4kn+mvZN0Xh7YoXlCBJXT5GhX70Cv3rBJzLgc1yg3D63SW e1Q7vpHUc9bQODq1GPWryDomWABwuI290dbfUVIIo2LcZYzE5sRhLdBvhhU3KEmZ/k2h7NosgCF8 DWsFs4mRpEFFCllXK7u8JCe5d3A2W8qmi37W/1HikjQQVRXm0TFuBXs196Arq+nVdlw+CSqFoI2Q W5uMFDYcJkhfAM0qv1OqQrMpPASGUhhxdB6+BfVDRgLyje43nnRe7FDUHA5ZctRvzKNbQZABOPKx oIlOigAAAAAAAA== --Apple-Mail-116-227710375-- From gih@apnic.net Wed Feb 23 18:00:53 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23043A692F for ; Wed, 23 Feb 2011 18:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.909 X-Spam-Level: X-Spam-Status: No, score=-96.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_HCC=4.295, HOST_EQ_DHCP=1.295, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ2iRt9+lot4 for ; Wed, 23 Feb 2011 18:00:52 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C245A3A6929 for ; Wed, 23 Feb 2011 18:00:51 -0800 (PST) Received: from 186.128.dhcp.conference.apricot.net (186.128.dhcp.conference.apricot.net [169.223.128.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id CFFADB6740; Thu, 24 Feb 2011 12:01:36 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <5A3140DD-1358-4F65-88FD-E1B10AF991E1@alcatel-lucent.com> Date: Thu, 24 Feb 2011 10:01:33 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <481E716C-35F1-4197-BD8F-A41A86588508@apnic.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <4F6C2533-005B-4FF9-9EF0-6630570A3EC7@apnic.net> <5A3140DD-1358-4F65-88FD-E1B10AF991E1@alcatel-lucent.com> To: Andrew Lange X-Mailer: Apple Mail (2.1082) Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 02:00:53 -0000 Andrew, I hope I was neutral in neither agreeing or disagreeing as to its = utility in my comment. I was simply checking your assertion that "it would be useful to have a = relationship object" and gently trying to understand your reasoning = behind holding that view. Geoff On 24/02/2011, at 9:12 AM, Andrew Lange wrote: > Geoff, >=20 > Do you disagree as to its utility?=20 >=20 > Andrew >=20 > On Feb 23, 2011, at 4:16 PM, Geoff Huston wrote: >=20 >>=20 >> On 24/02/2011, at 8:09 AM, Robert Loomans wrote: >>=20 >>>=20 >>> On 24/02/2011, at 09:17, Andrew Lange wrote: >>>=20 >>>> =46rom a work item perspective, it would be useful to have a = relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q = as legitimate connections."=20 >>>=20 >>> Geoff published a (now expired) draft for just such an object: = http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03 >>>=20 >>=20 >> and I can push it out again. >>=20 >> Andrew, I assume you are serious in claiming that this would be = useful to have in this context. >>=20 >> Geoff >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From mreynold@bbn.com Wed Feb 23 18:10:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FF73A695B for ; Wed, 23 Feb 2011 18:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmSYw+-BoKzQ for ; Wed, 23 Feb 2011 18:10:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6390B3A6944 for ; Wed, 23 Feb 2011 18:10:29 -0800 (PST) Received: from dhcp89-081-246.bbn.com ([128.89.81.246]:2978 helo=mreynoldsxp) by smtp.bbn.com with smtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PsQfl-0006WD-DK; Wed, 23 Feb 2011 21:11:17 -0500 Message-ID: <0EE228E7514B4DDAB43A0FEA8A112D4D@cam.bbn.com> From: "Mark Reynolds" To: "Stephen Kent" References: Date: Wed, 23 Feb 2011 21:07:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: sidr wg Subject: Re: [sidr] PKIX Observations on CRL (and Manifest) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 02:10:30 -0000 >> >>Can I ask relying party tool writers to consider this in their >>tools? Warnings are useful, but over-aggressive pruning or >>de-validation would not be good. >> >>cheers >> >>-George > BBN's relying party software provides for configuration options that control how stale objects (CRLs, manifests) or missing objects (manifests) are treated. The operator can set these is a simple configuration file, can supply them on the command line, or can rely on the built-in defaults. Currently, the built-in defaults are the most strict: stale CRLs and stale manifests are rejected, and missing manifests are right out. - Mark From christopher.morrow@gmail.com Wed Feb 23 19:04:40 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB483A67E4 for ; Wed, 23 Feb 2011 19:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.451 X-Spam-Level: X-Spam-Status: No, score=-103.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhXhe9oA7S+I for ; Wed, 23 Feb 2011 19:04:39 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E53B23A67C2 for ; Wed, 23 Feb 2011 19:04:38 -0800 (PST) Received: by wwb39 with SMTP id 39so129103wwb.13 for ; Wed, 23 Feb 2011 19:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aaONwr/b+phLHb8wdYIcfH3m0cSuYBbVOTIG4HUe6eg=; b=D5n5+ci0UYvcir29+ZsjXI9phzL8yRf1r+qlwdm2ot/WEHGx6rHDqUAGXhz00JKll4 IKNJfHTMCDyNxvqTgcgf5F0SyXRA1uka92Qs8ubGojl24n2poQtpZJbCFDhCzm/Btody YFmco37jij/zwAiT2XkirLxOkPk+QDIhTeEDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=MxwXTBVO1TxELjv8t6738H4rZvF+cbA+GiNBgs1k+1PAjLAZsO5FSQeI03JxhSoKlv JEc3Gjr0hjIFqjmz/WFO0T/WJkY5qXtNO3jC+SVHNbkuo7MIt9w1AcowHLhAnJdo2Q95 Wgb3JY7i24A6BIfHjL2Gz/bhVCY8MXYGLyT5E= MIME-Version: 1.0 Received: by 10.216.160.84 with SMTP id t62mr193579wek.69.1298516726672; Wed, 23 Feb 2011 19:05:26 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Wed, 23 Feb 2011 19:05:26 -0800 (PST) In-Reply-To: <481E716C-35F1-4197-BD8F-A41A86588508@apnic.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <4F6C2533-005B-4FF9-9EF0-6630570A3EC7@apnic.net> <5A3140DD-1358-4F65-88FD-E1B10AF991E1@alcatel-lucent.com> <481E716C-35F1-4197-BD8F-A41A86588508@apnic.net> Date: Wed, 23 Feb 2011 22:05:26 -0500 X-Google-Sender-Auth: Ogu4GaEoMwQPP0AvxSTPDg5hkac Message-ID: From: Christopher Morrow To: Geoff Huston Content-Type: text/plain; charset=ISO-8859-1 Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 03:04:40 -0000 On Wed, Feb 23, 2011 at 9:01 PM, Geoff Huston wrote: > Andrew, > > I hope I was neutral in neither agreeing or disagreeing as to its utility in my comment. > > I was simply checking your assertion that "it would be useful to have a relationship object" and gently trying to understand your reasoning behind holding that view. > for my money, I see this as data that will quickly rot, with very little ability to really know if it's valid or not from an external perspective. Providing ROA data for netblocks, and attaching that to the notion of a tree of certificate data down from RIR -> NIR -> LIR -> EndUser should be 'simple', at least the mechanisms exist to keep this updated and validated are I think. I don't think we want to introduce more data that will root (IRR style). Back to path validation though, what should we target as important items to 'secure' (validate I think is the term I'd use), currently the reqs talk about: o AS_PATH o prefix/length Should, and why?, the relationship between ASN's be validated/used as well? I think the thought had been that the RPKI data + irr data would lead to better/easier prefix-list-style protections, so the relationship didn't need to be validated beyond the immediate 2 ASN's. -Chris > > On 24/02/2011, at 9:12 AM, Andrew Lange wrote: > >> Geoff, >> >> Do you disagree as to its utility? >> >> Andrew >> >> On Feb 23, 2011, at 4:16 PM, Geoff Huston wrote: >> >>> >>> On 24/02/2011, at 8:09 AM, Robert Loomans wrote: >>> >>>> >>>> On 24/02/2011, at 09:17, Andrew Lange wrote: >>>> >>>>> From a work item perspective, it would be useful to have a relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections." >>>> >>>> Geoff published a (now expired) draft for just such an object: http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03 >>>> >>> >>> and I can push it out again. >>> >>> Andrew, I assume you are serious in claiming that this would be useful to have in this context. >>> >>> Geoff >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> > > -- > > Geoff Huston > Chief Scientist, APNIC > > +61 7 3858 3100 > gih@apnic.net > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From shane@castlepoint.net Wed Feb 23 21:23:47 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 047273A69BE for ; Wed, 23 Feb 2011 21:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwY7tzIp64uL for ; Wed, 23 Feb 2011 21:23:45 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C967C3A69BD for ; Wed, 23 Feb 2011 21:23:45 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 3EA112684EA; Wed, 23 Feb 2011 22:24:34 -0700 (MST) Received: from mbp.castlepoint.net (65-101-254-35.hlrn.qwest.net [65.101.254.35]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 23 Feb 2011 22:24:33 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.254.35; client-port=60292; syn-fingerprint=65535:56:1:64:M1452,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 23 Feb 2011 22:24:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70C1A0FF-F284-45FA-96C5-191955DA036C@castlepoint.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <15E88519-A211-4F6C-8CA4-CDEAAA5B1C32@castlepoint.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1082) Cc: Andrew Lange , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 05:23:47 -0000 Sandy, Thank you for responding! Please see below. On Feb 23, 2011, at 13:26 MST, Sandra Murphy wrote: >> Can you clarify what you mean by "the sidr work to date has not = formally bound the route origin ... and [is] easily spoofed"? >=20 > This is something that has been mentioned in the wg many times, so = I'll answer. >=20 > It is quite easy for an AS to construct an AS_PATH with the legitimate = authorized origin on the origin end, without every having received such = an announcement from the origin. Without the legitimate origin ever = having actually made the announcement to anyone, even. >=20 > That's why path validation is important. You really would like some = assurance that the origin actually announced the prefix *and* announced = it to the party that appears tp have propagated it onward. Let's deconstruct this a little further to see if we can be more clear = on the reqmt's, (which feeds into the re-charter, etc. discussions). Fundamentally I think it comes down to this: What is the routing scope = for which SIDR intends to provide AS_PATH 'authorization'? The reason = I'm asking is, operationally, the more certain I can be of that = 'authority' the more inclined/obligated I will be to impose, say, = AS_PATH filtering based on that 'authority' to accept or drop those = prefixes in my routers. Alternatively, if we're just signing AS_PATH's, = but don't know how to operationally use (or, it's too = difficult/burdensome to use) those AS_PATH signatures at, for example, a = certain routing scope/distance ... then, why bother imposing those = signatures beyond a certain routing scope in the first place (increasing = cost/complexity of the routers and Ops in the process)? Specifically, what you've described above (I believe) only refers to = just the _origin_ of a particular announcement -- not a 'signature' over = the complete AS_PATH or a signature for each ASN in an entire AS_PATH. = I described my understanding of "origin" in my previous e-mail in this = thread, namely: a given [customer] ASN (AS_A) expresses its intent to = announce prefixes from that ASN to a set of _immediately_ adjacent = (directly-connected) transit providers and/or peers. Again, just for = the purposes of drawing an analogy to something I'm already familiar = with, this would be similar to what ASN's do today with IRR 'aut-num' = objects by expressing their import & export policies to immediately = adjacent ASN's. Given this has already been done in the IRR, for dozens = of years, with aut-num objects means it should be straightforward to = have a similar concept in the RPKI. I'd also add that the benefit of = this approach is that the origin ASN, AS_A, knows first-hand (based on = contractual policy) to which [upstream] transit-providers or peers it = *potentially*[1] should or should not be announcing sets of routes to. = More importantly, capturing/recording this "adjacency" information is = already part of the 'work-flow' that we do today, in the IRR world, when = turning up (or, turning down) a particular [customer] neighbor ASN. = (Adding the RPKI bits to the workflow will add more time and steps to = that process, but the "process" is already there). If this is _all_ the current charter text and reqmt's draft is intended = to capture, I can start to look at refining those from this PoV. (And, = you can ignore the rest of this e-mail :-). That said, I'm still very = worried about _whether_ or how we are going to handle the case of, for = example, spoofing and/or hiding ASN'es in the case of 'local-as' and = 'private-as' that are used extensively on these directly adjacent = connections (to facilitate faster integrations of networks during M&A). OTOH, once we go beyond AS_A's immediately adjacent ASN's (routing scope = with AS_PATH of length > 2 -- IOW, the upstream peer/transit-provider's = neighbors), this is where I really question if any 'value' can be = derived from a complete, end-to-end AS_PATH signature (or, seeing a = signature on each ASN in the AS_PATH). More specifically, I mean that I = (and, other operators) not only could, but _will_ construct off-line = AS_PATH filters and push them to my routers (or, my future routers with = 'majik' crypto-assist can directly do the same thing themselves) where I = would be able to _reliably_ make a decision on whether to accept or deny = prefixes coming from peers with a _completely_ signed AS_PATH. As one = extreme example, is it *really* operationally feasible to impose a = filter of all possible AS_PATH's that UUnet *could* send to me, for all = their customers (plus, customers of customers, etc., etc. -- including = all of the prepending variations that may exist) on all of the eBGP = sessions that I have with AS701 and not have it be out-of-date half-way = through uploading it on my routers? >> I thought the entire goal of the RPKI and, more importantly, the = objects that it holds attest to the 'authorization' to originate a = route? In particular, I refer to the following in Section 3.1 of = http://tools.ietf.org/html/draft-ietf-sidr-arch-12: >=20 > Authorization yes but not authentication. >=20 > You know the origin AS is authorized to announce the prefix but you = don't know that the announcement is authentic. Any other AS could = produce a route that looks like the legitimate origin made the = announcement when they did not. >=20 > When this is pointed out, I always remind people: >=20 > Even though origin authorization is not the end game, it is a vital = necesary crucial important first step without which nothing else could = succeed. Right. I get that based on past discussions surrounding the = "liability", (and/or amount of work), to verify the authenticity of an = organization and their associated objects. That said, I applaud Randy = putting forward the "ghostbusters" draft to reveal the identify of the = "authorized" party associated with the RPKI objects they hold in order = to make it possible for operators to find out who the heck is behind a = set of RPKI objects. > I.e., we are not wasteing our time here. I'm just trying to make sure I'm on the same page wrt getting the = reqmt's straight in order that when solutions start appearing I can = clearly explain to my internal developers and end-users/customers what = they are, and are not, intended to solve for. Thanks again, -shane [1] I say "potentially", because there are, for example, both standard = and proprietary BGP TE communities, (such as NO_EXPORT), that allow = customers to selectively suppress, prepend or de-preference routes that = limit a prefixes routing scope ... but, those have nothing to do with = the AS_PATH attribute. > --Sandy >=20 >=20 >> ---snip--- >> A ROA is an attestation that the holder of a set of prefixes has >> authorized an autonomous system to originate routes for those >> prefixes. A ROA is structured according to the format described in >> [ROA-FORM]. The validity of this authorization depends on the = signer >> of the ROA being the holder of the prefix(es) in the ROA; this fact >> is asserted by an end-entity certificate from the PKI, whose >> corresponding private key is used to sign the ROA. >> ---snip--- >>=20 >> Perhaps there's a subtle _security_ nuance that I'm missing in your = statement? >>=20 >> Thanks, >>=20 >> -shane From dy243@hermes.cam.ac.uk Wed Feb 23 22:06:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0394A3A69EB for ; Wed, 23 Feb 2011 22:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.92 X-Spam-Level: X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwpV+0c68IIX for ; Wed, 23 Feb 2011 22:06:44 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by core3.amsl.com (Postfix) with ESMTP id EC7D13A69E8 for ; Wed, 23 Feb 2011 22:06:43 -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-gx0-f172.google.com ([209.85.161.172]:36074) 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 1PsUMO-0001eL-Wp (Exim 4.72) for sidr@ietf.org (return-path ); Thu, 24 Feb 2011 06:07:32 +0000 Received: by gxk5 with SMTP id 5so116595gxk.31 for ; Wed, 23 Feb 2011 22:07:31 -0800 (PST) Received: by 10.90.105.10 with SMTP id d10mr1462120agc.99.1298527651233; Wed, 23 Feb 2011 22:07:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.214.17 with HTTP; Wed, 23 Feb 2011 22:07:11 -0800 (PST) In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <15E88519-A211-4F6C-8CA4-CDEAAA5B1C32@castlepoint.net> From: Dongting Yu Date: Thu, 24 Feb 2011 06:07:11 +0000 Message-ID: To: Sandra Murphy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: Dongting Yu Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 06:06:45 -0000 Hello, On Wed, Feb 23, 2011 at 8:26 PM, Sandra Murphy w= rote: > It is quite easy for an AS to construct an AS_PATH with the legitimate > authorized origin on the origin end, without every having received such a= n > announcement from the origin. =A0Without the legitimate origin ever havin= g > actually made the announcement to anyone, even. > > That's why path validation is important. =A0You really would like some > assurance that the origin actually announced the prefix *and* announced i= t > to the party that appears tp have propagated it onward. Since my impression so far is that recording the actual route taken by the announcement is not feasible in all cases, is it possible to require only that a party involved can vouch/validate that part of the AS path as correct? So an AS can modify their own part of a path as long as they can say "yes it is correct" when asked, or they can, for example, add another ASN as long as the other AS can say "yes" when asked. The difference is in one case we aim for accuracy and in the other we just need someone (who has the rights) to verify it. My impression is that so far the former is leaned towards. But correct me if I have misunderstood. Dongting From jgs@bgp.nu Thu Feb 24 05:26:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22C0D3A6B12 for ; Thu, 24 Feb 2011 05:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbNnR+JsZCm5 for ; Thu, 24 Feb 2011 05:26:18 -0800 (PST) Received: from bgp.nu (bgp.nu [216.117.214.198]) by core3.amsl.com (Postfix) with ESMTP id 677AC3A6B16 for ; Thu, 24 Feb 2011 05:26:18 -0800 (PST) Received: from sa-nc-apg-254.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 3ED8F16144C1; Thu, 24 Feb 2011 08:27:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> Date: Thu, 24 Feb 2011 15:27:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> To: Andrew Lange X-Mailer: Apple Mail (2.1082) Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 13:26:19 -0000 Andrew, On Feb 24, 2011, at 1:17 AM, Andrew Lange wrote: > Given the thread, I can understand your frustration. And, I could = have made myself more clear. I'll try: given the policies that AS_B = might be implementing, we cannot know for certain, without AS_B = publishing their policies, if AS_B should in fact be announcing which of = AS_A's routes or in what form, hence the use of the term "Plausible."=20 Assume a model where the AS path is signed such that the recipient is = able to verify that for each arc in the path, the further AS did sign it = to the closer AS. To take your example and extend it, suppose we have AS_A --> AS_B --> AS_C --> AS_D (A announces a route to B announces it to C announces it to D.) If D is = able to verify the signature on the (B, C) arc, then it knows (for some = value of "knows" of course :-) that B did actually send the route to C. = Whether that fulfills "AS_B should in fact be announcing which of AS_A's = routes or in what form" I leave it to you to interpret -- it doesn't = protect against a policy misconfiguration on the announcing router of = AS_B. An abstract representation of AS_B's policy could do that, but = functionality like that is beyond the scope of the proposed charter = item. The fact that systems to provide exactly this kind of abstract = policy publication have fallen into disrepute doesn't fill me with = optimism about this approach, despite my own personal history with it. I interpret the proposed charter item to be asking not "if AS_B *should* = in fact be announcing which of AS_A's routes or in what form" but rather = roughly "if AS_B *did* in fact announce which of AS_A's routes and in = what form". --John= From ietfc@btconnect.com Thu Feb 24 05:51:44 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA98C3A6B0E for ; Thu, 24 Feb 2011 05:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHhr7xXZ7Joy for ; Thu, 24 Feb 2011 05:51:43 -0800 (PST) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id 3AA073A68DE for ; Thu, 24 Feb 2011 05:51:42 -0800 (PST) Received: from host86-141-16-12.range86-141.btcentralplus.com (HELO pc6) ([86.141.16.12]) by c2bthomr07.btconnect.com with SMTP id CBH27528; Thu, 24 Feb 2011 13:52:25 +0000 (GMT) Message-ID: <006201cbd421$14ffaa60$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sean Turner" , "Christopher Morrow" References: <000c01cbd1e3$c1036e40$4001a8c0@gateway.2wire.net> <975F6DE4-FF8F-4F6A-B9D2-38884E219BFF@ieca.com> Date: Thu, 24 Feb 2011 13:44:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4D66628C.0232, actions=TAG X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4D66629D.0183,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: sidr@ietf.org Subject: Re: [sidr] Last Call: (AnInfrastructure to X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 13:51:44 -0000 ----- Original Message ----- From: "Sean Turner" To: "Christopher Morrow" Cc: "iesg" ; "ietf" ; "t.petch" ; Sent: Monday, February 21, 2011 8:58 PM > > On Feb 21, 2011, at 1:15 PM, Christopher Morrow wrote: > > > (not speaking for the authors, just observing some... also not > > speaking as a co-chair) > > > > On Mon, Feb 21, 2011 at 11:23 AM, t.petch wrote: > >> I find this I-D problematic. The subject matter is of crucial importance, > >> comparable to, or perhaps more important than, IPv6, yet this I-D is not > >> an easy read and there should be one such somewhere. > > > > I thought there was to be an overview doc as well produced, with the > > goal being to lay out the basic parts referring to the other drafts > > for further info/expansion. > > > >> sidr has produced an awesome collection of I-Ds (some now obsolete) but it is > >> not obvious, short of spending a few months in the archives, how they fit > >> together. Other major projects - snmp for example - produced an Introduction, > >> acting as a starting point and a road map to the other I-Ds and I think that > >> that should be a prerequisite for sidr. This I-D is not it (even if it could > >> be); its Normative > >> References include a further 80 pages of sidr I-Ds! > >> > >> One small example. The I-Ds have several references to RPKI and indeed, that > >> appears in -arch; but it first appears on page 8 and is not even expanded, let > > > > eh.. that's a nit that someone should file... "hey, you can't use an > > acronym for the first time without actually expanding it properly!" > > > > Can you cite the proper para/page/section on this so the authors can fix it? > > > Maybe if we tweaked the last sentence in section 2: > > Such a PKI, which is henceforth referred to as the Resource Public Key Infrastructure (RPKI), is a central component of this architecture. I would add one more phrase of explanation at the end 'where a Resource is either a block of IP address space or an AS number.' You may, or may not, recall me asking some time ago whether RPKI was a sidr specific term or another of those security terms that non-security experts never get to know or understand. I still think that anyone coming from a routing background will struggle in the absence of that phrase I suggest you add. And notice that we are putting the explanation right at the end of a lengthy paragraph, deductive rather then inductive style, which I think always makes technical documents harder to follow (even if it is the one I fall naturally into). And this is my general point; this I-D, like most of sidr, is written to be understood by those who understand it when, with a little extra, it could be understood more widely. (And I have been tracking the sidr list since its inception:-( Manifests would be another similar but larger issue. Yes I see the detail of a manifest, but so what, why should I care? -arch I find unclear. And protocols? this -arch is light on protocols; presumably draft-ietf-sidr-rpki-rtr does not count as part of the -arch:-) etc etc Tom Petch > > Spt > > > -Chris > > > >> alone explained. Of course you can turn to Wikipedia and you find a clear > >> explanation of what RPKI is but you should not need Wikipedia to understand > >> something as important as sidr. This I-D seems to be written to be understood > >> by those who understand it:-( > >> > >> Tom Petch > >> > >> > >> ----- Original Message ----- > >> From: "The IESG" > >> To: "IETF-Announce" > >> Cc: > >> Sent: Monday, February 07, 2011 5:14 PM > >> Subject: [sidr] Last Call: (An Infrastructure to > >> > >> > >>> > >>> The IESG has received a request from the Secure Inter-Domain Routing WG > >>> (sidr) to consider the following document: > >>> - 'An Infrastructure to Support Secure Internet Routing' > >>> as an Informational RFC > >>> > >>> The IESG plans to make a decision in the next few weeks, and solicits > >>> final comments on this action. Please send substantive comments to the > >>> ietf at ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be > >>> sent to iesg at ietf.org instead. In either case, please retain the > >>> beginning of the Subject line to allow automated sorting. > >>> > >>> The file can be obtained via > >>> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ > >>> > >>> IESG discussion can be tracked via > >>> http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/ > >>> > >>> > >>> > >>> The following IPR Declarations may be related to this I-D: > >>> > >>> /ipr/1204/ > >>> > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr > >> > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From russ@cisco.com Thu Feb 24 12:00:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF553A6853 for ; Thu, 24 Feb 2011 12:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjklb7mVaUgc for ; Thu, 24 Feb 2011 12:00:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 170103A6850 for ; Thu, 24 Feb 2011 12:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1670; q=dns/txt; s=iport; t=1298577663; x=1299787263; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=5YM2pjxfKdyikXcoog1rjtPdaFhKbWTKKwZcQUzKbQw=; b=i0BwRH+xz0+xmNRNWOnMtt0BH+h5OezU6BGnkKrUPHJT+pkfM4TJGXPp d5/8B4WbhhFurQW2wDYZ5ntP+if0iCixhuaXb/Kzx71bxQstd3Fet8byd 4M/PvZ+Lj3r/fx8S7KaXb7JmieNqO3/C2AdrhtrIzor9nLv8C8u2Pljj/ Y=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFNHZk1AZnwM/2dsb2JhbACmMXOiIJt+hWAEhRCHDIM9 X-IronPort-AV: E=Sophos;i="4.62,220,1297036800"; d="asc'?scan'208";a="219820739" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2011 20:00:58 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1OK0vDX009059; Thu, 24 Feb 2011 20:00:57 GMT Message-ID: <4D66B8F7.3010607@cisco.com> Date: Thu, 24 Feb 2011 15:00:55 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "John G. Scudder" References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> In-Reply-To: <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27D31045D3D3474042A7AABC" Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 20:00:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27D31045D3D3474042A7AABC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I interpret the proposed charter item to be asking not "if AS_B *should= * in fact be announcing which of AS_A's routes or in what form" but rathe= r roughly "if AS_B *did* in fact announce which of AS_A's routes and in w= hat form". Isn't this a difference without a distinction? Let me put it another way.= If you claim "A did, in fact, send an update it received from B, which B received from C, to me," what did you intend to _do_ with this information? If you intend to block receipt of the route in the case where the signatures are not "valid," then you automatically moved to, "A should have sent me this update that it received from B, and B received from C." If you sign the update with no filtering, then you've proven what _did_ happen. Once you filter, you're trying to prove what _should_ happen. Can you explain the difference in some other way that doesn't mix the two ideas? :-) Russ --------------enig27D31045D3D3474042A7AABC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1muPkACgkQER27sUhU9OTKIACeKatu5H2MDkazfE7XU5jXQTe2 3lsAn2g/qUClry3VAYlObAbpV159slqD =lv7M -----END PGP SIGNATURE----- --------------enig27D31045D3D3474042A7AABC-- From kotikalapudi.sriram@nist.gov Thu Feb 24 15:51:09 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FDF3A68A6 for ; Thu, 24 Feb 2011 15:51:09 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcG6n2Xxz5Zq for ; Thu, 24 Feb 2011 15:51:09 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id F2F2A3A68A7 for ; Thu, 24 Feb 2011 15:51:08 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p1ONpe7I013394; Thu, 24 Feb 2011 18:51:40 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 24 Feb 2011 18:51:40 -0500 From: "Sriram, Kotikalapudi" To: Andrew Lange , Sandra Murphy Date: Thu, 24 Feb 2011 18:51:39 -0500 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvTr9aOFw5Mxu/6TiOFKsgGCT5tZwAykHeA Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> In-Reply-To: <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.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 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 23:51:10 -0000 Andrew, Comment below. Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Andrew Lange > Sent: Wednesday, February 23, 2011 6:17 PM > To: Sandra Murphy > Cc: sidr@ietf.org > Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work > --- snip --- > > From a work item perspective, it would be useful to have a relationship object signed that > says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections." This information, > combined with AS_A's signed route-objects means that downstream ASes would be able to > verify that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, AS_B] or [AS_A, > AS_Q] would be AS PATHs that could be authorized. Effectively solving the Origin + > Upstream issue would solve most of the problems. Yes, someone could then spoof an > announcement of origin+upstream+self, but then we're looking at a minimum of a 3-AS > path and the likelihood of that being best drops. We can also do this with a simple route- > filter and does not require on-system crypto calculations. > > Andrew > Yes, the path length goes up by 2. But normally an adversary would spoof an announcement with a subprefix (more specific) of the prefix that the legitimate prefix owner has announced (while still trying to keep within the maxlength as specified in the ROA). I that case the increased path length would not matter. The spoofed announcement would be accepted and propagated widely. Sriram From david.black@emc.com Thu Feb 24 18:47:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5713A68FD; Thu, 24 Feb 2011 18:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzz1+zPEj6Yy; Thu, 24 Feb 2011 18:47:24 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 239B83A68F9; Thu, 24 Feb 2011 18:47:23 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1P2mBng020021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2011 21:48:11 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 24 Feb 2011 21:48:00 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1P2lo3G026272; Thu, 24 Feb 2011 21:47:50 -0500 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 24 Feb 2011 21:47:49 -0500 From: To: , , Date: Thu, 24 Feb 2011 21:47:49 -0500 Thread-Topic: Gen-ART Review of draft-ietf-sidr-arch-11 Thread-Index: AcvUlmOMrLqZQAjwSPmfrbjAxjZC8A== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1BE9C@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: david.black@emc.com, Sandra.Murphy@sparta.com, sidr@ietf.org Subject: [sidr] Gen-ART Review of draft-ietf-sidr-arch-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 02:47:25 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-sidr-arch-11 Reviewer: David L. Black Review Date: February 24, 2011 IETF LC End Date: February 21, 2011 Summary: This draft is basically ready for publication, but has nits that should be = fixed before publication. First of all, I apologize for the tardiness of this review; I got sick over= the past weekend and unable to complete the review at that time. This draft is very well-written - it explains the PKI concepts well and has= good organization and flow. Overall, this is a nice piece of work, and an= example of what an architecture document should be - a technical overview = that leaves the details to other documents. I found a number of minor items that are mostly editorial: (1) Section 4.2 variously describes the repository system as including data= bases, file systems and possibly web servers as URIs are apparently require= d. I suggest that the term "directory structured" be used instead of discu= ssing a directory in a file system. I suggest that the required update beh= avior of the database be described (e.g., how much of full ACID transaction= support is required for what sorts or scopes of transactions). It appears= that URIs are a required form of addressing (e.g., as the SIA certificate = extension contains a URI), and I would suggest discussing the resulting URI= requirements on the access protocols in Section 4.3 (e.g., relationship of= the URI structure to the RSYNC directory structure). (2) In section 4.3, beyond bulk download of the entire repository contents,= is there also a requirement for bulk download of a directory's contents, o= r bulk download of the entire tree structure rooted at a directory? (3) The last paragraph of Section 5 states that the repository system is un= trusted. That statement should be repeated in=20 Section 4's material on repositories. (4) The draft selectively uses RFC 2119 upper case terms and their lower ca= se counterparts. That usage should be carefully double-checked to ensure t= hat the stronger upper case terms are used where needed - here are a couple= of examples where upper case may be more appropriate than lower case: - Top of p. 16: "An authority is required to issue a new manifest ..." (r= equired -> REQUIRED ?) - Start of section 7.2: " Whenever a certification authority ..., it must = perform a key rollover procedure." (must -> MUST ?) (5) Item 1 in Section 6 on Local Cache Maintenance says: 1. Query the registry system to obtain a copy of all certificates,=20 manifests and CRLs issued under the PKI. Was "repository" intended instead of "registry"? Item 3 is related and use= s the term "repository". (6) idnits 2.12.07 earned its keep by finding a bunch of nits: ** There are 2 instances of too long lines in the document, the longest o= ne being 18 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. =3D=3D Missing Reference: 'RFC3 779' is mentioned on line 166, but not de= fined =3D=3D Missing Reference: 'RFC 5871' is mentioned on line 647, but not de= fined =3D=3D Unused Reference: 'SIDR-ALG' is defined on line 1040, but no expli= cit reference was found in the text =3D=3D Unused Reference: 'PROVISION' is defined on line 1058, but no expl= icit reference was found in the text =3D=3D Unused Reference: 'RFC 5781' is defined on line 1062, but no expli= cit reference was found in the text -- No information found for draft-ietf-sidr-rpki-signed-object - is the name correct? -- No information found for draft-ietf-sidr-rescert-provisioning - is the name correct? 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 jgs@bgp.nu Fri Feb 25 06:04:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7583A69D2 for ; Fri, 25 Feb 2011 06:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXkMQU-8EZ2q for ; Fri, 25 Feb 2011 06:04:44 -0800 (PST) Received: from bgp.nu (bgp.nu [216.117.214.198]) by core3.amsl.com (Postfix) with ESMTP id DC0C53A69CA for ; Fri, 25 Feb 2011 06:04:44 -0800 (PST) Received: from sa-nc-apg-254.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 841351614755; Fri, 25 Feb 2011 09:05:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: <4D66B8F7.3010607@cisco.com> Date: Fri, 25 Feb 2011 16:05:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> To: Russ White X-Mailer: Apple Mail (2.1082) Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:04:45 -0000 On Feb 24, 2011, at 10:00 PM, Russ White wrote: > Can you explain the difference in some other way that doesn't mix the > two ideas? Since after reading your message carefully three times I don't = understand your question, I'm unable to answer it. Sorry. --John= From russ@cisco.com Fri Feb 25 06:09:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D34F3A69D2 for ; Fri, 25 Feb 2011 06:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn7JBSW6yZl5 for ; Fri, 25 Feb 2011 06:09:40 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id EB82D3A69AE for ; Fri, 25 Feb 2011 06:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1232; q=dns/txt; s=iport; t=1298643031; x=1299852631; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=OyuGgFCYDUFIEZf7yAu0pIQGO26LsB2ViL6ppmGFOOg=; b=PePmQNaiQKqX3jCPLI2HfJ5aYtPdU6WUxNFubXPVdt0cn4H5YM1fjkMb gEQFjGmmsB8U+4YORMNNAEQwv4MLapW1kfUpmTK6TQx6o+3K2ZmtGDJy3 YEsTMNRkQmPkv32wgnRuE+1qVO/1KDyrJUc9XoK2a0CAq1xRHkTV6vzve A=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI9GZ02rR7Hu/2dsb2JhbACmOnShPptthWAEhRCHDYM+ X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="asc'?scan'208";a="270484198" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 25 Feb 2011 14:10:31 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1PEAVRT009124; Fri, 25 Feb 2011 14:10:31 GMT Message-ID: <4D67B856.5030400@cisco.com> Date: Fri, 25 Feb 2011 09:10:30 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "John G. Scudder" References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> In-Reply-To: <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF9543B70F610D0F2405B59E" Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:09:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF9543B70F610D0F2405B59E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> Can you explain the difference in some other way that doesn't mix the >> two ideas? >=20 > Since after reading your message carefully three times I don't understa= nd your question, I'm unable to answer it. Sorry. You're apparently trying to separate the idea of proving an update traveled a specific path from the idea of using this information to actually filter or determine any other policy. I don't see how you can separate the two --can you explain how you can? :-) Russ --------------enigDF9543B70F610D0F2405B59E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1nuFYACgkQER27sUhU9ORK7wCfVmtPGowPuLpFffWuDVjJk9eY /bgAn11CTAR2mJ9WoOW3teU4tsx+w7Li =JmqY -----END PGP SIGNATURE----- --------------enigDF9543B70F610D0F2405B59E-- From jgs@juniper.net Fri Feb 25 06:16:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2B83A69D7 for ; Fri, 25 Feb 2011 06:16:52 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1lH3yYuGviW for ; Fri, 25 Feb 2011 06:16:51 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 2842F3A695C for ; Fri, 25 Feb 2011 06:16:51 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTWe5/yoapdnHS0EDzrPlMW1r3nftf1Bo@postini.com; Fri, 25 Feb 2011 06:17:43 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 25 Feb 2011 06:14:17 -0800 From: John Scudder To: Russ White Date: Fri, 25 Feb 2011 06:14:54 -0800 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvU9knC19JqEve/Qu+hgaYEYSLdLQ== Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> In-Reply-To: <4D67B856.5030400@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:16:52 -0000 On Feb 25, 2011, at 4:10 PM, Russ White wrote: >>> Can you explain the difference in some other way that doesn't mix the >>> two ideas? >>=20 >> Since after reading your message carefully three times I don't understan= d your question, I'm unable to answer it. Sorry. >=20 > You're apparently trying to separate the idea of proving an update > traveled a specific path from the idea of using this information to > actually filter or determine any other policy. I don't see how you can > separate the two --can you explain how you can? If you can establish the former (that the route did travel across the path = it said it did), that outcome can be used as input to policy. This is exac= tly analogous to draft-ietf-sidr-pfx-validate-01, BTW. Divide, conquer. A commonly used trick in computing. :-) --John= From russ@cisco.com Fri Feb 25 06:26:07 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591C63A69CF for ; Fri, 25 Feb 2011 06:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGPTLiSDq8SY for ; Fri, 25 Feb 2011 06:26:06 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 243DE3A67EC for ; Fri, 25 Feb 2011 06:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=2329; q=dns/txt; s=iport; t=1298644018; x=1299853618; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Frx1OOL3VBpxSR43gUxT9JMDl290bSfaNbS58cXGTSw=; b=SiacEBI9E+HB1XI2ZnA6NC7OVIvm+KZ3QH3ozdOVz0uXd8IIXZf2UhIS MDgZbQ1W+kKT0l4op8CW2Nu1vf/wwsx3XuUinrtPv5DApp9PncQWVjyYZ b0or635kAklFvF9S/D4IQIV5NICo0u0jci4L64wEK29ViehJRkR0XVvzc I=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHpLZ01AZnwM/2dsb2JhbACmOnShOZtnhWAEhRCHDYM+ X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="asc'?scan'208";a="220329132" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2011 14:26:47 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PEQlgc011707; Fri, 25 Feb 2011 14:26:47 GMT Message-ID: <4D67BC22.3070402@cisco.com> Date: Fri, 25 Feb 2011 09:26:42 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Scudder References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA5AD3B91BC2BBD58C2413BDB" Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:26:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA5AD3B91BC2BBD58C2413BDB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> You're apparently trying to separate the idea of proving an update >> traveled a specific path from the idea of using this information to >> actually filter or determine any other policy. I don't see how you can= >> separate the two --can you explain how you can? >=20 > If you can establish the former (that the route did travel across the p= ath it said it did), that outcome can be used as input to policy. This i= s exactly analogous to draft-ietf-sidr-pfx-validate-01, BTW. >=20 > Divide, conquer. A commonly used trick in computing. :-) Hmmm... This is what I thought. 1. Shane and I are arguing that you can't --or shouldn't-- imply policy based on which AS a particular piece of routing information went through multiple hops from you (I hope that's right, Shane). 2. You answered: > I interpret the proposed charter item to be asking not "if AS_B *should= * in fact be announcing which of AS_A's routes or in what form" but rathe= r roughly "if AS_B *did* in fact announce which of AS_A's routes and in w= hat form". 3. My question was --it seems you're trying to say, "no, I don't want to infer policy from this, I just want to prove what happened." At which point I asked --what's the difference if, in fact, you intend to act based on what you perceive as "what happened?" In trying to "divide and conquer," you're actually assuming step 2 from step 1 --and the assumption is what I think we need to drive out into the open air and discuss by building a set of requirements other than, "I want to prove what happened." :-) Russ --------------enigA5AD3B91BC2BBD58C2413BDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1nvCUACgkQER27sUhU9OSE1ACg2pKlQMoRWyaZkOYeQ6VBGUI/ ZYUAn1X7ZBPQJ6P/zPx2h9y26d2Yjg2n =1KXc -----END PGP SIGNATURE----- --------------enigA5AD3B91BC2BBD58C2413BDB-- From jmh@joelhalpern.com Fri Feb 25 06:28:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7D93A68D4 for ; Fri, 25 Feb 2011 06:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlac9LTwZNcw for ; Fri, 25 Feb 2011 06:28:23 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id 3C8B13A67EC for ; Fri, 25 Feb 2011 06:28:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id E4D2C325AEF6 for ; Fri, 25 Feb 2011 06:29:15 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-187.clppva.btas.verizon.net [71.161.52.187]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 5EBCC324643A for ; Fri, 25 Feb 2011 06:29:15 -0800 (PST) Message-ID: <4D67BCB9.5060903@joelhalpern.com> Date: Fri, 25 Feb 2011 09:29:13 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "sidr@ietf.org" References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:28:25 -0000 Let me try phrasing the issue differently. I may still be missing the point, from all sides. I believe that what is actually wanted is primarily: o To prevent any advertiser from sending an advertisement that would cause other properly behaving parties to send traffic iin a way that they are not "entitled" to cause As secondary matter o We want such attempted subversion to be visible at more than one hop because experience tells us that not everyone deploys the tools properly, and thus we can not count on every honest player doing their job well. (Colluding subverting players is addressed only to the degree that it is covered by what we are after, not explicitly. We are staying away from Byzantine Generals.) The above probably needs more wordsmithing, but is a problem statement that does not assume that packets follow their advertisements, nor that any party can control what any other party actually does. It also avoids getting into the question of the accuracy of the reflection of the path of the advertisement, the AS path in the advertisement, and the actual packet flow. Instead, it focuses on an attack we are trying to prevent. I believe that the primary solutions on the table are all solutions that can be reasonably considered to address the problem as stated. (I.e. I am not trying to change the solutions pace, only to clarify the problem space.) Apologies if I am still completely confused. Yours, Joel On 2/25/2011 9:14 AM, John Scudder wrote: > On Feb 25, 2011, at 4:10 PM, Russ White wrote: >>>> Can you explain the difference in some other way that doesn't mix the >>>> two ideas? >>> >>> Since after reading your message carefully three times I don't understand your question, I'm unable to answer it. Sorry. >> >> You're apparently trying to separate the idea of proving an update >> traveled a specific path from the idea of using this information to >> actually filter or determine any other policy. I don't see how you can >> separate the two --can you explain how you can? > > If you can establish the former (that the route did travel across the path it said it did), that outcome can be used as input to policy. This is exactly analogous to draft-ietf-sidr-pfx-validate-01, BTW. > > Divide, conquer. A commonly used trick in computing. :-) > > --John > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From jgs@juniper.net Fri Feb 25 06:42:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F55E3A69B2 for ; Fri, 25 Feb 2011 06:42:48 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHVNJzWpnnJf for ; Fri, 25 Feb 2011 06:42:47 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 575BB3A682C for ; Fri, 25 Feb 2011 06:42:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTWfAGgaqW8fQzVQXDRISNNkRZsgP78dJ@postini.com; Fri, 25 Feb 2011 06:43:40 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 25 Feb 2011 06:41:08 -0800 From: John Scudder To: "Joel M. Halpern" Date: Fri, 25 Feb 2011 06:41:43 -0800 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvU+glGtDLMg8sSSJaoAVccl3dK0A== Message-ID: <6A7C60DF-BDC4-4704-8D93-B099BB272614@juniper.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> In-Reply-To: <4D67BCB9.5060903@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:42:48 -0000 I think that is more or less right. --John On Feb 25, 2011, at 4:29 PM, Joel M. Halpern wrote: > Let me try phrasing the issue differently. I may still be missing the po= int, from all sides. >=20 > I believe that what is actually wanted is primarily: > o To prevent any advertiser from sending an advertisement that would caus= e other properly behaving parties to send traffic iin a way that they are n= ot "entitled" to cause >=20 > As secondary matter > o We want such attempted subversion to be visible at more than one hop be= cause experience tells us that not everyone deploys the tools properly, and= thus we can not count on every honest player doing their job well. >=20 > (Colluding subverting players is addressed only to the degree that it is = covered by what we are after, not explicitly. We are staying away from Byz= antine Generals.) >=20 > The above probably needs more wordsmithing, but is a problem statement th= at does not assume that packets follow their advertisements, nor that any p= arty can control what any other party actually does. It also avoids gettin= g into the question of the accuracy of the reflection of the path of the ad= vertisement, the AS path in the advertisement, and the actual packet flow. = Instead, it focuses on an attack we are trying to prevent. > I believe that the primary solutions on the table are all solutions that = can be reasonably considered to address the problem as stated. (I.e. I am = not trying to change the solutions pace, only to clarify the problem space.= ) >=20 > Apologies if I am still completely confused. > Yours, > Joel >=20 > On 2/25/2011 9:14 AM, John Scudder wrote: >> On Feb 25, 2011, at 4:10 PM, Russ White wrote: >>>>> Can you explain the difference in some other way that doesn't mix the >>>>> two ideas? >>>>=20 >>>> Since after reading your message carefully three times I don't underst= and your question, I'm unable to answer it. Sorry. >>>=20 >>> You're apparently trying to separate the idea of proving an update >>> traveled a specific path from the idea of using this information to >>> actually filter or determine any other policy. I don't see how you can >>> separate the two --can you explain how you can? >>=20 >> If you can establish the former (that the route did travel across the pa= th it said it did), that outcome can be used as input to policy. This is e= xactly analogous to draft-ietf-sidr-pfx-validate-01, BTW. >>=20 >> Divide, conquer. A commonly used trick in computing. :-) >>=20 >> --John >> _______________________________________________ >> 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 jgs@juniper.net Fri Feb 25 06:48:13 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE183A69B2 for ; Fri, 25 Feb 2011 06:48:13 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI9RrATIWgN7 for ; Fri, 25 Feb 2011 06:48:12 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 353BC3A682C for ; Fri, 25 Feb 2011 06:48:11 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTWfBXoz6bYvneEAuOGCs/fvWE9PL5Q15@postini.com; Fri, 25 Feb 2011 06:49:05 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 25 Feb 2011 06:39:59 -0800 From: John Scudder To: Russ White Date: Fri, 25 Feb 2011 06:40:35 -0800 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvU+eBKC/sfvvxqT+G5+d8wHHYRqQ== Message-ID: <9D569E24-1007-4F5B-BF30-0CEA08E8DB69@juniper.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BC22.3070402@cisco.com> In-Reply-To: <4D67BC22.3070402@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:48:13 -0000 On Feb 25, 2011, at 4:26 PM, Russ White wrote: >>> You're apparently trying to separate the idea of proving an update >>> traveled a specific path from the idea of using this information to >>> actually filter or determine any other policy. I don't see how you can >>> separate the two --can you explain how you can? >>=20 >> If you can establish the former (that the route did travel across the pa= th it said it did), that outcome can be used as input to policy. This is e= xactly analogous to draft-ietf-sidr-pfx-validate-01, BTW. >>=20 >> Divide, conquer. A commonly used trick in computing. :-) >=20 > Hmmm... >=20 > This is what I thought. >=20 > 1. Shane and I are arguing that you can't --or shouldn't-- imply policy > based on which AS a particular piece of routing information went through > multiple hops from you (I hope that's right, Shane). "Can't"? Hm. I'll address "shouldn't", by saying if you think that should= n't be done, then don't configure your policy to do it. Others disagree. = In any case, the question of which AS a particular piece of routing informa= tion went through is only tangentially related to the topic, which I will r= emind you is * Is the AS-Path represented in the route the same as the path through which the route update traveled This doesn't speak to any particular AS in the path. It just asks whether = there is a custodial chain that extends back to the route's origin. I'll also note in passing that as others -- Ruediger maybe? -- have noted, = AS path regexes wouldn't exist if policies weren't already being written ba= sed on exactly "which AS a particular piece of routing information went thr= ough multiple hops from you". > 2. You answered: >=20 >> I interpret the proposed charter item to be asking not "if AS_B *should*= in fact be announcing which of AS_A's routes or in what form" but rather r= oughly "if AS_B *did* in fact announce which of AS_A's routes and in what f= orm". >=20 > 3. My question was --it seems you're trying to say, "no, I don't want to > infer policy from this, I just want to prove what happened." At which > point I asked --what's the difference if, in fact, you intend to act > based on what you perceive as "what happened?" >=20 > In trying to "divide and conquer," you're actually assuming step 2 from > step 1 --and the assumption is what I think we need to drive out into > the open air and discuss by building a set of requirements other than, > "I want to prove what happened." You lost me again. My best guess based on the above is that you think we should actively preve= nt people from writing policies to prefer routes that have a known custodia= l chain that extends back to the origin to ones that do not have such. I d= o not think we should prevent them from doing so. The proposed charter add= ition suggests adding a tool to enable that choice. It seems like a worthy= thing to me. By and large I think the discussion of general policy in this context muddi= es the waters so I am going to try to resist the temptation to discuss it a= ny further. --John= From russ@cisco.com Fri Feb 25 06:53:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3FC3A69C3 for ; Fri, 25 Feb 2011 06:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcoblQmYKsMa for ; Fri, 25 Feb 2011 06:53:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D3C853A69B2 for ; Fri, 25 Feb 2011 06:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1064; q=dns/txt; s=iport; t=1298645647; x=1299855247; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=FrXDPckB8HWmNOZrlSTzTx1H7yDpsg8WpEB4vjpBpiQ=; b=Ay7/rUVJ3HFGvCSh9FLx740zJjUvXW4K+M+oHwdubVpHlPpo4OUphLLd nEX7dzuEoZiIfandPwwpKhm9D8uN5zZSBdmFgy1Ht4xRMziL8OsIPVpgZ MjniteR0676D95qhM4l3nA2DjuFyPY73R1vDekHMXvOLGTLrdzZIaq8Ws Q=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFdRZ01AZnwM/2dsb2JhbACmOnShPZtohWAEhRCHDYM+ X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="asc'?scan'208";a="220337852" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2011 14:54:07 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PEs6No019309; Fri, 25 Feb 2011 14:54:06 GMT Message-ID: <4D67C28D.1090504@cisco.com> Date: Fri, 25 Feb 2011 09:54:05 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Scudder References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BC22.3070402@cisco.com> <9D569E24-1007-4F5B-BF30-0CEA08E8DB69@juniper.net> In-Reply-To: <9D569E24-1007-4F5B-BF30-0CEA08E8DB69@juniper.net> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3604AB33162D1581C29DA66F" Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:53:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3604AB33162D1581C29DA66F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > * Is the AS-Path represented in the route the same as the path > through which the route update traveled >=20 > This doesn't speak to any particular AS in the path. It just asks whet= her there is a custodial chain that extends back to the route's origin. Why does the custodial chain matter? :-) Russ --------------enig3604AB33162D1581C29DA66F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1nwo0ACgkQER27sUhU9OQrTgCgrxXD5LYbSyf8QIJ7UZZ40+m5 /IoAn1dNZXUY9xXbvjJWYhMovzJEJu4h =M9mM -----END PGP SIGNATURE----- --------------enig3604AB33162D1581C29DA66F-- From jgs@juniper.net Fri Feb 25 06:58:20 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796353A69C3 for ; Fri, 25 Feb 2011 06:58:20 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kblkrRrrXDIA for ; Fri, 25 Feb 2011 06:58:19 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 9F1083A69B2 for ; Fri, 25 Feb 2011 06:58:18 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTWfDpB9oQMwaXa2AACG+jIz6mDR8b8kv@postini.com; Fri, 25 Feb 2011 06:59:12 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 25 Feb 2011 06:56:04 -0800 From: John Scudder To: Russ White Date: Fri, 25 Feb 2011 06:56:40 -0800 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvU/B+dDIzjIgCiSz6CtZ9uKHDiyQ== Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BC22.3070402@cisco.com> <9D569E24-1007-4F5B-BF30-0CEA08E8DB69@juniper.net> <4D67C28D.1090504@cisco.com> In-Reply-To: <4D67C28D.1090504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:58:20 -0000 On Feb 25, 2011, at 4:54 PM, Russ White wrote: > Why does the custodial chain matter? I think Joel summed it up pretty well. Rather than continue to pick at thi= s nit, why not switch gears and see what you think of his alternate formula= tion? --John= From russ@cisco.com Fri Feb 25 06:59:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF003A69DD for ; Fri, 25 Feb 2011 06:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2udTM9QnkyQ for ; Fri, 25 Feb 2011 06:59:28 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 96D4C3A69C3 for ; Fri, 25 Feb 2011 06:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1094; q=dns/txt; s=iport; t=1298646021; x=1299855621; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=vCzmu8VIGT0btJ+n1q1+cx/aiA1r1UTF12AXSot6wDk=; b=MBrvA9XUUtVeT3ca9S6sYuLqghJXub9EDlDURCX5UoAeXmVYNybqWozM RxvGttNU+rJRyWjhckMAlcfwfI+vjXadUwiEQAhWX1qiZ09N+OLXnJwGk 6NvazxlAeXTz+w228+2O3nUrNsFHhLtcd9xjwGZRnQ+rx/p3Xl/aYPRsB Y=; X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAINSZ01AZnwN/2dsb2JhbACmOnShP5tphWAEhRCHDYM+ X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="asc'?scan'208";a="220340111" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Feb 2011 15:00:09 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1PF09pE007885; Fri, 25 Feb 2011 15:00:09 GMT Message-ID: <4D67C3F5.5060304@cisco.com> Date: Fri, 25 Feb 2011 10:00:05 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Scudder References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BC22.3070402@cisco.com> <9D569E24-1007-4F5B-BF30-0CEA08E8DB69@juniper.net> <4D67C28D.1090504@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig24DA85CC0C41383F56BEF2BF" Cc: Andrew Lange , Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 14:59:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig24DA85CC0C41383F56BEF2BF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/25/2011 9:56 AM, John Scudder wrote: > On Feb 25, 2011, at 4:54 PM, Russ White wrote: >> Why does the custodial chain matter? >=20 > I think Joel summed it up pretty well. Rather than continue to pick at= this nit, why not switch gears and see what you think of his alternate f= ormulation? I thought I already responded to that? :-) Russ --------------enig24DA85CC0C41383F56BEF2BF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk1nw/cACgkQER27sUhU9OQA9wCeNyL+OQFEyniRBoVBgVg8UtZG MrAAmOH2JdRWUQSKFvhAAxViccu6lIo= =HH8Z -----END PGP SIGNATURE----- --------------enig24DA85CC0C41383F56BEF2BF-- From jgs@juniper.net Fri Feb 25 07:08:12 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D00F3A69E2 for ; Fri, 25 Feb 2011 07:08:12 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ+pOK2yvQUf for ; Fri, 25 Feb 2011 07:08:11 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 719C23A69BA for ; Fri, 25 Feb 2011 07:08:11 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTWfGD3JgGNrMYrpqk4gONcmhsmbSUhM+@postini.com; Fri, 25 Feb 2011 07:09:04 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 25 Feb 2011 07:03:02 -0800 From: John Scudder To: Russ White Date: Fri, 25 Feb 2011 07:03:38 -0800 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvU/Rh3OqoKsceLRh+4UX2qpxJE4Q== Message-ID: <7FB1C8BC-F5DB-4181-B231-1956235A662C@juniper.net> References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BC22.3070402@cisco.com> <9D569E24-1007-4F5B-BF30-0CEA08E8DB69@juniper.net> <4D67C28D.1090504@cisco.com> <4D67C3F5.5060304@cisco.com> In-Reply-To: <4D67C3F5.5060304@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:08:12 -0000 [extra cc's dropped] On Feb 25, 2011, at 5:00 PM, Russ White wrote: > On 2/25/2011 9:56 AM, John Scudder wrote: >>=20 ... >> I think Joel summed it up pretty well. Rather than continue to pick at = this nit, why not switch gears and see what you think of his alternate form= ulation? >=20 > I thought I already responded to that? Not that I saw but perhaps our messages have crossed. I was referring to=20 Message-Id: <4D67BCB9.5060903@joelhalpern.com> Date: February 25, 2011 4:29:13 PM GMT+02:00 in this same thread. I will patiently wait to see your reply. --John= From john@jlc.net Fri Feb 25 09:45:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246A83A69E7 for ; Fri, 25 Feb 2011 09:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.705 X-Spam-Level: X-Spam-Status: No, score=-106.705 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnnh7lzWeujQ for ; Fri, 25 Feb 2011 09:45:04 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 939183A6814 for ; Fri, 25 Feb 2011 09:45:04 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5821333C27; Fri, 25 Feb 2011 12:45:52 -0500 (EST) Date: Fri, 25 Feb 2011 12:45:52 -0500 From: John Leslie To: Russ White Message-ID: <20110225174552.GG7663@verdi> References: <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BC22.3070402@cisco.com> <9D569E24-1007-4F5B-BF30-0CEA08E8DB69@juniper.net> <4D67C28D.1090504@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4D67C28D.1090504@cisco.com> User-Agent: Mutt/1.4.1i Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:45:06 -0000 Russ White wrote: > To: John Scudder >=20 >> * Is the AS-Path represented in the route the same as the path >> through which the route update traveled >>=20 >> This doesn't speak to any particular AS in the path. It just asks >> whether there is a custodial chain that extends back to the route's >> origin. >=20 > Why does the custodial chain matter? I can't speak for John Scudder, but I would guess he means that it doesn't _matter_ whether it matters: that is what folks want to know. We have quite a history of "assuming" that the chain shows which ASs the routing information has traveled. In SIDR we are realizing how easily that can be untrue. It's natural for folks to want to ratify the assumption. Speaking for myself, I'm uneasy about making this a goal _before_ I'm convinced it's reasonable to achieve it. (This doesn't mean I insist on nailing down a solution before setting the goal -- it means I suspect that the goal is not reasonably achievable with current hardware.) -- John Leslie From randy@psg.com Sat Feb 26 03:38:20 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC383A6857 for ; Sat, 26 Feb 2011 03:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZPg8x5oNPqm for ; Sat, 26 Feb 2011 03:38:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A25753A6842 for ; Sat, 26 Feb 2011 03:38:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=96.130.dhcp.conference.apricot.net.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PtIUR-000830-Ia; Sat, 26 Feb 2011 11:39:11 +0000 Date: Sat, 26 Feb 2011 20:39:10 +0900 Message-ID: From: Randy Bush To: John Scudder In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 11:38:20 -0000 > If you can establish the former (that the route did travel across the > path it said it did), that outcome can be used as input to policy. > This is exactly analogous to draft-ietf-sidr-pfx-validate-01, BTW. > > Divide, conquer. A commonly used trick in computing. :-) more like what is taught in opsys 101, separation of mechanism from policy randy From randy@psg.com Sat Feb 26 03:46:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09ED3A6864 for ; Sat, 26 Feb 2011 03:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWc6LCbE1jsI for ; Sat, 26 Feb 2011 03:46:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C5F473A681C for ; Sat, 26 Feb 2011 03:46:51 -0800 (PST) Received: from localhost ([127.0.0.1] helo=96.130.dhcp.conference.apricot.net.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PtIcj-00085C-EU; Sat, 26 Feb 2011 11:47:45 +0000 Date: Sat, 26 Feb 2011 20:47:44 +0900 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: <4D67BCB9.5060903@joelhalpern.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 11:46:52 -0000 > o To prevent any advertiser from sending an advertisement that would > cause other properly behaving parties to send traffic iin a way that > they are not "entitled" to cause close, but i am not entirely comfortable with this o we can not hope to prevent the advertisement, only detect it is bogus. o it is the bgp receiver's policy decision on where to send traffic. a security researcher may specifically want to send traffic toward a bogus announcement. o i.e. 'cause' is too strong a word, perhaps 'lure' but you have the essential point randy From Internet-Drafts@ietf.org Sat Feb 26 12:45:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C8E3A6847; Sat, 26 Feb 2011 12:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.817 X-Spam-Level: X-Spam-Status: No, score=-102.817 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb9CSGf1SlqC; Sat, 26 Feb 2011 12:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38323A6817; Sat, 26 Feb 2011 12:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110226204501.11290.30784.idtracker@localhost> Date: Sat, 26 Feb 2011 12:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 20:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Algorithm Agility Procedure for RPKI. Author(s) : R. Gagliano, et al. Filename : draft-ietf-sidr-algorithm-agility-00.txt Pages : 25 Date : 2011-02-26 This document specifies the process that Certificate Authorities (CAs) and Relying Parties (RP) 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 support only a top-down migration (parent migrates before children). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-algorithm-agility-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-26123106.I-D@ietf.org> --NextPart-- From rogaglia@cisco.com Sun Feb 27 13:50:10 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7A33A6A3B for ; Sun, 27 Feb 2011 13:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ4gd31xjQ4n for ; Sun, 27 Feb 2011 13:50:08 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 1FF373A6832 for ; Sun, 27 Feb 2011 13:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=11810; q=dns/txt; s=iport; t=1298843466; x=1300053066; h=from:mime-version:subject:date:in-reply-to:to:references: message-id; bh=Cy1I5K5WzuMpEPZ7h4yfuTBgBb41I6HaRljiPbDNlz8=; b=H6bnUQ+N06/BabE/xlhbfHUbDN1fn3RrAdAlkiNJm8vtqhpYAsHDlQyx n99ppsfXCI9TpZZ/fFMjRKeHMvqc+pAqnSY9F7hPPto7OFeqD9aot9+y5 Ysvz0RmzVUermxZVwvCz3czRry17VsV+09BXenbbzJnm9ob4Qh3K4qGy1 s=; X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoEAF9Vak2Q/khNgWdsb2JhbACmRBUBARYiJZ45mlWFYQSMHQ X-IronPort-AV: E=Sophos;i="4.62,235,1297036800"; d="p7s'?scan'208,217";a="20230419" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 27 Feb 2011 21:51:05 +0000 Received: from ams3-vpn-dhcp543.cisco.com (ams3-vpn-dhcp543.cisco.com [10.61.66.31]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p1RLp4iw024953 for ; Sun, 27 Feb 2011 21:51:04 GMT From: Roque Gagliano Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-944-561200922; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 27 Feb 2011 22:51:04 +0100 In-Reply-To: <20110226204501.11290.30784.idtracker@localhost> To: "sidr@ietf.org wg" References: <20110226204501.11290.30784.idtracker@localhost> Message-Id: X-Mailer: Apple Mail (2.1082) Subject: Re: [sidr] I-D Action:draft-ietf-sidr-algorithm-agility-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 21:50:10 -0000 --Apple-Mail-944-561200922 Content-Type: multipart/alternative; boundary=Apple-Mail-943-561200805 --Apple-Mail-943-561200805 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG, We just submitted the -00 version of this algorithm agility draft, now = as a WG item.=20 The document includes the different changes requested since Beijing from = the individual submission, notably: 1. Change form "laisez faire" to "top-down" 2. Included Multi Algorithm support in the RPKI provisioning protocol 3. Included Validation of multiple instance of signed products 4. Included Revocations 5. Included Key rollover 6. Included Repository structure 7. Included Security Considerations 8. Included Acknowledgements We look forward for your comments. Regards, Roque. On Feb 26, 2011, at 9:45 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 >=20 > Title : Algorithm Agility Procedure for RPKI. > Author(s) : R. Gagliano, et al. > Filename : draft-ietf-sidr-algorithm-agility-00.txt > Pages : 25 > Date : 2011-02-26 >=20 > This document specifies the process that Certificate Authorities > (CAs) and Relying Parties (RP) 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 support only a top-down migration > (parent migrates before children). >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-00.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-943-561200805 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = WG,

We just submitted the -00 version of this = algorithm agility draft, now as a WG = item. 

The document includes the different = changes requested since Beijing from the individual submission, = notably:
1. Change form "laisez faire" to = "top-down"
   2.  Included Multi =
Algorithm support in the RPKI provisioning
       protocol

   3.  Included Validation of multiple instance of signed products

   4.  Included Revocations

   5.  Included Key rollover

   6.  Included Repository structure

   7.  Included Security Considerations

   8.  Included Acknowledgements


We look =
forward for your comments.
Regards,
Roque.


On = Feb 26, 2011, at 9:45 PM, Internet-Drafts@ietf.org = wrote:

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Secure = Inter-Domain Routing Working Group of the IETF.


Title =           : Algorithm = Agility Procedure for RPKI.
Author(s) =       : R. Gagliano, et al.
Filename =        : = draft-ietf-sidr-algorithm-agility-00.txt
Pages =           : = 25
= Date =            : = 2011-02-26

This document specifies the process that Certificate = Authorities
(CAs) and Relying Parties (RP) 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 = support only a top-down migration
(parent migrates before = children).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-= agility-00.txt

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is = the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.
<Mail = Attachment>_______________________________________________
si= dr mailing = list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

= --Apple-Mail-943-561200805-- --Apple-Mail-944-561200922 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIyNzIx NTEwNFowIwYJKoZIhvcNAQkEMRYEFFdUgjVMD/mjv7CBaQ4Ey92LY+DUMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAEMatDG7xUIbHrNuCDQyHiA9oGv1TmK1UwEQxWhII0C/HYtX73cL CfOPNkxHgbCikmWyoRPUdjvc2Cx/FYA6q6+H5uMmK9tIfTFDu7cfof1ZpCMpD1GM1o9XOv+W4F3e ci/BXkIETHK5TJ9o3C6XPiOoVaM+LuCx1xIYTqzZwZs7Xiv/bVdea6YxRZ5Sh9NnehgLAodAFqsm Ix9ygkvqYpjFVz9k3Y8OFI0Nh90COlTN0Mubxn0UY6YgfeiK8OMkJnALioFXt7YFYY8ez0gxkb0Z +TS4V8U1b4fSFkLJUxoRPfe73pgJrKkVbP6zTTCiUctoOPmaGPT7Hi6SvAuNBeYAAAAAAAA= --Apple-Mail-944-561200922-- From andrew.lange@alcatel-lucent.com Mon Feb 28 20:17:53 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714E03A6D96 for ; Mon, 28 Feb 2011 20:17:53 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJlvkxG+FcIN for ; Mon, 28 Feb 2011 20:17:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 7D3D83A6DA1 for ; Mon, 28 Feb 2011 20:17:51 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p214IqA2025987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Feb 2011 22:18:52 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p214IpkN020883 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Feb 2011 22:18:51 -0600 Received: from neo-178.vpn.ind.alcatel.com (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Feb 2011 22:18:51 -0600 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-47-670717743"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew Lange In-Reply-To: <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> Date: Mon, 28 Feb 2011 20:16:21 -0800 Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> To: "John G.Scudder" X-Mailer: Apple Mail (2.1082) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 04:17:53 -0000 --Apple-Mail-47-670717743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, But wouldn't a record of an existing announcement also show that AS_B = did in fact announce which of AS_A's routes and in what form? Why does = it need to be signed if all we want to do is record what happened? = Perhaps I'm missing something.... Andrew On Feb 24, 2011, at 5:27 AM, John G. Scudder wrote: > Andrew, >=20 > On Feb 24, 2011, at 1:17 AM, Andrew Lange wrote: >> Given the thread, I can understand your frustration. And, I could = have made myself more clear. I'll try: given the policies that AS_B = might be implementing, we cannot know for certain, without AS_B = publishing their policies, if AS_B should in fact be announcing which of = AS_A's routes or in what form, hence the use of the term "Plausible."=20 >=20 > Assume a model where the AS path is signed such that the recipient is = able to verify that for each arc in the path, the further AS did sign it = to the closer AS. To take your example and extend it, suppose we have >=20 > AS_A --> AS_B --> AS_C --> AS_D >=20 > (A announces a route to B announces it to C announces it to D.) If D = is able to verify the signature on the (B, C) arc, then it knows (for = some value of "knows" of course :-) that B did actually send the route = to C. Whether that fulfills "AS_B should in fact be announcing which of = AS_A's routes or in what form" I leave it to you to interpret -- it = doesn't protect against a policy misconfiguration on the announcing = router of AS_B. An abstract representation of AS_B's policy could do = that, but functionality like that is beyond the scope of the proposed = charter item. The fact that systems to provide exactly this kind of = abstract policy publication have fallen into disrepute doesn't fill me = with optimism about this approach, despite my own personal history with = it. >=20 > I interpret the proposed charter item to be asking not "if AS_B = *should* in fact be announcing which of AS_A's routes or in what form" = but rather roughly "if AS_B *did* in fact announce which of AS_A's = routes and in what form". >=20 > --John --Apple-Mail-47-670717743 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggZFMIIFLaAD AgECAhEA2STcHPwgFUjzymZ55K0wyzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA0MTQwMDAw MDBaFw0xMTA0MTQyMzU5NTlaMIHnMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEVMBMGA1UEAxMMQW5kcmV3IExhbmdlMS4wLAYJKoZIhvcNAQkBFh9hbmRyZXcu bGFuZ2VAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA zpUVaYV8lZ/sTUuCmVWLjpnZLO7Wfjs3QxQ/5bX6L8xkGdL5jhnDpuaI9ta4T+NuPO/AY07kaOUD 87n/Ze2TF4+rwLT48JXoxiJOSgY5qkuroK15qW24MpG1QT0nlodg83pqJQ7SqN8sFSSlnyWbB9/e WgAleEaJb6eNsiB0tncOslc5edI0IwEqEsIt2jhDIU7Lx3YGV/e5Z8J+tGrS7KY/WTbZXml8S6k9 RP44JI/Lrz/dbi+o9aqxTTj91StVRjj3JiboZ+oyLZmK1JEr04Deh+kZFpAHreKig4YhFreJr+lv ZMytmKdptyiFxEPn9mldZKYK2JaX5Ai1zR24awIDAQABo4ICITCCAh0wHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOupdX9c9crYS2uhB8HzOIVzTjg1MA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAqBgNVHREEIzAhgR9hbmRyZXcubGFuZ2VAYWxjYXRl bC1sdWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBO6f2sinZnDK3Vlh4lSGYGFE8YsBp8EIsA uFJQv7L4vsK9Y5DIO2pvAzjpKAaVe0gugQfyEAjmVOFnC2AvbWDaUYggZcX5WwzTP4aHHcVi8koB EQl6yEHtImNANjg67Q/twyjKtxHbt/7bdFFO/I/KwnGA1m2pu+WbQYpR/mGYc2uL/xuhMi5XfHLd WLeSLKB5pnLb30KuimuvXcNWKbSUO5wi8R4ihRHKTQo/VqUbd+qLk9lZyx2quSyjhZ5YzBkjnrey RU8WpBpQ2/1kB/iki8XVnUnkS5SyMcHz5eUpmWL08GfVqcU7phFLrGNOkQq0ztyYYh9MRrjlUG66 0VAEMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMAkGBSsOAwIaBQCgggIP MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMwMTA0MTYyMVow IwYJKoZIhvcNAQkEMRYEFEgY2CGmICoZuNF+lnhcWVGxF0TzMIHVBgkrBgEEAYI3EAQxgccwgcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1 c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANkk 3Bz8IBVI88pmeeStMMswDQYJKoZIhvcNAQEBBQAEggEAI14C0bCsTUmkT7zlD3/EAc2WtVw4BJzh HcUU2MVNID/41AaT0SQzvc8/HX9imdGXIl0Wb/B//NuXDFtXgEXwJE/G8xURuFg3Q5gX1YRg45Jb bTWQkSv7dojipLNUwlQcwAc2ztaokCuYlqmFw3v2WuAeuEpl8fFMHUnkhe1rpHba9k72tvIub8JW Gtl+vkh8LvYl5iVvWyb9nwxZNzzsVbAa4DQgpSpbBw2kF4gTXqvGjNR6zs2bb1XrdIp3hTcZf//Z 3qQtErK78/6hozg//32pBL/nTo1eb5DwGaF7hF5TYGS4ysGOcNQqT/p5lBjZSn/iTC/HRRro5GYW HIPYAQAAAAAAAA== --Apple-Mail-47-670717743-- From andrew.lange@alcatel-lucent.com Mon Feb 28 20:17:53 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 814E53A6DA1 for ; Mon, 28 Feb 2011 20:17:53 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ik2C0gfYoGb for ; Mon, 28 Feb 2011 20:17:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 7BF5D3A6D9C for ; Mon, 28 Feb 2011 20:17:51 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p214Irk5026000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Feb 2011 22:18:53 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p214Irn4020888 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Feb 2011 22:18:53 -0600 Received: from neo-178.vpn.ind.alcatel.com (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Feb 2011 22:18:52 -0600 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-48-670862106"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew Lange In-Reply-To: Date: Mon, 28 Feb 2011 20:18:45 -0800 Message-ID: <83D89ADA-16C7-494C-A3EA-21445829ABBB@alcatel-lucent.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1082) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 04:17:53 -0000 --Apple-Mail-48-670862106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sriram, Why would you accept a route de-aggregated by an upstream? If signed = route-object says AS_A owns and announces only the route 1.2.3.0/20 and = I'm seeing 1.2.3.0/21 from AS_B, the route filter should be configured = not to accept more specifics. If AS_A wants to de-aggregate, it can = split it's route-objects into the more specifics and register them. Andrew On Feb 24, 2011, at 3:51 PM, Sriram, Kotikalapudi wrote: > Andrew, >=20 > Comment below. >=20 > Sriram >=20 >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of Andrew Lange >> Sent: Wednesday, February 23, 2011 6:17 PM >> To: Sandra Murphy >> Cc: sidr@ietf.org >> Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation = work >>=20 > --- snip --- >>=20 >> =46rom a work item perspective, it would be useful to have a = relationship object signed that >> says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections." = This information, >> combined with AS_A's signed route-objects means that downstream ASes = would be able to >> verify that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, = AS_B] or [AS_A, >> AS_Q] would be AS PATHs that could be authorized. Effectively = solving the Origin + >> Upstream issue would solve most of the problems. Yes, someone could = then spoof an >> announcement of origin+upstream+self, but then we're looking at a = minimum of a 3-AS >> path and the likelihood of that being best drops. We can also do = this with a simple route- >> filter and does not require on-system crypto calculations. >>=20 >> Andrew >>=20 > Yes, the path length goes up by 2. > But normally an adversary would spoof an announcement with a subprefix = (more specific)=20 > of the prefix that the legitimate prefix owner has announced=20 > (while still trying to keep within the maxlength as specified in the = ROA). > I that case the increased path length would not matter.=20 > The spoofed announcement would be accepted and propagated widely. >=20 > Sriram >=20 --Apple-Mail-48-670862106 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggZFMIIFLaAD AgECAhEA2STcHPwgFUjzymZ55K0wyzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA0MTQwMDAw MDBaFw0xMTA0MTQyMzU5NTlaMIHnMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEVMBMGA1UEAxMMQW5kcmV3IExhbmdlMS4wLAYJKoZIhvcNAQkBFh9hbmRyZXcu bGFuZ2VAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA zpUVaYV8lZ/sTUuCmVWLjpnZLO7Wfjs3QxQ/5bX6L8xkGdL5jhnDpuaI9ta4T+NuPO/AY07kaOUD 87n/Ze2TF4+rwLT48JXoxiJOSgY5qkuroK15qW24MpG1QT0nlodg83pqJQ7SqN8sFSSlnyWbB9/e WgAleEaJb6eNsiB0tncOslc5edI0IwEqEsIt2jhDIU7Lx3YGV/e5Z8J+tGrS7KY/WTbZXml8S6k9 RP44JI/Lrz/dbi+o9aqxTTj91StVRjj3JiboZ+oyLZmK1JEr04Deh+kZFpAHreKig4YhFreJr+lv ZMytmKdptyiFxEPn9mldZKYK2JaX5Ai1zR24awIDAQABo4ICITCCAh0wHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOupdX9c9crYS2uhB8HzOIVzTjg1MA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAqBgNVHREEIzAhgR9hbmRyZXcubGFuZ2VAYWxjYXRl bC1sdWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBO6f2sinZnDK3Vlh4lSGYGFE8YsBp8EIsA uFJQv7L4vsK9Y5DIO2pvAzjpKAaVe0gugQfyEAjmVOFnC2AvbWDaUYggZcX5WwzTP4aHHcVi8koB EQl6yEHtImNANjg67Q/twyjKtxHbt/7bdFFO/I/KwnGA1m2pu+WbQYpR/mGYc2uL/xuhMi5XfHLd WLeSLKB5pnLb30KuimuvXcNWKbSUO5wi8R4ihRHKTQo/VqUbd+qLk9lZyx2quSyjhZ5YzBkjnrey RU8WpBpQ2/1kB/iki8XVnUnkS5SyMcHz5eUpmWL08GfVqcU7phFLrGNOkQq0ztyYYh9MRrjlUG66 0VAEMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMAkGBSsOAwIaBQCgggIP MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMwMTA0MTg0NVow IwYJKoZIhvcNAQkEMRYEFIagejH/qGvQJdc/0sO94/xZ8JocMIHVBgkrBgEEAYI3EAQxgccwgcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1 c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANkk 3Bz8IBVI88pmeeStMMswDQYJKoZIhvcNAQEBBQAEggEALwZBfNZkGAH/9hieVXJEIYg0COKGTm36 dQmbT0BgfHoNlnXLG4y3vPhmmdDLnxkwzY8ziSR7CmsyVvbbN+Jga9pNPklWme4lELZTmVrKSKHL lrtJKpJ7JH5Q+8j4QSaWbm0yQwBPRgbq6vSFmh0e/p5Z+uPRKPOXFfvaEiR1U9s4IUeRA0iL1hGv /1VZ1SdcDHbFZFmpDJIaVBlw77SxAM2s0nRJhnpj1yhf6HN5Sy+2rdPqN30VsvpqKzZ7BAa3BbnR 51AWNvPEWrdDCj004QXkw9w/T9U6jIiepsPuX4jXlPSf3xN4WvY8pKSOp0OxpY+UbxUJDxFZMHy9 A1wwTgAAAAAAAA== --Apple-Mail-48-670862106-- From andrew.lange@alcatel-lucent.com Mon Feb 28 20:23:40 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C047A3A6D16 for ; Mon, 28 Feb 2011 20:23:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RalNpY5vrTE for ; Mon, 28 Feb 2011 20:23:39 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B23373A6DA3 for ; Mon, 28 Feb 2011 20:23:39 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p214IpaD025970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Feb 2011 22:18:51 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p214In0h020872 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Feb 2011 22:18:50 -0600 Received: from neo-178.vpn.ind.alcatel.com (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Feb 2011 22:18:50 -0600 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-46-670517790"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew Lange In-Reply-To: <481E716C-35F1-4197-BD8F-A41A86588508@apnic.net> Date: Mon, 28 Feb 2011 20:13:01 -0800 Message-ID: <594973C4-D013-45F3-8A71-40588B48E960@alcatel-lucent.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <4F6C2533-005B-4FF9-9EF0-6630570A3EC7@apnic.net> <5A3140DD-1358-4F65-88FD-E1B10AF991E1@alcatel-lucent.com> <481E716C-35F1-4197-BD8F-A41A86588508@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1082) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Sandra Murphy , "sidr@ietf.org wg" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 04:23:40 -0000 --Apple-Mail-46-670517790 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Geoff, My reasoning is that without a specific policy statement, such as "B = should be announcing this route, signed A", then we can demonstrate that = B did announce it, but not if B should have announced it. With that = policy object then we can construct the route filter to check that not = only did B announce it but if they should be doing so. =46rom an = operational perspective that has value. Andrew On Feb 23, 2011, at 6:01 PM, Geoff Huston wrote: > Andrew, >=20 > I hope I was neutral in neither agreeing or disagreeing as to its = utility in my comment. >=20 > I was simply checking your assertion that "it would be useful to have = a relationship object" and gently trying to understand your reasoning = behind holding that view. >=20 > Geoff >=20 >=20 >=20 > On 24/02/2011, at 9:12 AM, Andrew Lange wrote: >=20 >> Geoff, >>=20 >> Do you disagree as to its utility?=20 >>=20 >> Andrew >>=20 >> On Feb 23, 2011, at 4:16 PM, Geoff Huston wrote: >>=20 >>>=20 >>> On 24/02/2011, at 8:09 AM, Robert Loomans wrote: >>>=20 >>>>=20 >>>> On 24/02/2011, at 09:17, Andrew Lange wrote: >>>>=20 >>>>> =46rom a work item perspective, it would be useful to have a = relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q = as legitimate connections."=20 >>>>=20 >>>> Geoff published a (now expired) draft for just such an object: = http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03 >>>>=20 >>>=20 >>> and I can push it out again. >>>=20 >>> Andrew, I assume you are serious in claiming that this would be = useful to have in this context. >>>=20 >>> Geoff >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > -- >=20 > Geoff Huston > Chief Scientist, APNIC >=20 > +61 7 3858 3100 > gih@apnic.net >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-46-670517790 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggZFMIIFLaAD AgECAhEA2STcHPwgFUjzymZ55K0wyzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA0MTQwMDAw MDBaFw0xMTA0MTQyMzU5NTlaMIHnMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEVMBMGA1UEAxMMQW5kcmV3IExhbmdlMS4wLAYJKoZIhvcNAQkBFh9hbmRyZXcu bGFuZ2VAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA zpUVaYV8lZ/sTUuCmVWLjpnZLO7Wfjs3QxQ/5bX6L8xkGdL5jhnDpuaI9ta4T+NuPO/AY07kaOUD 87n/Ze2TF4+rwLT48JXoxiJOSgY5qkuroK15qW24MpG1QT0nlodg83pqJQ7SqN8sFSSlnyWbB9/e WgAleEaJb6eNsiB0tncOslc5edI0IwEqEsIt2jhDIU7Lx3YGV/e5Z8J+tGrS7KY/WTbZXml8S6k9 RP44JI/Lrz/dbi+o9aqxTTj91StVRjj3JiboZ+oyLZmK1JEr04Deh+kZFpAHreKig4YhFreJr+lv ZMytmKdptyiFxEPn9mldZKYK2JaX5Ai1zR24awIDAQABo4ICITCCAh0wHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOupdX9c9crYS2uhB8HzOIVzTjg1MA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAqBgNVHREEIzAhgR9hbmRyZXcubGFuZ2VAYWxjYXRl bC1sdWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBO6f2sinZnDK3Vlh4lSGYGFE8YsBp8EIsA uFJQv7L4vsK9Y5DIO2pvAzjpKAaVe0gugQfyEAjmVOFnC2AvbWDaUYggZcX5WwzTP4aHHcVi8koB EQl6yEHtImNANjg67Q/twyjKtxHbt/7bdFFO/I/KwnGA1m2pu+WbQYpR/mGYc2uL/xuhMi5XfHLd WLeSLKB5pnLb30KuimuvXcNWKbSUO5wi8R4ihRHKTQo/VqUbd+qLk9lZyx2quSyjhZ5YzBkjnrey RU8WpBpQ2/1kB/iki8XVnUnkS5SyMcHz5eUpmWL08GfVqcU7phFLrGNOkQq0ztyYYh9MRrjlUG66 0VAEMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMAkGBSsOAwIaBQCgggIP MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMwMTA0MTMwMVow IwYJKoZIhvcNAQkEMRYEFI79+D/VlmKwExbqcphuJGXZwfK7MIHVBgkrBgEEAYI3EAQxgccwgcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1 c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANkk 3Bz8IBVI88pmeeStMMswDQYJKoZIhvcNAQEBBQAEggEAvcvNEbJsF5jopaA3hXVtWo5ahVkRaSDJ 94p43HlLGXjYAvX6phyMDmqJsWfpw7SfaaB/bTnkI61+n8YUeLMG0+GBUAIoBdtnV2Fe73xDgNzB 9IQe9xRelYeJ/mnj6pLh368Z8LJ7HAhkTJEPfMQaut8bZ8HISRRbhahe/lTAdHAf6Yt00Y2oVSEU UJT+/1f21anqAi4slWZSfZZq45POI185a1raDa7VYDIKtS20b9/5afBtVG3Af4t0GPmOUUYHSvMW 0ArYBA0dh+s+38h3XW675az5H7Basl18Y2xVuOtT3dOicZDJHITnB+XSqx7Q04fof3MvCSd/mudp ByUVTgAAAAAAAA== --Apple-Mail-46-670517790-- From andrew.lange@alcatel-lucent.com Mon Feb 28 20:27:43 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68903A6A20 for ; Mon, 28 Feb 2011 20:27:43 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSJMjNIJf6C5 for ; Mon, 28 Feb 2011 20:27:42 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id CB4543A698D for ; Mon, 28 Feb 2011 20:27:42 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p214ShZ4025227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Feb 2011 22:28:43 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p214ShJf022269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Feb 2011 22:28:43 -0600 Received: from neo-178.vpn.ind.alcatel.com (135.3.63.241) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 28 Feb 2011 22:28:42 -0600 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary="Apple-Mail-49-671457155"; protocol="application/pkcs7-signature"; micalg=sha1 From: Andrew Lange In-Reply-To: Date: Mon, 28 Feb 2011 20:28:40 -0800 Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> To: Andrew Lange X-Mailer: Apple Mail (2.1082) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 04:27:44 -0000 --Apple-Mail-49-671457155 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii John, To reply to my own message, after reading through the rest of this = chain.=20 Is all we're trying to do here is to establish a "custodial chain" of a = route to prevent some ill-behaving AS in the middle attempting to hijack = a route, effectively by pretending that the source AS is behind it, = since we're origin-validating, and hoping that its neighbors end up = preferring it's longer-AS announcement over other, likely preferred = routes, from legitimate sources? If that is the case, having a set of policy objects expressing AS = relationship should do the same thing and more with less overhead? = (yes, I know that data integrity becomes an issue, but data integrity is = always an issue.) Andrew On Feb 28, 2011, at 8:16 PM, Andrew Lange wrote: > John, >=20 > But wouldn't a record of an existing announcement also show that AS_B = did in fact announce which of AS_A's routes and in what form? Why does = it need to be signed if all we want to do is record what happened? = Perhaps I'm missing something.... >=20 > Andrew >=20 > On Feb 24, 2011, at 5:27 AM, John G. Scudder wrote: >=20 >> Andrew, >>=20 >> On Feb 24, 2011, at 1:17 AM, Andrew Lange wrote: >>> Given the thread, I can understand your frustration. And, I could = have made myself more clear. I'll try: given the policies that AS_B = might be implementing, we cannot know for certain, without AS_B = publishing their policies, if AS_B should in fact be announcing which of = AS_A's routes or in what form, hence the use of the term "Plausible."=20 >>=20 >> Assume a model where the AS path is signed such that the recipient is = able to verify that for each arc in the path, the further AS did sign it = to the closer AS. To take your example and extend it, suppose we have >>=20 >> AS_A --> AS_B --> AS_C --> AS_D >>=20 >> (A announces a route to B announces it to C announces it to D.) If D = is able to verify the signature on the (B, C) arc, then it knows (for = some value of "knows" of course :-) that B did actually send the route = to C. Whether that fulfills "AS_B should in fact be announcing which of = AS_A's routes or in what form" I leave it to you to interpret -- it = doesn't protect against a policy misconfiguration on the announcing = router of AS_B. An abstract representation of AS_B's policy could do = that, but functionality like that is beyond the scope of the proposed = charter item. The fact that systems to provide exactly this kind of = abstract policy publication have fallen into disrepute doesn't fill me = with optimism about this approach, despite my own personal history with = it. >>=20 >> I interpret the proposed charter item to be asking not "if AS_B = *should* in fact be announcing which of AS_A's routes or in what form" = but rather roughly "if AS_B *did* in fact announce which of AS_A's = routes and in what form". >>=20 >> --John >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-49-671457155 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggZFMIIFLaAD AgECAhEA2STcHPwgFUjzymZ55K0wyzANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA0MTQwMDAw MDBaFw0xMTA0MTQyMzU5NTlaMIHnMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEVMBMGA1UEAxMMQW5kcmV3IExhbmdlMS4wLAYJKoZIhvcNAQkBFh9hbmRyZXcu bGFuZ2VAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA zpUVaYV8lZ/sTUuCmVWLjpnZLO7Wfjs3QxQ/5bX6L8xkGdL5jhnDpuaI9ta4T+NuPO/AY07kaOUD 87n/Ze2TF4+rwLT48JXoxiJOSgY5qkuroK15qW24MpG1QT0nlodg83pqJQ7SqN8sFSSlnyWbB9/e WgAleEaJb6eNsiB0tncOslc5edI0IwEqEsIt2jhDIU7Lx3YGV/e5Z8J+tGrS7KY/WTbZXml8S6k9 RP44JI/Lrz/dbi+o9aqxTTj91StVRjj3JiboZ+oyLZmK1JEr04Deh+kZFpAHreKig4YhFreJr+lv ZMytmKdptyiFxEPn9mldZKYK2JaX5Ai1zR24awIDAQABo4ICITCCAh0wHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFOupdX9c9crYS2uhB8HzOIVzTjg1MA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcC ARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFu ZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAC hipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGG GGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAqBgNVHREEIzAhgR9hbmRyZXcubGFuZ2VAYWxjYXRl bC1sdWNlbnQuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBO6f2sinZnDK3Vlh4lSGYGFE8YsBp8EIsA uFJQv7L4vsK9Y5DIO2pvAzjpKAaVe0gugQfyEAjmVOFnC2AvbWDaUYggZcX5WwzTP4aHHcVi8koB EQl6yEHtImNANjg67Q/twyjKtxHbt/7bdFFO/I/KwnGA1m2pu+WbQYpR/mGYc2uL/xuhMi5XfHLd WLeSLKB5pnLb30KuimuvXcNWKbSUO5wi8R4ihRHKTQo/VqUbd+qLk9lZyx2quSyjhZ5YzBkjnrey RU8WpBpQ2/1kB/iki8XVnUnkS5SyMcHz5eUpmWL08GfVqcU7phFLrGNOkQq0ztyYYh9MRrjlUG66 0VAEMYID/zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMAkGBSsOAwIaBQCgggIP MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMwMTA0Mjg0MVow IwYJKoZIhvcNAQkEMRYEFEcAQyfJSyleKVsyp9FNU/4J8wetMIHVBgkrBgEEAYI3EAQxgccwgcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAc BgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1 c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwCEQDZJNwc/CAVSPPKZnnkrTDLMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhl IFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANkk 3Bz8IBVI88pmeeStMMswDQYJKoZIhvcNAQEBBQAEggEAND2XCNu6NltFREMII/LZgm7Z+kyokolV Kj09/OzhNvRYLya/ZosbScLST1hABQue6pICkfotWgLWYdO02fyiyu9KTWJU4HZE4iLkXY0WzGzS SlAKuUcFYIC80n1h9FRUCqPqEbAcIJnBs1ABCBMJmQd7oIOqViMxzOOBbW6fMoCzfNV7B1CQ81Hb 56azs2VTlBFXOVDGmQgbZpNMPQYFRb0EcEttFyet2JKuoMl9638YC12PiExT4Oy3fngYr7BruRNE wqqYGdF4LTLWnOszjgKt75yWr+7SruYbctR7IWe7UdbawpM0P5zCvnPbU+cE7evvL0AoxsyQA0Yv vx0RdQAAAAAAAA== --Apple-Mail-49-671457155-- From christopher.morrow@gmail.com Mon Feb 28 21:13:59 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BEC3A69AB for ; Mon, 28 Feb 2011 21:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.462 X-Spam-Level: X-Spam-Status: No, score=-103.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 823wKiJLoWJu for ; Mon, 28 Feb 2011 21:13:59 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C0E4E3A68D2 for ; Mon, 28 Feb 2011 21:13:58 -0800 (PST) Received: by wwb22 with SMTP id 22so3020352wwb.13 for ; Mon, 28 Feb 2011 21:15:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uQG09vs7A6urIydel+1LsRcN76ZFx0MDgjRpMMltkmg=; b=V0hkiUdrAR473xjV97B9NpF3bbPWUuZIzwFgygM/kuqMrLlVhbbf9lAWtS2BGmArVS eNs+kojasmCE9szuOrmLrZo9LkHORdMM0GEBKX5ZRKzLbL71r1G5/Nu69m57/OK1JBtw kjF1CDy9arcSCW1CBcPE1MqPHSQIMhxPpS31E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=foSs8UCpuZq6oMFPpnFy/oY+4vpR62HI6t0v902rD0hpHDpRJuqS6yapBnREiwVvp1 x8Fhp4uxMv3JqbFmejVjydZGO2yxYZGKVXSl4t0vKKc/oGc76PRbzvZbIaoWl+4kCzWp fjvnzaadHTZjRRCslU3L4r/oPl2azwd7jmf+4= MIME-Version: 1.0 Received: by 10.216.79.80 with SMTP id h58mr5965404wee.111.1298956500149; Mon, 28 Feb 2011 21:15:00 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.1.197 with HTTP; Mon, 28 Feb 2011 21:14:59 -0800 (PST) In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> Date: Tue, 1 Mar 2011 00:14:59 -0500 X-Google-Sender-Auth: cGXKeiacyaPL7cgo9AEfSjCUbD8 Message-ID: From: Christopher Morrow To: Andrew Lange Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 05:13:59 -0000 On Mon, Feb 28, 2011 at 11:28 PM, Andrew Lange wrote: > > If that is the case, having a set of policy objects expressing AS relatio= nship should do the same > thing =A0and more with less overhead? (yes, I know that data integrity be= comes an issue, but data > integrity is always an issue.) if you go this route, how do you validate the data you've received from the datastore? how do you do this in the face of all of the myriad of datastores we have today of this same data which are rotten and unmaintained? -Chris From randy@psg.com Mon Feb 28 21:40:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084A63A6CC0 for ; Mon, 28 Feb 2011 21:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlM8b8qipP0X for ; Mon, 28 Feb 2011 21:40:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 4CA613A6A5A for ; Mon, 28 Feb 2011 21:40:37 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PuIKy-000Mp9-Pc; Tue, 01 Mar 2011 05:41:33 +0000 Date: Tue, 01 Mar 2011 14:41:31 +0900 Message-ID: From: Randy Bush To: Andrew Lange In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Sandra Murphy , "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 05:40:39 -0000 > If that is the case, having a set of policy objects expressing AS > relationship should do the same thing and more with less overhead? real policy is per prefix, customer, peer, and things disgustingly more complex, with complications of backdoor relationships, ibgp policies to implement regionalization, and a jillion things you would not want to tell your children. aside from not wanting to publish much of that, even if it was publishable, how would you differentiate 'the announcement really took this path' from 'it is possible that the announcemnt took this path?' the latter being a half-assed probabilistic assurance. randy From gih@apnic.net Mon Feb 28 22:08:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF843A6AA1 for ; Mon, 28 Feb 2011 22:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.455 X-Spam-Level: X-Spam-Status: No, score=-101.455 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xsLpx6bQ0Tr for ; Mon, 28 Feb 2011 22:08:36 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 657973A6CBA for ; Mon, 28 Feb 2011 22:08:34 -0800 (PST) Received: from dhcp75.potaroo.net (eth143.act.adsl.internode.on.net [203.16.208.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2D3A3B649C; Tue, 1 Mar 2011 16:09:34 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-20-677505414; protocol="application/pkcs7-signature"; micalg=sha1 From: Geoff Huston In-Reply-To: Date: Tue, 1 Mar 2011 17:09:28 +1100 Message-Id: <72E92A4A-175E-4697-A9A5-F307B10F7AD2@apnic.net> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> To: Andrew Lange X-Mailer: Apple Mail (2.1082) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 06:08:38 -0000 --Apple-Mail-20-677505414 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>=20 >> If that is the case, having a set of policy objects expressing AS = relationship should do the same >> thing and more with less overhead? (yes, I know that data integrity = becomes an issue, but data >> integrity is always an issue.) I was deliberately keeping away from participating in this conversation, = but I have researched this topic in some depth in recent times = (http://www.potaroo.net/papers/BGP_Security_Literature_Review.pdf), and = I think that I have some familiarity with this topic that may be helpful = to others who are also watching this and trying to understand what is = being debated here. What I see here is a dichotomy between two distinct architectural = approaches, and the conversation appears to flip from one to the other = when we discuss path validation.=20 One view is that we are securing the operation of a particular protocol, = namely BGP. This protocol operates in a standard distance vector mode of = AShop-by-AShop, where information is propagated outward from the causal = point. If you want to secure this protocol, then there are two = fundamental attributes of the protocol's transitive data objects that = are securable, namely the address prefix and the AS path. The AS path is = constructed incrementally in this protocol, and the most direct = mechanism that would allow it to be secured is for each AS to be able to = demonstrate the validity of what it received and what it added. I.e. = incremental signing of elements of the AS path as the basic unit of = routing information propagates across the inter-AS network. To the = extent that this is an accurate reflection of the underlying inter AS = connection topology, EBGP multi-hop notwithstanding, this is an accurate = reflection of a subset of the interAS topology, and it allows a BGP = speaker the ability to validate, in the context of the operation of BGP = the protocol, information that is being propagated by BGP. The other view I see is a reflection of the observation that BGP, like = any other inter-domain routing protocol, is a mechanism that "discovers" = the inter-AS topology of the network. If you already "know" the "real" = topology via some other mechanism, then you can use this information as = a filter for information being passed to you in the routing protocol. = i.e. In this instance if you had complete information of all "valid" AS = adjacencies then you could use this as an information filter for AS = paths that you are being presented with via BGP. If an AS path contains = an assertion of an AS adjacency that is not in your local "map then you = have grounds to doubt that the information you are be presented with in = this particular update is in fact "valid" Superficially, this second approach is seductively attractive: its = simple to conceptualise, relatively lightweight and probably fast in = terms of processing overheads, and makes the minimum of assumptions as = to the way the protocol itself operates. This decoupling of the = propagation of the security credentials from the protocol operations = also appears to be consistent with the approach being taken to securing = origination - the security credentials are flooded via some other = mechanism and they are used locally to maintain a local route filter = which is then used to pass / reject incoming route updates in BGP based = on the implicit AS adjacencies that are being asserted in the AS Path. But this is a superficial attraction as I see it. This decoupled = approach still admits lies in routing. It limits the extent to which one = can lie, but it still admits lies.=20 However, I don't think this aspect of the issue of AS Plausibility vs AS = Path Provability is the core of the issue _for me_ (others see it = differently and want a stricter condition). More importantly for me at = any rate, is that this decoupling of topology information from the = operation of the protocol potentially stops the operation of the routing = protocol to be a topology discovery tool. If AS 1 and AS2 bring up a = peering session, then no one else will believe that adjacency (or the = routes that use that adjacency) until the security credentials of the = pairwise adjacency of AS1 and AS2 has already flooded the network. And = how does this association get flooded? Equally, how do you inform = everyone else that a peering session has been torn down? Or that this AS = adjacency has some policy constraints that are intended to limit the = scope of its visibility? As long as you are prepared to limit your = concept of the scope of a routing protocol to be one of best path = computation over a relatively fixed topology that all players know of in = advance then this idea of a decoupled approach to propagation of AS = adjacencies and the operation of the protocol itself could well be a = viable approach to securing the outcomes of the operation of the = protocol, or at least limiting the range of potential ways to lie in the = protocol. But if you also want some level of dynamic discovery of the = underlying topology as well as path computation in the scope of the = operation of the protocol, then you are asking a lot of this form of = decoupling of securing the underlying inter-AS topology from the = operation of the routing protocol, because at some point you need to = distribute the information of a new AS adjacency at the same time as you = want to pass the routing protocol packet. I.e. If you want to secure = what BGP is telling you in the AS Path then it makes sense to use a = mechanism that is directly associated with the manner of the = construction of the AS Path itself, within BGP itself. And if you couple = the security credentials to the protocol not only do you get dynamic = behaviour of topology discovery, you also get AS Provability in so far = as you are now back to being able to validate that the path of = propagation of the update matches the path describes in the update. (I note that the same argument of using in-band security credentials to = enable dynamic discovery of routing information could be applied to = origination security credentials and their manner of distribution, and I = also note that the WG decided not to go down that path for securing = origination. But having made that decision, I don't think that this = decision for the manner of securing origination necessarily precludes = the WG from using the BGP protocol mechanisms to bind the AS Path and = the AS Path security credentials together. I do however think that sBGP, = which as I recall bundles both origination and path security credentials = into the BGP protocol payload together with the routing data that the = credentials relate to, still strikes me as an approach that has an = attractive level of architectural consistency. :-) ) The above is all my own opinion, naturally! Now to clamber off this soap = box and head back to hide in my corner! regards, Geoff --Apple-Mail-20-677505414 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEATCCA/0w ggLloAMCAQICCCNaPoEoCivFMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTEwMTEwMzAwMTYxN1oXDTEx MTEwMzAwMTYxN1owgY0xEzARBgoJkiaJk/IsZAEBDANnaWgxFTATBgNVBAMMDEdlb2ZmIEh1c3Rv bjEOMAwGA1UEKgwFR2VvZmYxDzANBgNVBAQMBkh1c3RvbjEPMA0GA1UECwwGUGVvcGxlMRYwFAYD VQQKDA1BUE5JQyBQdHkgTHRkMRUwEwYKCZImiZPyLGQBGRYFc3RhZmYwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDKZPR8bfiBwWKDAK5gn3AdDFuKAl+RS+g5utzhXWp9UFDIW/uXwGSH vCZf2do2VmlwB5BwfPqyD0UQ+jrISPVBe7oeR4sHj9dfuTj6IVgWtYGYTdsXl2Bw2/byG8Zcksra 8LP4m1wnBb0TgxjxBGQABYCiY9w2qymbBg76KbU6SgrC0+JJop+NUMnk1s4W46Y/Sy+1DzBKSf/F Y8OoQkQm2kZykQdDqmCZ+aVT03I/Ac1BOmw/YWMBDzBjXAt6pcLk5Q2TM8/9fONyf9FzaLEaqn5h 8H3I/kEfLPuRTiPHdtyQDdDv0+Ls/sl6kABRCke1o5Fd5xYeB5YPGlr0reSLAgMBAAGjejB4MB0G A1UdDgQWBBR7n+TxN1+Ld4rVmUysk4E0Du7i1jAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFOA9 t5Jb7i6jsj5520WrMEIvAUusMA4GA1UdDwEB/wQEAwIB8jAYBgNVHREEETAPgQ1naWhAYXBuaWMu bmV0MA0GCSqGSIb3DQEBBQUAA4IBAQAdSobYsDIcdZeRVpF9MiGfHwTbbcpDzOPc0WB2VbUAXxO/ Wp+GywrA7I3ZEOA9YiSyc9qXUmW9Agh1ZlbqXfz3RleRV6eDBuCbV+RUMUm3jzfKIFxCgMgyJQrw 2WDvtwQFeJjUfiooIwhxUPq9luaug6yGinQ1IbW98PpY75w1M+hMgrDEYEr0LtSsLfxfuNbZhQfo lWXD/xJ960WHfRKXRRo9hKjPRWJOH8WJRNQfRfMTBl/1GLg/OWK8ah0YvVE0TBxPYvYwYcn6FPOt gclwCDc8IiV8lLeYquJYFsiVnCBTZzLbMXmKPLB80fIHfhMvUcOu4Iak9OBXDShWOwfFMYIDLTCC AykCAQEwfzBzMREwDwYDVQQDDAhzdGFmZi1jYTESMBAGA1UECwwJVGVjaG5pY2FsMRYwFAYDVQQK DA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhCcmlzYmFuZTESMBAGCgmSJomT8ixkARkWAmNhMQsw CQYDVQQGEwJBVQIII1o+gSgKK8UwCQYFKw4DAhoFAKCCAYMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwMzAxMDYwOTI5WjAjBgkqhkiG9w0BCQQxFgQUMhQaW+p4 U2jjo/IwHiLcVJ1LY4cwgY8GCSsGAQQBgjcQBDGBgTB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVAggjWj6BKAorxTCBkQYLKoZIhvcN AQkQAgsxgYGgfzBzMREwDwYDVQQDDAhzdGFmZi1jYTESMBAGA1UECwwJVGVjaG5pY2FsMRYwFAYD VQQKDA1BUE5JQyBQdHkgTHRkMREwDwYDVQQHDAhCcmlzYmFuZTESMBAGCgmSJomT8ixkARkWAmNh MQswCQYDVQQGEwJBVQIII1o+gSgKK8UwDQYJKoZIhvcNAQEBBQAEggEAPI/xoPkgvu959Y79W0Bz hBEfl4m7Sq1K1p6kOqM9q+IED565ghHHlLQ6Lyc40Odoa3e0eaHHyxtNiYMRGD6bn4QqN3xepA1s qZMvpZvRUCL6F25W7zEqlh27zskVJo977rLbUwRfVhOrTNCwqnyD7JYLA1tPIAe5bcH80sajx5gA O5Xz3aU1bIwo7Jef1gHZPeL6B+P2KNHv5sDhpc5HzLgO/smG4AxhXdUAQh0q8uedup5wf3SRjoJ2 mcfTrAGF4JSjjzG0t1JwmDNpXFjrTnxQwQ8gqsuH4MVtbWwNmJSEVggFmDVxVZfAUmOyTb6K4o7r TWYr09AWh6ru7KBb9wAAAAAAAA== --Apple-Mail-20-677505414--