From Sandra.Murphy@cobham.com Tue Mar 1 09:07:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C343F3A69EA for ; Tue, 1 Mar 2011 09:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-uW4Y20ZQJM for ; Tue, 1 Mar 2011 09:07:46 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D88F33A69B2 for ; Tue, 1 Mar 2011 09:07:45 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p21H8mtV003656 for ; Tue, 1 Mar 2011 11:08:48 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p21H8muu014676 for ; Tue, 1 Mar 2011 11:08:48 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.124]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 12:08:46 -0500 Date: Tue, 1 Mar 2011 12:08:38 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 01 Mar 2011 17:08:47.0942 (UTC) FILETIME=[544C7660:01CBD833] Subject: [sidr] Important dates for IETF 80 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 17:07:46 -0000 Please keep the following dates in mind for the upcoming IETF. All the dates can be found at http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80. 2011-03-04 (Friday): Final agenda to be published. SIDR is presently scheduled for two sessions - THURSDAY, March 31, 2011 0900-1130 Morning Session I and FRIDAY, April 1, 2011 1300-1400 Afternoon Session I 1415-1515 Afternoon Session II (a two hour session scheduled as two one hour back-back sessions) 2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC) If you have intent to submit a wg -00 draft, you should be in communication with the wg chairs to make the process smoother. 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool. 2011-03-16 (Wednesday): Draft Working Group agendas due by 17:00 PT (01:00 Thursday, March 17 UTC), upload using IETF Meeting Materials Management Tool. 2011-03-18 (Friday): Early Bird registration and payment cut-off at 17:00 PT (01:00 Saturday, March 19 UTC). --Sandy, speaking of wg co-chair From jmh@joelhalpern.com Tue Mar 1 13:28:54 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7D33A6A24 for ; Tue, 1 Mar 2011 13:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWuW2zPZjWm9 for ; Tue, 1 Mar 2011 13:28:53 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id 806C23A6A16 for ; Tue, 1 Mar 2011 13:28:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C01D23246832; Tue, 1 Mar 2011 13:29:57 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-81.clppva.btas.verizon.net [71.161.51.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 33F20324544A; Tue, 1 Mar 2011 13:29:57 -0800 (PST) Message-ID: <4D6D6555.2090807@joelhalpern.com> Date: Tue, 01 Mar 2011 16:29:57 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:28:54 -0000 Randy, would you be willing to be wording like this, with your corrections, into section 1 of the document? Thank you, Joel On 2/26/2011 6:47 AM, Randy Bush wrote: >> o To prevent any advertiser from sending an advertisement that would >> cause other properly behaving parties to send traffic iin a way that >> they are not "entitled" to cause > > close, but i am not entirely comfortable with this > o we can not hope to prevent the advertisement, only detect it is > bogus. > o it is the bgp receiver's policy decision on where to send traffic. > a security researcher may specifically want to send traffic toward > a bogus announcement. > o i.e. 'cause' is too strong a word, perhaps 'lure' > > but you have the essential point > > randy > From Sandra.Murphy@cobham.com Tue Mar 1 13:58:34 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3772E3A6A24 for ; Tue, 1 Mar 2011 13:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ESJEVWLN4DL for ; Tue, 1 Mar 2011 13:58:33 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4DD8E3A6A16 for ; Tue, 1 Mar 2011 13:58:31 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p21LxZvD009291; Tue, 1 Mar 2011 15:59:35 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p21LxZQ8028667; Tue, 1 Mar 2011 15:59:35 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.124]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 16:59:34 -0500 Date: Tue, 1 Mar 2011 16:59:33 -0500 (Eastern Standard Time) From: Sandra Murphy To: "Joel M. Halpern" In-Reply-To: <4D6D6555.2090807@joelhalpern.com> Message-ID: References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> X-X-Sender: sandy@worf.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 01 Mar 2011 21:59:34.0886 (UTC) FILETIME=[F37CD860:01CBD85B] Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 21:58:34 -0000 On Tue, 1 Mar 2011, Joel M. Halpern wrote: > Randy, would you be willing to be wording like this, with your corrections, > into section 1 of the document? > > Thank you, > Joel > > On 2/26/2011 6:47 AM, Randy Bush wrote: >>> o To prevent any advertiser from sending an advertisement that would >>> cause other properly behaving parties to send traffic iin a way that >>> they are not "entitled" to cause Clarification here. "they" are not entitled to cause -- do you mean the "other properly behaving parties"? If you mean "any advertiser" the text should read "it is not entitled to cause" not "they". Not just a nit -- the difference changes the meaning. --Sandy >> >> close, but i am not entirely comfortable with this >> o we can not hope to prevent the advertisement, only detect it is >> bogus. >> o it is the bgp receiver's policy decision on where to send traffic. >> a security researcher may specifically want to send traffic toward >> a bogus announcement. >> o i.e. 'cause' is too strong a word, perhaps 'lure' >> >> but you have the essential point >> >> randy >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From jmh@joelhalpern.com Tue Mar 1 14:04:17 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB703A6AD2 for ; Tue, 1 Mar 2011 14:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 cnR-oaqeqQsK for ; Tue, 1 Mar 2011 14:04:16 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id BBA033A6AB8 for ; Tue, 1 Mar 2011 14:04:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0FF5A325AEF6; Tue, 1 Mar 2011 14:05:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-81.clppva.btas.verizon.net [71.161.51.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 0BA363254013; Tue, 1 Mar 2011 14:05:19 -0800 (PST) Message-ID: <4D6D6D9B.6020904@joelhalpern.com> Date: Tue, 01 Mar 2011 17:05:15 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sandra Murphy References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:04:17 -0000 Thanks Sandy. Yes, I mean "it", not "they". Thanks for catching that. Joel On 3/1/2011 4:59 PM, Sandra Murphy wrote: > > > On Tue, 1 Mar 2011, Joel M. Halpern wrote: > >> Randy, would you be willing to be wording like this, with your >> corrections, into section 1 of the document? >> >> Thank you, >> Joel >> >> On 2/26/2011 6:47 AM, Randy Bush wrote: >>>> o To prevent any advertiser from sending an advertisement that would >>>> cause other properly behaving parties to send traffic iin a way that >>>> they are not "entitled" to cause > > > Clarification here. "they" are not entitled to cause -- do you mean the > "other properly behaving parties"? If you mean "any advertiser" the text > should read "it is not entitled to cause" not "they". > > Not just a nit -- the difference changes the meaning. > > --Sandy > > > >>> >>> close, but i am not entirely comfortable with this >>> o we can not hope to prevent the advertisement, only detect it is >>> bogus. >>> o it is the bgp receiver's policy decision on where to send traffic. >>> a security researcher may specifically want to send traffic toward >>> a bogus announcement. >>> o i.e. 'cause' is too strong a word, perhaps 'lure' >>> >>> but you have the essential point >>> >>> randy >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > From randy@psg.com Tue Mar 1 14:14:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478AC3A6AC6 for ; Tue, 1 Mar 2011 14:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWGkkryjQjX6 for ; Tue, 1 Mar 2011 14:14:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 40C073A6AD2 for ; Tue, 1 Mar 2011 14:14:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PuXqo-0000HB-Gt; Tue, 01 Mar 2011 22:15:26 +0000 Date: Wed, 02 Mar 2011 07:15:25 +0900 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: <4D6D6555.2090807@joelhalpern.com> References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 22:14:25 -0000 > Randy, would you be willing to be wording like this, with your > corrections, into section 1 of the document? lemme try to reword it, but later in the day. >>> o To prevent any advertiser from sending an advertisement that would >>> cause other properly behaving parties to send traffic iin a way that >>> they are not "entitled" to cause >> >> close, but i am not entirely comfortable with this >> o we can not hope to prevent the advertisement, only detect it is >> bogus. >> o it is the bgp receiver's policy decision on where to send traffic. >> a security researcher may specifically want to send traffic toward >> a bogus announcement. >> o i.e. 'cause' is too strong a word, perhaps 'lure' >> >> but you have the essential point randy From randy@psg.com Tue Mar 1 15:06:35 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7043A6B20 for ; Tue, 1 Mar 2011 15:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 PvXjVVjhiLp8 for ; Tue, 1 Mar 2011 15:06:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 163F93A6B1B for ; Tue, 1 Mar 2011 15:06:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PuYfJ-0000RZ-Jd; Tue, 01 Mar 2011 23:07:38 +0000 Date: Wed, 02 Mar 2011 08:07:36 +0900 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:06:36 -0000 something like A BGPsec design MUST allow the receiver of an announcement to detect that one or more ASes on the AS-Path is attempting to lure the receiver into sending traffic in a way that an announcer is not entitled to receive. ? randy From jmh@joelhalpern.com Tue Mar 1 15:24:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504083A6B4E for ; Tue, 1 Mar 2011 15:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 N9X409LsUfwd for ; Tue, 1 Mar 2011 15:24:29 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id 9E8473A6B4D for ; Tue, 1 Mar 2011 15:24:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id EBD42325B282; Tue, 1 Mar 2011 15:25:33 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-81.clppva.btas.verizon.net [71.161.51.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 65BB53245B42; Tue, 1 Mar 2011 15:25:33 -0800 (PST) Message-ID: <4D6D806C.9010206@joelhalpern.com> Date: Tue, 01 Mar 2011 18:25:32 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Randy Bush References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:24:30 -0000 I think that would help, and it is good enough for me. Thank you, Joel On 3/1/2011 6:07 PM, Randy Bush wrote: > something like > > A BGPsec design MUST allow the receiver of an announcement to > detect that one or more ASes on the AS-Path is attempting to > lure the receiver into sending traffic in a way that an > announcer is not entitled to receive. > > ? > > randy > From randy@psg.com Tue Mar 1 15:29:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9793A6998 for ; Tue, 1 Mar 2011 15:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Adz4h3PH3c19 for ; Tue, 1 Mar 2011 15:29:04 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BC0DE3A6B2B for ; Tue, 1 Mar 2011 15:29:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PuZ15-0000Vm-5h; Tue, 01 Mar 2011 23:30:07 +0000 Date: Wed, 02 Mar 2011 08:30:06 +0900 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: <4D6D806C.9010206@joelhalpern.com> References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> <4D6D806C.9010206@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 23:29:04 -0000 actually, a bit more coffee inclines me toward an even more restrictive statement A BGPsec design MUST allow the receiver of an announcement to detect that one or more ASes on the AS-Path is attempting to lure the receiver into sending traffic to an incorrect next hop. randy From kotikalapudi.sriram@nist.gov Tue Mar 1 17:30:57 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8073A6A21 for ; Tue, 1 Mar 2011 17:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFXGx3t9VLGj for ; Tue, 1 Mar 2011 17:30:56 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 619CD3A6A30 for ; Tue, 1 Mar 2011 17:30:56 -0800 (PST) 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 p221Vl85026865; Tue, 1 Mar 2011 20:31:47 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 1 Mar 2011 20:31:45 -0500 From: "Sriram, Kotikalapudi" To: Andrew Lange Date: Tue, 1 Mar 2011 20:31:46 -0500 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvXx8WXx8A806HUTSu3sj4RoPtUAgAqSZqw Message-ID: References: <4D5E9FC6.4020404@cisco.com> <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <83D89ADA-16C7-494C-A3EA-21445829ABBB@alcatel-lucent.com> In-Reply-To: <83D89ADA-16C7-494C-A3EA-21445829ABBB@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 01:30:57 -0000 Andrew, Response inline. Sriram > -----Original Message----- > From: Andrew Lange [mailto:andrew.lange@alcatel-lucent.com] > > Sriram, > > Why would you accept a route de-aggregated by an upstream? If signed route-object says > AS_A owns and announces only the route 1.2.3.0/20 and I'm seeing 1.2.3.0/21 from AS_B, > the route filter should be configured not to accept more specifics. If AS_A wants to de- > aggregate, it can split it's route-objects into the more specifics and register them. > > Andrew I am sure you understand that ROA allows the prefix owner to register not only a prefix-origin pair (say, {1.2.0.0/20, AS_A}) but also a maxlength to allow any subprefixes (more specifics) that she may originate at times from the same AS_A. So the registered ROA info may look like {1.2.0.0/20, AS_A, maxlength = 22}. Then if AS_A needs to announce more specifics 1.2.0.0/21 and 1.2.8.0/21, it can readily do so while depending on the same ROA for validation. The reason for this may be traffic engineering, e.g., when AS_A is multihomed to two other upstream ASs, say, AS_X and AS_Y, then AS_A can announce more specifics 1.2.0.0/21 and 1.2.8.0/21 to AS_X and AS_Y with some clever prepending so that inbound traffic is equally distributed over the links from AS_X and AS_Y to AS_A. This is just one example of the usability of maxlength. Now as one can see, there are meaningful uses of maxlength for the legitimate originator, but then that opens the door for subprefix hijacks (with your proposed approach to securing partial path) as I explained before. Such subprefix hijacking would be detectable in a different approach, for example, if the whole update were signed including the NLRI (prefix) and AS_PATH (in addition to use of the normal ROA information). Sriram > > On Feb 24, 2011, at 3:51 PM, Sriram, Kotikalapudi wrote: > > > Andrew, > > > > Comment below. > > > > Sriram > > > >> -----Original Message----- > >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Andrew > Lange > >> Sent: Wednesday, February 23, 2011 6:17 PM > >> To: Sandra Murphy > >> Cc: sidr@ietf.org > >> Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work > >> > > --- snip --- > >> > >> From a work item perspective, it would be useful to have a relationship object signed > that > >> says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections." This > information, > >> combined with AS_A's signed route-objects means that downstream ASes would be able > to > >> verify that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, AS_B] or [AS_A, > >> AS_Q] would be AS PATHs that could be authorized. Effectively solving the Origin + > >> Upstream issue would solve most of the problems. Yes, someone could then spoof an > >> announcement of origin+upstream+self, but then we're looking at a minimum of a 3-AS > >> path and the likelihood of that being best drops. We can also do this with a simple > route- > >> filter and does not require on-system crypto calculations. > >> > >> Andrew > >> > > Yes, the path length goes up by 2. > > But normally an adversary would spoof an announcement with a subprefix (more > specific) > > of the prefix that the legitimate prefix owner has announced > > (while still trying to keep within the maxlength as specified in the ROA). > > I that case the increased path length would not matter. > > The spoofed announcement would be accepted and propagated widely. > > > > Sriram > > From ietfc@btconnect.com Wed Mar 2 01:31:27 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81D93A689A for ; Wed, 2 Mar 2011 01:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSSSaDvwd1Cp for ; Wed, 2 Mar 2011 01:31:27 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id CACF13A6846 for ; Wed, 2 Mar 2011 01:31:25 -0800 (PST) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2beaomr10.btconnect.com with SMTP id BWO06248; Wed, 02 Mar 2011 09:32:19 +0000 (GMT) Message-ID: <00cb01cbd8b3$b8be0e80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joel M. Halpern" , "Randy Bush" References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> <4D6D806C.9010206@joelhalpern.com> Date: Wed, 2 Mar 2011 09:27:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D6E0EA3.0105, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D6E0EA4.022D,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 09:31:28 -0000 ----- Original Message ----- From: "Joel M. Halpern" To: "Randy Bush" Cc: Sent: Wednesday, March 02, 2011 12:25 AM > I think that would help, and it is good enough for me. > Thank you, > Joel > > On 3/1/2011 6:07 PM, Randy Bush wrote: > > something like > > > > A BGPsec design MUST allow the receiver of an announcement to > > detect that one or more ASes on the AS-Path is attempting to > > lure the receiver into sending traffic in a way that an > > announcer is not entitled to receive. > > Worded like this, with the emphasis on the consequences, would seem to include such things as inserting spurious communities, as opposed to just modifying the AS-Path in an unacceptable way. Is that the intention? It is quite a shift from the focus of 10 days ago, which I read as solely securing the AS-Path, as opposed to anything else that might be in the advertisement. Tom Petch > > ? > > > > randy > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Wed Mar 2 02:03:36 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958003A672F for ; Wed, 2 Mar 2011 02:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 KqZ+VdtyWW3M for ; Wed, 2 Mar 2011 02:03:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 3467D3A6966 for ; Wed, 2 Mar 2011 02:03:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Puiud-0003Nk-9N; Wed, 02 Mar 2011 10:04:07 +0000 Date: Wed, 02 Mar 2011 19:04:05 +0900 Message-ID: From: Randy Bush To: "t.petch" In-Reply-To: <00cb01cbd8b3$b8be0e80$4001a8c0@gateway.2wire.net> References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> <4D6D806C.9010206@joelhalpern.com> <00cb01cbd8b3$b8be0e80$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 10:03:36 -0000 > Worded like this, with the emphasis on the consequences, would seem to > include such things as inserting spurious communities, as opposed to > just modifying the AS-Path in an unacceptable way. Is that the > intention? > > It is quite a shift from the focus of 10 days ago, which I read as > solely securing the AS-Path, as opposed to anything else that might be > in the advertisement. this is a good and possibly important point i missed. first, to be as clear as possible, here are the words as i now have them in my edit buffer. 3.1 A BGPsec design MUST allow the receiver of an announcement to detect that one or more ASes on the AS-Path is attempting to lure the receiver into sending traffic to an incorrect next hop. i could make it something like 3.1 A BGPsec design MUST allow the receiver of an announcement to detect that one or more ASes have manipulated the AS-Path in an attempt to lure the receiver into sending traffic to an incorrect next hop. whatcha think? randy From randy@psg.com Wed Mar 2 13:58:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE623A68BF for ; Wed, 2 Mar 2011 13:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 D0e4T84UTDhx for ; Wed, 2 Mar 2011 13:58:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 9C54B3A68BD for ; Wed, 2 Mar 2011 13:58:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Puu54-0005cR-Th; Wed, 02 Mar 2011 21:59:39 +0000 Date: Thu, 03 Mar 2011 06:59:37 +0900 Message-ID: From: Randy Bush To: "t.petch" In-Reply-To: References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> <4D6D806C.9010206@joelhalpern.com> <00cb01cbd8b3$b8be0e80$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:58:39 -0000 > i could make it something like > > 3.1 A BGPsec design MUST allow the receiver of an announcement to > detect that one or more ASes have manipulated the AS-Path in an > attempt to lure the receiver into sending traffic to an incorrect > next hop. in a private email, a friend pointed out that we neither know nor do we care why charlene falsified the path. the point is that we must be able to detect that she did. so the wording i think i'll go with is 3.1 A BGPsec design MUST allow the receiver of an announcement to detect that one or more routers have falsified the AS-Path. last chance for word-diddling. randy From Donald.Smith@qwest.com Wed Mar 2 14:02:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31603A6889 for ; Wed, 2 Mar 2011 14:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwdGQ8UXK+cg for ; Wed, 2 Mar 2011 14:02:29 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id CB5603A67D9 for ; Wed, 2 Mar 2011 14:02:29 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id p22M3Ikx028551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2011 16:03:18 -0600 (CST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id EB0DB1E0053; Wed, 2 Mar 2011 15:03:12 -0700 (MST) Received: from suomp60i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id BE4D81E0058; Wed, 2 Mar 2011 15:03:12 -0700 (MST) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id p22M338i001337; Wed, 2 Mar 2011 16:03:12 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 2 Mar 2011 15:03:01 -0700 From: "Smith, Donald" To: "'Randy Bush'" , "'t.petch'" Date: Wed, 2 Mar 2011 15:03:00 -0700 Thread-Topic: [sidr] SIDR ReCharter - to capture/cover path validation work Thread-Index: AcvZJSvfiDvZC3bHTAiGX/FHE9TdngAAC7tA Message-ID: References: <4D5EB53F.7080708@cisco.com> <4D6167A5.3080303@cisco.com> <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> <4D6D806C.9010206@joelhalpern.com> <00cb01cbd8b3$b8be0e80$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'sidr@ietf.org'" Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:02:30 -0000 Ignorance is Bliss. "Bliss (Basic Language for Implementation of System Sof= tware) was a systems programming language originally for the PDP-10 and DECsystem-20 wri= tten at CMU." K-Oberman Donald.Smith@qwest.com > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Randy Bush > Sent: Wednesday, March 02, 2011 3:00 PM > To: t.petch > Cc: sidr@ietf.org > Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation > work > > > i could make it something like > > > > 3.1 A BGPsec design MUST allow the receiver of an announcement to > > detect that one or more ASes have manipulated the AS-Path in > an > > attempt to lure the receiver into sending traffic to an > incorrect > > next hop. > > in a private email, a friend pointed out that we neither know nor do we > care why charlene falsified the path. the point is that we must be > able > to detect that she did. > > so the wording i think i'll go with is > > 3.1 A BGPsec design MUST allow the receiver of an announcement to > detect that one or more routers have falsified the AS-Path. Falsified or manipulated? The falsified implies someone is telling a lie while manipulated means they= changed elements for some reason right? I would lean towards manipulated or modified portions that they are not aut= horitative for or something along those lines. > > last chance for word-diddling. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From jmh@joelhalpern.com Wed Mar 2 14:24:14 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF283A68BD for ; Wed, 2 Mar 2011 14:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 UrqtiGmnIOlA for ; Wed, 2 Mar 2011 14:24:13 -0800 (PST) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by core3.amsl.com (Postfix) with ESMTP id 90A8E3A68B5 for ; Wed, 2 Mar 2011 14:24:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 900654300E2; Wed, 2 Mar 2011 14:25:20 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-81.clppva.btas.verizon.net [71.161.51.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B92534300D5; Wed, 2 Mar 2011 14:25:19 -0800 (PST) Message-ID: <4D6EC3D0.7030505@joelhalpern.com> Date: Wed, 02 Mar 2011 17:25:20 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Randy Bush References: <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> <4D6D806C.9010206@joelhalpern.com> <00cb01cbd8b3$b8be0e80$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:24:14 -0000 Unfortunately, that change shifts things just enough to miss an important part of what I was hoping to achieve. While it is true that we can not know why anyone does anything, the reason we care about it is that certain kinds of path falsification can result in traffic being lured to places that any reasonable model of authorization (not necessarily just the strict mathematical sense, but the more general operational sense) says it aught not go. The purpose of the whole exchange was to try to get a motivation into the picture, rather than just another assertion that we want to protect the AS path. There is no need for new text just saying "we are protecting the AS path because we are protecting the AS path." Yours, Joel On 3/2/2011 4:59 PM, Randy Bush wrote: >> i could make it something like >> >> 3.1 A BGPsec design MUST allow the receiver of an announcement to >> detect that one or more ASes have manipulated the AS-Path in an >> attempt to lure the receiver into sending traffic to an incorrect >> next hop. > > in a private email, a friend pointed out that we neither know nor do we > care why charlene falsified the path. the point is that we must be able > to detect that she did. > > so the wording i think i'll go with is > > 3.1 A BGPsec design MUST allow the receiver of an announcement to > detect that one or more routers have falsified the AS-Path. > > last chance for word-diddling. > > randy > From randy@psg.com Wed Mar 2 14:35:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5E93A68E7 for ; Wed, 2 Mar 2011 14:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 G0mhxyo3hnxU for ; Wed, 2 Mar 2011 14:35:01 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 096AA3A68E6 for ; Wed, 2 Mar 2011 14:35:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PuueM-0005l5-9s; Wed, 02 Mar 2011 22:36:06 +0000 Date: Thu, 03 Mar 2011 07:36:05 +0900 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: <4D6EC3D0.7030505@joelhalpern.com> References: <4D6264D5.70209@cisco.com> <792819CB-289E-4CC7-B994-9B66D3C49419@alcatel-lucent.com> <47741B75-6F2E-4EE7-9BA4-220BB7BDC40F@bgp.nu> <4D66B8F7.3010607@cisco.com> <2E7B797B-81F7-43FC-82DF-006110EBF611@bgp.nu> <4D67B856.5030400@cisco.com> <4D67BCB9.5060903@joelhalpern.com> <4D6D6555.2090807@joelhalpern.com> <4D6D806C.9010206@joelhalpern.com> <00cb01cbd8b3$b8be0e80$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:35:02 -0000 > While it is true that we can not know why anyone does anything > ... > The purpose of the whole exchange was to try to get a motivation into > the picture a conundrum wrapped in a cabbage leaf. the draft can not meet the desires of both directions here, and the new version needs to get out. being lazy, i will choose the simplest one for the moment and the discussion can continue. randy From Internet-Drafts@ietf.org Wed Mar 2 15:00:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519703A68F2; Wed, 2 Mar 2011 15:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxn0QsQy8Xbn; Wed, 2 Mar 2011 15:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68BD3A68F9; Wed, 2 Mar 2011 15:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110302230001.12595.24422.idtracker@localhost> Date: Wed, 02 Mar 2011 15:00:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-10.txt Pages : 22 Date : 2011-03-02 In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-02144821.I-D@ietf.org> --NextPart-- From christopher.morrow@gmail.com Thu Mar 3 19:38:22 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180893A6922; Thu, 3 Mar 2011 19:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7ydFHamnkw5; Thu, 3 Mar 2011 19:38:21 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5740C3A6925; Thu, 3 Mar 2011 19:38:17 -0800 (PST) Received: by wyb42 with SMTP id 42so1869906wyb.31 for ; Thu, 03 Mar 2011 19:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=rIOA/sk4MU3t2jtKh1mqo5OrbJLQNUiHfEvWSO3Q/v4=; b=ngOxB7XZODk53S6+HKPB2FfgPIbMyUuhjE0tPiCucbC5Zg92RhQ48geEmBazrq1Jds +ydDiY+wQOiXy6lByNY3raIrxYUdqTcqgN6xKFZDl+5AZjbxMZ1nMEDn1g6QitFrwyvh vvjCw8bK9zOnb96KhazhDZdgK7StAf7j4A9eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YW+q9e40eUMEE6Em7NAqNzw971ZJv8BC5NRV3EUtUbVZkxawLK4K7G5YpGIJEDL16s jKzedmQ/lkeduODIvvAx5TmhbU88ROZXlk5qpsr/YQ6SZ6DJlHHIHb6UPIvK7U6ra966 aE0jbcgm+ZlR0aJALqg9rE1AkHOGXIcc4cqHs= MIME-Version: 1.0 Received: by 10.216.181.199 with SMTP id l49mr126113wem.68.1299209964944; Thu, 03 Mar 2011 19:39:24 -0800 (PST) Received: by 10.216.1.197 with HTTP; Thu, 3 Mar 2011 19:39:24 -0800 (PST) Date: Thu, 3 Mar 2011 22:39:24 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Adrian Farrel , Stewart Bryant Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 03:38:22 -0000 Ok, so a lot (102 messages on-list) was said about the recharter text here: = = = = = = = = = Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the route update traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta ================== o Of that text, I noticed no argument about the dates/drafts/work-items, I noticed at least some discussion about the second vulnerability to address: (let's call it a goal for now) ---------------------------------------------------------- * Is the AS-Path represented in the route the same as the path through which the route update traveled ---------------------------------------------------------- A few folks noted that perhaps 'route' was not the right word here, perhaps NLRI is. Using a wikipedia definition: "Once a BGP session is running, the BGP speakers exchange UPDATE messages about destinations to which the speaker offers connectivity. In the protocol, the basic CIDR route description is called Network Layer Reachability Information (NLRI). NLRI includes the expected destination prefix, prefix length, path of autonomous systems to the destination and next hop in attributes, which can carry a wide range of additional information that affects the acceptance policy of the receiving router. BGP speakers incrementally announce new NLRI to which they offer reachability, but also announce withdrawals of prefixes to which the speaker no longer offers connectivity." This seems mostly correct, we don't actually want to secure something that changes per router-hop (potentially) - next-hop, but we do care about prefix/length/as-path. Taking that into account changes the goal to: ---------------------------------------------------------- * Is the AS-Path represented in the NLRI the same as the path through which the NLRI traveled ---------------------------------------------------------- o At least one respondent noted that some/all of the work here, as it affects the BGP specification will have to be seen/etc by IDR, I don't think the charter changes as proposed preclude that. I believe the intent was to pass along all changes to IDR to make sure they don't see issues with the changes. It's probably fair to also point out that the current IDR chair acks th two goals listed, but still the material relevant to IDR should go there for checkbox/changes/etc. -------------------------------------------------------------------------------------------------------------------- Given the above the new charter reads: = = = = = = = = = Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the NLRI the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta ================== This I'll send along to the IESG shortly. -Chris From randy@psg.com Thu Mar 3 21:48:34 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A67B3A6960; Thu, 3 Mar 2011 21:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 adu1Usf5nGal; Thu, 3 Mar 2011 21:48:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id D59B03A695E; Thu, 3 Mar 2011 21:48:32 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PvNtP-000GtS-Eb; Fri, 04 Mar 2011 05:49:36 +0000 Date: Fri, 04 Mar 2011 14:49:33 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 05:48:34 -0000 > A few folks noted that perhaps 'route' was not the right word here, > perhaps NLRI is. Using a wikipedia definition: apologies, but i just don't have the copious free time to descend to this level of nit picking. i say ship it. randy From ietfc@btconnect.com Fri Mar 4 04:03:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383373A6994 for ; Fri, 4 Mar 2011 04:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP+Unk1W84HL for ; Fri, 4 Mar 2011 04:03:41 -0800 (PST) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id 0135A3A68A2 for ; Fri, 4 Mar 2011 04:03:40 -0800 (PST) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2bthomr10.btconnect.com with SMTP id BYW05341; Fri, 04 Mar 2011 12:04:42 +0000 (GMT) Message-ID: <00c801cbda5b$5528afc0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joel M. Halpern" , "Randy Bush" References: <4D6EC3D0.7030505@joelhalpern.com> Date: Fri, 4 Mar 2011 11:58:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D70D54F.016E, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4D70D55C.01DB,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 12:03:42 -0000 ---- Original Message ----- From: "Joel M. Halpern" To: "Randy Bush" Cc: "t.petch" ; Sent: Wednesday, March 02, 2011 11:25 PM > Unfortunately, that change shifts things just enough to miss an > important part of what I was hoping to achieve. > While it is true that we can not know why anyone does anything, the > reason we care about it is that certain kinds of path falsification can > result in traffic being lured to places that any reasonable model of > authorization (not necessarily just the strict mathematical sense, but > the more general operational sense) says it aught not go. > > The purpose of the whole exchange was to try to get a motivation into > the picture, rather than just another assertion that we want to protect > the AS path. There is no need for new text just saying "we are > protecting the AS path because we are protecting the AS path." I am easy about motivation, whether it is there or not; I wanted to be clear about scope, AS_Path or everything in the advertisement which the modified wording is. I like Donald's addition so while I am content with what is suggested below, I would also go for " A BGPsec design MUST allow the receiver of an announcement to detect that one or more routers have modified the AS_Path in a way that they are not authorised to do ... " Leaving Joel to add something like " ...with the objective of causing traffic to be misdirected. And yes, I do think it is worth spending a few days on being clear in our words, as opposed to our thoughts:-) Tom Petch > Yours, > Joel > > On 3/2/2011 4:59 PM, Randy Bush wrote: > >> i could make it something like > >> > >> 3.1 A BGPsec design MUST allow the receiver of an announcement to > >> detect that one or more ASes have manipulated the AS-Path in an > >> attempt to lure the receiver into sending traffic to an incorrect > >> next hop. > > > > in a private email, a friend pointed out that we neither know nor do we > > care why charlene falsified the path. the point is that we must be able > > to detect that she did. > > > > so the wording i think i'll go with is > > > > 3.1 A BGPsec design MUST allow the receiver of an announcement to > > detect that one or more routers have falsified the AS-Path. > > > > last chance for word-diddling. > > > > randy > > From randy@psg.com Fri Mar 4 05:02:32 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD31D3A69C9 for ; Fri, 4 Mar 2011 05:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8e9zWbQQfxSy for ; Fri, 4 Mar 2011 05:02:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C9EBE3A677E for ; Fri, 4 Mar 2011 05:02:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PvUfQ-000ICN-Uu; Fri, 04 Mar 2011 13:03:37 +0000 Date: Fri, 04 Mar 2011 22:03:35 +0900 Message-ID: From: Randy Bush To: "t.petch" In-Reply-To: <00c801cbda5b$5528afc0$4001a8c0@gateway.2wire.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 13:02:32 -0000 the current, yet to be pushed, text is 3.1 A BGPsec design must allow the receiver of a BGP announcement to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of eBGP exchanges that propagated the NLRI from the origin AS to the receiver. discussion of intent is simply inappropriate, you can not know it. and we want to protect against path prevarication where there was no intent at all. bgp has so many wonderful knobs, such as the one to masquerade as a different asn. mistype it and ... randy From jmh@joelhalpern.com Fri Mar 4 12:22:47 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DF83A69BE for ; Fri, 4 Mar 2011 12:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 HVcyg0juMU6m for ; Fri, 4 Mar 2011 12:22:46 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id 7043E3A699F for ; Fri, 4 Mar 2011 12:22:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 41B07324542C; Fri, 4 Mar 2011 12:23:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-81.clppva.btas.verizon.net [71.161.51.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 993463228220; Fri, 4 Mar 2011 12:23:55 -0800 (PST) Message-ID: <4D714A5A.6060607@joelhalpern.com> Date: Fri, 04 Mar 2011 15:23:54 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 20:22:47 -0000 I agree that intent can not be known. Which is why I had asked that the motivation / intent related text be included in the introduction, not in the requirements. I was not trying to change the requirements. Rather, I am asking that the document include some context, to help the reader accurately understand the requirements. One can argue that formally that is irrelelvant. Based on history, it seems very useful to me. Yours, Joel On 3/4/2011 8:03 AM, Randy Bush wrote: > the current, yet to be pushed, text is > > 3.1 A BGPsec design must allow the receiver of a BGP announcement > to determine, to a strong level of certainty, that the received > PATH attribute accurately represents the sequence of eBGP > exchanges that propagated the NLRI from the origin AS to the > receiver. > > discussion of intent is simply inappropriate, you can not know it. and we > want to protect against path prevarication where there was no intent at > all. > > bgp has so many wonderful knobs, such as the one to masquerade as a > different asn. mistype it and ... > > randy > From russ@cisco.com Sat Mar 5 07:39:07 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0013A6A78; Sat, 5 Mar 2011 07:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L4H0kEDeOAQ; Sat, 5 Mar 2011 07:39:06 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8BD113A69DD; Sat, 5 Mar 2011 07:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=2216; q=dns/txt; s=iport; t=1299339617; x=1300549217; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Nj2UGy7JEHoGCPk2eR/kEllMEl+bfCz4GKoZe3gL2HQ=; b=aY7gugrc5yerA+hh6tAYkF4rcUHZ7Eu8xRoxw2DdDVhKhB2w9yvi9lo/ zJF67CgDxaUBNBfoyV2wd1hJ0y6LqJszCG1snMTXd4B0y1RmU3gxZ0gMg pp0uAC68UXhsXP2OKU5irOT/C6Y3gCPaQQpCz6HoMYalpUrac9BYqu1tg E=; X-Files: signature.asc : 259 X-IronPort-AV: E=Sophos;i="4.62,269,1297036800"; d="asc'?scan'208";a="222884298" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Mar 2011 15:40:17 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p25FeGFm011214; Sat, 5 Mar 2011 15:40:17 GMT Message-ID: <4D725949.5020205@cisco.com> Date: Sat, 05 Mar 2011 10:39:53 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Christopher Morrow References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD56FA36F86BDD3CDDCAE6917" Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 15:39:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD56FA36F86BDD3CDDCAE6917 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > The purpose of the SIDR working group is to reduce vulnerabilities in > the inter-domain routing system. The two vulnerabilities that will be > addressed are: >=20 > * Is an Autonomous System (AS) authorized to originate an IP prefix > * Is the AS-Path represented in the route the same as the path > through which the route update traveled I'm a bit confused --what happened with the discussion around Joels' wording? Is this supposed to be the final taking into account that discussion? I would suggest that trying to prove how an update came to be where it currently is isn't the underlying problem to be solved. Perhaps something like: * Is the AS-Path represented in the route a correct representation of the path to reach the destination, and does the AS Path correctly represent the intentions of the autonomous systems listed? Though I know some folks are going to say, "you can't prove intentions," when you get down to it, when you say, "prove the path the update took," you are, in reality, saying, "prove that everyone in the AS path intended to send the update," so these are the same thing. I'm also not certain I agree with Randy that it's a "nit" to use NLRI instead of "the update." The one is a bit of information, the other seems to imply a packet --and there is no end to end "update packet" in BGP --at least not that I know of. An update only exists point to point between two speakers, I think (?). :-) Russ --------------enigD56FA36F86BDD3CDDCAE6917 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1yWUwACgkQER27sUhU9OQiSgCgsWxxz993wUYxAsoDd7EcjN5t HCgAmwQ1fGsy4P78eJ44bHTcpjJUlJo9 =5a6A -----END PGP SIGNATURE----- --------------enigD56FA36F86BDD3CDDCAE6917-- From christopher.morrow@gmail.com Sat Mar 5 09:36:13 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9183A683B; Sat, 5 Mar 2011 09:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUzahiA4k9iN; Sat, 5 Mar 2011 09:36:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 063563A6A37; Sat, 5 Mar 2011 09:36:11 -0800 (PST) Received: by wwb22 with SMTP id 22so2799920wwb.13 for ; Sat, 05 Mar 2011 09:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=11DkBvYTof0UKl7fImf28Tj0zT1cJebZTg1jveQ68nE=; b=YJs5wZsENbfWRt7nxZFF6emz6j3pN36c/5vePuKPnKdKPzPLXs3vnTtmlZpIhfb3yw 1vxvtNmUvG1RE+nB7fnOZC+SzSn3TA3XXOJZ3KTQE6qMTO8GF/DubAjs40e4dFtAetIZ OHMJqERMccLcBzwKCSoZ66h5lDEyiiDPYxjSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GuNv4Uwk1taWuh2AChLsSiNXMvMFJ9ZTF1vKXYXshmFKl76BLsKTyhn5880/THP1nj VwfnGr8zHvir8gAlHyk1d+xCoy9EOsqTGWoO3iOnOeQUv1lVbosg6PN0Rjgy19/HZY+5 cAPGD9b616TfB1nX6+kqBHt07+H+lF549I/D8= MIME-Version: 1.0 Received: by 10.216.24.73 with SMTP id w51mr1580144wew.72.1299346642049; Sat, 05 Mar 2011 09:37:22 -0800 (PST) Received: by 10.216.82.74 with HTTP; Sat, 5 Mar 2011 09:37:22 -0800 (PST) In-Reply-To: <4D725949.5020205@cisco.com> References: <4D725949.5020205@cisco.com> Date: Sat, 5 Mar 2011 12:37:22 -0500 Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 17:36:13 -0000 On Sat, Mar 5, 2011 at 10:39 AM, Russ White wrote: > >> The purpose of the SIDR working group is to reduce vulnerabilities in >> the inter-domain routing system. The two vulnerabilities that will be >> addressed are: >> >> =A0 * Is an Autonomous System (AS) authorized to originate an IP prefix >> =A0 * Is the AS-Path represented in the route the same as the path >> =A0 =A0 =A0 =A0through which the route update traveled > > I'm a bit confused --what happened with the discussion around Joels' > wording? Is this supposed to be the final taking into account that > discussion? I would suggest that trying to prove how an update came to > be where it currently is isn't the underlying problem to be solved. > Perhaps something like: > It seemed that discussion, while in the thread about the recharter was actually about the reqs doc. > I'm also not certain I agree with Randy that it's a "nit" to use NLRI > instead of "the update." The one is a bit of information, the other > seems to imply a packet --and there is no end to end "update packet" in > BGP --at least not that I know of. An update only exists point to point > between two speakers, I think (?). that was why NLRI was used. (no end-to-end packet) From kotikalapudi.sriram@nist.gov Sun Mar 6 14:02:29 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD53C3A6879; Sun, 6 Mar 2011 14:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye7HLEo6lQfk; Sun, 6 Mar 2011 14:02:26 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id A2C313A6845; Sun, 6 Mar 2011 14:02:26 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p26M2qBD029059; Sun, 6 Mar 2011 17:02:52 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sun, 6 Mar 2011 17:02:52 -0500 From: "Sriram, Kotikalapudi" To: Christopher Morrow , "sidr@ietf.org" , "sidr-chairs@ietf.org" , Adrian Farrel , Stewart Bryant Date: Sun, 6 Mar 2011 17:02:51 -0500 Thread-Topic: [sidr] Last Draft: ReCharter text Thread-Index: AcvaHciFI52qli3dSu6ta/F41NPy4wCK1W9c Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 06 Mar 2011 22:02:30 -0000 Chris, There is also this WG document which is missing in your list: "Use cases and interpretation of RPKI objects for issuers and relying parties" http://tools.ietf.org/html/draft-ietf-sidr-usecases-01 Sriram ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Christopher Morrow [christopher.morrow@gmail.com] Sent: Thursday, March 03, 2011 10:39 PM To: sidr@ietf.org; sidr-chairs@ietf.org; Adrian Farrel; Stewart Bryant Subject: [sidr] Last Draft: ReCharter text Ok, so a lot (102 messages on-list) was said about the recharter text here: = = = = = = = = = Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the route update traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta ================== o Of that text, I noticed no argument about the dates/drafts/work-items, I noticed at least some discussion about the second vulnerability to address: (let's call it a goal for now) ---------------------------------------------------------- * Is the AS-Path represented in the route the same as the path through which the route update traveled ---------------------------------------------------------- A few folks noted that perhaps 'route' was not the right word here, perhaps NLRI is. Using a wikipedia definition: "Once a BGP session is running, the BGP speakers exchange UPDATE messages about destinations to which the speaker offers connectivity. In the protocol, the basic CIDR route description is called Network Layer Reachability Information (NLRI). NLRI includes the expected destination prefix, prefix length, path of autonomous systems to the destination and next hop in attributes, which can carry a wide range of additional information that affects the acceptance policy of the receiving router. BGP speakers incrementally announce new NLRI to which they offer reachability, but also announce withdrawals of prefixes to which the speaker no longer offers connectivity." This seems mostly correct, we don't actually want to secure something that changes per router-hop (potentially) - next-hop, but we do care about prefix/length/as-path. Taking that into account changes the goal to: ---------------------------------------------------------- * Is the AS-Path represented in the NLRI the same as the path through which the NLRI traveled ---------------------------------------------------------- o At least one respondent noted that some/all of the work here, as it affects the BGP specification will have to be seen/etc by IDR, I don't think the charter changes as proposed preclude that. I believe the intent was to pass along all changes to IDR to make sure they don't see issues with the changes. It's probably fair to also point out that the current IDR chair acks th two goals listed, but still the material relevant to IDR should go there for checkbox/changes/etc. -------------------------------------------------------------------------------------------------------------------- Given the above the new charter reads: = = = = = = = = = Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the NLRI the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta ================== This I'll send along to the IESG shortly. -Chris _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Sun Mar 6 16:26:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9253A68A9 for ; Sun, 6 Mar 2011 16:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi9F11XNO7R8 for ; Sun, 6 Mar 2011 16:26:18 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 9AC773A677E for ; Sun, 6 Mar 2011 16:26:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PwOIJ-000LZx-BS; Mon, 07 Mar 2011 00:27:27 +0000 Date: Mon, 07 Mar 2011 09:27:24 +0900 Message-ID: From: Randy Bush To: "Joel M. Halpern" In-Reply-To: <4D714A5A.6060607@joelhalpern.com> References: <4D714A5A.6060607@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 00:26:19 -0000 > I agree that intent can not be known. > > Which is why I had asked that the motivation / intent related text be > included in the introduction, not in the requirements. i have done so in the yet-to-be-released version 3.19 A BGPsec design SHOULD NOT presume to know the intent of the origintor of a NLRI, nor that of any AS on the AS Path. cool? randy From christopher.morrow@gmail.com Sun Mar 6 19:23:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD223A67CC; Sun, 6 Mar 2011 19:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vbGjJgzXtkS; Sun, 6 Mar 2011 19:23:35 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 21E453A6827; Sun, 6 Mar 2011 19:23:34 -0800 (PST) Received: by wyb42 with SMTP id 42so4146049wyb.31 for ; Sun, 06 Mar 2011 19:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kIdTxMtTupYn4mJv7iUEUmEpuBoQ4a/qKW1h5j6XII8=; b=d6FsEoSkRoAvPTovwuH9ysa+WgPX7Du9/2uUOQiujGY3ZvmcsjvOdjLn1UKuXuhYCp gE7QTbZCuy5N6c67bLZXEcpZrgQguxK0HTGNIw7vQD95dIOJ9weyw9p4nJq3dwKFCAHt DQAMiwEYHJvEpDEovllAoxrCWG89TBaxvBC2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VSO3Ezgm90qAZ5bezmixu1NOgwou3S/hLmoHYjiBCLazHURddTqVNbxxSuiwwg4JcA eAAcQf++RnhzrbznpxnXMmz8cjpjWyQr8Df9fVXgjknKBZSzgPqVWs3dQp3OL8fw4uVI QAuyIMX2LchcQdNNGOnxa6Ao8i5/XUK697E1Q= MIME-Version: 1.0 Received: by 10.216.221.76 with SMTP id q54mr1510363wep.73.1299468287359; Sun, 06 Mar 2011 19:24:47 -0800 (PST) Received: by 10.216.82.74 with HTTP; Sun, 6 Mar 2011 19:24:47 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Mar 2011 22:24:47 -0500 Message-ID: From: Christopher Morrow To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr-chairs@ietf.org" , Adrian Farrel , "sidr@ietf.org" Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 03:23:37 -0000 On Sun, Mar 6, 2011 at 5:02 PM, Sriram, Kotikalapudi wrote: > Chris, > > There is also this WG document which is missing in your list: > "Use cases and interpretation of RPKI objects for issuers and relying par= ties" > http://tools.ietf.org/html/draft-ietf-sidr-usecases-01 easy enough to add. thanks! (notethat I hadn't heard back from either of the ADs yet, I expect they'll say something in the next few days) -Chris ___________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Christop= her Morrow [christopher.morrow@gmail.com] > Sent: Thursday, March 03, 2011 10:39 PM > To: sidr@ietf.org; sidr-chairs@ietf.org; Adrian Farrel; Stewart Bryant > Subject: [sidr] Last Draft: ReCharter text > > Ok, so a lot (102 messages on-list) was said about the recharter text her= e: > > =3D =3D =3D =3D =3D =3D =3D =3D =3D > > Description of Working Group: > > The purpose of the SIDR working group is to reduce vulnerabilities in > the inter-domain routing system. The two vulnerabilities that will be > addressed are: > > =A0* Is an Autonomous System (AS) authorized to originate an IP prefix > =A0* Is the AS-Path represented in the route the same as the path > =A0 =A0 =A0 through which the route update traveled > > The SIDR working group will take practical deployability into considerati= on. > > Building upon the already completed and implemented framework: > > =A0* Resource Public Key Infrastructure (RPKI) > =A0* Distribution of RPKI data to routing devices and its use in > =A0 =A0 =A0 operational networks > =A0* Document the use of certification objects within the secure > =A0 =A0 =A0 routing architecture > > > This working group will specify security enhancements for inter-domain > routing protocols. > > The SIDR working group is charged with the following goals and > milestones: > ID Date =A0 =A0 =A0Pub Date > Mar 2011 =A0 Jan 2012 =A0An overview of the RPKI and BGP Protocol changes > required for origin and path validation > Mar 2011 =A0 Jun 2012 =A0A document describing threats to the routing sys= tem > Mar 2011 =A0 Jun 2012 =A0A requirements document that =A0addresses these = threats > Mar2011 =A0 =A0Jan 2012 =A0Document the BGP protocol enhancements that me= et > the security requirements > Nov 2010 =A0 =A0Jul 2011 =A0 draft-ietf-sidr-origin-ops > Mar 2011 =A0 Jul 2012 =A0 Operational deployment guidance for network ope= rators > Jun 2011 =A0 =A0Dec 2011 System and architecture design choices made in > the protocol and RPKI > Mar 2010 =A0 =A0Mar 2012 =A0 draft-ietf-sidr-cps-irs > Mar 2010 =A0 =A0Mar 2012 =A0 draft-ietf-sidr-cps-isp > Nov 2010 =A0 =A0Jan 2012 =A0 draft-ietf-sidr-pfx-validate > Jan 2010 =A0 =A0Jun 2011 =A0 =A0draft-ietf-sidr-publication > Nov 2010 =A0 =A0Jun 2011 =A0 draft-ietf-sidr-repos-struct > Nov 2010 =A0 =A0Jun 2011 =A0 draft-ietf-sidr-roa-format > Feb 2011 =A0 =A0Jun 2011 =A0 =A0draft-ietf-sidr-rpki-rtr > Nov 2010 =A0 =A0Nov 2011 =A0 draft-ietf-sidr-ltamgmt > Dec 2010 =A0 =A0Oct 2011 =A0 draft-rgaglian-sidr-algorithm-agility > Jan 2011 =A0 =A0Oct 2011 =A0 draft-ietf-sidr-ghostbusters > Jan 2010 =A0 =A0Dec 2011 =A0 draft-ietf-sidr-keyroll > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-arch > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-cp > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-res-certs > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-roa-validation > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-signed-object > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-rpki-manifests > Jan 2010 =A0 =A0Jul 2011 =A0draft-ietf-sidr-rpki-algs > Jan 2010 =A0 =A0Jul 2011 =A0draft-ietf-sidr-rescerts-provisioning > Jan 2010 =A0 =A0Aug 2011 =A0draft-ietf-sidr-ta > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > o Of that text, I noticed no argument about the > dates/drafts/work-items, I noticed at least some > =A0 discussion about the second vulnerability to address: (let's call > it a goal for now) > > ---------------------------------------------------------- > =A0* Is the AS-Path represented in the route the same as the path > =A0 =A0 =A0 through which the route update traveled > ---------------------------------------------------------- > > A few folks noted that perhaps 'route' was not the right word here, > perhaps NLRI is. Using a wikipedia definition: > "Once a BGP session is running, the BGP speakers exchange UPDATE > messages about destinations to which the speaker offers connectivity. > In the protocol, the basic CIDR route description is called Network > Layer Reachability Information (NLRI). NLRI includes the expected > destination prefix, prefix length, path of autonomous systems to the > destination and next hop in attributes, which can carry a wide range > of additional information that affects the acceptance policy of the > receiving router. BGP speakers incrementally announce new NLRI to > which they offer reachability, but also announce withdrawals of > prefixes to which the speaker no longer offers connectivity." > > This seems mostly correct, we don't actually want to secure something > that changes per router-hop (potentially) - next-hop, but we do care > about prefix/length/as-path. Taking that into account changes the goal > to: > > > ---------------------------------------------------------- > * Is the AS-Path represented in the NLRI the same as the path through > which the NLRI traveled > ---------------------------------------------------------- > > o At least one respondent noted that some/all of the work here, as it > affects the > =A0 BGP specification will have to be seen/etc by IDR, I don't think the = charter > =A0 changes as proposed preclude that. I believe the intent was to pass > along all > =A0 changes to IDR to make sure they don't see issues with the changes. I= t's > =A0 probably fair to also point out that the current IDR chair acks th > two goals listed, > =A0 but still the material relevant to IDR should go there for > checkbox/changes/etc. > > -------------------------------------------------------------------------= ------------------------------------------- > Given the above the new charter reads: > > > =3D =3D =3D =3D =3D =3D =3D =3D =3D > > Description of Working Group: > > The purpose of the SIDR working group is to reduce vulnerabilities in > the inter-domain routing system. The two vulnerabilities that will be > addressed are: > > =A0* Is an Autonomous System (AS) authorized to originate an IP prefix > =A0* Is the AS-Path represented in the NLRI the same as the path > =A0 =A0 through which the NLRI traveled > > The SIDR working group will take practical deployability into considerati= on. > > Building upon the already completed and implemented framework: > > =A0* Resource Public Key Infrastructure (RPKI) > =A0* Distribution of RPKI data to routing devices and its use in > =A0 =A0 =A0 operational networks > =A0* Document the use of certification objects within the secure > =A0 =A0 =A0 routing architecture > > > This working group will specify security enhancements for inter-domain > routing protocols. > > The SIDR working group is charged with the following goals and > milestones: > ID Date =A0 =A0 =A0Pub Date > Mar 2011 =A0 Jan 2012 =A0An overview of the RPKI and BGP Protocol changes > required for origin and path validation > Mar 2011 =A0 Jun 2012 =A0A document describing threats to the routing sys= tem > Mar 2011 =A0 Jun 2012 =A0A requirements document that =A0addresses these = threats > Mar2011 =A0 =A0Jan 2012 =A0Document the BGP protocol enhancements that me= et > the security requirements > Nov 2010 =A0 =A0Jul 2011 =A0 draft-ietf-sidr-origin-ops > Mar 2011 =A0 Jul 2012 =A0 Operational deployment guidance for network ope= rators > Jun 2011 =A0 =A0Dec 2011 System and architecture design choices made in > the protocol and RPKI > Mar 2010 =A0 =A0Mar 2012 =A0 draft-ietf-sidr-cps-irs > Mar 2010 =A0 =A0Mar 2012 =A0 draft-ietf-sidr-cps-isp > Nov 2010 =A0 =A0Jan 2012 =A0 draft-ietf-sidr-pfx-validate > Jan 2010 =A0 =A0Jun 2011 =A0 =A0draft-ietf-sidr-publication > Nov 2010 =A0 =A0Jun 2011 =A0 draft-ietf-sidr-repos-struct > Nov 2010 =A0 =A0Jun 2011 =A0 draft-ietf-sidr-roa-format > Feb 2011 =A0 =A0Jun 2011 =A0 =A0draft-ietf-sidr-rpki-rtr > Nov 2010 =A0 =A0Nov 2011 =A0 draft-ietf-sidr-ltamgmt > Dec 2010 =A0 =A0Oct 2011 =A0 draft-rgaglian-sidr-algorithm-agility > Jan 2011 =A0 =A0Oct 2011 =A0 draft-ietf-sidr-ghostbusters > Jan 2010 =A0 =A0Dec 2011 =A0 draft-ietf-sidr-keyroll > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-arch > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-cp > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-res-certs > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-roa-validation > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-signed-object > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-rpki-manifests > Jan 2010 =A0 =A0Jul 2011 =A0draft-ietf-sidr-rpki-algs > Jan 2010 =A0 =A0Jul 2011 =A0draft-ietf-sidr-rescerts-provisioning > Jan 2010 =A0 =A0Aug 2011 =A0draft-ietf-sidr-ta > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > This I'll send along to the IESG shortly. > > -Chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From jgs@bgp.nu Mon Mar 7 05:57:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB2583A69A3; Mon, 7 Mar 2011 05:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XDUTdY9ag1v; Mon, 7 Mar 2011 05:57:19 -0800 (PST) Received: from bgp.nu (bgp.nu [216.117.214.198]) by core3.amsl.com (Postfix) with ESMTP id 2DA223A696B; Mon, 7 Mar 2011 05:57:19 -0800 (PST) Received: from jgs-sslvpn-nc.jnpr.net (nat-service4.juniper.net [66.129.225.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id BADA21614755; Mon, 7 Mar 2011 08:58:29 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: Date: Mon, 7 Mar 2011 15:58:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56961247-F5A1-4333-9540-99F29721A3E1@bgp.nu> References: To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 13:57:20 -0000 On Mar 4, 2011, at 5:39 AM, Christopher Morrow wrote: ... > A few folks noted that perhaps 'route' was not the right word here, > perhaps NLRI is. Using a wikipedia definition: I love Wikipedia, but the quoted definition is wrong, at least with = respect to the definitions given in RFC 4271: 1.1. Definition of Commonly Used Terms ... NLRI Network Layer Reachability Information. Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message. The path is the information reported in the path attributes field of the same UPDATE message. Given that what we're talking about securing is BGP, it would seem = sensible to use BGP's terminology. Given that, the text as written = seems right to me: ---------------------------------------------------------- * Is the AS-Path represented in the route the same as the path through which the route update traveled ---------------------------------------------------------- or if you insist perhaps ---------------------------------------------------------- * Is the AS-Path represented in the route the same as the path through which the NLRI traveled ---------------------------------------------------------- But if this is the biggest nit we have to pick then I'll agree with = "ship it". By the way, which Wikipedia article were you quoting, so I can think = about fixing it in my CFT? ... > but still the material relevant to IDR should go there for = checkbox/changes/etc. Yes. Speaking for myself I don't have a problem with progressing this = work in SIDR for the time being given that there is energy and expertise = to do it here. We can reshuffle deck chairs in the future as seems = warranted, and in any case should have review by both groups no matter = which WG the work is done in. --John= From randy@psg.com Mon Mar 7 14:45:38 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24363A69C4; Mon, 7 Mar 2011 14:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej0A7af+nDgR; Mon, 7 Mar 2011 14:45:38 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 1094E28C0EF; Mon, 7 Mar 2011 14:45:36 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PwjCN-0000b4-Uf; Mon, 07 Mar 2011 22:46:44 +0000 Date: Tue, 08 Mar 2011 07:46:42 +0900 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: <56961247-F5A1-4333-9540-99F29721A3E1@bgp.nu> References: <56961247-F5A1-4333-9540-99F29721A3E1@bgp.nu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Christopher Morrow , sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 22:45:38 -0000 > I love Wikipedia, but the quoted definition is wrong, at least with > respect to the definitions given in RFC 4271: so edit it randy From christopher.morrow@gmail.com Mon Mar 7 18:12:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCAF73A68D6; Mon, 7 Mar 2011 18:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.286 X-Spam-Level: X-Spam-Status: No, score=-103.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fACfno-d20fg; Mon, 7 Mar 2011 18:12:48 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 99C593A688B; Mon, 7 Mar 2011 18:12:47 -0800 (PST) Received: by wwa36 with SMTP id 36so141821wwa.13 for ; Mon, 07 Mar 2011 18:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a0VewltDZZ+9xCt+dOuhv6DFXPfLqPFaGaquCxnRvYk=; b=NtgUNMsBy3dS8dK/rmM+oyjGT4AprMuGf121g0PEccO00YlrPWZw+bU6hnKwiiOhaW XQ4k9tPl9/0xMQKWqqCCC23FmJ8VB6e2W+cdM2AFLblyX3550aA566I00A3FI5hg1lnD HFpBuy76CinwJMcEFtUcwFZ2VcLX+8s0MPr/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Z5uWHfQPRWyic3X9xhkSk+erGEaQEvpzxBsDE+Ak00RoBaFzZ4/lvkaC4SJ0exUInv aX4W8F83MIaqg6sSeubE2KhAhj4h3s0xQ0tvPyQGB8ixtiT7FKzBSTytE0yyQMgvpwwi sSeprVFk6R7ToKAC322xL6ljkKy3UURbSQUD8= MIME-Version: 1.0 Received: by 10.216.160.129 with SMTP id u1mr2908744wek.88.1299550440920; Mon, 07 Mar 2011 18:14:00 -0800 (PST) Received: by 10.216.82.74 with HTTP; Mon, 7 Mar 2011 18:14:00 -0800 (PST) In-Reply-To: <56961247-F5A1-4333-9540-99F29721A3E1@bgp.nu> References: <56961247-F5A1-4333-9540-99F29721A3E1@bgp.nu> Date: Mon, 7 Mar 2011 21:14:00 -0500 Message-ID: From: Christopher Morrow To: "John G. Scudder" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-chairs@ietf.org, Adrian Farrel , sidr@ietf.org Subject: Re: [sidr] Last Draft: ReCharter text X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 02:12:49 -0000 On Mon, Mar 7, 2011 at 8:58 AM, John G. Scudder wrote: > On Mar 4, 2011, at 5:39 AM, Christopher Morrow wrote: > ... >> A few folks noted that perhaps 'route' was not the right word here, >> perhaps NLRI is. Using a wikipedia definition: > > I love Wikipedia, but the quoted definition is wrong, at least with respe= ct to the definitions given in RFC 4271: I looked for the best rfc definition, missed 4271 :( In the end I was looking for the set of terms closest to what would be expected in the IDR/SIDR/routing-protocols-implementors world. > 1.1. =A0Definition of Commonly Used Terms > > ... > > =A0 NLRI > =A0 =A0 =A0Network Layer Reachability Information. > > =A0 Route > =A0 =A0 =A0A unit of information that pairs a set of destinations with th= e > =A0 =A0 =A0attributes of a path to those destinations. =A0The set of > =A0 =A0 =A0destinations are systems whose IP addresses are contained in o= ne > =A0 =A0 =A0IP address prefix carried in the Network Layer Reachability > =A0 =A0 =A0Information (NLRI) field of an UPDATE message. =A0The path is = the > =A0 =A0 =A0information reported in the path attributes field of the same > =A0 =A0 =A0UPDATE message. > > Given that what we're talking about securing is BGP, it would seem sensib= le to use BGP's terminology. =A0Given that, the text as written seems right= to me: > > ---------------------------------------------------------- > * Is the AS-Path represented in the route the same as the path > =A0 =A0 =A0through which the route update traveled > ---------------------------------------------------------- > > or if you insist perhaps > > ---------------------------------------------------------- > * Is the AS-Path represented in the route the same as the path through > which the NLRI traveled > ---------------------------------------------------------- The original poster's note was an attempt, I think, to convey the fact that a 'route' (prefix + path + attributes) was not actually whole across all of the path. each bgp speaker it hopped through made some judgment and added or subtracted bits to the 'route'. NLRI seemed to capture just the prefix+path part of the 'route', which ideally should not change at each hop (aside from having an AS added to the path). The second form you have seems to keep that idea in tact. > But if this is the biggest nit we have to pick then I'll agree with "ship= it". yes... going to the AD's + list + housely now. thanks! -chris > By the way, which Wikipedia article were you quoting, so I can think abou= t fixing it in my CFT? > > ... >> =A0 but still the material relevant to IDR should go there for checkbox/= changes/etc. > > Yes. =A0Speaking for myself I don't have a problem with progressing this = work in SIDR for the time being given that there is energy and expertise to= do it here. =A0We can reshuffle deck chairs in the future as seems warrant= ed, and in any case should have review by both groups no matter which WG th= e work is done in. > > --John From christopher.morrow@gmail.com Mon Mar 7 18:17:33 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BB73A69ED; Mon, 7 Mar 2011 18:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jALxrFXMyJ-B; Mon, 7 Mar 2011 18:17:32 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 017593A68D6; Mon, 7 Mar 2011 18:17:31 -0800 (PST) Received: by wwa36 with SMTP id 36so145330wwa.13 for ; Mon, 07 Mar 2011 18:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=ZGjRw8K3HTJyZIsvWZMbMdOINJuvae+rp5Vu+pa5FTc=; b=C4kwfoIhv+NC8ijSTaefUdzGMgLHq51vlAe/hIfvnnw5HiIIouu+YtrORQ5428bEqq TB5CdiLlni70Rp/DadFaUL4+yVpSmjIUkaJBBfA/IIhoLTvN39GcX11dee38alNSqL78 hkhggMtpgDsDwpX6usVj+aaRrAbjhsfM8y/ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WKGrRcD6LU0mLhiT/i6sCG6wm5zvbyGd39XQdnKQHJcf8ucyhKLqEQSeWsbdoiBPBE V532dMYS8jdqmjUkghlp0oJ/1M3nRAbGS3lPjqghJkFvsVApVT6ueEVhQ24Xpo7pOnfs EdkjJZEM4IM0W/UhixNfFCPKwM7/Z4Sv5ivo8= MIME-Version: 1.0 Received: by 10.216.221.76 with SMTP id q54mr2574376wep.73.1299550725692; Mon, 07 Mar 2011 18:18:45 -0800 (PST) Received: by 10.216.82.74 with HTTP; Mon, 7 Mar 2011 18:18:45 -0800 (PST) Date: Mon, 7 Mar 2011 21:18:45 -0500 Message-ID: From: Christopher Morrow To: Adrian Farrel , Stewart Bryant , sidr@ietf.org, sidr-chairs@ietf.org, Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] Please re-charter SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 02:17:33 -0000 Howdy AD folk, Please re-charter sidr with the new text included below. Some 103+ messages on-list boiled the original into what is now a more cogent charter. thanks! -Chris co-chair-weeble-wobble ------------------------------------ included text goes here --------------------------------------------- Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility May 2011 Dec 2011 draft-ietf-sidr-usecases Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta ------------------------------------ end included text ------------------------------------------------------ From christopher.morrow@gmail.com Mon Mar 7 18:21:35 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23DFA3A67B1; Mon, 7 Mar 2011 18:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysLuY5busJXF; Mon, 7 Mar 2011 18:21:32 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B98373A680B; Mon, 7 Mar 2011 18:21:31 -0800 (PST) Received: by wwa36 with SMTP id 36so148236wwa.13 for ; Mon, 07 Mar 2011 18:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=3kNcjJnfI5Krf9ja7Ss0KF9x5mzbWzitLQK/5HlywPg=; b=SEfgOwcu4Q/nuwg6BAdnTpQ6NtW3/WYVdkcoSzxvIBCKHozMeuqg4mrO0ZOj2LyCuR KE/KhVd+hpVeOVwhvup+WB8OX7A44sYChrPLu4YkMoyconB7l1wH1WXwHhb+NHmlekfE w0AjmqKeGf3Epx3mUQUcm2QAqUVRxhyWvAAUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=CA3JRv2766uSF/6xCjZd1kI//jo0LBafhjmnBmSVUg0N/sXFS18NFdf5DGVedXDyIF CMNfmR2TLV+z0Je++J0A4mNWonTutg7scA7DYQNOeR03gfuPV7JGVWe8CwOZ84z0xz3s u0vs4gCPOR6K2haROBoYftnAAEYnOkwGswPiY= MIME-Version: 1.0 Received: by 10.216.183.148 with SMTP id q20mr3907031wem.88.1299550965475; Mon, 07 Mar 2011 18:22:45 -0800 (PST) Received: by 10.216.82.74 with HTTP; Mon, 7 Mar 2011 18:22:45 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Mar 2011 21:22:45 -0500 Message-ID: From: Christopher Morrow To: Adrian Farrel , Stewart Bryant , sidr@ietf.org, sidr-chairs@ietf.org, Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] Please re-charter SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 02:21:35 -0000 (note fix to Roque's doc - algorithm-agility) On Mon, Mar 7, 2011 at 9:18 PM, Christopher Morrow wrote: > Howdy AD folk, > Please re-charter sidr with the new text included below. Some 103+ > messages on-list boiled the original into what is now a more cogent > charter. > > thanks! > -Chris > co-chair-weeble-wobble > > ------------------------------------ included text goes here > --------------------------------------------- > Description of Working Group: > > The purpose of the SIDR working group is to reduce vulnerabilities in > the inter-domain routing system. The two vulnerabilities that will be > addressed are: > > =A0* Is an Autonomous System (AS) authorized to originate an IP prefix > =A0* Is the AS-Path represented in the route the same as the path through > =A0 =A0which the NLRI traveled > > The SIDR working group will take practical deployability into considerati= on. > > Building upon the already completed and implemented framework: > > =A0* Resource Public Key Infrastructure (RPKI) > =A0* Distribution of RPKI data to routing devices and its use in > =A0 =A0 =A0operational networks > =A0* Document the use of certification objects within the secure > =A0 =A0 =A0routing architecture > > > This working group will specify security enhancements for inter-domain > routing protocols. > > The SIDR working group is charged with the following goals and > milestones: > ID Date =A0 =A0 =A0Pub Date > Mar 2011 =A0 Jan 2012 =A0An overview of the RPKI and BGP Protocol changes > required for origin and path validation > Mar 2011 =A0 Jun 2012 =A0A document describing threats to the routing sys= tem > Mar 2011 =A0 Jun 2012 =A0A requirements document that =A0addresses these = threats > Mar2011 =A0 =A0Jan 2012 =A0Document the BGP protocol enhancements that me= et > the security requirements > Nov 2010 =A0 =A0Jul 2011 =A0 draft-ietf-sidr-origin-ops > Mar 2011 =A0 Jul 2012 =A0 Operational deployment guidance for network ope= rators > Jun 2011 =A0 =A0Dec 2011 System and architecture design choices made in > the protocol and RPKI > Mar 2010 =A0 =A0Mar 2012 =A0 draft-ietf-sidr-cps-irs > Mar 2010 =A0 =A0Mar 2012 =A0 draft-ietf-sidr-cps-isp > Nov 2010 =A0 =A0Jan 2012 =A0 draft-ietf-sidr-pfx-validate > Jan 2010 =A0 =A0Jun 2011 =A0 =A0draft-ietf-sidr-publication > Nov 2010 =A0 =A0Jun 2011 =A0 draft-ietf-sidr-repos-struct > Nov 2010 =A0 =A0Jun 2011 =A0 draft-ietf-sidr-roa-format > Feb 2011 =A0 =A0Jun 2011 =A0 =A0draft-ietf-sidr-rpki-rtr > Nov 2010 =A0 =A0Nov 2011 =A0 draft-ietf-sidr-ltamgmt > Dec 2010 =A0 =A0Oct 2011 =A0 draft-ietf-sidr-algorithm-agility > May 2011 =A0 =A0Dec 2011 =A0draft-ietf-sidr-usecases > Jan 2011 =A0 =A0Oct 2011 =A0 draft-ietf-sidr-ghostbusters > Jan 2010 =A0 =A0Dec 2011 =A0 draft-ietf-sidr-keyroll > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-arch > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-cp > Jan 2010 =A0 =A0May 2011 =A0draft-ietf-sidr-res-certs > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-roa-validation > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-signed-object > Jan 2010 =A0 =A0Jun 2011 =A0draft-ietf-sidr-rpki-manifests > Jan 2010 =A0 =A0Jul 2011 =A0draft-ietf-sidr-rpki-algs > Jan 2010 =A0 =A0Jul 2011 =A0draft-ietf-sidr-rescerts-provisioning > Jan 2010 =A0 =A0Aug 2011 =A0draft-ietf-sidr-ta > > ------------------------------------ end included text > ------------------------------------------------------ > From iesg-secretary@ietf.org Tue Mar 8 06:30:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CA53A68F7; Tue, 8 Mar 2011 06:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHIx5I+mTr2Y; Tue, 8 Mar 2011 06:30:45 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C26A3A67B7; Tue, 8 Mar 2011 06:30:45 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110308143045.25501.59458.idtracker@localhost> Date: Tue, 08 Mar 2011 06:30:45 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Resource Certificate PKI (RPKI) Trust Anchor Locator) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:30:46 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Resource Certificate PKI (RPKI) Trust Anchor Locator' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-ta/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-ta/ Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). Downref: This documnet makes a normative reference to an Informational RFC: RFC 5781 The following IPR Declarations may be related to this I-D: /ipr/1204/ From randy@psg.com Tue Mar 8 13:19:33 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B24B3A63CA for ; Tue, 8 Mar 2011 13:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8GFIJT3Hg1z for ; Tue, 8 Mar 2011 13:19:32 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 5915B3A63C9 for ; Tue, 8 Mar 2011 13:19:32 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Px4Kj-0005sn-QB for sidr@ietf.org; Tue, 08 Mar 2011 21:20:46 +0000 Date: Wed, 09 Mar 2011 06:20:44 +0900 Message-ID: From: Randy Bush To: sidr wg list References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@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 Subject: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:19:33 -0000 from a conversation with an rpki-rtr implementor >> is there a default TCP/SSH port that the servers are listening >> to? i'll try to add those as defaults for the client piece when >> trying to establish a session. > no, we have not done this. perhaps we should. it would make (debugging) life easier as i could also conveniently add proper printers for tcpdump and wireshark. chairs, this may mean another round on the rpki-rtr draft and then there is the question if there should be two ports, one ssh and one unprotected. this question opens a large hole, as i have been resisting transport drift, e.g. "what about over tls?" and so forth. no one has asked for beep yet :) so, i suggest asking the iana for a port number, one and only one. objections? randy From christopher.morrow@gmail.com Tue Mar 8 13:25:38 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCC83A659B for ; Tue, 8 Mar 2011 13:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLR5wLukCqYb for ; Tue, 8 Mar 2011 13:25:38 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B9F833A657C for ; Tue, 8 Mar 2011 13:25:37 -0800 (PST) Received: by wyb42 with SMTP id 42so423338wyb.31 for ; Tue, 08 Mar 2011 13:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jI7nmqHGOW1T+ZpBOxUHk8Rr7jmdrFZVk/DBZUdT32c=; b=qdrc4mggp6SNSd1cyiz9AxUE9X6dF1Ta535J7ywffm4CJYgbXbm/jEDPcBHv0M8I7S mVeed2atPB3hEkj0YZcQicgsGjw8BdoX81zzsczi6iOiOtE9o1D+qU1edC5jt7FVcIFa 1Tykfpjrl8D+3yhSce9qwz/55mJIxEJI2mk8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=u67ghapO7/hmOe8rxDTdvVPaggq5ixox/W8XqXAcF8RY+kjgspQpx0wa0YdXL/skSr ECUP4DtS+keoUZAxDBMv7udbBhIn4SHDnqnajDBZRcLnGh709Nbg/MKRt6D4xViXI5cJ iRSmQUrtCf0B8JAyksGMiFy2BucQCuLMbJtmI= MIME-Version: 1.0 Received: by 10.216.160.129 with SMTP id u1mr3754991wek.88.1299619612452; Tue, 08 Mar 2011 13:26:52 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.82.74 with HTTP; Tue, 8 Mar 2011 13:26:52 -0800 (PST) In-Reply-To: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> Date: Tue, 8 Mar 2011 16:26:52 -0500 X-Google-Sender-Auth: dQP1BEnFYcWvaduHu0LnxvpH0Qs Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:25:38 -0000 On Tue, Mar 8, 2011 at 4:20 PM, Randy Bush wrote: > from a conversation with an rpki-rtr implementor > > =A0 =A0>> is there a default TCP/SSH port that the servers are listening > =A0 =A0>> to? =A0i'll try to add those as defaults for the client piece w= hen > =A0 =A0>> trying to establish a session. > =A0 =A0> no, we have not done this. =A0perhaps we should. > > =A0 =A0it would make (debugging) life easier as i could also conveniently > =A0 =A0add proper printers for tcpdump and wireshark. > > chairs, this may mean another round on the rpki-rtr draft > > and then there is the question if there should be two ports, one ssh and > one unprotected. =A0this question opens a large hole, as i have been > resisting transport drift, e.g. "what about over tls?" and so forth. =A0n= o > one has asked for beep yet :) > > so, i suggest asking the iana for a port number, one and only one. > objections? I'm personally a fan of keeping things simple .... what's the beef with tcp/22 here? From randy@psg.com Tue Mar 8 15:38:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630B73A67B1 for ; Tue, 8 Mar 2011 15:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zFPbpmBcLCb for ; Tue, 8 Mar 2011 15:38:36 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 3719A3A67AB for ; Tue, 8 Mar 2011 15:38:34 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Px6VH-0006Lz-I3 for sidr@ietf.org; Tue, 08 Mar 2011 23:39:48 +0000 Date: Wed, 09 Mar 2011 08:39:45 +0900 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] signaling origin validity state X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:38:39 -0000 draft-retana-bgp-security-state-diagnostic-00.txt This document describes an extension to the BGP Diagnostic Message to communicate the security state of a route. An application of this extension is to propagate information about non-secure advertisements back to the eBGP peer from where the information was received. aside from this being a major change in the trust model (from rpki to peer), there was prior art presented at the last meeting, see draft-zhang-idr-decoupling-01.txt This draft proposes a novel mitigation scheme to protect the inter- domain data delivery during false routing announcements. A new path attribute is defined to Decouple propagation of a path and adoption of a path for data forwarding in BGP (DBGP). DBGP does not use suspicious paths for data forwarding, but still propagates them in the routing system to facilitate attack detection. It can extensively protect data delivery from routing announcements of false sub- prefixes, false origins, false nodes and false links and works well with ongoing attack detection and prevention systems. the comments at the time were mostly that the wg's job was to validate and propagate good data, not bad. perhaps it's worth agenda time to discuss this whole trend and various flavors to climb on the origin validation bandwagon. randy From yb@oob.anycats.net Tue Mar 8 17:43:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879903A6800 for ; Tue, 8 Mar 2011 17:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDzBI-O36Hjt for ; Tue, 8 Mar 2011 17:43:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 987D83A67F7 for ; Tue, 8 Mar 2011 17:43:29 -0800 (PST) Received: from modemcable088.194-200-24.mc.videotron.ca ([24.200.194.88] helo=[10.0.1.2]) by psg.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Px8SC-0006aD-2I; Wed, 09 Mar 2011 01:44:44 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Yann Berthier In-Reply-To: Date: Tue, 8 Mar 2011 20:44:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 01:43:30 -0000 On 2011-03-08, at 4:26 PM, Christopher Morrow wrote: >> so, i suggest asking the iana for a port number, one and only one. >> objections? >=20 > I'm personally a fan of keeping things simple .... what's the beef > with tcp/22 here? The set of source IPs needing access to tcp/22 for mgmt may not be the = same as the set of IPs needing access to tcp/22 for the rpki service A dedicated port for rpki seems a good idea From christopher.morrow@gmail.com Tue Mar 8 18:38:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD9D3A680C for ; Tue, 8 Mar 2011 18:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Toxmn3wo4deH for ; Tue, 8 Mar 2011 18:38:24 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 76BAA3A680D for ; Tue, 8 Mar 2011 18:38:24 -0800 (PST) Received: by wyb42 with SMTP id 42so82025wyb.31 for ; Tue, 08 Mar 2011 18:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oKVm5GxKX3DZROyjmyXTiXYeDzKwiR/OfvW0N3HK03I=; b=S7UsYUkuxRNfcBuwCks/JOEy/A/LfA9f2JnfglJoa+6SP2wKuAIaKhVEVlB+hnwqqo iz5pemc2dOqq+PZz9wgQk2kbCFjEBrihDy81uj3eG9fLPZ6hcMLA7l6faa2ghm1pAHQG F6Yhpw4oIm5BmxG6FmxBAXIsHw4XiRH5Cz9h0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Rb6IM7AwGt+zIt+oDA9xfJ7RSqtV5q2VCfFvWleKZtVYUhBhj/T/Ras03ZNdL5nkvY /nD48OOSkyZLtp01tZcM4aBcKWY7rNXML0J4Ix3IaflSC/otSoscoPS7awcaI2rHNypQ YStjVrtstnyt1XMZO+l93jjO6MW+14/+dinaM= MIME-Version: 1.0 Received: by 10.216.183.148 with SMTP id q20mr4941063wem.88.1299638379635; Tue, 08 Mar 2011 18:39:39 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.82.74 with HTTP; Tue, 8 Mar 2011 18:39:39 -0800 (PST) In-Reply-To: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> Date: Tue, 8 Mar 2011 21:39:39 -0500 X-Google-Sender-Auth: IlzVjatUxoxvlqpK2z865twg7y4 Message-ID: From: Christopher Morrow To: Yann Berthier Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 02:38:25 -0000 On Tue, Mar 8, 2011 at 8:44 PM, Yann Berthier wrote: > > On 2011-03-08, at 4:26 PM, Christopher Morrow wrote: > >>> so, i suggest asking the iana for a port number, one and only one. >>> objections? >> >> I'm personally a fan of keeping things simple .... what's the beef >> with tcp/22 here? > > The set of source IPs needing access to tcp/22 for mgmt may not be the same as the set of IPs needing access to tcp/22 for the rpki service > > A dedicated port for rpki seems a good idea don't disagree, just seeking some justification for the change. I came up with: o diff hosts need ssh vs rpki-rtr (potentially off-net things?) o ability to drop shields in case of problems but still maintain management access o qos/debugging reasons o authentication requirements perhaps are different between user-ssh && rpki-rtr randy came up with: 'maybe we don't trust the ssh code to do this heavy lifting?' (or something similar) just hunting for the reason to be different. -chris From iesg-secretary@ietf.org Wed Mar 9 07:18:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667423A6866; Wed, 9 Mar 2011 07:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WjflxRjh6lK; Wed, 9 Mar 2011 07:18:45 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30B43A69A3; Wed, 9 Mar 2011 07:18:45 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110309151845.5346.21811.idtracker@localhost> Date: Wed, 09 Mar 2011 07:18:45 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Signed Object Template for the Resource Public Key Infrastructure) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:18:46 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Signed Object Template for the Resource Public Key Infrastructure' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-signed-object/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-signed-object/ Abstract This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. No IPR declarations have been submitted directly on this I-D. From Donald.Smith@qwest.com Wed Mar 9 08:29:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646133A683E for ; Wed, 9 Mar 2011 08:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 OJEh3esdEBvf for ; Wed, 9 Mar 2011 08:29:51 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id AC9F33A6859 for ; Wed, 9 Mar 2011 08:29:50 -0800 (PST) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id p29GV1BU026354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Mar 2011 09:31:01 -0700 (MST) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 62CCD1E006E; Wed, 9 Mar 2011 09:30:56 -0700 (MST) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 385621E0049; Wed, 9 Mar 2011 09:30:56 -0700 (MST) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id p29GUhZg006451; Wed, 9 Mar 2011 10:30:55 -0600 (CST) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Wed, 9 Mar 2011 09:30:45 -0700 From: "Smith, Donald" To: "'Christopher Morrow'" , "'Yann Berthier'" Date: Wed, 9 Mar 2011 09:30:45 -0700 Thread-Topic: [sidr] rpki-rtr standard port Thread-Index: AcveA0DKjNrdXjNcQ8y2591bcuWcawAc3BSg Message-ID: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'sidr wg list' Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:29:52 -0000 Sharing: No permission required. This is public share as desired. Donald.Smith@qwest.com > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Tuesday, March 08, 2011 7:40 PM > To: Yann Berthier > Cc: sidr wg list > Subject: Re: [sidr] rpki-rtr standard port > > On Tue, Mar 8, 2011 at 8:44 PM, Yann Berthier > wrote: > > > > On 2011-03-08, at 4:26 PM, Christopher Morrow wrote: > > > >>> so, i suggest asking the iana for a port number, one and only one. > >>> objections? > >> > >> I'm personally a fan of keeping things simple .... what's the beef > >> with tcp/22 here? > > > > The set of source IPs needing access to tcp/22 for mgmt may not be > the same as the set of IPs needing access to tcp/22 for the rpki > service > > > > A dedicated port for rpki seems a good idea > > don't disagree, just seeking some justification for the change. I came > up with: > o diff hosts need ssh vs rpki-rtr (potentially off-net things?) > o ability to drop shields in case of problems but still maintain > management access I think this is related to your "drop shields" statement but may be differe= nt enough to capture. Standard ssh port (22) for any router or router support system should only = be available from your trusted NOC ips. So a "new" port should be used for rpki that has different filtering acls o= r no filtering acls. In a perfect world NOBODY would use 22 for ssh that would slow down the bru= te force attacks by 64k times and make the scanners noisier. > o qos/debugging reasons > o authentication requirements perhaps are different between user-ssh > && rpki-rtr > > randy came up with: 'maybe we don't trust the ssh code to do this > heavy lifting?' (or something similar) > > just hunting for the reason to be different. > > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From randy@psg.com Wed Mar 9 15:20:58 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A753A672F for ; Wed, 9 Mar 2011 15:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnf+ne98LBYu for ; Wed, 9 Mar 2011 15:20:56 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id DBFC73A6A3F for ; Wed, 9 Mar 2011 15:20:55 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PxShk-000Bkk-M2; Wed, 09 Mar 2011 23:22:09 +0000 Date: Thu, 10 Mar 2011 08:22:07 +0900 Message-ID: From: Randy Bush To: Yann Berthier In-Reply-To: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:20:58 -0000 >> I'm personally a fan of keeping things simple .... what's the beef >> with tcp/22 here? > The set of source IPs needing access to tcp/22 for mgmt may not be the > same as the set of IPs needing access to tcp/22 for the rpki service the router is the originator of the ssh connection, so there is no guess as to the port the cache will use. if you are a big fan of ip address based acls, it is the cache you will be protecting, not the router. i think the issues were o predictability and default config of router o other tools may want to reach server on the ssh vs other transport issue, i am less happy. the protocol specifies ssh, and this discussion would lead to standardizing the port on the cache/server to be used. that the testbed currently provides a few clear-text servers for implementors to test without ssh is merely a test service, and, imiho, should not be standardized. unless operators would care to argue that they trust security services which use clear-text. randy From jmh@joelhalpern.com Wed Mar 9 15:45:17 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653393A6AF6 for ; Wed, 9 Mar 2011 15:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxn0u2AdlaJF for ; Wed, 9 Mar 2011 15:45:16 -0800 (PST) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by core3.amsl.com (Postfix) with ESMTP id 92DFC3A6B0C for ; Wed, 9 Mar 2011 15:45:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D282432444A3 for ; Wed, 9 Mar 2011 15:46:33 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.170] (unknown [129.192.147.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 838BB3228BC7 for ; Wed, 9 Mar 2011 15:46:33 -0800 (PST) Message-ID: <4D781158.3070801@joelhalpern.com> Date: Wed, 09 Mar 2011 18:46:32 -0500 From: Joel Halpern User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Fwd: Re: SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 23:45:17 -0000 I sent Randy the text below. He asked that I post it to the list. He had a number of concerns, one of which I is addressed by adding the [partially]. I also added the [possibly] trying to follow the suggestion further. I am not by any means wedded to this wording. What I am looking to accomplish is to add just a bit of text before the requirements to indicate why we are trying to do this. It is not normative. It is not itself setting a requirement. Yours, Joel -------- Original Message -------- Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work Date: Wed, 09 Mar 2011 13:46:28 -0500 From: Joel M. Halpern To: Randy Bush For the end of the Introduction: The requirements described here focus on protecting the AS Path information used in BGP. This is [partially] motivated by the fact that an attacker who can modify AS Path information can mislead otherwise well-behaving AS; [possibly] inducing them to forward packets in improper or possibly even harmful fashions. Yours, Joel From randy@psg.com Wed Mar 9 16:11:43 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4C03A6AD9 for ; Wed, 9 Mar 2011 16:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B4JdwgtN9GL for ; Wed, 9 Mar 2011 16:11:42 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 4DE243A6B0E for ; Wed, 9 Mar 2011 16:11:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PxTUv-000CBY-Na; Thu, 10 Mar 2011 00:12:58 +0000 Date: Thu, 10 Mar 2011 09:12:56 +0900 Message-ID: From: Randy Bush To: Joel Halpern In-Reply-To: <4D781158.3070801@joelhalpern.com> References: <4D781158.3070801@joelhalpern.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Fwd: Re: SIDR ReCharter - to capture/cover path validation work X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:11:43 -0000 > I sent Randy the text below. not including the text in brackets > The requirements described here focus on protecting the AS Path > information used in BGP. This is [partially] motivated by the fact > that an attacker who can modify AS Path information can mislead > otherwise well-behaving AS; [possibly] inducing them to forward > packets in improper or possibly even harmful fashions. one wants to protect the entire NLRI, not just the AS-Path. and the intro currently says precisely that. for reference, here is the current intro RPKI-based Origin Validation ([I-D.ietf-sidr-pfx-validate]) provides a measure of resilience to accidental mis-origination of prefixes. But it provides neither cryptographic assurance (announcements are not signed), nor assurance of the AS Path of the announcement. This document describes requirements to be placed on a BGP security protocol, herein termed BGPsec, intended to rectify these gaps. your paragraph drags intent in. as we are unable to know intent, what is the win here? then it gets into data plane forwarding, which the draft very explicitly avoids. what is a 'proper' direction? what is a 'harmful' direction? i feel the ground opening a big hole under me. again, what's the win? as i can not know your intent , i suspect you are trying to motivate the requirements in a practical manner. while this is an understandable goal, doing so seems to drag in all sorts of issues that might better be avoided. which is why the current bit of intro, quoted above, is very careful just to state it in terms of assurance. can other folk help us here? randy From christopher.morrow@gmail.com Wed Mar 9 19:25:13 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2FD3A686C for ; Wed, 9 Mar 2011 19:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMU9jB72oS+o for ; Wed, 9 Mar 2011 19:25:12 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E4DE43A67D6 for ; Wed, 9 Mar 2011 19:25:11 -0800 (PST) Received: by wyb42 with SMTP id 42so1241126wyb.31 for ; Wed, 09 Mar 2011 19:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fK4r0RcR0g57r8Or6Q003qyHSd3CqfmMouQzo0v2xxA=; b=jvE/vDbaFjfmHNWe1cEu9SQDuCe95LLN1PpCT781xCAtau5b4aocT21RTxYKpKN5W2 oPHE6ZsypVCe1vaT30RvfzIU3zyWQHfssl0irUDVNBM+YLQHmcYLpSriV/NC79NDFN54 N/3KKnaRrZGzvXq3YBgsx2qMGqrqx51BhtDes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nSKgEqsUrkvCgDihpA06Apnvy9zhihCfj84/CJjTJIOc3bczeWSUwv67PwLS5vroL9 0E1wn+mFZZuWcxdCeGZDqR3LiBXtvuDEk1yTrwZAYKkJTJIlr2jSQklRWKYwMJhEE2mA EG4h92eR3lp1pnXkS1fm7oVsrK/D2U89hSV38= MIME-Version: 1.0 Received: by 10.216.69.7 with SMTP id m7mr1723381wed.73.1299727588353; Wed, 09 Mar 2011 19:26:28 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.82.74 with HTTP; Wed, 9 Mar 2011 19:26:28 -0800 (PST) In-Reply-To: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> Date: Wed, 9 Mar 2011 22:26:28 -0500 X-Google-Sender-Auth: -LoIsXOqVmDGMdJlPxa7yFLFYPQ Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 03:25:13 -0000 On Wed, Mar 9, 2011 at 6:22 PM, Randy Bush wrote: >>> I'm personally a fan of keeping things simple .... what's the beef >>> with tcp/22 here? >> The set of source IPs needing access to tcp/22 for mgmt may not be the >> same as the set of IPs needing access to tcp/22 for the rpki service > > the router is the originator of the ssh connection, so there is no guess > as to the port the cache will use. =A0if you are a big fan of ip address > based acls, it is the cache you will be protecting, not the router. apologies I reversed the info/pkt flow. Ok, so ideally in a sane world I can already scp/ssh from a router to another router (maintenance requirements + code moves + config loads ... last-resort 'ohshit' configs.) Adding a few cache ips where the only thing running on the ip/port combo is this service seems ok to me. Ideally cache box has 'service' ip and 'maintenance' ip... with different security policies and 'better' service separation than I can get today in the world of routers. I'm back to 'why complicate things?' -Chris > i think the issues were > =A0o predictability and default config of router > =A0o other tools may want to reach server > > on the ssh vs other transport issue, i am less happy. =A0the protocol > specifies ssh, and this discussion would lead to standardizing the port > on the cache/server to be used. =A0that the testbed currently provides a > few clear-text servers for implementors to test without ssh is merely a > test service, and, imiho, should not be standardized. =A0unless operators > would care to argue that they trust security services which use > clear-text. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Wed Mar 9 19:27:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199133A680B for ; Wed, 9 Mar 2011 19:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zStceWcTQI7N for ; Wed, 9 Mar 2011 19:27:24 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 2C2083A67D6 for ; Wed, 9 Mar 2011 19:27:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PxWYJ-000DJe-0n; Thu, 10 Mar 2011 03:28:39 +0000 Date: Thu, 10 Mar 2011 12:28:38 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 03:27:25 -0000 > I'm back to 'why complicate things?' config default implicity and wireshark and tcpdump templates in tension with use of a limited pool of assigned port numbers. randy From christopher.morrow@gmail.com Wed Mar 9 19:31:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427583A67D6 for ; Wed, 9 Mar 2011 19:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.492 X-Spam-Level: X-Spam-Status: No, score=-103.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esF+fMU0plxL for ; Wed, 9 Mar 2011 19:31:47 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BD98B3A67F7 for ; Wed, 9 Mar 2011 19:31:46 -0800 (PST) Received: by wyb42 with SMTP id 42so1244089wyb.31 for ; Wed, 09 Mar 2011 19:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ticS1MXQhXbH36m9IId14uQSaBE/TYBWkej5S2/GDY4=; b=cKRtg8V8w+MWji9O2iMzR4HALXaytqmbvyVunZiYwimQx5gbdJZ+rNH8gsPpt2zey2 IH6u8ZiJNrt7CKOwurv5zOev4pqCsOulKy6RFxsc2h9hD4AL7B+nbnWEQLII5S20S23I 1Ul3B48MBAWi5coh9+rf0LxmGaboTcjXqQTDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=HLhw5LG3zxwpydd4ioXp6fwkcxKjYPy9ZOGi1vXhthCzdmo6GVuZcfe/ib1qK3JopK oV7yTWrDyQlfeG6kizQX2uRpmBizThASaVjjmNJxmr6KVDjJ57Fobe1Ab3BPgBZHExiz hbtpnWueOyJ4vtKbaDslFWuPbA8BlDMkiLEyw= MIME-Version: 1.0 Received: by 10.216.24.73 with SMTP id w51mr5976728wew.72.1299727983430; Wed, 09 Mar 2011 19:33:03 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.216.82.74 with HTTP; Wed, 9 Mar 2011 19:33:03 -0800 (PST) In-Reply-To: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> Date: Wed, 9 Mar 2011 22:33:03 -0500 X-Google-Sender-Auth: TMzWnu9EBiDfyvEzgk-6JVNquAc Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 03:31:48 -0000 On Wed, Mar 9, 2011 at 10:28 PM, Randy Bush wrote: >> I'm back to 'why complicate things?' > > > config default implicity and wireshark and tcpdump templates in tension > with use of a limited pool of assigned port numbers. router points to cache on "cache-service-ip:port" (22 or other it's not super important at this point, I think.) "port" is running ONLY the cache-service, not regular/normal ssh, or an sshd configured to only do the right thing for cache requests and NOT permit user login/shell. I presume this all shows up in some nice package anyway. that does argue for a 'not port 22' solution, I suppose, less confusion and not subject to the daily dose of ssh scanners. I think this still is a local implementation decision, you could say it's simpler/easier to just pick a new port from IANA and use that for this service. I'd support that as a path forward. From Internet-Drafts@ietf.org Wed Mar 9 23:00:14 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF5A3A6808; Wed, 9 Mar 2011 23:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7l6bqFKU8hU; Wed, 9 Mar 2011 23:00:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D713A68C6; Wed, 9 Mar 2011 23:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310070001.21512.99122.idtracker@localhost> Date: Wed, 09 Mar 2011 23:00:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ghostbusters-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 07:00:14 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI Ghostbusters Record Author(s) : R. Bush Filename : draft-ietf-sidr-ghostbusters-01.txt Pages : 7 Date : 2011-03-09 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information to be signed (indirectly) by a resource-owning certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-ghostbusters-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-09225841.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Mar 10 02:00:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A67F3A6A17; Thu, 10 Mar 2011 02:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 9OTOgDfxGMs4; Thu, 10 Mar 2011 02:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19C13A69D0; Thu, 10 Mar 2011 02:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310100001.15558.97926.idtracker@localhost> Date: Thu, 10 Mar 2011 02:00:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 10:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-06.txt Pages : 8 Date : 2011-03-10 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-10014529.I-D@ietf.org> --NextPart-- From jgs@bgp.nu Thu Mar 10 03:41:40 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442B23A6A1E for ; Thu, 10 Mar 2011 03:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4u9oGCaWWaP for ; Thu, 10 Mar 2011 03:41:39 -0800 (PST) Received: from bgp.nu (bgp.nu [216.117.214.198]) by core3.amsl.com (Postfix) with ESMTP id 9B8D23A6933 for ; Thu, 10 Mar 2011 03:41:39 -0800 (PST) Received: from sa-nc-ipg-172-23-0-130.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id DFF731614791; Thu, 10 Mar 2011 06:42:55 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: Date: Thu, 10 Mar 2011 13:42:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1082) Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 11:41:40 -0000 On Mar 10, 2011, at 5:33 AM, Christopher Morrow wrote: ... > that does argue for a 'not port 22' solution, I suppose, less > confusion and not subject to the daily dose of ssh scanners. >=20 > I think this still is a local implementation decision, you could say > it's simpler/easier to just pick a new port from IANA and use that for > this service. I'd support that as a path forward. If "not subject to ssh scanners" is really the goal, surely a new = well-known port would defeat it. To get your daily dose of = security-by-obscurity, you need obscurity. --John= From rv@x37.NIC.DTAG.DE Thu Mar 10 08:48:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090813A6A3A for ; Thu, 10 Mar 2011 08:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMYHyMBEvjqp for ; Thu, 10 Mar 2011 08:48:40 -0800 (PST) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by core3.amsl.com (Postfix) with ESMTP id AA0AA3A6A28 for ; Thu, 10 Mar 2011 08:48:39 -0800 (PST) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id RAA24929; Thu, 10 Mar 2011 17:49:47 +0100 (MET) To: Christopher Morrow From: Ruediger Volk In-Reply-To: Your message of "Wed, 09 Mar 2011 22:26:28 EST." Date: Thu, 10 Mar 2011 17:49:49 +0100 Message-ID: <5150.1299775789@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 16:48:41 -0000 > On Wed, Mar 9, 2011 at 6:22 PM, Randy Bush wrote: > >>> I'm personally a fan of keeping things simple .... what's the beef > >>> with tcp/22 here? > >> The set of source IPs needing access to tcp/22 for mgmt may not be the > >> same as the set of IPs needing access to tcp/22 for the rpki service > > > > the router is the originator of the ssh connection, so there is no guess > > as to the port the cache will use. =A0if you are a big fan of ip address > > based acls, it is the cache you will be protecting, not the router. > > apologies I reversed the info/pkt flow. Ok, so ideally in a sane world > I can already scp/ssh from a router to another router (maintenance > requirements + code moves + config loads ... last-resort 'ohshit' > configs.) Adding a few cache ips where the only thing running on the > ip/port combo is this service seems ok to me. > > Ideally cache box has 'service' ip and 'maintenance' ip... with > different security policies and 'better' service separation than I can > get today in the world of routers. I wonder whether that's how ssh designers intended to support selection of application service; or: what the commonly used / most appropriate way to select one of several application services with access over ssh are. I never had to use a separate host IP address for using scp for target hosts that I also have ssh shell sessions with (and I certainly have used scp from certain routers targetting my usual Unix ssh accounts). I'm no ssh expert; is one around and willing to provide some clue, please? I suspect that if there is no predefined/commonly used mechanism in place something as simple as prepend to the protocol as piped into the ssh transport "originators sends 'this-magic-token-invokes-the-RPKI-cache-server\n'" could do the job. > I'm back to 'why complicate things?' > > -Chris Ruediger Volk From sra@hactrn.net Thu Mar 10 09:05:15 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C803A687A for ; Thu, 10 Mar 2011 09:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcAV1bP68NdZ for ; Thu, 10 Mar 2011 09:05:14 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id E4A163A6A03 for ; Thu, 10 Mar 2011 09:05:13 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6072B2845C for ; Thu, 10 Mar 2011 17:06:29 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 195D222829 for ; Thu, 10 Mar 2011 12:06:29 -0500 (EST) Date: Thu, 10 Mar 2011 12:06:29 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <5150.1299775789@x37.NIC.DTAG.DE> References: <5150.1299775789@x37.NIC.DTAG.DE> 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: <20110310170629.195D222829@thrintun.hactrn.net> Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:05:15 -0000 I'm not a hard-core ssh expert either, but keep in mind that we're already using the ssh "subsystem" mechanism, ie, we are using an assigned name for the specific service we're trying to reach. Furthermore, while outside the network spec, implementations like OpenSSH already have the concept of restricting a particular set set of authentication credentials to running a command determined entirely by the server. That is: ie, it is not difficult to lock a particular set of credentials into running only the specific command or subsystem one wants to allow. Small matter of configuration, but one would have to configure credentials in any case, this is just a bit more config. I think the port number thing is more about people who really just want to be able to filter based on port numbers, full stop. I don't, particularly, because forcing encrypted traffic (content the filter can't inspect, by definition) to use port A instead of port B has never struck me as an effective policy enforcement mechanism. YMMV. From rv@x37.NIC.DTAG.DE Thu Mar 10 09:49:41 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34743A6947 for ; Thu, 10 Mar 2011 09:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKUBMSBj3VPd for ; Thu, 10 Mar 2011 09:49:41 -0800 (PST) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by core3.amsl.com (Postfix) with ESMTP id 8C79F3A690A for ; Thu, 10 Mar 2011 09:49:40 -0800 (PST) Received: from x37.NIC.DTAG.DE (x37.NIC.DTAG.DE [194.25.1.186]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id SAA04897; Thu, 10 Mar 2011 18:50:38 +0100 (MET) To: Rob Austein From: Ruediger Volk In-Reply-To: Your message of "Thu, 10 Mar 2011 12:06:29 EST." <20110310170629.195D222829@thrintun.hactrn.net> Date: Thu, 10 Mar 2011 18:50:41 +0100 Message-ID: <5220.1299779441@x37.NIC.DTAG.DE> Sender: rv@x37.NIC.DTAG.DE Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:49:41 -0000 Rob, thanks > I'm not a hard-core ssh expert either, but keep in mind that we're > already using the ssh "subsystem" mechanism, ie, we are using an > assigned name for the specific service we're trying to reach. sorry, I forgot/missed that use of ssh subsystem "rpki-rtr" is already in the draft; that clearly does the selection of application service. > Furthermore, while outside the network spec, implementations like > OpenSSH already have the concept of restricting a particular set set > of authentication credentials to running a command determined entirely > by the server. That is: ie, it is not difficult to lock a particular > set of credentials into running only the specific command or subsystem > one wants to allow. Small matter of configuration, but one would have > to configure credentials in any case, this is just a bit more config. > > I think the port number thing is more about people who really just > want to be able to filter based on port numbers, full stop. I don't, > particularly, because forcing encrypted traffic (content the filter > can't inspect, by definition) to use port A instead of port B has > never struck me as an effective policy enforcement mechanism. YMMV. With application selection taken care of elsewhere using seperate addresses for helping packet filters etc. seems perfectly appropriate; using separate well defined port would be wasteful. Ruediger Volk From yb@oob.anycats.net Thu Mar 10 10:20:38 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72C13A6906 for ; Thu, 10 Mar 2011 10:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwR4qWBCFVA0 for ; Thu, 10 Mar 2011 10:20:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 185E83A68F1 for ; Thu, 10 Mar 2011 10:20:37 -0800 (PST) Received: from modemcable088.194-200-24.mc.videotron.ca ([24.200.194.88] helo=[10.0.1.2]) by psg.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PxkUj-000GVG-IX; Thu, 10 Mar 2011 18:21:53 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Yann Berthier In-Reply-To: <20110310170629.195D222829@thrintun.hactrn.net> Date: Thu, 10 Mar 2011 13:21:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <76333A36-430F-4E55-840C-788A5900FC5D@oob.anycats.net> References: <5150.1299775789@x37.NIC.DTAG.DE> <20110310170629.195D222829@thrintun.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:20:38 -0000 On 2011-03-10, at 12:06 PM, Rob Austein wrote: > I think the port number thing is more about people who really just > want to be able to filter based on port numbers, full stop. I don't, > particularly, because forcing encrypted traffic (content the filter > can't inspect, by definition) to use port A instead of port B has > never struck me as an effective policy enforcement mechanism. YMMV. the content being encrypted does not mean i don't want to restrict its = accessibility to a set of ips-i-trust-more; like, my routers similarly, it may not be the same set as the ones presumably used for = management of the cache box but whatever - i can use a separate ip for rpki-rtr vs mgmt of the = cache, so no big deal either way From iesg-secretary@ietf.org Thu Mar 10 10:23:55 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18C13A6B4C; Thu, 10 Mar 2011 10:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 r-uGcyJgy18G; Thu, 10 Mar 2011 10:23:54 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4283A6B45; Thu, 10 Mar 2011 10:23:54 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310182354.28560.67584.idtracker@localhost> Date: Thu, 10 Mar 2011 10:23:54 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Manifests for the Resource Public Key Infrastructure) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:23:55 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Manifests for the Resource Public Key Infrastructure' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manifests/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-manifests/ Abstract This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority, that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Mar 10 10:27:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E2A3A6B44; Thu, 10 Mar 2011 10:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 x9jioWsU8AYB; Thu, 10 Mar 2011 10:27:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D254A3A6B3B; Thu, 10 Mar 2011 10:27:01 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310182701.28846.23980.idtracker@localhost> Date: Thu, 10 Mar 2011 10:27:01 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:27:03 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-algs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-algs/ Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format for the Resource Public Key Infrastructure subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the Relying Parties (RPs) that verify these digital signatures. Downref: Normative reference to is made to an Informational draft: draft-ietf-sidr-arch No IPR declarations have been submitted directly on this I-D. From Sandra.Murphy@cobham.com Thu Mar 10 12:40:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7693A692B for ; Thu, 10 Mar 2011 12:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mq3VbcmSQRNZ for ; Thu, 10 Mar 2011 12:40:22 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0A2C63A67F8 for ; Thu, 10 Mar 2011 12:40:20 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p2AKfbNK011585 for ; Thu, 10 Mar 2011 14:41:37 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p2AKfcKH009795 for ; Thu, 10 Mar 2011 14:41:38 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.170]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 15:41:37 -0500 Date: Thu, 10 Mar 2011 15:41:36 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Mar 2011 20:41:37.0478 (UTC) FILETIME=[8D40C660:01CBDF63] Subject: [sidr] agenda item request X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:40:31 -0000 The draft agendas for IETF 80 are due next Wednesday, 2011-03-16. If you would like to make a presentation at sidr for IETF 80, please send mail to the list by Wednesday morning to give the chairs a chance to construct the agenda for upload. I remind everyone that sidr is presently scheduled for two sessions: THURSDAY, March 31, 2011 0900-1130 Morning Session I and FRIDAY, April 1, 2011 1300-1400 Afternoon Session I & 1415-1515 Afternoon Session II --Sandy From iesg-secretary@ietf.org Thu Mar 10 13:19:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D563A6AAA; Thu, 10 Mar 2011 13:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 WveXJkal4-0p; Thu, 10 Mar 2011 13:19:04 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241A33A691F; Thu, 10 Mar 2011 13:19:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310211904.15568.39897.idtracker@localhost> Date: Thu, 10 Mar 2011 13:19:04 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (A Profile for Route Origin Authorizations (ROAs)) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:19:05 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'A Profile for Route Origin Authorizations (ROAs)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-format/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-format/ Abstract This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. No IPR declarations have been submitted directly on this I-D. From randy@psg.com Thu Mar 10 13:39:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C543A6A69 for ; Thu, 10 Mar 2011 13:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnfARe0VHJHd for ; Thu, 10 Mar 2011 13:39:18 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 5B32A3A6943 for ; Thu, 10 Mar 2011 13:39:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pxnb0-000HZj-DK; Thu, 10 Mar 2011 21:40:34 +0000 Date: Fri, 11 Mar 2011 06:40:34 +0900 Message-ID: From: Randy Bush To: Rob Austein In-Reply-To: <20110310170629.195D222829@thrintun.hactrn.net> References: <5150.1299775789@x37.NIC.DTAG.DE> <20110310170629.195D222829@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:39:19 -0000 > I think the port number thing is more about people who really just > want to be able to filter based on port numbers, full stop. not completely. if i know the port number, i can hack tcpdump and wireshark smarts. randy From randy@psg.com Thu Mar 10 13:59:16 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DD13A6ABC for ; Thu, 10 Mar 2011 13:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYuX7H+OqLK0 for ; Thu, 10 Mar 2011 13:59:15 -0800 (PST) Received: from ran.psg.com (ssh.psg.com [IPv6:2001:418:1::40]) by core3.amsl.com (Postfix) with ESMTP id 2D9713A6A79 for ; Thu, 10 Mar 2011 13:59:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PxnuJ-000HeH-Ax; Thu, 10 Mar 2011 22:00:31 +0000 Date: Fri, 11 Mar 2011 07:00:30 +0900 Message-ID: From: Randy Bush To: Oliver Borchert User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: [sidr] Behavior of entities talking RPKI-Router protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:59:16 -0000 > (A) Unexpected withdrawal of white list (WL) entries. > > (i) What is the routers expected behavior when it receives a > withdrawal of a white list (WL) entry that does not exist? error code 6 > (B) The RPKI Validation cache may contain ROA's whose Prefix/Origin > content is identical. An example could be a ROA that is about to > expire and the "follow up" ROA is generated in advance to prevent a down > time. During a short period of time both would certify the > Prefix/Origin content. > > (i) Should the server send a WL announcement for each instance or > should the server reduce the information to a single WL announcement? > In other words should the router see the announcement of the new one > followed by the withdrawal of the old one? 1:1 > (ii) In case the cache sends a WL announcement for each corresponding > ROA entry can we expect the cache also to sends a WL withdrawal > for each expired/revoked ROA? yes randy From sra@hactrn.net Thu Mar 10 14:37:30 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77B13A6920 for ; Thu, 10 Mar 2011 14:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAoyHUMKEakT for ; Thu, 10 Mar 2011 14:37:30 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 9BB793A6866 for ; Thu, 10 Mar 2011 14:37:29 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 0F9EB2845C for ; Thu, 10 Mar 2011 22:38:46 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id BEE9022829 for ; Thu, 10 Mar 2011 17:38:45 -0500 (EST) Date: Thu, 10 Mar 2011 17:38:45 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <5150.1299775789@x37.NIC.DTAG.DE> <20110310170629.195D222829@thrintun.hactrn.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: <20110310223845.BEE9022829@thrintun.hactrn.net> Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 22:37:30 -0000 At Fri, 11 Mar 2011 06:40:34 +0900, Randy Bush wrote: > > > I think the port number thing is more about people who really just > > want to be able to filter based on port numbers, full stop. > > not completely. if i know the port number, i can hack tcpdump and > wireshark smarts. Unless you've got: a) An unusually smart Wireshark decoder, and b) A copy of the private key for at least one of the parties (or possibly you need both, I don't know the deep protocol details), you are not going to see a whole heck of a lot besides the initial ssh key exchange followed by a lot of encrypted glop. Initial setup debugging and traffic analysis, in other words. Mind, I'm not actively opposed to using a separate port, I just don't see the point (but then, I liked Chaosnet contact names too, back in the day). If somebody really needs this bikeshed to be hot pink, go for it. From Internet-Drafts@ietf.org Thu Mar 10 18:15:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9E43A6840; Thu, 10 Mar 2011 18:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 OP8LSVM1njlZ; Thu, 10 Mar 2011 18:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79BF3A67FF; Thu, 10 Mar 2011 18:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110311021501.21191.96432.idtracker@localhost> Date: Thu, 10 Mar 2011 18:15:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ghostbusters-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI Ghostbusters Record Author(s) : R. Bush Filename : draft-ietf-sidr-ghostbusters-02.txt Pages : 7 Date : 2011-03-10 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information to be signed (indirectly) by a resource-owning certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-ghostbusters-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-10180514.I-D@ietf.org> --NextPart-- From turners@ieca.com Thu Mar 10 18:41:00 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5F33A6B1B for ; Thu, 10 Mar 2011 18:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QwzS3gj8+XW for ; Thu, 10 Mar 2011 18:40:59 -0800 (PST) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by core3.amsl.com (Postfix) with SMTP id 3D7653A6840 for ; Thu, 10 Mar 2011 18:40:59 -0800 (PST) Received: from [98.139.91.65] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 11 Mar 2011 02:42:15 -0000 Received: from [98.139.91.23] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 11 Mar 2011 02:42:15 -0000 Received: from [127.0.0.1] by omp1023.mail.sp2.yahoo.com with NNFMP; 11 Mar 2011 02:42:15 -0000 X-Yahoo-Newman-Id: 475582.52976.bm@omp1023.mail.sp2.yahoo.com Received: (qmail 94216 invoked from network); 11 Mar 2011 02:42:15 -0000 Received: from thunderfish.local (turners@71.191.0.253 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 10 Mar 2011 18:42:14 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: cAMHVs4VM1mrdEVh30KwnUfI41hw4cZMRQYgb8y8iv4ALUi Gt_dTEl.wp7gUl4tvPknQfxAw1uKyq7ewI6GFiot6MLQu9_paKJr8xgicMmV 6.fqJ7sWJUiZB2zH2rkgi4LnC7_lKCq6qdxSaU8VJewZ0VtjMyh5aHMkyTUa lZlBMpP5j99vT5N_BQNc1t5_ekdhHWzHOr6jd581qHqSXDFs.cjwoBvnJelE 3uY3_dCt2s_EdZPXGShx7SilUQ5GIDPJ8Dl.H_S0lvC8k8yZzfcakts5_DV8 LtDgI7aLzwTxugTfbNTnJ0v5e0oK3637PY1s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D798C05.7080205@ieca.com> Date: Thu, 10 Mar 2011 21:42:13 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: sidr@ietf.org References: <20110222053002.8118.82908.idtracker@localhost> In-Reply-To: <20110222053002.8118.82908.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action:draft-ietf-sidr-repos-struct-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 02:41:00 -0000 Hi, I think this draft needs media type registrations for .mft and .roa. .cer and .crl are already in RFC 2585. I think it needs media type registration because every other draft I've ever seen that specifies a file extension does so. RFC 2585 specifies .cer and .crl and they're in a media type registration. Also, I got the impression that the repository draft can be done in other ways and a media type would support other profiles of the repository. http://tools.ietf.org/html/rfc4288 outlines the registration procedures. We'll be in the application/* tree so it's standard tree and the procedures are: Proposed registrations in the standards tree by other standards bodies should be communicated to the IESG (at iesg@ietf.org) and to the ietf-types list (at ietf-types@iana.org). During IETF LC make sure to ask the AD to copy ietf-types@iana.org. Here's some suggested text for Section 7: 7. IANA Considerations IANA is requested to register the following two media types: application/rpki-manifest application/rpki-roa This document also uses the .cer and .crl file extensions from application/pkix-cert and application/pkix-crl media registries defined in [RFC2585]. 7.1. application/rpki-manifest MIME media type name: application MIME subtype name: rpki-manifest Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries a RPKI Manifest [I-D.ietf-sidr-rpki-manifests] Interoperability considerations: None Published specification: This document Applications which use this media type: Any MIME-complaint transport Additional information: Magic number(s): None File extension(s): .mft Macintosh File Type Code(s): Person & email address to contact for further information: Geoff Huston Intended usage: COMMON Author/Change controller: Geoff Huston 7.2. application/rpki-roa MIME media type name: application MIME subtype name: rpki-roa Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries a RPKI ROA [ID.ietf-sidr-roa-format] Interoperability considerations: None Published specification: This document Applications which use this media type: Any MIME-complaint transport Additional information: Magic number(s): None File extension(s): .roa Macintosh File Type Code(s): Person & email address to contact for further information: Geoff Huston Intended usage: COMMON Author/Change controller: Geoff Huston Will also need to add a normative reference to the roa draft and to RFC 2585. spt From rogaglia@cisco.com Thu Mar 10 19:54:37 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7C03A6B63 for ; Thu, 10 Mar 2011 19:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3J5vzPtISCE for ; Thu, 10 Mar 2011 19:54:36 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id CFB013A680D for ; Thu, 10 Mar 2011 19:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=6419; q=dns/txt; s=iport; t=1299815755; x=1301025355; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=p0o/WRz0iGfK4hiodpIOePMzIRAPqxoZT34pEGGTRIM=; b=UjrqupJbGYyoFymYw0XoAQ3yzg6sVxPMAEjKJF+EPCy+zj8NYSDyZBF4 9KHaE/BkfzSNrlYcefETr4/yD5yJxc9GcQ3Vj8zVECfRA6sM3HcYHuyKB gLwVzuOCmFZLyGWtewAIMbbZSIUG4vrWxFV/73GR4WYWsHGRTBumR5YHd g=; X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAB8seU2Q/khLgWdsb2JhbACYY41SFAEBFiYlpGScLIViBIxD X-IronPort-AV: E=Sophos;i="4.62,301,1297036800"; d="p7s'?scan'208";a="21262216" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 Mar 2011 03:55:53 +0000 Received: from ams3-vpn-dhcp4999.cisco.com (ams3-vpn-dhcp4999.cisco.com [10.61.83.134]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2B3tr4S001905; Fri, 11 Mar 2011 03:55:53 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-147--613994212; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Fri, 11 Mar 2011 04:55:52 +0100 Message-Id: <923D4C86-5982-4D94-85A2-4C7FD63355AC@cisco.com> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1082) Cc: sidr@ietf.org Subject: Re: [sidr] agenda item request X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 03:54:37 -0000 --Apple-Mail-147--613994212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sandra, I would like to ask some minutes to present the changes on: = draft-ietf-sidr-algorithm-agility-00.txt=20 roque On Mar 10, 2011, at 9:41 PM, Sandra Murphy wrote: > The draft agendas for IETF 80 are due next Wednesday, 2011-03-16. >=20 > If you would like to make a presentation at sidr for IETF 80, please = send mail to the list by Wednesday morning to give the chairs a chance = to construct the agenda for upload. >=20 > I remind everyone that sidr is presently scheduled for two sessions: >=20 > THURSDAY, March 31, 2011 0900-1130 Morning Session I >=20 > and >=20 > FRIDAY, April 1, 2011 1300-1400 Afternoon Session I & 1415-1515 = Afternoon Session II >=20 >=20 > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-147--613994212 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMxMTAz NTU1M1owIwYJKoZIhvcNAQkEMRYEFBMQN+NRbvfLXfYuZ0rtiXEnao6jMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAEZAo50B038/ILKDIRPLACPdf5bWHP8zA/kuTipclqr59zqVa+Sb c0GLcVc40wAxFIHs2Pz376qCEKs7PjCeVvmDAkQnRxOFQfVXNYcIZ9h/zxNtclwYIJH5LRcmZxG2 EhUrJGeB6Wlt3I/4jjfFECnILlsnJ11A+ZTfCPYbkYpuxO3hK8hLLcwMTdqppyNtfkdIsvt+7pqN 3QI65RJ5hbALmWQT3AqaGJlPWdTBNio1jOAf08vsSq85wgYIzmY1YWP8DiUlNWl8SADsS3n4x7FV a2nO9LeVZIFuqCYmwDERTaSaeKCVe4HOPYKc6F17zN4ZdkSXDndMgBF26kCCzG4AAAAAAAA= --Apple-Mail-147--613994212-- From ietfc@btconnect.com Fri Mar 11 03:08:13 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976563A68AA for ; Fri, 11 Mar 2011 03:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52t1Rgg1Cu-T for ; Fri, 11 Mar 2011 03:08:12 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 4826E3A6889 for ; Fri, 11 Mar 2011 03:08:11 -0800 (PST) Received: from host217-44-145-106.range217-44.btcentralplus.com (HELO pc6) ([217.44.145.106]) by c2beaomr10.btconnect.com with SMTP id CAK14245; Fri, 11 Mar 2011 11:09:23 +0000 (GMT) Message-ID: <01fd01cbdfd3$be1f31c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher Morrow" , "Yann Berthier" References: <20110307160613.GA31591@juniper.net> <20110308135934.GB28230@juniper.net> Date: Fri, 11 Mar 2011 11:04:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4D7A02E3.0060, actions=tag X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4D7A02E6.0115,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: sidr wg list Subject: Re: [sidr] rpki-rtr standard port X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 11:08:13 -0000 ----- Original Message ----- From: "Christopher Morrow" To: "Yann Berthier" Cc: "sidr wg list" Sent: Wednesday, March 09, 2011 3:39 AM > On Tue, Mar 8, 2011 at 8:44 PM, Yann Berthier wrote: > > > > On 2011-03-08, at 4:26 PM, Christopher Morrow wrote: > > > >>> so, i suggest asking the iana for a port number, one and only one. > >>> objections? > >> > >> I'm personally a fan of keeping things simple .... what's the beef > >> with tcp/22 here? > > > > The set of source IPs needing access to tcp/22 for mgmt may not be the same as the set of IPs needing access to tcp/22 for the rpki service > > > > A dedicated port for rpki seems a good idea > > don't disagree, just seeking some justification for the change. I came up with: > o diff hosts need ssh vs rpki-rtr (potentially off-net things?) > o ability to drop shields in case of problems but still maintain > management access > o qos/debugging reasons > o authentication requirements perhaps are different between user-ssh > && rpki-rtr I think that those are the reasons why a separate port is required. susbsystem is the standard SSH way of differentiating traffic but that is really the view of the implementer, of getting the end points of the session to the right place. Operationally, you need to be able to track the different traffic for the life of a session. RPKI is rather important, it should become critical to the Internet, so being able to offer it the best in operations seems a no brainer. As you say, filtering, performance, tracing for trouble shooting purposes, letting it through or not through firewalls etc, ... And I think it different to BGP in that it will span a wider network, whereas much of BGP is just about immediate neighbours, so there are likely to be more hops along the way where things could go wrong or need to be made right. With SNMP over SSH, there was a brief discussion about reusing the existing SNMP ports but it gained no support, rather that it was taken to be axiomatic that there would be a port, the debate being rather system or not, and one port or two (commands and notifications). Tom Petch > > randy came up with: 'maybe we don't trust the ssh code to do this > heavy lifting?' (or something similar) > > just hunting for the reason to be different. > > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Sun Mar 13 23:29:32 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B2D3A6ACE for ; Sun, 13 Mar 2011 23:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 GtE-wWxqG1KX for ; Sun, 13 Mar 2011 23:29:31 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id BE3E13A6A60 for ; Sun, 13 Mar 2011 23:29:31 -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 p2E6Uq9J015377; Mon, 14 Mar 2011 01:30:52 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p2E6UodC022337; Mon, 14 Mar 2011 01:30:50 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([68.55.40.223]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 02:30:49 -0400 Date: Mon, 14 Mar 2011 02:30:52 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Sean Turner In-Reply-To: <4D798C05.7080205@ieca.com> Message-ID: References: <20110222053002.8118.82908.idtracker@localhost> <4D798C05.7080205@ieca.com> X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Mar 2011 06:30:49.0819 (UTC) FILETIME=[5C212AB0:01CBE211] Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action:draft-ietf-sidr-repos-struct-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 06:29:33 -0000 Sean, you don't indicate whether you think a new version is needed before requesting publication. --Sandy On Thu, 10 Mar 2011, Sean Turner wrote: > Hi, > > I think this draft needs media type registrations for .mft and .roa. .cer and > .crl are already in RFC 2585. I think it needs media type registration > because every other draft I've ever seen that specifies a file extension does > so. RFC 2585 specifies .cer and .crl and they're in a media type > registration. Also, I got the impression that the repository draft can be > done in other ways and a media type would support other profiles of the > repository. > > http://tools.ietf.org/html/rfc4288 outlines the registration procedures. > We'll be in the application/* tree so it's standard tree and the procedures > are: > > Proposed registrations in the standards tree by other standards > bodies should be communicated to the IESG (at iesg@ietf.org) and to > the ietf-types list (at ietf-types@iana.org). > > During IETF LC make sure to ask the AD to copy ietf-types@iana.org. Here's > some suggested text for Section 7: > > 7. IANA Considerations > > IANA is requested to register the following two media types: > > application/rpki-manifest > application/rpki-roa > > This document also uses the .cer and .crl file extensions from > application/pkix-cert and application/pkix-crl media registries > defined in [RFC2585]. > > 7.1. application/rpki-manifest > > MIME media type name: application > > MIME subtype name: rpki-manifest > > Required parameters: None > > Optional parameters: None > > Encoding considerations: binary > > Security considerations: > > Carries a RPKI Manifest [I-D.ietf-sidr-rpki-manifests] > > Interoperability considerations: None > > Published specification: This document > > Applications which use this media type: Any MIME-complaint transport > > Additional information: > Magic number(s): None > File extension(s): .mft > Macintosh File Type Code(s): > > Person & email address to contact for further information: > Geoff Huston > > Intended usage: COMMON > > Author/Change controller: > Geoff Huston > > 7.2. application/rpki-roa > > MIME media type name: application > > MIME subtype name: rpki-roa > > Required parameters: None > > Optional parameters: None > > Encoding considerations: binary > > Security considerations: > > Carries a RPKI ROA [ID.ietf-sidr-roa-format] > > Interoperability considerations: None > > Published specification: This document > > Applications which use this media type: Any MIME-complaint transport > > Additional information: > Magic number(s): None > File extension(s): .roa > Macintosh File Type Code(s): > > Person & email address to contact for further information: > Geoff Huston > > Intended usage: COMMON > > Author/Change controller: > Geoff Huston > > Will also need to add a normative reference to the roa draft and to RFC 2585. > > spt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From turners@ieca.com Mon Mar 14 11:27:32 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E033A6B1E for ; Mon, 14 Mar 2011 11:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCUo+Li4Se13 for ; Mon, 14 Mar 2011 11:27:31 -0700 (PDT) Received: from nm24.bullet.mail.ac4.yahoo.com (nm24.bullet.mail.ac4.yahoo.com [98.139.52.221]) by core3.amsl.com (Postfix) with SMTP id 7E9D13A6E24 for ; Mon, 14 Mar 2011 11:27:30 -0700 (PDT) Received: from [98.139.52.192] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 14 Mar 2011 18:28:50 -0000 Received: from [98.139.52.145] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 14 Mar 2011 18:28:50 -0000 Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 14 Mar 2011 18:28:50 -0000 X-Yahoo-Newman-Id: 892284.88145.bm@omp1028.mail.ac4.yahoo.com Received: (qmail 16885 invoked from network); 14 Mar 2011 18:28:50 -0000 Received: from thunderfish.local (turners@96.231.119.32 with plain) by smtp115.biz.mail.re2.yahoo.com with SMTP; 14 Mar 2011 11:28:50 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 6.QtAJMVM1kioMdFWfB.sFvjV49xqhf6aBobBs8erYWkIbg lef14HnUpq8U1_OE66UbLiWn9xDJxCur_iLPDvMTeddm_M2rk0zzTpKx0Nkf bMSSxeQdl_eEe7vGdGodjR0mV4Q64Qowzti16ItyaOCBJ1uzP6ulfIoTVkFu aC_pXVKjydU6O7BxQX9idz_zS8WDWtSMXbP64XycJwRkcvWcAjo72heHj0eB kDixmuXUOgjEU2g6Pwtbhob4BNPplxZxAQlrZBDus4A.zVeQRC9qkFq.OXQi M1nFdhaFUVM9fmUMpXtHoOlnzcFOpvNtMhXYHe_7KDccyJ1OgaGAy7BM.XiQ vm_xY_q09PSeI_lQWGVB9Z45APJxvmULOnT6hPqyIppvOVxdMLlUMunTkF9y 7Z6E1BrO8.0Q9zsneJqogjGWt3s23_3S7LMLnHw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D7E5E62.8080402@ieca.com> Date: Mon, 14 Mar 2011 14:28:50 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sandra Murphy References: <20110222053002.8118.82908.idtracker@localhost> <4D798C05.7080205@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action:draft-ietf-sidr-repos-struct-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:27:32 -0000 The ietf-types folks get two weeks so running them in parallel with IETF LC would be best. Just remind Stewart in the proto write-up to ask them for the review. Note that I ran this by the Apps ADs. One said this looked fine (this doesn't mean that the reviewer will find something else), with one exception: Make the security considerations point to the appropriate documents. That is: Carries a RPKI Manifest. See [I-D.ietf-sidr-rpki-manifests]. and Carries a RPKI ROA. See [ID.ietf-sidr-roa-format]. spt On 3/14/11 2:30 AM, Sandra Murphy wrote: > Sean, you don't indicate whether you think a new version is needed > before requesting publication. > > --Sandy > > > On Thu, 10 Mar 2011, Sean Turner wrote: > >> Hi, >> >> I think this draft needs media type registrations for .mft and .roa. >> .cer and .crl are already in RFC 2585. I think it needs media type >> registration because every other draft I've ever seen that specifies a >> file extension does so. RFC 2585 specifies .cer and .crl and they're >> in a media type registration. Also, I got the impression that the >> repository draft can be done in other ways and a media type would >> support other profiles of the repository. >> >> http://tools.ietf.org/html/rfc4288 outlines the registration >> procedures. We'll be in the application/* tree so it's standard tree >> and the procedures are: >> >> Proposed registrations in the standards tree by other standards >> bodies should be communicated to the IESG (at iesg@ietf.org) and to >> the ietf-types list (at ietf-types@iana.org). >> >> During IETF LC make sure to ask the AD to copy ietf-types@iana.org. >> Here's some suggested text for Section 7: >> >> 7. IANA Considerations >> >> IANA is requested to register the following two media types: >> >> application/rpki-manifest >> application/rpki-roa >> >> This document also uses the .cer and .crl file extensions from >> application/pkix-cert and application/pkix-crl media registries >> defined in [RFC2585]. >> >> 7.1. application/rpki-manifest >> >> MIME media type name: application >> >> MIME subtype name: rpki-manifest >> >> Required parameters: None >> >> Optional parameters: None >> >> Encoding considerations: binary >> >> Security considerations: >> >> Carries a RPKI Manifest [I-D.ietf-sidr-rpki-manifests] >> >> Interoperability considerations: None >> >> Published specification: This document >> >> Applications which use this media type: Any MIME-complaint transport >> >> Additional information: >> Magic number(s): None >> File extension(s): .mft >> Macintosh File Type Code(s): >> >> Person & email address to contact for further information: >> Geoff Huston >> >> Intended usage: COMMON >> >> Author/Change controller: >> Geoff Huston >> >> 7.2. application/rpki-roa >> >> MIME media type name: application >> >> MIME subtype name: rpki-roa >> >> Required parameters: None >> >> Optional parameters: None >> >> Encoding considerations: binary >> >> Security considerations: >> >> Carries a RPKI ROA [ID.ietf-sidr-roa-format] >> >> Interoperability considerations: None >> >> Published specification: This document >> >> Applications which use this media type: Any MIME-complaint transport >> >> Additional information: >> Magic number(s): None >> File extension(s): .roa >> Macintosh File Type Code(s): >> >> Person & email address to contact for further information: >> Geoff Huston >> >> Intended usage: COMMON >> >> Author/Change controller: >> Geoff Huston >> >> Will also need to add a normative reference to the roa draft and to >> RFC 2585. >> >> spt >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > From Internet-Drafts@ietf.org Mon Mar 14 16:15:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B043A6EF3; Mon, 14 Mar 2011 16:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 RWFId5eByxjB; Mon, 14 Mar 2011 16:15:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E905F3A6F79; Mon, 14 Mar 2011 16:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314231501.3499.72867.idtracker@localhost> Date: Mon, 14 Mar 2011 16:15:01 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:15:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-11.txt Pages : 22 Date : 2011-03-14 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14160906.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 16:45:10 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A303A6FAD; Mon, 14 Mar 2011 16:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+IEbRCzzb9U; Mon, 14 Mar 2011 16:45:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD8F3A6FC2; Mon, 14 Mar 2011 16:45:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314234504.17995.74975.idtracker@localhost> Date: Mon, 14 Mar 2011 16:45:04 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ghostbusters-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:45:10 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI Ghostbusters Record Author(s) : R. Bush Filename : draft-ietf-sidr-ghostbusters-03.txt Pages : 7 Date : 2011-03-14 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information to be signed (indirectly) by a resource-owning certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-ghostbusters-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14164319.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Tue Mar 15 07:31:54 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59103A6D85; Tue, 15 Mar 2011 07:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 6nnOB0zIIWj6; Tue, 15 Mar 2011 07:31:54 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045693A6D27; Tue, 15 Mar 2011 07:31:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110315143154.15088.87614.idtracker@localhost> Date: Tue, 15 Mar 2011 07:31:54 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (A Profile for X.509 PKIX Resource Certificates) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 14:31:55 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'A Profile for X.509 PKIX Resource Certificates' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-res-certs/ This IETF Last Call is to draw the attention of the IETF to an additional downref in the draft that was noted during IESG review. Section 4.9.6 contains a reference to RFC5781. This reference has not been added to the references section of the draft, but will need to be a normative reference. As was noted in the previous IETF Last call this document also has a downref to RFC2986. No IPR declarations have been submitted directly on this I-D. From david.black@emc.com Fri Mar 18 18:38:33 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C99F3A69BA; Fri, 18 Mar 2011 18:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.446 X-Spam-Level: X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-0hTGzAR6Bt; Fri, 18 Mar 2011 18:38:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 5569D3A6A2D; Fri, 18 Mar 2011 18:38:32 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2J1dGcw019630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2011 21:39:16 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 18 Mar 2011 21:39:05 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2J1boO6021783; Fri, 18 Mar 2011 21:37:51 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Fri, 18 Mar 2011 21:37:50 -0400 From: To: , , , Date: Fri, 18 Mar 2011 21:37:49 -0400 Thread-Topic: Gen-ART review of draft-ietf-sidr-signed-object-03 Thread-Index: Acvl1kEzZp5/3+1tQ6Wkup9OI/E3Mg== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5DAD082@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: morrowc@ops-netman.net, david.black@emc.com, Sandra.Murphy@sparta.com, sidr@ietf.org Subject: [sidr] Gen-ART review of draft-ietf-sidr-signed-object-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 01:38:33 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-sidr-signed-object-03.txt Reviewer: David L. Black Review Date: March 18, 2011 IETF LC End Date: March 23, 2011 Please resolve these comments along with any other Last Call comments you m= ay receive. Summary: This draft is ready for publication as a Proposed Standard RFC. This draft specifies a template that is a profile of the CMS signed data ob= ject. The intent is that specifications for RPKI objects used for SIDR wil= l extend this template to specify the objects. This draft serves a valuabl= e function, in that most of the ASN.1 necessary to use CMS, including all o= f the signing syntax, is specified here as opposed to being left to the spe= cific object definitions, removing a number of opportunities for unintended= divergence. The draft was clearly written by experts in this area. I didn't find anythi= ng that appeared to need attention, and neither did idnits 2.12.08 . Kudos= to the authors - in my experience, drafts that are this clean are the exce= ption in Gen-ART reviews at IETF Last Call. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From wwwrun@core3.amsl.com Mon Mar 21 14:26:39 2011 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 91BC828C1A4; Mon, 21 Mar 2011 14:26:39 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110321212639.91BC828C1A4@core3.amsl.com> Date: Mon, 21 Mar 2011 14:26:39 -0700 (PDT) Cc: morrowc@ops-netman.net, Sandra.Murphy@sparta.com, sidr@ietf.org Subject: [sidr] WG Review: Recharter of Secure Inter-Domain Routing (sidr) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:26:39 -0000 A modified charter has been submitted for the Secure Inter-Domain Routing (sidr) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 29, 2011. Secure Inter-Domain Routing (sidr) ------------------------------------------------ Current Status: Active Working Group Last updated: 2011-03-09 Chairs: Sandra Murphy Chris Morrow Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing lists: Address: sidr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sidr Archive: http://www.ietf.org/mail-archive/web/sidr/ Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. The SIDR working group is charged with the following goals and milestones: ID Date Pub Date Mar 2011 Jan 2012 An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 Jun 2012 A document describing threats to the routing system Mar 2011 Jun 2012 A requirements document that addresses these threats Mar 2011 Jan 2012 Document the BGP protocol enhancements that meet the security requirements Nov 2010 Jul 2011 draft-ietf-sidr-origin-ops Mar 2011 Jul 2012 Operational deployment guidance for network operators Jun 2011 Dec 2011 System and architecture design choices made in the protocol and RPKI Mar 2010 Mar 2012 draft-ietf-sidr-cps-irs Mar 2010 Mar 2012 draft-ietf-sidr-cps-isp Nov 2010 Jan 2012 draft-ietf-sidr-pfx-validate Jan 2010 Jun 2011 draft-ietf-sidr-publication Nov 2010 Jun 2011 draft-ietf-sidr-repos-struct Nov 2010 Jun 2011 draft-ietf-sidr-roa-format Feb 2011 Jun 2011 draft-ietf-sidr-rpki-rtr Nov 2010 Nov 2011 draft-ietf-sidr-ltamgmt Dec 2010 Oct 2011 draft-rgaglian-sidr-algorithm-agility May 2011 Dec 2011 draft-ietf-sidr-usecases Jan 2011 Oct 2011 draft-ietf-sidr-ghostbusters Jan 2010 Dec 2011 draft-ietf-sidr-keyroll Jan 2010 May 2011 draft-ietf-sidr-arch Jan 2010 May 2011 draft-ietf-sidr-cp Jan 2010 May 2011 draft-ietf-sidr-res-certs Jan 2010 Jun 2011 draft-ietf-sidr-roa-validation Jan 2010 Jun 2011 draft-ietf-sidr-signed-object Jan 2010 Jun 2011 draft-ietf-sidr-rpki-manifests Jan 2010 Jul 2011 draft-ietf-sidr-rpki-algs Jan 2010 Jul 2011 draft-ietf-sidr-rescerts-provisioning Jan 2010 Aug 2011 draft-ietf-sidr-ta From holler_f@informatik.haw-hamburg.de Wed Mar 23 07:54:50 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7713A691D for ; Wed, 23 Mar 2011 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDKN0+pYI1v9 for ; Wed, 23 Mar 2011 07:54:49 -0700 (PDT) Received: from wp197.webpack.hosteurope.de (wp197.webpack.hosteurope.de [80.237.132.204]) by core3.amsl.com (Postfix) with ESMTP id 5B5CF3A684B for ; Wed, 23 Mar 2011 07:54:48 -0700 (PDT) Received: from e176153121.adsl.alicedsl.de ([85.176.153.121] helo=whiteshark.ath.cx); authenticated by wp197.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1Q2PTx-0007K9-KD; Wed, 23 Mar 2011 15:56:21 +0100 Date: Wed, 23 Mar 2011 15:56:19 +0100 From: holler_f@informatik.haw-hamburg.de To: sidr@ietf.org Message-ID: <20110323145619.GM73261@whiteshark.ath.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x38akuY2VS0PywU3" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-bounce-key: webpack.hosteurope.de; holler_f@informatik.haw-hamburg.de; 1300892183; 90917479; Subject: [sidr] rpki-rtr: query for certain records & more detailed certification status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:54:50 -0000 --x38akuY2VS0PywU3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I will start to work on a RTR C implementation soon and have 2 questions about the RTR draft: The current draft provides a mechanism to fetch all or a bulk of validated prefix origin records from the cache that have a serial number greater than X. Is there any discussion to extend the protocol later with: * a PDU to ask the cache for the validation list of a certain AS Number and/or Prefix? (instead of requesting _all_ data records from the cache) * a mechanism to provide a more detailed certification status for a prefix origin? ie: valid/invalid/no signature available? (maybe in the reserved field in the Prefix PDUs?) thanks for your help & best regards Fabian --x38akuY2VS0PywU3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2KChMACgkQeki1sRhDXQCj8wCgh+BswkTD2Fe/f2AcsqzY44Rf HWoAnjUM7ZVhBVJQU6s7knu4/2DBP+IV =ZnD5 -----END PGP SIGNATURE----- --x38akuY2VS0PywU3-- From randy@psg.com Wed Mar 23 10:02:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74A2F3A6938 for ; Wed, 23 Mar 2011 10:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IoaecpGTkLP for ; Wed, 23 Mar 2011 10:02:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id C598E3A6934 for ; Wed, 23 Mar 2011 10:02:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q2RRq-0000kq-Bz; Wed, 23 Mar 2011 17:02:18 +0000 Date: Wed, 23 Mar 2011 10:02:19 -0700 Message-ID: From: Randy Bush To: holler_f@informatik.haw-hamburg.de In-Reply-To: <20110323145619.GM73261@whiteshark.ath.cx> References: <20110323145619.GM73261@whiteshark.ath.cx> 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] rpki-rtr: query for certain records & more detailed certification status X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 17:02:02 -0000 > Is there any discussion to extend the protocol later with: > > * a PDU to ask the cache for the validation list of a certain AS > Number and/or Prefix? (instead of requesting _all_ data records from > the cache) > > * a mechanism to provide a more detailed certification status for a > prefix origin? ie: valid/invalid/no signature available? (maybe in > the reserved field in the Prefix PDUs?) no, there has not been. randy From Sandra.Murphy@cobham.com Fri Mar 25 08:20:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B7D28C112 for ; Fri, 25 Mar 2011 08:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 09Qla95Kpn91 for ; Fri, 25 Mar 2011 08:20:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9D7A128C106 for ; Fri, 25 Mar 2011 08:20:23 -0700 (PDT) Received: from Beta5.sparta.com ([157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p2PFLwDe011246 for ; Fri, 25 Mar 2011 10:21:58 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p2PFLw9u002297 for ; Fri, 25 Mar 2011 10:21:58 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([212.47.23.197]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Mar 2011 11:21:57 -0400 Date: Fri, 25 Mar 2011 11:21:58 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Mar 2011 15:21:58.0147 (UTC) FILETIME=[61AD5D30:01CBEB00] Subject: [sidr] new agenda uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 15:20:24 -0000 A new agenda was just uploaded. I belivee that it contains all the requests for agenda time. If I have missed an agenda item or if the time alloted or order or name or whatever is not appropriate, please reply to both wg chairs. --Sandy From Sandra.Murphy@cobham.com Sun Mar 27 17:19:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9163E3A6983 for ; Sun, 27 Mar 2011 17:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 4zI4SWkpMNpC for ; Sun, 27 Mar 2011 17:19:03 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2BD023A697F for ; Sun, 27 Mar 2011 17:19:02 -0700 (PDT) Received: from Beta5.sparta.com ([157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p2S0Kdk1004102 for ; Sun, 27 Mar 2011 19:20:39 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p2S0Kd1e016925 for ; Sun, 27 Mar 2011 19:20:39 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([130.129.68.12]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 20:20:38 -0400 Date: Sun, 27 Mar 2011 20:20:38 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Mar 2011 00:20:38.0976 (UTC) FILETIME=[F737FC00:01CBECDD] Subject: [sidr] ad-hoc RPKI workshop announcement X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Mar 2011 00:19:04 -0000 I am NOT speaking as wg chair here; I've just been requested to pass on this announcement. Everyone is invited to join an ad-hoc workshop in the terminal room on Tueday at 1:00pm. Rob Austein will lead the participants in using the RPKI implementation he's written (see https://subvert-rpki.hactrn.net). Full participation in the workshop will require a laptop (or remote access to a server somewhere) with your favorite flavor of unix. Versions known to have been tried, in order from well-used to have-one-report-of-use, are freebsd, macosx, linux fedora, linux ubuntu, linux debian, linux centos, linux gentoo. Sorry for the short notice. Rob says he was asked to do this for a few folk and decided he might as well let others in on the fun. Reply to me if you intend to come, for planning purposes if it looks like the terminal room is going to be overwhelmed. --Sandy, speaking as plain old sidr member, in plain old civilian mufti From Sandra.Murphy@cobham.com Mon Mar 28 08:58:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F094028C0D9 for ; Mon, 28 Mar 2011 08:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLhqvpuHW6J5 for ; Mon, 28 Mar 2011 08:58:52 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 21CD928C0D7 for ; Mon, 28 Mar 2011 08:58:52 -0700 (PDT) Received: from Beta5.sparta.com ([157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p2SG0TQX011260 for ; Mon, 28 Mar 2011 11:00:29 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p2SG0THI003039 for ; Mon, 28 Mar 2011 11:00:29 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([130.129.22.15]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Mar 2011 12:00:28 -0400 Date: Mon, 28 Mar 2011 12:00:29 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Mar 2011 16:00:29.0237 (UTC) FILETIME=[426EF650:01CBED61] Subject: [sidr] jabber scribe(s) and minute taker(s) X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 28 Mar 2011 15:58:53 -0000 I want to have volunteers identified ahead of time to do the jabber scribing and minute taking in the sidr meetings Thu and Fri. Note that it is not necessary that you volunteer for both sessions. Please respond to the list if you can undertake one of these duties. --Sandy From Sandra.Murphy@cobham.com Wed Mar 30 09:56:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3D33A6B9F for ; Wed, 30 Mar 2011 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, NO_DNS_FOR_FROM=1.496, 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 ZAbvo3maVHi1 for ; Wed, 30 Mar 2011 09:56:46 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 05FFD3A6B89 for ; Wed, 30 Mar 2011 09:56:43 -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 p2UGwM2K015446 for ; Wed, 30 Mar 2011 11:58:22 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p2UGwMPe025919 for ; Wed, 30 Mar 2011 11:58:22 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([130.129.22.15]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 12:58:21 -0400 Date: Wed, 30 Mar 2011 12:58:25 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 30 Mar 2011 16:58:22.0218 (UTC) FILETIME=[AD514EA0:01CBEEFB] Subject: [sidr] new agenda; new slides X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 30 Mar 2011 16:56:46 -0000 A new version of the agenda is available. I uploaded a new versions yesterday (the new version today was to change the presenter for one slot - Roque's wife had a blessed event and he will not be here). Note that our agenda is now pretty full. I invited a bunch of implementers of pieces of the RPKI specification set to talk about their implementations and got acceptance from about 8. So the final slot will be a bunch of short presentations (5 minutes strict limit) of those implementations. I have also uploaded the slides that I have received. If you sent me slides but you do not see them on the meeting materials site, or if you do not recognize the slides associated with your presentation, please respond. --Sandy From raszuk@cisco.com Thu Mar 31 01:49:49 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E323A6B2D for ; Thu, 31 Mar 2011 01:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnpREfclFPhF for ; Thu, 31 Mar 2011 01:49:48 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8153F3A6B2B for ; Thu, 31 Mar 2011 01:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=614; q=dns/txt; s=iport; t=1301561488; x=1302771088; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=vKTlesIxlT9GtdqnCdJkBDPsCEMuQXHem2hw9VsmPwU=; b=i+xIDM+s4H5isAjd23ii0kmhwMi4JUlexLKg02V1OGhz9XtIGYqmTkTP ZAJJRHEKTN0O1tmlfoflVybTxW6ePDambEgY7gIEDvJ5mMzg8btRtKcGo jtEH+qVX6oO945gXTs+rHDcFMvAAotlSe7iPTpHZBT49ARJZrDQIfLskx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABBAlE2rRDoH/2dsb2JhbAClT3eiP4JwDgGZBYVrBI0Rg1U X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="286372610" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 08:51:28 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2V8pRRS010755; Thu, 31 Mar 2011 08:51:27 GMT Message-ID: <4D944091.3050109@cisco.com> Date: Thu, 31 Mar 2011 10:51:29 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: sidr@ietf.org, Randy Bush Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Clarifying question ... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:49:49 -0000 Hi, If I am not mistaken there was a Randy's comment today at the mic indicating that an AS may consider a path origin validation as INVALID as compared to the peering AS just because the "RPKI may not be synchronized" Is this at all possible ? Doesn't RPKI already have been enhanced sufficiently to avoid mis-detections even in the AS migration cases ? Otherwise if this is a valid comment and if due to issues with RPKI sync ASes will even transiently be subject to wrong classifications of legitimate incoming paths I think there is a much bigger issue to worry about. Many thx, R. From randy@psg.com Thu Mar 31 01:54:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12F028C10E for ; Thu, 31 Mar 2011 01:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHdVLXlWjx-p for ; Thu, 31 Mar 2011 01:54:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id F15853A6969 for ; Thu, 31 Mar 2011 01:54:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5Dg2-000CI2-Js; Thu, 31 Mar 2011 08:56:27 +0000 Date: Thu, 31 Mar 2011 10:56:25 +0200 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4D944091.3050109@cisco.com> References: <4D944091.3050109@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 08:54:48 -0000 Robert Raszuk wrote: > > Hi, > > If I am not mistaken there was a Randy's comment today at the mic > indicating that an AS may consider a path origin validation as INVALID > as compared to the peering AS just because the "RPKI may not be > synchronized" > > Is this at all possible ? Doesn't RPKI already have been enhanced > sufficiently to avoid mis-detections even in the AS migration cases ? you may find the first para of section 6 of draft-ietf-sidr-origin-ops useful. to save you actually reading the draft Like the DNS, the global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, etc. Thus, one cache or router may have different data about a particular prefix than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches. rany From raszuk@cisco.com Thu Mar 31 02:00:28 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCA428C0F7 for ; Thu, 31 Mar 2011 02:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZOfzJgBNrSy for ; Thu, 31 Mar 2011 02:00:27 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7639C3A6BA8 for ; Thu, 31 Mar 2011 02:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1205; q=dns/txt; s=iport; t=1301562127; x=1302771727; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZYt6qzJJUNXXTSExHKFPi6RFhvO00ITGfHsa0ok40qQ=; b=erksbTT2Pncsn1UcffjzSGgc47hCgvflOxQcSqiOEa0u1KNbBe/794yX x3IrlEFq3Xd9zHZt2TuP4QgRSH+Y2jQHMmRPqcxvPqycooP0g3CKDTzAG rOchpby+UPVADS/uvM/81GdD4no9NRn0Q6kh5ptbyy6b7NKkVA67RUYuQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG9ClE2rRDoI/2dsb2JhbAClT3eIeZlWgnAOAZkGhWsEjRGDVQ X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="286378796" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 09:02:07 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2V925Le026960; Thu, 31 Mar 2011 09:02:06 GMT Message-ID: <4D94430F.6070606@cisco.com> Date: Thu, 31 Mar 2011 11:02:07 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Randy Bush References: <4D944091.3050109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying question ... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:00:28 -0000 Hi, Having different data is obvious. I am not saying this is a problem. Having data in one cache which will invalidate a valid prefix due to loose consistency is a problem. It has been pointed to Alvaro that he may indicate prefix as INVALID due to this reason. Thx, R.. > Robert Raszuk wrote: >> >> Hi, >> >> If I am not mistaken there was a Randy's comment today at the mic >> indicating that an AS may consider a path origin validation as INVALID >> as compared to the peering AS just because the "RPKI may not be >> synchronized" >> >> Is this at all possible ? Doesn't RPKI already have been enhanced >> sufficiently to avoid mis-detections even in the AS migration cases ? > > you may find the first para of section 6 of draft-ietf-sidr-origin-ops > useful. to save you actually reading the draft > > Like the DNS, the global RPKI presents only a loosely consistent > view, depending on timing, updating, fetching, etc. Thus, one cache > or router may have different data about a particular prefix than > another cache or router. There is no 'fix' for this, it is the > nature of distributed data with distributed caches. > > rany > From randy@psg.com Thu Mar 31 02:07:52 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C12728C1E5 for ; Thu, 31 Mar 2011 02:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eORmjJCDuf1E for ; Thu, 31 Mar 2011 02:07:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id CCE8928C1E1 for ; Thu, 31 Mar 2011 02:07:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5Dsh-000CLq-D6; Thu, 31 Mar 2011 09:09:31 +0000 Date: Thu, 31 Mar 2011 11:09:29 +0200 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4D94430F.6070606@cisco.com> References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 09:07:52 -0000 > Having data in one cache which will invalidate a valid prefix due to > loose consistency is a problem. It has been pointed to Alvaro that he > may indicate prefix as INVALID due to this reason. which people at the mic tried to point out in response to the signaling preso. randy From randy@psg.com Thu Mar 31 02:09:39 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4CC28C1F2 for ; Thu, 31 Mar 2011 02:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXfCvdMWlSa6 for ; Thu, 31 Mar 2011 02:09:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id E745828C22B for ; Thu, 31 Mar 2011 02:09:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5DuB-000CMb-GP; Thu, 31 Mar 2011 09:11:03 +0000 Date: Thu, 31 Mar 2011 11:11:02 +0200 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4D94430F.6070606@cisco.com> References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 09:09:39 -0000 > Having data in one cache which will invalidate a valid prefix due to > loose consistency is a problem. It has been pointed to Alvaro that he > may indicate prefix as INVALID due to this reason. or, to put it another way, this is what russ housley was trying to tell you. randy From raszuk@cisco.com Thu Mar 31 02:19:22 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6959328C0CF for ; Thu, 31 Mar 2011 02:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXVRgobPz25v for ; Thu, 31 Mar 2011 02:19:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 790FF28C0F7 for ; Thu, 31 Mar 2011 02:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=539; q=dns/txt; s=iport; t=1301563260; x=1302772860; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0zqPzsD9vE6oIqx2gqKgdImYBtn3SPtvqH4IWjJJ6PE=; b=hphw2W7Dd2jk13vKrShJoErKo/nC8hZAJNSEEo1FRvottIXmlUS5EF+R yzTc5U+eMlpEEbc6zBqQ+LtcseXSMFaVL9mUswZtaruVs51jwABMQpiop kvqhx8uGNY/1LFXmNpwUToGSCiIRPoc6h4GjgetCBEkB65OMEoYz6PoBC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABdHlE2rRDoG/2dsb2JhbAClT3eIeZlNgnAOAZkQhWsEjRGDVQ X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="286388080" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 09:20:50 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2V9KlmC006386; Thu, 31 Mar 2011 09:20:48 GMT Message-ID: <4D944771.8080106@cisco.com> Date: Thu, 31 Mar 2011 11:20:49 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Randy Bush References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying question ... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:19:22 -0000 It seems you are confirming that RPKI origin validation may very well turn Internet into a swiss cheese with transient short lived holes in it. I am not sure if this is an expected and well known issue by all parties. R. >> Having data in one cache which will invalidate a valid prefix due to >> loose consistency is a problem. It has been pointed to Alvaro that he >> may indicate prefix as INVALID due to this reason. > > which people at the mic tried to point out in response to the signaling > preso. > > randy > From randy@psg.com Thu Mar 31 02:32:34 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C76A28C227 for ; Thu, 31 Mar 2011 02:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iExzlm4MRD5q for ; Thu, 31 Mar 2011 02:32:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id A71EB3A6B00 for ; Thu, 31 Mar 2011 02:32:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5EGF-000CRo-H6; Thu, 31 Mar 2011 09:33:51 +0000 Date: Thu, 31 Mar 2011 11:33:50 +0200 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: <4D944771.8080106@cisco.com> References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 09:32:34 -0000 > It seems you are confirming that RPKI origin validation may very well > turn Internet into a swiss cheese with transient short lived holes in > it. no, it will maintain the bgp swiss cheese. i have a tee shirt which says "bgp never really converges." and this is a slight to the swiss, who have many wonderful cheeses randy From christopher.morrow@gmail.com Thu Mar 31 02:41:46 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1EB3A6A3D for ; Thu, 31 Mar 2011 02:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNuBXdYRJiST for ; Thu, 31 Mar 2011 02:41:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 97B903A68F6 for ; Thu, 31 Mar 2011 02:41:41 -0700 (PDT) Received: by wwa36 with SMTP id 36so1806682wwa.13 for ; Thu, 31 Mar 2011 02:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WaWV35zGjmn6je8hQr9qGSt5O9UBzLHmr2KfRS63OCY=; b=kWDYUvaQfUf4Nxex1xOmSwOuQ2ooLDDvNDPPFlHGUzAmSamZnYBLYmYflj20TBAQHR dNtpzcvk32hrxafpaTKADL8NytlcQY6UquS9jd9HDaza4ZVLfsDv+8RIYbsJWrCY2TKd Qa3nwAunJi5Y8LAazz5z2OzmBn07Y2rg4FeVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qQNGHdzC0TUEDDIz9uHLe1+W6Q+5IscL873F4DdApli+yyZFCqW+fiZJMgS+a63A3r mxBUn8kadjWN7C9xgtS5qv/Fz5DS9ZkVAEfc6j5Jhgh8bXaM7VHRujHKzDNEqqo8gIUK MzVu2L8grLMOCfSoQzQ8zLjJKFFY9JlU65obY= MIME-Version: 1.0 Received: by 10.216.254.82 with SMTP id g60mr2260569wes.90.1301564600356; Thu, 31 Mar 2011 02:43:20 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.185.16 with HTTP; Thu, 31 Mar 2011 02:43:20 -0700 (PDT) In-Reply-To: References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> Date: Thu, 31 Mar 2011 11:43:20 +0200 X-Google-Sender-Auth: l_slWV9R5S20t9EIlEbSaZHdBho Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 09:41:47 -0000 On Thu, Mar 31, 2011 at 11:33 AM, Randy Bush wrote: >> It seems you are confirming that RPKI origin validation may very well >> turn Internet into a swiss cheese with transient short lived holes in >> it. > > no, it will maintain the bgp swiss cheese. =A0i have a tee shirt which > says "bgp never really converges." this also seems (to me) to imply that 'invalid =3D=3D drop' policy is global, no? I suspect for a great long while 'invalid =3D=3D lowered pref' will predominate. Hopefully when we get more comfortable and more reasonable with operations of the rPKI we'll have less cheese to deal with. -chris (no chair clothing on) From randy@psg.com Thu Mar 31 02:47:24 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03D023A6957 for ; Thu, 31 Mar 2011 02:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf+WYFxXGOXU for ; Thu, 31 Mar 2011 02:47:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 42EC83A68F6 for ; Thu, 31 Mar 2011 02:47:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5EUv-000CVu-RF; Thu, 31 Mar 2011 09:49:02 +0000 Date: Thu, 31 Mar 2011 11:49:00 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 09:47:24 -0000 > this also seems (to me) to imply that 'invalid == drop' policy is > global, no? I suspect for a great long while 'invalid == lowered pref' > will predominate. Hopefully when we get more comfortable and more > reasonable with operations of the rPKI we'll have less cheese to deal > with. this was my original position, but [other] operators whacked me out of it. essentially the argument is, if you're not gonna drop something that is clearly invalid, then why the heck run it? and the rpki having all the consistency problems of a widely distributed database is not related to, or effected by, incremental deployment. randy From iesg-secretary@ietf.org Thu Mar 31 03:36:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F66C28C10C; Thu, 31 Mar 2011 03:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2p0ZO-oKjlM; Thu, 31 Mar 2011 03:36:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379F93A6B24; Thu, 31 Mar 2011 03:36:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110331103605.21654.33101.idtracker@localhost> Date: Thu, 31 Mar 2011 03:36:05 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Validation of Route Origination using the Resource Certificate PKI and ROAs) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 10:36:06 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Validation of Route Origination using the Resource Certificate PKI and ROAs' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-validation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-roa-validation/ An IPR disclosure related to this document can be found at http://datatracker.ietf.org/ipr/1204/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1204/ From christopher.morrow@gmail.com Thu Mar 31 04:13:13 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507C73A6B3B for ; Thu, 31 Mar 2011 04:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.455 X-Spam-Level: X-Spam-Status: No, score=-103.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqEHhlfm7G8P for ; Thu, 31 Mar 2011 04:13:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 607443A6AD9 for ; Thu, 31 Mar 2011 04:13:12 -0700 (PDT) Received: by wyb29 with SMTP id 29so2145321wyb.31 for ; Thu, 31 Mar 2011 04:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EzIsJ8R1nKFD58/wSJG91+lmnl4BXQg+m5dx40jVo+w=; b=XDYwk3E4A10TQ9nCtIluc/4IYuRwqxx7xEpYzNWfpRHVN650JshUyEyESRI4NSE4qw xBqLmqaq2+RaAGWKzYLfyWh2qV2lwjV6pOY5NbegOTPSyLF3jxbDvxH26KDpy8lpi8eN qhV+dwNopQwmA4GQQoYJ7S8OuZEHwK/9IDCnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OIibgut252EnlxnfU55IU/KYzGni6NFRL3ihyXnQvm4Jru2JnTnoPxCGtf0YMFzzeU OXJpixY4nmo1Kvy1APXLJGx1HA+E5KlOnp/PVh5SFeDIf9p9txSRtR1A0NzNuGGAZJ2F pWU2yk8P4V9o2pH81ZpdK+lohuhNi1RK9tyy8= MIME-Version: 1.0 Received: by 10.216.195.202 with SMTP id p52mr2360827wen.75.1301570091501; Thu, 31 Mar 2011 04:14:51 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.216.185.16 with HTTP; Thu, 31 Mar 2011 04:14:51 -0700 (PDT) In-Reply-To: References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> Date: Thu, 31 Mar 2011 13:14:51 +0200 X-Google-Sender-Auth: mPk_Tnjw80sIWBhQehvStN9Eda4 Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 11:13:13 -0000 On Thu, Mar 31, 2011 at 11:49 AM, Randy Bush wrote: >> this also seems (to me) to imply that 'invalid =3D=3D drop' policy is >> global, no? I suspect for a great long while 'invalid =3D=3D lowered pre= f' >> will predominate. Hopefully when we get more comfortable and more >> reasonable with operations of the rPKI we'll have less cheese to deal >> with. > > this was my original position, but [other] operators whacked me out of > it. =A0essentially the argument is, if you're not gonna drop something > that is clearly invalid, then why the heck run it? I may have 2 routes, which one is better? given all things equal i'd prefer 'valid' over 'invalid' origins. I'd even prefer a longer-as-path-valid-origin over short-as-path-invalid. I don't want to shut the door completely, I like having a choice. > and the rpki having all the consistency problems of a widely distributed > database is not related to, or effected by, incremental deployment. ok From randy@psg.com Thu Mar 31 04:21:15 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECB43A68B1 for ; Thu, 31 Mar 2011 04:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dNOTAGgEHcR for ; Thu, 31 Mar 2011 04:21:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id 474DF3A68B7 for ; Thu, 31 Mar 2011 04:21:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5FwW-000CqB-Vd; Thu, 31 Mar 2011 11:21:37 +0000 Date: Thu, 31 Mar 2011 13:21:34 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 11:21:15 -0000 > I don't want to shut the door completely, I like having a choice. you have the choice. i hope all my customers accept invalid routes randy From randy@psg.com Thu Mar 31 04:22:06 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC1C3A6B3C for ; Thu, 31 Mar 2011 04:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPnrkCiTnGlk for ; Thu, 31 Mar 2011 04:22:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by core3.amsl.com (Postfix) with ESMTP id BF7533A6B10 for ; Thu, 31 Mar 2011 04:22:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=dhcp-6391.meeting.ietf.org.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q5FxN-000CqV-GB; Thu, 31 Mar 2011 11:22:30 +0000 Date: Thu, 31 Mar 2011 13:22:27 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 11:22:07 -0000 [ let's try again ] > I don't want to shut the door completely, I like having a choice. you have the choice. i hope all my competitors accept invalid routes randy From dougm.tlist@gmail.com Thu Mar 31 04:44:57 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFAC28C0F0 for ; Thu, 31 Mar 2011 04:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnqLjCmS9Z-Z for ; Thu, 31 Mar 2011 04:44:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CB5843A6B3D for ; Thu, 31 Mar 2011 04:44:55 -0700 (PDT) Received: by wwa36 with SMTP id 36so1886821wwa.13 for ; Thu, 31 Mar 2011 04:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E3Jq362Q2N8Y1F6v7mLWG5fc7rRNWsnZje73yDhCuJA=; b=d9K4+DpA+sFVLdYT6Sk5NBntUapODwjk43W5jTZliYXOYmvB6XUDhzP34imwjqOYWF pq+WLd/J18m/wKIcuKnKTmpYav41BZ3mvFfXxJWrXpBwlAHPj92qjBJsKN7+e/kWJ3XI 0XdUfMASIEew3n9Y4mwTFCtCB/C+IqYJy7tUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Iqpkv7kyeCY/XSMCBbUb5ghwcskq0fq29f9US0ivthpXBmz2K3C37ONrWyEfDoR8yZ lgQ00WOJ5dRfJqEEY6cfmERUmvmmQ40Zp/66rVpU2gsX/98qIzWsM7jJxON3XmBJe1M+ /YiM9vgTOORbnez93qR8/r4hiS+V8ZXyWeh4k= Received: by 10.227.150.207 with SMTP id z15mr2612186wbv.149.1301571994777; Thu, 31 Mar 2011 04:46:34 -0700 (PDT) Received: from dhcp-151a.meeting.ietf.org (dhcp-151a.meeting.ietf.org [130.129.21.26]) by mx.google.com with ESMTPS id o23sm597346wbc.61.2011.03.31.04.46.33 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 04:46:33 -0700 (PDT) Message-ID: <4D946997.3080003@gmail.com> Date: Thu, 31 Mar 2011 07:46:31 -0400 From: Doug Montgomery User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sidr@ietf.org References: <4D944091.3050109@cisco.com> In-Reply-To: <4D944091.3050109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Clarifying 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, 31 Mar 2011 11:44:57 -0000 On 3/31/11 4:51 AM, Robert Raszuk wrote: > Hi, > > If I am not mistaken there was a Randy's comment today at the mic > indicating that an AS may consider a path origin validation as INVALID > as compared to the peering AS just because the "RPKI may not be > synchronized" > > Is this at all possible ? Doesn't RPKI already have been enhanced > sufficiently to avoid mis-detections even in the AS migration cases ? > > Otherwise if this is a valid comment and if due to issues with RPKI > sync ASes will even transiently be subject to wrong classifications of > legitimate incoming paths I think there is a much bigger issue to > worry about. > > Many thx, > R. If you think about the concatenated timing cycles of RPKI repository publication, polling intervals of validating caches, and notification intervals between caches and routers it is clear there will be (hopefully transient) incidents of RPKI state skew across the global net ... and in particular in the context of this draft, two neighboring eBGP speakers. Of course, beyond the timing effects of normal operations, reboots etc of routers/cache's/repositories could also cause these transients. When A sends and announcement to B, that B thinks has an invalid origin, it is not clear if it is A or B who has a stale view of the global RPKI (maybe A has not rsync'ed a recent CRL) or maybe they have a consistent view, it is just the case that A implements a policy that does not preclude selection of routes with invalid origins (e.g., it implements a preference for valid origins vs a policy that ignores invalid routes). While I am very supportive of the need for new diagnostics for BGP routing w/ ROA/RPKI processing there are some details of the draft that need some clarification. 1. As was pointed out at the mic, there is no way in the protocol to know if your peer has even tried to implement RPKI/ROA validation. While one could question if they would implement this new capability before they implemented ROA processing, you should address (a) if you will blindly send these messages to such a router, or (b) have some way of using the query feature to decide if you should bother your neighbor with these. 2. In the early days one might expect a few valid origins and ~300,000 unknows. While you note rate limiting these, one might recommend the ability to choose which validation codes you send diagnostics for. 3. The ROA validation drafts recognize 3 potential results - valid, invalid, unknown. Seems like your Method 1 validity codes should follow this. 4. It is not clear that routers that follow the rpki/rtr model (i.e., don't have a full RPKI cache, but instead just a white list) will have enough information to emit the reason codes specified for method 1 validity code 2 (i.e., invalid). dougm From gregory.cauchie@orange-ftgroup.com Thu Mar 31 04:48:20 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CE43A6AD9 for ; Thu, 31 Mar 2011 04:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_SHOP=2.3, MIME_8BIT_HEADER=0.3, 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 enYNl9-c6qTa for ; Thu, 31 Mar 2011 04:48:19 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id ED6BE3A68B7 for ; Thu, 31 Mar 2011 04:48:18 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 52E646D8003 for ; Thu, 31 Mar 2011 13:50:31 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 44F7E6C0001 for ; Thu, 31 Mar 2011 13:50:31 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 13:49:57 +0200 Received: from [10.193.106.106] ([10.193.106.106]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 13:49:57 +0200 Message-ID: <4D946A63.9040908@orange-ftgroup.com> Date: Thu, 31 Mar 2011 13:49:55 +0200 From: =?ISO-8859-1?Q?CAUCHIE_Gr=E9gory?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: sidr@ietf.org References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080503010304040208020509" X-OriginalArrivalTime: 31 Mar 2011 11:49:57.0151 (UTC) FILETIME=[C1D9EAF0:01CBEF99] Subject: Re: [sidr] Clarifying question ... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gregory.cauchie@orange-ftgroup.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:48:20 -0000 This is a cryptographically signed message in MIME format. --------------ms080503010304040208020509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 31/03/2011 13:22, Randy Bush a =E9crit : > [ let's try again ] > >> I don't want to shut the door completely, I like having a choice. > you have the choice. i hope all my competitors accept invalid routes > As a provider I have the same point of view as Randy. But then when we=20 talk about first deployments, it can be harmful to reject UPDATE=20 messages because there is some problem with the signature of the prefix=20 in a legitimate announcement. That's where the draft on security state diagnostic message by Alvaro=20 and Robert can be interesting in debugging such cases. However, I will=20 tend to limit the scope of such messages only to information pertaining=20 to the neighbouring AS (ie the prefixes it originates and maybe in the=20 future the AS_PATH its has signed, and not the prefixes signed by a=20 5-hop-far AS). Greg --------------ms080503010304040208020509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOHDCC BIgwggNwoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoT DkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFD IFJhY2luZTAeFw0wMjEwMDMwNzE1MjBaFw0xMjEwMDIwNzE1MjBaMFwxCzAJBgNVBAYTAkZS MRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UE AxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAPKErrcyQf+tgRGBsiBQKGGnvheMF+E74XARkkDrNnL/oA5w6e96Nj5eF7TdoiE7AIQR vOUrJkI9xP74szDUP/CPBPVxxL0855pyoH/qBcgdVCVWBDKGGroc9A5OeXsKCietb1y4+PV5 JeQVw3e41vqJ06Ut81QYPkZ84uJSIiRNoaZG+dBYBOfP8pL3Gj2jnX53eslfdiXjslMk7icb vcvAuBlzHU/LkLNHZV/iEJGGfj3X8kOMF0e3v1OlAX+TXEYlvA46wnffqVMIgiiFbAHPOBMI qOMOVQXx2SdokRcpAsHtb8LcaLrSseDf/bmzvhkufp6qYoUoNC9s4g48J9ECAwEAAaOCAVsw ggFXMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFKeHuNCL9G/jwcDa7Y604KcQKfzY MHwGA1UdIwR1MHOAFLdJ7pNBIn/ZqJeVJz5kZp6uGD8DoVikVjBUMQswCQYDVQQGEwJGUjEX MBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMxFzAVBgNVBAMT DkZUUkQgQUMgUmFjaW5lggEAMA4GA1UdDwEB/wQEAwIBBjCBgAYDVR0fBHkwdzA/oD2gO4Y5 aHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxyYWNpbmUu Y3JsMDSgMqAwhi5odHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5mci9jcmxyYWNpbmUu Y3JsMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAQEAto0WYTNPzNN/XrdT 255IwPKbYLZD/YRfQwwcbB4Ff6F9Km+J69KLpZZZx0Z/8rTsjVFc3A2QHTMy4OB2vJ1qPMUO +JlahqhHbun4GHxM0xl9qzGAaveo5xvIMqHYUnnRZ6s8LadQVbkcHxgw4oPkwRGbKoGyT6WE dFhWmn4BOBuwURN/JL4LynTkwHEklDbheEyAVTOrJIbZ88rWAKOoSzDhD+Wu/ZVvbcYuYNev qafJceD1g6rQhaz7O4HnGdmiau3/ayV7ZNDqxnm0Sfli4r4ltTi6GkxmEoT7X1JdKuH0na0Z dYRoqxRopM8uLsFMOHc46GT7HwsNcqXctRpORDCCBKIwggOKoAMCAQICAwCKZTANBgkqhkiG 9w0BAQUFADBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNV BAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwHhcNMTAw NzEyMTAzOTI0WhcNMTMwNzExMTAzOTI0WjCBojELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZy YW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFTUElDMRgwFgYDVQQDEw9HcmVnb3J5IENB VUNISUUxGDAWBgoJkiaJk/IsZAEBEwhHT0lDNzMwMDExMC8GCSqGSIb3DQEJARYiZ3JlZ29y eS5jYXVjaGllQG9yYW5nZS1mdGdyb3VwLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAt5FjyQyPyGn4d2i7iP9R6e3V+XWkmLUir7VkVtsyG+/2W/tas6gILdx6NKv30sfWQ3+g huBF+Pkhxh9qBy3vjLtKysYX1OYlEi3YRfus6MGAWu1+1updfKwQLZpZD5ctp8CYOXGS9F+S GW3Gf8EB1z+RB6LX2vxNBiN2XUXLz8UCAwEAAaOCAagwggGkMA8GA1UdDwEB/wQFAwMHMAAw EwYDVR0lBAwwCgYIKwYBBQUHAwQwHQYDVR0OBBYEFBAt5fHNt/+8hqAE+aZD4e4TEHOWMGMG A1UdIwRcMFqAFKeHuNCL9G/jwcDa7Y604KcQKfzYoT+BPUM9RlIsTz1GcmFuY2UgVGVsZWNv bSxPVT1GVFJELUFzcGljLENOPUZUUkQgQUMgb3BlcmF0aW9ubmVsbGWCAQEwgZIGA1UdHwSB ijCBhzBHoEWgQ4ZBaHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVl cy9jcmxvcGVyYXRpb25uZWxsZS5jcmwwPKA6oDiGNmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0 ZWxlY29tLmZyL2NybG9wZXJhdGlvbm5lbGxlLmNybDARBglghkgBhvhCAQEEBAMCBSAwUAYD VR0RBEkwR4EiZ3JlZ29yeS5jYXVjaGllQG9yYW5nZS1mdGdyb3VwLmNvbYEhZ3JlZ29yeS5j YXVjaGllQGZyYW5jZXRlbGVjb20uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQDEYI80Q1FsKFpy 0P7ugRdyAyrkpi38t0rcktZvM9mL3LL4GYSEn7QeZZdVz/iYiA+eCtQkQQL9HZTV2U+5ehn/ Lhb9AnUfdj9LeF4HuEjsulPiTJdtIJPAyskNPi+Q7RC5prJadXJ48LIQa9OXZF8R9oHs70/P Q/+r6GuAAS3+Ywzx8mS1HKHsMKW/WwrSUnh257UXLF++yfz5g0bjaJrEqDXXVxFBKwP76lYk FS2nDWLNceqtFlt4UlQ2rP112C+gW+qmmidKYZYdxj5KOtV1MB6h0euQrrpfI8Eiiaxlkrtd qyUckSCFke9tgd99FVZcvoPrvCf2SolNot1Dk4ExMIIE5jCCA86gAwIBAgIDAIpkMA0GCSqG SIb3DQEBBQUAMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEG A1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZTAeFw0x MDA3MTIxMDM5MjRaFw0xMzA3MTExMDM5MjRaMIGiMQswCQYDVQQGEwJGUjEXMBUGA1UEChMO RnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQVNQSUMxGDAWBgNVBAMTD0dyZWdvcnkg Q0FVQ0hJRTEYMBYGCgmSJomT8ixkAQETCEdPSUM3MzAwMTEwLwYJKoZIhvcNAQkBFiJncmVn b3J5LmNhdWNoaWVAb3JhbmdlLWZ0Z3JvdXAuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDWbC6qSGTDAlz7mVMPpr6JRIu058v6o2jnKOmqSNoMxMikiqRbXGNXZpaK5muLSWSe nn+teWuIfm4alQNgvSATFF0uvmxqSysTpdAGVsjiHJLzXmrQXK5y6BCSyyT3iixopWPMvUK1 JqhMdGkBvfUtlRdzlSXSsSoVfLUFR2tvcwIDAQABo4IB7DCCAegwDwYDVR0PAQH/BAUDAwfA ADApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0OBBYE FLurIHxEuJvLQPzIXhWcUyrFt+jUMGMGA1UdIwRcMFqAFKeHuNCL9G/jwcDa7Y604KcQKfzY oT+BPUM9RlIsTz1GcmFuY2UgVGVsZWNvbSxPVT1GVFJELUFzcGljLENOPUZUUkQgQUMgb3Bl cmF0aW9ubmVsbGWCAQEwgZIGA1UdHwSBijCBhzBHoEWgQ4ZBaHR0cDovL2x1Y2lmZXIucmQu ZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxvcGVyYXRpb25uZWxsZS5jcmwwPKA6oDiG Nmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0ZWxlY29tLmZyL2NybG9wZXJhdGlvbm5lbGxlLmNy bDARBglghkgBhvhCAQEEBAMCBaAwfgYDVR0RBHcwdaAsBgorBgEEAYI3FAIDoB4MHGdvaWM3 MzAwQHJkLmZyYW5jZXRlbGVjb20uZnKBImdyZWdvcnkuY2F1Y2hpZUBvcmFuZ2UtZnRncm91 cC5jb22BIWdyZWdvcnkuY2F1Y2hpZUBmcmFuY2V0ZWxlY29tLmNvbTANBgkqhkiG9w0BAQUF AAOCAQEAMjStlnSNuwD+8rrhh2x/MUitjMWsaZlkIw1K2TDhxlS8JVF+aY/Cls0fbdcQsw/J zrSFlzHC5cBqHyXvlTtj5cCva0/zlDTBhr+eDuyibyHxBYFvKVM37esX0d1ogl6Iwt1Lh3Yx houNe+5Krpd9NdSUMwX1oO+9VCO8I9cscCHGwTT5Yst8/RFdphZZo2JVVxdLBw6Wn9dNQUf7 Vpx8P1Dt5TRwkU+ByvIOCIGxbBvn8vGng0melSrRrccAKmFI1T5J122ewdaifQRDyd5N6T0a k0el5dKIs1Arxh+UpOpLFIv39VJqwoQ1t2XL7fduu7HBEnEwfoQt+PJnyfDcLTGCArUwggKx AgEBMGMwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQL EwpGVFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxlAgMAimQwCQYF Kw4DAhoFAKCCAagwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwMzMxMTE0OTU1WjAjBgkqhkiG9w0BCQQxFgQU/yeawePDDoWgUA3//dTtq+ClIikwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHIGCSsGAQQBgjcQBDFl MGMwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpG VFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxlAgMAimUwdAYLKoZI hvcNAQkQAgsxZaBjMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTET MBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZQID AIplMA0GCSqGSIb3DQEBAQUABIGAxFXaEnUdecINnD17CViD+BsX0SgpCYOZGLS+k2UkXtZR CjrOabizRvl1EOGKwSLSsp3aYulImceN/zu1/zzXjisQNx+m5mxlrdkEoYSxBFN1QdNYI8bw i1GqtZlbQNuEpF/UrWfa9+3PjBxIobHlSLMTF+6IX1vyKaA+mH5YwiAAAAAAAAA= --------------ms080503010304040208020509-- From raszuk@cisco.com Thu Mar 31 04:57:14 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3816328C14F for ; Thu, 31 Mar 2011 04:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.404 X-Spam-Level: X-Spam-Status: No, score=-9.404 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4xEcaDPF36f for ; Thu, 31 Mar 2011 04:57:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BD6623A6875 for ; Thu, 31 Mar 2011 04:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=raszuk@cisco.com; l=1510; q=dns/txt; s=iport; t=1301572732; x=1302782332; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b/WuW478o1z6HDMQeRN0a7jLg443G7uM2QvnrmDh7I8=; b=Lfcy4YoBPub075TqcqolqFvfUJ42TSYMkOgOYhOb6URt+600H1BlLiDl Xr42y8bCkVUJJboOXJrVk73N9mNAhKepb2kGBhYttmiPgJyFvgDDwhaH8 SGPvJBXAwNwidsXfEJ3xg0plqFBzFPStu8ONKQigqupaIrbHHlzHZ7hu0 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0HAFtslE2rRDoG/2dsb2JhbACYTI0Bd4h5mWiCcA4BmRGFawSNEYNV X-IronPort-AV: E=Sophos;i="4.63,275,1299456000"; d="scan'208";a="673711577" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2011 11:58:42 +0000 Received: from [10.21.106.8] (sjc-vpnasa-517.cisco.com [10.21.106.8]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2VBwftg020841; Thu, 31 Mar 2011 11:58:42 GMT Message-ID: <4D946C73.2090302@cisco.com> Date: Thu, 31 Mar 2011 13:58:43 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: gregory.cauchie@orange-ftgroup.com References: <4D944091.3050109@cisco.com> <4D94430F.6070606@cisco.com> <4D944771.8080106@cisco.com> <4D946A63.9040908@orange-ftgroup.com> In-Reply-To: <4D946A63.9040908@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sidr@ietf.org Subject: Re: [sidr] Clarifying question ... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:57:14 -0000 Hi Grégory, > tend to limit the scope of such messages only to information > pertaining to the neighbouring AS (ie the prefixes it originates > and maybe in the future the AS_PATH its has signed, and not the > prefixes signed by a 5-hop-far AS). This is actually a very useful idea reg the scoping of what given peer should get as part of this diagnostic message. We will incorporate this to make sure that implementations do allow to configure such scope. Many thx, R. > Le 31/03/2011 13:22, Randy Bush a écrit : >> [ let's try again ] >> >>> I don't want to shut the door completely, I like having a choice. >> you have the choice. i hope all my competitors accept invalid routes >> > As a provider I have the same point of view as Randy. But then when we > talk about first deployments, it can be harmful to reject UPDATE > messages because there is some problem with the signature of the prefix > in a legitimate announcement. > That's where the draft on security state diagnostic message by Alvaro > and Robert can be interesting in debugging such cases. However, I will > tend to limit the scope of such messages only to information pertaining > to the neighbouring AS (ie the prefixes it originates and maybe in the > future the AS_PATH its has signed, and not the prefixes signed by a > 5-hop-far AS). > > Greg > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Thu Mar 31 08:16:54 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4503A680E; Thu, 31 Mar 2011 08:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P2ViHJ6azHs; Thu, 31 Mar 2011 08:16:53 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 5110E3A6AD7; Thu, 31 Mar 2011 08:16:50 -0700 (PDT) Received: by wwk4 with SMTP id 4so5326212wwk.1 for ; Thu, 31 Mar 2011 08:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=phZ3FjTlDskgjA6rBqxPdXAY/z1O35b6VKCUHaPNpk8=; b=O+1LHbsRcqXivOjOQiwqkGEjA93xGa37zbqbrdrgn0tp5tPyS2fnUxAsabwh0nMhaK bAp4gSSe+8QEBGcUOKi2Z2AM5QiOcGW65GMTW7FA2sq/Kmu1Y4/rbzxpBMTrHheecuFt 5lST2bdwgBrQvHG+PXfeXZM0bYykmsv5tV4xw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jyfzA60l8FKHlhU7nz81Sbgf4+2EhGcKQKDYzB3Q1ir0OjwhtHV+eF7KmpOqa56P49 6fRQriPfqqv+xZi/rrB2FtW9+kcGi+U6OiZIfV/LT+HMfvizWQmhqPL2SQOCkNo5wKnq rgSKz8A9qzcodpjVV8+b1lqcc89+PfdVl6p7Q= MIME-Version: 1.0 Received: by 10.216.244.6 with SMTP id l6mr2157742wer.60.1301584709357; Thu, 31 Mar 2011 08:18:29 -0700 (PDT) Received: by 10.216.185.16 with HTTP; Thu, 31 Mar 2011 08:18:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 17:18:29 +0200 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:16:54 -0000 for the record, this concluded with a single set of comments that the authors addressed... so it's falling to the next line of process stakes: iesg review. -Chris On Wed, Feb 16, 2011 at 7:39 PM, Christopher Morrow wrote: > Ok folk, > The rpki-rtr document: > =A0 > > went through WGLC on version ~02, it's since had a slight mod (added a > Cache-nonce added) which is here in section 4.1: > > "The Cache Nonce reassures the router that the serial numbers are > =A0 comensurate, i.e. the cache session has not been changed." > > and again in 4.2: > "The Cache Nonce tells the cache what instance the router expects to > =A0 ensure that the serial numbers are comensurate, i.e. the cache > =A0 session has not been changed." > > and again in 4.4: > "In response to a Reset Query, the Cache Nonce tells the router the > =A0 instance of the cache session for future confirmation. =A0In response > =A0 to a Serial Query, the Cache Nonce reassures the router that the > =A0 serial numbers are comensurate, i.e. the cache session has not been > =A0 changed." > > and again in 4.7: > "The Cache Nonce MUST be the same as that of the corresponding Cache > =A0 Response which began the, possibly null, sequence of data PDUs." > > There's not much meat to the actual change, and the authors identified > the problem on their own. So, in the spirit of valentines day, let's > decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move > forward. If there are no further comments/issues I'll push this > version out over the weekend to the AD's as a publication request. > > -Chris > > From sebastian.spies@nist.gov Thu Mar 31 08:45:34 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B2E3A6B13 for ; Thu, 31 Mar 2011 08:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V30ZsmQpbiK8 for ; Thu, 31 Mar 2011 08:45:34 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id CAA303A6B0E for ; Thu, 31 Mar 2011 08:45:33 -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 p2VFl2Ix017252 for ; Thu, 31 Mar 2011 11:47:02 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 31 Mar 2011 11:47:02 -0400 From: "Spies, Sebastian Martin" To: "sidr@ietf.org" Date: Thu, 31 Mar 2011 11:47:00 -0400 Thread-Topic: draft-ietf-sidr-roa-format ASN1-format Thread-Index: Acvvut/CAsv2N4JFTA6SJhynvcwFaQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sebastian.spies@nist.gov Subject: [sidr] draft-ietf-sidr-roa-format ASN1-format X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Mar 2011 15:45:34 -0000 The AFI of ROAIPAddress (defined in 3. The ROA eContent of draft-ietf-sidr-roa-format) is of type OCTET STRING (SIZE (2..3)). For which reason is it necessary to have a variable AFI size? We are having just two values 0001 and 0002 and it is unlikely to see new address families at a count that exceeds 2^16. So why should there be a third byte? ---- Sebastian Spies From andy@arin.net Thu Mar 31 10:01:18 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FF33A6A33 for ; Thu, 31 Mar 2011 10:01:18 -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 YXTRfQ1AftRh for ; Thu, 31 Mar 2011 10:01:17 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by core3.amsl.com (Postfix) with ESMTP id C2DB53A6A63 for ; Thu, 31 Mar 2011 10:01:15 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 354C6213625; Thu, 31 Mar 2011 13:02:55 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id DEB9C213623; Thu, 31 Mar 2011 13:02:54 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 31 Mar 2011 13:02:40 -0400 Received: from CHAXCH01.corp.arin.net ([169.254.1.110]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.01.0270.001; Thu, 31 Mar 2011 13:02:54 -0400 From: Andy Newton To: "Spies, Sebastian Martin" Thread-Topic: [sidr] draft-ietf-sidr-roa-format ASN1-format Thread-Index: Acvvut/CAsv2N4JFTA6SJhynvcwFaQALB/YA Date: Thu, 31 Mar 2011 17:02:53 +0000 Message-ID: <58DFC632-0D8A-4C47-92EC-9B8699F2481F@arin.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B0A99107F64474394302A9635296855@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] draft-ietf-sidr-roa-format ASN1-format X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 31 Mar 2011 17:01:18 -0000 On Mar 31, 2011, at 11:47 AM, Spies, Sebastian Martin wrote: > The AFI of ROAIPAddress (defined in 3. The ROA eContent of draft-ietf-sid= r-roa-format) is of type OCTET STRING (SIZE (2..3)). For which reason is it= necessary to have a variable AFI size? We are having just two values 0001 = and 0002 and it is unlikely to see new address families at a count that exc= eeds 2^16. So why should there be a third byte? I believe this is represented the same way as it is in RFC 3779. Section 2.= 3.3: IPAddressFamily ::=3D SEQUENCE { -- AFI & optional SAFI -- addressFamily OCTET STRING (SIZE (2..3)), ipAddressChoice IPAddressChoice } -andy= From christopher.morrow@gmail.com Thu Mar 31 15:27:25 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5BC28C10D; Thu, 31 Mar 2011 15:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mteSLJCUaOCe; Thu, 31 Mar 2011 15:27:24 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 414473A698F; Thu, 31 Mar 2011 15:27:24 -0700 (PDT) Received: by eye13 with SMTP id 13so1012110eye.31 for ; Thu, 31 Mar 2011 15:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=NL5iNxFVmox5ZbVKALSvYzmoc4ppStfoxodsQEuZFtI=; b=agqhGEaIC2N3Am1nPdmyuZLnGIqT1VK2PGEAc1DyeSzKxqYc5ivxj1o1Aj7ZFbaeJm s8TO4fXbJqbwqxTxByq22Es+OfoNMgrMJiGYPKIP1zr6oyeFw1MGkg2+Q4BZYNTLDqZZ 1t185OLVRApxk+QC7RhZU7aXRim1i+J/vuYME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RxKG+OStmyU6FVAU5M3XgzRYwXeOu8VujnO+072ivMUeGgDDbS9XS6ZLIJLAX7lcXD O7HpARQHhYDcvg5aPmFK0FrNDD0Q1/gt11XETGxLz+cJdqrcQx8RR4UaWIMvyeEz3dhN SoCoLfPjf/qNP+jFQArTyzOmT8e78qJAG023U= MIME-Version: 1.0 Received: by 10.213.111.13 with SMTP id q13mr2031142ebp.31.1301610541986; Thu, 31 Mar 2011 15:29:01 -0700 (PDT) Received: by 10.213.4.132 with HTTP; Thu, 31 Mar 2011 15:29:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Apr 2011 00:29:01 +0200 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 22:27:25 -0000 So, I should have waited until after the thurs meeting content settled... Before sending this blithely off to the AD's for processing. The room discussion about this draft wended it's way into: "Is SSH as a transport really necessary?" and: "Well, we like ssh because we understand it... well, maybe we just need something like md5 or AO?" and ended with: "Hey, AO may be acceptable, we can chat more about this, and potentially add it if people think it's of interest?" That said I quickly looked around for 'open source plaforms with AO support= ': only mentions MD5. I don't see support for AO in FreeBSD, though my fbsd-foo is ... poor. Do we want to rev the draft and add AO as an option for the transport? or just stick with SSH? -Chris On Thu, Mar 31, 2011 at 5:18 PM, Christopher Morrow wrote: > for the record, this concluded with a single set of comments that the > authors addressed... so it's falling to the next line of process > stakes: iesg review. > > -Chris > > On Wed, Feb 16, 2011 at 7:39 PM, Christopher Morrow > wrote: >> Ok folk, >> The rpki-rtr document: >> =A0 >> >> went through WGLC on version ~02, it's since had a slight mod (added a >> Cache-nonce added) which is here in section 4.1: >> >> "The Cache Nonce reassures the router that the serial numbers are >> =A0 comensurate, i.e. the cache session has not been changed." >> >> and again in 4.2: >> "The Cache Nonce tells the cache what instance the router expects to >> =A0 ensure that the serial numbers are comensurate, i.e. the cache >> =A0 session has not been changed." >> >> and again in 4.4: >> "In response to a Reset Query, the Cache Nonce tells the router the >> =A0 instance of the cache session for future confirmation. =A0In respons= e >> =A0 to a Serial Query, the Cache Nonce reassures the router that the >> =A0 serial numbers are comensurate, i.e. the cache session has not been >> =A0 changed." >> >> and again in 4.7: >> "The Cache Nonce MUST be the same as that of the corresponding Cache >> =A0 Response which began the, possibly null, sequence of data PDUs." >> >> There's not much meat to the actual change, and the authors identified >> the problem on their own. So, in the spirit of valentines day, let's >> decide by Friday Feb 18, 2011 23:59 UTC if things are still ok to move >> forward. If there are no further comments/issues I'll push this >> version out over the weekend to the AD's as a publication request. >> >> -Chris >> >> > From sra@hactrn.net Thu Mar 31 23:13:23 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5CE3A6BEC for ; Thu, 31 Mar 2011 23:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.294 X-Spam-Level: X-Spam-Status: No, score=-102.294 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, 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 6ZnJ2fhYEQnP for ; Thu, 31 Mar 2011 23:12: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 29EC13A6BF2 for ; Thu, 31 Mar 2011 23:12:46 -0700 (PDT) Received: from nargothrond.hactrn.net (dhcp-434c.meeting.ietf.org [130.129.67.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 557C02845C; Fri, 1 Apr 2011 06:14:20 +0000 (UTC) Received: from nargothrond.hactrn.net (localhost [IPv6:::1]) by nargothrond.hactrn.net (Postfix) with ESMTP id E4491678F39; Fri, 1 Apr 2011 08:14:17 +0200 (CEST) Date: Fri, 01 Apr 2011 08:14:17 +0200 From: Rob Austein To: "Spies, Sebastian Martin" In-Reply-To: <58DFC632-0D8A-4C47-92EC-9B8699F2481F@arin.net> References: <58DFC632-0D8A-4C47-92EC-9B8699F2481F@arin.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20110401061417.E4491678F39@nargothrond.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-sidr-roa-format ASN1-format X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 01 Apr 2011 06:13:23 -0000 At Thu, 31 Mar 2011 17:02:53 +0000, Andy Newton wrote: > > On Mar 31, 2011, at 11:47 AM, Spies, Sebastian Martin wrote: > > > The AFI of ROAIPAddress (defined in 3. The ROA eContent of > > draft-ietf-sidr-roa-format) is of type OCTET STRING (SIZE > > (2..3)). For which reason is it necessary to have a variable AFI > > size? We are having just two values 0001 and 0002 and it is > > unlikely to see new address families at a count that exceeds > > 2^16. So why should there be a third byte? > > I believe this is represented the same way as it is in RFC 3779. Section 2.3.3: > > IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI -- > addressFamily OCTET STRING (SIZE (2..3)), > ipAddressChoice IPAddressChoice } Yes, that byte is the optional SAFI. At least, that's how all the running code of which I'm aware interprets it. At present we're only certifying AFIs 1 and 2 with null SAFI, hence the text in section 3.3. The text should say that the third byte is the SAFI. Good catch.