From jgs@juniper.net Sat Apr 3 17:42:34 2010 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 868053A6957 for ; Sat, 3 Apr 2010 17:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 PNg8Pq7qQCcb for ; Sat, 3 Apr 2010 17:42:33 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id BD83E3A68BD for ; Sat, 3 Apr 2010 17:42:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS7fgdYtYdtc4IPiXnmWnC/KFexXoBj0t@postini.com; Sat, 03 Apr 2010 17:42:33 PDT Received: from [172.16.13.201] (172.16.13.201) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.393.1; Sat, 3 Apr 2010 17:39:32 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 3 Apr 2010 20:39:31 -0400 Message-ID: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net> To: MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 04 Apr 2010 00:42:34 -0000 Geoff and George, I noticed the following in Section 2 of = draft-ietf-sidr-roa-validation-05: A route's "origin AS" is the final element of the route object's AS_PATH attribute. If the final AS_PATH element is an AS Set, indicating that the route is an aggregate, then the origin AS is taken as the AS component of the AGGREGATOR attribute [RFC4271]. In the case where there is an AS Set as the final AS_PATH element and no AGGREGATOR attribute is present then the origin AS is the AS immediately preceding the AS Set in the AS_PATH, and if there is no such AS then the route's origin AS cannot be determined. Granted this is a corner case, but nonetheless I can't see what the = reason would be for considering an intermediate AS (albeit the first one = contained in an AS_SEQUENCE) to be the origin. I suggest revising as = follows: Consider the origin AS to be the contents of the AS_SET if it's = a singleton set. Otherwise the origin cannot be determined. Given that it's a corner case, you could also cut right to the chase and = just call it undetermined if the path starts (or ends, in your parlance) = with an AS_SET, period. --John= From randy@psg.com Sat Apr 3 18:12:39 2010 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 E2E033A68AA for ; Sat, 3 Apr 2010 18:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 o3N8X0yvM9Hg for ; Sat, 3 Apr 2010 18:12:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 003533A6876 for ; Sat, 3 Apr 2010 18:12:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NyEO8-0007SS-3C; Sun, 04 Apr 2010 01:12:32 +0000 Date: Sun, 04 Apr 2010 10:12:31 +0900 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net> References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: draft-ietf-sidr-roa-validation@tools.ietf.org, sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 04 Apr 2010 01:12:40 -0000 > Given that it's a corner case, you could also cut right to the chase > and just call it undetermined if the path starts (or ends, in your > parlance) with an AS_SET, period. if the originating asn is a set, the prefix is 'matched' by a roa, yet there is no aggregator, i might consider it invalid. if the originating asn is a set, the orgin asn has an is an aggregator, but it is not for a 'matching' roa's asn, i might consider it invalid. randy From gih@apnic.net Sun Apr 4 02:24:43 2010 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 358043A68EE for ; Sun, 4 Apr 2010 02:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 KI4aPS6I6AEI for ; Sun, 4 Apr 2010 02:24:42 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 335AB3A6881 for ; Sun, 4 Apr 2010 02:24:42 -0700 (PDT) Received: from dhcp71.potaroo.net (dhcp71.potaroo.net [203.10.60.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C278AD589B; Sun, 4 Apr 2010 19:24:36 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net> Date: Sun, 4 Apr 2010 19:24:31 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net> To: John G. Scudder X-Mailer: Apple Mail (2.1078) Cc: draft-ietf-sidr-roa-validation@tools.ietf.org, sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 04 Apr 2010 09:24:43 -0000 On 04/04/2010, at 10:39 AM, John G. Scudder wrote: > Geoff and George, >=20 > I noticed the following in Section 2 of = draft-ietf-sidr-roa-validation-05: >=20 > A route's "origin AS" is the final element of the route object's > AS_PATH attribute. If the final AS_PATH element is an AS Set, > indicating that the route is an aggregate, then the origin AS is > taken as the AS component of the AGGREGATOR attribute [RFC4271]. In > the case where there is an AS Set as the final AS_PATH element and = no > AGGREGATOR attribute is present then the origin AS is the AS > immediately preceding the AS Set in the AS_PATH, and if there is no > such AS then the route's origin AS cannot be determined. >=20 > Granted this is a corner case, but nonetheless I can't see what the = reason would be for considering an intermediate AS (albeit the first one = contained in an AS_SEQUENCE) to be the origin. I suggest revising as = follows: Consider the origin AS to be the contents of the AS_SET if it's = a singleton set. Otherwise the origin cannot be determined. >=20 > Given that it's a corner case, you could also cut right to the chase = and just call it undetermined if the path starts (or ends, in your = parlance) with an AS_SET, period. Thanks for this comment John. As a background here I had performed a = brief search through what I though was the obvious RFCs and related drafts to find a definition of the "Origin AS" and came up with nothing I could readily reference in this draft, so I found that I had to provide a workable definition of an "origin AS". The definition as stated in the draft is an uncomfortable hybrid in so = far as it conflates an originator with an aggregator, and in the light of your comments, thats probably a step too far. So how about I take your advice and cut to the chase with: "A route's "origin AS" is the final element of the route object's AS_PATH attribute. If the final AS_PATH element is an AS Set, indicating that the route is an aggregate, then the origin AS cannot be determined." Does that work? kind regards, Geoff From kotikalapudi.sriram@nist.gov Sun Apr 4 20:23:50 2010 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 A3B6D3A686A for ; Sun, 4 Apr 2010 20:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 xP1YsaoA5-nb for ; Sun, 4 Apr 2010 20:23:49 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 643253A68AB for ; Sun, 4 Apr 2010 20:23:32 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o353N8KI017251; Sun, 4 Apr 2010 23:23:08 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sun, 4 Apr 2010 23:23:08 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston , "John G. Scudder" Date: Sun, 4 Apr 2010 23:22:46 -0400 Thread-Topic: [sidr] Comment on draft-ietf-sidr-roa-validation-05 Thread-Index: AcrT2LcLV3TIOjL4Q2WHpCmxYdWThgAlQ3yJ Message-ID: References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> In-Reply-To: <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.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-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "draft-ietf-sidr-roa-validation@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 03:23:51 -0000 Geoff: George: Are you leaning towards an "Invalid" or "Unknown" for the decision when an AS set is found for the origin AS in an update? I think when we had a discussion on this topic long time ago, the thinking was that we should try to discourage the usage of AS sets. I am trying to figure if that meant calling the=20 update "Invaid" in this situation? Sriram=20 ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Geoff Hust= on [gih@apnic.net] Sent: Sunday, April 04, 2010 5:24 AM To: John G. Scudder Cc: draft-ietf-sidr-roa-validation@tools.ietf.org; sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 On 04/04/2010, at 10:39 AM, John G. Scudder wrote: > Geoff and George, > > I noticed the following in Section 2 of draft-ietf-sidr-roa-validation-05= : > > A route's "origin AS" is the final element of the route object's > AS_PATH attribute. If the final AS_PATH element is an AS Set, > indicating that the route is an aggregate, then the origin AS is > taken as the AS component of the AGGREGATOR attribute [RFC4271]. In > the case where there is an AS Set as the final AS_PATH element and no > AGGREGATOR attribute is present then the origin AS is the AS > immediately preceding the AS Set in the AS_PATH, and if there is no > such AS then the route's origin AS cannot be determined. > > Granted this is a corner case, but nonetheless I can't see what the reaso= n would be for considering an intermediate AS (albeit the first one contain= ed in an AS_SEQUENCE) to be the origin. I suggest revising as follows: Con= sider the origin AS to be the contents of the AS_SET if it's a singleton se= t. Otherwise the origin cannot be determined. > > Given that it's a corner case, you could also cut right to the chase and = just call it undetermined if the path starts (or ends, in your parlance) wi= th an AS_SET, period. Thanks for this comment John. As a background here I had performed a brief search through what I though was the obvious RFCs and related drafts to find a definition of the "Origin AS" and came up with nothing I could readily reference in this draft, so I found that I had to provide a workable definition of an "origin AS". The definition as stated in the draft is an uncomfortable hybrid in so far as it conflates an originator with an aggregator, and in the light of your comments, thats probably a step too far. So how about I take your advice and cut to the chase with: "A route's "origin AS" is the final element of the route object's AS_PATH attribute. If the final AS_PATH element is an AS Set, indicating that the route is an aggregate, then the origin AS cannot be determined." Does that work? kind regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Sun Apr 4 21:47:24 2010 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 990B13A6888 for ; Sun, 4 Apr 2010 21:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=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 5F9YNivb+v6t for ; Sun, 4 Apr 2010 21:47:23 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C815D3A687B for ; Sun, 4 Apr 2010 21:47:23 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0BED0268674; Sun, 4 Apr 2010 22:47:22 -0600 (MDT) Received: from [192.168.1.64] (97-118-206-171.hlrn.qwest.net [97.118.206.171]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sun, 04 Apr 2010 22:47:21 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.206.171; client-port=56310; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Danny McPherson In-Reply-To: Date: Sun, 4 Apr 2010 22:47:21 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 04:47:24 -0000 On Apr 4, 2010, at 9:22 PM, Sriram, Kotikalapudi wrote: > > Are you leaning towards an "Invalid" or "Unknown" for the decision > when an AS set is found for the origin AS in an update? > I think when we had a discussion on this topic long time ago, > the thinking was that we should try to discourage the usage > of AS sets. I am trying to figure if that meant calling the > update "Invaid" in this situation? Of ~344k prefixes in the current routing system: Today: o 61 prefixes with AS_SETS o 50 only include a single AS in the set o only 48 different sets appear o 1 includes only 4 occurrences of the same AS o 1 includes 4 occurrences of the same AS and an IANA DSU AS o 5 of those have an origin code of incomplete In 2005: o 45 prefixes with AS_SETS o 31 only include a single AS in the set o only 39 different sets appear o 1 includes a unique AS and an IANA DSU AS o 4 with incomplete origin code So, one couple make an assumption that only 9 of these have any chance of being an problem today, and it might well not be an issue -- unless you're one of those folks, of course. As long as the spec supports it and people use it, we need to, methinks... -danny From randy@psg.com Sun Apr 4 22:41:03 2010 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 C48753A6783 for ; Sun, 4 Apr 2010 22:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 06VmQqZnmZmg for ; Sun, 4 Apr 2010 22:41:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 21F2B3A6767 for ; Sun, 4 Apr 2010 22:41:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nyf3O-000Bt1-M8; Mon, 05 Apr 2010 05:40:54 +0000 Date: Mon, 05 Apr 2010 14:40:53 +0900 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 05:41:03 -0000 > Today: > o 61 prefixes with AS_SETS > o 50 only include a single AS in the set > o only 48 different sets appear > o 1 includes only 4 occurrences of the same AS > o 1 includes 4 occurrences of the same AS and an IANA DSU AS > o 5 of those have an origin code of incomplete > > In 2005: > o 45 prefixes with AS_SETS > o 31 only include a single AS in the set > o only 39 different sets appear > o 1 includes a unique AS and an IANA DSU AS > o 4 with incomplete origin code what do you mean incomplete origin code? AGGREGATOR or igp flag? how many in the originating position, i.e. the first on the as-path? i think that is the issue here. but 33% growth in five years is a major market! :) randy From gih@apnic.net Mon Apr 5 00:34:17 2010 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 F3D743A6835 for ; Mon, 5 Apr 2010 00:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 nsca4RUB3AZH for ; Mon, 5 Apr 2010 00:34:16 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id D0B033A6802 for ; Mon, 5 Apr 2010 00:34:15 -0700 (PDT) Received: from dhcp70.potaroo.net (dhcp70.potaroo.net [203.10.60.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 29318D57BD; Mon, 5 Apr 2010 17:34:11 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 5 Apr 2010 17:34:05 +1000 Content-Transfer-Encoding: 7bit Message-Id: <517DA84C-F658-4979-AAE9-A1E737906F11@apnic.net> References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1078) Cc: "draft-ietf-sidr-roa-validation@tools.ietf.org" , "John G. Scudder" , "sidr@ietf.org" Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 07:34:17 -0000 On 05/04/2010, at 1:22 PM, Sriram, Kotikalapudi wrote: > Geoff: > George: > > Are you leaning towards an "Invalid" or "Unknown" for the decision > when an AS set is found for the origin AS in an update? > I think when we had a discussion on this topic long time ago, > the thinking was that we should try to discourage the usage > of AS sets. I am trying to figure if that meant calling the > update "Invaid" in this situation? > > Sriram > > Hi, Given that I am assuming that in the case of a route with an AS Set the origin AS is unable to be determined, then if a valid ROA exists where the address prefix in the route object "matches" the prefix in the ROA, then outcome of the validation operation would be "invalid" within the scope of the semantics of route object validation as specified in section 2 of the roa-validation draft(*). And IF no valid ROA exists where the address prefix in the route object "matches" the prefix in the ROA, then outcome of the validation operation would be "unknown", again by application of the same pseudo-algorithm specified in that draft (*). regards, Geoff * to quote the draft: Route validation is defined by the following procedure: 1. Select all valid ROAs that include a ROAIPAddress value that either matches, or is a covering aggregate of, the address prefix in the route. 2. If the set of candidate ROAs is empty then the validation procedure stops with an outcome of "unknown". 3. If any of the selected ROAs has an asID value that matches the origin AS in the route, and the route object's address prefix matches a ROAIPAddress in the ROA (where "match" is defined as where the route object's address precisely matches the ROAIPAddress, or where the ROAIPAddress includes a maxLength element, and the route's address prefix is a more specific prefix of the ROAIPAddress, and the route's address prefix length value is less than or equal to the ROAIPAddress maxLength value) then the validation procedure stops with an outcome of "valid". 4. Otherwise, the validation procedure stops with an outcome of "invalid". From robert@ripe.net Mon Apr 5 01:01:17 2010 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 2FD843A67D3 for ; Mon, 5 Apr 2010 01:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 YBs6JjsgesnU for ; Mon, 5 Apr 2010 01:01:16 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 252B83A6765 for ; Mon, 5 Apr 2010 01:01:16 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1NyhF4-0008RT-Vd for sidr@ietf.org; Mon, 05 Apr 2010 10:01:12 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=Kistel-Mac.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NyhF4-0007mY-QH for sidr@ietf.org; Mon, 05 Apr 2010 10:01:06 +0200 Message-ID: <4BB998C2.2040801@ripe.net> Date: Mon, 05 Apr 2010 10:01:06 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sidr@ietf.org References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27475bab1e634698e4b701ef885557b48d9 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27475bab1e634698e4b701ef885557b48d9 Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 08:01:17 -0000 On 2010.04.05. 6:47, Danny McPherson wrote: > Of ~344k prefixes in the current routing system: [...] > So, one couple make an assumption that only 9 of these have any > chance of being an problem today, and it might well not be an issue > -- unless you're one of those folks, of course. > > As long as the spec supports it and people use it, we > need to, methinks... > > -danny I disagree with this. I think that spending hours and hours on specifying, debating, coding, testing, etc. a feature that is used in 0.02% (or 0.003%, depending on how you count) of the cases is not a good investment, imo. Such an underused feature will not have a well tested codebase, with all possible bugs ironed out, which is a recipe for security problems. Robert From danny@tcb.net Mon Apr 5 05:42:08 2010 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 45A1D3A696E for ; Mon, 5 Apr 2010 05:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, 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 IkQikS+R8PFj for ; Mon, 5 Apr 2010 05:42:07 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 81B5D3A6933 for ; Mon, 5 Apr 2010 05:42:07 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id A5BC026866F; Mon, 5 Apr 2010 06:42:05 -0600 (MDT) Received: from [192.168.1.64] (97-118-206-171.hlrn.qwest.net [97.118.206.171]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 05 Apr 2010 06:42:05 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.206.171; client-port=61115; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 5 Apr 2010 06:42:04 -0600 Content-Transfer-Encoding: 7bit Message-Id: <7529122E-C2E5-41DB-B857-04920280F4C7@tcb.net> References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net> To: Randy Bush X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 12:42:08 -0000 On Apr 4, 2010, at 11:40 PM, Randy Bush wrote: > what do you mean incomplete origin code? AGGREGATOR or igp flag? I mean the ORIGIN attribute (i.e., INCOMPLETE v. EGP v. IGP). > how many in the originating position, i.e. the first on the as-path? > i think that is the issue here. > > but 33% growth in five years is a major market! :) So, actually, if you were to exclude the ones that have only a single AS in the AS_SET, there were 14 in 2005 and are only 11 now, so it's actually a decrease in the last 5 years. As for the ones that have a single AS in the AS_SET, I'd venture a guess that they're not necessarily intentional, but instead are simply an artifact *OS configuration mechanics (e.g., 'aggregate-address ... ... as-set'). -danny --- as-sets.txt (20100404) 1 {14083} i 1 {14707} i 1 {16678} i 1 {17348} i 1 {17378} i 1 {18669} i 1 {19636} i 1 {20251} i 1 {209,25729} i 1 {21135,49476} i 1 {22620} i 1 {23468} i 1 {23491} i 1 {25019,41426} ? 1 {25576} i 1 {2561} ? 1 {2561} i 1 {25784} ? 1 {25846} ? 1 {25912} i 1 {26262} i 1 {2732} i 1 {2764} ? 1 {2764} i 1 {28571} i 1 {32941} i 1 {33395} i 1 {34037} i 1 {3491,15412,19710} i 1 {35821,35821,35821,35821} i 1 {35970} i 1 {36647} i 1 {40986} i 1 {45514,45514,45514,45514,65081} i 1 {4558,30994,33770} i 1 {46124,46136} i 1 {47798} i 1 {6127} i 1 {6556} i 1 {8002,15412} i 2 {11060,12262} i 2 {25784} i 2 {32734} i 2 {32885} i 2 {40616} i 2 {6877} i 3 {20148} i 6 {4237} i From danny@tcb.net Mon Apr 5 05:52:29 2010 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 876A63A6992 for ; Mon, 5 Apr 2010 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.347 X-Spam-Level: X-Spam-Status: No, score=-100.347 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_20=-0.74, J_CHICKENPOX_41=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 wJGcIpadfuTb for ; Mon, 5 Apr 2010 05:52:28 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 00EF328C0E6 for ; Mon, 5 Apr 2010 05:52:26 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 8B93526866F; Mon, 5 Apr 2010 06:52:24 -0600 (MDT) Received: from [192.168.1.64] (97-118-206-171.hlrn.qwest.net [97.118.206.171]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 05 Apr 2010 06:52:24 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.206.171; client-port=61122; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4BB998C2.2040801@ripe.net> Date: Mon, 5 Apr 2010 06:52:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <56C7A12A-ECE5-4869-A3AD-76F2EBE65D3E@tcb.net> References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> <4BB998C2.2040801@ripe.net> To: Robert Kisteleki X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 12:52:29 -0000 On Apr 5, 2010, at 2:01 AM, Robert Kisteleki wrote: >=20 > I disagree with this. I think that spending hours and hours on = specifying, debating, coding, testing, etc. a feature that is used in = 0.02% (or 0.003%, depending on how you count) of the cases is not a good = investment, imo. >=20 > Such an underused feature will not have a well tested codebase, with = all possible bugs ironed out, which is a recipe for security problems. My point was, it's all about perspective. Whether you like it or not,=20= not accommodating those networks when adding new capabilities, when=20 those routes are perfectly legitimate (i.e., within spec of a standards=20= track document) and work just fine today, is inappropriate. =20 As I've stated before, if we do things in SIDR that introduce new=20 constraints on what and how people are doing something today that's completely within the bounds of legitimacy, then we ought to have a=20 darn good reason to do so. That said, it might be less resource intensive to just contact those=20 folks originating AS_SETs and convince them they don't need'm - assuming they don't. -danny From Sandra.Murphy@cobham.com Mon Apr 5 11:29:11 2010 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 9ED5F3A6853 for ; Mon, 5 Apr 2010 11:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_41=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 r2m0Lnv4Nd9q for ; Mon, 5 Apr 2010 11:29:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 96B683A659A for ; Mon, 5 Apr 2010 11:29:10 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o35IT7TN027722; Mon, 5 Apr 2010 13:29:07 -0500 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 o35IT3EM005690; Mon, 5 Apr 2010 13:29:07 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Apr 2010 14:28:57 -0400 Date: Mon, 5 Apr 2010 14:28:57 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: <56C7A12A-ECE5-4869-A3AD-76F2EBE65D3E@tcb.net> Message-ID: References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> <4BB998C2.2040801@ripe.net> <56C7A12A-ECE5-4869-A3AD-76F2EBE65D3E@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Apr 2010 18:28:57.0464 (UTC) FILETIME=[DAADC780:01CAD4ED] Cc: sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 18:29:11 -0000 On Mon, 5 Apr 2010, Danny McPherson wrote: > > On Apr 5, 2010, at 2:01 AM, Robert Kisteleki wrote: > >> >> I disagree with this. I think that spending hours and hours on specifying, debating, coding, testing, etc. a feature that is used in 0.02% (or 0.003%, depending on how you count) of the cases is not a good investment, imo. >> >> Such an underused feature will not have a well tested codebase, with all possible bugs ironed out, which is a recipe for security problems. > > My point was, it's all about perspective. Whether you like it or not, > not accommodating those networks when adding new capabilities, when > those routes are perfectly legitimate (i.e., within spec of a standards > track document) and work just fine today, is inappropriate. There's also the point to be concerned about, which is defining the validation of BGP routes to handle an AS_SET origin, to avoid creating a way for an attacker to counter the validation check. No matter how few times the feature is used in practice, the feature exists in BGP and in the implemented code. Not used in practice does not mean it could not be used in malice. So, for a wild example, suppose the validation check looked to see if one single AS in the origin AS_SET matched a valid ROA for the prefix, and passed the BGP route as valid. That would give a malicious person a way to ensure that their bogus route would be accepted. If on the other hand, the validation code looked to see if all ASs in the AS_SET matched a valid ROA, that might break legitimate uses. We need a defined way to deal with AS_SETs that doesn't afford opportunities for the malicious source while still permitting either the accidental or the rare intentional use. --Sandy > > As I've stated before, if we do things in SIDR that introduce new > constraints on what and how people are doing something today that's > completely within the bounds of legitimacy, then we ought to have a > darn good reason to do so. > > That said, it might be less resource intensive to just contact those > folks originating AS_SETs and convince them they don't need'm - > assuming they don't. > > -danny > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From danny@tcb.net Mon Apr 5 11:37:34 2010 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 CB7143A693E for ; Mon, 5 Apr 2010 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.46 X-Spam-Level: X-Spam-Status: No, score=-100.46 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_50=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 WdGD3Ch9NZYp for ; Mon, 5 Apr 2010 11:37:34 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id F31C028C146 for ; Mon, 5 Apr 2010 11:37:33 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 1E99126867A; Mon, 5 Apr 2010 12:37:32 -0600 (MDT) Received: from [192.168.1.64] (97-118-206-171.hlrn.qwest.net [97.118.206.171]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 05 Apr 2010 12:37:31 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.206.171; client-port=51218; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 5 Apr 2010 12:37:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1EE7DC95-CDDF-4509-9B70-107440BF1DD2@tcb.net> References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> <4BB998C2.2040801@ripe.net> <56C7A12A-ECE5-4869-A3AD-76F2EBE65D3E@tcb.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 18:37:34 -0000 On Apr 5, 2010, at 12:28 PM, Sandra Murphy wrote: > There's also the point to be concerned about, which is defining the = validation of BGP routes to handle an AS_SET origin, to avoid creating a = way for an attacker to counter the validation check. >=20 > No matter how few times the feature is used in practice, the feature = exists in BGP and in the implemented code. Not used in practice does = not mean it could not be used in malice. >=20 > So, for a wild example, suppose the validation check looked to see if = one single AS in the origin AS_SET matched a valid ROA for the prefix, = and passed the BGP route as valid. That would give a malicious person a = way to ensure that their bogus route would be accepted. If on the other = hand, the validation code looked to see if all ASs in the AS_SET matched = a valid ROA, that might break legitimate uses. >=20 > We need a defined way to deal with AS_SETs that doesn't afford = opportunities for the malicious source while still permitting either the = accidental or the rare intentional use. I agree, and I think that reinforces my earlier statements. One might say that to deal with the vast majority of the cases today,=20 if an AS_SET contains only a single AS, and there's a valid ROA for=20 that origin AS for the prefix in question, it should be considered=20 valid. =20 Additionally (more generically to capture the above as well), if=20 AS_SETs are going to be employed by an AS then all ASes in the set=20 must have a corresponding ROA for the prefix in question, else the route is invalid. Of course, a big disclaimer security consideration statement there as well to outline your example above and state this=20 is a dumb idea in practice; but that's a different issue... -danny =20= From gih@apnic.net Mon Apr 5 14:44:20 2010 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 B7A413A6A8B for ; Mon, 5 Apr 2010 14:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 As9RhJHtMitO for ; Mon, 5 Apr 2010 14:44:19 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 298333A68E9 for ; Mon, 5 Apr 2010 14:44:19 -0700 (PDT) Received: from dhcp70.potaroo.net (dhcp70.potaroo.net [203.10.60.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1BB26D589B; Tue, 6 Apr 2010 07:44:14 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <1EE7DC95-CDDF-4509-9B70-107440BF1DD2@tcb.net> Date: Tue, 6 Apr 2010 07:44:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1D99F46F-8FE2-4DD0-B26A-53B9069B6C35@apnic.net> References: <57DB6CC0-7A4C-4431-9509-94848740EB0A@juniper.net>, <30561767-13B9-4FDA-8A6B-79347E8E174C@apnic.net> <4BB998C2.2040801@ripe.net> <56C7A12A-ECE5-4869-A3AD-76F2EBE65D3E@tcb.net> <1EE7DC95-CDDF-4509-9B70-107440BF1DD2@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1078) Cc: sidr@ietf.org Subject: Re: [sidr] Comment on draft-ietf-sidr-roa-validation-05 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, 05 Apr 2010 21:44:20 -0000 On 06/04/2010, at 4:37 AM, Danny McPherson wrote: >=20 > On Apr 5, 2010, at 12:28 PM, Sandra Murphy wrote: >=20 >> There's also the point to be concerned about, which is defining the = validation of BGP routes to handle an AS_SET origin, to avoid creating a = way for an attacker to counter the validation check. >>=20 >> No matter how few times the feature is used in practice, the feature = exists in BGP and in the implemented code. Not used in practice does = not mean it could not be used in malice. >>=20 >> So, for a wild example, suppose the validation check looked to see if = one single AS in the origin AS_SET matched a valid ROA for the prefix, = and passed the BGP route as valid. That would give a malicious person a = way to ensure that their bogus route would be accepted. If on the other = hand, the validation code looked to see if all ASs in the AS_SET matched = a valid ROA, that might break legitimate uses. >>=20 >> We need a defined way to deal with AS_SETs that doesn't afford = opportunities for the malicious source while still permitting either the = accidental or the rare intentional use. >=20 > I agree, and I think that reinforces my earlier statements. >=20 The circularity of this has not escaped me - I recall about 3 (or was it = 4) years ago arguing for the need for some form of signed credentials = that would support proxy aggregation in BGP as the associated = transformation of a number of discrete originations into a single = origination with an associated AS Set. AS I recall the argument was tied = up with the multiple signature debate, as essentially a proxy = aggregation should reflect in some form or fashion the assent of those = entities whose routes have been aggregated in this fashion At the time = the opposition from working group participants to this concept was small = in number but, from my perspective, typically vehement. I gave up. = Others should not feel in any way constrained by my experiences in = trying to push that particular barrow.=20 Good luck. regards, Geoff From kotikalapudi.sriram@nist.gov Mon Apr 5 21:31:34 2010 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 7C6FA3A685D for ; Mon, 5 Apr 2010 21:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 qYoVmMRa03gD for ; Mon, 5 Apr 2010 21:31:33 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 50C033A67CC for ; Mon, 5 Apr 2010 21:31:33 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o364VMHX031623; Tue, 6 Apr 2010 00:31:22 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 6 Apr 2010 00:31:21 -0400 From: "Sriram, Kotikalapudi" To: Sandra Murphy , Danny McPherson Date: Tue, 6 Apr 2010 00:31:00 -0400 Thread-Topic: Enumerating all scenarios with AS-set (was: RE: [sidr] Comment on draft-ietf-sidr-roa-validation-05) Thread-Index: AQHK1UBz1sbmCatZCk+b5qRv6cS4Sw== 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 06 Apr 2010 04:31:34 -0000 > .... > So, for a wild example, suppose the validation check looked to see if one > single AS in the origin AS_SET matched a valid ROA for the prefix, and > passed the BGP route as valid. That would give a malicious person a way > to ensure that their bogus route would be accepted. If on the other hand= , > the validation code looked to see if all ASs in the AS_SET matched a vali= d > ROA, that might break legitimate uses. > ....=20 > --Sandy Sandy's hypothetical attack example as well John's original message made me= think about=20 enumerating all the use-case scenarios for {Prefix, Origin} validation with= AS-sets. These are the use-case scenarios that I am able enumerate when the origin i= n an update is an=20 AS-set (please let me know if you can think of any other reasonable use cas= e that is not listed below): A1: The AS-set consists of a single unrepeated ASN; No ROA exists with a co= vering prefix. A2: The AS-set consists of a single unrepeated ASN; ROA exists with a cover= ing prefix; AS mismatch. A3: The AS-set consists of a single unrepeated ASN; ROA exists with a cover= ing prefix; AS match. B1: The AS-set contains the same ASN repeated multiple (>1) times and no ot= her ASNs; No ROA exists with a covering prefix. B2: The AS-set contains the same ASN repeated multiple (>1) times and no ot= her ASNs; ROA exists with a covering prefix; AS mismatch. B3: The AS-set contains the same ASN repeated multiple (>1) times and no ot= her ASNs; ROA exists with a covering prefix; AS match. C1: The AS-set contains at least two distinct ASNs; No ROA exists with a co= vering prefix. C2: The AS-set contains at least two distinct ASNs; multiple ROAs exist wit= h a covering prefix; AT LEAST ONE of the ASNs in the AS set DOES NOT MATCH = with any ASN from the collective set of ASNs in said multiple ROAs. C3: The AS-set contains at least two distinct ASNs; multiple ROAs exist wit= h a covering prefix; EVERY ONE of the ASNs in the AS set MATCHES with an AS= N from the collective set of ASNs in said multiple ROAs. There are two essential things that the address-resource owner needs to be = made aware of about validation: 1. In the long run, when deployment is deemed complete, an update with an A= S set will be considered Invalid except in cases A3, B3, and C3. 2. NO concession is made during validation by way of aggregation of more sp= ecific prefixes in ROAs to =93effectively=94 create a ROA for a less specif= ic prefix.=20 Example: Existence of the following four ROAs, namely, ROA-1: {10.1.0.0/18,= AS64496}, ROA-2: {10.1.64.0/18, AS64497}, ROA-3: {10.1.128.0/18, AS64498},= ROA-4: {10.1.192.0/18, AS64499} WILL NOT by itself result in positive vali= dation of an update that has the aggregate prefix 10.1.0.0/16 with the AS s= et {AS64496, AS64497, AS64498, AS64499} as origin. Note: Sandy=92s hypothetical attack scenario is easily mitigated if the out= come of validation in use case C2 is always =93Invalid.=94 The algorithms s= hould be designed to carefully consider all of the nine use-case scenarios = listed above (assuming we are not missing any that are of any consequence). Sriram= From Sandra.Murphy@cobham.com Tue Apr 6 10:49:08 2010 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 B213A3A69FA for ; Tue, 6 Apr 2010 10:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6baMLPKv+jil for ; Tue, 6 Apr 2010 10:49:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 14D5A3A69E0 for ; Tue, 6 Apr 2010 10:48:54 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o36HmpiG009495; Tue, 6 Apr 2010 12:48:51 -0500 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 o36Hmpba015690; Tue, 6 Apr 2010 12:48:51 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 13:48:51 -0400 Date: Tue, 6 Apr 2010 13:48:50 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Sriram, Kotikalapudi" In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="87957877-13577-1270576130=:4124" X-OriginalArrivalTime: 06 Apr 2010 17:48:51.0479 (UTC) FILETIME=[6B035A70:01CAD5B1] Cc: "sidr@ietf.org" Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 06 Apr 2010 17:49:08 -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. --87957877-13577-1270576130=:4124 Content-Type: TEXT/PLAIN; charset=Windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Comments in line. On Tue, 6 Apr 2010, Sriram, Kotikalapudi wrote: >> .... >> So, for a wild example, suppose the validation check looked to see if on= e >> single AS in the origin AS_SET matched a valid ROA for the prefix, and >> passed the BGP route as valid. That would give a malicious person a way >> to ensure that their bogus route would be accepted. If on the other han= d, >> the validation code looked to see if all ASs in the AS_SET matched a val= id >> ROA, that might break legitimate uses. >> .... >> --Sandy > > Sandy's hypothetical attack example as well John's original message made = me think about > enumerating all the use-case scenarios for {Prefix, Origin} validation wi= th AS-sets. > > > There are two essential things that the address-resource owner needs to b= e made aware of about validation: > 1. In the long run, when deployment is deemed complete, an update with an= AS set will be considered Invalid except in cases A3, B3, and C3. > 2. NO concession is made during validation by way of aggregation of more = specific prefixes in ROAs to =93effectively=94 create a ROA for a less spec= ific prefix. > Example: Existence of the following four ROAs, namely, ROA-1: {10.1.0.0/1= 8, AS64496}, ROA-2: {10.1.64.0/18, AS64497}, ROA-3: {10.1.128.0/18, AS64498= }, ROA-4: {10.1.192.0/18, AS64499} WILL NOT by itself result in positive va= lidation of an update that has the aggregate prefix 10.1.0.0/16 with the AS= set {AS64496, AS64497, AS64498, AS64499} as origin. You seem to be presuming specific validation outcomes here. I'm not=20 saying you are wrong, but I'm not certain the use cases document should be= =20 saying ANYTHING about the validation algorithm. I also don't know if we have a consensus of the security concerns with=20 AS_SETS to be making presumptions about the validation outcomes. It=20 appears that John, for one, does not care for the roa-validation draft's=20 suggested outcome. As wg chair, I'd appreciate some more discussion on what to do with=20 AS_SETS. Jump in any time folks. As I tried to say yesterday, the object= =20 here is to avoid leaving a hole in the spec implementers would have to=20 imaginatively fill, creating inter-op problems and maybe a vulnerability. About point 2: There is this thing called "proxy aggregation" where an=20 ISP discovers two external peer BGP routes that are aggregatable and=20 announces the aggregate. Long long ago, IIRC, we decided that proxy=20 aggregation was too hard and too rare and we would declare it out of=20 scope. Your point 2 would specifically disallow proxy aggregation. Not=20 saying that's a bad thing, for a feature that was declared out of scope.=20 Just warning about the side effect. --Sandy > > Note: Sandy=92s hypothetical attack scenario is easily mitigated if the o= utcome of validation in use case C2 is always =93Invalid.=94 The algorithms= should be designed to carefully consider all of the nine use-case scenario= s listed above (assuming we are not missing any that are of any consequence= ). > > Sriram --87957877-13577-1270576130=:4124-- From Sandra.Murphy@cobham.com Tue Apr 6 12:34:54 2010 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 846443A67DA for ; Tue, 6 Apr 2010 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 RL0f1+XMH5lU for ; Tue, 6 Apr 2010 12:34:53 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 565B23A659A for ; Tue, 6 Apr 2010 12:34:53 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o36JYoca011554; Tue, 6 Apr 2010 14:34:50 -0500 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 o36JYnTf021301; Tue, 6 Apr 2010 14:34:49 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Apr 2010 15:34:48 -0400 Date: Tue, 6 Apr 2010 15:34:48 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Sriram, Kotikalapudi" In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 06 Apr 2010 19:34:48.0941 (UTC) FILETIME=[385B11D0:01CAD5C0] Cc: "sidr@ietf.org" Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 06 Apr 2010 19:34:54 -0000 On Tue, 6 Apr 2010, Sriram, Kotikalapudi wrote: > Responses inline. > >> -----Original Message----- >> From: Sandra Murphy [mailto:sandra.murphy@sparta.com] >> Sent: Tuesday, April 06, 2010 1:49 PM >> >> Comments in line. >> >> On Tue, 6 Apr 2010, Sriram, Kotikalapudi wrote: >> >>>> .... >> About point 2: There is this thing called "proxy aggregation" where an >> ISP discovers two external peer BGP routes that are aggregatable and >> announces the aggregate. Long long ago, IIRC, we decided that proxy >> aggregation was too hard and too rare and we would declare it out of >> scope. Your point 2 would specifically disallow proxy aggregation. Not >> saying that's a bad thing, for a feature that was declared out of scope. >> Just warning about the side effect. > > My point 2 was not to say that proxy aggregation would be disallowed. > In that example, if the prefix owner of 10.1.0.0/16 wants the proxy aggregation to pass the ROA validation, then they should be aware enough to create four ROAs > for the _aggregate_ prefix (/16) as follows: > ROA-5: {10.1.0.0/16, maxlength =18, AS64496}, > ROA-6: {10.1.0.0/16, maxlength =18, AS64497}, > ROA-7: {10.1.0.0/16, maxlength =18, AS64498}, > ROA-8: {10.1.0.0/16, maxlength =18, AS64499}. > That is, they should not merely create ROAs for the more specifics > as stated in my point 2 above, and hope that the router > algorithm will magically combine the ROAs for the more specifics > and hence figure it out that the proxy aggregation is OK. > No ... they should know that will not work. > The way to make it work is to create ROAs for the aggregate > as illustrated in ROA-5 through ROA-8 above. > With this set of ROAs for the aggregate, the four > ASs listed above can still originate the more specifics (/18s), > and when an upstream ISP's AS does proxy aggregation, then > that proxy aggregation will pass ROA validation. > That is what I think we want to happen. > It is just a matter of cautioning the user and their ISP about what specific > ROAs they should create if they wish to do proxy aggregation. As I understand proxy aggregation, an ISP receives updates from two peers and discovers that the NLRI in the two updates coincidentally aggregate and the ISP wants to announce the aggregate. (If I'm wrong, I should be corrected - I'm thinking of description in rfc2519 and Geoff's example in http://www.potaroo.net/ispcol/2006-05/bgp.html.) So neither origin AS has authority over the aggregate prefix. So neither origin AS would be able to issue a ROA for the proxy aggregated prefix. --Sandy P.S. I found the long ago discussion on the pre-wg sidr list starting with: http://www.ietf.org/mail-archive/web/sidr/current/msg00025.html > > Sriram > From kotikalapudi.sriram@nist.gov Tue Apr 6 13:43:19 2010 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 AABAE3A6963 for ; Tue, 6 Apr 2010 13:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 t5a2ZgtRsVCY for ; Tue, 6 Apr 2010 13:43:17 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id BB2353A67EF for ; Tue, 6 Apr 2010 13:41:23 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o36KfDeh023696 for ; Tue, 6 Apr 2010 16:41:13 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 6 Apr 2010 14:39:44 -0400 From: "Sriram, Kotikalapudi" To: Sandra Murphy Date: Tue, 6 Apr 2010 14:39:43 -0400 Thread-Topic: Enumerating all scenarios with AS-set (was: RE: [sidr] Comment on draft-ietf-sidr-roa-validation-05) Thread-Index: AcrVsXTbf1t8ruEqTBOVNnf/Pu5gsgAAKd+Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 06 Apr 2010 20:43:19 -0000 Responses inline. > -----Original Message----- > From: Sandra Murphy [mailto:sandra.murphy@sparta.com] > Sent: Tuesday, April 06, 2010 1:49 PM > > Comments in line. >=20 > On Tue, 6 Apr 2010, Sriram, Kotikalapudi wrote: >=20 > >> .... > >> So, for a wild example, suppose the validation check looked to see if = one > >> single AS in the origin AS_SET matched a valid ROA for the prefix, and > >> passed the BGP route as valid. That would give a malicious person a w= ay > >> to ensure that their bogus route would be accepted. If on the other h= and, > >> the validation code looked to see if all ASs in the AS_SET matched a v= alid > >> ROA, that might break legitimate uses. > >> .... > >> --Sandy > > > > Sandy's hypothetical attack example as well John's original message mad= e me think about > > enumerating all the use-case scenarios for {Prefix, Origin} validation = with AS-sets. > > > > > There are two essential things that the address-resource owner needs to= be made aware of > about validation: > > 1. In the long run, when deployment is deemed complete, an update with = an AS set will > be considered Invalid except in cases A3, B3, and C3. > > 2. NO concession is made during validation by way of aggregation of mor= e specific > prefixes in ROAs to "effectively" create a ROA for a less specific prefix= . > > Example: Existence of the following four ROAs, namely, ROA-1: {10.1.0.0= /18, > AS64496}, ROA-2: {10.1.64.0/18, AS64497}, ROA-3: {10.1.128.0/18, AS64498}= , ROA-4: > {10.1.192.0/18, AS64499} WILL NOT by itself result in positive validation= of an update > that has the aggregate prefix 10.1.0.0/16 with the AS set {AS64496, AS644= 97, AS64498, > AS64499} as origin. >=20 > You seem to be presuming specific validation outcomes here. I'm not > saying you are wrong, but I'm not certain the use cases document should b= e > saying ANYTHING about the validation algorithm. You are right. ONLY the use cases will be recorded in the use case document= . Nothing needs to be said there about the algorithm or validation outcomes. I mentioned some example validation decisions (which I think are inline with the current approach in the ROA validation documents) only to help further this email discussion.=20 =20 >=20 > I also don't know if we have a consensus of the security concerns with > AS_SETS to be making presumptions about the validation outcomes. It > appears that John, for one, does not care for the roa-validation draft's > suggested outcome. >=20 > As wg chair, I'd appreciate some more discussion on what to do with > AS_SETS. Jump in any time folks. As I tried to say yesterday, the objec= t > here is to avoid leaving a hole in the spec implementers would have to > imaginatively fill, creating inter-op problems and maybe a vulnerability. >=20 > About point 2: There is this thing called "proxy aggregation" where an > ISP discovers two external peer BGP routes that are aggregatable and > announces the aggregate. Long long ago, IIRC, we decided that proxy > aggregation was too hard and too rare and we would declare it out of > scope. Your point 2 would specifically disallow proxy aggregation. Not > saying that's a bad thing, for a feature that was declared out of scope. > Just warning about the side effect. My point 2 was not to say that proxy aggregation would be disallowed. In that example, if the prefix owner of 10.1.0.0/16 wants the proxy aggrega= tion to pass the ROA validation, then they should be aware enough to create= four ROAs for the _aggregate_ prefix (/16) as follows: ROA-5: {10.1.0.0/16, maxlength =3D18, AS64496}, ROA-6: {10.1.0.0/16, maxlength =3D18, AS64497},=20 ROA-7: {10.1.0.0/16, maxlength =3D18, AS64498},=20 ROA-8: {10.1.0.0/16, maxlength =3D18, AS64499}. That is, they should not merely create ROAs for the more specifics as stated in my point 2 above, and hope that the router algorithm will magically combine the ROAs for the more specifics and hence figure it out that the proxy aggregation is OK. No ... they should know that will not work.=20 The way to make it work is to create ROAs for the aggregate as illustrated in ROA-5 through ROA-8 above. With this set of ROAs for the aggregate, the four ASs listed above can still originate the more specifics (/18s), and when an upstream ISP's AS does proxy aggregation, then that proxy aggregation will pass ROA validation. That is what I think we want to happen. It is just a matter of cautioning the user and their ISP about what specifi= c=20 ROAs they should create if they wish to do proxy aggregation. Sriram From kotikalapudi.sriram@nist.gov Tue Apr 6 14:53:33 2010 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 152133A69A4 for ; Tue, 6 Apr 2010 14:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-1.133, 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 5huv0+qBbQTD for ; Tue, 6 Apr 2010 14:53:32 -0700 (PDT) Received: from wsxghub1.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by core3.amsl.com (Postfix) with ESMTP id EFFD53A699A for ; Tue, 6 Apr 2010 14:53:31 -0700 (PDT) Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 6 Apr 2010 17:53:07 -0400 From: "Sriram, Kotikalapudi" To: Sandra Murphy Date: Tue, 6 Apr 2010 17:53:07 -0400 Thread-Topic: Enumerating all scenarios with AS-set (was: RE: [sidr] Comment on draft-ietf-sidr-roa-validation-05) Thread-Index: AcrVwEd2gbfiGBM2RwC6+1kuVwpI7QADm2A4 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 06 Apr 2010 21:53:33 -0000 > ________________________________________ > From: Sandra Murphy [sandra.murphy@sparta.com] > Sent: Tuesday, April 06, 2010 3:34 PM > .... snip .... > As I understand proxy aggregation, an ISP receives updates from two peers > and discovers that the NLRI in the two updates coincidentally aggregate > and the ISP wants to announce the aggregate. (If I'm wrong, I should be > corrected - I'm thinking of description in rfc2519 and Geoff's example > in http://www.potaroo.net/ispcol/2006-05/bgp.html.) > > So neither origin AS has authority over the aggregate prefix. So neither > origin AS would be able to issue a ROA for the proxy aggregated prefix. > --Sandy You are right. What you describe may indeed be more often the case with pro= xy aggregation. I was considering the other (may be less common) case when the deaggregate = blocks are all owned by one common entity, and originated by different ASs which are also owned = by that entity. In the case which you described (possibly the more common case), I agree it= is not possible=20 to have multiple ROAs for the aggregate. I would lean towards having such proxy aggregated updates receive a "Not kn= own" validation assertion during partial deployment period (if no conflicting RO= A is found), and disallow them (i.e., Invalid) when deployment is considered to be compl= ete. =20 Sriram=20 > > P.S. I found the long ago discussion on the pre-wg sidr list starting wi= th: > http://www.ietf.org/mail-archive/web/sidr/current/msg00025.html From Sandra.Murphy@cobham.com Wed Apr 7 13:13:31 2010 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 5275A28C10B for ; Wed, 7 Apr 2010 13:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 twu4CAFL7Xn2 for ; Wed, 7 Apr 2010 13:13:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0A63A3A6888 for ; Wed, 7 Apr 2010 13:13:24 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o37KDLlq027280; Wed, 7 Apr 2010 15:13:21 -0500 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 o37KDL6E004274; Wed, 7 Apr 2010 15:13:21 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.119]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 16:13:20 -0400 Date: Wed, 7 Apr 2010 16:13:20 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Sriram, Kotikalapudi" In-Reply-To: Message-ID: References: , X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Apr 2010 20:13:20.0805 (UTC) FILETIME=[C4BF4550:01CAD68E] Cc: "sidr@ietf.org" Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 07 Apr 2010 20:13:31 -0000 On Tue, 6 Apr 2010, Sriram, Kotikalapudi wrote: > >> ________________________________________ >> From: Sandra Murphy [sandra.murphy@sparta.com] >> Sent: Tuesday, April 06, 2010 3:34 PM >> .... snip .... >> As I understand proxy aggregation, an ISP receives updates from two peers >> and discovers that the NLRI in the two updates coincidentally aggregate >> and the ISP wants to announce the aggregate. (If I'm wrong, I should be >> corrected - I'm thinking of description in rfc2519 and Geoff's example >> in http://www.potaroo.net/ispcol/2006-05/bgp.html.) >> >> So neither origin AS has authority over the aggregate prefix. So neither >> origin AS would be able to issue a ROA for the proxy aggregated prefix. >> --Sandy > > You are right. What you describe may indeed be more often the case with proxy aggregation. > I was considering the other (may be less common) case when the deaggregate blocks are all owned > by one common entity, and originated by different ASs which are also owned by that entity. > In the case which you described (possibly the more common case), I agree it is not possible > to have multiple ROAs for the aggregate. If I'm understanding, you are suggesting that the common entity (say AS900) holds an aggregate block as well as holding two other ASNs (AS901 and AS902), that AS901 and AS902 are each originating a distinct more specific of the aggregate block and AS900 wants to propagate the aggregate route as an aggregation of the two more specific routes, rather than just originate a route to the aggregate block on its own. That seems odd to me, but I've learned not to bet against the existence of odd routing policies. I'd be curious to hear if this is a recognized corner case. Your suggestion is that AS900 could sign a ROA allowing AS901 and AS902 to originate the aggregate, if I understand. That is not what is really happening here; but the artificial construct would allow the aggregated route to validate. > I would lean towards having such proxy aggregated updates receive a "Not > known" validation assertion during partial deployment period (if no > conflicting ROA is found), and disallow them (i.e., Invalid) when > deployment is considered to be complete. By "such proxy aggregated updates" do you mean subcases like what you have just described? Or do you mean cases of proxy aggregation in general? Are you suggesting a change to the roa-validation draft's handling of AS_SETS originations? Are you suggesting that the roa-validation draft should discuss different validity outcomes in different deployment periods? --Sandy > > Sriram > >> >> P.S. I found the long ago discussion on the pre-wg sidr list starting with: >> http://www.ietf.org/mail-archive/web/sidr/current/msg00025.html > > > From gih@apnic.net Wed Apr 7 16:07:33 2010 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 75A103A68E9 for ; Wed, 7 Apr 2010 16:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.215 X-Spam-Level: X-Spam-Status: No, score=-0.215 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_40=-0.185] 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 7GWPDHwv25nu for ; Wed, 7 Apr 2010 16:07:32 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 4DCC43A67D7 for ; Wed, 7 Apr 2010 16:07:32 -0700 (PDT) Received: from dhcp70.potaroo.net (dhcp70.potaroo.net [203.10.60.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8EDBFD589B for ; Thu, 8 Apr 2010 09:07:26 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) From: Geoff Huston In-Reply-To: Date: Thu, 8 Apr 2010 09:07:20 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: , To: sidr@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 07 Apr 2010 23:07:33 -0000 [I was under the impression that the working practice of this WG is for = the co-chairs to either explicitly state their particular role and = interests in making each and every posting, or, if any such explicit = disclaimers are missing, then its reasonable for the WG participants to = assume that the Co-Chairs' postings are related specifically to matters = that fall within the purview of the functions of a WG chair. To what = extent this current thread of enumeration of proxy aggregation use cases = relates to the procedures of the WG or a consensus call is not clear to = me, so I am a bit puzzled as to why one WG co-chair appears to be so = engaged in this thread in what I can only assume is a WG Chair role.] To quote RFC 4271: When a BGP speaker aggregates several routes for the purpose of advertisement to a particular peer, the AS_PATH of the aggregated route normally includes an AS_SET formed from the set of ASes from which the aggregate was formed. I use the term "proxy aggregation" to describe this action - others may = have different terms to describe this practice.=20 The efforts to conflate security credentials associated with origination = and proxy aggregation have been less than successful, and as John = Scudder pointed out its probably a far more direct path to look at = origination and proxy aggregation as distinct. So, in that vein, I'm = still comfortable in using the text I proposed earlier in response to = John's original observation, namely: "A route's "origin AS" is the final element of the route object's AS_PATH attribute. If the final AS_PATH element is an AS Set, indicating that the route is an aggregate, then the origin AS cannot be determined." This wording, in effect, leaves the entire issue of proxy aggregation = and the associated security credentials that would allow relying parties = to be assured of the integrity of the proxy aggregation action to be = validated by some to-be-determined mechanism that is not necessarily a = ROA. In thinking more about the original suggestion of John's it strikes = me that an effort to shoehorn the specification of security credentials = relating to proxy aggregation into the current constraints of a ROA is = not going to be a productive one. Geoff From gih@apnic.net Wed Apr 7 17:19:24 2010 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 0B9B43A681C for ; Wed, 7 Apr 2010 17:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drWt1V+HWaa8 for ; Wed, 7 Apr 2010 17:19:17 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id DA2D43A67E1 for ; Wed, 7 Apr 2010 17:19:15 -0700 (PDT) Received: from sep0016464ba587.canberra.aarnet.edu.au (aarnet-edm.canberra.aarnet.edu.au [202.158.221.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 12B61D589B; Thu, 8 Apr 2010 10:19:10 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 10:19:04 +1000 Message-Id: To: sidr-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: sidr@ietf.org Subject: [sidr] SIDR WG Charter question on Security requirements for Proxy Aggregation 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, 08 Apr 2010 00:19:24 -0000 >=20 > This wording, in effect, leaves the entire issue of proxy aggregation = and the associated security credentials that would allow relying parties = to be assured of the integrity of the proxy aggregation action to be = validated by some to-be-determined mechanism that is not necessarily a = ROA.=20 I suppose that this observation raises a WG charter question that should = be explicitly addressed to the WG Chairs and potentially the Routing = ADs: Given that AS Path is still not within SIDR's charter (due to an = on-going lack of clear requirements from the RPSEC WG), what is the = status of Proxy Aggregation with respect to the SIDR WG Charter? I = personally suspect that it too is outside of the current SIDR charter, = as the security requirements for proxy aggregation are not overly clear. = Here's what I could find from the last iteration of RPSEC's musings on = this topic: "Aggregation and de-aggregation: According to RFC4271 [RFC4271], if a BGP speaker chooses to aggregate a set of more specific prefixes into a less specific prefix then the ATOMIC_AGGREGATE attribute SHOULD be set. This creates a significant challenge for solutions to secure BGP because some origination information is removed (i.e. the more-specific information which triggered the generation of the aggregate). Proposed solutions MUST indicate how aggregation will be accommodated." It seems to me that the essential requirements for securing proxy = aggregation are missing at this stage, which makes it somewhat difficult = for SIDR to work on mechanisms without some re-spinning of the SIDR WG = Charter (or some other WG) that would permit the preliminary work on = security requirements relating to proxy aggregation to come first. So my question to the WG Co-chairs is: is work on securing Proxy = Aggregation within the current SIDR charter? If so, on what basis? thanks, Geoff= From kotikalapudi.sriram@nist.gov Mon Apr 12 10:25:32 2010 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 BE76F28C17A for ; Mon, 12 Apr 2010 10:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_50=0.001, 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 i5niacJOGEVi for ; Mon, 12 Apr 2010 10:25:30 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id E8B6228C106 for ; Mon, 12 Apr 2010 10:23:20 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o3CHN122009540; Mon, 12 Apr 2010 13:23:01 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 12 Apr 2010 13:22:38 -0400 From: "Sriram, Kotikalapudi" To: Sandra Murphy Date: Mon, 12 Apr 2010 13:23:00 -0400 Thread-Topic: Enumerating all scenarios with AS-set (was: RE: [sidr] Comment on draft-ietf-sidr-roa-validation-05) Thread-Index: AcrWjtCW6DrDgYuxSnqOxZ/GQshnhwDzMmrg Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 12 Apr 2010 17:25:32 -0000 Sandy: My responses in line below. I was traveling last week and had limited access to my NIST email. Hence the delay in responding.=20 Sriram > -----Original Message----- > From: Sandra Murphy [mailto:sandra.murphy@sparta.com] > Sent: Wednesday, April 07, 2010 4:13 PM >=20 > On Tue, 6 Apr 2010, Sriram, Kotikalapudi wrote: >=20 > > > >> ________________________________________ > >> From: Sandra Murphy [sandra.murphy@sparta.com] > >> Sent: Tuesday, April 06, 2010 3:34 PM > >> .... snip .... > >> As I understand proxy aggregation, an ISP receives updates from two pe= ers > >> and discovers that the NLRI in the two updates coincidentally aggregat= e > >> and the ISP wants to announce the aggregate. (If I'm wrong, I should = be > >> corrected - I'm thinking of description in rfc2519 and Geoff's example > >> in http://www.potaroo.net/ispcol/2006-05/bgp.html.) > >> > >> So neither origin AS has authority over the aggregate prefix. So neit= her > >> origin AS would be able to issue a ROA for the proxy aggregated prefix= . > >> --Sandy > > > > You are right. What you describe may indeed be more often the case with= proxy > aggregation. > > I was considering the other (may be less common) case when the deaggreg= ate blocks are > all owned > > by one common entity, and originated by different ASs which are also ow= ned by that > entity. > > In the case which you described (possibly the more common case), I agre= e it is not > possible > > to have multiple ROAs for the aggregate. >=20 > If I'm understanding, you are suggesting that the common entity (say > AS900) holds an aggregate block as well as holding two other ASNs (AS901 > and AS902), that AS901 and AS902 are each originating a distinct more > specific of the aggregate block and AS900 wants to propagate the aggregat= e > route as an aggregation of the two more specific routes, rather than just > originate a route to the aggregate block on its own. >=20 > That seems odd to me, but I've learned not to bet against the existence o= f > odd routing policies. I'd be curious to hear if this is a recognized > corner case. >=20 > Your suggestion is that AS900 could sign a ROA allowing AS901 and AS902 t= o > originate the aggregate, if I understand. That is not what is really > happening here; but the artificial construct would allow the aggregated > route to validate. >=20 > > I would lean towards having such proxy aggregated updates receive a "No= t > > known" validation assertion during partial deployment period (if no > > conflicting ROA is found), and disallow them (i.e., Invalid) when > > deployment is considered to be complete. >=20 > By "such proxy aggregated updates" do you mean subcases like what you hav= e > just described? Or do you mean cases of proxy aggregation in general? I meant the general case as you stated previously, "As I understand proxy aggregation, an ISP receives updates from two peers and discovers that the NLRI in the two updates coincidentally aggregate and the ISP wants to announce the aggregate." =20 >=20 > Are you suggesting a change to the roa-validation draft's handling of > AS_SETS originations? Yes, what I had in mind was that if the 9 use cases (w.r.t. AS_SETs) that I outlined in my email (link below) were duly considered, then the treatment of AS_SETs would be possibly much more adequate. Not calling for any fundamental change in the _principles_ behind the validation methodology; I was merely suggesting enumeration and consideration of more (hopefully an exhaustive set of) use case scenarios for updates involving AS_SETs. With this approach, the adversary cannot exploit or misuse AS_SET to gain advantage. And also, any updates with with a single ASN (put in once or repeated multiple times) in an AS_SET=20 are duly treated, and can be declared "Valid" if there exists a=20 ROA for the prefix with that ASN. The email where I described the 9 use cases with AS_SETs is at: http://www.ietf.org/mail-archive/web/sidr/current/msg01524.html Probably no one is proposing changing the ROA structure --=20 nevertheless, I also think that changing the ROA structure to allow inclusion of an AS_SET as origin is not worth the effort given that there is an extremely small number of proxy originations observed per Danny's email: http://www.ietf.org/mail-archive/web/sidr/current/msg01519.html >=20 > Are you suggesting that the roa-validation draft should discuss different > validity outcomes in different deployment periods? I think this is not an issue really. I was merely thinking that what is con= sidered "Unknown" (i.e., when ROA is not found) during "partial" deployment would c= hange to "Invalid" if and when deployment is considered or declared COMPLETE(!) some= day.=20 But now I think that it does not matter if the algorithm never makes that t= ransition.=20 I think there is no harm in continuing on with the decision outcome=20 "Unknown" when covering ROA is not found even far out into the future.=20 (Here I am speaking in the context of what is already described in the two ROA validation algorithm documents.) Sriram >=20 > --Sandy >=20 > > From kotikalapudi.sriram@nist.gov Mon Apr 12 15:40:19 2010 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 34F1B3A684D for ; Mon, 12 Apr 2010 15:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-1.749, BAYES_20=-0.74] 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 ymzVguXK37Us for ; Mon, 12 Apr 2010 15:40:18 -0700 (PDT) Received: from wsxghub1.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by core3.amsl.com (Postfix) with ESMTP id 0576A3A6452 for ; Mon, 12 Apr 2010 15:40:17 -0700 (PDT) Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 12 Apr 2010 18:39:48 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston , "sidr@ietf.org" Date: Mon, 12 Apr 2010 18:40:11 -0400 Thread-Topic: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) Thread-Index: AcrWpyToTt9LFghETE+yu8NV+zyTXAD1hx6g Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 12 Apr 2010 22:40:19 -0000 Comments inline. Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of G= eoff Huston > Sent: Wednesday, April 07, 2010 7:07 PM > To: sidr@ietf.org > Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comme= nt on draft-ietf- > sidr-roa-validation-05) > > --- snip --- > > The efforts to conflate security credentials associated with origination = and proxy > aggregation have been less than successful, and as John Scudder pointed o= ut its probably a > far more direct path to look at origination and proxy aggregation as dist= inct. So, in that vein, > I'm still comfortable in using the text I proposed earlier in response to= John's original > observation, namely: >=20 > "A route's "origin AS" is the final element of the route object's > AS_PATH attribute. If the final AS_PATH element is an AS Set, > indicating that the route is an aggregate, then the origin AS > cannot be determined." This approach (i.e., "the origin AS cannot be determined" interpretation st= ated above) is vulnerable to attacks if the validation decision that goes with it is "U= nknown". (That would be the case if you give the user the benefit of the doubt.)=20 The adversary can insert his false origin as an AS_SET (artificially) and thus attempt to get away with it. But this type of attack can be prevented as explained below. Why not look inside the AS_SET and attempt to validate the update?=20 If there is a single ASN in the AS_SET -- occurring just once or repeated multiple times -- that is a straight forwar= d case to try=20 to test for validation. Danny's data shows 51 of 61 updates with AS_SETs ar= e like that. http://www.ietf.org/mail-archive/web/sidr/current/msg01515.html=20 If there are two or more distinct ASNs in the AS_SET and there is no coveri= ng ROA, then we go with "Unknown" as validation decision.=20 If there are two or more distinct ASNs in the AS_SET and there is a coverin= g ROA and the ASN in the ROA does not match any ASN in the AS_SET, then clearly we go with "Invalid" as validation decision. I enumerated other cases (9 cases in all) in my earlier email: http://www.ietf.org/mail-archive/web/sidr/current/msg01524.html I tried not to assign validation outcomes there -- I think one can determin= e those=20 rationally following the principles of your current validation algorithm. This approach (such as the one I proposed above) prevents an adversary=20 from taking advantage of AS_SET to try get past the validator.=20 And in most cases involving AS_SETs (referring again to Danny's data), we would be able to decisively evaluate the update as "Valid" or "Invalid"= =20 when a covering ROA exists for the prefix. Not much shoehorning is involved as I see it (unless I am missing something). =20 Sriram >=20 > This wording, in effect, leaves the entire issue of proxy aggregation and= the associated > security credentials that would allow relying parties to be assured of th= e integrity of the > proxy aggregation action to be validated by some to-be-determined mechani= sm that is not > necessarily a ROA. In thinking more about the original suggestion of John= 's it strikes me > that an effort to shoehorn the specification of security credentials rela= ting to proxy > aggregation into the current constraints of a ROA is not going to be a pr= oductive one. >=20 > Geoff >=20 From gih@apnic.net Mon Apr 12 16:24:41 2010 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 EBF2228C0DE for ; Mon, 12 Apr 2010 16:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=1.184, 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 FFfgRloyUeIv for ; Mon, 12 Apr 2010 16:24:39 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 75DAF3A6A5D for ; Mon, 12 Apr 2010 16:24:39 -0700 (PDT) Received: from dhcp70.potaroo.net (dhcp70.potaroo.net [203.10.60.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A8EEDD58AC; Tue, 13 Apr 2010 09:24:30 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Tue, 13 Apr 2010 09:24:25 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2D7DAA47-7F61-43AD-9003-BC157EC384F1@apnic.net> References: , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1078) Cc: "sidr@ietf.org" Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 12 Apr 2010 23:24:41 -0000 Hi, Personally I I am very unsure of the wisdom of attempting to use a = origination authority to infer validation of a proxy aggregation action, = regardless of what lies inside the AS Set. It makes more sense to me to = consider the requirements for validation of proxy aggregation as an = initial step rather than this attempt to retrofit an existing mechanism = that has different semantics to the problem. However, as I noted last = week, I really am unsure whether this WG is chartered to look at = requirements, and hence my question (still unanswered!) to the WG chairs = on the charter. regards, Geoff On 13/04/2010, at 8:40 AM, Sriram, Kotikalapudi wrote: > Comments inline. >=20 > Sriram >=20 >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of Geoff Huston >> Sent: Wednesday, April 07, 2010 7:07 PM >> To: sidr@ietf.org >> Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: = Comment on draft-ietf- >> sidr-roa-validation-05) >>=20 >> --- snip --- >>=20 >> The efforts to conflate security credentials associated with = origination and proxy >> aggregation have been less than successful, and as John Scudder = pointed out its probably a >> far more direct path to look at origination and proxy aggregation as = distinct. So, in that vein, >> I'm still comfortable in using the text I proposed earlier in = response to John's original >> observation, namely: >>=20 >> "A route's "origin AS" is the final element of the route object's >> AS_PATH attribute. If the final AS_PATH element is an AS Set, >> indicating that the route is an aggregate, then the origin AS >> cannot be determined." >=20 > This approach (i.e., "the origin AS cannot be determined" = interpretation stated above) > is vulnerable to attacks if the validation decision that goes with it = is "Unknown". > (That would be the case if you give the user the benefit of the = doubt.)=20 > The adversary can insert his false origin as an AS_SET (artificially) > and thus attempt to get away with it. But this type of attack can > be prevented as explained below. >=20 > Why not look inside the AS_SET and attempt to validate the update?=20 > If there is a single ASN in the AS_SET -- > occurring just once or repeated multiple times -- that is a straight = forward case to try=20 > to test for validation. Danny's data shows 51 of 61 updates with = AS_SETs are like that. > http://www.ietf.org/mail-archive/web/sidr/current/msg01515.html=20 >=20 > If there are two or more distinct ASNs in the AS_SET and there is no = covering ROA, > then we go with "Unknown" as validation decision.=20 > If there are two or more distinct ASNs in the AS_SET and there is a = covering ROA > and the ASN in the ROA does not match any ASN in the AS_SET, then > clearly we go with "Invalid" as validation decision. > I enumerated other cases (9 cases in all) in my earlier email: > http://www.ietf.org/mail-archive/web/sidr/current/msg01524.html > I tried not to assign validation outcomes there -- I think one can = determine those=20 > rationally following the principles of your current validation = algorithm. >=20 > This approach (such as the one I proposed above) prevents an adversary=20= > from taking advantage of AS_SET to try get past the validator.=20 > And in most cases involving AS_SETs (referring again to Danny's data), > we would be able to decisively evaluate the update as "Valid" or = "Invalid"=20 > when a covering ROA exists for the prefix. > Not much shoehorning is involved as I see it > (unless I am missing something). >=20 > Sriram >>=20 >> This wording, in effect, leaves the entire issue of proxy aggregation = and the associated >> security credentials that would allow relying parties to be assured = of the integrity of the >> proxy aggregation action to be validated by some to-be-determined = mechanism that is not >> necessarily a ROA. In thinking more about the original suggestion of = John's it strikes me >> that an effort to shoehorn the specification of security credentials = relating to proxy >> aggregation into the current constraints of a ROA is not going to be = a productive one. >>=20 >> Geoff >>=20 From andrei@ripe.net Tue Apr 13 02:50:28 2010 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 6F2A33A6821 for ; Tue, 13 Apr 2010 02:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 7KitA+FNPErz for ; Tue, 13 Apr 2010 02:50:27 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 539F83A6807 for ; Tue, 13 Apr 2010 02:50:23 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O1cl0-0000OB-28; Tue, 13 Apr 2010 11:50:15 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=Andrei-Robachevskys-MacBook-Air.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O1ckz-0002tC-Ol; Tue, 13 Apr 2010 11:50:09 +0200 Message-ID: <4BC43E51.5090707@ripe.net> Date: Tue, 13 Apr 2010 11:50:09 +0200 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: , In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb1b158b87da990b5b296438c93b6018fe X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb1b158b87da990b5b296438c93b6018fe Cc: "sidr@ietf.org" Subject: Re: [sidr] Enumerating all scenarios with AS-set (was: RE: Comment on draft-ietf-sidr-roa-validation-05) 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, 13 Apr 2010 09:50:28 -0000 Sriram, Kotikalapudi wrote on 13/4/10 12:40 AM: [...] > This approach (such as the one I proposed above) prevents an adversary > from taking advantage of AS_SET to try get past the validator. > And in most cases involving AS_SETs (referring again to Danny's data), > we would be able to decisively evaluate the update as "Valid" or "Invalid" > when a covering ROA exists for the prefix. > Not much shoehorning is involved as I see it > (unless I am missing something). > I agree with Geoff's point that proper handling of cases of proxy aggregation depends on the requirements of as-path validation. But at the current stage of SIDR work, since ROAs do not really protect against anything malicious, I am more in favour of the original validation process as stated in draft-ietf-sidr-roa-validation-05. I think that in reality aggregation is not coincidental and relates to the fact that the aggregator has the rights to use of the address space of the covering prefix, and, therefore, is the only one able to issue the appropriate ROA. Andrei From warren@kumari.net Mon Apr 26 17:52:09 2010 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 3EAC83A68B3 for ; Mon, 26 Apr 2010 17:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Sd6iq2EYI3U for ; Mon, 26 Apr 2010 17:52:08 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 536A43A686E for ; Mon, 26 Apr 2010 17:52:08 -0700 (PDT) Received: from [192.168.0.210] (pool-71-114-43-185.washdc.dsl-w.verizon.net [71.114.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 367122284090; Mon, 26 Apr 2010 20:49:45 -0400 (EDT) Message-Id: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> From: Warren Kumari To: Randy Bush In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Apr 2010 20:51:54 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Chris Morrow , sidr wg Subject: Re: [sidr] draft-ymbk-rpki-rtr-protocol-05.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, 27 Apr 2010 00:52:09 -0000 While going through back mail I noticed this and that there seems to be no followups. I support this as a WG doc. W On Mar 27, 2010, at 12:58 PM, Randy Bush wrote: > we would like to sumbit draft-ymbk-rpki-rtr-protocol-05.txt as a > sidr wg > draft on standards track. it needs to be standards track as it is a > normative reference from draft-pmohapat-sidr-pfx-validate-04.txt. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From sra@hactrn.net Mon Apr 26 19:24:49 2010 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 3CC6F28C1DB for ; Mon, 26 Apr 2010 19:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 dYoRyDTJXo9u for ; Mon, 26 Apr 2010 19:24:48 -0700 (PDT) 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 97AA93A685B for ; Mon, 26 Apr 2010 19:24:47 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id A1EA028468 for ; Tue, 27 Apr 2010 02:24:33 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6098822831 for ; Mon, 26 Apr 2010 22:24:33 -0400 (EDT) Date: Mon, 26 Apr 2010 22:24:33 -0400 From: Rob Austein To: sidr@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100427022433.6098822831@thrintun.hactrn.net> Subject: [sidr] Proposal to remove use of TLS from RPKI provisioning ("up-down") 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: Tue, 27 Apr 2010 02:24:49 -0000 I'm writing to propose that we remove all use and mention of TLS from the RPKI "up-down" protocol described in the (expired) draft draft-ietf-sidr-rescerts-provisioning. Background: In June 2007 we had a team of security reviewers (Steve Bellovin, Steve Kent, and Russ Housley) examine the "up-down" protocol. At that time, they recommended that we run the entire protocol under TLS, so we did. In the three years since then, we've started running a testbed with a few friendly volunteers, trying to get some feel for how well the RPKi protocol (and my implementation of it) works. In practice, getting TLS configuration right has turned out to be enough of a problem that I asked the same team of security reviewers to take another look at the problem. Their conclusion this time was that TLS is not really buying us anything we don't (or can't) get from CMS. Given this, it seems clear (to me, anyway) that using both TLS and CMS is over-engineering for this protocol, and since CMS is both better suited for the way this protocol works and also easier to get configured correctly, I think we should drop TLS. Note that this is less about TLS in the abstract than it is about TLS as used in the up-down protocol. There are protocols for which TLS is an appropriate tool, this protocol just happens not to be one of them. The basic problem is that we're dealing with a message-based client-server protocol that doesn't really have any concept of a session. The full protocol wrapping, for those who might not have it memorized, is TCP(TLS(HTTP(CMS(XML(up-down))))), that is: the protocol itself is expressed in XML, which we then sign with CMS and pass around via HTTPS POST commands and responses. CMS is well-suited for this, both because the message-based nature of the protocol means that an implementation already has the complete message in hand by the time it's trying to verify the CMS signature. We'd need to use CMS (or something enough like it as to make no difference) anyway, because one of the requirements for this protocol is that the messages be auditable at some future time; with CMS this is trivial, assuming we've preserved the necessary certificates, with TLS this can't be done at all once the TLS session has gone away. TLS, unlike CMS, has to be initiated before we ever see the complete message. This leads to all sorts of complications, whether or not one is using the TLS Server Name Indication extension. It is of course possible to overcome all of these complications, but the result, at least in the context of the up-down protocol, is fragile. As far as I have been able to determine, there are no existing large scale deployments of inter-organizational TLS using mandatory client certificates; most use of TLS is either without client certificates or is within a single organization. We're already making all the authorization decisions based on the results of checking the CMS message signatures, and pretty much have to do it that way (decision has to follow the auditable path), so TLS authentication doesn't buy us much either. As discussed at some length on this mailing list and in WG sessions, TLS as we're using it in this protocol does not protect us from replay attacks. We still need some form of replay protection, but I'll talk about that in a separate message; for the moment, suffice it to say that the presence or absence of TLS isn't likely to change the replay protection mechanism. As far as I know, the up-down protocol does not need confidentiality, but if it did, we could get it easily enough by enabling CMS encryption. I am -not- suggesting that we -should- use CMS encryption, I'd rather be able to debug operational problems, but if we need encryption, we can get it from CMS with the same keys and certificates we're already using. Any attacker who can DoS a server by generating a lot of bogus CMS messages can presumably also generate a lot of bogus TLS messages, so the DoS-prevention argument doesn't apply. If we were keeping long-lived TLS sessions around, we might get some benefit from TLS session caching, but we're not. Given that we're using HTTP, where the semantics of persistent connections were designed to avoid connection bursts rather than support sessions in the normal sense, we can't rely on sessions staying up even if we wanted them to do so. So, since TLS is not adding anything critical, and creates some operational issues, I propose that we remove TLS from the protocol. From sra@hactrn.net Mon Apr 26 20:34:36 2010 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 9B9193A6885 for ; Mon, 26 Apr 2010 20:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 LLNOxecJ3sUC for ; Mon, 26 Apr 2010 20:34:35 -0700 (PDT) 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 71A863A6823 for ; Mon, 26 Apr 2010 20:34:35 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id B275E2842B for ; Tue, 27 Apr 2010 03:34:21 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 39A0A22831 for ; Mon, 26 Apr 2010 23:34:21 -0400 (EDT) Date: Mon, 26 Apr 2010 23:34:21 -0400 From: Rob Austein To: sidr@ietf.org 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: <20100427033421.39A0A22831@thrintun.hactrn.net> Subject: [sidr] Replay protection in RPKI provisioning 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: Tue, 27 Apr 2010 03:34:36 -0000 As has been discussed on the mailing list and in several recent WG meetings, even with TLS (which I'm proposing we drop), we do not currently have effective replay protection in the RPKI up-down protocol (expired draft-ietf-sidr-rescerts-provisioning). The solutions for this are relatively straightforward, we just have to update the spec to include them. The first level of replay protection would be just to check the timestamp in the CMS message, and enforce a rule that any new message from a particular peer (protocol, not routing sense of "peer") must have a newer timestamp than any we've seen until now. The CMS profile we're using already includes timestamps, so we get this for free, and we don't need synchronized clocks, we just need to know that the timestamp as viewed by the sending party has increased. This, by itself, should be enough to detect replay attempts. The second level of protection would be if we also need to detect messages being dropped out of the protocol exchange (ie, this one is about selective message blocking, not replay per se). A timestamp won't suffice for this, but a counter will. So if we're concerned about this we should add a serial number to the XML header. Geoff proposed something like this back in 2007, although his proposed mechanism was a bit more complicated than I think we'd really need for this threat. All we'd really need would be an XML attribute containing a simple nonnegative integer serial number: the client would increment this to the next value when sending a new message, the server would just echo back the client's value. I'm reasonably certain that we need the first rule (timestamp check), as there is at least one known attack (replay of an old issuance request) without it. I'm not sure we need the serial number, but Steve Bellovin recommended that we at least think about it. For both of these, there is the little issue of what an implementation is meant to do if the rule is violated. Log something, almost certainly, but should it reject the message? Probably, for timestamp violation, similarly for serial number repeating or going backwards. Not quite so obvious for a gap in the serial number sequence, seems like rejecting the message in this case would invite a cheap denial of service attack, so my inclination would be to raise an alert but allow the message in this case. At minimum, I propose that we add the timestamp check rule. This requires no change to the message format. From gih@apnic.net Mon Apr 26 21:09:39 2010 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 11C3128C204 for ; Mon, 26 Apr 2010 21:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 dVLaXMzRnQsZ for ; Mon, 26 Apr 2010 21:09:37 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 22C4228C20F for ; Mon, 26 Apr 2010 21:07:52 -0700 (PDT) Received: from [10.10.35.10] (62-50-197-59.client.stsn.net [62.50.197.59]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id ECC26D58FA; Tue, 27 Apr 2010 14:07:35 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <20100427033421.39A0A22831@thrintun.hactrn.net> Date: Tue, 27 Apr 2010 14:07:30 +1000 Content-Transfer-Encoding: 7bit Message-Id: <4347BE99-7E18-4D29-B8D7-62D41E0D477D@apnic.net> References: <20100427033421.39A0A22831@thrintun.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1078) Cc: sidr@ietf.org Subject: Re: [sidr] Replay protection in RPKI provisioning 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: Tue, 27 Apr 2010 04:09:40 -0000 Hi Rob, > Geoff > proposed something like this back in 2007, although his proposed > mechanism was a bit more complicated than I think we'd really need for > this threat. I dug out the original exchange from 3 June 2007 and I think you were proposing some complications to the mechanism at the time.... "1) RobK is correct that the msg_ref checking algorithm as now specified is more complicated than it needs to be. This is at least partly my fault, for not having backed us fully out of an interim conversation in which we were thinking about just using CMS timestamps for replay protection and dropping msg_ref entirely." and on the 5th June: "1) On the replay protection thing: Randy and I have been talking to Steve Bellovin, and while we haven't quite converged yet it looks like the simplest answer is to follow RobK's earlier suggestion: just make the msg_ref a monotonically increasing integer, no CMS timestamp required, no reset mechanism required, done, full stop. The likely implementation would be to generate the msg_ref value from a clock on the sender side, eg, nanoseconds since epoch, but it really doesn't matter so long as it's monotonically increasing. The CMS timestamp doesn't isn't fine enough for this, and combining CMS timestamp with an additional value has timing screws, so let's just keep this simple and go with the counter." Steve Bellovin's comments at the time (6th June) were: "The whole point of something that's purely clock-driven is to avoid the need for non-volatile client state. We're talking about secured objects, rather than secured transmission, which means that things like nonces are very much harder to use. (Exception: we probably could use hash chains, though I haven't worked this out in detail. Apart from complexity, see your local IPR lawyer.) "The point where I currently disagree with Rob and Randy is on the granularity of the timer. Whatever granularity is chosen bounds the maximum signing rate. Thus, if you use a 1-second clock, you can't sign more than 1 object/sec. (Well, you can cheat and "borrow" from future seconds, up to the actual clock skew, but that does cut your margin.) If we go with a nanosecond timer, we're limited to 10^9 objects/sec, ever. I'm not convinced we can predict the future well enough to know that that's reasonable, so I've suggested that the spec support fractional seconds -- we can always extend the number of significant digits to the right of the radix point without a protocol change. "That said, I think that a fixed-granularity timer is fine if someone will do the quantitative analysis to show what the bound should be. I don't know the subject area quite well enough to do that, I suspect." I haven't looked further to see where it got to but the high order bits for me from from that exchange appears to be that there is a timer granularity issue that appears to affect the maximum message rate. Geoff From robert@ripe.net Tue Apr 27 00:26:30 2010 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 37B523A6802 for ; Tue, 27 Apr 2010 00:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 n6oLYUIqWaoX for ; Tue, 27 Apr 2010 00:26:29 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 187073A67CF for ; Tue, 27 Apr 2010 00:26:29 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1O6fBK-0003y6-0d for sidr@ietf.org; Tue, 27 Apr 2010 09:26:15 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=Kistel-Mac.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1O6fBJ-0005dV-T7 for sidr@ietf.org; Tue, 27 Apr 2010 09:26:09 +0200 Message-ID: <4BD69191.1070108@ripe.net> Date: Tue, 27 Apr 2010 09:26:09 +0200 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sidr@ietf.org References: <20100427033421.39A0A22831@thrintun.hactrn.net> <4347BE99-7E18-4D29-B8D7-62D41E0D477D@apnic.net> In-Reply-To: <4347BE99-7E18-4D29-B8D7-62D41E0D477D@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2742298fe0f8201fc2cda189f4fa4ecd5d9 X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2742298fe0f8201fc2cda189f4fa4ecd5d9 Subject: Re: [sidr] Replay protection in RPKI provisioning 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: Tue, 27 Apr 2010 07:26:30 -0000 > "The point where I currently disagree with Rob and Randy is on the > granularity of the timer. Whatever granularity is chosen bounds the > maximum signing rate. Thus, if you use a 1-second clock, you can't > sign more than 1 object/sec. (Well, you can cheat and "borrow" from > future seconds, up to the actual clock skew, but that does cut your > margin.) If we go with a nanosecond timer, we're limited to 10^9 > objects/sec, ever. I'm not convinced we can predict the future well > enough to know that that's reasonable, so I've suggested that the spec > support fractional seconds -- we can always extend the number of > significant digits to the right of the radix point without a protocol > change. I could live with a 10^9 message/sec limitation (it's not a system global, but per client/server relation)... If that's not enough, the . tuple solves all issues, I think. Robert(K) From warren@kumari.net Tue Apr 27 10:15:49 2010 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 77E553A6B66 for ; Tue, 27 Apr 2010 10:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 nRXxCgSPVZFE for ; Tue, 27 Apr 2010 10:15:48 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id CEA283A6B5F for ; Tue, 27 Apr 2010 10:15:39 -0700 (PDT) Received: from dhcp-172-29-46-102.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id AC84E22841BC; Tue, 27 Apr 2010 13:13:15 -0400 (EDT) Message-Id: <431DF314-CE97-47D9-9D59-E6A4B549DB31@kumari.net> From: Warren Kumari To: Rob Austein In-Reply-To: <20100427022433.6098822831@thrintun.hactrn.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Apr 2010 13:15:24 -0400 References: <20100427022433.6098822831@thrintun.hactrn.net> X-Mailer: Apple Mail (2.936) Cc: sidr@ietf.org Subject: Re: [sidr] Proposal to remove use of TLS from RPKI provisioning ("up-down") 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: Tue, 27 Apr 2010 17:15:49 -0000 On Apr 26, 2010, at 10:24 PM, Rob Austein wrote: > I'm writing to propose that we remove all use and mention of TLS from > the RPKI "up-down" protocol described in the (expired) draft > draft-ietf-sidr-rescerts-provisioning. I would like to second this. > > Background: In June 2007 we had a team of security reviewers (Steve > Bellovin, Steve Kent, and Russ Housley) examine the "up-down" > protocol. At that time, they recommended that we run the entire > protocol under TLS, so we did. > > In the three years since then, we've started running a testbed with a > few friendly volunteers, trying to get some feel for how well the RPKi > protocol (and my implementation of it) works. In practice, getting > TLS configuration right has turned out to be enough of a problem As one of the participants in the testbed, I'd like to chime in here -- getting the TLS config correct is really hard, and troubleshooting that various failure modes is seriously non-trivial. > that > I asked the same team of security reviewers to take another look at > the problem. Their conclusion this time was that TLS is not really > buying us anything we don't (or can't) get from CMS. Given this, it > seems clear (to me, anyway) that using both TLS and CMS is > over-engineering for this protocol, and since CMS is both better > suited for the way this protocol works and also easier to get > configured correctly, I think we should drop TLS. > > Note that this is less about TLS in the abstract than it is about TLS > as used in the up-down protocol. There are protocols for which TLS is > an appropriate tool, this protocol just happens not to be one of them. > > The basic problem is that we're dealing with a message-based > client-server protocol that doesn't really have any concept of a > session. The full protocol wrapping, for those who might not have it > memorized, is TCP(TLS(HTTP(CMS(XML(up-down))))), that is: the protocol > itself is expressed in XML, which we then sign with CMS and pass > around via HTTPS POST commands and responses. > > CMS is well-suited for this, both because the message-based nature of > the protocol means that an implementation already has the complete > message in hand by the time it's trying to verify the CMS signature. > We'd need to use CMS (or something enough like it as to make no > difference) anyway, because one of the requirements for this protocol > is that the messages be auditable at some future time; with CMS this > is trivial, assuming we've preserved the necessary certificates, with > TLS this can't be done at all once the TLS session has gone away. > > TLS, unlike CMS, has to be initiated before we ever see the complete > message. This leads to all sorts of complications, whether or not one > is using the TLS Server Name Indication extension. It is of course > possible to overcome all of these complications, but the result, at > least in the context of the up-down protocol, is fragile. As far as I > have been able to determine, there are no existing large scale > deployments of inter-organizational TLS using mandatory client > certificates; most use of TLS is either without client certificates or > is within a single organization. > > We're already making all the authorization decisions based on the > results of checking the CMS message signatures, and pretty much have > to do it that way (decision has to follow the auditable path), so TLS > authentication doesn't buy us much either. > > As discussed at some length on this mailing list and in WG sessions, > TLS as we're using it in this protocol does not protect us from replay > attacks. We still need some form of replay protection, but I'll talk > about that in a separate message; for the moment, suffice it to say > that the presence or absence of TLS isn't likely to change the replay > protection mechanism. > > As far as I know, the up-down protocol does not need confidentiality, > but if it did, we could get it easily enough by enabling CMS > encryption. I am -not- suggesting that we -should- use CMS > encryption, I'd rather be able to debug operational problems, but if > we need encryption, we can get it from CMS with the same keys and > certificates we're already using. > > Any attacker who can DoS a server by generating a lot of bogus CMS > messages can presumably also generate a lot of bogus TLS messages, so > the DoS-prevention argument doesn't apply. If we were keeping > long-lived TLS sessions around, we might get some benefit from TLS > session caching, but we're not. Given that we're using HTTP, where > the semantics of persistent connections were designed to avoid > connection bursts rather than support sessions in the normal sense, we > can't rely on sessions staying up even if we wanted them to do so. > > So, since TLS is not adding anything critical, and creates some > operational issues, I propose that we remove TLS from the protocol. +1. W > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Tue Apr 27 11:26:08 2010 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 CDBCB28C21E for ; Tue, 27 Apr 2010 11:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_50=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 9Ew4ZOm2luAv for ; Tue, 27 Apr 2010 11:26:08 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2015228C249 for ; Tue, 27 Apr 2010 11:24:40 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3RIOR1T003405; Tue, 27 Apr 2010 13:24:27 -0500 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 o3RIOQXM015903; Tue, 27 Apr 2010 13:24:27 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Apr 2010 14:16:30 -0400 Date: Tue, 27 Apr 2010 14:16:30 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Warren Kumari In-Reply-To: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Apr 2010 18:16:30.0789 (UTC) FILETIME=[C2B6B750:01CAE635] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] draft-ymbk-rpki-rtr-protocol-05.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, 27 Apr 2010 18:26:09 -0000 On Mon, 26 Apr 2010, Warren Kumari wrote: > While going through back mail I noticed this and that there seems to be no > followups. That's because there's been no official call for adoption. And that is because the request is motivated by a reference in another document that is not itself a working group document. And because I've heard that there are changes afoot in the other document. It appeared to me therefore that it was premature to announce a call for adoption of this draft. Perhaps I misunderstood. Randy, could you confirm that you would like to see this adopted by the working group without respect to the status of the other document? --Sandy > > I support this as a WG doc. > > W > > On Mar 27, 2010, at 12:58 PM, Randy Bush wrote: > >> we would like to sumbit draft-ymbk-rpki-rtr-protocol-05.txt as a sidr wg >> draft on standards track. it needs to be standards track as it is a >> normative reference from draft-pmohapat-sidr-pfx-validate-04.txt. >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Tue Apr 27 11:58:48 2010 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 6D71D3A6A94 for ; Tue, 27 Apr 2010 11:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.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 q7HCy6D7T3aA for ; Tue, 27 Apr 2010 11:58:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 445C33A6A2D for ; Tue, 27 Apr 2010 11:58:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O6pzF-0003gd-8Z; Tue, 27 Apr 2010 18:58:25 +0000 Date: Tue, 27 Apr 2010 11:58:25 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.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: Chris Morrow , sidr wg Subject: Re: [sidr] draft-ymbk-rpki-rtr-protocol-05.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, 27 Apr 2010 18:58:48 -0000 > Randy, could you confirm that you would like to see this adopted by > the working group without respect to the status of the other document? i confirm that we submitted draft-ymbk-rpki-rtr-protocol as a wg document irrespective of the status of draft-pmohapat-sidr-pfx-validate (which should be out in -07 shortly). i merely meant to note that there was a normative reference to it from draft-pmohapat-sidr-pfx-validate, and hence draft-ymbk-rpki-rtr-protocol was forced to come out of the closet of running code. randy From Sandra.Murphy@cobham.com Tue Apr 27 12:18:44 2010 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 0C0C03A6959 for ; Tue, 27 Apr 2010 12:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, 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 fF+rQw9LZwcc for ; Tue, 27 Apr 2010 12:18:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id AC6B93A6A16 for ; Tue, 27 Apr 2010 12:18:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3RJITam004667; Tue, 27 Apr 2010 14:18:29 -0500 Received: from laconia.cos.ads.sparta.com (cos.sparta.com [157.185.16.10]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3RJIQMt019251; Tue, 27 Apr 2010 14:18:28 -0500 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by laconia.cos.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Apr 2010 13:18:08 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Apr 2010 15:17:13 -0400 Date: Tue, 27 Apr 2010 15:17:12 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Apr 2010 19:17:13.0109 (UTC) FILETIME=[3DB4A450:01CAE63E] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] draft-ymbk-rpki-rtr-protocol-05.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, 27 Apr 2010 19:18:44 -0000 My apologies. I'll get right on this. --Sandy On Tue, 27 Apr 2010, Randy Bush wrote: >> Randy, could you confirm that you would like to see this adopted by >> the working group without respect to the status of the other document? > > i confirm that we submitted draft-ymbk-rpki-rtr-protocol as a wg > document irrespective of the status of draft-pmohapat-sidr-pfx-validate > (which should be out in -07 shortly). > > i merely meant to note that there was a normative reference to it from > draft-pmohapat-sidr-pfx-validate, and hence draft-ymbk-rpki-rtr-protocol > was forced to come out of the closet of running code. > > randy > From kawamucho@mesh.ad.jp Tue Apr 27 20:31:16 2010 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 442F93A6A0F for ; Tue, 27 Apr 2010 20:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.693 X-Spam-Level: * X-Spam-Status: No, score=1.693 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 ghHg4jYcbYT3 for ; Tue, 27 Apr 2010 20:31:15 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by core3.amsl.com (Postfix) with ESMTP id 026FF3A685B for ; Tue, 27 Apr 2010 20:31:14 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o3S3V1Ar015334; Wed, 28 Apr 2010 12:31:01 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o3S3V1H01278; Wed, 28 Apr 2010 12:31:01 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id o3S3V0tp016518; Wed, 28 Apr 2010 12:31:00 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3S3V0gq010834; Wed, 28 Apr 2010 12:31:00 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3S3V07o031571; Wed, 28 Apr 2010 12:31:00 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o3S3V0NF020615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Apr 2010 12:31:00 +0900 Message-ID: <4BD7ABF3.3040203@mesh.ad.jp> Date: Wed, 28 Apr 2010 12:30:59 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Warren Kumari References: <20100427022433.6098822831@thrintun.hactrn.net> <431DF314-CE97-47D9-9D59-E6A4B549DB31@kumari.net> In-Reply-To: <431DF314-CE97-47D9-9D59-E6A4B549DB31@kumari.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Proposal to remove use of TLS from RPKI provisioning ("up-down") 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: Wed, 28 Apr 2010 03:31:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi > As one of the participants in the testbed, I'd like to chime in here > --getting the TLS config correct is really hard, and troubleshooting > that various failure modes is seriously non-trivial. I'll admit that I'm one of the testbed participants that stumbled over this. Regards, Seiichi Warren Kumari wrote: > > On Apr 26, 2010, at 10:24 PM, Rob Austein wrote: > >> I'm writing to propose that we remove all use and mention of TLS from >> the RPKI "up-down" protocol described in the (expired) draft >> draft-ietf-sidr-rescerts-provisioning. > > I would like to second this. > >> >> Background: In June 2007 we had a team of security reviewers (Steve >> Bellovin, Steve Kent, and Russ Housley) examine the "up-down" >> protocol. At that time, they recommended that we run the entire >> protocol under TLS, so we did. >> >> In the three years since then, we've started running a testbed with a >> few friendly volunteers, trying to get some feel for how well the RPKi >> protocol (and my implementation of it) works. In practice, getting >> TLS configuration right has turned out to be enough of a problem > > As one of the participants in the testbed, I'd like to chime in here > --getting the TLS config correct is really hard, and troubleshooting > that various failure modes is seriously non-trivial. > > > >> that >> I asked the same team of security reviewers to take another look at >> the problem. Their conclusion this time was that TLS is not really >> buying us anything we don't (or can't) get from CMS. Given this, it >> seems clear (to me, anyway) that using both TLS and CMS is >> over-engineering for this protocol, and since CMS is both better >> suited for the way this protocol works and also easier to get >> configured correctly, I think we should drop TLS. >> >> Note that this is less about TLS in the abstract than it is about TLS >> as used in the up-down protocol. There are protocols for which TLS is >> an appropriate tool, this protocol just happens not to be one of them. >> >> The basic problem is that we're dealing with a message-based >> client-server protocol that doesn't really have any concept of a >> session. The full protocol wrapping, for those who might not have it >> memorized, is TCP(TLS(HTTP(CMS(XML(up-down))))), that is: the protocol >> itself is expressed in XML, which we then sign with CMS and pass >> around via HTTPS POST commands and responses. >> >> CMS is well-suited for this, both because the message-based nature of >> the protocol means that an implementation already has the complete >> message in hand by the time it's trying to verify the CMS signature. >> We'd need to use CMS (or something enough like it as to make no >> difference) anyway, because one of the requirements for this protocol >> is that the messages be auditable at some future time; with CMS this >> is trivial, assuming we've preserved the necessary certificates, with >> TLS this can't be done at all once the TLS session has gone away. >> >> TLS, unlike CMS, has to be initiated before we ever see the complete >> message. This leads to all sorts of complications, whether or not one >> is using the TLS Server Name Indication extension. It is of course >> possible to overcome all of these complications, but the result, at >> least in the context of the up-down protocol, is fragile. As far as I >> have been able to determine, there are no existing large scale >> deployments of inter-organizational TLS using mandatory client >> certificates; most use of TLS is either without client certificates or >> is within a single organization. >> >> We're already making all the authorization decisions based on the >> results of checking the CMS message signatures, and pretty much have >> to do it that way (decision has to follow the auditable path), so TLS >> authentication doesn't buy us much either. >> >> As discussed at some length on this mailing list and in WG sessions, >> TLS as we're using it in this protocol does not protect us from replay >> attacks. We still need some form of replay protection, but I'll talk >> about that in a separate message; for the moment, suffice it to say >> that the presence or absence of TLS isn't likely to change the replay >> protection mechanism. >> >> As far as I know, the up-down protocol does not need confidentiality, >> but if it did, we could get it easily enough by enabling CMS >> encryption. I am -not- suggesting that we -should- use CMS >> encryption, I'd rather be able to debug operational problems, but if >> we need encryption, we can get it from CMS with the same keys and >> certificates we're already using. >> >> Any attacker who can DoS a server by generating a lot of bogus CMS >> messages can presumably also generate a lot of bogus TLS messages, so >> the DoS-prevention argument doesn't apply. If we were keeping >> long-lived TLS sessions around, we might get some benefit from TLS >> session caching, but we're not. Given that we're using HTTP, where >> the semantics of persistent connections were designed to avoid >> connection bursts rather than support sessions in the normal sense, we >> can't rely on sessions staying up even if we wanted them to do so. >> >> So, since TLS is not adding anything critical, and creates some >> operational issues, I propose that we remove TLS from the protocol. > > +1. > > W > >> _______________________________________________ >> 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkvXq/MACgkQcrhTYfxyMkIQdACghmQ2otCXnNUGhsiqW41I1lt9 qooAnjhtL+RQaQbeGQ4rNN/zxn1+w76h =k5sK -----END PGP SIGNATURE----- From sra@hactrn.net Tue Apr 27 21:17:09 2010 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 46F1F3A6A0F for ; Tue, 27 Apr 2010 21:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Q9xlKJGt-7Oj for ; Tue, 27 Apr 2010 21:17:08 -0700 (PDT) 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 9E3593A6A08 for ; Tue, 27 Apr 2010 21:17:07 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 476702842B for ; Wed, 28 Apr 2010 04:16:53 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EA34922831 for ; Wed, 28 Apr 2010 00:16:52 -0400 (EDT) Date: Wed, 28 Apr 2010 00:16:52 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4347BE99-7E18-4D29-B8D7-62D41E0D477D@apnic.net> References: <20100427033421.39A0A22831@thrintun.hactrn.net> <4347BE99-7E18-4D29-B8D7-62D41E0D477D@apnic.net> 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: <20100428041652.EA34922831@thrintun.hactrn.net> Subject: Re: [sidr] Replay protection in RPKI provisioning 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: Wed, 28 Apr 2010 04:17:09 -0000 Hi, Geoff At Tue, 27 Apr 2010 14:07:30 +1000, Geoff Huston wrote: > > I dug out the original exchange from 3 June 2007 and I think you were > proposing some complications to the mechanism at the time.... No doubt. Thanks for the archives, I had forgotten some of the details, but I still think that we (for some definition of "we") went a bit overboard at the time. You're correct that perfect avoidance of all possible replay would require a counter or clock that increments at least as fast as the signing rate, whatever that might be. On the other hand, for the one attack I know of at the moment (replay of an old issuance request with a compromised key after that key has been revoked), a clock check with one-second granularity is almost certainly good enough: for this attack to work in this case, the revocation request would have to come less than a second after the initial issuance request, which seems unlikely. The nanosecond timer isn't quite the same thing as the sequence number I was talking about yesterday: the sequence number would be intended to catch dropped messages, a timer wouldn't do that. Interesting that Steve Bellovin seems to have been advocating the clock-based approach back when as a way of avoiding state; he was correct about that, of course, but he's also the person who suggested the sequence number this time, so I may need to get him into an argument with himself to find out who wins that one. In any case: I still suspect that the trivial timer check I proposed yesterday would suffice for the one attack we know about today. From terry.manderson@icann.org Tue Apr 27 21:23:11 2010 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 EC91B3A6A97 for ; Tue, 27 Apr 2010 21:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.926 X-Spam-Level: X-Spam-Status: No, score=-4.926 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_20=-0.74, 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 wN41j4vxrQHf for ; Tue, 27 Apr 2010 21:23:09 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id C8D8C3A6885 for ; Tue, 27 Apr 2010 21:23:09 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 27 Apr 2010 21:22:58 -0700 From: Terry Manderson To: Rob Austein , "sidr@ietf.org" Date: Tue, 27 Apr 2010 21:22:56 -0700 Thread-Topic: [sidr] Proposal to remove use of TLS from RPKI provisioning ("up-down") protocol Thread-Index: AcrlsNZ24sy0LoVNToKYD5SiNH293QA2aOGR Message-ID: In-Reply-To: <20100427022433.6098822831@thrintun.hactrn.net> 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] Proposal to remove use of TLS from RPKI provisioning ("up-down") 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: Wed, 28 Apr 2010 04:23:11 -0000 On 27/04/10 12:24 PM, "Rob Austein" wrote: > I'm writing to propose that we remove all use and mention of TLS from > the RPKI "up-down" protocol described in the (expired) draft > draft-ietf-sidr-rescerts-provisioning. >=20 I second this given my observations from October last year (http://www.ietf.org/mail-archive/web/sidr/current/msg01256.html) and your operational trials. However I'm not sure it should be dropped without providing (noting your second email) a mechanism to mitigate replay and reorder attacks. Provided that your timer approach deals with any known attacks and this is adopted a= s a defined rule for acceptance of the request I'll happily acquiesce. Cheers Terry From gih@apnic.net Tue Apr 27 22:05:46 2010 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 B822A3A6767 for ; Tue, 27 Apr 2010 22:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, 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 aHRiip0ZUQA5 for ; Tue, 27 Apr 2010 22:05:45 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 994EC3A6AE3 for ; Tue, 27 Apr 2010 22:05:16 -0700 (PDT) Received: from [10.10.35.213] (62-50-196-155.client.stsn.net [62.50.196.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id AA192D58AC; Wed, 28 Apr 2010 15:04:49 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 28 Apr 2010 15:04:44 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1078) Cc: Chris Morrow , sidr wg Subject: [sidr] SIDR Charter Question 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, 28 Apr 2010 05:05:46 -0000 three weeks ago I asked: >=20 > It seems to me that the essential requirements for securing proxy = aggregation are missing at this stage, which makes it somewhat difficult = for SIDR to work on mechanisms without some re-spinning of the SIDR WG = Charter (or some other WG) that would permit the preliminary work on = security requirements relating to proxy aggregation to come first. >=20 > So my question to the WG Co-chairs is: is work on securing Proxy = Aggregation within the current SIDR charter? If so, on what basis? I would hope that by now the WGchairs have had sufficient time to = consider this question, so I'd like to ask once more: Is work on = securing Proxy Aggregation within the current SIDR Charter? If so, on = what basis? regards, =20 Geoff From housley@vigilsec.com Wed Apr 28 00:57:02 2010 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 AF98D3A6855 for ; Wed, 28 Apr 2010 00:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=0.373, 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 vJPyh0gAdGIG for ; Wed, 28 Apr 2010 00:57:02 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id E9F053A6B1C for ; Wed, 28 Apr 2010 00:57:01 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id CC6C49A474E for ; Wed, 28 Apr 2010 03:56:59 -0400 (EDT) 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 pZK5lX+QPv54 for ; Wed, 28 Apr 2010 03:56:48 -0400 (EDT) Received: from [10.10.50.157] (cust.static.213-180-180-201.cybernet.ch [213.180.180.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 048089A4743 for ; Wed, 28 Apr 2010 03:56:58 -0400 (EDT) Message-ID: <4BD7EA43.6000204@vigilsec.com> Date: Wed, 28 Apr 2010 03:56:51 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sidr@ietf.org References: <20100427022433.6098822831@thrintun.hactrn.net> In-Reply-To: <20100427022433.6098822831@thrintun.hactrn.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Proposal to remove use of TLS from RPKI provisioning ("up-down") 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: Wed, 28 Apr 2010 07:57:02 -0000 > So, since TLS is not adding anything critical, and creates some > operational issues, I propose that we remove TLS from the protocol. This seems quite reasonable to me. Russ From Sandra.Murphy@cobham.com Wed Apr 28 10:33:55 2010 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 52A2D3A6827 for ; Wed, 28 Apr 2010 10:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_50=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 GzXW6sDmfEYl for ; Wed, 28 Apr 2010 10:33:54 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 6B5A93A69C3 for ; Wed, 28 Apr 2010 10:33:54 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3SHXaba017324; Wed, 28 Apr 2010 12:33:37 -0500 Received: from laconia.cos.ads.sparta.com (cos.sparta.com [157.185.16.10]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3SHXYKa027247; Wed, 28 Apr 2010 12:33:35 -0500 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by laconia.cos.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 11:33:17 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 13:16:14 -0400 Date: Wed, 28 Apr 2010 13:16:14 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Apr 2010 17:16:14.0724 (UTC) FILETIME=[81C8BC40:01CAE6F6] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 17:33:55 -0000 I have said that it was the consensus even before sidr was officially a wg that proxy aggregation would not be part of our work. And I pointed to the email archive for that discussion. You have said that you do not believe that it is possible at this point, so I don't think that you are unhappy with that statement. So I am confused as to what further statement I could make that would help at this point. Can you point me to where you still see a problem? --Sandy On Wed, 28 Apr 2010, Geoff Huston wrote: > three weeks ago I asked: > >> >> It seems to me that the essential requirements for securing proxy aggregation are missing at this stage, which makes it somewhat difficult for SIDR to work on mechanisms without some re-spinning of the SIDR WG Charter (or some other WG) that would permit the preliminary work on security requirements relating to proxy aggregation to come first. >> >> So my question to the WG Co-chairs is: is work on securing Proxy Aggregation within the current SIDR charter? If so, on what basis? > > I would hope that by now the WGchairs have had sufficient time to consider this question, so I'd like to ask once more: Is work on securing Proxy Aggregation within the current SIDR Charter? If so, on what basis? > > > regards, > > Geoff > > From gih@apnic.net Wed Apr 28 11:11:40 2010 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 E3CE03A688E for ; Wed, 28 Apr 2010 11:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 O9hdRe3YjFwo for ; Wed, 28 Apr 2010 11:11:39 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 4D3713A69D0 for ; Wed, 28 Apr 2010 11:11:36 -0700 (PDT) Received: from [10.31.8.43] (89.Red-217-127-196.staticIP.rima-tde.net [217.127.196.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8A2BFD58C8; Thu, 29 Apr 2010 04:11:18 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 29 Apr 2010 04:11:13 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1078) Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 18:11:41 -0000 Thank you for this response. As I had noted earlier, if you had made it = clearer in which role you were posting in these discussions it would be = easier for others, or at least myself, to understand when you were = making pronouncements as WG chair and when you were asking questions and = airing opinions as an individual participant.=20 If proxy aggregation is "not part of our work" then the outcome of such = actions, namely AS Sets in the AS_PATH is likewise "not part of our = work." I will edit the roa validation draft accordingly. On 29/04/2010, at 3:16 AM, Sandra Murphy wrote: > I have said that it was the consensus even before sidr was officially = a wg that proxy aggregation would not be part of our work. And I = pointed to the email archive for that discussion. >=20 > You have said that you do not believe that it is possible at this = point, so I don't think that you are unhappy with that statement. >=20 > So I am confused as to what further statement I could make that would = help at this point. >=20 > Can you point me to where you still see a problem? >=20 > --Sandy >=20 > On Wed, 28 Apr 2010, Geoff Huston wrote: >=20 >> three weeks ago I asked: >>=20 >>>=20 >>> It seems to me that the essential requirements for securing proxy = aggregation are missing at this stage, which makes it somewhat difficult = for SIDR to work on mechanisms without some re-spinning of the SIDR WG = Charter (or some other WG) that would permit the preliminary work on = security requirements relating to proxy aggregation to come first. >>>=20 >>> So my question to the WG Co-chairs is: is work on securing Proxy = Aggregation within the current SIDR charter? If so, on what basis? >>=20 >> I would hope that by now the WGchairs have had sufficient time to = consider this question, so I'd like to ask once more: Is work on = securing Proxy Aggregation within the current SIDR Charter? If so, on = what basis? >>=20 >>=20 >> regards, >>=20 >> Geoff >>=20 >>=20 From morrowc@ops-netman.net Wed Apr 28 11:33:33 2010 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 A66263A69E8 for ; Wed, 28 Apr 2010 11:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.612 X-Spam-Level: X-Spam-Status: No, score=0.612 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 eWit1InWwN1B for ; Wed, 28 Apr 2010 11:33:33 -0700 (PDT) Received: from neo-u2.ops-netman.net (neo-u2.OPS-NETMAN.NET [71.246.230.124]) by core3.amsl.com (Postfix) with ESMTP id 47B6728C0FE for ; Wed, 28 Apr 2010 11:33:32 -0700 (PDT) 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 EBC08358704; Wed, 28 Apr 2010 18:33:16 +0000 (UTC) Message-ID: <4BD87F6B.3080108@ops-netman.net> Date: Wed, 28 Apr 2010 14:33:15 -0400 From: Chris Morrow User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Geoff Huston References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> In-Reply-To: <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 18:33:33 -0000 Geoff Huston wrote: > three weeks ago I asked: > >> It seems to me that the essential requirements for securing proxy >> aggregation are missing at this stage, which makes it somewhat >> difficult for SIDR to work on mechanisms without some re-spinning >> of the SIDR WG Charter (or some other WG) that would permit the >> preliminary work on security requirements relating to proxy >> aggregation to come first. >> >> So my question to the WG Co-chairs is: is work on securing Proxy >> Aggregation within the current SIDR charter? If so, on what basis? > > I would hope that by now the WGchairs have had sufficient time to > consider this question, so I'd like to ask once more: Is work on > securing Proxy Aggregation within the current SIDR Charter? If so, > on what basis? (Apologies, this got lost (the original question) in other issues.) Sandy did respond (phew!) but as a person in the group: My (personal) feeling is that looking at the use of Proxy Aggregation in the DFZ today shows a very small number of routes (less than 1% by danny@tcb.net's measurements) and almost all of these looked like misconfig/mistake issues. I think trying to decide how to authenticate proxy-aggregated routes is a more difficult task than we should try to tackle. Is this route signed by the original as-owner or the aggregator as an origin signing, or some set? how do you determine what set? ugh... If at all possible we should avoid this, it will open up issues and add complication for something that is not in common/proper use today. -chris From Sandra.Murphy@cobham.com Wed Apr 28 11:38:41 2010 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 AA1943A6C0C for ; Wed, 28 Apr 2010 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_50=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 VJ-a9erskbcS for ; Wed, 28 Apr 2010 11:38:39 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id ADE053A695F for ; Wed, 28 Apr 2010 11:38:39 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3SIcOAR018357; Wed, 28 Apr 2010 13:38:24 -0500 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 o3SIcIZX030376; Wed, 28 Apr 2010 13:38:21 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 14:37:32 -0400 Date: Wed, 28 Apr 2010 14:37:32 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Apr 2010 18:37:32.0521 (UTC) FILETIME=[DD2D7D90:01CAE701] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 18:38:41 -0000 On Thu, 29 Apr 2010, Geoff Huston wrote: > Thank you for this response. As I had noted earlier, if you had made it clearer in which role you were posting in these discussions it would be easier for others, or at least myself, to understand when you were making pronouncements as WG chair and when you were asking questions and airing opinions as an individual participant. > > If proxy aggregation is "not part of our work" then the outcome of such actions, namely AS Sets in the AS_PATH is likewise "not part of our work." I will edit the roa validation draft accordingly. Actually, no, that is not the case. When I say that proxy aggregation is not part of our work, I mean that sidr does not promise to protect BGP announcements formed by proxy aggregation. While it is true that AS_SETS are principally generated in BGP updates by an AS that is doing proxy aggregation, AS_SETS are still part of the BGP protocol and might appear in a received AS_PATH. Until and unless the idr working group decides to eliminate that feature from the BGP protocol, the sidr route validation must still make a statement about what happens when the AS_PATH origin is an AS_SET. That is necessary for completeness. Furthermore, without such a statement, implementers could make different decisions as to how to handle such cases and attack paths could result. The sidr wg is not now considering anything but origin authorization, so an AS_PATH segment that is an AS_SET but is not the origin is not of our concern at all. --Sandy > > > On 29/04/2010, at 3:16 AM, Sandra Murphy wrote: > >> I have said that it was the consensus even before sidr was officially a wg that proxy aggregation would not be part of our work. And I pointed to the email archive for that discussion. >> >> You have said that you do not believe that it is possible at this point, so I don't think that you are unhappy with that statement. >> >> So I am confused as to what further statement I could make that would help at this point. >> >> Can you point me to where you still see a problem? >> >> --Sandy >> >> On Wed, 28 Apr 2010, Geoff Huston wrote: >> >>> three weeks ago I asked: >>> >>>> >>>> It seems to me that the essential requirements for securing proxy aggregation are missing at this stage, which makes it somewhat difficult for SIDR to work on mechanisms without some re-spinning of the SIDR WG Charter (or some other WG) that would permit the preliminary work on security requirements relating to proxy aggregation to come first. >>>> >>>> So my question to the WG Co-chairs is: is work on securing Proxy Aggregation within the current SIDR charter? If so, on what basis? >>> >>> I would hope that by now the WGchairs have had sufficient time to consider this question, so I'd like to ask once more: Is work on securing Proxy Aggregation within the current SIDR Charter? If so, on what basis? >>> >>> >>> regards, >>> >>> Geoff >>> >>> > > From Sandra.Murphy@cobham.com Wed Apr 28 11:50:58 2010 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 E3A363A6840 for ; Wed, 28 Apr 2010 11:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_40=-0.185] 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 j2VjiKe75t63 for ; Wed, 28 Apr 2010 11:50:58 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DA7253A6B97 for ; Wed, 28 Apr 2010 11:50:56 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3SIogbt018552; Wed, 28 Apr 2010 13:50:42 -0500 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 o3SIoepI030840; Wed, 28 Apr 2010 13:50:41 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 14:46:43 -0400 Date: Wed, 28 Apr 2010 14:46:43 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Apr 2010 18:46:43.0587 (UTC) FILETIME=[25A37D30:01CAE703] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 18:50:59 -0000 On Wed, 28 Apr 2010, Sandra Murphy wrote: > > > On Thu, 29 Apr 2010, Geoff Huston wrote: > >> Thank you for this response. As I had noted earlier, if you had made it >> clearer in which role you were posting in these discussions it would be >> easier for others, or at least myself, to understand when you were making >> pronouncements as WG chair and when you were asking questions and airing >> opinions as an individual participant. >> >> If proxy aggregation is "not part of our work" then the outcome of such >> actions, namely AS Sets in the AS_PATH is likewise "not part of our work." >> I will edit the roa validation draft accordingly. > > Actually, no, that is not the case. > > When I say that proxy aggregation is not part of our work, I mean that sidr > does not promise to protect BGP announcements formed by proxy aggregation. > > While it is true that AS_SETS are principally generated in BGP updates by an > AS that is doing proxy aggregation, AS_SETS are still part of the BGP > protocol and might appear in a received AS_PATH. > > Until and unless the idr working group decides to eliminate that feature from > the BGP protocol, the sidr route validation must still make a statement about > what happens when the AS_PATH origin is an AS_SET. > > That is necessary for completeness. Furthermore, without such a statement, > implementers could make different decisions as to how to handle such cases > and attack paths could result. > > The sidr wg is not now considering anything but origin authorization, so an > AS_PATH segment that is an AS_SET but is not the origin is not of our concern > at all. > > > --Sandy Whoops! I meant: --Sandy, still conversing as wg chair > > > >> >> >> On 29/04/2010, at 3:16 AM, Sandra Murphy wrote: >> >>> I have said that it was the consensus even before sidr was officially a wg >>> that proxy aggregation would not be part of our work. And I pointed to >>> the email archive for that discussion. >>> >>> You have said that you do not believe that it is possible at this point, >>> so I don't think that you are unhappy with that statement. >>> >>> So I am confused as to what further statement I could make that would help >>> at this point. >>> >>> Can you point me to where you still see a problem? >>> >>> --Sandy >>> >>> On Wed, 28 Apr 2010, Geoff Huston wrote: >>> >>>> three weeks ago I asked: >>>> >>>>> >>>>> It seems to me that the essential requirements for securing proxy >>>>> aggregation are missing at this stage, which makes it somewhat difficult >>>>> for SIDR to work on mechanisms without some re-spinning of the SIDR WG >>>>> Charter (or some other WG) that would permit the preliminary work on >>>>> security requirements relating to proxy aggregation to come first. >>>>> >>>>> So my question to the WG Co-chairs is: is work on securing Proxy >>>>> Aggregation within the current SIDR charter? If so, on what basis? >>>> >>>> I would hope that by now the WGchairs have had sufficient time to >>>> consider this question, so I'd like to ask once more: Is work on securing >>>> Proxy Aggregation within the current SIDR Charter? If so, on what basis? >>>> >>>> >>>> regards, >>>> >>>> Geoff >>>> >>>> >> >> > From warren@kumari.net Wed Apr 28 11:59:11 2010 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 C73763A67DB for ; Wed, 28 Apr 2010 11:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.648 X-Spam-Level: * X-Spam-Status: No, score=1.648 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_50=0.001, FB_WORD2_END_DOLLAR=3.294] 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 uoHgMlH+c8pa for ; Wed, 28 Apr 2010 11:59:10 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id BFFDE3A67B6 for ; Wed, 28 Apr 2010 11:59:10 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 9054D228464C; Wed, 28 Apr 2010 14:56:42 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 5EFEC2284090; Wed, 28 Apr 2010 14:56:41 -0400 (EDT) Message-Id: <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> From: Warren Kumari To: Sandra Murphy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Apr 2010 14:58:53 -0400 References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> X-Mailer: Apple Mail (2.936) Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 18:59:11 -0000 On Apr 28, 2010, at 2:37 PM, Sandra Murphy wrote: > > > On Thu, 29 Apr 2010, Geoff Huston wrote: > >> Thank you for this response. As I had noted earlier, if you had >> made it clearer in which role you were posting in these discussions >> it would be easier for others, or at least myself, to understand >> when you were making pronouncements as WG chair and when you were >> asking questions and airing opinions as an individual participant. >> >> If proxy aggregation is "not part of our work" then the outcome of >> such actions, namely AS Sets in the AS_PATH is likewise "not part >> of our work." I will edit the roa validation draft accordingly. > > Actually, no, that is not the case. > > When I say that proxy aggregation is not part of our work, I mean > that sidr does not promise to protect BGP announcements formed by > proxy aggregation. > > While it is true that AS_SETS are principally generated in BGP > updates by an AS that is doing proxy aggregation, AS_SETS are still > part of the BGP protocol and might appear in a received AS_PATH. > > Until and unless the idr working group decides to eliminate that > feature from the BGP protocol, the sidr route validation must still > make a statement about what happens when the AS_PATH origin is an > AS_SET. > > That is necessary for completeness. Furthermore, without such a > statement, implementers could make different decisions as to how to > handle such cases and attack paths could result. > > The sidr wg is not now considering anything but origin > authorization, so an AS_PATH segment that is an AS_SET but is not > the origin is not of our concern at all. Just for giggles I decided to see how how widely AS Sets were being used by having a quick look at route views data (yes, which I realize is incomplete, etc). I used an as-path regexp to only get AS paths that included an AS_SET and then did some grep, sed and awk hackery to get a handle on the data. I see zero AS_PATHs where the AS_SET is not the origin (i.e, where the AS_SET segment is not followed by i (internal), e (external) or ? (unknown): wkumari@colon:~/tmp$ cat assets | grep '} [^ie\?]' I see 39 unique paths where the "AS_SET" is only a single AS: wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/ \1/' | sort | uniq | grep -v ',' | wc -l 39 and 21 unique paths where the AS_SET contains multiple ASs: wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/ \1/' | sort | uniq | grep ',' 11060,12262 1239,17079,27773 17746,64512 209,25729 21135,49476 25019,41426 25912,65427 31812,65473 33363,65129,65188 3356,8928,22351 3491,15412,19710 35821,35821,35821,35821 45514,45514,45514 45514,45514,45514,65081 4558,30994,33770 46124,46136 50693,64601,64604,64607,64608,64609,64610,65505 64520,64521 7470,24128,38865,45199 8002,15412 8508,24748,35434 Of these, only: 11060,12262 1239,17079,27773 209,25729 21135,49476 25019,41426 3356,8928,22351 3491,15412,19710 35821,35821,35821,35821 45514,45514,45514 4558,30994,33770 46124,46136 7470,24128,38865,45199 8002,15412 8508,24748,35434 do not contain private AS numbers. Some of the above contain only a single AS repeated multiple times (like 35821). I don't want this to devolve into a discussion on the merits of aggregation, if AS_SETs should be deprecated or anything similar, this was just because I wanted know for my own sake what the numbers were and figured others might be interested too.... W > > > > --Sandy > > > >> >> >> On 29/04/2010, at 3:16 AM, Sandra Murphy wrote: >> >>> I have said that it was the consensus even before sidr was >>> officially a wg that proxy aggregation would not be part of our >>> work. And I pointed to the email archive for that discussion. >>> >>> You have said that you do not believe that it is possible at this >>> point, so I don't think that you are unhappy with that statement. >>> >>> So I am confused as to what further statement I could make that >>> would help at this point. >>> >>> Can you point me to where you still see a problem? >>> >>> --Sandy >>> >>> On Wed, 28 Apr 2010, Geoff Huston wrote: >>> >>>> three weeks ago I asked: >>>> >>>>> >>>>> It seems to me that the essential requirements for securing >>>>> proxy aggregation are missing at this stage, which makes it >>>>> somewhat difficult for SIDR to work on mechanisms without some >>>>> re-spinning of the SIDR WG Charter (or some other WG) that would >>>>> permit the preliminary work on security requirements relating to >>>>> proxy aggregation to come first. >>>>> >>>>> So my question to the WG Co-chairs is: is work on securing >>>>> Proxy Aggregation within the current SIDR charter? If so, on >>>>> what basis? >>>> >>>> I would hope that by now the WGchairs have had sufficient time to >>>> consider this question, so I'd like to ask once more: Is work on >>>> securing Proxy Aggregation within the current SIDR Charter? If >>>> so, on what basis? >>>> >>>> >>>> regards, >>>> >>>> Geoff >>>> >>>> >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Eagles soar but a weasel will never get sucked into a jet engine From gih@apnic.net Wed Apr 28 12:02:11 2010 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 3612C3A68C7 for ; Wed, 28 Apr 2010 12:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 D5dYV-oLEJaL for ; Wed, 28 Apr 2010 12:02:10 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 7D6DC3A6A70 for ; Wed, 28 Apr 2010 12:02:07 -0700 (PDT) Received: from [10.31.8.43] (89.Red-217-127-196.staticIP.rima-tde.net [217.127.196.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0AD57D58C8; Thu, 29 Apr 2010 05:01:40 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 29 Apr 2010 05:01:36 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <56825053-0433-4035-A85F-83651B8DC17D@apnic.net> References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1078) Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 19:02:11 -0000 On 29/04/2010, at 4:46 AM, Sandra Murphy wrote: >=20 >=20 > On Wed, 28 Apr 2010, Sandra Murphy wrote: >=20 >>=20 >>=20 >> On Thu, 29 Apr 2010, Geoff Huston wrote: >>=20 >>> Thank you for this response. As I had noted earlier, if you had made = it clearer in which role you were posting in these discussions it would = be easier for others, or at least myself, to understand when you were = making pronouncements as WG chair and when you were asking questions and = airing opinions as an individual participant. >>> If proxy aggregation is "not part of our work" then the outcome of = such actions, namely AS Sets in the AS_PATH is likewise "not part of our = work." I will edit the roa validation draft accordingly. >>=20 >> Actually, no, that is not the case. >>=20 >> When I say that proxy aggregation is not part of our work, I mean = that sidr does not promise to protect BGP announcements formed by proxy = aggregation. >>=20 >> While it is true that AS_SETS are principally generated in BGP = updates by an AS that is doing proxy aggregation, AS_SETS are still part = of the BGP protocol and might appear in a received AS_PATH. >>=20 >> Until and unless the idr working group decides to eliminate that = feature from the BGP protocol, the sidr route validation must still make = a statement about what happens when the AS_PATH origin is an AS_SET. >>=20 >> That is necessary for completeness. Furthermore, without such a = statement, implementers could make different decisions as to how to = handle such cases and attack paths could result. >>=20 >> The sidr wg is not now considering anything but origin authorization, = so an AS_PATH segment that is an AS_SET but is not the origin is not of = our concern at all. >>=20 >>=20 >> --Sandy >=20 >=20 > Whoops! >=20 > I meant: >=20 > --Sandy, still conversing as wg chair >=20 thank you. So I'm confused with this additional statement of yours in the role of = WG chair. To explain my confusion, when I grep AS_SET in RFC4271 I see it = exclusively described with reference to aggregation - for example: = "AS_SETs are used in the route aggregation algorithm described in = Section 9.2.2.2"=20 So __with particular reference to the definition of an originating AS__ = (which is where this particular particular strand started), where and = why do AS_SETs have any relevance to the WG consideration of Origination = Authorization? i.e. to phrase it in a more practical manner, what = precisely is the problem with applying the edit proposed by John Scudder = to the roa validation draft?=20 Again, I'm asking the WG chairs here for further clarification because = the above exchange has managed to confused me. Geoff From Sandra.Murphy@cobham.com Wed Apr 28 12:12:23 2010 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 6E84B3A6A4B for ; Wed, 28 Apr 2010 12:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.064 X-Spam-Level: * X-Spam-Status: No, score=1.064 tagged_above=-999 required=5 tests=[AWL=-2.231, BAYES_50=0.001, FB_WORD2_END_DOLLAR=3.294] 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 L20u5mN0sEof for ; Wed, 28 Apr 2010 12:12:21 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B79BD3A698D for ; Wed, 28 Apr 2010 12:12:20 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3SJC50j018936; Wed, 28 Apr 2010 14:12:05 -0500 Received: from laconia.cos.ads.sparta.com (cos.sparta.com [157.185.16.10]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o3SJC5og032087; Wed, 28 Apr 2010 14:12:05 -0500 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by laconia.cos.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 13:11:42 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 15:10:49 -0400 Date: Wed, 28 Apr 2010 15:10:49 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Warren Kumari In-Reply-To: <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Apr 2010 19:10:49.0315 (UTC) FILETIME=[835C1330:01CAE706] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 19:12:23 -0000 The relative frequency of use of AS_SETs is interesting, but not really germane to the point here. If we were trying to develop a protection for AS_SETs then we might want to ask the engineering question of where and how often they were used. But for the purpose of validating received updates, we need a rule for what is done with AS_SETs that appear in the AS_PATH origin. Lack of rules leaves opportunities for deliberate or accidental mischief. AS_SETs might not be used very often, but that doesn't stop someone from using AS_SETs deliberately with malicious intent. --Sandy, making a technical point as wg member and a document completeness point as wg chair. On Wed, 28 Apr 2010, Warren Kumari wrote: > > On Apr 28, 2010, at 2:37 PM, Sandra Murphy wrote: > >> >> >> On Thu, 29 Apr 2010, Geoff Huston wrote: >> >>> Thank you for this response. As I had noted earlier, if you had made it >>> clearer in which role you were posting in these discussions it would be >>> easier for others, or at least myself, to understand when you were making >>> pronouncements as WG chair and when you were asking questions and airing >>> opinions as an individual participant. >>> >>> If proxy aggregation is "not part of our work" then the outcome of such >>> actions, namely AS Sets in the AS_PATH is likewise "not part of our work." >>> I will edit the roa validation draft accordingly. >> >> Actually, no, that is not the case. >> >> When I say that proxy aggregation is not part of our work, I mean that sidr >> does not promise to protect BGP announcements formed by proxy aggregation. >> >> While it is true that AS_SETS are principally generated in BGP updates by >> an AS that is doing proxy aggregation, AS_SETS are still part of the BGP >> protocol and might appear in a received AS_PATH. >> >> Until and unless the idr working group decides to eliminate that feature >> from the BGP protocol, the sidr route validation must still make a >> statement about what happens when the AS_PATH origin is an AS_SET. >> >> That is necessary for completeness. Furthermore, without such a statement, >> implementers could make different decisions as to how to handle such cases >> and attack paths could result. >> >> The sidr wg is not now considering anything but origin authorization, so an >> AS_PATH segment that is an AS_SET but is not the origin is not of our >> concern at all. > > Just for giggles I decided to see how how widely AS Sets were being used by > having a quick look at route views data (yes, which I realize is incomplete, > etc). > > I used an as-path regexp to only get AS paths that included an AS_SET and > then did some grep, sed and awk hackery to get a handle on the data. > > > I see zero AS_PATHs where the AS_SET is not the origin (i.e, where the AS_SET > segment is not followed by i (internal), e (external) or ? (unknown): > > wkumari@colon:~/tmp$ cat assets | grep '} [^ie\?]' > > I see 39 unique paths where the "AS_SET" is only a single AS: > wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/\1/' | > sort | uniq | grep -v ',' | wc -l > 39 > > and 21 unique paths where the AS_SET contains multiple ASs: > wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed 's/.*{\(.*\)}.*/\1/' | > sort | uniq | grep ',' > 11060,12262 > 1239,17079,27773 > 17746,64512 > 209,25729 > 21135,49476 > 25019,41426 > 25912,65427 > 31812,65473 > 33363,65129,65188 > 3356,8928,22351 > 3491,15412,19710 > 35821,35821,35821,35821 > 45514,45514,45514 > 45514,45514,45514,65081 > 4558,30994,33770 > 46124,46136 > 50693,64601,64604,64607,64608,64609,64610,65505 > 64520,64521 > 7470,24128,38865,45199 > 8002,15412 > 8508,24748,35434 > > Of these, only: > 11060,12262 > 1239,17079,27773 > 209,25729 > 21135,49476 > 25019,41426 > 3356,8928,22351 > 3491,15412,19710 > 35821,35821,35821,35821 > 45514,45514,45514 > 4558,30994,33770 > 46124,46136 > 7470,24128,38865,45199 > 8002,15412 > 8508,24748,35434 > > do not contain private AS numbers. Some of the above contain only a single AS > repeated multiple times (like 35821). > > I don't want this to devolve into a discussion on the merits of aggregation, > if AS_SETs should be deprecated or anything similar, this was just because I > wanted know for my own sake what the numbers were and figured others might be > interested too.... > > W > > > >> >> >> >> --Sandy >> >> >> >>> >>> >>> On 29/04/2010, at 3:16 AM, Sandra Murphy wrote: >>> >>>> I have said that it was the consensus even before sidr was officially a >>>> wg that proxy aggregation would not be part of our work. And I pointed >>>> to the email archive for that discussion. >>>> >>>> You have said that you do not believe that it is possible at this point, >>>> so I don't think that you are unhappy with that statement. >>>> >>>> So I am confused as to what further statement I could make that would >>>> help at this point. >>>> >>>> Can you point me to where you still see a problem? >>>> >>>> --Sandy >>>> >>>> On Wed, 28 Apr 2010, Geoff Huston wrote: >>>> >>>>> three weeks ago I asked: >>>>> >>>>>> >>>>>> It seems to me that the essential requirements for securing proxy >>>>>> aggregation are missing at this stage, which makes it somewhat >>>>>> difficult for SIDR to work on mechanisms without some re-spinning of >>>>>> the SIDR WG Charter (or some other WG) that would permit the >>>>>> preliminary work on security requirements relating to proxy aggregation >>>>>> to come first. >>>>>> >>>>>> So my question to the WG Co-chairs is: is work on securing Proxy >>>>>> Aggregation within the current SIDR charter? If so, on what basis? >>>>> >>>>> I would hope that by now the WGchairs have had sufficient time to >>>>> consider this question, so I'd like to ask once more: Is work on >>>>> securing Proxy Aggregation within the current SIDR Charter? If so, on >>>>> what basis? >>>>> >>>>> >>>>> regards, >>>>> >>>>> Geoff >>>>> >>>>> >>> >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > -- > Eagles soar but a weasel will never get sucked into a jet engine > > From morrowc@ops-netman.net Wed Apr 28 12:25:10 2010 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 784533A69BB for ; Wed, 28 Apr 2010 12:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.259 X-Spam-Level: ** X-Spam-Status: No, score=2.259 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_50=0.001, FB_WORD2_END_DOLLAR=3.294, 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 KRmgdqCw+mQM for ; Wed, 28 Apr 2010 12:25:09 -0700 (PDT) Received: from neo-u2.ops-netman.net (neo-u2.OPS-NETMAN.NET [71.246.230.124]) by core3.amsl.com (Postfix) with ESMTP id 7C09F3A67DB for ; Wed, 28 Apr 2010 12:25:08 -0700 (PDT) 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 3D1D735C0B4; Wed, 28 Apr 2010 19:24:53 +0000 (UTC) Message-ID: <4BD88B84.6070105@ops-netman.net> Date: Wed, 28 Apr 2010 15:24:52 -0400 From: Chris Morrow User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Sandra Murphy References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 19:25:10 -0000 Sandra Murphy wrote: > The relative frequency of use of AS_SETs is interesting, but not really > germane to the point here. > > If we were trying to develop a protection for AS_SETs then we might want > to ask the engineering question of where and how often they were used. > > But for the purpose of validating received updates, we need a rule for > what is done with AS_SETs that appear in the AS_PATH origin. Lack of > rules leaves opportunities for deliberate or accidental mischief. > > AS_SETs might not be used very often, but that doesn't stop someone from > using AS_SETs deliberately with malicious intent. right so as a starting point: "AS_SET in an origin is unvalidatable." how about that? (I think this is fine since: 1) they aren't used in production very much anymore 2) where used, they seem to be mis-used 3) the rules for how you do verification/validation of an AS_SET are at best murky. -chris (regular user) > --Sandy, making a technical point as wg member and a document > completeness point as wg chair. > > On Wed, 28 Apr 2010, Warren Kumari wrote: > >> >> On Apr 28, 2010, at 2:37 PM, Sandra Murphy wrote: >> >>> >>> >>> On Thu, 29 Apr 2010, Geoff Huston wrote: >>> >>>> Thank you for this response. As I had noted earlier, if you had made >>>> it clearer in which role you were posting in these discussions it >>>> would be easier for others, or at least myself, to understand when >>>> you were making pronouncements as WG chair and when you were asking >>>> questions and airing opinions as an individual participant. >>>> >>>> If proxy aggregation is "not part of our work" then the outcome of >>>> such actions, namely AS Sets in the AS_PATH is likewise "not part of >>>> our work." I will edit the roa validation draft accordingly. >>> >>> Actually, no, that is not the case. >>> >>> When I say that proxy aggregation is not part of our work, I mean >>> that sidr does not promise to protect BGP announcements formed by >>> proxy aggregation. >>> >>> While it is true that AS_SETS are principally generated in BGP >>> updates by an AS that is doing proxy aggregation, AS_SETS are still >>> part of the BGP protocol and might appear in a received AS_PATH. >>> >>> Until and unless the idr working group decides to eliminate that >>> feature from the BGP protocol, the sidr route validation must still >>> make a statement about what happens when the AS_PATH origin is an >>> AS_SET. >>> >>> That is necessary for completeness. Furthermore, without such a >>> statement, implementers could make different decisions as to how to >>> handle such cases and attack paths could result. >>> >>> The sidr wg is not now considering anything but origin authorization, >>> so an AS_PATH segment that is an AS_SET but is not the origin is not >>> of our concern at all. >> >> Just for giggles I decided to see how how widely AS Sets were being >> used by having a quick look at route views data (yes, which I realize >> is incomplete, etc). >> >> I used an as-path regexp to only get AS paths that included an AS_SET >> and then did some grep, sed and awk hackery to get a handle on the data. >> >> >> I see zero AS_PATHs where the AS_SET is not the origin (i.e, where the >> AS_SET segment is not followed by i (internal), e (external) or ? >> (unknown): >> >> wkumari@colon:~/tmp$ cat assets | grep '} [^ie\?]' >> >> I see 39 unique paths where the "AS_SET" is only a single AS: >> wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed >> 's/.*{\(.*\)}.*/\1/' | sort | uniq | grep -v ',' | wc -l >> 39 >> >> and 21 unique paths where the AS_SET contains multiple ASs: >> wkumari@colon:~/tmp$ cat assets | egrep "^\*" | sed >> 's/.*{\(.*\)}.*/\1/' | sort | uniq | grep ',' >> 11060,12262 >> 1239,17079,27773 >> 17746,64512 >> 209,25729 >> 21135,49476 >> 25019,41426 >> 25912,65427 >> 31812,65473 >> 33363,65129,65188 >> 3356,8928,22351 >> 3491,15412,19710 >> 35821,35821,35821,35821 >> 45514,45514,45514 >> 45514,45514,45514,65081 >> 4558,30994,33770 >> 46124,46136 >> 50693,64601,64604,64607,64608,64609,64610,65505 >> 64520,64521 >> 7470,24128,38865,45199 >> 8002,15412 >> 8508,24748,35434 >> >> Of these, only: >> 11060,12262 >> 1239,17079,27773 >> 209,25729 >> 21135,49476 >> 25019,41426 >> 3356,8928,22351 >> 3491,15412,19710 >> 35821,35821,35821,35821 >> 45514,45514,45514 >> 4558,30994,33770 >> 46124,46136 >> 7470,24128,38865,45199 >> 8002,15412 >> 8508,24748,35434 >> >> do not contain private AS numbers. Some of the above contain only a >> single AS repeated multiple times (like 35821). >> >> I don't want this to devolve into a discussion on the merits of >> aggregation, if AS_SETs should be deprecated or anything similar, this >> was just because I wanted know for my own sake what the numbers were >> and figured others might be interested too.... >> >> W >> >> >> >>> >>> >>> >>> --Sandy >>> >>> >>> >>>> >>>> >>>> On 29/04/2010, at 3:16 AM, Sandra Murphy wrote: >>>> >>>>> I have said that it was the consensus even before sidr was >>>>> officially a wg that proxy aggregation would not be part of our >>>>> work. And I pointed to the email archive for that discussion. >>>>> >>>>> You have said that you do not believe that it is possible at this >>>>> point, so I don't think that you are unhappy with that statement. >>>>> >>>>> So I am confused as to what further statement I could make that >>>>> would help at this point. >>>>> >>>>> Can you point me to where you still see a problem? >>>>> >>>>> --Sandy >>>>> >>>>> On Wed, 28 Apr 2010, Geoff Huston wrote: >>>>> >>>>>> three weeks ago I asked: >>>>>> >>>>>>> >>>>>>> It seems to me that the essential requirements for securing proxy >>>>>>> aggregation are missing at this stage, which makes it somewhat >>>>>>> difficult for SIDR to work on mechanisms without some re-spinning >>>>>>> of the SIDR WG Charter (or some other WG) that would permit the >>>>>>> preliminary work on security requirements relating to proxy >>>>>>> aggregation to come first. >>>>>>> >>>>>>> So my question to the WG Co-chairs is: is work on securing Proxy >>>>>>> Aggregation within the current SIDR charter? If so, on what basis? >>>>>> >>>>>> I would hope that by now the WGchairs have had sufficient time to >>>>>> consider this question, so I'd like to ask once more: Is work on >>>>>> securing Proxy Aggregation within the current SIDR Charter? If >>>>>> so, on what basis? >>>>>> >>>>>> >>>>>> regards, >>>>>> >>>>>> Geoff >>>>>> >>>>>> >>>> >>>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> -- >> Eagles soar but a weasel will never get sucked into a jet engine >> >> From Sandra.Murphy@cobham.com Wed Apr 28 13:16:51 2010 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 61C103A697A for ; Wed, 28 Apr 2010 13:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_50=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 Sj+efqsuu8vB for ; Wed, 28 Apr 2010 13:16:50 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2862B3A6900 for ; Wed, 28 Apr 2010 13:16:50 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3SKGYpd020213; Wed, 28 Apr 2010 15:16:34 -0500 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 o3SKGH2x002927; Wed, 28 Apr 2010 15:16:20 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Apr 2010 16:10:29 -0400 Date: Wed, 28 Apr 2010 16:10:28 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <56825053-0433-4035-A85F-83651B8DC17D@apnic.net> Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <56825053-0433-4035-A85F-83651B8DC17D@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Apr 2010 20:10:29.0108 (UTC) FILETIME=[D9152340:01CAE70E] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 28 Apr 2010 20:16:51 -0000 On Thu, 29 Apr 2010, Geoff Huston wrote: > > On 29/04/2010, at 4:46 AM, Sandra Murphy wrote: > >> >> >> On Wed, 28 Apr 2010, Sandra Murphy wrote: >> >>> >>> >>> On Thu, 29 Apr 2010, Geoff Huston wrote: >>> >>>> Thank you for this response. As I had noted earlier, if you had made it clearer in which role you were posting in these discussions it would be easier for others, or at least myself, to understand when you were making pronouncements as WG chair and when you were asking questions and airing opinions as an individual participant. >>>> If proxy aggregation is "not part of our work" then the outcome of such actions, namely AS Sets in the AS_PATH is likewise "not part of our work." I will edit the roa validation draft accordingly. >>> >>> Actually, no, that is not the case. >>> >>> When I say that proxy aggregation is not part of our work, I mean that sidr does not promise to protect BGP announcements formed by proxy aggregation. >>> >>> While it is true that AS_SETS are principally generated in BGP updates by an AS that is doing proxy aggregation, AS_SETS are still part of the BGP protocol and might appear in a received AS_PATH. >>> >>> Until and unless the idr working group decides to eliminate that feature from the BGP protocol, the sidr route validation must still make a statement about what happens when the AS_PATH origin is an AS_SET. >>> >>> That is necessary for completeness. Furthermore, without such a statement, implementers could make different decisions as to how to handle such cases and attack paths could result. >>> >>> The sidr wg is not now considering anything but origin authorization, so an AS_PATH segment that is an AS_SET but is not the origin is not of our concern at all. >>> >>> >>> --Sandy >> >> >> Whoops! >> >> I meant: >> >> --Sandy, still conversing as wg chair >> > > thank you. > > So I'm confused with this additional statement of yours in the role of WG chair. > > To explain my confusion, when I grep AS_SET in RFC4271 I see it exclusively described with reference to aggregation - for example: "AS_SETs are used in the route aggregation algorithm described in Section 9.2.2.2" Section 9.2 is describing the "Update-Send Process." My statements about the AS_SET concern what happens in the Update receipt process, when the route validation is performed. > > So __with particular reference to the definition of an originating AS__ (which is where this particular particular strand started), where and why do AS_SETs have any relevance to the WG consideration of Origination Authorization? i.e. to phrase it in a more practical manner, what precisely is the problem with applying the edit proposed by John Scudder to the roa validation draft? The algorithm in 9.2.2.2 that is referenced above can result in an AS_SET as the first segment in an AS_PATH. Also, RFC4271 has plenty of references to AS_SETs occurring as the first segment in an AS_PATH (i.e., the originating AS). So an originating AS of type AS_SET is a legal part of BGP and will not be rejected by current implementations. An originating AS in the AS_PATH of type AS_SET is therefore part of our work because it will occur in inputs that the route validation must judge. I as wg chair am correcting your statement 'the outcome of such actions, namely AS Sets in the AS_PATH is likewise "not part of our work."' When you say "what precisely is the problem with applying the edit proposed by John Scudder to the roa validation draft?", I presume that you are referring to John's message of 3 Apr, in which he says: Granted this is a corner case, but nonetheless I can't see what the reason would be for considering an intermediate AS (albeit the first one contained in an AS_SEQUENCE) to be the origin. I suggest revising as follows: Consider the origin AS to be the contents of the AS_SET if it's a singleton set. Otherwise the origin cannot be determined. Given that it's a corner case, you could also cut right to the chase and just call it undetermined if the path starts (or ends, in your parlance) with an AS_SET, period. I am not saying that there is anything wrong with John's edit. I am not judging consensus that this would be the best way of dealing with an originating AS of type AS_SET. I am saying that we must have SOME rule of what happens when validating a route that contains an originating AS of type AS_SET, for document and implementation completeness. --Sandy, as wg chair > > Again, I'm asking the WG chairs here for further clarification because the above exchange has managed to confused me. > > Geoff > > From gih@apnic.net Wed Apr 28 23:06:48 2010 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 46F773A6AEA for ; Wed, 28 Apr 2010 23:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 A+1YVeIjIYLy for ; Wed, 28 Apr 2010 23:06:47 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 376183A6AE7 for ; Wed, 28 Apr 2010 23:06:47 -0700 (PDT) Received: from [10.31.8.43] (89.Red-217-127-196.staticIP.rima-tde.net [217.127.196.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8969CD58C8; Thu, 29 Apr 2010 16:06:29 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4BD88B84.6070105@ops-netman.net> Date: Thu, 29 Apr 2010 16:06:24 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> To: Chris Morrow X-Mailer: Apple Mail (2.1078) Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 29 Apr 2010 06:06:48 -0000 On 29/04/2010, at 5:24 AM, Chris Morrow wrote: >=20 >=20 > Sandra Murphy wrote: >> The relative frequency of use of AS_SETs is interesting, but not = really >> germane to the point here. >>=20 >> If we were trying to develop a protection for AS_SETs then we might = want >> to ask the engineering question of where and how often they were = used. >>=20 >> But for the purpose of validating received updates, we need a rule = for >> what is done with AS_SETs that appear in the AS_PATH origin. Lack of >> rules leaves opportunities for deliberate or accidental mischief. >>=20 >> AS_SETs might not be used very often, but that doesn't stop someone = from >> using AS_SETs deliberately with malicious intent. >=20 > right so as a starting point: > "AS_SET in an origin is unvalidatable." >=20 > how about that? (I think this is fine since: > 1) they aren't used in production very much anymore > 2) where used, they seem to be mis-used > 3) the rules for how you do verification/validation of an AS_SET are = at > best murky. >=20 > -chris > (regular user) >=20 You ask: "how about that?" That still works for me. Ironically (or any other adjective that matches = - I can think of quite a few more extreme ones that I could substitute) = this is _precisely_ where all this started when I proposed using the = following definition of an "origin AS" (in my note from 4 April): "A route's "origin AS" is the final element of the route object's AS_PATH attribute. If the final AS_PATH element is an AS Set, indicating that the route is an aggregate, then the origin AS cannot be determined." Geoff From morrowc@ops-netman.net Thu Apr 29 08:30:00 2010 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 0DEE428C149 for ; Thu, 29 Apr 2010 08:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_50=0.001, 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 oPARS+KrlQJO for ; Thu, 29 Apr 2010 08:29:59 -0700 (PDT) Received: from neo-u2.ops-netman.net (neo-u2.OPS-NETMAN.NET [71.246.230.124]) by core3.amsl.com (Postfix) with ESMTP id 048ED3A6A93 for ; Thu, 29 Apr 2010 08:29:57 -0700 (PDT) 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 961BF358778; Thu, 29 Apr 2010 15:29:41 +0000 (UTC) Message-ID: <4BD9A5E4.5070502@ops-netman.net> Date: Thu, 29 Apr 2010 11:29:40 -0400 From: Chris Morrow User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Geoff Huston References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> In-Reply-To: <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 29 Apr 2010 15:30:00 -0000 Geoff Huston wrote: > On 29/04/2010, at 5:24 AM, Chris Morrow wrote: > >> >> Sandra Murphy wrote: >>> The relative frequency of use of AS_SETs is interesting, but not really >>> germane to the point here. >>> >>> If we were trying to develop a protection for AS_SETs then we might want >>> to ask the engineering question of where and how often they were used. >>> >>> But for the purpose of validating received updates, we need a rule for >>> what is done with AS_SETs that appear in the AS_PATH origin. Lack of >>> rules leaves opportunities for deliberate or accidental mischief. >>> >>> AS_SETs might not be used very often, but that doesn't stop someone from >>> using AS_SETs deliberately with malicious intent. >> right so as a starting point: >> "AS_SET in an origin is unvalidatable." ("on reciept" i forgot to add) >> >> how about that? (I think this is fine since: >> 1) they aren't used in production very much anymore >> 2) where used, they seem to be mis-used >> 3) the rules for how you do verification/validation of an AS_SET are at >> best murky. >> >> -chris >> (regular user) >> > > > You ask: "how about that?" > > That still works for me. Ironically (or any other adjective that matches - I can think of quite a few more extreme ones that I could substitute) this is _precisely_ where all this started when I proposed using the following definition of an "origin AS" (in my note from 4 April): > > "A route's "origin AS" is the final element of the route object's > AS_PATH attribute. If the final AS_PATH element is an AS Set, > indicating that the route is an aggregate, then the origin AS > cannot be determined." cool, so I actually only did half the problem (reciept), on send as well we'd have to say: "If you are sending an update (announce or withdrawal) and that update's origin is an AS_SET, you can not sign the update." I think that makes sense because you can't determine which AS in the AS_SET should do the signing? -chris (again as a regular user) From kotikalapudi.sriram@nist.gov Thu Apr 29 08:43:04 2010 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 4A90A3A6B94 for ; Thu, 29 Apr 2010 08:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.827 X-Spam-Level: X-Spam-Status: No, score=-3.827 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_50=0.001, 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 f8UYo0BfoNKh for ; Thu, 29 Apr 2010 08:43:03 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 311E23A6AF6 for ; Thu, 29 Apr 2010 08:43:02 -0700 (PDT) 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 o3TFgUEZ007442; Thu, 29 Apr 2010 11:42:30 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 29 Apr 2010 11:42:30 -0400 From: "Sriram, Kotikalapudi" To: Chris Morrow , Geoff Huston Date: Thu, 29 Apr 2010 11:42:18 -0400 Thread-Topic: [sidr] SIDR Charter Question Thread-Index: AcrnsPik+vBJsnn5QIiuswZWhcKlAQAAPOlg Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> <4BD9A5E4.5070502@ops-netman.net> In-Reply-To: <4BD9A5E4.5070502@ops-netman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 29 Apr 2010 15:43:04 -0000 When you said "you can not sign the update", did you mean "you cannot register a ROA for your prefix with the AS set"? Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Chris Morrow > Sent: Thursday, April 29, 2010 11:30 AM > To: Geoff Huston > Cc: Sandra Murphy; sidr wg > Subject: Re: [sidr] SIDR Charter Question > > > > Geoff Huston wrote: > > On 29/04/2010, at 5:24 AM, Chris Morrow wrote: > > > >> > >> Sandra Murphy wrote: > >>> The relative frequency of use of AS_SETs is interesting, but not really > >>> germane to the point here. > >>> > >>> If we were trying to develop a protection for AS_SETs then we might want > >>> to ask the engineering question of where and how often they were used. > >>> > >>> But for the purpose of validating received updates, we need a rule for > >>> what is done with AS_SETs that appear in the AS_PATH origin. Lack of > >>> rules leaves opportunities for deliberate or accidental mischief. > >>> > >>> AS_SETs might not be used very often, but that doesn't stop someone from > >>> using AS_SETs deliberately with malicious intent. > >> right so as a starting point: > >> "AS_SET in an origin is unvalidatable." > > ("on reciept" i forgot to add) > > >> > >> how about that? (I think this is fine since: > >> 1) they aren't used in production very much anymore > >> 2) where used, they seem to be mis-used > >> 3) the rules for how you do verification/validation of an AS_SET are at > >> best murky. > >> > >> -chris > >> (regular user) > >> > > > > > > You ask: "how about that?" > > > > That still works for me. Ironically (or any other adjective that matches - I can think of > quite a few more extreme ones that I could substitute) this is _precisely_ where all this > started when I proposed using the following definition of an "origin AS" (in my note from 4 > April): > > > > "A route's "origin AS" is the final element of the route object's > > AS_PATH attribute. If the final AS_PATH element is an AS Set, > > indicating that the route is an aggregate, then the origin AS > > cannot be determined." > > cool, so I actually only did half the problem (reciept), on send as well > we'd have to say: "If you are sending an update (announce or withdrawal) > and that update's origin is an AS_SET, you can not sign the update." > > I think that makes sense because you can't determine which AS in the > AS_SET should do the signing? > > -chris > (again as a regular user) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Thu Apr 29 09:12:52 2010 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 4C35A3A69B2 for ; Thu, 29 Apr 2010 09:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_40=-0.185] 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 KFQu4q2rJaUx for ; Thu, 29 Apr 2010 09:12:51 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 47ECB28C0D8 for ; Thu, 29 Apr 2010 09:12:18 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3TGC2ZF030146; Thu, 29 Apr 2010 11:12:02 -0500 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 o3TGBttL005155; Thu, 29 Apr 2010 11:11:56 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Apr 2010 12:11:26 -0400 Date: Thu, 29 Apr 2010 12:11:26 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 Apr 2010 16:11:26.0514 (UTC) FILETIME=[9EA4B920:01CAE7B6] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 29 Apr 2010 16:12:52 -0000 On Thu, 29 Apr 2010, Geoff Huston wrote: > > On 29/04/2010, at 5:24 AM, Chris Morrow wrote: > >> >> >> Sandra Murphy wrote: >>> The relative frequency of use of AS_SETs is interesting, but not really >>> germane to the point here. >>> >>> If we were trying to develop a protection for AS_SETs then we might want >>> to ask the engineering question of where and how often they were used. >>> >>> But for the purpose of validating received updates, we need a rule for >>> what is done with AS_SETs that appear in the AS_PATH origin. Lack of >>> rules leaves opportunities for deliberate or accidental mischief. >>> >>> AS_SETs might not be used very often, but that doesn't stop someone from >>> using AS_SETs deliberately with malicious intent. >> >> right so as a starting point: >> "AS_SET in an origin is unvalidatable." >> >> how about that? (I think this is fine since: >> 1) they aren't used in production very much anymore >> 2) where used, they seem to be mis-used >> 3) the rules for how you do verification/validation of an AS_SET are at >> best murky. >> >> -chris >> (regular user) >> > > > You ask: "how about that?" > > That still works for me. Ironically (or any other adjective that matches - I can think of quite a few more extreme ones that I could substitute) this is _precisely_ where all this started when I proposed using the following definition of an "origin AS" (in my note from 4 April): > > "A route's "origin AS" is the final element of the route object's > AS_PATH attribute. If the final AS_PATH element is an AS Set, > indicating that the route is an aggregate, then the origin AS > cannot be determined." > Ironically, this also works to satisfy the requirement I stated that there needed to be some statement of what to do with AS_SETs. (Presuming that you intend that "cannot be determined" will lead to one of the defined validation conditions (e.g., "unknown", but that's not my call), not be left to some arbitrary action devised by the implementer.) Just to be clear, even the current language in draft-ietf-sidr-roa-validation-05 satisfies the requirement. I am not making a consensus statement about which statement should be chosen. --Sandy, speaking as wg chair > > > Geoff > > > From kotikalapudi.sriram@nist.gov Thu Apr 29 09:16:47 2010 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 44D1E3A69F3 for ; Thu, 29 Apr 2010 09:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 hslkKtdFq61J for ; Thu, 29 Apr 2010 09:16:46 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 976383A6985 for ; Thu, 29 Apr 2010 09:16:45 -0700 (PDT) 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 o3TGGEI0009404; Thu, 29 Apr 2010 12:16:14 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 29 Apr 2010 12:16:13 -0400 From: "Sriram, Kotikalapudi" To: Geoff Huston , Chris Morrow Date: Thu, 29 Apr 2010 12:16:08 -0400 Thread-Topic: [sidr] SIDR Charter Question Thread-Index: AcrnYkCGYBO97vKMQUG1DpXr/3OAcgAQ6Ang Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> In-Reply-To: <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C49307A10FF71DMBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 29 Apr 2010 16:16:47 -0000 --_000_D7A0423E5E193F40BE6E94126930C49307A10FF71DMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" May be we could include a BCP statement or warning within the algorithm document for the (very few) users of AS sets. If they use, for example, [AS42] or [AS42, AS42] type of AS set for whatever reason (i.e., with singleton AS in the AS set or the same ASN repeated multiple times) and also register a ROA for their prefix with that ASN (AS42 in the example) -- the BCP statement would warn them that their ROA would thwart a potential hijacker of their prefix but they should not expect to receive a positive ("Valid") assertion for their own update which contains that AS set as origin. Also, the same applies for cases when they actually do a genuine proxy aggregation such as using an AS set [AS42, AS43, AS44] for example and register three ROAs for their aggregate prefix for each of the three ASNs. Again, they should not expect a positive ("Valid") assertion for their own update which contains that AS set as origin. Sriram > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Geoff Huston > Sent: Thursday, April 29, 2010 2:06 AM > To: Chris Morrow > Cc: Sandra Murphy; sidr wg > Subject: Re: [sidr] SIDR Charter Question > > > On 29/04/2010, at 5:24 AM, Chris Morrow wrote: > > > > > > > Sandra Murphy wrote: > >> The relative frequency of use of AS_SETs is interesting, but not really > >> germane to the point here. > >> > >> If we were trying to develop a protection for AS_SETs then we might want > >> to ask the engineering question of where and how often they were used. > >> > >> But for the purpose of validating received updates, we need a rule for > >> what is done with AS_SETs that appear in the AS_PATH origin. Lack of > >> rules leaves opportunities for deliberate or accidental mischief. > >> > >> AS_SETs might not be used very often, but that doesn't stop someone from > >> using AS_SETs deliberately with malicious intent. > > > > right so as a starting point: > > "AS_SET in an origin is unvalidatable." > > > > how about that? (I think this is fine since: > > 1) they aren't used in production very much anymore > > 2) where used, they seem to be mis-used > > 3) the rules for how you do verification/validation of an AS_SET are at > > best murky. > > > > -chris > > (regular user) > > > > > You ask: "how about that?" > > That still works for me. Ironically (or any other adjective that matches - I can think of quite > a few more extreme ones that I could substitute) this is _precisely_ where all this started > when I proposed using the following definition of an "origin AS" (in my note from 4 April): > > "A route's "origin AS" is the final element of the route object's > AS_PATH attribute. If the final AS_PATH element is an AS Set, > indicating that the route is an aggregate, then the origin AS > cannot be determined." > > > > Geoff > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --_000_D7A0423E5E193F40BE6E94126930C49307A10FF71DMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29u dGVudD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0 ZiAtLT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGlu Zy1sZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIHNlcmlmIiBz aXplPSI0Ij4NCjxkaXY+TWF5IGJlIHdlIGNvdWxkIGluY2x1ZGUgYSBCQ1Agc3RhdGVtZW50IG9y IHdhcm5pbmcgd2l0aGluIHRoZTwvZGl2Pg0KPGRpdj5hbGdvcml0aG0gZG9jdW1lbnQgZm9yIHRo ZSAodmVyeSBmZXcpIHVzZXJzIG9mIEFTIHNldHMuPC9kaXY+DQo8ZGl2PklmIHRoZXkgdXNlLCBm b3IgZXhhbXBsZSwgW0FTNDJdIG9yIFtBUzQyLCBBUzQyXSB0eXBlIG9mIEFTIHNldDwvZGl2Pg0K PGRpdj5mb3Igd2hhdGV2ZXIgcmVhc29uIChpLmUuLCB3aXRoIHNpbmdsZXRvbiBBUyBpbiB0aGUg QVMgc2V0PC9kaXY+DQo8ZGl2Pm9yIHRoZSBzYW1lIEFTTiByZXBlYXRlZCBtdWx0aXBsZSB0aW1l cykgYW5kIGFsc28gcmVnaXN0ZXIgYSBST0EgZm9yIHRoZWlyPC9kaXY+DQo8ZGl2PnByZWZpeCB3 aXRoIHRoYXQgQVNOIChBUzQyIGluIHRoZSBleGFtcGxlKSAtLSA8L2Rpdj4NCjxkaXY+dGhlIEJD UCBzdGF0ZW1lbnQgd291bGQgd2FybiB0aGVtIHRoYXQgPC9kaXY+DQo8ZGl2PnRoZWlyIFJPQSB3 b3VsZCB0aHdhcnQgYSBwb3RlbnRpYWwgaGlqYWNrZXIgb2YgdGhlaXIgcHJlZml4IGJ1dCA8L2Rp dj4NCjxkaXY+dGhleSBzaG91bGQgbm90IGV4cGVjdCB0byByZWNlaXZlIGEgcG9zaXRpdmUgKCZx dW90O1ZhbGlkJnF1b3Q7KSBhc3NlcnRpb24gZm9yIHRoZWlyPC9kaXY+DQo8ZGl2Pm93biB1cGRh dGUgd2hpY2ggY29udGFpbnMgdGhhdCBBUyBzZXQgYXMgb3JpZ2luLjwvZGl2Pg0KPGRpdj5BbHNv LCB0aGUgc2FtZSBhcHBsaWVzIGZvciBjYXNlcyB3aGVuIHRoZXkgYWN0dWFsbHkgZG8gYSBnZW51 aW5lIHByb3h5IDwvZGl2Pg0KPGRpdj5hZ2dyZWdhdGlvbiBzdWNoIGFzIHVzaW5nIGFuIEFTIHNl dCBbQVM0MiwgQVM0MywgQVM0NF0gZm9yIGV4YW1wbGUgPC9kaXY+DQo8ZGl2PmFuZCZuYnNwOyBy ZWdpc3RlciB0aHJlZSBST0FzIGZvciB0aGVpciBhZ2dyZWdhdGUgcHJlZml4IGZvciBlYWNoIDwv ZGl2Pg0KPGRpdj5vZiB0aGUmbmJzcDsgdGhyZWUgQVNOcy4gQWdhaW4sIHRoZXkgc2hvdWxkIG5v dCBleHBlY3QgYSBwb3NpdGl2ZSAoJnF1b3Q7VmFsaWQmcXVvdDspIDwvZGl2Pg0KPGRpdj5hc3Nl cnRpb24gZm9yIHRoZWlyIG93biB1cGRhdGUgd2hpY2ggY29udGFpbnMgdGhhdCBBUyBzZXQgYXMg b3JpZ2luLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlNyaXJhbTwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2 Pg0KPGRpdj4mZ3Q7IEZyb206IHNpZHItYm91bmNlc0BpZXRmLm9yZyBbPGEgaHJlZj0ibWFpbHRv OnNpZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZzwvYT5d IE9uIEJlaGFsZiBPZiBHZW9mZiBIdXN0b248L2Rpdj4NCjxkaXY+Jmd0OyBTZW50OiBUaHVyc2Rh eSwgQXByaWwgMjksIDIwMTAgMjowNiBBTTwvZGl2Pg0KPGRpdj4mZ3Q7IFRvOiBDaHJpcyBNb3Jy b3c8L2Rpdj4NCjxkaXY+Jmd0OyBDYzogU2FuZHJhIE11cnBoeTsgc2lkciB3ZzwvZGl2Pg0KPGRp dj4mZ3Q7IFN1YmplY3Q6IFJlOiBbc2lkcl0gU0lEUiBDaGFydGVyIFF1ZXN0aW9uPC9kaXY+DQo8 ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgT24gMjkvMDQvMjAx MCwgYXQgNToyNCBBTSwgQ2hyaXMgTW9ycm93IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2 Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyBTYW5kcmEgTXVycGh5IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmZ3Q7IFRoZSBy ZWxhdGl2ZSBmcmVxdWVuY3kgb2YgdXNlIG9mIEFTX1NFVHMgaXMgaW50ZXJlc3RpbmcsIGJ1dCBu b3QgcmVhbGx5PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyZndDsgZ2VybWFuZSB0byB0aGUgcG9pbnQg aGVyZS48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmZ3Q7 IElmIHdlIHdlcmUgdHJ5aW5nIHRvIGRldmVsb3AgYSBwcm90ZWN0aW9uIGZvciBBU19TRVRzIHRo ZW4gd2UgbWlnaHQgd2FudDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmZ3Q7IHRvIGFzayB0aGUgZW5n aW5lZXJpbmcgcXVlc3Rpb24gb2Ygd2hlcmUgYW5kIGhvdyBvZnRlbiB0aGV5IHdlcmUgdXNlZC48 L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmZ3Q7IEJ1dCBm b3IgdGhlIHB1cnBvc2Ugb2YgdmFsaWRhdGluZyByZWNlaXZlZCB1cGRhdGVzLCB3ZSBuZWVkIGEg cnVsZSBmb3I8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jmd0OyB3aGF0IGlzIGRvbmUgd2l0aCBBU19T RVRzIHRoYXQgYXBwZWFyIGluIHRoZSBBU19QQVRIIG9yaWdpbi4mbmJzcDsgTGFjayBvZjwvZGl2 Pg0KPGRpdj4mZ3Q7ICZndDsmZ3Q7IHJ1bGVzIGxlYXZlcyBvcHBvcnR1bml0aWVzIGZvciBkZWxp YmVyYXRlIG9yIGFjY2lkZW50YWwgbWlzY2hpZWYuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyZndDs8 L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jmd0OyBBU19TRVRzIG1pZ2h0IG5vdCBiZSB1c2VkIHZlcnkg b2Z0ZW4sIGJ1dCB0aGF0IGRvZXNuJ3Qgc3RvcCBzb21lb25lIGZyb208L2Rpdj4NCjxkaXY+Jmd0 OyAmZ3Q7Jmd0OyB1c2luZyBBU19TRVRzIGRlbGliZXJhdGVseSB3aXRoIG1hbGljaW91cyBpbnRl bnQuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgcmlnaHQgc28g YXMgYSBzdGFydGluZyBwb2ludDo8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZxdW90O0FTX1NFVCBp biBhbiBvcmlnaW4gaXMgdW52YWxpZGF0YWJsZS4mcXVvdDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBob3cgYWJvdXQgdGhhdD8gKEkgdGhpbmsgdGhpcyBpcyBm aW5lIHNpbmNlOjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgMSkgdGhleSBhcmVuJ3QgdXNlZCBpbiBw cm9kdWN0aW9uIHZlcnkgbXVjaCBhbnltb3JlPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAyKSB3aGVy ZSB1c2VkLCB0aGV5IHNlZW0gdG8gYmUgbWlzLXVzZWQ8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IDMp IHRoZSBydWxlcyBmb3IgaG93IHlvdSBkbyB2ZXJpZmljYXRpb24vdmFsaWRhdGlvbiBvZiBhbiBB U19TRVQgYXJlIGF0PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBiZXN0IG11cmt5LjwvZGl2Pg0KPGRp dj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IC1jaHJpczwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgKHJlZ3VsYXIgdXNlcik8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZn dDsgPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgWW91IGFzazogJnF1b3Q7aG93 IGFib3V0IHRoYXQ/JnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgVGhh dCBzdGlsbCB3b3JrcyBmb3IgbWUuIElyb25pY2FsbHkgKG9yIGFueSBvdGhlciBhZGplY3RpdmUg dGhhdCBtYXRjaGVzIC0gSSBjYW4gdGhpbmsgb2YgcXVpdGU8L2Rpdj4NCjxkaXY+Jmd0OyBhIGZl dyBtb3JlIGV4dHJlbWUgb25lcyB0aGF0IEkgY291bGQgc3Vic3RpdHV0ZSkgdGhpcyBpcyBfcHJl Y2lzZWx5XyB3aGVyZSBhbGwgdGhpcyBzdGFydGVkPC9kaXY+DQo8ZGl2PiZndDsgd2hlbiBJIHBy b3Bvc2VkIHVzaW5nIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBvZiBhbiAmcXVvdDtvcmlnaW4g QVMmcXVvdDsgKGluIG15IG5vdGUgZnJvbSA0IEFwcmlsKTo8L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rp dj4NCjxkaXY+Jmd0OyAmcXVvdDtBIHJvdXRlJ3MgJnF1b3Q7b3JpZ2luIEFTJnF1b3Q7IGlzIHRo ZSBmaW5hbCBlbGVtZW50IG9mIHRoZSByb3V0ZSBvYmplY3QnczwvZGl2Pg0KPGRpdj4mZ3Q7Jm5i c3A7IEFTX1BBVEggYXR0cmlidXRlLiZuYnNwOyBJZiB0aGUgZmluYWwgQVNfUEFUSCBlbGVtZW50 IGlzIGFuIEFTIFNldCw8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyBpbmRpY2F0aW5nIHRoYXQgdGhl IHJvdXRlIGlzIGFuIGFnZ3JlZ2F0ZSwgdGhlbiB0aGUgb3JpZ2luIEFTPC9kaXY+DQo8ZGl2PiZn dDsmbmJzcDsgY2Fubm90IGJlIGRldGVybWluZWQuJnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDsgPC9k aXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsm bmJzcDsgR2VvZmY8L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxk aXY+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv ZGl2Pg0KPGRpdj4mZ3Q7IHNpZHIgbWFpbGluZyBsaXN0PC9kaXY+DQo8ZGl2PiZndDsgc2lkckBp ZXRmLm9yZzwvZGl2Pg0KPGRpdj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lkciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaWRyPC9hPjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZm9udD4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_D7A0423E5E193F40BE6E94126930C49307A10FF71DMBCLUSTERxcha_-- From morrowc@ops-netman.net Thu Apr 29 09:46:20 2010 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 A0DFE28C188 for ; Thu, 29 Apr 2010 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.161 X-Spam-Level: * X-Spam-Status: No, score=1.161 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_50=0.001, 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 qzbLSpL5jw0c for ; Thu, 29 Apr 2010 09:46:19 -0700 (PDT) Received: from neo-u2.ops-netman.net (neo-u2.OPS-NETMAN.NET [71.246.230.124]) by core3.amsl.com (Postfix) with ESMTP id 897B228C191 for ; Thu, 29 Apr 2010 09:46:19 -0700 (PDT) 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 DE77335C28F; Thu, 29 Apr 2010 16:46:02 +0000 (UTC) Message-ID: <4BD9B7C9.4050000@ops-netman.net> Date: Thu, 29 Apr 2010 12:46:01 -0400 From: Chris Morrow User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> <4BD9A5E4.5070502@ops-netman.net> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 29 Apr 2010 16:46:20 -0000 Sriram, Kotikalapudi wrote: > When you said "you can not sign the update", > did you mean "you cannot register a ROA for your prefix with the AS set"? yes, three folks now have corrected me. (I got ahead of myself) -chris >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Chris Morrow >> Sent: Thursday, April 29, 2010 11:30 AM >> To: Geoff Huston >> Cc: Sandra Murphy; sidr wg >> Subject: Re: [sidr] SIDR Charter Question >> >> >> >> Geoff Huston wrote: >>> On 29/04/2010, at 5:24 AM, Chris Morrow wrote: >>> >>>> Sandra Murphy wrote: >>>>> The relative frequency of use of AS_SETs is interesting, but not really >>>>> germane to the point here. >>>>> >>>>> If we were trying to develop a protection for AS_SETs then we might want >>>>> to ask the engineering question of where and how often they were used. >>>>> >>>>> But for the purpose of validating received updates, we need a rule for >>>>> what is done with AS_SETs that appear in the AS_PATH origin. Lack of >>>>> rules leaves opportunities for deliberate or accidental mischief. >>>>> >>>>> AS_SETs might not be used very often, but that doesn't stop someone from >>>>> using AS_SETs deliberately with malicious intent. >>>> right so as a starting point: >>>> "AS_SET in an origin is unvalidatable." >> ("on reciept" i forgot to add) >> >>>> how about that? (I think this is fine since: >>>> 1) they aren't used in production very much anymore >>>> 2) where used, they seem to be mis-used >>>> 3) the rules for how you do verification/validation of an AS_SET are at >>>> best murky. >>>> >>>> -chris >>>> (regular user) >>>> >>> >>> You ask: "how about that?" >>> >>> That still works for me. Ironically (or any other adjective that matches - I can think of >> quite a few more extreme ones that I could substitute) this is _precisely_ where all this >> started when I proposed using the following definition of an "origin AS" (in my note from 4 >> April): >>> "A route's "origin AS" is the final element of the route object's >>> AS_PATH attribute. If the final AS_PATH element is an AS Set, >>> indicating that the route is an aggregate, then the origin AS >>> cannot be determined." >> cool, so I actually only did half the problem (reciept), on send as well >> we'd have to say: "If you are sending an update (announce or withdrawal) >> and that update's origin is an AS_SET, you can not sign the update." >> >> I think that makes sense because you can't determine which AS in the >> AS_SET should do the signing? >> >> -chris >> (again as a regular user) >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr From warren@kumari.net Thu Apr 29 09:56:14 2010 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 0901428C169 for ; Thu, 29 Apr 2010 09:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_50=0.001, 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 vr2BFVlM42th for ; Thu, 29 Apr 2010 09:56:12 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 7B2E83A6B83 for ; Thu, 29 Apr 2010 09:56:12 -0700 (PDT) Received: by smtp.kumari.net (Postfix, from userid 5001) id 52F2C2284688; Thu, 29 Apr 2010 12:53:43 -0400 (EDT) Received: from dot.her.corp.google.com (unknown [74.202.225.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 3B4C5228446F; Thu, 29 Apr 2010 12:53:42 -0400 (EDT) Message-Id: <7ED71DC6-B865-4C2C-9F69-723602A0ECFE@kumari.net> From: Warren Kumari To: "Sriram, Kotikalapudi" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-49-47696920 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Apr 2010 12:55:56 -0400 References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> X-Mailer: Apple Mail (2.936) Cc: Chris Morrow , Sandra Murphy , sidr wg Subject: Re: [sidr] SIDR Charter Question 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, 29 Apr 2010 16:56:14 -0000 --Apple-Mail-49-47696920 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 29, 2010, at 12:16 PM, Sriram, Kotikalapudi wrote: > May be we could include a BCP statement or warning within the > algorithm document for the (very few) users of AS sets. > If they use, for example, [AS42] or [AS42, AS42] type of AS set > for whatever reason (i.e., with singleton AS in the AS set > or the same ASN repeated multiple times) and also register a ROA for > their > prefix with that ASN (AS42 in the example) -- > the BCP statement would warn them that > their ROA would thwart a potential hijacker of their prefix but > they should not expect to receive a positive ("Valid") assertion for > their > own update which contains that AS set as origin. I am not following you here -- can you please explain what you mean by "should not expect to receive a positive ("Valid") assertion for their own update which contains that AS set as origin."? > Also, the same applies for cases when they actually do a genuine proxy > aggregation such as using an AS set [AS42, AS43, AS44] for example > and register three ROAs for their aggregate prefix for each > of the three ASNs. Again, they should not expect a positive ("Valid") > assertion for their own update which contains that AS set as origin. > > Sriram > > > -----Original Message----- > > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On > Behalf Of Geoff Huston > > Sent: Thursday, April 29, 2010 2:06 AM > > To: Chris Morrow > > Cc: Sandra Murphy; sidr wg > > Subject: Re: [sidr] SIDR Charter Question > > > > > > On 29/04/2010, at 5:24 AM, Chris Morrow wrote: > > > > > > > > > > > Sandra Murphy wrote: > > >> The relative frequency of use of AS_SETs is interesting, but > not really > > >> germane to the point here. Well, I sort of think it is -- if 95% of routes contained AS_SETs in the origin then saying that you just cannot validate routes with AS_SETs in the origin is a non-starter. > > >> > > >> If we were trying to develop a protection for AS_SETs then we > might want > > >> to ask the engineering question of where and how often they > were used. > > >> > > >> But for the purpose of validating received updates, we need a > rule for > > >> what is done with AS_SETs that appear in the AS_PATH origin. > Lack of > > >> rules leaves opportunities for deliberate or accidental mischief. Yes -- because their occurrence is not huge, we can make the call that these routs just do not get the win... W > > >> > > >> AS_SETs might not be used very often, but that doesn't stop > someone from > > >> using AS_SETs deliberately with malicious intent. > > > > > > right so as a starting point: > > > "AS_SET in an origin is unvalidatable." > > > > > > how about that? (I think this is fine since: > > > 1) they aren't used in production very much anymore > > > 2) where used, they seem to be mis-used > > > 3) the rules for how you do verification/validation of an AS_SET > are at > > > best murky. > > > > > > -chris > > > (regular user) > > > > > > > > > You ask: "how about that?" > > > > That still works for me. Ironically (or any other adjective that > matches - I can think of quite > > a few more extreme ones that I could substitute) this is > _precisely_ where all this started > > when I proposed using the following definition of an "origin > AS" (in my note from 4 April): > > > > "A route's "origin AS" is the final element of the route object's > > AS_PATH attribute. If the final AS_PATH element is an AS Set, > > indicating that the route is an aggregate, then the origin AS > > cannot be determined." > > > > > > > > Geoff > > > > > > _______________________________________________ > > 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 -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett --Apple-Mail-49-47696920 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Apr 29, 2010, = at 12:16 PM, Sriram, Kotikalapudi wrote:

May be we could include a BCP statement or = warning within the
algorithm document for the (very few) users = of AS sets.
If they use, for example, [AS42] or [AS42, AS42] = type of AS set
for whatever reason (i.e., with singleton AS in = the AS set
or the same ASN repeated multiple times) and also = register a ROA for their
prefix with that ASN (AS42 in the = example) --
the BCP statement would warn them = that
their ROA would thwart a potential hijacker of their = prefix but
they should not expect to receive a positive = ("Valid") assertion for = their
own update which contains that AS set as = origin.

I am = not following you here -- can you please explain what you mean by "should not expect to receive a positive = ("Valid") assertion for their own update which contains that AS set = as origin."?

Also, the same applies for cases when they = actually do a genuine proxy
aggregation such as using an AS = set [AS42, AS43, AS44] for example
and  register three = ROAs for their aggregate prefix for each
of the  three = ASNs. Again, they should not expect a positive = ("Valid")
assertion for their own update which contains that = AS set as = origin.
 
Sriram
 
> = -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] = On Behalf Of Geoff Huston
> Sent: Thursday, April 29, 2010 = 2:06 AM
> To: Chris Morrow
> Cc: Sandra = Murphy; sidr wg
> Subject: Re: [sidr] SIDR Charter = Question
>
>
> On 29/04/2010, at = 5:24 AM, Chris Morrow wrote:
>
> = >
> >
> > Sandra Murphy = wrote:
> >> The relative frequency of use of AS_SETs = is interesting, but not really
> >> germane to the = point = here.

Well, I = sort of think it is -- if 95% of routes contained AS_SETs in the origin = then saying that you just cannot validate routes with AS_SETs in the = origin is a non-starter.

> >>
> >> If = we were trying to develop a protection for AS_SETs then we might = want
> >> to ask the engineering question of where = and how often they were used.
> >>
> = >> But for the purpose of validating received updates, we need a = rule for
> >> what is done with AS_SETs that appear = in the AS_PATH origin.  Lack of
> >> rules = leaves opportunities for deliberate or accidental = mischief.

Yes = -- because their occurrence is not huge, we can make the call that these = routs just do not get the = win...

W

> >>
> >> = AS_SETs might not be used very often, but that doesn't stop someone = from
> >> using AS_SETs deliberately with malicious = intent.
> >
> > right so as a starting = point:
> > "AS_SET in an origin is = unvalidatable."
> >
> > how about that? = (I think this is fine since:
> > 1) they aren't used in = production very much anymore
> > 2) where used, they = seem to be mis-used
> > 3) the rules for how you do = verification/validation of an AS_SET are at
> > best = murky.
> >
> > -chris
> = > (regular user)
> = >
>
>
> You ask: "how about = that?"
>
> That still works for me. Ironically = (or any other adjective that matches - I can think of = quite
> a few more extreme ones that I could substitute) = this is _precisely_ where all this started
> when I = proposed using the following definition of an "origin AS" (in my note = from 4 April):
>
> "A route's "origin AS" is = the final element of the route object's
>  AS_PATH = attribute.  If the final AS_PATH element is an AS = Set,
>  indicating that the route is an aggregate, = then the origin AS
>  cannot be = determined."
>
>
>
>&n= bsp;  Geoff
>
>
> = _______________________________________________
> sidr = mailing list
 
____________________= ___________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

=
--
"Build a man a = fire, and he'll be warm for a day. Set a man on fire, and he'll be warm = for the rest of his life." -- Terry Pratchett

= --Apple-Mail-49-47696920-- From Wesley.E.George@sprint.com Thu Apr 29 12:47:50 2010 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 9E51928C222 for ; Thu, 29 Apr 2010 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_60=1, HTML_MESSAGE=0.001, 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 ptSU9cRDgvCH for ; Thu, 29 Apr 2010 12:47:44 -0700 (PDT) Received: from TX2EHSOBE008.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id B3EB128C17C for ; Thu, 29 Apr 2010 12:47:36 -0700 (PDT) Received: from mail114-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 8.1.340.0; Thu, 29 Apr 2010 19:47:22 +0000 Received: from mail114-tx2 (localhost.localdomain [127.0.0.1]) by mail114-tx2-R.bigfish.com (Postfix) with ESMTP id 10E7419F05DA for ; Thu, 29 Apr 2010 19:47:23 +0000 (UTC) X-SpamScore: -9 X-BigFish: VS-9(zz1418M4015Lzz1202hz4fhzz2fh87h2a8h61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail114-tx2 (localhost.localdomain [127.0.0.1]) by mail114-tx2 (MessageSwitch) id 127257044252125_13045; Thu, 29 Apr 2010 19:47:22 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.244]) by mail114-tx2.bigfish.com (Postfix) with ESMTP id 00F9E12D8050 for ; Thu, 29 Apr 2010 19:47:22 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.0.482.44; Thu, 29 Apr 2010 19:47:20 +0000 Received: from PDAWH04A.ad.sprint.com (pdawh04a.corp.sprint.com [144.226.110.79]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.3/Sentrion-MTA-4.0.3) with ESMTP id o3TJl5a4011131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Apr 2010 14:47:20 -0500 Received: from PLSWM01C.ad.sprint.com ([144.226.242.77]) by PDAWH04A.ad.sprint.com ([2002:90e2:6e4f::90e2:6e4f]) with mapi; Thu, 29 Apr 2010 14:47:13 -0500 From: "George, Wes E IV [NTK]" To: "sidr@ietf.org" Date: Thu, 29 Apr 2010 14:47:03 -0500 Thread-Topic: non-transitive extended community in draft-pmohapat-sidr-origin-validation-signaling-00 Thread-Index: Acrn1L1oulpGySQjSCmpkXkXqqGCsQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F7EB0A7C707E39409A73CD0353242551A8925C05BFPLSWM01Cadspr_" MIME-Version: 1.0 X-Reverse-DNS: smtpls1.sprint.com Subject: [sidr] non-transitive extended community in draft-pmohapat-sidr-origin-validation-signaling-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, 29 Apr 2010 19:47:50 -0000 --_000_F7EB0A7C707E39409A73CD0353242551A8925C05BFPLSWM01Cadspr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pradosh and I were talking about the BGP implementation the other day, and = I had a comment about the extended community that is proposed to carry a ro= ute's validation state. He said that he had discussed this issue with some = folks one on one, but recommended that I bring it to the list for wider dis= cussion. In the current draft, the extended community is tagged as non-transitive, a= nd because of that, there is language to say that it MUST not be announced = to eBGP peers. I think I understand why this would be the case; since there= is no certification as to the validity of the data beyond your own AS like= there is with the actual RPKI infrastructure, it is not really a trustwort= hy source of validation data beyond one's own AS. However, I believe that I have a use case where it would be valuable to be = able to configure the extended community as transitive. In a scenario where= origin validation has relatively wide adoption, I expect that many large I= SPs and other networks will set up their own RPKI cache servers to manage o= rigin validation duties for their networks. However, I believe that there w= ill be some other networks that will not want to set up their own RPKI cach= e. Ok, no big deal, right? While it wouldn't be in the IGP, it's still possible for those networks to = configure their routers to use a third party's cache. For example, a networ= k could be using an RPKI cache set up by an ISP for their customers to use,= kind of like a cache-only DNS server. But, this assumes that they have sof= tware on their AS border routers that supports origin validation at all, wh= ich is sort of a big "if". The reality is that there are plenty of people r= unning code and routers that don't have a new feature roadmap anymore, and = likely won't be getting this feature, but are otherwise still functional wi= thin the area they are serving in a given network. While SIDR origin valida= tion is a good reason to upgrade, it may not actually impress the beancount= er crew enough to shake the necessary money loose to do so. I agree that it is much cleaner and more appropriate to actually do your ow= n RPKI validation and provide that info directly to your ASBRs, but I think= that making this community configurable as transitive even if we specify t= hat it MUST default to non-transitive gives good flexibility. More specific= ally, this allows people to take advantage of origin validation for policy = decisions such as the examples given in Anaheim even if their ASBRs do not = support the full implementation. Carrying the communities into eBGP gives a= measure of backwards compatibility that may encourage wider deployment. If we end up going in that direction, it may make sense to identify some be= st practices around how to ensure that the validity communities that you re= ceive are trustworthy, such as eBGP session authentication, having a policy= or knob that removes/ignores validity communities from eBGP peers you do n= ot have a trust relationship with, etc. Thanks, Wes ________________________________ This e-mail may contain Sprint Nextel Company proprietary information inten= ded for the sole use of the recipient(s). Any use by others is prohibited. = If you are not the intended recipient, please contact the sender and delete= all copies of the message. --_000_F7EB0A7C707E39409A73CD0353242551A8925C05BFPLSWM01Cadspr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pradosh and I were talking about the BGP implementation the other day,= and I had a comment about the extended community that is proposed to carry= a route’s validation state. He said that he had discussed this issue= with some folks one on one, but recommended that I bring it to the list for wider discussion.
 
In the current draft, the extended community is tagged as non-transiti= ve, and because of that, there is language to say that it MUST not be annou= nced to eBGP peers. I think I understand why this would be the case; since = there is no certification as to the validity of the data beyond your own AS like there is with the actual R= PKI infrastructure, it is not really a trustworthy source of validation dat= a beyond one’s own AS.
 
However, I believe that I have a use case where it would be valuable t= o be able to configure the extended community as transitive. In a scenario = where origin validation has relatively wide adoption, I expect that many la= rge ISPs and other networks will set up their own RPKI cache servers to manage origin validation duties for = their networks. However, I believe that there will be some other networks t= hat will not want to set up their own RPKI cache. Ok, no big deal, right?
While it wouldn’t be in the IGP, it’s still possible for t= hose networks to configure their routers to use a third party’s cache= . For example, a network could be using an RPKI cache set up by an ISP for = their customers to use, kind of like a cache-only DNS server. But, this assumes that they have software on their AS border ro= uters that supports origin validation at all, which is sort of a big “= ;if”. The reality is that there are plenty of people running code and= routers that don’t have a new feature roadmap anymore, and likely won’t be getting this feature, but are otherwise = still functional within the area they are serving in a given network. While= SIDR origin validation is a good reason to upgrade, it may not actually im= press the beancounter crew enough to shake the necessary money loose to do so.
 
I agree that it is much cleaner and more appropriate to actually do yo= ur own RPKI validation and provide that info directly to your ASBRs, but I = think that making this community configurable as transitive even if we spec= ify that it MUST default to non-transitive gives good flexibility. More specifically, this allows people to take advan= tage of origin validation for policy decisions such as the examples given i= n Anaheim even if their ASBRs do not support the full implementation. Carry= ing the communities into eBGP gives a measure of backwards compatibility that may encourage wider deployment.
 
If we end up going in that direction, it may make sense to identify so= me best practices around how to ensure that the validity communities that y= ou receive are trustworthy, such as eBGP session authentication, having a p= olicy or knob that removes/ignores validity communities from eBGP peers you do not have a trust relationship w= ith, etc.
Thanks,
Wes
 

  ___________= _____________________  
This e-m= ail may contain Sprint Nextel Company proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If you a= re not the intended recipient, please contact the sender and delete all copies of the message.
 --_000_F7EB0A7C707E39409A73CD0353242551A8925C05BFPLSWM01Cadspr_-- From randy@psg.com Thu Apr 29 13:47:07 2010 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 7A61E3A68AD for ; Thu, 29 Apr 2010 13:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.805, 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 8ut8Y0S2HdIs for ; Thu, 29 Apr 2010 13:47:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 9B3DC3A6845 for ; Thu, 29 Apr 2010 13:47:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1O7adG-000BfE-M1; Thu, 29 Apr 2010 20:46:50 +0000 Date: Thu, 29 Apr 2010 13:46:49 -0700 Message-ID: From: Randy Bush To: Chris Morrow In-Reply-To: <4BD9A5E4.5070502@ops-netman.net> References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> <4BD9A5E4.5070502@ops-netman.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 Subject: Re: [sidr] AS-SETs (was some political bs subject) 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, 29 Apr 2010 20:47:07 -0000 as i said last week, though a bit more tersely :) would folk please look at rfc 4271 section 5.1.7. this specifies the optional attribute AGGREGATOR, which should be the as number of the aggregating as. you will see that this is the asn used to validate against the roa in draft-pmohapat-sidr-pfx-validate-07.txt. could you point out the harm in this simple seeming approach? randy From Sandra.Murphy@cobham.com Fri Apr 30 10:06:25 2010 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 B892928C10C for ; Fri, 30 Apr 2010 10:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_50=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 taTyoTcR4Nlp for ; Fri, 30 Apr 2010 10:06:25 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id CD93728C0FC for ; Fri, 30 Apr 2010 10:06:24 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o3UH6AaL013404; Fri, 30 Apr 2010 12:06:10 -0500 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 o3UH69hr019271; Fri, 30 Apr 2010 12:06:10 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Apr 2010 12:59:48 -0400 Date: Fri, 30 Apr 2010 12:59:46 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> <4BD9A5E4.5070502@ops-netman.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 30 Apr 2010 16:59:48.0877 (UTC) FILETIME=[8AFFEBD0:01CAE886] Cc: Chris Morrow , sidr wg Subject: Re: [sidr] AS-SETs (was some political bs subject) 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, 30 Apr 2010 17:06:25 -0000 The draft-ietf-sidr-roa-validation-05 contains this same specification, in the section John Scudder pointed to in his message of 3 Apr (section 2, page 3). The difficulty lies in the fact that the AGGREGATOR attribute is only a "MAY attach" in RFC4271. The paragraph in draft-ietf-sidr-roa-validation-05 also contains a specification of what to do if there is no AGGREGATOR attribute available. As I view the conversation, John objected to this second part of the draft's specification, not the first part. But the conversation spiraled from there. --Sandy, speaking as wg chair On Thu, 29 Apr 2010, Randy Bush wrote: > as i said last week, though a bit more tersely :) > > would folk please look at rfc 4271 section 5.1.7. this specifies the > optional attribute AGGREGATOR, which should be the as number of the > aggregating as. you will see that this is the asn used to validate > against the roa in draft-pmohapat-sidr-pfx-validate-07.txt. > > could you point out the harm in this simple seeming approach? > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From gih@apnic.net Fri Apr 30 11:44:54 2010 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 9EE683A6837 for ; Fri, 30 Apr 2010 11:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 jlleO1bZLCQg for ; Fri, 30 Apr 2010 11:44:53 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 67A1E3A6AE4 for ; Fri, 30 Apr 2010 11:44:52 -0700 (PDT) Received: from [10.31.8.43] (89.Red-217-127-196.staticIP.rima-tde.net [217.127.196.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8EA08D58FA; Sat, 1 May 2010 04:44:29 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 1 May 2010 04:44:21 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <76A4DB2C-92FB-460A-8B78-F4DCAB1F7AE2@apnic.net> References: <6BE81341-4FAA-4A81-8DD0-D43900FD8B51@kumari.net> <96FE2DA2-8068-4E2B-A532-AB76BDA98434@apnic.net> <1667E28A-82CB-4F1E-AC0A-2A7619DD7C55@apnic.net> <6249EC88-79D1-4385-B7A2-D6802F123E23@kumari.net> <4BD88B84.6070105@ops-netman.net> <222E2D36-FBE3-4951-BB1D-8B17391AA099@apnic.net> <4BD9A5E4.5070502@ops-netman.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1078) Cc: Chris Morrow , sidr wg Subject: [sidr] origin AS definition (was some sns about some political bs) 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, 30 Apr 2010 18:44:54 -0000 On 01/05/2010, at 2:59 AM, Sandra Murphy wrote: > The draft-ietf-sidr-roa-validation-05 contains this same = specification, in the section John Scudder pointed to in his message of = 3 Apr (section 2, page 3). >=20 > The difficulty lies in the fact that the AGGREGATOR attribute is only = a "MAY attach" in RFC4271. The paragraph in = draft-ietf-sidr-roa-validation-05 also contains a specification of what = to do if there is no AGGREGATOR attribute available. As I view the = conversation, John objected to this second part of the draft's = specification, not the first part. >=20 John suggested the following: "Granted this is a corner case, but nonetheless I can't see what the = reason would be for considering an intermediate AS (albeit the first one = contained in an AS_SEQUENCE) to be the origin. I suggest revising as = follows: Consider the origin AS to be the contents of the AS_SET if it's = a singleton set. Otherwise the origin cannot be determined. "Given that it's a corner case, you could also cut right to the chase = and just call it undetermined if the path starts (or ends, in your = parlance) with an AS_SET, period." > But the conversation spiraled from there. Evidently. What do those folk who have opinions on the topic think about the = following text as a definition: A route's "origin AS" is defined as follows: If the final path segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the first element of the sequence (i.e. the AS in the rightmost position with respect to the position of octets in the protocol message). If the final path segment of the AS_PATH is of type AS_SET, indicating that the route is an aggregate, then the origin AS is taken as the AS component of the AGGREGATOR attribute [RFC4271], if present. Otherwise, the route's origin=20 AS cannot be determined. Geoff