From kent@bbn.com Mon May 4 05:32:50 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B633A6C06 for ; Mon, 4 May 2009 05:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 68egcEEnIJOW for ; Mon, 4 May 2009 05:32:49 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id C985D3A6906 for ; Mon, 4 May 2009 05:32:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M0xN8-0006s5-Fg for sidr@ietf.org; Mon, 04 May 2009 08:34:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> Date: Mon, 4 May 2009 08:34:12 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [sidr] GOST & 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: Mon, 04 May 2009 12:32:50 -0000 I have been ion vacation (yes, again) so I'm very late to this discussion. I think there are some valid issues being raised, and some red herrings. Yes, we need to accommodate algorithm agility. I believe that the formats of all of our data structures already do this, i.e., they explicitly state which algorithms were used for signing and hashing the objects in question. I am not convinced that the S/MIME cert extension is applicable here. My recollection is that this extension is intended to convey algorithm capabilities of a recipient to a prospective sender, so that the sender can select appropriate algorithms to use in protecting a message. Thus the info being communicated is relevant to the set of senders who communicate with a given recipient. The (public) RPKI context is different; every relying party (primarily ISPs) MUST be able to process the signed objects generated by every cert issuer (primarily ISPs). We have not documented how one would transition from one algorithm suite to another, given our syntactic ability to express the old and new suites. I agree with Russ's observation that this need not be solved immediately, since we have a while before it is likely that we will need to do that. Joel's observation that this may require parallel sets of certs is certainly one way to do this, and it may be the one we adopt. That solution is messy, as Randy noted, but not impossible to accommodate. Sandy noted that islands of RPKI use could employ different algorithms without affecting everybody else. That is true, and is relevant for closed RPKI contexts of the sort that we have discussed. However, this is different from the public RPKI use that is the primary motivation for this work. I think we need to be more careful in our documents to distinguish between these two cases, i.e., the public RPKI context and private RPKI contexts. The message that triggered this thread was prompted by comments from Dimitri, and his concern is different from all of the discussion that followed on the list. What Dimitri was proposing is that the architecture allow country-specific algorithm choices for the (public) RPKI. I think this is a very bad idea. If we agree to do this, then there is no limit to the set of algorithms that may need to be supported in software (and, eventually, in router hardware), and that is not a reasonable outcome. The (public) RPKI is global in its scope. Thus if different countries elect to employ different algorithms these countries are imposing a burden on the rest of the relying parties (all other ISPs in the world). Or, as someone noted, the allocations and origin AS info associated with the ISPs in these countries will be ignored by others. Neither if these is a good outcome. The PKI standards produced by PKIX do not specify any mandatory to implement algorithms. This is because those standards are generic and may often be used in closed PKIs where the algorithm choices have only local impact. This is not true for the RPKI. In this context, a mandatory to implement set of algorithms is necessary, and that is what has been specified in the cert profile, and maybe in some other documents. I agree that we should consolidate the specification of this algorithm suite, so that when new algorithms are agreed upon for use in the RPKI, the number of documents that need be changed will be minimized. Probably the preferred solution here is to focus the algorithm specs in the CP, and have the cert/CRL profile, and the ROA and manifest specs reference the CP. We also need to better distinguish the one public RPKI from private RPKI contexts. For example, a private RPKI context probably need not abide by the same CP as the public RPKI, and thus there is no need for these folks to put the public RPKI policy OID in certs used exclusively in that context. Steve From Sandra.Murphy@cobham.com Mon May 4 06:54:24 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C0C3A6ADC for ; Mon, 4 May 2009 06:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 mt2QzDPu4A3i for ; Mon, 4 May 2009 06:54:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5E66E3A691C for ; Mon, 4 May 2009 06:54:23 -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 n44DtfEo021554; Mon, 4 May 2009 08:55:41 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n44Dtf4n011206; Mon, 4 May 2009 08:55:41 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([10.0.0.30]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 09:55:40 -0400 Date: Mon, 4 May 2009 09:55:39 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 04 May 2009 13:55:40.0908 (UTC) FILETIME=[02C5E2C0:01C9CCC0] Cc: sidr@ietf.org Subject: Re: [sidr] GOST & 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: Mon, 04 May 2009 13:54:24 -0000 Steve, welcome back from your vacation. Thank you for your comments. For one thing, they provide a synopsis of the arguments put forth up to this point. Perhaps it is a good thing to have someone summarize an argument chain occasionally, and if that means sending someone on vacation, that's tolerable, right? I would like to clarify one of your comments: >The PKI standards produced by PKIX do not specify any mandatory to >implement algorithms. This is because those standards are generic and may >often be used in closed PKIs where the algorithm choices have only local >impact. This is not true for the RPKI. In this context, a mandatory to >implement set of algorithms is necessary, and that is what has been >specified in the cert profile, and maybe in some other documents. The cert profile currently says that the one algorithm suite is a MUST, which I believe means that certs using other algs would be non-compliant. I see a difference between that statement and making one algorithm a mandatory-to-implement. Do you? Can you say which you think is the better approach? --Sandy On Mon, 4 May 2009, Stephen Kent wrote: > I have been ion vacation (yes, again) so I'm very late to this discussion. I > think there are some valid issues being raised, and some red herrings. > > Yes, we need to accommodate algorithm agility. I believe that the formats of > all of our data structures already do this, i.e., they explicitly state which > algorithms were used for signing and hashing the objects in question. > > I am not convinced that the S/MIME cert extension is applicable here. My > recollection is that this extension is intended to convey algorithm > capabilities of a recipient to a prospective sender, so that the sender can > select appropriate algorithms to use in protecting a message. Thus the info > being communicated is relevant to the set of senders who communicate with a > given recipient. The (public) RPKI context is different; every relying party > (primarily ISPs) MUST be able to process the signed objects generated by > every cert issuer (primarily ISPs). > > We have not documented how one would transition from one algorithm suite to > another, given our syntactic ability to express the old and new suites. I > agree with Russ's observation that this need not be solved immediately, since > we have a while before it is likely that we will need to do that. Joel's > observation that this may require parallel sets of certs is certainly one way > to do this, and it may be the one we adopt. That solution is messy, as Randy > noted, but not impossible to accommodate. > > Sandy noted that islands of RPKI use could employ different algorithms > without affecting everybody else. That is true, and is relevant for closed > RPKI contexts of the sort that we have discussed. However, this is different > from the public RPKI use that is the primary motivation for this work. I > think we need to be more careful in our documents to distinguish between > these two cases, i.e., the public RPKI context and private RPKI contexts. > > The message that triggered this thread was prompted by comments from Dimitri, > and his concern is different from all of the discussion that followed on the > list. What Dimitri was proposing is that the architecture allow > country-specific algorithm choices for the (public) RPKI. I think this is a > very bad idea. If we agree to do this, then there is no limit to the set of > algorithms that may need to be supported in software (and, eventually, in > router hardware), and that is not a reasonable outcome. > > The (public) RPKI is global in its scope. Thus if different countries elect > to employ different algorithms these countries are imposing a burden on the > rest of the relying parties (all other ISPs in the world). Or, as someone > noted, the allocations and origin AS info associated with the ISPs in these > countries will be ignored by others. Neither if these is a good outcome. > > The PKI standards produced by PKIX do not specify any mandatory to implement > algorithms. This is because those standards are generic and may often be used > in closed PKIs where the algorithm choices have only local impact. This is > not true for the RPKI. In this context, a mandatory to implement set of > algorithms is necessary, and that is what has been specified in the cert > profile, and maybe in some other documents. I agree that we should > consolidate the specification of this algorithm suite, so that when new > algorithms are agreed upon for use in the RPKI, the number of documents that > need be changed will be minimized. Probably the preferred solution here is to > focus the algorithm specs in the CP, and have the cert/CRL profile, and the > ROA and manifest specs reference the CP. > > We also need to better distinguish the one public RPKI from private RPKI > contexts. For example, a private RPKI context probably need not abide by the > same CP as the public RPKI, and thus there is no need for these folks to put > the public RPKI policy OID in certs used exclusively in that context. > > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kent@bbn.com Mon May 4 07:02:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B743A6F1F for ; Mon, 4 May 2009 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 ba6DhSx+vjRw for ; Mon, 4 May 2009 07:02:38 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6BD503A6ADC for ; Mon, 4 May 2009 07:02:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1M0ym2-0003Ms-BZ; Mon, 04 May 2009 10:04:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> Date: Mon, 4 May 2009 10:04:00 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] GOST & 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: Mon, 04 May 2009 14:02:39 -0000 At 9:55 AM -0400 5/4/09, Sandra Murphy wrote: >Steve, welcome back from your vacation. > >Thank you for your comments. For one thing, they provide a synopsis >of the arguments put forth up to this point. Perhaps it is a good >thing to have someone summarize an argument chain occasionally, and >if that means sending someone on vacation, that's tolerable, right? It's a tough approach to the problem, but I'm happy to make the sacrifice :-). > >I would like to clarify one of your comments: > >>The PKI standards produced by PKIX do not specify any mandatory to >>implement algorithms. This is because those standards are generic and may >>often be used in closed PKIs where the algorithm choices have only local >>impact. This is not true for the RPKI. In this context, a mandatory to >>implement set of algorithms is necessary, and that is what has been >>specified in the cert profile, and maybe in some other documents. > >The cert profile currently says that the one algorithm suite is a >MUST, which I believe means that certs using other algs would be >non-compliant. I see a difference between that statement and making >one algorithm a mandatory-to-implement. Do you? Can you say which >you think is the better approach? For the public RPKI, we need a (very short) list of mandatory to implement algorithms, and a statement about which algorithms MUST be used at any point in time. I think the cert profile (and the ROA and manifest docs) should remove all algorithm references, and have the CP specify algorithm mandates. Steve From root@core3.amsl.com Mon May 25 17:15:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 926AF3A6E71; Mon, 25 May 2009 17:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090526001501.926AF3A6E71@core3.amsl.com> Date: Mon, 25 May 2009 17:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-bogons-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 00:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Bogon Origin Attestations (BOAs) Author(s) : T. Manderson Filename : draft-ietf-sidr-bogons-03.txt Pages : 14 Date : 2009-05-25 This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorised any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA. A BOA also provides a means of verifying that a BGP speaker is not using an AS without appropriate authority. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of the Border Gateway Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bogons-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-bogons-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-25171350.I-D@ietf.org> --NextPart-- From gih@apnic.net Tue May 26 13:37:35 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063EC3A6B43 for ; Tue, 26 May 2009 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkqawwxMlyyn for ; Tue, 26 May 2009 13:37:34 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id EC7733A67DD for ; Tue, 26 May 2009 13:37:33 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DCD46110068; Wed, 27 May 2009 06:39:12 +1000 (EST) Message-Id: <561CF52A-FFDE-409A-81B4-0A68F5C73718@apnic.net> From: Geoff Huston To: Sandy Murphy Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 06:39:12 +1000 X-Mailer: Apple Mail (2.935.3) Cc: sidr@ietf.org Subject: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 May 2009 20:37:35 -0000 Hi Sandy, WG co-chair hat OFF. Following the WG discussion on the topic of ROA validation at IETF 74 the draft's authors gained the impression that the rough consensus position from the last SIDR WG meeting was to drop to drop the concept of BOAs and use only ROAs. The authors have prepared a revision to the WG document that reflects that understanding. However, the authors would like to confirm that impression with yourself as the relevant co- chair and with the WG, via this note, before submitting this document as draft-ietf-sidr-roa-validation-02.txt. You, and WG members of course, can review the proposed revisions to the WG document that reflect what the authors believe is the WG's rough consensus position on this topic at draft-huston-sidr-roa-validation-01.txt thanks, Geoff Huston & George Michaelson From sra@hactrn.net Tue May 26 14:55:10 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559823A6C0F for ; Tue, 26 May 2009 14:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js2p0V9CLBYK for ; Tue, 26 May 2009 14:55:09 -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 707473A6B57 for ; Tue, 26 May 2009 14:55:09 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 8B2D928450 for ; Tue, 26 May 2009 21:56:49 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4712822809 for ; Tue, 26 May 2009 17:56:49 -0400 (EDT) Date: Tue, 26 May 2009 17:56:49 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <561CF52A-FFDE-409A-81B4-0A68F5C73718@apnic.net> References: <561CF52A-FFDE-409A-81B4-0A68F5C73718@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090526215649.4712822809@thrintun.hactrn.net> Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 May 2009 21:55:10 -0000 At Wed, 27 May 2009 06:39:12 +1000, Geoff Huston wrote: > ... > You, and WG members of course, can review the proposed revisions to > the WG document that reflect what the authors believe is the WG's > rough consensus position on this topic at > draft-huston-sidr-roa-validation-01.txt I've skimmed the new version and think this is a major improvement. Thanks, guys! Nit: there's a vestigial mention of BOAs at the start of section 2 (clearly just an editing oversight, given the other changes). --Rob From terry.mndrsn@gmail.com Tue May 26 16:39:37 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3783A69EB for ; Tue, 26 May 2009 16:39:37 -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=[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 7t-xM0GZlqv5 for ; Tue, 26 May 2009 16:39:36 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id E93E23A6822 for ; Tue, 26 May 2009 16:39:35 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1214322fge.18 for ; Tue, 26 May 2009 16:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=AUbnO4GhP8Un5QIfWSkQ5VsiCxenK0lZ+iTv8Vv518w=; b=eRv3sanEvJNefsAdWEyzfIip0ZKfTmjAPAnPeZXp7BqwTmW+AKkAEktwcu4c0O2Xum lA6QGbK3LiYOA3EYtWnIR6Fwk7xvQSz2VxiezBiobzzxA61pHuNazOpBlPj5S4n8oURS 3SW8F2E+XSMBRNdgho37bNiplpPNU77w/sUcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=jZtb8/SAab7TWYahLzWpLF1l/timpc/cY1fhxOroHIR6lOvG1E2s6bkoEBh5PuuDYf q0hlJnafy5IS2Q086NjYyMY1Uz31UctrM/Uuj4w26WMdKequ7EZasO7wpYPSwfuwEzGL RLLvyOePL3N2usixzq/PJpUaeUhCaFiUkZ4KI= Received: by 10.86.4.7 with SMTP id 7mr7562683fgd.46.1243381259110; Tue, 26 May 2009 16:40:59 -0700 (PDT) Received: from ?192.168.1.101? ([114.77.128.245]) by mx.google.com with ESMTPS id d6sm14322989fga.17.2009.05.26.16.40.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 26 May 2009 16:40:57 -0700 (PDT) Sender: Terry Manderson Message-Id: From: Terry Manderson To: Geoff Huston In-Reply-To: <561CF52A-FFDE-409A-81B4-0A68F5C73718@apnic.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 27 May 2009 09:40:49 +1000 References: <561CF52A-FFDE-409A-81B4-0A68F5C73718@apnic.net> X-Mailer: Apple Mail (2.930.3) Cc: sidr@ietf.org, Sandy Murphy Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 May 2009 23:39:37 -0000 On 27/05/2009, at 6:39 AM, Geoff Huston wrote: > Hi Sandy, > > WG co-chair hat OFF. > > Following the WG discussion on the topic of ROA validation at IETF > 74 the draft's authors gained the > impression that the rough consensus position from the last SIDR WG > meeting was to drop to drop the concept of BOAs and use only ROAs. Please be clear that impression is only that of the authors of the ROA validation draft and any others that may be against the idea of saying "no, this resource may not be routed". I don't recall a 'raise hands' or 'hum' call for dropping the BOA idea at the WG. Perhaps that question can be asked at Stockholm, however I think the observation raised in IETF 74, that without well defined use cases which would lead to what objects (and functions) are appropriate, it is amazingly premature to drop the BOA concept midway. Fine to suggest it - but understand the reasons why. My personal observation of IETF 74 was a glaring misunderstanding of the concept of negative attestation versus contradictory attestation. A negative attestation like that provided by a BOA is a perfectly valid and well used security construct. In fact, every security product in existence uses it. Should RPKI not have such an ability leaves it bereft of the expected controls that a resource holder may need. An additional (personal) observation is that the BOA in its original form was far reaching and usurped the make before break concept. This is rectified in the latest revision draft-ietf-sidr-bogons-03.txt to allow only the valid resource holder to make such statements. > The authors have prepared a revision to the WG document that > reflects that understanding. However, the authors would like to > confirm that impression with yourself as the relevant co-chair and > with the WG, via this note, before submitting this document as draft- > ietf-sidr-roa-validation-02.txt. You, and WG members of course, can > review the proposed revisions to the WG document that reflect what > the authors believe is the WG's rough consensus position on this > topic at draft-huston-sidr-roa-validation-01.txt However - that said, I think untangling the BOA from ROA validation is the right thing to do, just not for the reasons you state. ROAs are the higher order object, any other RPKI object in a make before break paradigm must be in deference to the ROA. Terry From danny@tcb.net Wed May 27 09:22:04 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066873A6AA6 for ; Wed, 27 May 2009 09:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0scxCRDjdRH for ; Wed, 27 May 2009 09:22:03 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 50A393A6883 for ; Wed, 27 May 2009 09:22:03 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 72B8B2684EA; Wed, 27 May 2009 10:23:26 -0600 (MDT) Received: from 10-1-15-14.aa.arbor.net (division.aa.arbor.net [204.181.64.3]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 27 May 2009 10:23:26 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: sidr@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 10:23:07 -0600 X-Mailer: Apple Mail (2.935.3) Subject: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 16:22:04 -0000 Folks, One of the primary misconfiguration modes that happens today (and I experienced first hand ~15 years ago) is route leaks where a customer becomes transit between a set of peers. That is, customer A is connected to ISP 1 and gets a new connection to ISP 2. When ISP 2 is turning up the session they don't apply any ingress policy set for explicit prefix or AS path filtering initially, but they do tag the routes as customer routes (which they often prefer over routes from bilateral peers). The result is that all the traffic in the ISP 2 -> ISP 1 direction is forwarded through Customer A. With a strict origin-only validation model the origin and prefix are preserved, only the AS path changes. This vulnerability can obviously be crafted to launch various types of wide-spread or targeted attacks, and the current solutions here provide no protection mechanisms whatsoever for this. The reality is that origin validation is critical, but unless coupled with some mechanism to automate and protect against leaks (intentional or not), then there's a huge hole in the solutions space. I know this was debated quite a bit a while back (well, i.e., path v. origin) but wanted to see how folks envision this being addressed with the current work underway.. Thoughts? -danny From jared@puck.nether.net Wed May 27 09:28:09 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779803A6ECE for ; Wed, 27 May 2009 09:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 ikVmNQTQTq6u for ; Wed, 27 May 2009 09:28:08 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 6BB613A6BD6 for ; Wed, 27 May 2009 09:28:08 -0700 (PDT) Received: from rev-204-42-254-133.dhcp.nether.net (rev-204-42-254-133.dhcp.nether.net [204.42.254.133]) (authenticated bits=0) by puck.nether.net (8.14.3/8.12.9) with ESMTP id n4RGTgJu084159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 May 2009 12:29:42 -0400 (EDT) (envelope-from jared@puck.nether.net) From: Jared Mauch To: Danny McPherson In-Reply-To: References: Message-Id: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 12:29:39 -0400 X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (puck.nether.net [204.42.254.5]); Wed, 27 May 2009 12:29:42 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 16:28:09 -0000 On May 27, 2009, at 12:23 PM, Danny McPherson wrote: > > Folks, > One of the primary misconfiguration modes that happens > today (and I experienced first hand ~15 years ago) is > route leaks where a customer becomes transit between a > set of peers. > > That is, customer A is connected to ISP 1 and gets a > new connection to ISP 2. When ISP 2 is turning up the > session they don't apply any ingress policy set for > explicit prefix or AS path filtering initially, but they > do tag the routes as customer routes (which they often > prefer over routes from bilateral peers). The result > is that all the traffic in the ISP 2 -> ISP 1 direction > is forwarded through Customer A. > > With a strict origin-only validation model the origin > and prefix are preserved, only the AS path changes. > This vulnerability can obviously be crafted to launch > various types of wide-spread or targeted attacks, and > the current solutions here provide no protection mechanisms > whatsoever for this. > > The reality is that origin validation is critical, but > unless coupled with some mechanism to automate and > protect against leaks (intentional or not), then there's > a huge hole in the solutions space. I know this was debated > quite a bit a while back (well, i.e., path v. origin) but > wanted to see how folks envision this being addressed with > the current work underway.. > > Thoughts? This happens a lot. I have a large set of data over the past years that is collected here: http://puck.nether.net/bgp/leakinfo.cgi There is constant noise visible. The currently visible problem set can be resolved with presently available tools (eg: better bgp policy w/ communities). There is very little incentive for providers to fix this. We constantly have leaks with some customers leaking their transit-learned path for a customer of theirs. - Jared From danny@tcb.net Wed May 27 09:31:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EAFB3A6CE1 for ; Wed, 27 May 2009 09:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7hsUGw3C2Xy for ; Wed, 27 May 2009 09:31:55 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 251003A6882 for ; Wed, 27 May 2009 09:31:55 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 3F28E2684EA; Wed, 27 May 2009 10:32:58 -0600 (MDT) Received: from 10-1-15-14.aa.arbor.net (division.aa.arbor.net [204.181.64.3]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 27 May 2009 10:32:57 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: Jared Mauch In-Reply-To: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 10:32:38 -0600 References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> X-Mailer: Apple Mail (2.935.3) Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 16:31:56 -0000 On May 27, 2009, at 10:29 AM, Jared Mauch wrote: > > This happens a lot. I have a large set of data over the past years > that is collected here: > > http://puck.nether.net/bgp/leakinfo.cgi > > There is constant noise visible. The currently visible problem set > can be resolved with presently available tools (eg: better bgp > policy w/ communities). And I'm saying if SIDR doesn't protect against this, and it happens a lot, then we're leaving a very large void. > There is very little incentive for providers to fix this. Right, until it's used to launch a targeted attack against a target someone cares about. To say there's no incentive to fix this is to say there's no incentive for SIDR. > We constantly have leaks with some customers leaking their transit- > learned path for a customer of theirs. That was my experience as well... -danny From jared@puck.nether.net Wed May 27 10:44:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E523A6A77 for ; Wed, 27 May 2009 10:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 GtFGyPiOEbcC for ; Wed, 27 May 2009 10:44:43 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id D40A03A698B for ; Wed, 27 May 2009 10:44:42 -0700 (PDT) Received: from rev-204-42-254-133.dhcp.nether.net (rev-204-42-254-133.dhcp.nether.net [204.42.254.133]) (authenticated bits=0) by puck.nether.net (8.14.3/8.12.9) with ESMTP id n4RHkEdt030415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 May 2009 13:46:22 -0400 (EDT) (envelope-from jared@puck.nether.net) From: Jared Mauch To: Danny McPherson In-Reply-To: References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> Message-Id: <94307F66-4D8C-4111-920B-039AFB2D9485@puck.nether.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 13:46:13 -0400 X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (puck.nether.net [204.42.254.5]); Wed, 27 May 2009 13:46:22 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 17:44:44 -0000 On May 27, 2009, at 12:32 PM, Danny McPherson wrote: > > On May 27, 2009, at 10:29 AM, Jared Mauch wrote: > >> >> This happens a lot. I have a large set of data over the past years >> that is collected here: >> >> http://puck.nether.net/bgp/leakinfo.cgi >> >> There is constant noise visible. The currently visible problem set >> can be resolved with presently available tools (eg: better bgp >> policy w/ communities). > > And I'm saying if SIDR doesn't protect against this, and > it happens a lot, then we're leaving a very large void. The challenge is building the appropriate layers of defense. We have some defenses in our network to prevent these leaks. They are not perfect. I wish we could express the complex policies consistently across our network, but it's not possible without significant sacrifices to route cpu. When they cross the line to customer impacting, we lose. >> There is very little incentive for providers to fix this. > > Right, until it's used to launch a targeted attack against > a target someone cares about. To say there's no incentive > to fix this is to say there's no incentive for SIDR. There will always be people who will invest in these technologies, even if there is no payoff. I wouldn't go so far as to say there's no incentive for SIDR. Defense in depth/layered approach seems sensible to me, there is a more complex issue of getting people to deploy what the current best- practices are. This is common throughout all unregulated industries. - Jared From Sandra.Murphy@cobham.com Wed May 27 10:56:25 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B873A6D64 for ; Wed, 27 May 2009 10:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 0HGiUUf-oJam for ; Wed, 27 May 2009 10:56:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 6664A28B56A for ; Wed, 27 May 2009 10:56:23 -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 n4RHvsJS025897; Wed, 27 May 2009 12:57:54 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n4RHvrND000387; Wed, 27 May 2009 12:57:53 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.209]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 13:57:52 -0400 Date: Wed, 27 May 2009 13:57:51 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: Message-ID: References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 May 2009 17:57:52.0230 (UTC) FILETIME=[A79DE860:01C9DEF4] Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 17:56:25 -0000 On Wed, 27 May 2009, Danny McPherson wrote: > > On May 27, 2009, at 10:29 AM, Jared Mauch wrote: > >> >> This happens a lot. I have a large set of data over the past years that is >> collected here: >> >> http://puck.nether.net/bgp/leakinfo.cgi >> >> There is constant noise visible. The currently visible problem set can be >> resolved with presently available tools (eg: better bgp policy w/ >> communities). > > And I'm saying if SIDR doesn't protect against this, and > it happens a lot, then we're leaving a very large void. Danny is right that fixing only origination is not complete protection. But it is not possible to fix the path problem without fixing the origin problem first. Any check of the validity of the path has to start with the validity of the origin. So we're doing the first step first and we will need to do the next step next. And I'd say that the largest void is mis-origination, so IMHO we are working on the biggest problem first. --Sandy > >> There is very little incentive for providers to fix this. > > Right, until it's used to launch a targeted attack against > a target someone cares about. To say there's no incentive > to fix this is to say there's no incentive for SIDR. > >> We constantly have leaks with some customers leaking their transit-learned >> path for a customer of theirs. > > > That was my experience as well... > > -danny > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Wed May 27 12:41:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2354A3A6E92 for ; Wed, 27 May 2009 12:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APxqfATZcI4y for ; Wed, 27 May 2009 12:41:55 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 6F89E3A6A7E for ; Wed, 27 May 2009 12:41:55 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C4D6C2684EA; Wed, 27 May 2009 13:43:11 -0600 (MDT) Received: from 10-1-15-14.aa.arbor.net (division.aa.arbor.net [204.181.64.3]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 27 May 2009 13:43:11 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: sidr@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 27 May 2009 13:42:30 -0600 References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 19:41:56 -0000 On May 27, 2009, at 11:57 AM, Sandra Murphy wrote: > Danny is right that fixing only origination is not complete > protection. > > But it is not possible to fix the path problem without fixing the > origin problem first. Any check of the validity of the path has to > start with the validity of the origin. > > So we're doing the first step first and we will need to do the next > step next. I don't think anything I said diverged from any of the above. I just don't want folks to confuse the current efforts here with solving this problem, and would like to ensure that no solution here is complete until we address the path problem as well. > And I'd say that the largest void is mis-origination, so IMHO we are > working on the biggest problem first. I'm not sure about that argument. It's more like we're putting bars on the windows and leaving the doors wide open, but everyone is entitled to their opinion :-) -danny From gih@apnic.net Wed May 27 13:16:46 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6EB3A6BAB for ; Wed, 27 May 2009 13:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-0myWDhgbYk for ; Wed, 27 May 2009 13:16:45 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id 071D83A69CA for ; Wed, 27 May 2009 13:16:44 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A665A11006B; Thu, 28 May 2009 06:18:24 +1000 (EST) Message-Id: From: Geoff Huston To: Danny McPherson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 06:18:23 +1000 References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> X-Mailer: Apple Mail (2.935.3) Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 20:16:46 -0000 On 28/05/2009, at 5:42 AM, Danny McPherson wrote: > > On May 27, 2009, at 11:57 AM, Sandra Murphy wrote: > >> Danny is right that fixing only origination is not complete >> protection. >> >> But it is not possible to fix the path problem without fixing the >> origin problem first. Any check of the validity of the path has to >> start with the validity of the origin. >> >> So we're doing the first step first and we will need to do the next >> step next. > > I don't think anything I said diverged from any of the above. > I just don't want folks to confuse the current efforts here with > solving this problem, and would like to ensure that no solution > here is complete until we address the path problem as well. > >> And I'd say that the largest void is mis-origination, so IMHO we >> are working on the biggest problem first. > > I'm not sure about that argument. It's more like we're > putting bars on the windows and leaving the doors wide open, > but everyone is entitled to their opinion :-) The original plot was that path validation would be passed to SIDR once RPSEC had managed to reach some form of consensus about what was the requirement with respect to path validation. From the charter: " The SIDR working group will develop security mechanisms which fulfill those requirements which have been agreed on by the RPSEC working group. In developing these mechanisms, the SIDR working group will take practical deployability into consideration. " The best that RPSEC could come up with (after some years) on the requirements realted to AS Path validation was : "AS_PATH Feasibility Check: The AS_PATH list may correspond to a valid list of autonomous systems according to the first verification category listed in the "Areas to Secure" Section above. Further study will determine the extent to which this is a security requirement." So the options available to SIDR do not look overly inviting right now in terms of having a clear understanding ot what approach should be used for AS Path validation. The SIDR WG could: a) rerun the RPSEC debate on the topic (ugh) b) do nothing (hmm) c) do something else (???) So its not exactly like we're doing task A and then heading on in an orderly manner to tackle task B. The problem is that while we have clear requirements for origination to work to, while the requirements for path validation remain unclear, and the last group to attempt such clarification got badly bogged. Geoff From Sandra.Murphy@cobham.com Wed May 27 13:29:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EE4C3A6DAD for ; Wed, 27 May 2009 13:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 5H0ZFI8qgF+3 for ; Wed, 27 May 2009 13:29:18 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 438B43A68C4 for ; Wed, 27 May 2009 13:29:18 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n4RKUxTg029117; Wed, 27 May 2009 15:30:59 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n4RKUs87008107; Wed, 27 May 2009 15:30:54 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.209]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 16:30:53 -0400 Date: Wed, 27 May 2009 16:30:51 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: Message-ID: References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 May 2009 20:30:53.0839 (UTC) FILETIME=[084841F0:01C9DF0A] Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 27 May 2009 20:29:19 -0000 On Wed, 27 May 2009, Danny McPherson wrote: > > On May 27, 2009, at 11:57 AM, Sandra Murphy wrote: > >> Danny is right that fixing only origination is not complete protection. >> >> But it is not possible to fix the path problem without fixing the origin >> problem first. Any check of the validity of the path has to start with the >> validity of the origin. >> >> So we're doing the first step first and we will need to do the next step >> next. > > I don't think anything I said diverged from any of the above. > I just don't want folks to confuse the current efforts here with > solving this problem, and would like to ensure that no solution > here is complete until we address the path problem as well. I agree that the problem is bigger than the origin authorization that sidr is working on. However, please remember that origin authorization is the first step to full path protection, so everything we do here is vital and necessary. Process-wise, the sidr charter does not talk about working on a solution to the path problem. It talks about working on a solution to the origin problem. At the time of chartering, the RPSEC group was tasked with establishing the BGP security requirements. It was pretty clear at the time that the only consensus in that working group was on securing the origin, so that was all that the sidr charter specifically mentioned. Because origin authorization protection had to be done as the first step toward path authorization, this was not wasted effort. The charter says that we are tasked to work on RPSEC established requirements. That left an opening for RPSEC to establish more than origin authorization as a security requirement. But then RPSEC sputtered and died, without even publishing a draft that said that origin authorization was a requirement, much less saying anything about path authorization. So to address anything beyond origin authorization, we need to re-charter, or open a new working group. But the first step, the vital step, the necessary step, is the work we are doing right now on origin authorization. > >> And I'd say that the largest void is mis-origination, so IMHO we are >> working on the biggest problem first. > > I'm not sure about that argument. It's more like we're > putting bars on the windows and leaving the doors wide open, > but everyone is entitled to their opinion :-) No, we're talking about putting bars on the outside door and when we are done there we will proceed to put bars on interior doors. Doing path authorization WITHOUT origin authorization is a protected structure built on sand. Useless, wasted effort. The origin authorization has to be done first. FIRST. Vital. Necessary. Can't be skipped. The base case. We must do this. We need this - it is not a choice. OK? --Sandy > > -danny > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Thu May 28 17:25:00 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958963A696A for ; Thu, 28 May 2009 17:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NCNgkHOSKLJ for ; Thu, 28 May 2009 17:25:00 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id EC0D93A68BE for ; Thu, 28 May 2009 17:24:59 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 65E992684EA; Thu, 28 May 2009 18:26:43 -0600 (MDT) Received: from [10.1.0.106] (69.150.142.130 [69.150.142.130]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Thu, 28 May 2009 18:26:43 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=69.150.142.130; client-port=55337; syn-fingerprint=65535:52:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <3479D20C-249B-4E6A-940E-4ED8D6E3680B@tcb.net> From: Danny McPherson To: sidr@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 18:22:34 -0600 References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 29 May 2009 00:25:00 -0000 On May 27, 2009, at 2:30 PM, Sandra Murphy wrote: > The origin authorization has to be done first. FIRST. Vital. > Necessary. Can't be skipped. The base case. We must do this. We > need this - it is not a choice. Again, I never said it was. What I said is that if the aim here is to actually secure the routing system then we need to squarely address the path issue as well, or ALL the vulnerabilities that exist today pretty much remain with only origin authorization - and if they remain, it's unlikely operators are going to jump through hoops to solve 10% of the problem. That said, if SIDR is only concerned with development and specification of an RPKI for origin authorization, and BGP security and future employment of that will address the rest of the problem, that mostly makes sense to me - but I don't want folks to be confused about what SIDR is and is not doing. -danny From danny@tcb.net Thu May 28 17:30:16 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A033A696A for ; Thu, 28 May 2009 17:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSltQqMllx9i for ; Thu, 28 May 2009 17:30:16 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7A1913A67F3 for ; Thu, 28 May 2009 17:30:16 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 27E3E2684EA; Thu, 28 May 2009 18:32:00 -0600 (MDT) Received: from [10.1.0.106] (69.150.142.130 [69.150.142.130]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Thu, 28 May 2009 18:32:00 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=69.150.142.130; client-port=55462; syn-fingerprint=65535:52:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <73BD37BF-A1D3-4C7B-AEF0-AB6CD35B6E01@tcb.net> From: Danny McPherson To: sidr@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 28 May 2009 18:26:46 -0600 References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 29 May 2009 00:30:16 -0000 On May 27, 2009, at 2:30 PM, Sandra Murphy wrote: > The origin authorization has to be done first. FIRST. Vital. > Necessary. Can't be skipped. The base case. We must do this. We > need this - it is not a choice. Again, I never said it was. What I said is that if the aim here is to actually secure the routing system then we need to squarely address the path issue as well, or ALL the vulnerabilities that exist today pretty much remain with only origin authorization - and if they remain, it's unlikely operators are going to jump through hoops to solve 10% of the problem. That said, if SIDR is only concerned with development and specification of an RPKI for origin authorization, and BGP security and future employment of that will address the rest of the problem, that mostly makes sense to me - but I don't want folks to be confused about what SIDR is and is not doing. -danny From Sandra.Murphy@cobham.com Thu May 28 17:46:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280D33A67C0 for ; Thu, 28 May 2009 17:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 0E23UGk+wowz for ; Thu, 28 May 2009 17:46:47 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 43FFF3A67A7 for ; Thu, 28 May 2009 17:46:46 -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 n4T0mTWF017322; Thu, 28 May 2009 19:48:29 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n4T0mUWo026611; Thu, 28 May 2009 19:48:30 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 20:48:29 -0400 Date: Thu, 28 May 2009 20:48:28 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: <3479D20C-249B-4E6A-940E-4ED8D6E3680B@tcb.net> Message-ID: References: <8E69BE95-6F1D-4018-AF06-097CF778F4BE@puck.nether.net> <3479D20C-249B-4E6A-940E-4ED8D6E3680B@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 May 2009 00:48:29.0424 (UTC) FILETIME=[2EF11F00:01C9DFF7] Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 29 May 2009 00:46:48 -0000 On Thu, 28 May 2009, Danny McPherson wrote: > > On May 27, 2009, at 2:30 PM, Sandra Murphy wrote: > >> The origin authorization has to be done first. FIRST. Vital. Necessary. >> Can't be skipped. The base case. We must do this. We need this - it is >> not a choice. > > Again, I never said it was. Ah. I thought your window barring vs open door was meant (or could be read by others) to indicate that you thought we were addressing the wrong problem. So I said it is required as many ways as I could to try to emphasize the point that origin authentication is not the wrong problem. > > What I said is that if the aim here is to actually secure > the routing system then we need to squarely address the path > issue as well, or ALL the vulnerabilities that exist today > pretty much remain with only origin authorization - and if > they remain, it's unlikely operators are going to jump > through hoops to solve 10% of the problem. Origin authentication does protect against the accidental announcement of mis-origin info. That's a lot of incidents that occur today. However, as you and I and others have said, that doesn't stop the deliberate attack (or more subtle ways of messing up - there's no such thing as fool proof since fools are so ingenious). > > That said, if SIDR is only concerned with development and > specification of an RPKI for origin authorization, and BGP > security and future employment of that will address the > rest of the problem, that mostly makes sense to me - but I > don't want folks to be confused about what SIDR is and is > not doing. The path issue could be a re-chartered SIDR work item or it could be a new working group work item. I don't think it matters which. Doing the path proteciton matters. It is not the task of the SIDR working group right now. SIDR is laying the ground work on which the path protections will be built. --Sandy > > -danny > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr