From sidr-bounces@ietf.org Mon Dec 1 06:10:37 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125AC3A69C0; Mon, 1 Dec 2008 06:10:37 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5733A69C0 for ; Mon, 1 Dec 2008 06:10:35 -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 zCFuUQk5fwnp for ; Mon, 1 Dec 2008 06:10:34 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2E0173A689F for ; Mon, 1 Dec 2008 06:10:34 -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 mB1EAQbo007923; Mon, 1 Dec 2008 08:10:26 -0600 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 mB1EAQqZ011977; Mon, 1 Dec 2008 08:10:26 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.105]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 09:10:26 -0500 Date: Mon, 1 Dec 2008 09:10:26 -0500 (Eastern Standard Time) From: Sandra Murphy To: bmanning@vacation.karoshi.com In-Reply-To: <20081128085751.GA23357@vacation.karoshi.com.> Message-ID: References: <20081128085751.GA23357@vacation.karoshi.com.> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 01 Dec 2008 14:10:26.0120 (UTC) FILETIME=[8EC90480:01C953BE] Cc: sidr@ietf.org Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org People seem to be confusing one specification with one trust anchor. And also not noting that the ability of a relying party to choose a trust anchor is a big get-out-of-jail-free card for those who are allergic to the idea of one root. NOT that I'm recommending using that card. --Sandy On Fri, 28 Nov 2008, bmanning@vacation.karoshi.com wrote: > > if indeed there is agreement on one and only one RPKI, then > one of the primary advantages of using the IP protocols will > be lost. > > there is -zero- requirement for full, continious interconnectivity > in the base IP protocol. creation of a mandate for a single, one > and only RPKI, forces folks into an always on, always connected > mode ... and i am not sure how well this presumption will work > for things like mannet/monnet networking. > > --bill > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 06:23:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7A13A69ED; Mon, 1 Dec 2008 06:23:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383EF3A69ED for ; Mon, 1 Dec 2008 06:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[AWL=1.010, 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 EfxPMzMXOAWs for ; Mon, 1 Dec 2008 06:23:23 -0800 (PST) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 7520D3A689F for ; Mon, 1 Dec 2008 06:23:23 -0800 (PST) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id mB1ENDRf020227; Mon, 1 Dec 2008 14:23:13 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id mB1ENDYf020226; Mon, 1 Dec 2008 14:23:13 GMT Date: Mon, 1 Dec 2008 14:23:13 +0000 From: bmanning@vacation.karoshi.com To: Sandra Murphy Message-ID: <20081201142313.GA20119@vacation.karoshi.com.> References: <20081128085751.GA23357@vacation.karoshi.com.> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: sidr@ietf.org Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org perhaps you are right Sandy, its that confusing subject line, "One and Only One RPKI" that triggered my response. --bill On Mon, Dec 01, 2008 at 09:10:26AM -0500, Sandra Murphy wrote: > People seem to be confusing one specification with one trust anchor. > > And also not noting that the ability of a relying party to choose a trust > anchor is a big get-out-of-jail-free card for those who are allergic to > the idea of one root. NOT that I'm recommending using that card. > > --Sandy > > On Fri, 28 Nov 2008, bmanning@vacation.karoshi.com wrote: > > > > >if indeed there is agreement on one and only one RPKI, then > >one of the primary advantages of using the IP protocols will > >be lost. > > > >there is -zero- requirement for full, continious interconnectivity > >in the base IP protocol. creation of a mandate for a single, one > >and only RPKI, forces folks into an always on, always connected > >mode ... and i am not sure how well this presumption will work > >for things like mannet/monnet networking. > > > >--bill > > > >_______________________________________________ > >sidr mailing list > >sidr@ietf.org > >https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 07:36:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE263A6AEF; Mon, 1 Dec 2008 07:36:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032723A6AD0 for ; Mon, 1 Dec 2008 07:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=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 MN6LW4f84J9s for ; Mon, 1 Dec 2008 07:36:38 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3A4E43A6AAE for ; Mon, 1 Dec 2008 07:36:38 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L7Ap1-0007AS-DY; Mon, 01 Dec 2008 10:36:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <003201c9512c$9bb96840$0601a8c0@allison> References: <003201c9512c$9bb96840$0601a8c0@allison> Date: Mon, 1 Dec 2008 10:29:25 -0500 To: "tom.petch" From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] One and only one RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 7:40 PM +0100 11/26/08, tom.petch wrote: >piggybacking, a question that has been bugging me , what is an RPKI? The resource PKI is an instance of a PKI, devoted to issuing certs for the "resources" that are managed by IANA and the RIRs, i.e., Internet address space and autonomous system numbers. >Is it an 'object class' of which the one discussed within sidr is an object >instance? There is only one resource allocation system for the Internet, so there is only one RPKI. >or is it something invented by sidr/RPSEC/IETF etc and does not >exist outside this? SIDR is creating the standards that define the RPKI, while IANA and the RIRs are implementing CAs, protocols, and repositories consistent with those standards. >I have been through the I-Ds and they all seem to take this knowledge >as a prerequisite but without any normative reference thereto. Sorry that we didn't do an adequate job there. We will revisit the documents , primarily the architecture document, and see how we can improve the communication. >Perhaps draft-ietf-sidr-arch could contain an explanation (and an expansion >of RPKI when first it appears:-). yes, it should! Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 11:06:58 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CBC3A6BA3; Mon, 1 Dec 2008 11:06:58 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509AB3A6BA3 for ; Mon, 1 Dec 2008 11:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZgGt+12v3Gp for ; Mon, 1 Dec 2008 11:06:57 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6CB863A682B for ; Mon, 1 Dec 2008 11:06:57 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L7E6e-0001BT-G1; Mon, 01 Dec 2008 14:06:53 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> Date: Mon, 1 Dec 2008 11:23:23 -0500 To: George Michaelson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 6:12 PM -0600 11/24/08, George Michaelson wrote: >Some people now appear to want an *implicit* meaning of 'if not in >ROA, then excluded' -but, they also somehow want this to be >conditional. I an incremental deployment context, a context with which we will have to deal for several (many?) years, we can't reject all assertions that are not verifiable via use of ROAs. >Secondly, there is a semantic difference between 'all which is not >explicitly permitted is forbidden' and 'this is explicitly >forbidden'. ibid. >We have tried to make an explicit semantic around the word NOT: > > NOT prefix / > >ie do NOT accept / as a valid route. Thats what a BOA says. >its explicit what prefixes are being knocked out. > >Others seem to want an *implicit* NOT. But, it appears to be a >conditionally implicit NOT: how can you decide when it does, or does >not apply? > >This is of course two different problems: > >1) how do you conditionally flag it does or doesn't apply? The ROA >has no syntax for this >2) what is the scope of the "NOT" logic? > >in an explicit (BOA) world, the scope can be any prefix(s) you like: >its an explicit statement of intent around the NOT word. a BOA cannot make assertions about prefixes the issues does not control, so the statement above is not quite true. >in a world of ROA only, the only NOT you can have is "anything else" >so its demonstrably semantically weaker. I proposed issuing a ROA with an AS of 1, so that it would explicitly "trump" any non-authenticated assertions about the prefix(es) in question. That is a counter to the generally less-powerful ROA semantics, yet it requires no new processing by relying parties. That's why I prefer a ROA-based approach to a BOA-based approach. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 11:07:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065A828C0E6; Mon, 1 Dec 2008 11:07:27 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B5BE3A696B for ; Mon, 1 Dec 2008 11:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 q46Xev3ihxEE for ; Mon, 1 Dec 2008 11:07:25 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9784B3A682B for ; Mon, 1 Dec 2008 11:07:25 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L7E75-0001BT-DU; Mon, 01 Dec 2008 14:07:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 1 Dec 2008 11:31:58 -0500 To: Andy Newton From: Stephen Kent Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Given Geoff's examples of how to use BOAs, I think the only vase that cannot be handled by the ROA use convention I proposed is the negative assertion about As numbers. Geoff, do you agree? Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 11:59:38 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EBD3A67A7; Mon, 1 Dec 2008 11:59:38 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E40B53A67A7 for ; Mon, 1 Dec 2008 11:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 EE--PwJGqNmx for ; Mon, 1 Dec 2008 11:59:36 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id D127E3A676A for ; Mon, 1 Dec 2008 11:59:35 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2533A110068; Tue, 2 Dec 2008 05:59:30 +1000 (EST) Message-Id: From: Geoff Huston To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 06:59:29 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Hair hat OFF Hi Steve, What I _think_ you describes as the "ROA use convention" is the use of a ROA with an AS of 0 to act as an explicit denial in terms of saying "these prefixes are bogons". I could be wrong in my understanding of course. I must admit that right now I don't think I understand your proposed "ROA use convention" clearly enough to agree with your assertion The BOA Approach: The BOA document is coupled with the ROA validation document so that the ROA interpretation and the BOA interpretation are explicitly described. in this context the ROA does NOT act with a double meaning - it is an explicit authority without any implicit negation connotations. The presence of a ROA does not act as a form of negation of any other form of route origination. The BOA has no max length attribute - any more specific of any prefix described in the BOA is encompassed in the BOA. The "ROA use convention": This "ROA use convention" has me confused. In particular my confusion lies in the following areas: 1. Does a 'convention ROA' has any implicit denial associated with it, or is it a simple positive assertion as described above? 2. How should a ROA with a AS value of 0 and a maxlength attribute be interpreted. Does a ROA for prefix=10.0.0.0/8 maxlength=8, AS=0 say anything at all about 10.0.0.0/9? So if you don't mind I'll reserve judgement on your question and observe that while the BOA adds a further object to the repertoire of 'recognised' RPKI signed objects, it does so in a manner that makes negation explicit, does not rely on variable interpretation of ROAs, does not stretch the ROA semantics beyond the simple positive authority to as AS to originate a route and allows for incremental piecemeal deployment in the network. Regards, Geoff On 02/12/2008, at 3:31 AM, Stephen Kent wrote: > Given Geoff's examples of how to use BOAs, I think the only vase > that cannot be handled by the ROA use convention I proposed is the > negative assertion about As numbers. > > Geoff, do you agree? > > Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 14:34:26 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4023A6BB1; Mon, 1 Dec 2008 14:34:26 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB9E28C103 for ; Mon, 1 Dec 2008 14:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.063 X-Spam-Level: X-Spam-Status: No, score=-1.063 tagged_above=-999 required=5 tests=[AWL=0.054, 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 enipbCnfyQsj for ; Mon, 1 Dec 2008 14:34:24 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 0614A28C0E4 for ; Mon, 1 Dec 2008 14:34:24 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 6D324268766; Mon, 1 Dec 2008 15:34:20 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Dec 2008 15:34:20 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=51109; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> From: Danny McPherson To: Geoff Huston In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 1 Dec 2008 15:34:19 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 25, 2008, at 6:39 PM, Geoff Huston wrote: > > Sure. So here's some use cases of BOAs: > > 1. I have been allocated 203.10.61.0/24. I do not use it today in > any public routing context. It should not appear in BGP at all. I do > not give my authorization to any AS to originate a route for this > prefix, or any more specific of this prefix. If I generate a BOA for > 203.10.61.0/24 then my intention of saying that any use of this > prefix in the public Internet is unauthorized is clear. If you do not give your authorization then do not issue a ROA. With the incremental deployment argument, I'm not sure who would be looking at BOAs if they're not looking at ROAs. > 2. I have been allocated AS 131074 as an AS number. I do not use it > today in any public routing context. It should not appear in BGP at > all either as an origination AS nor as a transit AS in any AS path. > If I generate a BOA for AS131074 then my intention of saying that > any use of this AS number in the public Internet is unauthorized is > clear. But the draft currently does not mitigate "nor as a transit AS", unless I'm missing something. Specifically: S.5 graf 2: "If a route object has an AS origination that refers to an AS number that is listed in a valid BOA, then the route object can be regarded as a Bogon object, and local policies that apply to Bogon AS's can be applied to the object. This holds whether or not the address prefix of the route object is described by a valid ROA or not." I see nothing about "or as a transit AS" in there. > 3. I have been allocated 203.10.60.0/22. I wish to ensure that any > more specific advertisement of this prefix is unauthorized. If I > generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my > intention is clear. I still don't by it.. As an operator, you tell me who is authorized to originate and that's the only origin AS I accept. That's easier to configure in a router, requires less objects in the RPKI, and makes life much simpler. > And a non-use case of BOAs: > > 4. I am a wholesale ISP, and while I allocate address space to my > clients from my aggregate address block (10.0.0.0/8) I also permit > my clients to use their more specific prefix at local exchanges. My > AS number is 131072 and I have generated a ROA for 10.0.0.0/8 , > maxlength=8 origin AS 131072. I do not have a problem with more > specifics of 10.0.0.0/8 being used in routing contexts, as part of > my wholesale stance. I would prefer that my ROA did not cause my > customer's more specifics to be treated as unauthorized routes, > irrespective of whether they are ready to use a ROA today or not. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 14:35:18 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81C728C11E; Mon, 1 Dec 2008 14:35:18 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A4428C136 for ; Mon, 1 Dec 2008 14:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=0.052, 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 X08KHFS8Loeb for ; Mon, 1 Dec 2008 14:35:16 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 89DBD28C11E for ; Mon, 1 Dec 2008 14:35:16 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 21785268766; Mon, 1 Dec 2008 15:35:13 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 01 Dec 2008 15:35:12 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=51110; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 1 Dec 2008 15:35:12 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org BOA I-D authors, Perhaps some of my confusion from this discussion stems from the use of the term "bogon". So, with that, I have two more questions I'm hoping will help clarify the goals here for me. 1) Given the use of the term "bogon" within sidr today, it's clearly much wider than the traditional "unallocated from IANA or an RIR" AS number or prefix. Exactly what is a "bogon" in your mind, and shouldn't it be spelled out in the draft? The use of the term "invalid" recurs throughout, but what constitutes a bogon here appears to be well beyond today's operational interpretation of such a term. Projecting this effort under the auspices of "bogons" as we know them today seems a bit inadequate. 2) The BOA draft suggests that if a valid ROA exists for a given prefix then a BOA should be disregarded. Can you explain to me where or why this apparent conflict would occur? 3) Also, I'm still not entirely up to speed here, but say, as an ISP, I issue a ROA for a prefix I want to permit another AS to originate. IF a BOA exists for the AS originating the route then according to the BOA draft "local policies" should be enacted (e.g., drop the "route object"). However, if for a prefix, then if a ROA exists it should essentially trump the BOA. Could you explain the logic behind this text? Thanks! -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 15:00:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F77E28C147; Mon, 1 Dec 2008 15:00:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D9E3A6BBC for ; Mon, 1 Dec 2008 15:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 K5GCvJIjUf1l for ; Mon, 1 Dec 2008 15:00:23 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id ABCD828C139 for ; Mon, 1 Dec 2008 15:00:20 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4EEE0110068; Tue, 2 Dec 2008 09:00:15 +1000 (EST) Message-Id: <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> From: Geoff Huston To: Danny McPherson In-Reply-To: <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 10:00:14 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 02/12/2008, at 9:34 AM, Danny McPherson wrote: > > On Nov 25, 2008, at 6:39 PM, Geoff Huston wrote: >> >> Sure. So here's some use cases of BOAs: >> >> 1. I have been allocated 203.10.61.0/24. I do not use it today in >> any public routing context. It should not appear in BGP at all. I >> do not give my authorization to any AS to originate a route for >> this prefix, or any more specific of this prefix. If I generate a >> BOA for 203.10.61.0/24 then my intention of saying that any use of >> this prefix in the public Internet is unauthorized is clear. > > If you do not give your authorization then do not issue a ROA. > With the incremental deployment argument, I'm not sure who would > be looking at BOAs if they're not looking at ROAs. I'm sorry, but I cannot see any logic in that response. If I do not give my authorization and I would like to inform everyone else that any use of this address, or this AS is an instance of a hijack then your response seems to be saying to me that I should not do anything. If that is what you are saying then it seems to be a totally ineffectual course of action in my opinion. > > >> 2. I have been allocated AS 131074 as an AS number. I do not use it >> today in any public routing context. It should not appear in BGP at >> all either as an origination AS nor as a transit AS in any AS path. >> If I generate a BOA for AS131074 then my intention of saying that >> any use of this AS number in the public Internet is unauthorized is >> clear. > > But the draft currently does not mitigate "nor as a transit AS", > unless I'm missing something. Specifically: > > S.5 graf 2: > > "If a route object has an AS origination that refers to an AS number > that is listed in a valid BOA, then the route object can be regarded > as a Bogon object, and local policies that apply to Bogon AS's can > be applied to the object. This holds whether or not the address > prefix of the route object is described by a valid ROA or not." > > I see nothing about "or as a transit AS" in there. My apologies - we are not allowed to talk about transit yet as its not an agreed requirement coming out of RSPSEC. So if I remove "nor as a transit AS" and sundry words then I trust that the point I was making is amply clear. > > >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any >> more specific advertisement of this prefix is unauthorized. If I >> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my >> intention is clear. > > I still don't by it.. As an operator, you tell me who is authorized > to originate and that's the only origin AS I accept. That's easier to > configure in a router, requires less objects in the RPKI, and makes > life > much simpler. No security at all makes like enormously simpler. At some point it is necessary to understand what makes a robust security environemnt even in a world of partial use and piecemeal adoptions and then work through the issues related to operational deployment. But you appear to have some other approach in mind. > > >> And a non-use case of BOAs: >> >> 4. I am a wholesale ISP, and while I allocate address space to my >> clients from my aggregate address block (10.0.0.0/8) I also permit >> my clients to use their more specific prefix at local exchanges. My >> AS number is 131072 and I have generated a ROA for 10.0.0.0/8 , >> maxlength=8 origin AS 131072. I do not have a problem with more >> specifics of 10.0.0.0/8 being used in routing contexts, as part of >> my wholesale stance. I would prefer that my ROA did not cause my >> customer's more specifics to be treated as unauthorized routes, >> irrespective of whether they are ready to use a ROA today or not. > > Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 15:12:51 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3FB28C136; Mon, 1 Dec 2008 15:12:51 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503E028C136 for ; Mon, 1 Dec 2008 15:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT9RXf58GRyZ for ; Mon, 1 Dec 2008 15:12:49 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 59D2728C13F for ; Mon, 1 Dec 2008 15:12:49 -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 mB1NCg1p020367; Mon, 1 Dec 2008 17:12:42 -0600 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 mB1NCfKA007187; Mon, 1 Dec 2008 17:12:42 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Dec 2008 18:12:41 -0500 Date: Mon, 1 Dec 2008 18:12:39 -0500 (Eastern Standard Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> Message-ID: References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 01 Dec 2008 23:12:41.0507 (UTC) FILETIME=[4F631730:01C9540A] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mon, 1 Dec 2008, Danny McPherson wrote: > > On Nov 25, 2008, at 6:39 PM, Geoff Huston wrote: >> >> Sure. So here's some use cases of BOAs: >> >> 1. I have been allocated 203.10.61.0/24. I do not use it today in any >> public routing context. It should not appear in BGP at all. I do not give >> my authorization to any AS to originate a route for this prefix, or any >> more specific of this prefix. If I generate a BOA for 203.10.61.0/24 then >> my intention of saying that any use of this prefix in the public Internet >> is unauthorized is clear. > > If you do not give your authorization then do not issue a ROA. > With the incremental deployment argument, I'm not sure who would > be looking at BOAs if they're not looking at ROAs. The issue in incremental deployment is not what the people who haven't deployed it should do but what the people who DO deploy it should do. What do the people who DO understand ROAs(and BOAs) do when they see something unsecured - it might be legit, just not produced by someone who understands ROAs(BOAs). > >> 2. I have been allocated AS 131074 as an AS number. I do not use it today >> in any public routing context. It should not appear in BGP at all either as >> an origination AS nor as a transit AS in any AS path. If I generate a BOA >> for AS131074 then my intention of saying that any use of this AS number in >> the public Internet is unauthorized is clear. > > But the draft currently does not mitigate "nor as a transit AS", > unless I'm missing something. Specifically: > > S.5 graf 2: > > "If a route object has an AS origination that refers to an AS number that is > listed in a valid BOA, then the route object can be regarded as a Bogon > object, and local policies that apply to Bogon AS's can be applied to the > object. This holds whether or not the address prefix of the route object is > described by a valid ROA or not." > > I see nothing about "or as a transit AS" in there. > >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any more >> specific advertisement of this prefix is unauthorized. If I generate a BOA >> for 203.10.60.0/23 AND 203.10.62.0/23 then my intention is clear. > > I still don't by it.. As an operator, you tell me who is authorized > to originate and that's the only origin AS I accept. That's easier to > configure in a router, requires less objects in the RPKI, and makes life > much simpler. So it seems you are in the "and that's all" camp in interpreting ROAs, right? Does your answer assume operators are using ROAs to produce route filters? Does your answer change if operators are using ROAs in the decision procedure, as presented at the last meeting? --Sandy > >> And a non-use case of BOAs: >> >> 4. I am a wholesale ISP, and while I allocate address space to my clients >> from my aggregate address block (10.0.0.0/8) I also permit my clients to >> use their more specific prefix at local exchanges. My AS number is 131072 >> and I have generated a ROA for 10.0.0.0/8 , maxlength=8 origin AS 131072. >> I do not have a problem with more specifics of 10.0.0.0/8 being used in >> routing contexts, as part of my wholesale stance. I would prefer that my >> ROA did not cause my customer's more specifics to be treated as >> unauthorized routes, irrespective of whether they are ready to use a ROA >> today or not. > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 15:30:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254A828C127; Mon, 1 Dec 2008 15:30:46 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E816328C127 for ; Mon, 1 Dec 2008 15:30:44 -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 C9hX3F6nTwO3 for ; Mon, 1 Dec 2008 15:30:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5F53928C103 for ; Mon, 1 Dec 2008 15:30:43 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7IDs-000BSa-55; Mon, 01 Dec 2008 23:30:36 +0000 Message-ID: <4934739A.40900@psg.com> Date: Tue, 02 Dec 2008 08:30:34 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Sandra Murphy References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > So it seems you are in the "and that's all" camp in interpreting ROAs, > right? > > Does your answer assume operators are using ROAs to produce route > filters? Does your answer change if operators are using ROAs in the > decision procedure, as presented at the last meeting? from my pov, no randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 16:00:14 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63E03A697B; Mon, 1 Dec 2008 16:00:14 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D468B3A697B for ; Mon, 1 Dec 2008 16:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 9-vp9f8hYgrQ for ; Mon, 1 Dec 2008 16:00:13 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 075553A67FD for ; Mon, 1 Dec 2008 16:00:13 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D11CA110068; Tue, 2 Dec 2008 10:00:08 +1000 (EST) Message-Id: <052356B0-62B7-46E7-BE51-E917DCA17D24@apnic.net> From: Geoff Huston To: Robert Kisteleki , "Jos I. Boumans" In-Reply-To: <4922E1E3.4020608@ripe.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 11:00:07 +1100 References: <4922E1E3.4020608@ripe.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] RPSLSIG adoption? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 19/11/2008, at 2:40 AM, Robert Kisteleki wrote: > Hi, > > After my (rushed) presentation yesterday I'd like to ask if there > are people in the WG who think that this idea is worth pursuing and > should it be a WG item? > > http://www.ietf.org/internet-drafts/draft-kisteleki-sidr-rpsl-sig-00.txt WG Co-Chair hat ON Thank you for your presentation to the WG at the last IETF meeting. After asking the WG for their views on this question, I have reviewed the WG email on this question, the SIDR charter, and consulted with the relevant Routing AD on the charter issue, and as a result I am in a position to conclude that I have observed a rough consensus on the part of the Working Group in favour of adoption of this document as a WG item. I would like to request that you edit your draft to reflect this, (draft-ietf-sidr-rpsl-sig) and submit this draft as a WG document. Kind regards, Geoff Huston co-char SIDR WG. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 16:06:32 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2DEE3A69E9; Mon, 1 Dec 2008 16:06:32 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0313A6A8E for ; Mon, 1 Dec 2008 16:06:31 -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 gus-DazTyXEL for ; Mon, 1 Dec 2008 16:06:30 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D59CB3A697B for ; Mon, 1 Dec 2008 16:06:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,698,1220227200"; d="scan'208";a="119928186" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2008 00:06:27 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB206RYo024002; Mon, 1 Dec 2008 16:06:27 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mB206Rfe029865; Tue, 2 Dec 2008 00:06:27 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 16:06:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 16:05:28 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-01.txt Thread-Index: AclUCKNaftvVswHhSmCUffFvwvIPAgAAbl7w References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> From: "Pradosh Mohapatra (pmohapat)" To: "Geoff Huston" , "Danny McPherson" X-OriginalArrivalTime: 02 Dec 2008 00:06:27.0045 (UTC) FILETIME=[D1F52150:01C95411] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4318; t=1228176387; x=1229040387; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20Request=20for=20WG=20Last=20Ca ll=20fordraft-ietf-sidr-bogons-02.txt=20anddraft-ietf-sidr-r oa-validation-01.txt |Sender:=20; bh=zYJnFUf1zSyHKh/APv5u5MAXkrZumAhRB8TpZebpxMM=; b=MeW2qjm54dKdOb91mbLPEoHSqz/ZViHwbRoB02qOptMLjmSzwXJRBYlr9X HemGmrxR9OFYc/yd5LolBkLDl4yi3/Dzhp14exmL7msx/Ch8toRwBf21q1W4 OY+5OXpnbGhXHGt745RudPx38AD/gqrgt1QgSD++6WB58r0heKII0=; Authentication-Results: sj-dkim-1; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Geoff, | >> 1. I have been allocated 203.10.61.0/24. I do not use it | today in any | >> public routing context. It should not appear in BGP at | all. I do not | >> give my authorization to any AS to originate a route for | this prefix, | >> or any more specific of this prefix. If I generate a BOA for | >> 203.10.61.0/24 then my intention of saying that any use of this | >> prefix in the public Internet is unauthorized is clear. | > | > If you do not give your authorization then do not issue a ROA. | > With the incremental deployment argument, I'm not sure who would be | > looking at BOAs if they're not looking at ROAs. | | I'm sorry, but I cannot see any logic in that response. If I | do not give my authorization and I would like to inform | everyone else that any use of this address, or this AS is an | instance of a hijack then your response seems to be saying to | me that I should not do anything. | If that is what you are saying then it seems to be a totally | ineffectual course of action in my opinion. What if: when "I have been allocated 203.10.61.0/24", I issue an ROA for the same with my origin AS? Doesn't that automatically mean that all the advertisements of the prefix from another origin AS are automatically invalid? And since I will not be generating any updates for this prefix, it will not appear in BGP at all! Doesn't that solve the problem you cited? Are you concerned that some other AS would also issue an ROA for the same or a more specific block of the prefix? That can't be! | >> 2. I have been allocated AS 131074 as an AS number. I do | not use it | >> today in any public routing context. It should not appear | in BGP at | >> all either as an origination AS nor as a transit AS in any AS path. | >> If I generate a BOA for AS131074 then my intention of | saying that any | >> use of this AS number in the public Internet is unauthorized is | >> clear. | > | > But the draft currently does not mitigate "nor as a transit AS", | > unless I'm missing something. Specifically: | > | > S.5 graf 2: | > | > "If a route object has an AS origination that refers to an | AS number | > that is listed in a valid BOA, then the route object can be | regarded | > as a Bogon object, and local policies that apply to Bogon | AS's can be | > applied to the object. This holds whether or not the | address prefix of | > the route object is described by a valid ROA or not." | > | > I see nothing about "or as a transit AS" in there. | | My apologies - we are not allowed to talk about transit yet | as its not an agreed requirement coming out of RSPSEC. So if | I remove "nor as a transit AS" and sundry words then I trust | that the point I was making is amply clear. How important is the case of "AS protection" as opposed to "prefix" protection? Doesn't this automatically become a by-product of ROA level checks? | >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any | >> more specific advertisement of this prefix is unauthorized. If I | >> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my | >> intention is clear. | > | > I still don't by it.. As an operator, you tell me who is | authorized | > to originate and that's the only origin AS I accept. | That's easier to | > configure in a router, requires less objects in the RPKI, and makes | > life much simpler. | | | No security at all makes like enormously simpler. At some | point it is | necessary to understand what makes a robust security | environemnt even | in a world of partial use and piecemeal adoptions and then work | through the issues related to operational deployment. But you appear | to have some other approach in mind. As others have suggested, when "I have been allocated 203.10.60.0/22", I issue an ROA for 203.10.60.0/22-22. That automatically means that there can't be any other advertisements for this prefix or its more specifics (unless I suballocate a more specific block and a new ROA gets added to the repository for that]. Is there any case that's not handled by doing this? - Pradosh _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 16:08:39 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE85F3A6BAF; Mon, 1 Dec 2008 16:08:39 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF863A6BAF for ; Mon, 1 Dec 2008 16:08: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 Ygeg4EL5zpQh for ; Mon, 1 Dec 2008 16:08:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BE73E3A6A7B for ; Mon, 1 Dec 2008 16:08:37 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7IoX-000Boq-7g; Tue, 02 Dec 2008 00:08:29 +0000 Message-ID: <49347C7B.6030304@psg.com> Date: Tue, 02 Dec 2008 09:08:27 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "Pradosh Mohapatra (pmohapat)" References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > What if: when "I have been allocated 203.10.61.0/24", I issue an > ROA for the same with my origin AS? Doesn't that automatically > mean that all the advertisements of the prefix from another origin > AS are automatically invalid? no, not if roas exist for them too. while having the same prefix announced by multiple ass is unusual, it is valid practice. think anycast. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 16:15:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA943A6A93; Mon, 1 Dec 2008 16:15:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6C43A6A8E for ; Mon, 1 Dec 2008 16:15:42 -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 zxmp3+sn7ISI for ; Mon, 1 Dec 2008 16:15:41 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7366728C13D for ; Mon, 1 Dec 2008 16:15:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,699,1220227200"; d="scan'208";a="119930100" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2008 00:15:38 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id mB20Fb14032198; Mon, 1 Dec 2008 16:15:38 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id mB20Fbfm028589; Tue, 2 Dec 2008 00:15:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 16:15:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 16:14:57 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408358962@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49347C7B.6030304@psg.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-01.txt Thread-Index: AclUEhxgOaFwj6XRQJ25b5CEre2JigAAB5zg References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <49347C7B.6030304@psg.com> From: "Pradosh Mohapatra (pmohapat)" To: "Randy Bush" X-OriginalArrivalTime: 02 Dec 2008 00:15:37.0792 (UTC) FILETIME=[1A3A7400:01C95413] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=563; t=1228176938; x=1229040938; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20Request=20for=20WG=20Last=20Ca ll=20fordraft-ietf-sidr-bogons-02.txt=20anddraft-ietf-sidr-r oa-validation-01.txt |Sender:=20; bh=eKVhGTkGY3l00Pwra+LryfKtoS9U8sE+qUVv4pb0NbQ=; b=RvwM3wZ8sDV/Xg+klprxx6e0lxbtT72G2/BLZy6gbdGeYiDSDxcTIfhHnF 1jm+ccZDci0o5vcwknDazu1HSqGoTjikFgSzLdgi4+yRPHJP6rTabPEtsNPr NLn7YhFy3B; Authentication-Results: sj-dkim-4; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org | > What if: when "I have been allocated 203.10.61.0/24", I | issue an ROA | > for the same with my origin AS? Doesn't that automatically | mean that | > all the advertisements of the prefix from another origin AS are | > automatically invalid? | | no, not if roas exist for them too. while having the same | prefix announced by multiple ass is unusual, it is valid | practice. think anycast. Agreed. What I meant is that existence of ROA(s) should be sufficient to detect invalid uses/filter invalid BGP announcements. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 16:17:15 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4724B28C135; Mon, 1 Dec 2008 16:17:15 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA81C28C135 for ; Mon, 1 Dec 2008 16:17: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=[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 CAW-Sw1U7D+g for ; Mon, 1 Dec 2008 16:17:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2DD0028C103 for ; Mon, 1 Dec 2008 16:17:13 -0800 (PST) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Iwb-000Bqf-O8; Tue, 02 Dec 2008 00:16:49 +0000 Message-ID: <49347E70.9050009@psg.com> Date: Tue, 02 Dec 2008 09:16:48 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "Pradosh Mohapatra (pmohapat)" References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <49347C7B.6030304@psg.com> <04CAD96D4C5A3D48B1919248A8FE0D5408358962@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408358962@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Pradosh Mohapatra (pmohapat) wrote: > | > What if: when "I have been allocated 203.10.61.0/24", I > | issue an ROA > | > for the same with my origin AS? Doesn't that automatically > | mean that > | > all the advertisements of the prefix from another origin AS are > | > automatically invalid? > | > | no, not if roas exist for them too. while having the same > | prefix announced by multiple ass is unusual, it is valid > | practice. think anycast. > > Agreed. What I meant is that existence of ROA(s) should be > sufficient to detect invalid uses/filter invalid BGP announcements. of course randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 16:22:32 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2F33A6A8E; Mon, 1 Dec 2008 16:22:32 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5B33A697B for ; Mon, 1 Dec 2008 16:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 VLUwPD9e7lkz for ; Mon, 1 Dec 2008 16:22:29 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 7CBBD3A6991 for ; Mon, 1 Dec 2008 16:22:28 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 09333110068; Tue, 2 Dec 2008 10:22:22 +1000 (EST) Message-Id: <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> From: Geoff Huston To: Pradosh Mohapatra (pmohapat) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 11:22:22 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat OFF On 02/12/2008, at 11:05 AM, Pradosh Mohapatra (pmohapat) wrote: > Hi Geoff, > > | >> 1. I have been allocated 203.10.61.0/24. I do not use it > | today in any > | >> public routing context. It should not appear in BGP at > | all. I do not > | >> give my authorization to any AS to originate a route for > | this prefix, > | >> or any more specific of this prefix. If I generate a BOA for > | >> 203.10.61.0/24 then my intention of saying that any use of this > | >> prefix in the public Internet is unauthorized is clear. > | > > | > If you do not give your authorization then do not issue a ROA. > | > With the incremental deployment argument, I'm not sure who would = > be > | > looking at BOAs if they're not looking at ROAs. > | > | I'm sorry, but I cannot see any logic in that response. If I > | do not give my authorization and I would like to inform > | everyone else that any use of this address, or this AS is an > | instance of a hijack then your response seems to be saying to > | me that I should not do anything. > | If that is what you are saying then it seems to be a totally > | ineffectual course of action in my opinion. > > > What if: when "I have been allocated 203.10.61.0/24", I issue an > ROA for the same with my origin AS? Doesn't that automatically > mean that all the advertisements of the prefix from another origin > AS are automatically invalid? No. Some folk believe that this should be the case, others believe = that this should not be the case. Those who believe that this should = not be the case are proposing the BOA as a form of explicitly stating = what is invalid without having to state what is valid. By the way, given that you have published a ROA aithorizing your = origin AS to advertise the prefix, I suspect that this has created = some further vulnerabilities that a BOA would not create. What happens = if I use this ROA you've created to hijack with your prefix by = prepending your origin AS to my AS? Can a third party detect that this = is a hijack of your prefix from the origination information and the = ROA? I do not think so. > And since I will not be generating > any updates for this prefix, it will not appear in BGP at all! > Doesn't that solve the problem you cited? no - see above,. > Are you concerned that > some other AS would also issue an ROA for the same or a more > specific block of the prefix? That can't be! > > | >> 2. I have been allocated AS 131074 as an AS number. I do > | not use it > | >> today in any public routing context. It should not appear > | in BGP at > | >> all either as an origination AS nor as a transit AS in any AS = > path. > | >> If I generate a BOA for AS131074 then my intention of > | saying that any > | >> use of this AS number in the public Internet is unauthorized is > | >> clear. > | > > | > But the draft currently does not mitigate "nor as a transit AS", > | > unless I'm missing something. Specifically: > | > > | > S.5 graf 2: > | > > | > "If a route object has an AS origination that refers to an > | AS number > | > that is listed in a valid BOA, then the route object can be > | regarded > | > as a Bogon object, and local policies that apply to Bogon > | AS's can be > | > applied to the object. This holds whether or not the > | address prefix of > | > the route object is described by a valid ROA or not." > | > > | > I see nothing about "or as a transit AS" in there. > | > | My apologies - we are not allowed to talk about transit yet > | as its not an agreed requirement coming out of RSPSEC. So if > | I remove "nor as a transit AS" and sundry words then I trust > | that the point I was making is amply clear. > > > How important is the case of "AS protection" as opposed to > "prefix" protection? Doesn't this automatically become a > by-product of ROA level checks? > > No, it does not. There are many instances of use of AS numbers what = are not recorded in any allocation database. See the attached list for = today's set of bogon ASs > | >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that = > any > | >> more specific advertisement of this prefix is unauthorized. If I > | >> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my > | >> intention is clear. > | > > | > I still don't by it.. As an operator, you tell me who is > | authorized > | > to originate and that's the only origin AS I accept. > | That's easier to > | > configure in a router, requires less objects in the RPKI, and = > makes > | > life much simpler. > | > | > | No security at all makes like enormously simpler. At some > | point it is > | necessary to understand what makes a robust security > | environemnt even > | in a world of partial use and piecemeal adoptions and then work > | through the issues related to operational deployment. But you appear > | to have some other approach in mind. > > As others have suggested, when "I have been allocated 203.10.60.0/22", > I issue an ROA for 203.10.60.0/22-22. That automatically means that > there can't be any other advertisements for this prefix or its more > specifics (unless I suballocate a more specific block and a new ROA > gets added to the repository for that]. Is there any case that's not > handled by doing this? > That's your _assumption_ of the sematics of a ROA. What reference = material or working group draft can you cite for semantic = interpretation of a ROA? draft-ieft-sidr-roa-validation? I don't think = so. The point of hte BOA draft it that it challenges this assumption = by taking the position that such route aorigination authorities are = explicitly scoped to the authority described in the object, without = the implicit inclusion of any other authority or denial. AS referred to earlier, here's the list of today's bogon AS numbers, = just in case you thought that this is a non-problem: AS4801 Announced by AS703 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS4801 Announced by AS9304 HUTCHISON-AS-AP Hutchison Global = Communications AS8008 Announced by AS23577 ATM-MPLS-AS-KR Korea Telecom AS9218 Announced by AS71 HP-INTERNET-AS Hewlett-Packard Company AS9798 Announced by AS151 IND-NTC-AS - Hewlett-Packard Company AS9935 Announced by AS2687 ASATTCA AT&T Global Network = Services - AP AS11153 Announced by AS10910 INTERNAP-BLK - Internap Network = Services Corporation AS11196 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS11253 Announced by AS4323 TWTC - tw telecom holdings, inc. AS11378 Announced by AS22822 LLNW - Limelight Networks, Inc. AS11536 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS11536 Announced by AS13333 NAUTICOM-NET - Pinnatech, Inc. AS11600 Announced by AS6461 MFNX MFN - Metromedia Fiber Network AS11720 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS11967 Announced by AS6203 ISDN-NET - ISDN-Net Inc. AS12077 Announced by AS13768 PEER1 - Peer 1 Network Inc. AS12134 Announced by AS3356 LEVEL3 Level 3 Communications AS12185 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS13317 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS13377 Announced by AS3549 GBLX Global Crossing Ltd. AS13608 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS13746 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS13926 Announced by AS5109 AS-IDS-NET - Integrated Data = Systems, LLC AS13956 Announced by AS3549 GBLX Global Crossing Ltd. AS14293 Announced by AS6461 MFNX MFN - Metromedia Fiber Network AS14373 Announced by AS6922 TEXASAGENCYNET - State of Texas = General Services Commission AS14458 Announced by AS1239 SPRINTLINK - Sprint AS14539 Announced by AS6517 RELIANCEGLOBALCOM - Reliance = Globalcom Services, Inc AS14548 Announced by AS7385 INTEGRATELECOM - Integra Telecom, = Inc. AS14568 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS14575 Announced by AS2828 XO-AS15 - XO Communications AS14584 Announced by AS10910 INTERNAP-BLK - Internap Network = Services Corporation AS14606 Announced by AS4323 TWTC - tw telecom holdings, inc. AS14715 Announced by AS19024 INTERNAP-BLK5 - Internap Network = Services Corporation AS14764 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS14812 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS14923 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS15037 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS15053 Announced by AS12180 INTERNAP-2BLK - Internap Network = Services Corporation AS15115 Announced by AS1239 SPRINTLINK - Sprint AS15115 Announced by AS10912 INTERNAP-BLK - Internap Network = Services Corporation AS15132 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS15211 Announced by AS6395 LVLT-6395 - Level 3 = Communications, Inc. AS15337 Announced by AS6325 ILLINOIS-CENTURY - Illinois = Century Network AS16611 Announced by AS3144 PINNACLE - Pinnacle On-Line AS16611 Announced by AS12064 ASN-CXA-HR-12064-CBS - Cox = Communications Inc. AS16859 Announced by AS19262 VZGNI-TRANSIT - Verizon Internet = Services Inc. AS16876 Announced by AS4181 TDS-AS - TDS TELECOM AS16927 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS17144 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS17144 Announced by AS13791 INTERNAP-BLK3 - Internap Network = Services Corporation AS17275 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS17275 Announced by AS6461 MFNX MFN - Metromedia Fiber Network AS17275 Announced by AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox = Communications Inc. AS17283 Announced by AS3549 GBLX Global Crossing Ltd. AS17300 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS17300 Announced by AS1239 SPRINTLINK - Sprint AS17300 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS18504 Announced by AS4565 MEGAPATH2-US - MegaPath Networks = Inc. AS18506 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS18533 Announced by AS174 COGENT Cogent/PSI AS18641 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS18706 Announced by AS3356 LEVEL3 Level 3 Communications AS18726 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS18726 Announced by AS14742 INTERNAP-BLOCK-4 - Internap = Network Services Corporation AS18860 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS18932 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS18932 Announced by AS7132 SBIS-AS - AT&T Internet Services AS19097 Announced by AS1785 AS-PAETEC-NET - PaeTec = Communications, Inc. AS19097 Announced by AS13407 CTC-BGP2 - Computer Telephone Corp AS19132 Announced by AS6140 IMPSAT-USA - ImpSat USA, Inc. AS19243 Announced by AS2686 AT&T Global Network Services - EMEA AS19243 Announced by AS10913 INTERNAP-BLK - Internap Network = Services Corporation AS19612 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS19612 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS19713 Announced by AS10367 METRO2000 - Metro2000, Inc. AS19851 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS19981 Announced by AS80 GE-CRD - General Electric Company AS19999 Announced by AS577 BACOM - Bell Canada AS19999 Announced by AS15290 ALLST-15290 - Allstream Corp. = Corporation Allstream AS20146 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS20156 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS20247 Announced by AS19262 VZGNI-TRANSIT - Verizon Internet = Services Inc. AS20323 Announced by AS3300 BT-INFONET-EUROPE BT-Infonet-Europe AS20364 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS20380 Announced by AS1239 SPRINTLINK - Sprint AS20408 Announced by AS7132 SBIS-AS - AT&T Internet Services AS20463 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS21676 Announced by AS1239 SPRINTLINK - Sprint AS21732 Announced by AS12181 INTERNAP-2BLK - Internap Network = Services Corporation AS21846 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS22022 Announced by AS3356 LEVEL3 Level 3 Communications AS22056 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS22219 Announced by AS3356 LEVEL3 Level 3 Communications AS22219 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS22232 Announced by AS2647 SITA SITA AS22232 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS22360 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS22372 Announced by AS3549 GBLX Global Crossing Ltd. AS22372 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS22457 Announced by AS6496 ANET - ANET Internet Solutions, Inc AS22457 Announced by AS19024 INTERNAP-BLK5 - Internap Network = Services Corporation AS22492 Announced by AS4323 TWTC - tw telecom holdings, inc. AS22586 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS22721 Announced by AS174 COGENT Cogent/PSI AS22741 Announced by AS10910 INTERNAP-BLK - Internap Network = Services Corporation AS22751 Announced by AS22197 APPS - Apps Communications AS22757 Announced by AS17054 AS17054 - CONTINENTAL BROADBAND = PENNSYLVANIA, INC. AS22761 Announced by AS7029 WINDSTREAM - Windstream = Communications Inc AS22815 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS22815 Announced by AS3356 LEVEL3 Level 3 Communications AS22846 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS22846 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS22875 Announced by AS10910 INTERNAP-BLK - Internap Network = Services Corporation AS22875 Announced by AS13789 INTERNAP-BLK3 - Internap Network = Services Corporation AS22943 Announced by AS10910 INTERNAP-BLK - Internap Network = Services Corporation AS23011 Announced by AS12006 EUREKANETWORKS-AS-12006 - eLink = Communications INC. AS23021 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS23021 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS23035 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS23108 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS23108 Announced by AS1239 SPRINTLINK - Sprint AS23108 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS23247 Announced by AS10910 INTERNAP-BLK - Internap Network = Services Corporation AS23276 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS23276 Announced by AS21548 MTO - MTO Telecom Inc. AS23434 Announced by AS16852 LVLT-16852 - Level 3 = Communications, Inc. AS23448 Announced by AS852 ASN852 - Telus Advanced = Communications AS23448 Announced by AS6327 SHAW - Shaw Communications Inc. AS23475 Announced by AS1239 SPRINTLINK - Sprint AS23475 Announced by AS7132 SBIS-AS - AT&T Internet Services AS23480 Announced by AS6298 ASN-CXA-PH-6298-CBS - Cox = Communications Inc. AS23491 Announced by AS6395 LVLT-6395 - Level 3 = Communications, Inc. AS23502 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS23918 Announced by AS4716 POWEREDCOM KDDI Corporation AS24011 Announced by AS174 COGENT Cogent/PSI AS24012 Announced by AS1239 SPRINTLINK - Sprint AS24012 Announced by AS4862 EQUANT-ASIA Equant AS for Asian = Region covering Japan AS24084 Announced by AS3300 BT-INFONET-EUROPE BT-Infonet-Europe AS24084 Announced by AS4755 TATACOMM-AS TATA Communications = formerly VSNL is Leading ISP AS25639 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS25964 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS25992 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS26001 Announced by AS1239 SPRINTLINK - Sprint AS26023 Announced by AS16399 NETWORKGCI - Globalcom AS26051 Announced by AS17229 ATT-CERFNET-BLOCK - AT&T = Enhanced Network Services AS26064 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS26187 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS26396 Announced by AS32703 IFN-NET - Indiana Fiber Network, = LLC AS26483 Announced by AS3356 LEVEL3 Level 3 Communications AS26515 Announced by AS7795 NTELOSINC - Ntelos Inc. AS26539 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS26581 Announced by AS1239 SPRINTLINK - Sprint AS26650 Announced by AS3491 BTN-ASN - Beyond The Network = America, Inc. AS26656 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS26656 Announced by AS1239 SPRINTLINK - Sprint AS26690 Announced by AS7132 SBIS-AS - AT&T Internet Services AS26883 Announced by AS6337 HIWAAY - HIWAAY INFORMATION = SERVICES, INC. AS26951 Announced by AS14743 INTERNAP-BLOCK-4 - Internap = Network Services Corporation AS26970 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS26970 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS26973 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS27197 Announced by AS7029 WINDSTREAM - Windstream = Communications Inc AS27223 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS27243 Announced by AS17054 AS17054 - CONTINENTAL BROADBAND = PENNSYLVANIA, INC. AS27252 Announced by AS30314 KAN-ED - Kansas Education Network AS27301 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS27363 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS27363 Announced by AS1239 SPRINTLINK - Sprint AS27363 Announced by AS6128 CABLE-NET-1 - Cablevision Systems = Corp. AS27451 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS27451 Announced by AS7132 SBIS-AS - AT&T Internet Services AS27642 Announced by AS7132 SBIS-AS - AT&T Internet Services AS28544 Announced by AS6503 Avantel, S.A. AS28551 Announced by AS11172 Alestra AS28551 Announced by AS22566 MAXCOM Telecomunicaciones SA de CV AS29703 Announced by AS852 ASN852 - Telus Advanced = Communications AS29703 Announced by AS6539 GT-BELL - Bell Canada AS29755 Announced by AS7132 SBIS-AS - AT&T Internet Services AS29770 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS29770 Announced by AS1239 SPRINTLINK - Sprint AS29837 Announced by AS3549 GBLX Global Crossing Ltd. AS29994 Announced by AS558 NET2EZ - Net2EZ AS30028 Announced by AS7132 SBIS-AS - AT&T Internet Services AS30273 Announced by AS6128 CABLE-NET-1 - Cablevision Systems = Corp. AS30273 Announced by AS23329 AS-OPENACCESS - Open Access Inc. AS30419 Announced by AS3356 LEVEL3 Level 3 Communications AS30707 Announced by AS12181 INTERNAP-2BLK - Internap Network = Services Corporation AS30711 Announced by AS7132 SBIS-AS - AT&T Internet Services AS31966 Announced by AS4265 CERNET-ASN-BLOCK - California = Education and Research Federation Network AS31966 Announced by AS4267 CERNET-ASN-BLOCK - California = Education and Research Federation Network AS31966 Announced by AS14743 INTERNAP-BLOCK-4 - Internap = Network Services Corporation AS32057 Announced by AS26554 US-SIGNAL - US Signal Corporation AS32108 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS32108 Announced by AS36607 NETONEGROUP - NET ONE GROUP, LLC AS32326 Announced by AS3549 GBLX Global Crossing Ltd. AS32326 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS32434 Announced by AS4323 TWTC - tw telecom holdings, inc. AS32458 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS32567 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS32689 Announced by AS13675 FAIRPO-3 - FAIRPOINT = COMMUNICATIONS, INC. AS32732 Announced by AS1785 AS-PAETEC-NET - PaeTec = Communications, Inc. AS32822 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS32822 Announced by AS3356 LEVEL3 Level 3 Communications AS32873 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS32873 Announced by AS10912 INTERNAP-BLK - Internap Network = Services Corporation AS32895 Announced by AS10910 INTERNAP-BLK - Internap Network = Services Corporation AS33089 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS33400 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS33445 Announced by AS701 UUNET - MCI Communications = Services, Inc. d/b/a Verizon Business AS33574 Announced by AS209 ASN-QWEST - Qwest Communications = Corporation AS33649 Announced by AS7018 ATT-INTERNET4 - AT&T WorldNet = Services AS38137 Announced by AS17494 BTTB-AS-AP Telecom Operator & = Internet Service Provider as well AS38205 Announced by AS17494 BTTB-AS-AP Telecom Operator & = Internet Service Provider as well AS38722 Announced by AS9304 HUTCHISON-AS-AP Hutchison Global = Communications AS38870 Announced by AS9482 ASN-ACON-AP Australia Connect Pty = Ltd AS64553 Announced by AS9498 BBIL-AP BHARTI Airtel Ltd. AS65009 Announced by AS15924 BORUSANTELEKOM-AS Borusan = Telekom Autonomus System AS65031 Announced by AS2588 LATNET ISP AS65101 Announced by AS29405 VNET-AS VNET ISP Bratislava, = Slovakia, SK AS65445 Announced by AS27817 Red Nacional Acad=E9mica de = Tecnolog=EDa Avanzada - RENATA AS65491 Announced by AS27817 Red Nacional Acad=E9mica de = Tecnolog=EDa Avanzada - RENATA AS65498 Announced by AS27817 Red Nacional Acad=E9mica de = Tecnolog=EDa Avanzada - RENATA AS65528 Announced by AS31405 TMD AS for T-Mobile Deutschland, = GPRS/UMTS access and content provider _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 18:30:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4183A6AA7; Mon, 1 Dec 2008 18:30:01 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5272E3A6AA7 for ; Mon, 1 Dec 2008 18:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=0.051, 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 2kI7md2wl3o7 for ; Mon, 1 Dec 2008 18:29:58 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 72F8F3A689F for ; Mon, 1 Dec 2008 18:29:58 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id CDC27268766; Mon, 1 Dec 2008 19:29:54 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Dec 2008 19:29:54 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=52242; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <4A1F98FD-F5A8-4294-8D9F-A414DBBD9613@tcb.net> From: Danny McPherson To: Geoff Huston In-Reply-To: <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 1 Dec 2008 19:29:53 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 1, 2008, at 4:00 PM, Geoff Huston wrote: > I'm sorry, but I cannot see any logic in that response. If I do not > give my authorization and I would like to inform everyone else that > any use of this address, or this AS is an instance of a hijack A hijack, that's new.. So, publish a BOA for each professed hijack, so that when it's picked up 24 hours later folks can filter based on a BOA? It'll be interested to project how folks would automate such a BOA publication model. > then your response seems to be saying to me that I should not do > anything. If that is what you are saying then it seems to be a > totally ineffectual course of action in my opinion. No, you're saying you're doing this to support incremental deployment, I'm saying that capability doesn't exist today and will clearly only complicate things down the road - e.g., who's ever going to remove a BOA - sound familiar (e.g., who ever removes a stale IRR object, which is a positive thing)? What existing capability are you adapting to RPKI? > My apologies - we are not allowed to talk about transit yet as its > not an agreed requirement coming out of RSPSEC. So if I remove "nor > as a transit AS" and sundry words then I trust that the point I was > making is amply clear. I don't consider it "sundry", it's a very important distinction, and suggesting that BOAs add some capability that ROAs or SIDR can't help with along the lines of looking for potential bogon ASNs in a is misleading at best. >> I still don't by it.. As an operator, you tell me who is authorized >> to originate and that's the only origin AS I accept. That's easier >> to >> configure in a router, requires less objects in the RPKI, and makes >> life >> much simpler. > > No security at all makes like enormously simpler. At some point it > is necessary to understand what makes a robust security environemnt > even in a world of partial use and piecemeal adoptions and then work > through the issues related to operational deployment. But you appear > to have some other approach in mind. Right, and adding new capabilities (e.g., telling everyone via means that are clearly not real time, and may be delayed for a day or more, via a global RPKI, that your route has been hijacked and should NOT be advertised by Miguel in Mexico, it just doesn't seem like a clean way to build this architecture to me - especially when you're asking folks to configure routers or implement control plane state and memory based on the contents of this RPKI. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 18:32:13 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342D83A6859; Mon, 1 Dec 2008 18:32:13 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AB03A6859 for ; Mon, 1 Dec 2008 18:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0JM3J7sr-jj for ; Mon, 1 Dec 2008 18:32:11 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E291B3A67F5 for ; Mon, 1 Dec 2008 18:32:11 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 6C842268766; Mon, 1 Dec 2008 19:32:08 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Dec 2008 19:32:08 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=52244; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <4232C338-DC4C-4746-90BD-5C83C31172A9@tcb.net> From: Danny McPherson To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 1 Dec 2008 19:32:07 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 1, 2008, at 4:12 PM, Sandra Murphy wrote: > > The issue in incremental deployment is not what the people who > haven't deployed it should do but what the people who DO deploy it > should do. What do the people who DO understand ROAs(and BOAs) do > when they see something unsecured - it might be legit, just not > produced by someone who understands ROAs(BOAs). Right, but if the owner also published a BOA about who they should not accept it from - what's the value add for those who have deployed it again? They can say, ohh, there's a ROA for AS 1 to originate 10.0.0.0/8. They also published a BOA for AS2 to originate 10.0.0.0/16. So, what's that mean to me since I deployed it? Accept 10.0.0.0/8 only from AS 1. I'm not going to put a policy in my router that says AND accept it from anyone else, or any more specific, except AS 2. Tracking those BOAs is costing money (hardware, time, complexity) and there is no added benefit. >> I still don't by it.. As an operator, you tell me who is authorized >> to originate and that's the only origin AS I accept. That's easier >> to >> configure in a router, requires less objects in the RPKI, and makes >> life >> much simpler. > > So it seems you are in the "and that's all" camp in interpreting > ROAs, right? No, I'm in the "show-me-how-to-configure-this-in-a-router-and- convince-me-that-all-the-complexity-and-added-infrastructure-is worth-the-investment-when-I'm-pretty-sure-I'd-be-just-as-happy with-an-'explicit accept'='implicit deny'-model-like-all-my-other- security-policies" camp. I'm certain that if more people who are supposed to deploy this stuff were paying attention they'd be making the same arguments, but they're not, and so we need to give heavy consideration to this. > Does your answer assume operators are using ROAs to produce route > filters? Maybe. > Does your answer change if operators are using ROAs in the decision > procedure, as presented at the last meeting? Maybe. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 18:43:17 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88ADE3A6AA7; Mon, 1 Dec 2008 18:43:17 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197A73A6AA7 for ; Mon, 1 Dec 2008 18:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=0.057, 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 3CrSK3L30V+e for ; Mon, 1 Dec 2008 18:43:16 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 40E223A6887 for ; Mon, 1 Dec 2008 18:43:16 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id BE21C368025; Mon, 1 Dec 2008 19:43:12 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 01 Dec 2008 19:43:12 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=52278; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <39C4DBEA-893B-4069-B0BF-4D06A82A891B@tcb.net> From: Danny McPherson To: Geoff Huston In-Reply-To: <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 1 Dec 2008 19:43:11 -0700 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 1, 2008, at 5:22 PM, Geoff Huston wrote: > > > No. Some folk believe that this should be the case, others believe > that this should not be the case. Those who believe that this should > not be the case are proposing the BOA as a form of explicitly > stating what is invalid without having to state what is valid. Heh, well said. BOAs provide a mechanism to explicit state *some* of what is invalid, without having to state what is valid. Seems like a less than optimal foundation for a secure inter-domain routing protocol, or any protocol, to me. > By the way, given that you have published a ROA aithorizing your > origin AS to advertise the prefix, I suspect that this has created > some further vulnerabilities that a BOA would not create. What > happens if I use this ROA you've created to hijack with your prefix > by prepending your origin AS to my AS? Can a third party detect that > this is a hijack of your prefix from the origination information and > the ROA? I do not think so. I'm not sure what the point is here, per BOAs, as currently specified under the SIDR charter and your previous comment on this specific issue, provide no such protections either. Professing it as otherwise is misleading. > That's your _assumption_ of the sematics of a ROA. What reference > material or working group draft can you cite for semantic > interpretation of a ROA? draft-ieft-sidr-roa-validation? I don't > think so. Yeah, I think we prolly need to revisit that as well. > The point of hte BOA draft it that it challenges this assumption by > taking the position that such route aorigination authorities are > explicitly scoped to the authority described in the object, without > the implicit inclusion of any other authority or denial. > > AS referred to earlier, here's the list of today's bogon AS numbers, > just in case you thought that this is a non-problem: Right, so let's automate publication of those BOAs so that routers can be configured to drop them tomorrow, instead of only accepting those ASNs or any bogon or hijacked prefixes from legit sources. And then tomorrow we can deal with the previous 24 hours of "Bogons - whatever that entails", all the while the prior set of bogons are half gone but all the objects remain for security reasons, and all of this gets really interesting during large route leaks, and possibly even result in a DOS themselves, and operators can't even pick up legit objects because there are some many BOAs. And don't forget that the state of those BOAs change daily, and perhaps may of those were legit but I "missed picking it up by seconds". Seems way inefficient to me... -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 20:23:17 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A96803A68B8; Mon, 1 Dec 2008 20:23:17 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412E03A68B8 for ; Mon, 1 Dec 2008 20:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsEFpKaB54l6 for ; Mon, 1 Dec 2008 20:23:15 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 447753A6807 for ; Mon, 1 Dec 2008 20:23:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,700,1220227200"; d="scan'208";a="204750515" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Dec 2008 04:23:11 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB24NBVA023588; Mon, 1 Dec 2008 20:23:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB24NB3T000317; Tue, 2 Dec 2008 04:23:11 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 20:23:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 20:22:58 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408358A48@xmb-sjc-215.amer.cisco.com> In-Reply-To: <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-01.txt Thread-Index: AclUFBKhZYEnRL8EQL6oc2Xdx8KRcgABoHGQ References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> From: "Pradosh Mohapatra (pmohapat)" To: "Geoff Huston" X-OriginalArrivalTime: 02 Dec 2008 04:23:11.0549 (UTC) FILETIME=[AFC1E6D0:01C95435] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2409; t=1228191791; x=1229055791; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20Request=20for=20WG=20Last=20Ca ll=20fordraft-ietf-sidr-bogons-02.txt=20anddraft-ietf-sidr-r oa-validation-01.txt |Sender:=20; bh=R/sYYOicHiMoyEcn7g/a4WIXcW4Z4695Y+Ew7qLovvU=; b=Plv3wH+3WTPaiyU/x7nXraGPDHgIuA29nt7wmyfISxkaj7dRRoWqA599ns FRuY+Z3UcghSgh1oU3QKAkkIVLq/p2mJy/xhKprUa4l/LuDrDcX7MXxCc0u7 65HTvOZSNU; Authentication-Results: sj-dkim-2; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org | > What if: when "I have been allocated 203.10.61.0/24", I | issue an ROA | > for the same with my origin AS? Doesn't that automatically | mean that | > all the advertisements of the prefix from another origin AS are | > automatically invalid? | | | No. Some folk believe that this should be the case, others | believe that this should not be the case. Those who believe | that this should not be the case are proposing the BOA as a | form of explicitly stating what is invalid without having to | state what is valid. Why should this not be the case? | By the way, given that you have published a ROA aithorizing | your origin AS to advertise the prefix, I suspect that this | has created some further vulnerabilities that a BOA would not | create. What happens if I use this ROA you've created to | hijack with your prefix by prepending your origin AS to my | AS? Can a third party detect that this is a hijack of your | prefix from the origination information and the ROA? I do not | think so. This is a good example case for path attestation / complete AS_PATH validation, no? When a third party tries to verify whether the path leads back to origin AS, that should fail (whenever we get to that part)... | > As others have suggested, when "I have been allocated | 203.10.60.0/22", | > I issue an ROA for 203.10.60.0/22-22. That automatically means that | > there can't be any other advertisements for this prefix or its more | > specifics (unless I suballocate a more specific block and a new ROA | > gets added to the repository for that]. Is there any case | that's not | > handled by doing this? | > | | That's your _assumption_ of the sematics of a ROA. What | reference material or working group draft can you cite for | semantic interpretation of a ROA? | draft-ieft-sidr-roa-validation? I don't think so. The point | of hte BOA draft it that it challenges this assumption by | taking the position that such route aorigination authorities | are explicitly scoped to the authority described in the | object, without the implicit inclusion of any other authority | or denial. So are you saying that an entity who is not owner of prefix 10/8 can issue an ROA for it and it would be present in/added to the RPKI repository? - Pradosh _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 20:52:35 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911013A6BCD; Mon, 1 Dec 2008 20:52:35 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69EB3A6BCD for ; Mon, 1 Dec 2008 20:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 DsCJ+m0BcYev for ; Mon, 1 Dec 2008 20:52:33 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id C81323A6BC9 for ; Mon, 1 Dec 2008 20:52:32 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DFD0E110068; Tue, 2 Dec 2008 14:52:26 +1000 (EST) Message-Id: From: Geoff Huston To: "Pradosh Mohapatra (pmohapat)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408358A48@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 15:52:24 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D5408358A48@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat off On 02/12/2008, at 3:22 PM, Pradosh Mohapatra (pmohapat) wrote: > | > What if: when "I have been allocated 203.10.61.0/24", I > | issue an ROA > | > for the same with my origin AS? Doesn't that automatically > | mean that > | > all the advertisements of the prefix from another origin AS are > | > automatically invalid? > | > | > | No. Some folk believe that this should be the case, others > | believe that this should not be the case. Those who believe > | that this should not be the case are proposing the BOA as a > | form of explicitly stating what is invalid without having to > | state what is valid. > > Why should this not be the case? > Because the transitive closure of ROAs in an environment of piecemeal deployment is non-deterministic. > | By the way, given that you have published a ROA aithorizing > | your origin AS to advertise the prefix, I suspect that this > | has created some further vulnerabilities that a BOA would not > | create. What happens if I use this ROA you've created to > | hijack with your prefix by prepending your origin AS to my > | AS? Can a third party detect that this is a hijack of your > | prefix from the origination information and the ROA? I do not > | think so. > > This is a good example case for path attestation / complete AS_PATH > validation, no? When a third party tries to verify whether the > path leads back to origin AS, that should fail (whenever we get to > that part)... right - the "lets use magic" solution. I'm convinced. > > > | > As others have suggested, when "I have been allocated > | 203.10.60.0/22", > | > I issue an ROA for 203.10.60.0/22-22. That automatically means > that > | > there can't be any other advertisements for this prefix or its > more > | > specifics (unless I suballocate a more specific block and a new > ROA > | > gets added to the repository for that]. Is there any case > | that's not > | > handled by doing this? > | > > | > | That's your _assumption_ of the sematics of a ROA. What > | reference material or working group draft can you cite for > | semantic interpretation of a ROA? > | draft-ieft-sidr-roa-validation? I don't think so. The point > | of hte BOA draft it that it challenges this assumption by > | taking the position that such route aorigination authorities > | are explicitly scoped to the authority described in the > | object, without the implicit inclusion of any other authority > | or denial. > > So are you saying that an entity who is not owner of prefix 10/8 > can issue an ROA for it and it would be present in/added to the > RPKI repository? > The best answer I can give here is please read the sidr drafts. Your question really makes me suspect that you have not done so. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 1 22:52:57 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B968A3A6ABC; Mon, 1 Dec 2008 22:52:57 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE8AC3A6A85 for ; Mon, 1 Dec 2008 22:52:55 -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 E6qXROBI9C1w for ; Mon, 1 Dec 2008 22:52:55 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2CD2F3A6ABC for ; Mon, 1 Dec 2008 22:52:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,701,1220227200"; d="scan'208";a="119987214" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 02 Dec 2008 06:52:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mB26qpcQ019542; Mon, 1 Dec 2008 22:52:51 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB26qpjZ007378; Tue, 2 Dec 2008 06:52:51 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 22:52:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Dec 2008 22:52:46 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408358AA0@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-01.txt Thread-Index: AclUOc2vUYUdPRgfSwWmafXEAgCV5QAD6ykg References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D5408358A48@xmb-sjc-215.amer.cisco.com> From: "Pradosh Mohapatra (pmohapat)" To: "Geoff Huston" X-OriginalArrivalTime: 02 Dec 2008 06:52:51.0434 (UTC) FILETIME=[982F9CA0:01C9544A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1390; t=1228200771; x=1229064771; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[sidr]=20Request=20for=20WG=20Last=20Ca ll=20fordraft-ietf-sidr-bogons-02.txt=20anddraft-ietf-sidr-r oa-validation-01.txt |Sender:=20; bh=luk4HQ1ETpPElr7FRBBPPTygOOXtDmeSWa7m/hNOpFs=; b=XenWmM+w4y6kGDADfhGbITQYUggwlI6JB6r4Jko6pDE1izXVgTv/EOKBIm MetDhFjKb95+mwyXF5LSNAs98Jk95WaG42JFuZ0HTQauJXwlWTK4txpZ+jEs FSDhT3LPho; Authentication-Results: sj-dkim-3; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org | > | > As others have suggested, when "I have been allocated | > | 203.10.60.0/22", | > | > I issue an ROA for 203.10.60.0/22-22. That automatically means | > that | > | > there can't be any other advertisements for this prefix or its | > more | > | > specifics (unless I suballocate a more specific block and a new | > ROA | > | > gets added to the repository for that]. Is there any case | > | that's not | > | > handled by doing this? | > | > | > | | > | That's your _assumption_ of the sematics of a ROA. What reference | > | material or working group draft can you cite for semantic | > | interpretation of a ROA? | > | draft-ieft-sidr-roa-validation? I don't think so. The | point of hte | > | BOA draft it that it challenges this assumption by taking the | > | position that such route aorigination authorities are explicitly | > | scoped to the authority described in the object, without the | > | implicit inclusion of any other authority or denial. | > | > So are you saying that an entity who is not owner of prefix | 10/8 can | > issue an ROA for it and it would be present in/added to the RPKI | > repository? | > | | The best answer I can give here is please read the sidr | drafts. Your question really makes me suspect that you have | not done so. I have. Your response above prompted the question. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 2 00:44:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECB43A6829; Tue, 2 Dec 2008 00:44:05 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487F83A6829 for ; Tue, 2 Dec 2008 00:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 K5l8+Xmb-SQE for ; Tue, 2 Dec 2008 00:44:03 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 2B68D3A67CC for ; Tue, 2 Dec 2008 00:44:03 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id E37EE11006A; Tue, 2 Dec 2008 18:43:56 +1000 (EST) Message-Id: <18FA6812-803A-455F-A29D-B5728C72BEE8@apnic.net> From: Geoff Huston To: Pradosh Mohapatra (pmohapat) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5408358AA0@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 19:43:50 +1100 References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D5408358A48@xmb-sjc-215.amer.cisco.com> <04 CAD96D4C5A3D48B1919248A8FE0D5408358AA0@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 02/12/2008, at 5:52 PM, Pradosh Mohapatra (pmohapat) wrote: > | > | > As others have suggested, when "I have been allocated > | > | 203.10.60.0/22", > | > | > I issue an ROA for 203.10.60.0/22-22. That automatically means > | > that > | > | > there can't be any other advertisements for this prefix or its > | > more > | > | > specifics (unless I suballocate a more specific block and a > new > | > ROA > | > | > gets added to the repository for that]. Is there any case > | > | that's not > | > | > handled by doing this? > | > | > > | > | > | > | That's your _assumption_ of the sematics of a ROA. What > reference > | > | material or working group draft can you cite for semantic > | > | interpretation of a ROA? > | > | draft-ieft-sidr-roa-validation? I don't think so. The > | point of hte > | > | BOA draft it that it challenges this assumption by taking the > | > | position that such route aorigination authorities are explicitly > | > | scoped to the authority described in the object, without the > | > | implicit inclusion of any other authority or denial. > | > > | > So are you saying that an entity who is not owner of prefix > | 10/8 can > | > issue an ROA for it and it would be present in/added to the RPKI > | > repository? > | > > | > | The best answer I can give here is please read the sidr > | drafts. Your question really makes me suspect that you have > | not done so. > > I have. Your response above prompted the question. WG Chair Hat OFF. Good to hear. In which case you would be well aware that a person who is not the current right of use holder of an address prefix cannot generate a valid RPKI object of any form and sign the object with an RPKI signature using that prefix. So I fail to understand how an an entity who is not owner of prefix 10/8 can issue an ROA for it that would be considered valid in the RPKI, and if its invalidly signed then whether it is in an RPKI repository publication point or not is irrelevant. But as we've all read the drafts we all knew that anyway. So I'm not sure why its worth repeating here. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 2 09:22:23 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB613A69F2; Tue, 2 Dec 2008 09:22:23 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0113A69F2 for ; Tue, 2 Dec 2008 09:22:22 -0800 (PST) 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=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHtc54n1SXcz for ; Tue, 2 Dec 2008 09:22:21 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2FD493A67D0 for ; Tue, 2 Dec 2008 09:22:21 -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 mB2HMDq4029841; Tue, 2 Dec 2008 11:22:13 -0600 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 mB2HMCXT031466; Tue, 2 Dec 2008 11:22:12 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 12:22:12 -0500 Date: Tue, 2 Dec 2008 12:22:11 -0500 (Eastern Standard Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: <4232C338-DC4C-4746-90BD-5C83C31172A9@tcb.net> Message-ID: References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net> <56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net> <0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net> <19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net> <16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net> <264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <4232C338-DC4C-4746-90BD-5C83C31172A9@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 02 Dec 2008 17:22:12.0255 (UTC) FILETIME=[8363A2F0:01C954A2] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mon, 1 Dec 2008, Danny McPherson wrote: > > On Dec 1, 2008, at 4:12 PM, Sandra Murphy wrote: >> >> The issue in incremental deployment is not what the people who haven't >> deployed it should do but what the people who DO deploy it should do. What >> do the people who DO understand ROAs(and BOAs) do when they see something >> unsecured - it might be legit, just not produced by someone who understands >> ROAs(BOAs). > > Right, but if the owner also published a BOA about who they > should not accept it from - what's the value add for those > who have deployed it again? They can say, ohh, there's a ROA > for AS 1 to originate 10.0.0.0/8. They also published a BOA > for AS2 to originate 10.0.0.0/16. So, what's that mean to me > since I deployed it? Accept 10.0.0.0/8 only from AS 1. I'm > not going to put a policy in my router that says AND accept > it from anyone else, or any more specific, except AS 2. Tracking > those BOAs is costing money (hardware, time, complexity) and > there is no added benefit. Danny, BOAs don't say "don't accept 10/8 from AS2". They say "don't accept any advertisement for 10/8". > >>> I still don't by it.. As an operator, you tell me who is authorized >>> to originate and that's the only origin AS I accept. That's easier to >>> configure in a router, requires less objects in the RPKI, and makes life >>> much simpler. >> >> So it seems you are in the "and that's all" camp in interpreting ROAs, >> right? > > No, I'm in the "show-me-how-to-configure-this-in-a-router-and- > convince-me-that-all-the-complexity-and-added-infrastructure-is > worth-the-investment-when-I'm-pretty-sure-I'd-be-just-as-happy > with-an-'explicit accept'='implicit deny'-model-like-all-my-other- > security-policies" camp. I was trying to guess what you think a ROA means. Your previous statements and this statement make it sound like you think a prefix holder will sign ROAs for every and all ASs that are allowed to advertise the prefix, so signing ROAs means "these ASs are allowed to announce the prefic -- and that's all". Those configuring their routers use that semantics to decide what to configure. If you think that a set of ROAs means "these ASs are allowed to announce the prefix, but not necessarily only these ASs", then router configuration goes differently. We are presently working out how the meaning of these ROAs results in router configuration. If you have ideas of how the configuration would happen, it would be valuable for us to hear them. > > I'm certain that if more people who are supposed to deploy this > stuff were paying attention they'd be making the same arguments, > but they're not, and so we need to give heavy consideration to this. > >> Does your answer assume operators are using ROAs to produce route filters? > > Maybe. > >> Does your answer change if operators are using ROAs in the decision >> procedure, as presented at the last meeting? > > > Maybe. I presume there's a smilie in there. So when you figure it out, you'll let us know, right? :-) --Sandy > > -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 2 10:06:12 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4956328C125; Tue, 2 Dec 2008 10:06:12 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE4F28C125 for ; Tue, 2 Dec 2008 10:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 gDmc-iIV+ul4 for ; Tue, 2 Dec 2008 10:06:10 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 23C1028B56A for ; Tue, 2 Dec 2008 10:06:10 -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 mB2I5uOP030783; Tue, 2 Dec 2008 12:05:57 -0600 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 mB2I0tUD000699; Tue, 2 Dec 2008 12:05:56 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 13:02:38 -0500 Date: Tue, 2 Dec 2008 13:02:38 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> Message-ID: References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 02 Dec 2008 18:02:38.0458 (UTC) FILETIME=[2984D5A0:01C954A8] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 2 Dec 2008, Geoff Huston wrote: > WG Chair Hat OFF > > On 02/12/2008, at 11:05 AM, Pradosh Mohapatra (pmohapat) wrote: > >> Hi Geoff, >> >> | >> 1. I have been allocated 203.10.61.0/24. I do not use it >> | today in any >> | >> public routing context. It should not appear in BGP at >> | all. I do not >> | >> give my authorization to any AS to originate a route for >> | this prefix, >> | >> or any more specific of this prefix. If I generate a BOA for >> | >> 203.10.61.0/24 then my intention of saying that any use of this >> | >> prefix in the public Internet is unauthorized is clear. >> | > >> | > If you do not give your authorization then do not issue a ROA. >> | > With the incremental deployment argument, I'm not sure who would be >> | > looking at BOAs if they're not looking at ROAs. >> | >> | I'm sorry, but I cannot see any logic in that response. If I >> | do not give my authorization and I would like to inform >> | everyone else that any use of this address, or this AS is an >> | instance of a hijack then your response seems to be saying to >> | me that I should not do anything. >> | If that is what you are saying then it seems to be a totally >> | ineffectual course of action in my opinion. >> >> >> What if: when "I have been allocated 203.10.61.0/24", I issue an >> ROA for the same with my origin AS? Doesn't that automatically >> mean that all the advertisements of the prefix from another origin >> AS are automatically invalid? > > > No. Some folk believe that this should be the case, others believe that this > should not be the case. Those who believe that this should not be the case > are proposing the BOA as a form of explicitly stating what is invalid > without having to state what is valid. Can you explain why you think it better to say what is invalid rather than stating what is valid? > > By the way, given that you have published a ROA aithorizing your origin AS to > advertise the prefix, I suspect that this has created some further > vulnerabilities that a BOA would not create. What happens if I use this ROA > you've created to hijack with your prefix by prepending your origin AS to my > AS? Can a third party detect that this is a hijack of your prefix from the > origination information and the ROA? I do not think so. > > We all recognize and acknowledge that the sidr work does not protect against those who want to append the valid origin on an invalid path. The sidr work protects the origin of the AS_PATH only, and does not provide protection of the validity of the rest of the AS_PATH. Recognize that protection of the origination of the route is NECESSARY. Everything we do here is needed by any protection of the full AS_PATH developed some time in the future. >> And since I will not be generating >> any updates for this prefix, it will not appear in BGP at all! >> Doesn't that solve the problem you cited? > > no - see above,. Please explain further. It appears to me that if you take the "these ASs and that's all" interpretation of a set of ROAs, an AS that produces one ROA does prevent other ASs from advertising the prefix (and being believed). > >> Are you concerned that >> some other AS would also issue an ROA for the same or a more >> specific block of the prefix? That can't be! > >> >> | >> 2. I have been allocated AS 131074 as an AS number. I do >> | not use it >> | >> today in any public routing context. It should not appear >> | in BGP at >> | >> all either as an origination AS nor as a transit AS in any AS path. >> | >> If I generate a BOA for AS131074 then my intention of >> | saying that any >> | >> use of this AS number in the public Internet is unauthorized is >> | >> clear. >> | > >> | > But the draft currently does not mitigate "nor as a transit AS", >> | > unless I'm missing something. Specifically: >> | > >> | > S.5 graf 2: >> | > >> | > "If a route object has an AS origination that refers to an >> | AS number >> | > that is listed in a valid BOA, then the route object can be >> | regarded >> | > as a Bogon object, and local policies that apply to Bogon >> | AS's can be >> | > applied to the object. This holds whether or not the >> | address prefix of >> | > the route object is described by a valid ROA or not." >> | > >> | > I see nothing about "or as a transit AS" in there. >> | >> | My apologies - we are not allowed to talk about transit yet >> | as its not an agreed requirement coming out of RSPSEC. So if >> | I remove "nor as a transit AS" and sundry words then I trust >> | that the point I was making is amply clear. >> >> >> How important is the case of "AS protection" as opposed to >> "prefix" protection? Doesn't this automatically become a >> by-product of ROA level checks? >> >> > > No, it does not. There are many instances of use of AS numbers what are not > recorded in any allocation database. See the attached list for today's set of > bogon ASs Who would sign the BOAs for unallocated ASs? (I don't know. RIRs? How would that work -- would such a BOA have to change with each new allocation? Would there be a BOA for each unallocated AS that would be revoked when it was allocated?) > > >> | >> 3. I have been allocated 203.10.60.0/22. I wish to ensure that any >> | >> more specific advertisement of this prefix is unauthorized. If I >> | >> generate a BOA for 203.10.60.0/23 AND 203.10.62.0/23 then my >> | >> intention is clear. >> | > >> | > I still don't by it.. As an operator, you tell me who is >> | authorized >> | > to originate and that's the only origin AS I accept. >> | That's easier to >> | > configure in a router, requires less objects in the RPKI, and makes >> | > life much simpler. >> | >> | >> | No security at all makes like enormously simpler. At some >> | point it is >> | necessary to understand what makes a robust security >> | environemnt even >> | in a world of partial use and piecemeal adoptions and then work >> | through the issues related to operational deployment. But you appear >> | to have some other approach in mind. >> >> As others have suggested, when "I have been allocated 203.10.60.0/22", >> I issue an ROA for 203.10.60.0/22-22. That automatically means that >> there can't be any other advertisements for this prefix or its more >> specifics (unless I suballocate a more specific block and a new ROA >> gets added to the repository for that]. Is there any case that's not >> handled by doing this? >> > > That's your _assumption_ of the sematics of a ROA. What reference material or > working group draft can you cite for semantic interpretation of a ROA? > draft-ieft-sidr-roa-validation? I don't think so. The point of hte BOA draft > it that it challenges this assumption by taking the position that such route > aorigination authorities are explicitly scoped to the authority described in > the object, without the implicit inclusion of any other authority or denial. We are still in the process of specifying things and what they mean, i.e., the drafts aren't done yet. Actually, we are not arguing about the semantics of a single ROA as much as we are arguing about the semantics of a set of ROAs. If one ROA means "this AS is allowed to advertise this prefix", does the complete set of ROAs mean "these ASs and maybe others are allowed to advertise this prefix" or "these ASs and no others are allowed to advertise this prefix". Do prefix holders (who are RPKI aware) sign ROAs for every AS that might announce their prefix? If so, what does that mean about interpreting ROAs? If not, what does that mean about interpreting ROAs? > > AS referred to earlier, here's the list of today's bogon AS numbers, just in > case you thought that this is a non-problem: > > Wow. And the Internet still works. Amazing. Given the general falibility of humans, I presume there are cases where one AS gets its AS number wrong and uses some other (allocated) AS number? Is that common? There are configuration options to check if your neighbor AS is using the proper AS number in its advertisement to you - but since it's an option, I'm guessing you can NOT check if you want. What is the damage right now to using an unallocated AS? Mis-using an allocated AS? What would be the damage in an RPKI aware router from an announcement that used an unallocated AS? (Would ROAs or prefix-BOAs prevent such announcements?) What about an announcement that mis-used an allocated AS? --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 2 11:56:29 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F1A3A68BE; Tue, 2 Dec 2008 11:56:29 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DE93A6B51 for ; Tue, 2 Dec 2008 11:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 cbv5qFQ37Xjl for ; Tue, 2 Dec 2008 11:56:28 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id EA73A3A68BE for ; Tue, 2 Dec 2008 11:56:27 -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 mB2JuKMD000746; Tue, 2 Dec 2008 13:56:20 -0600 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 mB2JuKx3006543; Tue, 2 Dec 2008 13:56:20 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 14:56:19 -0500 Date: Tue, 2 Dec 2008 14:56:19 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: <6F70023C-57B1-4C8D-8DDF-B9D7D8F139F9@apnic.net><56AFA6B5-BCFB-4CDC-B921-3590F71CCBA0@tcb.net><0072BC84-507D-497C-B8B6-0F26DE804316@apnic.net><19318B76-0E1E-4DC5-8017-D2350352169C@tcb.net><16C1A7B4-C46F-4354-B1F8-4AF8EB5249B9@apnic.net><264FCEF8-3DD1-49AB-B41F-56FD0A1B2870@tcb.net> <76720B94-5516-48BB-9D83-F3182969A6DE@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D540835895A@xmb-sjc-215.amer.cisco.com> <3C4C05F3-8554-4F68-9508-F6B1E3E20660@apnic.net> <04CAD96D4C5A3D48B1919248A8FE0D5408358A48@xmb-sjc-215.amer.cisco.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 02 Dec 2008 19:56:19.0614 (UTC) FILETIME=[0B3EA3E0:01C954B8] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call fordraft-ietf-sidr-bogons-02.txt anddraft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 2 Dec 2008, Geoff Huston wrote: > WG Chair Hat off > > On 02/12/2008, at 3:22 PM, Pradosh Mohapatra (pmohapat) wrote: > >> | > What if: when "I have been allocated 203.10.61.0/24", I >> | issue an ROA >> | > for the same with my origin AS? Doesn't that automatically >> | mean that >> | > all the advertisements of the prefix from another origin AS are >> | > automatically invalid? >> | >> | >> | No. Some folk believe that this should be the case, others >> | believe that this should not be the case. Those who believe >> | that this should not be the case are proposing the BOA as a >> | form of explicitly stating what is invalid without having to >> | state what is valid. >> >> Why should this not be the case? >> > > Because the transitive closure of ROAs in an environment of piecemeal > deployment is non-deterministic. I can't grasp this statement. What do you mean by transitive closure of ROAs? ROAs aren't a relation that could be performed transitively. And I don't see the non-determinism. Are you saying that the complete set of ROAs does not give you the complete set of valid advertisements? If so, then you are using the "these ASs and maybe others" semantics. Right? > > > >> | By the way, given that you have published a ROA aithorizing >> | your origin AS to advertise the prefix, I suspect that this >> | has created some further vulnerabilities that a BOA would not >> | create. What happens if I use this ROA you've created to >> | hijack with your prefix by prepending your origin AS to my >> | AS? Can a third party detect that this is a hijack of your >> | prefix from the origination information and the ROA? I do not >> | think so. >> >> This is a good example case for path attestation / complete AS_PATH >> validation, no? When a third party tries to verify whether the >> path leads back to origin AS, that should fail (whenever we get to >> that part)... > > right - the "lets use magic" solution. I'm convinced. I don't understand this statement. But I've already noted that we're not working on protecting the AS_PATH beyond the origination point. I think that when Pradosh said "whenever we get to that part" he was referring to potential future work to protect the AS_PATH beyond the origination. > > >> >> >> | > As others have suggested, when "I have been allocated >> | 203.10.60.0/22", >> | > I issue an ROA for 203.10.60.0/22-22. That automatically means that >> | > there can't be any other advertisements for this prefix or its more >> | > specifics (unless I suballocate a more specific block and a new ROA >> | > gets added to the repository for that]. Is there any case >> | that's not >> | > handled by doing this? >> | > >> | >> | That's your _assumption_ of the sematics of a ROA. What >> | reference material or working group draft can you cite for >> | semantic interpretation of a ROA? >> | draft-ieft-sidr-roa-validation? I don't think so. The point >> | of hte BOA draft it that it challenges this assumption by >> | taking the position that such route aorigination authorities >> | are explicitly scoped to the authority described in the >> | object, without the implicit inclusion of any other authority >> | or denial. >> >> So are you saying that an entity who is not owner of prefix 10/8 >> can issue an ROA for it and it would be present in/added to the >> RPKI repository? >> > > The best answer I can give here is please read the sidr drafts. Your question > really makes me suspect that you have not done so. I think Pradosh was asking his question about your statement, not the drafts. The 10/8 and other non-globally-routed prefixes are, according to my reading of the drafts, intended to be protected within one AS by a local RPKI structure rooted on a local trust anchor. --Sandy > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 2 12:19:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D663A6B5D; Tue, 2 Dec 2008 12:19:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9505B3A6B3D for ; Tue, 2 Dec 2008 12:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s58+kd196-v9 for ; Tue, 2 Dec 2008 12:19:23 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A1B8C3A69DE for ; Tue, 2 Dec 2008 12:19:23 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L7biG-0005S5-Fz; Tue, 02 Dec 2008 15:19:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <492EB12F.4090107@ripe.net> References: <4922E1E3.4020608@ripe.net> <492EB12F.4090107@ripe.net> Date: Tue, 2 Dec 2008 15:18:31 -0500 To: Robert Kisteleki From: Stephen Kent Cc: sidr@ietf.org Subject: [sidr] draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 3:39 PM +0100 11/27/08, Robert Kisteleki wrote: >Stephen Kent wrote: >>However, I worry that we need to tightly restrict which RPSL data >>can be validated using an RPKI cert. My concern is that it would be >>easy for folks to misinterpret the extent of what an RPLI cert >>attests to, and thus accord signed RPSL data more trust than it >>deserves. I also worry that using RPKI certs for this purpose might >>cause folks to want to have Subject names be meaningful, not >>arbitrary, as now required by our specs. So, if Robert is >>comfortable with imposing these sorts of constraints, I think it >>appropriate to make this a work item. > >Section (2) of the draft says: > >"2. Meaning of a signature > > By signing an RPSL object, the signer of the object expresses that: > o they have the right to use the resource that the object refers to > (ie. found as the primary key or in some other field of the > object); > o ..." > >So in fact I already restrict the usage to only those type of >objects that have something to to with actual number resources (ie. >this excludes person objects). I'd be less comfortable to state *in >this document* that the certificate subject names should not be >meaningful; I'd defer that to the higher level documents such as the >certificate profile and architecture documents. However, since this >is only redundancy, not a new requirement, I'm not specifically >against this. > >Robert Robert, Thanks for the clarification., but I still have some serious concerns that I think need to be addressed as we progress this as a WG item. I looked at your document and I see that section 5 is a "Minimum set of Signed Attributes." To try to prevent the problem I cited, it really needs a definitive list of the objects and attributes that MAY be signed, with a prohibition on signing any other objects/attributes. This is the opposite of what your text says, as it allows the signer to include whatever other attributes the signer wishes. The name of an AS is NOT something that can be validated using the RPKI, and this needs to made clear to folks using this mechanism. The same is true for net name, org, country and status. The simplest thing to do would be to exclude these as signed attributes. I am not very familiar with the attributes you listed for the four object types, but I suspect that a more of them will fall into this category. Also, for each of these objects/attributes, you need to describe what constitutes validation based on an appropriate cert or ROA, i.e., what checks MUST be performed by the RP to ensure that the signed object/attributes are consistent with the ROKI objects used to verify the signature. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 2 16:24:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E7D28C227; Tue, 2 Dec 2008 16:24:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B6928C20D for ; Tue, 2 Dec 2008 16:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 4NZrF2RVDKrs for ; Tue, 2 Dec 2008 16:24:23 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 932A728C207 for ; Tue, 2 Dec 2008 16:24:23 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L7fXL-0007gK-Fp; Tue, 02 Dec 2008 19:24:16 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 2 Dec 2008 19:24:12 -0500 To: Geoff Huston From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 6:59 AM +1100 12/2/08, Geoff Huston wrote: >WG Hair hat OFF > >Hi Steve, > >What I _think_ you describes as the "ROA use convention" is the use >of a ROA with an AS of 0 to act as an explicit denial in terms of >saying "these prefixes are bogons". I could be wrong in my >understanding of course. I would not use the term "bogons" right now, given the debate about the meaning. The intent of the AS 0 ROA convention is to make an assertion that can be verified within the RPKI and which gives a relying party a basis for rejecting unverified assertions about routes for the prefix(es) in question. >I must admit that right now I don't think I understand your proposed >"ROA use convention" clearly enough to agree with your assertion > >The BOA Approach: > >The BOA document is coupled with the ROA validation document so that >the ROA interpretation and the BOA interpretation are explicitly >described. in this context the ROA does NOT act with a double >meaning - it is an explicit authority without any implicit negation >connotations. While it is fair to say that issuing an AS 0 ROA is intended to convey a special meaning, the processing of such a ROA is exactly the same as for any other ROA. So I hesitate to use the phrase "double meaning" even though I am sympathetic with your use of that term. >The presence of a ROA does not act as a form of negation of any >other form of route origination. The BOA has no max length attribute >- any more specific of any prefix described in the BOA is >encompassed in the BOA. > >The "ROA use convention": > >This "ROA use convention" has me confused. In particular my >confusion lies in the following areas: > > 1. Does a 'convention ROA' has any implicit denial associated with >it, or is it a simple positive assertion as described above? An AS 0 ROA is a positive assertion about the prefixes expressed in it, as far as RP software is concerned. The "feature" of this assertion is that, any unauthenticated assertions about the prefixes should be rejected in favor of this verifiable ROA (assuming that the ROA was signed by an entity that holds the prefixes in question). In saying that I am making some assumptions about how ROs use ROAs, and Danny has argued that we need to be more precise about such assumptions. I see the AS 0 ROA as a valuable tool to deal with unallocated and reserved address space, during the very long period when relying parties will see a mix of verifiable and unverifiable assertions about route origination. I have not thought so much about the utility of this capability in a fully deployed system. I also did not consider assertions about AS numbers, a feature of BOAs. > 2. How should a ROA with a AS value of 0 and a maxlength attribute >be interpreted. > Does a ROA for prefix=10.0.0.0/8 maxlength=8, AS=0 say >anything at all about 10.0.0.0/9? To prevent unauthenticated assertions about all more specific prefixes from being accepted, the max length would have to be 32. Otherwise, an unauthenticated assertion about a longer prefix would not be "trumped" by the AS 0 ROA. >So if you don't mind I'll reserve judgement on your question and >observe that while the BOA adds a further object to the repertoire >of 'recognised' RPKI signed objects, it does so in a manner that >makes negation explicit, does not rely on variable interpretation of >ROAs, does not stretch the ROA semantics beyond the simple positive >authority to as AS to originate a route and allows for incremental >piecemeal deployment in the network. I admit that the AS 0 convention is a way of expressing a negative assertion about resources under the control of the ROA signer. However, I think the fact that this mechanism does not create a new type of sighed object, and requires no new processing, makes it worthwhile to consider. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 2 17:12:16 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BF028C23E; Tue, 2 Dec 2008 17:12:16 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED6028C23E for ; Tue, 2 Dec 2008 17:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[AWL=-1.095, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, MANGLED_BEST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxMMYGhqxmcN for ; Tue, 2 Dec 2008 17:12:14 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 1636228C236 for ; Tue, 2 Dec 2008 17:12:14 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 3EA61368028; Tue, 2 Dec 2008 18:12:10 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 02 Dec 2008 18:12:10 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=52522; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <9B9AF45C-7231-4F82-8CBA-A8A8E2D40CB9@tcb.net> From: Danny McPherson To: Stephen Kent , Matt Lepinski Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 2 Dec 2008 18:12:08 -0700 X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: [sidr] Comments on sidr-arch-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Matt/Steve, Finally find time to do a detailed review of sidr-arch-04, some comments below. --- High-level comments: - Use of the term "holder", "resource holder", "legitimate holder", etc.. occurs throughout. It might be useful to make this term explicit. - Use of the terms "registry/registries" and "subscribers" is loose and could use an explicit definition and some consistency early in the document, in particular in S 2 where some ambiguities might exist. - S 3.1. I quite like this section, in particular: "These filters would prevent importation of any route in which the origin AS of the AS-PATH attribute is not an AS that is authorized (via a valid ROA) to originate the route. (See Section 6.3 for more details.)" The reference should be S 7.3, not S 6.3. Furthermore, given this text, and all of S 7.3., and discussions on the mailing list as of late, we should perhaps revisit this discussion explcitly and rework this text to accommodate consensus, and see that any consensus finds it's way into subsequent documents (e.g., the ROA validation I-D). - Perhaps it'd be useful throughout to replace "portable" with PI and PA, and then expand upon PA w/multi-homed from there? Introducing the term portable may not necessarily mean PI, of course. S 7.2.3. attempts to talk about this briefly. - Option 1 in 7.2.2 seems untenable to me. If the "susbcriber" isn't willing to deal with getting their own AS, then it is quite certain they'll not want to bother with getting a CA, creating ROAs, etc.. Either way, in both examples, it's most likely to be handled via proxy functions by one of the ISPs involved. It may be worth noting here that inconsistent AS origins are generally considered undesirable on the global Internet, for this, and other reasons. On that, I wonder if any more text needs to be added regarding issues with "proxy" handling by ISPs in scenarios such as this, or do you believe we're covered fully with the existing framework? Furthermore, on 3/2007 Iljitsch pointed out that there is very little discussion of a case where "customer M" announces a subset of ISP 1s address block to ISP 1 and ISP 2 and you agreed to add some text around this. I don't see it either. - IANA Considerations surely should include some guidance to IANA about investigation and preparation for anything that might be required WRT serving as a TA. Also, for legacy space, etc.. In general, I like to see more description and discussion of the TA model here, as others (e.g., Roque on 11/17/08) and previous discussions seem to support as well. --- Editorial comments: - You'll need to update to the 4748 boilerplate in the next revision, as you likely know. - sidr-res-certs-14 reference can be updated to -15 now. - S 2. s/block of IP address/block of IP address/ s/knowledge the/knowledge of the/ s/IP address is hierarchic/IP addresses is hierarchic/ s/National Internet Registries and (NIRs)/National Internet Registries (NIRs), as/ s/regional or national registries/RIRs or NIRs/ - S 2.1. The acronymn 'CA' is introduced for the first time, might be good to expand it in it's first use in an architecture document. - S 2.2. Graf 1 Ref to 6.2.2 should be 7.2.2. s/internet registry or/RIR or/ - S 2.5. What would "in an out-of band fashion" entail in practice? s/material provide to/material to/ - S 3. The tail end of this reads a bit odd: "A Route Origination Authorization (ROA) makes such authorization explicit, allowing a holder of address space to create an object that explicitly and verifiably asserts that an AS is authorized originate routes to prefixes." Perhaps replace "to prefixes" with "for a given set of prefixes"? - S 3.1. Graf 2 ref should be S 7.3, not S 6.3. - S 3.2. s/time that is quite low/that time is quite low/ - S 4. s/The use access controls/The use of access controls/ - S 4.2. s/each registry/each RIR/ ? s/Registries are encouraged/RIRs are encouraged/ ? s/encouraged maintain/encouraged to maintain/ - S 6. Graf 1 ref should be 7.3, not 6.3. Should't step 3 also saying something about missing data as well, as S 7.3. does for ROAs? - S 7. I'm not sure first-hop AS is unambiguous. Why not be explicit and say "origin AS" here? - S 7.1. Graf 1 ref should be 7.2.2., not 6.2.2. Graf 3 perhaps s/effected by/accomplished by/ ? s/SHOULD NOT to/SHOULD NOT/ - S 7.2.1. s/certificates its own/certificates from its own/ - S 7.2.2. s/originate routers/originate routes/ s/encompassing prefix/encompassing aggregate/ ? - S 7.2.3. s/regional or national registry/RIR or NIR/ - 7.3. This entire section needs reworked, IMO. Perhaps it should just be removed and handled elsewhere, e.g., the ROA validation draft? I particularly do not like this text, which seemed to be bolted onto the end, clearly as an afterthought: "(and thus the filter described below which naively rejects all UPDATES without a corresponding ROA would incorrectly reject valid routes originated by ISPs that do not yet implement this architecture)." - S 8. s/database servers/database servers./ - S 10. s/Time/Tim/ - S 11.1. You should all those shold be Normative references, I wouldn't think so. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 00:52:38 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF59428C0DC; Wed, 3 Dec 2008 00:52:37 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C06E3A6B36 for ; Wed, 3 Dec 2008 00:52:37 -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 l8ZOimZbuT9X for ; Wed, 3 Dec 2008 00:52:36 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 2B71B28C0F3 for ; Wed, 3 Dec 2008 00:52:36 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1L7nTC-0005hg-CH; Wed, 03 Dec 2008 09:52:30 +0100 Received: from Kistel-Mac.local (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id 4D6F42F583; Wed, 3 Dec 2008 09:52:30 +0100 (CET) Message-ID: <493648CE.7000307@ripe.net> Date: Wed, 03 Dec 2008 09:52:30 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Stephen Kent References: <4922E1E3.4020608@ripe.net> <492EB12F.4090107@ripe.net> In-Reply-To: X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274e14c6541d7d557d1245834d8f1ddd879 Cc: sidr@ietf.org Subject: Re: [sidr] draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi, > Robert, > > Thanks for the clarification., but I still have some serious concerns > that I think need to be addressed as we progress this as a WG item. > > I looked at your document and I see that section 5 is a "Minimum set of > Signed Attributes." To try to prevent the problem I cited, it really > needs a definitive list of the objects and attributes that MAY be > signed, with a prohibition on signing any other objects/attributes. > This is the opposite of what your text says, as it allows the signer to > include whatever other attributes the signer wishes. > > The name of an AS is NOT something that can be validated using the RPKI, > and this needs to made clear to folks using this mechanism. The same is > true for net name, org, country and status. The simplest thing to do > would be to exclude these as signed attributes. I am not very familiar > with the attributes you listed for the four object types, but I suspect > that a more of them will fall into this category. The intention here is that the owner of the resources can make verifiable statements. They can claim, by constructing and signing RPSL objects, that certain facts are true regarding the use of the resource; in other words, this mechanism allows the holder of the resources to bind their resources and other info together. So it's really intentional that other attributes such as org name, AS name, import/export attributes, contact info, ... can be covered by the signature, even though these are not number resources. If we state that the only attributes that can be signed are the ones that carry number resources, and which can also be found in the covering certificate (ie. your "maximum set" approach, if I understand correctly), then there is no practical gain for the signature. The only only meaning for such an object in my interpretation would be "The resource holder has spoken. They said they have an object." without any verifiable claims about the actual content of the object. Based on this, I believe that the current "minimum set" specification is the right approach. > Also, for each of these objects/attributes, you need to describe what > constitutes validation based on an appropriate cert or ROA, i.e., what > checks MUST be performed by the RP to ensure that the signed > object/attributes are consistent with the ROKI objects used to verify > the signature. Very good suggestion, I completely agree with it. Regards, Robert > Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 07:58:09 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44153A694C; Wed, 3 Dec 2008 07:58:09 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC363A694C for ; Wed, 3 Dec 2008 07:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 o9xoKuQzqpsT for ; Wed, 3 Dec 2008 07:58:08 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 278BE3A692F for ; Wed, 3 Dec 2008 07:58:08 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L7u6y-0001Bz-B4; Wed, 03 Dec 2008 10:58:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <493648CE.7000307@ripe.net> References: <4922E1E3.4020608@ripe.net> <492EB12F.4090107@ripe.net> <493648CE.7000307@ripe.net> Date: Wed, 3 Dec 2008 10:55:02 -0500 To: Robert Kisteleki From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-kisteleki-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 9:52 AM +0100 12/3/08, Robert Kisteleki wrote: >Hi, > >>Robert, >> >>Thanks for the clarification., but I still have some serious >>concerns that I think need to be addressed as we progress this as a >>WG item. >> >>I looked at your document and I see that section 5 is a "Minimum >>set of Signed Attributes." To try to prevent the problem I cited, >>it really needs a definitive list of the objects and attributes >>that MAY be signed, with a prohibition on signing any other >>objects/attributes. This is the opposite of what your text says, >>as it allows the signer to include whatever other attributes the >>signer wishes. >> >>The name of an AS is NOT something that can be validated using the >>RPKI, and this needs to made clear to folks using this mechanism. >>The same is true for net name, org, country and status. The >>simplest thing to do would be to exclude these as signed >>attributes. I am not very familiar with the attributes you listed >>for the four object types, but I suspect that a more of them will >>fall into this category. > >The intention here is that the owner of the resources can make >verifiable statements. They can claim, by constructing and signing >RPSL objects, that certain facts are true regarding the use of the >resource; in other words, this mechanism allows the holder of the >resources to bind their resources and other info together. So it's >really intentional that other attributes such as org name, AS name, >import/export attributes, contact info, ... can be covered by the >signature, even though these are not number resources. The problem is that the RPKI cert(s) used to verify such signed assertions do not attest to the accuracy of the other attributes. This means that we are allowing (really encouraging) relying parties to accept as accurate the data verified using RPKI certs, and that is dangerous. It creates potential liabilities for the CAs in the RPKI. For example, if an ISP asserts in a signed object that it's name is Foo Corp, when in reality its name is Bar Co., this could create a liability for the registry that issued the CA cert to Bar Co. We have tried to avoid this sort of liability by restricting the subject names in resource certs to be non-meaningful, and this proposal reintroduces this liability. >If we state that the only attributes that can be signed are the ones >that carry number resources, and which can also be found in the >covering certificate (ie. your "maximum set" approach, if I >understand correctly), then there is no practical gain for the >signature. The only only meaning for such an object in my >interpretation would be "The resource holder has spoken. They said >they have an object." without any verifiable claims about the actual >content of the object. I think you are underestimating what could be done, but maybe I don't know enough about RPSL. Let me give an example: If an ISP signs an object that asserts that it announces routes for several prefixes, then this assertion could be verified using a combination of the ROAs that attest to the origin AS info for each prefix, plus the transitive verification of similar records signed by other ISPs. That would provide the sort of static connectivity verification that soBGP proposed. This is an example of a set of assertions that could be verified using data to which the RPKI attests. > >Based on this, I believe that the current "minimum set" >specification is the right approach. I have to disagree. I think the proposal suffers from many of the same security problems that arise if one uses (non-resource) certs for authentication of RPSL data today, i.e., what you enable is an authenticated entity to make arbitrary assertions about arbitrary data. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 10:19:23 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778923A68D5; Wed, 3 Dec 2008 10:19:23 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E08F3A68EC for ; Wed, 3 Dec 2008 10:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=0.083, 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 e023c3IgsqdY for ; Wed, 3 Dec 2008 10:19:21 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 92A933A6802 for ; Wed, 3 Dec 2008 10:19:21 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id B843C36803E; Wed, 3 Dec 2008 11:19:17 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 03 Dec 2008 11:19:17 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=61720; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> From: Danny McPherson To: Geoff Huston In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 11:19:16 -0700 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote: > WG Chair Hat OFF > > Since Sandy's Last Call on this document there have been a few > changes to the document which I should note here. > > The first set of changes concerns the revision from -13 to -14 (http://smakd.potaroo.net/cgi-bin/htmlwdiff?f1=..%2fall-ids%2fdraft-ietf-sidr-res-certs-14.txt&f2=..%2fall-ids%2fdraft-ietf-sidr-res-certs-13.txt > ) > > Following advice from Steve Kent, the section on Trust Anchors was > revised (section 6). The change has concerned the terminology used to > described the various structures proposed in the TA model. Indeed, and these changes, from -13 -> -14, and, certainly, -14 to -15, seem quite significant, in particular those in the introductory section of 6.3. Can you provide a pointer to the discussion that led to these changes post WG LC? Also, given these changes, and in particular the sensitive nature of their content, I would suggest that the WG fully re-LC this document after this discussion is revisited on the mailing list and consensus is reached regarding this topic: Thanks! -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 10:54:18 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C0B3A698B; Wed, 3 Dec 2008 10:54:18 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3B83A698B for ; Wed, 3 Dec 2008 10:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=0.080, 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 YrD+AUx8rIoI for ; Wed, 3 Dec 2008 10:54:16 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 139513A6958 for ; Wed, 3 Dec 2008 10:54:16 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 214B736803E; Wed, 3 Dec 2008 11:54:12 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 03 Dec 2008 11:54:11 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=61884; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 11:54:10 -0700 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] Comments on sidr-res-certs-15 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff/George/Robert, Some belated comments on this draft. I hope most help contribute tot he accuracy of the document prior to publication, as many are trivial. Thanks! -danny --- Substantial Comments I already provided comments on my concern with the significant set of changes that were added post WG LC in S 6.3 and beyond in the -15 revision. I would like to see discussion of these on the WG mailing list, and perhaps even suspect some of that would be more suitable for the sidr-arch draft, rather than this draft. --- Mostly Editorial Comments Below - Boilerplate update to 4748 will be required when new revision is issued. - S 1. I believe it would be worthwhile in the beginning to define "number registry", as that term is used both frequently and rather ambiguously throughout. In the second to last graf you mention a use case regarding "the detection of potential unauthorized use of IP addresses", can you explain what this means? - S 3.2. Regarding Serial number, did you really mean "unique per Issuer", or "unique for each certificate issued"? - S 3.4. The second graf here suggests that ID.sidr-arch imposes conventions on Issuer names in resources certificates. I don't believe it does. It talks about Subject names, but not issuers names. Perhaps you can clarify for me? - S 3.7. s/current time,/current time./ - S 3.9.1. Need consistent capitalization of "basic constraints", varies within this section, as well as in other sections (e.g. 6.3.1) - S 3.9.5. s/implying at/implying that/ - S 3.9.7. s/is referenced the/is referenced in the/ - S 3.9.8. s/none must/MUST NOT/ - S 6.2. Regarding "It is suggested that implementations of Resource Certificate validation MAY halt with a validation failure if the certification path length exceeds a locally defined configuration parameter.", do you have an indication of what might be reasonable here in practice? - S 6.3. Third graf, use of "registry" is rather ambiguous again. s/must be a superset/MUST be a superset/ ? s/thought not mandated/though not mandated/ - S 6.3.1. s/fof those/of those/ - S 8. s/[RFC3779]apply/[RFC3779] apply/ _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 12:28:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47F43A696D; Wed, 3 Dec 2008 12:28:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B7B3A689C for ; Wed, 3 Dec 2008 12:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=0.078, 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 AKm57YFtx+qJ for ; Wed, 3 Dec 2008 12:28:39 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 13B083A6820 for ; Wed, 3 Dec 2008 12:28:39 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 1CA4B368040; Wed, 3 Dec 2008 13:28:35 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 03 Dec 2008 13:28:34 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=63873; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <8C455A1F-C1A2-4782-A92B-A9DD1AD77051@tcb.net> From: Danny McPherson To: Matt Lepinski In-Reply-To: <48EB6D8F.3070800@bbn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 13:28:34 -0700 References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EB6D8F.3070800@bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Oct 7, 2008, at 8:09 AM, Matt Lepinski wrote: > > 2) With regards to format, there was discussion in March in > Philidelphia which led to the addition of the max-length field. At > that time, the question was raised as to whether there should also > be a min-length field and at the time there seemed to be no operator > requirement for such a field. In particular, to justify a min-length > field one would need a use-case where a registered holder of IP > resources wishes to give an AS permission to advertise many long > prefixes, but expressly forbid the AS from advertising the aggregate > prefix. Such a use-case seems unlikely because in most cases > advertising the aggregate prefix does no harm (and indeed will be > ignored in the presence of advertisements for longer prefixes) > although I could be missing something. Matt, Catching up on old email (rereading while looking at I-D changes) One trivial comment here.. If two ASes announce the same aggregate (prefix/len) it can certainly do harm, as more specifics may be suppressed and routing would simply select the preferred AS based on AS_PATH or other selection criteria. Route hijacks that are no more specific than the legit route occur frequently, and cause considerable pain to the prefix holder. I'm not making a case for minLength, just sharing an observation. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 12:44:12 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA70028C113; Wed, 3 Dec 2008 12:44:12 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5438C3A6820 for ; Wed, 3 Dec 2008 12:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.041 X-Spam-Level: X-Spam-Status: No, score=-1.041 tagged_above=-999 required=5 tests=[AWL=0.076, 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 E+syN0RFzexP for ; Wed, 3 Dec 2008 12:44:10 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id ACFCB3A6A1F for ; Wed, 3 Dec 2008 12:44:10 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id CE3F1368040; Wed, 3 Dec 2008 13:44:06 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 03 Dec 2008 13:44:06 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=64092; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <948A55BE-05D8-4012-ADF0-5D326C94E8CE@tcb.net> From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 13:44:05 -0700 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] Comments on sidr-roa-format-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Matt/Steve/Derrick, Some comments on the ROA format draft below.. Thanks! -danny --- Substantial Comments - This document uses the term "holder" as well, could we define this in the arch draft, or elsewhere, and so that it has a common unambiguous interpretation within the context of the SIDR work? - The ROA validation text doesn't include signing Time as a consideration at all, although 2.1.6.4.3 and 2.1.6.4.4 both suggest that it explicitly specifies that it no way affects validation. Text should be added to the S 3. accommodating this. - It is normal to specify in the validation procedures whether ordering of the procedures is required or not? - Does there need to be text about UTCTime v. GeneralizedTime and their relation and employment before and after 2049 and 2050, in the respective sections? --- Editorial Comments - Abstract: s/to that one/to one/ - S 2.1.3.2.3. s/of IP address prefix/of an IP address prefix/ - S 2.1.6.4.2. Shouldn't the reference to RFC 3852 be to S 11.2 (v. S 11.1)? - S 2.1.6.4.3. s/of absence/or absence/ - S 2.1.6.4.4. The title of this section should have a space between BinarySigningTime and Attribute. s/of absence/or absence/ _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 13:39:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE6728C1C9; Wed, 3 Dec 2008 13:39:03 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A747B28C1C9 for ; Wed, 3 Dec 2008 13:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.071, 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 q5HkDKUpOa69 for ; Wed, 3 Dec 2008 13:39:02 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 02D4028C1C8 for ; Wed, 3 Dec 2008 13:39:02 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id F1B5F368040; Wed, 3 Dec 2008 14:38:57 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 03 Dec 2008 14:38:57 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=49252; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 14:38:57 -0700 References: X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Comments on sidr-res-certs-15 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > One other trivial comment here: S 3.9.7. expands SIA to "Subject Information Access", rather than "Subject Information Authority". An earlier version of the respos-struct draft did the same, but it was corrected. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 14:13:53 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE3728C1C9; Wed, 3 Dec 2008 14:13:53 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9087F3A6B97 for ; Wed, 3 Dec 2008 14:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=0.068, 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 MGH3pGJlwbfK for ; Wed, 3 Dec 2008 14:13:50 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E638E3A6B86 for ; Wed, 3 Dec 2008 14:13:50 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id F3F4D368040; Wed, 3 Dec 2008 15:13:46 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 03 Dec 2008 15:13:46 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=49324; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 15:13:45 -0700 References: X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Comments on sidr-res-certs-15 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Question about "multi-use" EEs.. The repos-struct-01 draft seems to suggest that they're "defined" in the res-certs draft: "2.1. Manifests All CA's and all EE's that have repository publication points ("multi-use" EE certificates, as defined in [I-D.ietf-sidr-res-certs])..." But the only text in the res-certs draft regarding multi-use certs is in S 7: "In the case of a "multi-use" EE certificate, the EE certificate should issued using the CURRENT CA." Does something more need to be provided to define this term here? Also, S 7. Bullet 6 (within key rollover operation) of res-certs-15: s/should issued using/should be issued using/ -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 14:33:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0DA53A67DA; Wed, 3 Dec 2008 14:33:42 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37AE23A67DA for ; Wed, 3 Dec 2008 14:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2UgBDz1AqWw for ; Wed, 3 Dec 2008 14:33:41 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 988B63A6358 for ; Wed, 3 Dec 2008 14:33:41 -0800 (PST) Received: from [10.0.1.200] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 942283C2F44; Wed, 3 Dec 2008 14:33:37 -0800 (PST) Message-Id: <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> From: David Conrad To: Geoff Huston In-Reply-To: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 14:33:36 -0800 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org [No hat] Hi, I have been avoiding raising any issues on the res-cert draft for political reasons, however I believe the draft is flawed in a non- political way in that section 6.3 makes reference to IANA acting in some capacity as a trust anchor yet the IANA Considerations section states: "[Note to IANA, to be removed prior to publication: there are no IANA considerations stated in this document.]" Either IANA is acting in some capacity as a trust anchor and as a result there ARE IANA considerations - OR - IANA is not acting in in some capacity as a trust anchor in which case the absence of IANA considerations is appropriate, but section 6.3 needs to be revised to make explicit that IANA is NOT involved in the RPKI trust hierarchy. You can't have both. Hopefully this comment will not trigger political sensitivities regarding IANA's role in the RPKI. Back under my rock. Regards, -drc _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 14:51:15 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1783A6B9D; Wed, 3 Dec 2008 14:51:15 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E043A67DA for ; Wed, 3 Dec 2008 14:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 UO9aF3r1TI0i for ; Wed, 3 Dec 2008 14:51:13 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id DC1C53A6A2D for ; Wed, 3 Dec 2008 14:50:55 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1B4C1110062; Thu, 4 Dec 2008 08:50:50 +1000 (EST) Message-Id: From: Geoff Huston To: Danny McPherson In-Reply-To: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 4 Dec 2008 09:50:48 +1100 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 04/12/2008, at 5:19 AM, Danny McPherson wrote: > > On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote: > >> WG Chair Hat OFF >> >> Since Sandy's Last Call on this document there have been a few >> changes to the document which I should note here. >> >> The first set of changes concerns the revision from -13 to -14 (http://smakd.potaroo.net/cgi-bin/htmlwdiff?f1=..%2fall-ids%2fdraft-ietf-sidr-res-certs-14.txt&f2=..%2fall-ids%2fdraft-ietf-sidr-res-certs-13.txt >> ) >> >> Following advice from Steve Kent, the section on Trust Anchors was >> revised (section 6). The change has concerned the terminology used to >> described the various structures proposed in the TA model. > > Indeed, and these changes, from -13 -> -14, and, certainly, > -14 to -15, seem quite significant, in particular those in > the introductory section of 6.3. Can you provide a pointer > to the discussion that led to these changes post WG LC? > > Also, given these changes, and in particular the sensitive > nature of their content, I would suggest that the WG fully > re-LC this document after this discussion is revisited on the > mailing list and consensus is reached regarding this topic: > > > WG Chair Hat OFF The text you refer to was provided by Steve Kent. I understand that the text was proposed on the basis that the original text did not describe a valid PKIX construct. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 15:00:13 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27B83A6B86; Wed, 3 Dec 2008 15:00:12 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80B03A6B86 for ; Wed, 3 Dec 2008 15:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=0.066, 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 u6bNJQu21EZa for ; Wed, 3 Dec 2008 15:00:11 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 08D793A6A2D for ; Wed, 3 Dec 2008 15:00:11 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id F27AE368040; Wed, 3 Dec 2008 16:00:06 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 03 Dec 2008 16:00:06 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=49579; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <31BBA2D9-73D0-4C7C-9F94-2B0A0AB08721@tcb.net> From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 16:00:05 -0700 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] Comments on sidr-repos-struct-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff/Robert/George, Some comments below on the sidr-repos-struct-01 draft, mostly trivial. --- Editorial Comments - S 2.1. I'm not sure exactly which point the second graf in this section is intending to make. Some rewording, in particular around "RPKI is "complete set"," is in order. - S 2.2. s/continue of use a/continue the use of a/ s/pooint/point/ s/Whn/When/ In the CRL graf the text provides: "The scope of a CRL in the RPKI is all objects issued by a CA, implying that publication of successive instances of a CA's CRL may overwrite previous instances of CRLs signed by the same CA's private key in the publication repository." Regarding this text, is there an instance where it would not overwrite previous instances of CRLs? "applying the algorithm described above" in the Signed Objects text seems a bit overly terse given that the prevous three items all elaborated on the point. At least adding "for CRL object names" would be consistent. - S 2.3. s/the case of a EE's/the case of an EE's/ - S 3. s/certifificate/certificate/ - S 5. I'm wondering if the last graf there should provide any guidance on what might be a reasonable chain length? We left this [perhaps] sufficiently vague other I-Ds as well. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 15:10:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACB43A6A2D; Wed, 3 Dec 2008 15:10:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AE803A6A2D for ; Wed, 3 Dec 2008 15:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=0.065, 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 ngUp+9JjwfnI for ; Wed, 3 Dec 2008 15:10:24 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C1FC33A67DA for ; Wed, 3 Dec 2008 15:10:24 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id DC9FF368040; Wed, 3 Dec 2008 16:10:20 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 03 Dec 2008 16:10:20 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=49766; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: David Conrad In-Reply-To: <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 3 Dec 2008 16:10:19 -0700 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 3, 2008, at 3:33 PM, David Conrad wrote: > [No hat] > > Hi, > > I have been avoiding raising any issues on the res-cert draft for > political reasons, however I believe the draft is flawed in a non- > political way in that section 6.3 makes reference to IANA acting in > some capacity as a trust anchor yet the IANA Considerations section > states: > > "[Note to IANA, to be removed prior to publication: there are no > IANA considerations stated in this document.]" > > Either IANA is acting in some capacity as a trust anchor and as a > result there ARE IANA considerations > > - OR - > > IANA is not acting in in some capacity as a trust anchor in which > case the absence of IANA considerations is appropriate, but section > 6.3 needs to be revised to make explicit that IANA is NOT involved > in the RPKI trust hierarchy. > > You can't have both. > > Hopefully this comment will not trigger political sensitivities > regarding IANA's role in the RPKI. FWIW, I raised the same concern yesterday on the list via comments made on the sidr-arch draft: --- IANA Considerations surely should include some guidance to IANA about investigation and preparation for anything that might be required WRT serving as a TA. Also, for legacy space, etc.. In general, I like to see more description and discussion of the TA model here, as others (e.g., Roque on 11/17/08) and previous discussions seem to support as well. --- -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 21:33:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2436728C104; Wed, 3 Dec 2008 21:33:27 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C8F28C0F2 for ; Wed, 3 Dec 2008 21:33:26 -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 U2RZNMKleR-B for ; Wed, 3 Dec 2008 21:33:24 -0800 (PST) Received: from midgard.seastrom.com (midgard.seastrom.com [IPv6:2610:178:1:1:203:47ff:fefd:df3e]) by core3.amsl.com (Postfix) with ESMTP id 405F128C0E5 for ; Wed, 3 Dec 2008 21:33:24 -0800 (PST) Received: from c-69-255-3-202.hsd1.va.comcast.net ([69.255.3.202] helo=[192.168.3.76]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1L86pv-0004Y5-Tj; Thu, 04 Dec 2008 00:33:16 -0500 Message-Id: From: John Curran To: David Conrad In-Reply-To: <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 4 Dec 2008 00:33:14 -0500 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs (IANA Considerations section) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 3, 2008, at 5:33 PM, David Conrad wrote: > ... > Either IANA is acting in some capacity as a trust anchor and as a > result there ARE IANA considerations > - OR - > IANA is not acting in in some capacity as a trust anchor in which > case the absence of IANA considerations is appropriate, but section > 6.3 needs to be revised to make explicit that IANA is NOT involved > in the RPKI trust hierarchy. David - As I read the draft, the IANA's role as a trust anchor is no different than any of the RIR's (i.e. each acting as their own trust anchor for their own RPKI hierarchy): S 6.3: "This observation motivates a two-tier trust anchor model for the RPKI. The top tier trust anchor for each RIR (and IANA) will be a self-signed certificate that contains no resource extensions. ... " Setting aside the relative merits of having each RIR and IANA using a separate RPKI hierarchy, it's somewhat understandable that there is no IANA Considerations section, since there is no new requirements for namespace management being put or changed on the IANA, per BCP26. As written, the IANA might, at its discretion, decide to make use of res certs, but that's not mandatory for this document to be useful. While there is no new namespace of identifiers to be managed, I think that it might be valuable to document the communities expectations for the IANA in an "IANA Considerations" section. Per the current draft, this wouldn't necessary mention any IANA role as a trust anchor but instead simply be note to the effect that "This document defines a standard profile for certificates supporting validation of assertions of right-to-use for Internet numbering resources, and that the IANA should provide support for such assertions for the Internet numbering resources which it manages." /John _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 3 23:08:15 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090373A67DD; Wed, 3 Dec 2008 23:08:15 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14473A67DD for ; Wed, 3 Dec 2008 23: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 xelN7-DcLoJR for ; Wed, 3 Dec 2008 23:08:13 -0800 (PST) Received: from midgard.seastrom.com (midgard.seastrom.com [IPv6:2610:178:1:1:203:47ff:fefd:df3e]) by core3.amsl.com (Postfix) with ESMTP id 046A53A67B6 for ; Wed, 3 Dec 2008 23:08:13 -0800 (PST) Received: from c-69-255-3-202.hsd1.va.comcast.net ([69.255.3.202] helo=[192.168.3.76]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1L88Jj-0004hE-6E; Thu, 04 Dec 2008 02:08:07 -0500 Message-Id: <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> From: John Curran To: Geoff Huston In-Reply-To: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 4 Dec 2008 02:08:06 -0500 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote: > > Since Sandy's Last Call on this document there have been a few > changes to the document which I should note here. > ... > Following advice from Steve Kent, the section on Trust Anchors was > revised (section 6). The change has concerned the terminology used to > described the various structures proposed in the TA model. The clarifications and additions in section 6.3 are a major step forward in understanding the intent of the draft with respect to Trust Anchors. With the improved understanding, there are some questions raised as to how exactly the full set of assertions should be obtained for any given Internet numbering resource. The draft uses the term "default trust anchor collection" in section 6.3 ("Relying Parties can assemble the default trust anchor collection by using the registry TA certificate for each nominated trust anchor...") but doesn't specify how to navigate the multiple RPKI hierarchies that occur only in the presence of a "trust anchor collection", nor does it provide guidance on to perform overall interpretation of multiple valid assertions which might occur in presence of a "trust anchor collection". The semantic logic regarding how to handle sets of overlapping and contradictory assertions is essential for consistent interpretation of the certificates contained in the full set of RIR/IANA RPKI hierarchies. Note that RFC 3779 not only doesn't provide any assistance in resolving this situation, it specifically sets rules to prevent such an situation from occurring: "Sections 2 and 3 specify several rules about the encoding of the extensions defined in this specification that MUST be followed. These encoding rules serve the following purposes. First, they result in a unique encoding of the extension's value; two instances of an extension can be compared for equality octet-by-octet. Second, they achieve the minimal size encoding of the information. Third, they allow relying parties to use one-pass algorithms when performing certification path validation; in particular, the relying parties do not need to sort the information, or to implement extra code in the subset checking algorithms to handle several boundary cases (adjacent, overlapping, or subsumed ranges)." In its present form, the draft departs from the single certificate hierarchy envisioned in RFC 3779 ("IP address space is currently managed by a hierarchy nominally rooted at IANA, but managed by the RIRs"), and thus makes numerous combinations of conflicting assertions possible for the same numbering resource. Without unstated information on how to obtain and correctly interpret such combinations, the ambiguities that result prevent using the proposed model with multiple RPKI hierarchies to ascertain information for a given numbering resource with any degree of certainty. As this is *the* utility value of an RPKI system for many in the community, I'd recommend we either correct the model or supply the missing information which will allow for deterministic use of the total RPKI infrastructure. /John _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Dec 4 09:38:56 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E143A6A8B; Thu, 4 Dec 2008 09:38:55 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A263A6A8B for ; Thu, 4 Dec 2008 09:38:55 -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 qWdZEb0-azIr for ; Thu, 4 Dec 2008 09:38:54 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 63B4A3A68ED for ; Thu, 4 Dec 2008 09:38:54 -0800 (PST) Received: from wlan39-077.mdr.icann.org (wlan39-077.mdr.icann.org [192.0.39.77]) by virtualized.org (Postfix) with ESMTP id 77F823C3EBA; Thu, 4 Dec 2008 09:38:49 -0800 (PST) Message-Id: <0BF7E2EA-769D-46F4-B0B4-469407BDDB7E@virtualized.org> From: David Conrad To: John Curran In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 4 Dec 2008 09:38:48 -0800 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs (IANA Considerations section) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org John, On Dec 3, 2008, at 9:33 PM, John Curran wrote: > As I read the draft, the IANA's role as a trust anchor is no different > than any of the RIR's (i.e. each acting as their own trust anchor for > their own RPKI hierarchy): Yes, that is my interpretation of the draft as well. > As written, the IANA might, at its discretion, decide to make use of > res certs, but that's not mandatory for this document to be useful. I don't want to go too far afield on a meta-point, but in the Brave New Internet in which we find ourselves, IANA does not do things at its discretion. IANA implements decisions others make (presumably via some community-based consensus) through IANA Consideration sections or by specific direction of the IAB, IESG, etc. The alternative would be "top down" decision making (oh, the horror) and would require IANA staff to have a level of expertise in a wide array of topic areas that is most likely not reasonable to assume. With respect to the draft, if SIDR is indicating IANA needs to maintain an RPKI trust anchor (regardless of what it is covering), I believe an IANA considerations section needs to state IANA is directed to do this. I understand that some folks are working on appropriate wording. Regards, -drc _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Dec 4 22:50:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194C03A68B7; Thu, 4 Dec 2008 22:50:27 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524703A68B7 for ; Thu, 4 Dec 2008 22:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 XJorLHFK+81s for ; Thu, 4 Dec 2008 22:50:24 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id A285C3A67FB for ; Thu, 4 Dec 2008 22:50:22 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C361A110067; Fri, 5 Dec 2008 16:50:16 +1000 (EST) Message-Id: From: Geoff Huston To: David Conrad In-Reply-To: <0BF7E2EA-769D-46F4-B0B4-469407BDDB7E@virtualized.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 17:50:15 +1100 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> <0BF7E2EA-769D-46F4-B0B4-469407BDDB7E@virtualized.org> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs (IANA Considerations section) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 05/12/2008, at 4:38 AM, David Conrad wrote: > John, > > On Dec 3, 2008, at 9:33 PM, John Curran wrote: >> As I read the draft, the IANA's role as a trust anchor is no >> different >> than any of the RIR's (i.e. each acting as their own trust anchor for >> their own RPKI hierarchy): > > Yes, that is my interpretation of the draft as well. > >> As written, the IANA might, at its discretion, decide to make use of >> res certs, but that's not mandatory for this document to be useful. > > I don't want to go too far afield on a meta-point, but in the Brave > New Internet in which we find ourselves, IANA does not do things at > its discretion. IANA implements decisions others make (presumably > via some community-based consensus) through IANA Consideration > sections or by specific direction of the IAB, IESG, etc. The > alternative would be "top down" decision making (oh, the horror) and > would require IANA staff to have a level of expertise in a wide > array of topic areas that is most likely not reasonable to assume. > > With respect to the draft, if SIDR is indicating IANA needs to > maintain an RPKI trust anchor (regardless of what it is covering), I > believe an IANA considerations section needs to state IANA is > directed to do this. I understand that some folks are working on > appropriate wording. WG CHair Hat Off From time to time the IETF heads into areas where its role intersects with the roles of other bodies, and its ability to direct the IANA to do, or not do, certain things has some relationship with the roles of these other bodies as well. In this case the draft's authors, namely myself, George Michaelson and Rob Loomans, have been made aware of some degree of intersection of interests between the RIRs and the IANA in terms of the roles of various bodies in terms of the publication of putative TA material that may be used by relying parties. The draft deliberately does not prescribe any particular solution over and above any other, but proposes a way in which the RIRs and IANA can publish putative TA material in a manner that is useful to relying parties, should they choose to uses this material as their nominated Trust Anchors. i.e. to state this clearly using wording comparable to David Conrad's note, the draft does not provide any particular direction to IANA, and while some folk may be off working on some appropriate wording to suggest to add to the draft that does provide such direction, other folk, including myself as a co-author of the document, are currently of the view that the current wording is entirely appropriate for the circumstance that we find ourselves in. No doubt the politics of the formation of rough consensus gathering in the IETF will sort all this out in the fullness of time. My personal opinion follows: The draft is not advocating that IANA does, or does not do any particular action with respect to the publication of TA material. In looking at the abundance of heat and absence of light that the topic of IANA signing of the root zone of the DNS has managed to generate over the years so far, and with the end still not yet in sight, and with the various statements of vague equivocation being made by many bodies, including that of the IAB (!), its all to easy to see that this general topic of the assumption of a "root" authority is one that is not simple, and that this topic when related to the address space may well bring out many more interests and many more perspectives than are evident in the current set of interested parties in the SIDR discussion. It would've been a tragedy, and perhaps a fatal one, if the DNSSEC standards had been contingent on the adoption of a single nominated process for iANA to sign the root zone of the DNS using IANA- generated keys. Obviously the DNSSEC documents would not have been published as RFCs yet, and the DNSSEC specifications would still be sitting in some strange half life as quasi-standards awaiting the termination of a process that is both overly political and potentially non-terminating! The signal that would give to DNS users as to the viability of DNSSEC would be less than a wholesome endorsement. I personally see no merit whatsoever in consigning the SIDR work into a similar indeterminate twilight awaiting the termination of a political process that really has no clear outcome once the matter really gets the level of heat applied to it over the expression of national political interests into the Internet's infrastructure. Once the issue of authority over the address space is raised, then in the same fashion as the DNS where the matter has headed off into the realm of international politics, I personally suspect that we would see a statement of overarching interest being made by the NTIA within the US Government, citing some continuity of USG address management dating back through to the ARPA programs, and I also suspect that we'd see strong, perhaps vehement, statements of opposition coming from other national interests who would take the view, with some rational foundation, that one government has no right to hold such a privileged position with respect to an international public network while all other governments and treaty organizations are shut out of the process completely. The alignment of interests that are vehemently opposed to the USG exercising such a special role, and in particular given the rather unique ability to undertake a revocation apply a new level of political concern to the picture. It may well be that this particular looming political imbroglio over the authority of the address space is unavoidable, and that no matter what the IETF does or does not do, we are going to have to ensure the political stoush. Or, just maybe, we in the IETF can attempt to avoid the issue to some extent and insist that beauty, or in this case the choice of Trust Anchors, is in the eye of the beholder, or in this case is in the eye of relying parties. Maybe its better for the IETF to avoid being prescriptive as to where or how putative trust should be asserted as a part of the IETF's technology standard, and allow the technology to progress and be published as an Internet Standard without being stalled up on an issue which is not readily tractable given the breadth and diversity of interests. But some folk are perhaps more interested in politicizing the IETF and its outcomes, and forcing the IETF to take a stance that may well be interpreted as an outrageously partisan stance from a broader international political perspective. I _personally_ would view that development with some sorrow, as I suspect that we've seen too much of the IETF being branded as the compliant lapdog of a single government's interests for the past two decades, and as the IETF we've strived to get beyond all that and concentrate on developing and standardizing technology to the best of our collective abilities in the same fashion as, or hopefully better than, any other international standards organization. The way we've done that is to avoid taking sides arbitrarily in political debates and attempting to look at situations as objectively and as rationally as possible and perform a scoped task that relates to the development of technology. A little more of that form of rational process would, I believe, assist the SIDR WG to make the appropriate call here as well. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 5 00:28:18 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6FC28C0E7; Fri, 5 Dec 2008 00:28:18 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72893A6B14 for ; Fri, 5 Dec 2008 00:28:17 -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 B6+a6Tfaq1Sa for ; Fri, 5 Dec 2008 00:28:16 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id BF71228C0E7 for ; Fri, 5 Dec 2008 00:28:16 -0800 (PST) Received: from [192.168.1.109] (pool-71-105-66-99.lsanca.dsl-w.verizon.net [71.105.66.99]) by virtualized.org (Postfix) with ESMTP id 535853C4EFA; Fri, 5 Dec 2008 00:28:06 -0800 (PST) Message-Id: <4E673D88-86F1-4D16-B317-AC416A6382F7@virtualized.org> From: David Conrad To: Geoff Huston In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 00:28:04 -0800 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> <0BF7E2EA-769D-46F4-B0B4-469407BDDB7E@virtualized.org> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs (IANA Considerations section) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff, [No hat. Really. Personal opinion only] On Dec 4, 2008, at 10:50 PM, Geoff Huston wrote: > From time to time the IETF heads into areas where its role > intersects with the roles of other bodies, Yep. Like (say) IPv6 and IPSEC requirements and the interaction with national crypto laws where the decision was made to choose the technically correct solution in the face of concerns that national laws would make deployment more difficult or even impossible (I remember a particularly interesting plenary in Danbury where that topic was 'discussed')... > The draft is not advocating that IANA does, or does not do any > particular action with respect to the publication of TA material. [many, many words elided] > A little more of that form of rational process would, I believe, > assist the SIDR WG to make the appropriate call here as well. This may come as a surprise, but I do not necessarily disagree with what you have said. Because of personal experience, I am probably more aware of the political ramifications of single root issues than most here and as a result can see arguments both ways as to appropriate directions to take regarding trust anchor(s). However, I am unaware of any public discussion in which those trust anchor issues have been broached much less addressed. In the case of DNSSEC, there was little, if any, discussion about the operational realities of attempting to deploy DNSSEC including trust anchor issues and IANA's role. As a (arguably) direct result, we're now 12 years into deployment and have gotten minimal traction. It would be tragic to repeat that particularly sad history with RPKI. Presumably, the goal here is to get something that can actually be deployed... I would gently suggest that attempting to ignore the politically sensitive issues (whether they be national politics or ICANN/RIR politics) by not addressing the underlying cause of those issues is leading us down the exact same potentially non-terminal path you express concerns about (particularly when the NRO representative at the ICANN meeting waves a bouquet of red flags at the assembled governance officials during the plenary and when it becomes a topic of discussion and not necessarily in a good way (I'm told) at the IGF). The ant mound has already been stirred. Pretending you're not covered in honey is unlikely to have a positive outcome. If you wish to argue that the treatment of trust anchors should not be in the res-certs draft, that's fine as long as you follow it up with 'it should be in X' (and you define 'X' :-)). I believe it important that there be an open discussion about the pros and cons of the various trust anchor models and any recommendation be made in a transparent manner. I reiterate my belief that if IANA is going to be a participant in a trust anchor or anchors, it needs to be called out explicitly in the IANA Considerations section, but that's merely my opinion (like the entirety of this note). FWIW. Regards, -drc _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 5 02:31:17 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1695628C156; Fri, 5 Dec 2008 02:31:17 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461483A6BE0 for ; Fri, 5 Dec 2008 02:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 lQZ8qp3nIa83 for ; Fri, 5 Dec 2008 02:31:15 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 00AC23A6BEE for ; Fri, 5 Dec 2008 02:31:14 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 10C79110061; Fri, 5 Dec 2008 20:31:03 +1000 (EST) Message-Id: <3E422472-A42D-435C-8049-79250EB0111B@apnic.net> From: Geoff Huston To: David Conrad In-Reply-To: <4E673D88-86F1-4D16-B317-AC416A6382F7@virtualized.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 21:31:00 +1100 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> <0BF7E2EA-769D-46F4-B0B4-469407BDDB7E@virtualized.org> <4E673D88-86F1-4D16-B317-AC416A6382F7@virtualized.org> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs (IANA Considerations section) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat OFF On 05/12/2008, at 7:28 PM, David Conrad wrote: > Geoff, > > [No hat. Really. Personal opinion only] > > On Dec 4, 2008, at 10:50 PM, Geoff Huston wrote: >> From time to time the IETF heads into areas where its role >> intersects with the roles of other bodies, > > Yep. Like (say) IPv6 and IPSEC requirements and the interaction > with national crypto laws where the decision was made to choose the > technically correct solution in the face of concerns that national > laws would make deployment more difficult or even impossible (I > remember a particularly interesting plenary in Danbury where that > topic was 'discussed')... > >> The draft is not advocating that IANA does, or does not do any >> particular action with respect to the publication of TA material. > [many, many words elided] ahh, but they were many fine words! :-) > >> A little more of that form of rational process would, I believe, >> assist the SIDR WG to make the appropriate call here as well. > > This may come as a surprise, but I do not necessarily disagree with > what you have said. Because of personal experience, I am probably > more aware of the political ramifications of single root issues than > most here and as a result can see arguments both ways as to > appropriate directions to take regarding trust anchor(s). > > However, I am unaware of any public discussion in which those trust > anchor issues have been broached much less addressed. In the case > of DNSSEC, there was little, if any, discussion about the > operational realities of attempting to deploy DNSSEC including trust > anchor issues and IANA's role. As a (arguably) direct result, we're > now 12 years into deployment and have gotten minimal traction. It > would be tragic to repeat that particularly sad history with RPKI. > Presumably, the goal here is to get something that can actually be > deployed... There are of course many possible reasons for this rather sad state of affairs in DNSSEC, but I must admit that I find it rather difficult to believe that a lack of an IETF debate on this topic would be at the heart of this particular saga (DNSSEC). > > > I would gently suggest that attempting to ignore the politically > sensitive issues (whether they be national politics or ICANN/RIR > politics) by not addressing the underlying cause of those issues is > leading us down the exact same potentially non-terminal path you > express concerns about (particularly when the NRO representative at > the ICANN meeting waves a bouquet of red flags at the assembled > governance officials during the plenary and when it becomes a topic > of discussion and not necessarily in a good way (I'm told) at the > IGF). The ant mound has already been stirred. Pretending you're > not covered in honey is unlikely to have a positive outcome. I'm sorry, but I'm completely unaware of this circumstance you are reporting here. However, I suppose that it is illustrative of the state of affairs we live in these days where these matters enjoy such political sensitivity. > > > If you wish to argue that the treatment of trust anchors should not > be in the res-certs draft, that's fine as long as you follow it up > with 'it should be in X' (and you define 'X' :-)). I believe it > important that there be an open discussion about the pros and cons > of the various trust anchor models and any recommendation be made in > a transparent manner. I reiterate my belief that if IANA is going to > be a participant in a trust anchor or anchors, it needs to be called > out explicitly in the IANA Considerations section, but that's merely > my opinion (like the entirety of this note). > I am arguing that the res-cert draft is appropriately phrased in making no particular call on IANA to represent itself as the "root" TA fpr the RPKI, and arguing that the draft is appropriate in that it paints the picture that the selection of TA material is a matter for relying parties to determine and simply describes how TA material can be packaged in a way that creates stable TA material. i.e. I am not heading down the path of saying where it should be - I am limiting myself to a "not here please" statement. My related observation is pretty much the same as yours - these are thorny matters with many interests and perspectives. I for one don't see this matter being resolved by a simple SIDR WG discussion - oh no - thats just the opening statements in something that I fear will carry on, like DNSSEC, for a decade or longer. So maybe I should just reconcile myself to the fact that progress on these drafts is not going to be glacial - its going to be geological, and I should spare my fingers the trouble of typing too much too early, becuase it seems that this particualr set of issues is going to be hanging around for decades, like this complete set of SIDR WG drafts. Oh what fun. not. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 5 06:11:58 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636843A6C71; Fri, 5 Dec 2008 06:11:58 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD223A6C71 for ; Fri, 5 Dec 2008 06:11:57 -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 c3qeM-g3ioRg for ; Fri, 5 Dec 2008 06:11:56 -0800 (PST) Received: from midgard.seastrom.com (midgard.seastrom.com [IPv6:2610:178:1:1:203:47ff:fefd:df3e]) by core3.amsl.com (Postfix) with ESMTP id 7EDD53A6C70 for ; Fri, 5 Dec 2008 06:11:56 -0800 (PST) Received: from c-69-255-3-202.hsd1.va.comcast.net ([69.255.3.202] helo=[192.168.3.76]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1L8bPI-000Ac0-Ff; Fri, 05 Dec 2008 09:11:49 -0500 Message-Id: From: John Curran To: Geoff Huston In-Reply-To: <3E422472-A42D-435C-8049-79250EB0111B@apnic.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 09:11:47 -0500 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> <0BF7E2EA-769D-46F4-B0B4-469407BDDB7E@virtualized.org> <4E673D88-86F1-4D16-B317-AC416A6382F7@virtualized.org> <3E422472-A42D-435C-8049-79250EB0111B@apnic.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs (IANA Considerations section) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 5, 2008, at 5:31 AM, Geoff Huston wrote: > ... > I am arguing that the res-cert draft is appropriately phrased in > making no particular call on IANA to represent itself as the "root" > TA fpr the RPKI, and arguing that the draft is appropriate in that > it paints the picture that the selection of TA material is a matter > for relying parties to determine and simply describes how TA > material can be packaged in a way that creates stable TA material. > i.e. I am not heading down the path of saying where it should be - I > am limiting myself to a "not here please" statement. Geoff - That indirection would be a wonderful, elegant solution to the situation, but unfortunately in its present form it creates much larger problem than it solves. In particular, we need to keep in mind that the usefulness of the RPKI system for most parties is going to be predicated upon providing a well-understood, deterministic mechanism for verification of assertions across the entire Internet numbering resource space. The ability to perform such validation is well-defined in a world with a single PKI hierarchy covering the resource space, and (with all due respect to drc :-) it would be understandable if an IETF WG decided omit specification of the TA entity in the IANA Considerations section due to the inherently political nature of the question, and with the hope that the Trust Anchor determination for such a system would indeed be addressed someplace else. While this would fail to allow for immediate implementation of the full desired functionality, advancing a res-cert draft without the TA specified would still allow for technical validation of the solution and insertion of the appropriate TA once that matter had been settled "elsewhere". However, the res-cert-15 draft sidesteps this issue instead by introduction of the alternative of having a "trust anchor collection"; i.e. multiple RPKI certificate hierarchies to cover the entire Internet numbering resource space. This proposal of multiple PKI hierarchies for a single resource space is completely new technical construct which lacks definition of many desired operations such as the process for overall assertion validation, and process for transfer of resources between RPKI hierarchies. As a result, the IETF is being encouraged to advance an incomplete *technical* solution. Even if a well-understood and accepted set of "trust anchor collection" material is determined elsewhere sometime in the future, it's inclusion still leaves unaddressed how a third-party makes use of the constellations of RPKI certificate hierarchies to come up with a generally understood consistent answer in validation of any given RPKI assertion, nor would it address how routine PKI functions should be implemented between the multiple RPKI hierarchies that have been introduced as the "solution" to the TA specification problem. It's not the omission of the "root" TA for RPKI which is the issue, it's the introduction of the ill-defined technical construct of a "trust anchor constellation" which (IMHO) makes the current res-cert draft fundamentally flawed. > My related observation is pretty much the same as yours - these are > thorny matters with many interests and perspectives. I for one don't > see this matter being resolved by a simple SIDR WG discussion - oh > no - thats just the opening statements in something that I fear will > carry on, like DNSSEC, for a decade or longer. So maybe I should > just reconcile myself to the fact that progress on these drafts is > not going to be glacial - its going to be geological, and I should > spare my fingers the trouble of typing too much too early, becuase > it seems that this particualr set of issues is going to be hanging > around for decades, like this complete set of SIDR WG drafts. Oh > what fun. not. The set of changes getting from res-cert-13 to res-cert-15 introduces technical ambiguity as noted above, and it seems quite appropriate that incomplete specifications move at glacial pace, if at all. /John _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 5 06:40:19 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928F33A6C64; Fri, 5 Dec 2008 06:40:19 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4136D3A6C6E for ; Fri, 5 Dec 2008 06:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bc6olL-hZlv for ; Fri, 5 Dec 2008 06:40:14 -0800 (PST) Received: from davinci.fing.edu.uy (davinci.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id 9F0423A6AC8 for ; Fri, 5 Dec 2008 06:40:12 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (85-7-200.lacnic.net.uy [200.7.85.33] (may be forged)) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id mB5Ee1K6022451; Fri, 5 Dec 2008 12:40:02 -0200 (UYST) Message-Id: From: Roque Gagliano To: Danny McPherson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 5 Dec 2008 12:40:01 -0200 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <9B506FA8-F17B-441B-A4B9-90270450D968@virtualized.org> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Fri, 05 Dec 2008 12:40:03 -0200 (UYST) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1994075986==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1994075986== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-124-1072698295" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-124-1072698295 Content-Type: multipart/alternative; boundary=Apple-Mail-123-1072698213 --Apple-Mail-123-1072698213 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > > In general, I like to see more description and discussion of the > TA model here, as others (e.g., Roque on 11/17/08) and previous > discussions seem to support as well. Hi Danny, I want to clarified that it was my understanding before the meeting that TA material information was going to be in the version 04 arch document (that was the issue that I raised in the 11/17 email), however during the IETF73 version 15 of the cert-profile came out and included that information. As we discussed at the SIDR meeting, we should avoid having information duplicated in different documents and as arch document should not have formating information, the cert profile doc should then be the correct place to have this information. So, I do not have an open point on this issue. Regards, Roque > --- > > -danny > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-123-1072698213 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

In general, I like to see more description and = discussion of the
TA model here, as others (e.g., Roque on 11/17/08) = and previous
discussions seem to support as = well.

Hi = Danny,

I want to clarified that it was my = understanding before the meeting that TA material information was going = to be in the version 04 arch document (that was the issue that I raised = in the 11/17 email), however during the IETF73 version 15 of the = cert-profile came out and included that = information.

As we discussed at the SIDR = meeting, we should avoid having information duplicated in different = documents and as arch document should not have formating information, = the cert profile doc should then be the correct place to have this = information.

So, I do not have an open point on = this = issue.

Regards,
Roque






---

-danny
__________________________________= _____________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

= --Apple-Mail-123-1072698213-- --Apple-Mail-124-1072698295 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkk5PUEACgkQnk+WSgHpbO61JwCeMU9xdmXI9VjCHvfmvibODmDf O9IAnA7rVP/iPNgSIevfh9xzC/cOxiYH =ZWRh -----END PGP SIGNATURE----- --Apple-Mail-124-1072698295-- --===============1994075986== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1994075986==-- From sidr-bounces@ietf.org Mon Dec 8 13:37:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E953A69AC; Mon, 8 Dec 2008 13:37:03 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE0823A69AC for ; Mon, 8 Dec 2008 13:37:01 -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 ctBbPsJJm5PU for ; Mon, 8 Dec 2008 13:37:01 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2BFE23A6978 for ; Mon, 8 Dec 2008 13:37:01 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.173.171]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L9nmf-0000EY-Br; Mon, 08 Dec 2008 16:36:53 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 8 Dec 2008 14:44:46 -0500 To: sidr@ietf.org From: Stephen Kent Subject: [sidr] a proposed syntax change to the format of trust anchors X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org The current res-cert profile defines a format for trust anchors based on self-signed certs (either in isolation or embedded in a CMS signed object). There is some work ongoing in the PKIX WG addressing trust anchor management. Much of this work is not directly applicable to the SIDR context, as the PKIX work is initially focusing on push-based management of TAs, whereas the SIDR model is pull-based. However, we have tentative agreement on a base format for trust anchors, and that format could be used in the SIDR context, with only a very minor change to our current syntax. Specifically, the base format allows for a SEQUENE of self-signed certs (or other representations about which we do not care) instead of a single self-signed cert. If there are no objections, I'd like to ask Geoff to change the TA text in his document to adopt this format. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 8 13:37:06 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B183A6A9C; Mon, 8 Dec 2008 13:37:06 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EF13A6A85 for ; Mon, 8 Dec 2008 13:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4aHlWq2pMWz for ; Mon, 8 Dec 2008 13:37:05 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4FDDD3A6A82 for ; Mon, 8 Dec 2008 13:37:05 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.173.171]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L9nmg-0000EY-Aw; Mon, 08 Dec 2008 16:36:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> Date: Mon, 8 Dec 2008 14:56:35 -0500 To: John Curran From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 2:08 AM -0500 12/4/08, John Curran wrote: >On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote: >> >>Since Sandy's Last Call on this document there have been a few >>changes to the document which I should note here. >>... >>Following advice from Steve Kent, the section on Trust Anchors was >>revised (section 6). The change has concerned the terminology used to >>described the various structures proposed in the TA model. > >The clarifications and additions in section 6.3 are a major >step forward in understanding the intent of the draft with >respect to Trust Anchors. With the improved understanding, >there are some questions raised as to how exactly the full >set of assertions should be obtained for any given Internet >numbering resource. > >The draft uses the term "default trust anchor collection" in >section 6.3 ("Relying Parties can assemble the default trust >anchor collection by using the registry TA certificate for each >nominated trust anchor...") but doesn't specify how to navigate >the multiple RPKI hierarchies that occur only in the presence >of a "trust anchor collection", nor does it provide guidance >on to perform overall interpretation of multiple valid assertions >which might occur in presence of a "trust anchor collection". > >The semantic logic regarding how to handle sets of overlapping >and contradictory assertions is essential for consistent >interpretation of the certificates contained in the full set >of RIR/IANA RPKI hierarchies. Note that RFC 3779 not only >doesn't provide any assistance in resolving this situation, >it specifically sets rules to prevent such an situation from >occurring: >"Sections 2 and 3 specify several rules about the encoding of the >extensions defined in this specification that MUST be followed. >These encoding rules serve the following purposes. First, they >result in a unique encoding of the extension's value; two instances >of an extension can be compared for equality octet-by-octet. >Second, they achieve the minimal size encoding of the information. >Third, they allow relying parties to use one-pass algorithms when >performing certification path validation; in particular, the relying >parties do not need to sort the information, or to implement extra >code in the subset checking algorithms to handle several boundary >cases (adjacent, overlapping, or subsumed ranges)." >In its present form, the draft departs from the single certificate >hierarchy envisioned in RFC 3779 ("IP address space is currently >managed by a hierarchy nominally rooted at IANA, but managed by >the RIRs"), and thus makes numerous combinations of conflicting >assertions possible for the same numbering resource. Without >unstated information on how to obtain and correctly interpret >such combinations, the ambiguities that result prevent using >the proposed model with multiple RPKI hierarchies to ascertain >information for a given numbering resource with any degree of >certainty. As this is *the* utility value of an RPKI system >for many in the community, I'd recommend we either correct the >model or supply the missing information which will allow for >deterministic use of the total RPKI infrastructure. > >/John John, I'm not sure what you mean by "multiple valid assertions." If you mean multiple ROAs that identify different AS'es, then that is an allowed outcome, as I believe Randy has separately noted. If the ROAs all can be validated, then they are all equally "good" in the eyes of the RPKI model. This is true whether we have one TA or multiple TAs. It think the point to which you may be alluding is that if we have the five RIRs and IANA as TAs, then a mismatch between IANA's allocation database and the database of any RIR, or between the databases of any RIRs, will not automatically be detected by the RFC 3779 path validation mechanism. That observation is correct, but there's more ... I once proposed developing software to detect conflicting allocations (sub-allocations). The proposed was shot down by folks who argued that transfer of address space among users would cause too many false positives to make detection mechanisms worthwhile. Thus, even if we were to adopt a model where IANA is the only default TA, lower tiers in the nominal hierarchy can still make mistakes that result in conflicts. The limitation imposed by the 3779 path validation criteria is that such errors are limited to the set of resources held by the CA in question. So, if we adopt a model with IANA as the only root, we do reduce the range of errors that can result in conflicting allocations, but we do not prevent all such (potential) conflicts. I can think of ways to help relying parties to detect possible IANA/RIR and RIR/RIR allocation conflicts in a model where both RIRs and IANA are TAs, but, as noted above, we have to remember that this will not deal with all such conflicts. Finallly, we have to remember that, ultimately, each RP gets to make its own TA choices. We are offering a default (or putative) set of TAs as part of the architecture, but we cannot mandate which entities each relying party will select. Also, ISPs that use RFC 1918 addresses and choose to make use of the RPKI, they will need to (locally) override the public address space hierarchy anyway. Steve P.S. Irrespective of my analysis above, yes, I do prefer a singly-rooted PKI, with IANA as the only TA, but I can live with a set of TAs so long as I can count them on my fingers, and they all are authoritative for the resources in question :-). _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 8 13:43:00 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A1E3A6A19; Mon, 8 Dec 2008 13:43:00 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4FA3A6975 for ; Mon, 8 Dec 2008 13:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 pW7nUMSor5CZ for ; Mon, 8 Dec 2008 13:42:58 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id F3A313A6A19 for ; Mon, 8 Dec 2008 13:42:57 -0800 (PST) Received: from dhcp20.potaroo.net (dhcp20.potaroo.net [203.10.60.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 48FA9110064; Tue, 9 Dec 2008 07:42:51 +1000 (EST) Message-Id: <8F2D07BA-1736-4970-A5D1-316FABF05C65@apnic.net> From: Geoff Huston To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 08:42:50 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] a proposed syntax change to the format of trust anchors X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 09/12/2008, at 6:44 AM, Stephen Kent wrote: > The current res-cert profile defines a format for trust anchors > based on self-signed certs (either in isolation or embedded in a CMS > signed object). > > There is some work ongoing in the PKIX WG addressing trust anchor > management. Much of this work is not directly applicable to the SIDR > context, as the PKIX work is initially focusing on push-based > management of TAs, whereas the SIDR model is pull-based. However, we > have tentative agreement on a base format for trust anchors, and > that format could be used in the SIDR context, with only a very > minor change to our current syntax. Specifically, the base format > allows for a SEQUENE of self-signed certs (or other representations > about which we do not care) instead of a single self-signed cert. > > If there are no objections, I'd like to ask Geoff to change the TA > text in his document to adopt this format. Thanks Steve, As I understand your proposal, the CMS packaging remains, but it allows for a sequence of self-signed certs in which, in this profile, the sequence has a single member. have I got that right? regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 8 14:10:45 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9976028C107; Mon, 8 Dec 2008 14:10:45 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D41A28C107 for ; Mon, 8 Dec 2008 14:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVwp6pFVwFdO for ; Mon, 8 Dec 2008 14:10:42 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 19A7328C103 for ; Mon, 8 Dec 2008 14:10:42 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.173.171]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L9oJI-0000q6-A3; Mon, 08 Dec 2008 17:10:36 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <8F2D07BA-1736-4970-A5D1-316FABF05C65@apnic.net> References: <8F2D07BA-1736-4970-A5D1-316FABF05C65@apnic.net> Date: Mon, 8 Dec 2008 17:09:03 -0500 To: Geoff Huston From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] a proposed syntax change to the format of trust anchors X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org >>... > >Thanks Steve, > >As I understand your proposal, the CMS packaging remains, but it >allows for a sequence of self-signed certs in which, in this >profile, the sequence has a single member. > >have I got that right? > >regards, > > Geoff Yes, Geoff, absolutely correct. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 8 14:50:30 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5521C3A6ABC; Mon, 8 Dec 2008 14:50:30 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21A628C0FD for ; Mon, 8 Dec 2008 14:50:29 -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 YrThbTVMRa+y for ; Mon, 8 Dec 2008 14:50:29 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 024043A69AC for ; Mon, 8 Dec 2008 14:50:29 -0800 (PST) Received: from dhcp204.apnic.net (dhcp204.apnic.net [202.12.29.204]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3136B110064 for ; Tue, 9 Dec 2008 08:50:23 +1000 (EST) Message-Id: From: George Michaelson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 08:50:22 +1000 References: <8F2D07BA-1736-4970-A5D1-316FABF05C65@apnic.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] a proposed syntax change to the format of trust anchors X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 09/12/2008, at 8:09 AM, Stephen Kent wrote: >>> ... >> >> Thanks Steve, >> >> As I understand your proposal, the CMS packaging remains, but it >> allows for a sequence of self-signed certs in which, in this >> profile, the sequence has a single member. >> >> have I got that right? >> >> regards, >> >> Geoff > > Yes, Geoff, absolutely correct. > > Steve I think that converging our TA model with TAMP is a very good idea, and I support this proposal. -George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 9 08:12:10 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD3F3A6883; Tue, 9 Dec 2008 08:12:10 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1602C3A683E for ; Tue, 9 Dec 2008 08:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, 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 sCzZxXnBEP9V for ; Tue, 9 Dec 2008 08:12:08 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 5E1BA3A6883 for ; Tue, 9 Dec 2008 08:12:08 -0800 (PST) Received: from omzismtp01.vzbi.com ([165.122.46.164]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KBM00418A58G700@firewall.verizonbusiness.com> for sidr@ietf.org; Tue, 09 Dec 2008 16:07:56 +0000 (GMT) Received: from omzismtp01.vzbi.com ([127.0.0.1]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KBM00ACKA58DP00@omzismtp01.vzbi.com> for sidr@ietf.org; Tue, 09 Dec 2008 16:07:56 +0000 (GMT) Received: from [127.0.0.1] ([131.146.206.207]) by omzismtp01.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KBM00A28A56EY00@omzismtp01.vzbi.com> for sidr@ietf.org; Tue, 09 Dec 2008 16:07:56 +0000 (GMT) Message-id: <493E97DA.709@verizonbusiness.com> Date: Tue, 09 Dec 2008 11:07:54 -0500 From: Heather Schiller User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-version: 1.0 To: Stephen Kent References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> In-reply-to: Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Stephen Kent wrote: > > Steve > > > P.S. Irrespective of my analysis above, yes, I do prefer a > singly-rooted PKI, with IANA as the only TA, but I can live with a set > of TAs so long as I can count them on my fingers, and they all are > authoritative for the resources in question :-). > _______________________________________________ Steve, That's the concern -- what happens if 2 RIR's assert authority to the same resource? --Heather _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 9 09:09:26 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A44C3A6ABD; Tue, 9 Dec 2008 09:09:26 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13E43A694F for ; Tue, 9 Dec 2008 09:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 nUCqa4286Gzj for ; Tue, 9 Dec 2008 09:09:25 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id EC5F33A6ABD for ; Tue, 9 Dec 2008 09:09:24 -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 mB9H97HQ023510; Tue, 9 Dec 2008 11:09:07 -0600 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 mB9H97L2029455; Tue, 9 Dec 2008 11:09:07 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.132]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Dec 2008 12:09:06 -0500 Date: Tue, 9 Dec 2008 12:09:05 -0500 (Eastern Standard Time) From: Sandra Murphy To: Heather Schiller In-Reply-To: <493E97DA.709@verizonbusiness.com> Message-ID: References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 09 Dec 2008 17:09:06.0733 (UTC) FILETIME=[D812BDD0:01C95A20] Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 9 Dec 2008, Heather Schiller wrote: > Stephen Kent wrote: >> >> Steve >> >> >> P.S. Irrespective of my analysis above, yes, I do prefer a singly-rooted >> PKI, with IANA as the only TA, but I can live with a set of TAs so long as >> I can count them on my fingers, and they all are authoritative for the >> resources in question :-). >> _______________________________________________ > > > Steve, That's the concern -- what happens if 2 RIR's assert authority to the > same resource? That was my interpretation of John's concern, too. I believe that part of the freedom granted to relying parties ("granted" because there's no way to prevent them) is not only that relying parties are free to choose their trust anchors, but also that the relying parties are free to say what they trust their trust anchors to speak authoritatively for. So the relying parties can take care to ensure that they do not grant overlapping authority to their trust anchors. It should be the case that relying parties who mess that up, mess themselves up, not other people. --Sandy > > --Heather > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 9 10:38:50 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AE13A6B42; Tue, 9 Dec 2008 10:38:50 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E723A6B42 for ; Tue, 9 Dec 2008 10:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 tbMO5cj3uITd for ; Tue, 9 Dec 2008 10:38:48 -0800 (PST) Received: from ashesmtp02.verizonbusiness.com (ashesmtp02.verizonbusiness.com [198.4.8.166]) by core3.amsl.com (Postfix) with ESMTP id 658E33A6930 for ; Tue, 9 Dec 2008 10:38:48 -0800 (PST) Received: from omzismtp03.vzbi.com ([165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KBM00E5LH4H0E00@firewall.verizonbusiness.com> for sidr@ietf.org; Tue, 09 Dec 2008 18:38:41 +0000 (GMT) Received: from omzismtp03.vzbi.com ([127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KBM009MJH4HRO00@omzismtp03.vzbi.com> for sidr@ietf.org; Tue, 09 Dec 2008 18:38:41 +0000 (GMT) Received: from [127.0.0.1] ([131.146.206.207]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KBM0095LH4FQJ00@omzismtp03.vzbi.com> for sidr@ietf.org; Tue, 09 Dec 2008 18:38:41 +0000 (GMT) Message-id: <493EBB2F.90701@verizonbusiness.com> Date: Tue, 09 Dec 2008 13:38:39 -0500 From: Heather Schiller User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-version: 1.0 To: Sandra Murphy References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> In-reply-to: Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Sandra Murphy wrote: > > > On Tue, 9 Dec 2008, Heather Schiller wrote: > >> Stephen Kent wrote: >>> >>> Steve >>> >>> >>> P.S. Irrespective of my analysis above, yes, I do prefer a >>> singly-rooted PKI, with IANA as the only TA, but I can live with a >>> set of TAs so long as I can count them on my fingers, and they all >>> are authoritative for the resources in question :-). >>> _______________________________________________ >> >> >> Steve, That's the concern -- what happens if 2 RIR's assert authority >> to the same resource? > > That was my interpretation of John's concern, too. > > I believe that part of the freedom granted to relying parties ("granted" > because there's no way to prevent them) is not only that relying parties > are free to choose their trust anchors, but also that the relying > parties are free to say what they trust their trust anchors to speak > authoritatively for. > > So the relying parties can take care to ensure that they do not grant > overlapping authority to their trust anchors. It should be the case > that relying parties who mess that up, mess themselves up, not other > people. > > --Sandy > > > It sounds like you are suggesting that it is up to the operator to decide who is authoritative for a set of resources. This seems illogical because the operator doesn't control the resources and who is authoritative for them. Deciding which RIR should be authoritative for a resource is non trivial and should not be left up to individual operators. Appointing a single TA - and having it delegate downward resolves this conflict. ..alternatively find some other way to ensure that multiple TA's can not have a conflict. --Heather _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 9 19:33:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B6F3A6AB6; Tue, 9 Dec 2008 19:33:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB9428C159 for ; Tue, 9 Dec 2008 19:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 nXW3WoVMn869 for ; Tue, 9 Dec 2008 19:33:41 -0800 (PST) Received: from caida.org (rommie.caida.org [192.172.226.78]) by core3.amsl.com (Postfix) with ESMTP id 01FB33A6986 for ; Tue, 9 Dec 2008 19:33:40 -0800 (PST) Received: by caida.org (Postfix, from userid 2000) id 7AA15B961; Tue, 9 Dec 2008 19:33:33 -0800 (PST) Date: Tue, 9 Dec 2008 19:33:33 -0800 From: k claffy To: sidr@ietf.org Message-ID: <20081210033333.GA59426@rommie.caida.org> References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, Dec 09, 2008 at 12:09:05PM -0500, Sandra Murphy wrote: On Tue, 9 Dec 2008, Heather Schiller wrote: >Stephen Kent wrote: >> >>P.S. Irrespective of my analysis above, yes, I do prefer a singly-rooted >>PKI, with IANA as the only TA, but I can live with a set of TAs so long >>as I can count them on my fingers, and they all are authoritative for the >>resources in question :-). >>_______________________________________________ >Steve, That's the concern -- what happens if 2 RIR's assert authority to >the same resource? That was my interpretation of John's concern, too. I believe that part of the freedom granted to relying parties ("granted" because there's no way to prevent them) is not only that relying parties are free to choose their trust anchors, but also that the relying parties are free to say what they trust their trust anchors to speak authoritatively for. So the relying parties can take care to ensure that they do not grant overlapping authority to their trust anchors. It should be the case that relying parties who mess that up, mess themselves up, not other people. zoinks. that seems like an awful lot of trust to take out of the architecture and put back into the oft overtired or overworked or counterincented fingers sidr is trying to secure against. are you still going with 'secure' in the title? another problem, this relatively radical change in the architecture turns a whole class of people who are guaranteed to be proponents of sidr (like caida, whose research it will make easier because it will reduce the amount of work we have to do to resolve addresses to science) into people whose lives sidr will make much harder for little benefit. so, you at least have some marketing issues. but i see even deeper problems. it now sounds like a dlv-based bgp, and afaict for the same reasons. geoff explains to drc: My related observation is pretty much the same as yours - these are thorny matters with many interests and perspectives. I for one don't see this matter being resolved by a simple SIDR WG discussion - oh no - thats just the opening statements in something that I fear will carry on, like DNSSEC, for a decade or longer. as justified as that fear is, i can't imagine widespread support for pulling another IPv6 to avoid pulling another DNSSEC. (i'm no DNSSEC fan, but we should acknowledge that the root is closer to getting signed than it's ever been (thanks to meatspace governments recognizing the alternatives are worse), while IPv6 still doesn't even have any scalable routing architecture to even talk about deploying. but i asked vixie to tune in here, since he no doubt has some hard-earned wisdom from tilting at dlv that is relevant.) seems to me we've got a long history of 'let's leave that (economic/ownership/trust) part of this problem for some set of people who is not us' in recent ietf attempts to retrofit societal needs back into the Internet architecture, and scant evidence that even the designers are happy with the results. i agree that the trust architecture merits a separate draft, but i don't see a good case for postponing that draft. especially since geoff and others are pushing hard for the RIRs to allow for legitimate sale of ipv4 addresses to the highest bidder, asap. if we're gonna turn the economic and the ownership architectures for IP addresses upside down at the same time, we'd best make the trust architecture exceedingly clear. k _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 10 00:12:19 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57033A6B70; Wed, 10 Dec 2008 00:12:19 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD673A6B70 for ; Wed, 10 Dec 2008 00:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 haQyck1U33dW for ; Wed, 10 Dec 2008 00:12:17 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.51]) by core3.amsl.com (Postfix) with ESMTP id 54D013A6866 for ; Wed, 10 Dec 2008 00:12:17 -0800 (PST) Received: from [58.163.108.218] (unknown [58.163.108.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 465D2110065; Wed, 10 Dec 2008 18:12:10 +1000 (EST) Message-Id: From: Geoff Huston To: Heather Schiller In-Reply-To: <493E97DA.709@verizonbusiness.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 19:12:08 +1100 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 10/12/2008, at 3:07 AM, Heather Schiller wrote: > Stephen Kent wrote: >> Steve >> P.S. Irrespective of my analysis above, yes, I do prefer a singly- >> rooted PKI, with IANA as the only TA, but I can live with a set of >> TAs so long as I can count them on my fingers, and they all are >> authoritative for the resources in question :-). >> _______________________________________________ > > > Steve, That's the concern -- what happens if 2 RIR's assert > authority to the same resource? > WG chair hat off And no I'm not Steve either. :-) There is no protection anywhere in the RPKI to prevent overlap as an intrinsic property of the RPKI in the case where a single issuer may certify the same resource to two different entities simultaneously. Certificates do not generally prevent this situation of overlap. And in some cases this may be a feature rather than a bug. When you consider the case of a transfer of resources between two entities it may be prudent to certify the new entity with the resources while the old entity is also certified with the resources in order to allow relying parties to synchronise their local cached state of the distributed repository with the new entity's certified resources before the CA revokes the old entity's certificate that included the transferred resources. As far as I can tell certificates cannot provide any particular "protection in terms of duplication. The protection, and assurance, is reliant on the accuracy and integrity of the processes used by all involved parties in the correct and diligent administration of number resources. I don't see how certificates can provide any intrinsic protection against procedural failures - it is incumbent on the CAs here to be very diligent in their administration of these resources and ensure that their records, and their issued certificates are accurate. As far as I understand the situation this statement applies irrespective of any particular TA model. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Dec 10 06:27:53 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D363A6B9F; Wed, 10 Dec 2008 06:27:53 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469863A6B9F for ; Wed, 10 Dec 2008 06:27:52 -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 z2w-MSgM6KUs for ; Wed, 10 Dec 2008 06:27:51 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 727A03A68DC for ; Wed, 10 Dec 2008 06:27:51 -0800 (PST) Received: from zx80.arin.net ([::ffff:192.136.136.49]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 10 Dec 2008 09:27:44 -0500 id 01588470.493FD1E0.00006B27 Message-Id: <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us> From: Andrew Newton To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 09:27:43 -0500 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 2, 2008, at 7:24 PM, Stephen Kent wrote: > An AS 0 ROA is a positive assertion about the prefixes expressed in > it, as far as RP software is concerned. The "feature" of this > assertion is that, any unauthenticated assertions about the prefixes > should be rejected in favor of this verifiable ROA (assuming that > the ROA was signed by an entity that holds the prefixes in > question). In saying that I am making some assumptions about how ROs > use ROAs, and Danny has argued that we need to be more precise about > such assumptions. > > I see the AS 0 ROA as a valuable tool to deal with unallocated and > reserved address space, during the very long period when relying > parties will see a mix of verifiable and unverifiable assertions > about route origination. I have not thought so much about the > utility of this capability in a fully deployed system. I also did > not consider assertions about AS numbers, a feature of BOAs. Steve, Sorry for the late reply on this subject, but I was rereading the archives and it brought to my recollection a statement you made at the microphone in Minneapolis regarding AS 0 ROAs. I didn't readily grasp the meaning of what you said, so I'm seeking clarification. As I recall, you stated that a registry wishing to use a BOA to cover its space could just as well use AS 0 ROAs with a different practice. Whenever that registry allocated space, it would have to reissue the AS 0 ROAs so the newly allocated space is not covered. At least I think that was the gist of what you described. Is this correct, or can you explain again the scenario you mentioned? -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Dec 11 13:54:30 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA74C3A6959; Thu, 11 Dec 2008 13:54:30 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEAB3A6959 for ; Thu, 11 Dec 2008 13:54:29 -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 FlLA3euRRIRe for ; Thu, 11 Dec 2008 13:54:28 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A1DA23A68E3 for ; Thu, 11 Dec 2008 13:54:28 -0800 (PST) Received: from col-dhcp33-244-160.bbn.com ([128.33.244.160]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LAtUC-000885-CM; Thu, 11 Dec 2008 16:54:20 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> Date: Thu, 11 Dec 2008 16:54:22 -0500 To: Sandra Murphy From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 12:09 PM -0500 12/9/08, Sandra Murphy wrote: >On Tue, 9 Dec 2008, Heather Schiller wrote: >... > >So the relying parties can take care to ensure that they do not >grant overlapping authority to their trust anchors. It should be >the case that relying parties who mess that up, mess themselves up, >not other people. > >--Sandy yes, the effects of an RP error in managing it TA info is local to that RP. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Dec 11 14:09:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3383A67AB; Thu, 11 Dec 2008 14:09:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FF93A67AB for ; Thu, 11 Dec 2008 14:09: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=[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 T7tMWszj0ZPb for ; Thu, 11 Dec 2008 14:09:41 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 366FF3A66B4 for ; Thu, 11 Dec 2008 14:09:41 -0800 (PST) Received: from col-dhcp33-244-160.bbn.com ([128.33.244.160]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LAtUD-000885-BS; Thu, 11 Dec 2008 16:54:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <493EBB2F.90701@verizonbusiness.com> References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> <493EBB2F.90701@verizonbusiness.com> Date: Thu, 11 Dec 2008 16:54:22 -0500 To: Heather Schiller From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 1:38 PM -0500 12/9/08, Heather Schiller wrote: >... >It sounds like you are suggesting that it is up to the operator to >decide who is authoritative for a set of resources. This seems >illogical because the operator doesn't control the resources and who >is authoritative for them. Deciding which RIR should be >authoritative for a resource is non trivial and should not be left >up to individual operators. Appointing a single TA - and having it >delegate downward resolves this conflict. ..alternatively find some >other way to ensure that multiple TA's can not have a conflict. > > >--Heather Heather, In ANY PKI, each RP is always the final arbiter of who he/she perceives to be authoritative. The best we can do here is to provide a default TA (or set of TAs), that are easy for RPs to adopt, and that reflect the extant resource allocation system. That's what we have done, almost :-). I have a lot of exposure to attempts to create PKIs that cross organizations boundaries, in various parts of the world. Compared the other efforts with which I am familiar, this is a very, very good effort. We have avoided creating third parties to act as CAs. We don't have bridge CAs (which could not work with the 3779 path validation description). We're debating the downside of offering 6 TAs, all of which are legitimate, authoritative entities in the resource allocation system, vs 1. I think we're pretty close. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Dec 11 14:21:32 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B683A6872; Thu, 11 Dec 2008 14:21:32 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D5C3A6872 for ; Thu, 11 Dec 2008 14:21:31 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdnWUl2bg7L2 for ; Thu, 11 Dec 2008 14:21:30 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2A9283A66B4 for ; Thu, 11 Dec 2008 14:21:30 -0800 (PST) Received: from col-dhcp33-244-160.bbn.com ([128.33.244.160]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LAtUE-000885-AR; Thu, 11 Dec 2008 16:54:22 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <493E97DA.709@verizonbusiness.com> References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> Date: Thu, 11 Dec 2008 16:54:22 -0500 To: Heather Schiller From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0907368182==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --===============0907368182== Content-Type: multipart/alternative; boundary="============_-983090030==_ma============" --============_-983090030==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:07 AM -0500 12/9/08, Heather Schiller wrote: >Stephen Kent wrote: >> >>Steve >> >> >>P.S. Irrespective of my analysis above, yes, I do prefer a >>singly-rooted PKI, with IANA as the only TA, but I can live with a >>set of TAs so long as I can count them on my fingers, and they all >>are authoritative for the resources in question :-). >>_______________________________________________ > > >Steve, That's the concern -- what happens if 2 RIR's assert >authority to the same resource? > > --Heather If two RIRs claim to be authoritative for the same address block, and if they both allocate that block to lower tier entities (e.g., ISPs), then certs and ROAs issued by those entities will validated by RP software using the default TA set. Note, though that an equivalent problem can arise of one RIR accidentally allocates the same block to two ISPs. We can't reliably detect and automatically reject this, because when address space transfers are in process, they look the same (in terms of RPKI objects). Yes, it would be preferable if we had a way to detect inter-RIR conflicts when they represent errors. There is at least one possible solution to this, even if both IANA and the RIRs are represented as "default" or "nominal" trust anchors, but it would be cleaner if IANA was the sole TA. Steve --============_-983090030==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection"
At 11:07 AM -0500 12/9/08, Heather Schiller wrote:
Stephen Kent wrote:

Steve


P.S.  Irrespective of my analysis above, yes, I do prefer a singly-rooted PKI, with IANA as the only TA, but I can live with a set of TAs so long as I can count them on my fingers, and they all are authoritative for the resources in question :-).
_______________________________________________


Steve, That's the concern -- what happens if 2 RIR's assert authority to the same resource?

  --Heather

If two RIRs claim to be authoritative for the same address block, and if they both allocate that block to lower tier entities (e.g., ISPs), then certs and ROAs issued by those entities will validated by RP software using the default TA set. Note, though that an equivalent problem can arise of one RIR accidentally allocates the same block to two ISPs. We can't reliably detect and automatically reject this, because when address space transfers are in process, they look the same (in terms of RPKI objects).

Yes, it would be preferable if we had a way to detect inter-RIR conflicts when they represent errors.  There is at least one possible solution to this, even if both IANA and the RIRs are represented as "default" or "nominal" trust anchors, but it would be cleaner if IANA was the sole TA.

Steve


--============_-983090030==_ma============-- --===============0907368182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0907368182==-- From sidr-bounces@ietf.org Thu Dec 11 14:21:34 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78823A69BD; Thu, 11 Dec 2008 14:21:34 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C06D3A6872 for ; Thu, 11 Dec 2008 14:21: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=[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 n7xa3mwTXB51 for ; Thu, 11 Dec 2008 14:21:31 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1E94F3A66B4 for ; Thu, 11 Dec 2008 14:21:31 -0800 (PST) Received: from col-dhcp33-244-160.bbn.com ([128.33.244.160]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LAtUF-000885-AA; Thu, 11 Dec 2008 16:54:23 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20081210033333.GA59426@rommie.caida.org> References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> <20081210033333.GA59426@rommie.caida.org> Date: Thu, 11 Dec 2008 16:54:22 -0500 To: k claffy From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 7:33 PM -0800 12/9/08, k claffy wrote: >On Tue, Dec 09, 2008 at 12:09:05PM -0500, Sandra Murphy wrote: > On Tue, 9 Dec 2008, Heather Schiller wrote: > >Stephen Kent wrote: > >> > >>P.S. Irrespective of my analysis above, yes, I do prefer a singly-rooted > >>PKI, with IANA as the only TA, but I can live with a set of TAs so long > >>as I can count them on my fingers, and they all are authoritative for the > >>resources in question :-). > >>_______________________________________________ > >Steve, That's the concern -- what happens if 2 RIR's assert authority to > >the same resource? > > That was my interpretation of John's concern, too. > > I believe that part of the freedom granted to relying parties ("granted" > because there's no way to prevent them) is not only that relying parties > are free to choose their trust anchors, but also that the relying parties > are free to say what they trust their trust anchors to speak > authoritatively for. that's correct. > > So the relying parties can take care to ensure that they do not grant > overlapping authority to their trust anchors. It should be the case that > relying parties who mess that up, mess themselves up, not other people. > >zoinks. that seems like an awful lot of trust to take >out of the architecture and put back into the oft >overtired or overworked or counterincented fingers sidr >is trying to secure against. are you still going with >'secure' in the title? yes, I am :-). The insecurity that results from an RP making errors primarily affects that RP, i.e., he/she is vulnerable to viewing invalid origin assertions as being authentic, but no other RPs suffer the same fate. >another problem, this relatively radical change in the >architecture turns a whole class of people who are guaranteed >to be proponents of sidr (like caida, whose research it will >make easier because it will reduce the amount of work we have >to do to resolve addresses to science) into people whose lives >sidr will make much harder for little benefit. On what basis do you assert that there is little benefit from this infrastructure? >so, you at least have some marketing issues. > >but i see even deeper problems. it now sounds like a dlv-based >bgp, and afaict for the same reasons. geoff explains to drc: > > My related observation is pretty much the same as yours - these are > thorny matters with many interests and perspectives. I for one don't > see this matter being resolved by a simple SIDR WG discussion - oh > no - thats just the opening statements in something that I fear will > carry on, like DNSSEC, for a decade or longer. I am less pessimistic that Geoff in this regard, but I do think it would be preferable to move forward with our 6 TA model, and work the politics to to enable migration to a single TA (IANA) model. It will be easy to make this migration if the community agrees. >as justified as that fear is, i can't imagine widespread support >for pulling another IPv6 to avoid pulling another DNSSEC. I don't understand this metaphor. I fear you've been hanging out with Randy too much :-)! >(i'm no DNSSEC fan, but we should acknowledge that the root is >closer to getting signed than it's ever been (thanks to meatspace >governments recognizing the alternatives are worse), while >IPv6 still doesn't even have any scalable routing architecture >to even talk about deploying. but i asked vixie to tune in >here, since he no doubt has some hard-earned wisdom from tilting >at dlv that is relevant.) I agree that we're getting close on IANA as the single DNSSEC root. This too has been a political issue, after a long technical development process. I am hoping we have a shorter tech development process for the RPKI. >seems to me we've got a long history of 'let's leave that >(economic/ownership/trust) part of this problem for some set >of people who is not us' in recent ietf attempts to retrofit >societal needs back into the Internet architecture, and scant >evidence that even the designers are happy with the results. >i agree that the trust architecture merits a separate draft, >but i don't see a good case for postponing that draft. especially >since geoff and others are pushing hard for the RIRs to allow for >legitimate sale of ipv4 addresses to the highest bidder, asap. >if we're gonna turn the economic and the ownership >architectures for IP addresses upside down at the same time, >we'd best make the trust architecture exceedingly clear. We can split off the discussion of trust anchors options and management into a separate I-D, if enough folks believe that will help. But, I also agree with you that if we just use this document restructuring to defer the problem, we are not making great progress. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 12 10:39:32 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAC63A6B03; Fri, 12 Dec 2008 10:39:32 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0514A28C131 for ; Fri, 12 Dec 2008 10:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 YHRBKQQeaJFz for ; Fri, 12 Dec 2008 10:39:30 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 17F3F3A6B03 for ; Fri, 12 Dec 2008 10:39:30 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LBCv3-0004Lo-Dx; Fri, 12 Dec 2008 13:39:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us> References: <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us> Date: Fri, 12 Dec 2008 10:52:28 -0500 To: Andrew Newton From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 9:27 AM -0500 12/10/08, Andrew Newton wrote: >On Dec 2, 2008, at 7:24 PM, Stephen Kent wrote: > >>An AS 0 ROA is a positive assertion about the prefixes expressed in >>it, as far as RP software is concerned. The "feature" of this >>assertion is that, any unauthenticated assertions about the >>prefixes should be rejected in favor of this verifiable ROA >>(assuming that the ROA was signed by an entity that holds the >>prefixes in question). In saying that I am making some assumptions >>about how ROs use ROAs, and Danny has argued that we need to be >>more precise about such assumptions. >> >>I see the AS 0 ROA as a valuable tool to deal with unallocated and >>reserved address space, during the very long period when relying >>parties will see a mix of verifiable and unverifiable assertions >>about route origination. I have not thought so much about the >>utility of this capability in a fully deployed system. I also did >>not consider assertions about AS numbers, a feature of BOAs. > >Steve, > >Sorry for the late reply on this subject, but I was rereading the >archives and it brought to my recollection a statement you made at >the microphone in Minneapolis regarding AS 0 ROAs. I didn't readily >grasp the meaning of what you said, so I'm seeking clarification. > >As I recall, you stated that a registry wishing to use a BOA to >cover its space could just as well use AS 0 ROAs with a different >practice. >Whenever that registry allocated space, it would have to reissue the >AS 0 ROAs so the newly allocated space is not covered. At least I >think that was the gist of what you described. > >Is this correct, or can you explain again the scenario you mentioned? > >-andy Andy, Your characterization is good paraphrase of my comments at the mic. In fairness to Geoff's BOA proposal, my ROA As 0 convention is not as powerful, in that it has no provisions for making a negative assertion about AS numbers. If I were a registry (or an ISP) making use of the AS 0 ROA approach, I would issue one EE cert and one associated ROA )covering all of the unallocated space that I hold). The EE cert would have a lifetime consistent with the time I take to respond to allocation requests, maybe on 1-day lifetime. That way I would not have to put the EE cert on a CRL when a new AS 0 ROA was issued; I'd just be issuing one new cert and one new ROA every day. Since it is probably good practice to issue a CRL every day, the set of objects published by the registry/ISP would have to change that frequently anyway, so this is not much of a new burden, (e.g., the manifest has to change whenever a new CRL is issued). I also note that even if we don't adopt AS 0 ROAs as a recognized way to make this sort of assertion, any ROA issuer can use it anyway, either explicitly or via analogous means :-). Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 12 11:31:20 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8D13A698A; Fri, 12 Dec 2008 11:31:20 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F5F3A6B03 for ; Fri, 12 Dec 2008 11:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OguTfHxhidTv for ; Fri, 12 Dec 2008 11:31:18 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id ED0333A698A for ; Fri, 12 Dec 2008 11:31:17 -0800 (PST) Received: from zx80.arin.net ([::ffff:192.136.136.49]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 12 Dec 2008 14:31:10 -0500 id 01588112.4942BBFE.0000189E Message-Id: From: Andrew Newton To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 14:31:10 -0500 References: <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 12, 2008, at 10:52 AM, Stephen Kent wrote: > Andy, > > Your characterization is good paraphrase of my comments at the mic. > In fairness to Geoff's BOA proposal, my ROA As 0 convention is not > as powerful, in that it has no provisions for making a negative > assertion about AS numbers. > > If I were a registry (or an ISP) making use of the AS 0 ROA > approach, I would issue one EE cert and one associated ROA )covering > all of the unallocated space that I hold). The EE cert would have a > lifetime consistent with the time I take to respond to allocation > requests, maybe on 1-day lifetime. That way I would not have to put > the EE cert on a CRL when a new AS 0 ROA was issued; I'd just be > issuing one new cert and one new ROA every day. Since it is probably > good practice to issue a CRL every day, the set of objects published > by the registry/ISP would have to change that frequently anyway, so > this is not much of a new burden, (e.g., the manifest has to change > whenever a new CRL is issued). > > I also note that even if we don't adopt AS 0 ROAs as a recognized > way to make this sort of assertion, any ROA issuer can use it > anyway, either explicitly or via analogous means :-). > > Steve Steve, Thanks for the information. That was very helpful. As to the use of a negative attestation (be it BOA or AS 0 ROA) by a registry, that will most likely be decided by policy in my opinion. But I do believe there are operational differences between the two approaches. A 1 day lifetime is reasonable during the working week, but weekends and holidays are a different story. And often times those weekends are used for maintenance windows. Additionally, there are exception cases were allocations need to be updated urgently and then there are trouble shooting events... in both these situations an AS 0 ROA acts like an another moving part that needs to be double checked whereas a BOA requires less care and maintenance. From my perspective, a BOA seems less error prone should negative attestations be desired. I think there is also another angle to the adoption issue that needs consideration. As I stated, I do not know if negative attestations will be immediately adopted and at what level. But let's hypothesize about a community that adopts RPKI and does not use them. And then, 5 years after adoption they determine that such a thing is needed. To get them, there would be a need to cycle back through the standards track and software adoption curve. It seems better to have BOAs in the standard now and have them ignored then to have to iterate through another standards & software adoption process. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 12 11:37:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E6C3A6B42; Fri, 12 Dec 2008 11:37:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3781D3A6B42 for ; Fri, 12 Dec 2008 11:37: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 G4dVrU0ymEfQ for ; Fri, 12 Dec 2008 11:37:24 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 603F53A698A for ; Fri, 12 Dec 2008 11:37:24 -0800 (PST) Received: from zx80.arin.net ([::ffff:192.136.136.49]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 12 Dec 2008 14:37:17 -0500 id 01588112.4942BD6D.00001CE0 Message-Id: <8F3B5F9B-1FC3-4872-9851-B573B31DB376@hxr.us> From: Andrew Newton To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 14:37:16 -0500 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 11, 2008, at 4:54 PM, Stephen Kent wrote: > If two RIRs claim to be authoritative for the same address block, > and if they both allocate that block to lower tier entities (e.g., > ISPs), then certs and ROAs issued by those entities will validated > by RP software using the default TA set. Note, though that an > equivalent problem can arise of one RIR accidentally allocates the > same block to two ISPs. We can't reliably detect and automatically > reject this, because when address space transfers are in process, > they look the same (in terms of RPKI objects). > > Yes, it would be preferable if we had a way to detect inter-RIR > conflicts when they represent errors. There is at least one > possible solution to this, even if both IANA and the RIRs are > represented as "default" or "nominal" trust anchors, but it would be > cleaner if IANA was the sole TA. > > Steve Steve, I want to be sure I understand this. The double allocation conflict can originate from anywhere in the tree, even from the root, right? So this conflict is only tangential to the nature of the trust anchor(s)? -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 12 13:50:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F803A6889; Fri, 12 Dec 2008 13:50:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23F43A6889 for ; Fri, 12 Dec 2008 13:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 ME5EAiXLzs-l for ; Fri, 12 Dec 2008 13:50:38 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E4D643A67E4 for ; Fri, 12 Dec 2008 13:50:37 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LBFu0-00084Y-CQ; Fri, 12 Dec 2008 16:50:28 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <3998050D-E54A-4F8B-8D18-0AAB55956879@hxr.us> Date: Fri, 12 Dec 2008 16:46:25 -0500 To: Andrew Newton From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] Request for WG Last Call for draft-ietf-sidr-bogons-02.txt and draft-ietf-sidr-roa-validation-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 2:31 PM -0500 12/12/08, Andrew Newton wrote: >On Dec 12, 2008, at 10:52 AM, Stephen Kent wrote: >... >Steve, > >Thanks for the information. That was very helpful. > >As to the use of a negative attestation (be it BOA or AS 0 ROA) by a >registry, that will most likely be decided by policy in my opinion. >But I do believe there are operational differences between the two approaches. > >A 1 day lifetime is reasonable during the working week, but weekends >and holidays are a different story. And often times those weekends >are used for maintenance windows. Additionally, there are exception >cases were allocations need to be updated urgently and then there >are trouble shooting events... in both these situations an AS 0 ROA >acts like an another moving part that needs to be double checked >whereas a BOA requires less care and maintenance. From my >perspective, a BOA seems less error prone should negative >attestations be desired. First, recall that each CRL says when the next CRL will be issued, so if one decides to not issue CRLs on weekend and holidays, that distinction is easy to express in the CRL NextUpdate field. Similarly, if the intent is to not make new allocations and enable then during such periods, the AS 0 ROA can be given a longer lifetime for those days. Separately, I don't think I understand the operational difference. A BOA, as a signed object, would need to be revoked just as an AS 0 ROA would, and it would have the same lifetime management requirements. Which aspect of BOAs vs. AA 0 ROAs, do you believe make the former easier to deal with in these contexts? >I think there is also another angle to the adoption issue that needs >consideration. As I stated, I do not know if negative attestations >will be immediately adopted and at what level. But let's >hypothesize about a community that adopts RPKI and does not use >them. And then, 5 years after adoption they determine that such a >thing is needed. To get them, there would be a need to cycle back >through the standards track and software adoption curve. It seems >better to have BOAs in the standard now and have them ignored then >to have to iterate through another standards & software adoption >process. I think there are several, separable issues here. One issue is whether we need to make provisions for negative assertions. If so, then I agree that making provisions for such assertions sooner is better. A second issue is the scope of such assertions (just address space or address space and AS numbers). Then we can ask what form such assertions should take, e.g., BOAs vs. ROAs, vs. ? I observe that if the scope of such assertions is just address space, and not AS numbers I believe we can do this via ROAs, and thus we already have the necessary mechanism available. It then becomes a matter of policy whether to make such assertions ort not. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 12 13:53:45 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583963A6889; Fri, 12 Dec 2008 13:53:45 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E2443A6889 for ; Fri, 12 Dec 2008 13:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 mGaGJ1PwtX0u for ; Fri, 12 Dec 2008 13:53:43 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5CEB13A67E4 for ; Fri, 12 Dec 2008 13:53:43 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LBFx2-00085o-By; Fri, 12 Dec 2008 16:53:36 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <8F3B5F9B-1FC3-4872-9851-B573B31DB376@hxr.us> References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> <8F3B5F9B-1FC3-4872-9851-B573B31DB376@hxr.us> Date: Fri, 12 Dec 2008 16:53:25 -0500 To: Andrew Newton From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 2:37 PM -0500 12/12/08, Andrew Newton wrote: >>... > >Steve, > >I want to be sure I understand this. The double allocation conflict >can originate from anywhere in the tree, even from the root, right? >So this conflict is only tangential to the nature of the trust anchor(s)? > >-andy Yes, that's right. The use of 3779 extensions does not prevent an authorized holder of resources from issuing two certs for a subset of the resources. It does provide hard evidence of such an allocation, which in itself helps identify where an error was made, if indeed, the actions reflects an error (e.g., vs. a transfer of the resource). Use of CRLs also allows one to remedy an error in a highly visible fashion. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Dec 12 15:03:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62953A6938; Fri, 12 Dec 2008 15:03:01 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4583B3A6923 for ; Fri, 12 Dec 2008 15:03:01 -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 muYY-2e5BvGt for ; Fri, 12 Dec 2008 15:03:00 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 8C9E83A691E for ; Fri, 12 Dec 2008 15:03:00 -0800 (PST) Received: from [10.0.1.200] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 980A33D573A; Fri, 12 Dec 2008 15:02:49 -0800 (PST) Message-Id: From: David Conrad To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 12 Dec 2008 15:02:48 -0800 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> <8F3B5F9B-1FC3-4872-9851-B573B31DB376@hxr.us> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Dec 12, 2008, at 1:53 PM, Stephen Kent wrote: > At 2:37 PM -0500 12/12/08, Andrew Newton wrote: >> >> The double allocation conflict can originate from anywhere in the >> tree, even from the root, right? So this conflict is only >> tangential to the nature of the trust anchor(s)? > Yes, that's right. Sorry, I'm a bit confused, but perhaps that's because I misunderstood the original issue. My reading of the issue in question is: Assume you as an RP have accepted TAs 1 through 6 to certify blocks of address space they allocate and (say) TA 2 decides to certify the same block as TA 3. This seems fundamentally different to me than 'further down the tree', i.e., either ISP X doubly allocating a block to two customers or ISP X and ISP Y receiving the same allocation. In both of the 'further down the tree' cases, there is a parent that can 'adjudicate' the conflict either via the chain of trust defined by the RPKI or via contractual relationships. In the case of multiple TAs certifying the same block, no such parent exists and the RP gets a choice: either accept the fact that a block has been allocated to multiple entities and deal with it (somehow), figure out which of the assertions to believe from which TA, or stop believing one of the TAs. None of these seem particularly appealing. If I didn't misunderstand the issue, this seems like a potentially serious problem, particularly if the TAs have difficulty working/ playing well together (perish the thought) and/or turn out to be competitors in the fullness of time. Did I misunderstand? Regards, -drc _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 15 07:44:57 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E813328C0FB; Mon, 15 Dec 2008 07:44:57 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9898628C0F8 for ; Mon, 15 Dec 2008 07:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 zz9NGNXLUy43 for ; Mon, 15 Dec 2008 07:44:55 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 970D328C0FB for ; Mon, 15 Dec 2008 07:44:55 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LCFck-0007j8-Az; Mon, 15 Dec 2008 10:44:46 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> <8F3B5F9B-1FC3-4872-9851-B573B31DB376@hxr.us> Date: Mon, 15 Dec 2008 10:42:15 -0500 To: David Conrad From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] draft-ietf-res-certs ("Trust Anchor Collection" model) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 3:02 PM -0800 12/12/08, David Conrad wrote: >On Dec 12, 2008, at 1:53 PM, Stephen Kent wrote: >>At 2:37 PM -0500 12/12/08, Andrew Newton wrote: >>> >>>The double allocation conflict can originate from anywhere in the >>>tree, even from the root, right? So this conflict is only >>>tangential to the nature of the trust anchor(s)? >>Yes, that's right. > >Sorry, I'm a bit confused, but perhaps that's because I >misunderstood the original issue. My reading of the issue in >question is: > >Assume you as an RP have accepted TAs 1 through 6 to certify blocks >of address space they allocate and (say) TA 2 decides to certify the >same block as TA 3. This seems fundamentally different to me than >'further down the tree', i.e., either ISP X doubly allocating a >block to two customers or ISP X and ISP Y receiving the same >allocation. In both of the 'further down the tree' cases, there is >a parent that can 'adjudicate' the conflict either via the chain of >trust defined by the RPKI or via contractual relationships. In the >case of multiple TAs certifying the same block, no such parent >exists and the RP gets a choice: either accept the fact that a block >has been allocated to multiple entities and deal with it (somehow), >figure out which of the assertions to believe from which TA, or stop >believing one of the TAs. None of these seem particularly appealing. > >If I didn't misunderstand the issue, this seems like a potentially >serious problem, particularly if the TAs have difficulty >working/playing well together (perish the thought) and/or turn out >to be competitors in the fullness of time. > >Did I misunderstand? > >Regards, >-drc David, You are correct that in the case of a duplicate allocation by any entity farther down the tree, there is a single entity (the CA in question) that can resolve the conflict. However, from the perspective of relying party software, the problem is the same, i.e., the conflicting assertions (certs and ROAs) both validate. I thought that was the focus of the question. As you note, if two RIRs issue conflicting certs, and both are TAs, then the out-of-band resolution of the conflict requires cooperation across organizational boundaries. If the community agrees that records maintained by IANA re allocation of address blocks to RIRs are the preferred way to avoid/resolve such conflicts, then certs issued by IANA to the RIRs, reflecting such allocations, would provide a solution (at least from the RP software perspective). Note that such certs could be issued by IANA even if each RIR is a "default" TA, and used by RP software as an independent check on the consistency of the RPKI TA certs issued by RIRs to themselves. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Dec 15 13:35:18 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9473428C150; Mon, 15 Dec 2008 13:35:18 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7902128C150 for ; Mon, 15 Dec 2008 13:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.062 X-Spam-Level: X-Spam-Status: No, score=-1.062 tagged_above=-999 required=5 tests=[AWL=0.055, 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 FGt9vXtyluJl for ; Mon, 15 Dec 2008 13:35:16 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id CE62B28C122 for ; Mon, 15 Dec 2008 13:35:16 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 1B2562684EA; Mon, 15 Dec 2008 14:35:10 -0700 (MST) Received: from [192.168.0.100] (97-122-99-176.hlrn.qwest.net [97.122.99.176]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 15 Dec 2008 14:35:09 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.99.176; client-port=63456; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <2246B399-C624-4E52-9BDF-5A6E5A9DA9D5@tcb.net> From: Danny McPherson To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 15 Dec 2008 14:35:09 -0700 References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> <8F3B5F9B-1FC3-4872-9851-B573B31DB376@hxr.us> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: [sidr] Multiple v. Single TA (was something else) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > Note that such certs could be issued by IANA even if each RIR is a > "default" TA, and used by RP software as an independent check on the > consistency of the RPKI TA certs issued by RIRs to themselves. Steve, Can you expand upon this comment? Would this be a normal model to operate or is there some offshoot? Somewhat related... Here's one of my issues with multiple RIRs being TAs. Some RIRs invest much more heavily in security than others, and NONE currently have an operational role in routing on the Internet (this talk of weekends, holidays, et al., illustrates the issue). If someone were to launch a targeted attack they could first compromise the least secure RIR (TA), and then they can do what they wish and affect ANY resource, right?. Whereas, with a single TA model, the attack surface would only involve a single RIR and IANA up my validation path, is that correct? What other factors should be considered here? What about security of the repository in a multi-TA model, are there things that should be considered there? -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 16 06:31:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774D728C122; Tue, 16 Dec 2008 06:31:25 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10E028C0F7 for ; Tue, 16 Dec 2008 06:31:24 -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 pPh4lNwqWNPA for ; Tue, 16 Dec 2008 06:31:24 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 790B63A6A93 for ; Tue, 16 Dec 2008 06:31:05 -0800 (PST) Received: from ros-dhcp233-050-110.bbn.com ([192.233.50.110]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LCawp-0007rL-FK; Tue, 16 Dec 2008 09:30:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <2246B399-C624-4E52-9BDF-5A6E5A9DA9D5@tcb.net> References: <17A2325B-A90B-438F-8794-4D01B8A57D55@tcb.net> <92AEE15F-1DBD-4BF1-9857-B22C658A1166@istaff.org> <493E97DA.709@verizonbusiness.com> <8F3B5F9B-1FC3-4872-9851-B573B31DB376@hxr.us> <2246B399-C624-4E52-9BDF-5A6E5A9DA9D5@tcb.net> Date: Tue, 16 Dec 2008 09:31:02 -0500 To: Danny McPherson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] Multiple v. Single TA (was something else) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 2:35 PM -0700 12/15/08, Danny McPherson wrote: >> Note that such certs could be issued by IANA even if each RIR is a >>"default" TA, and used by RP software as an independent check on >>the consistency of the RPKI TA certs issued by RIRs to themselves. > >Steve, >Can you expand upon this comment? Would this be a normal >model to operate or is there some offshoot? This is definitely a special case. In a "normal' RP environment, there would be no provision to perform this sort of cross check. I fairness, however, use of the 3779 extension in path validation is not supported by most RPs anyway, so the RPKI is special. Also, since we see a need to provide tools to enable an RP to manage TAs to allow for use of RFC 1918 addresses (locally), it would be simple to add this cross check into such code. >Somewhat related... > >Here's one of my issues with multiple RIRs being TAs. Some >RIRs invest much more heavily in security than others, and NONE >currently have an operational role in routing on the Internet >(this talk of weekends, holidays, et al., illustrates the issue). > >If someone were to launch a targeted attack they could first >compromise the least secure RIR (TA), and then they can do what >they wish and affect ANY resource, right?. Whereas, with a single >TA model, the attack surface would only involve a single RIR and >IANA up my validation path, is that correct? What other factors >should be considered here? I agree with your analysis. Having RIRs be TAs without a cross check capability does increase the overall system vulnerability, for the reasons you cited above. >What about security of the repository in a multi-TA model, are >there things that should be considered there? I don't think the repository system incurs significant additional risks due to adoption of a multi-TA model, since each RIR seems like a "natural" host for repository data for its members. Also, we put in a number of safeguards (based on data being signed by the cognizant authorities, typically ISPs) to minimize the risks posed by attacks against repositories But I admit to not having looked into this issue closely. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Dec 16 08:46:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3145C3A6AA6; Tue, 16 Dec 2008 08:46:42 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B3C3A6AA6 for ; Tue, 16 Dec 2008 08:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 uRhmQ1deOS7X for ; Tue, 16 Dec 2008 08:46:39 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A053A3A6AA7 for ; Tue, 16 Dec 2008 08:46:06 -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 mBGGjw8I015795 for ; Tue, 16 Dec 2008 10:45:58 -0600 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 mBGGjvPW015569 for ; Tue, 16 Dec 2008 10:45:58 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.134]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Dec 2008 11:45:57 -0500 Date: Tue, 16 Dec 2008 11:45:57 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 16 Dec 2008 16:45:57.0351 (UTC) FILETIME=[C4D41F70:01C95F9D] Subject: [sidr] minutes from sidr IETF 73 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thanks to Roque Gagliano, who took the minutes at the sidr meeting in Minneapolis. The minutes are below. Please comment to the list of any changes you think are needed. --Sandy Minutes for IETF SIDR Meeting IETF73. November 17th 2008. 1300-1500 Salon AB - Hilton. Minneapolis, MN. USA. Chairs: Sandra Murphy Geoff Huston (participating remotely). Minutes taker: Roque Gagliano - LACNIC Jabber scriber: George Michaelson - APNIC 1300: Session called to order. A) Administrivia B) Updated Drafts 1) Two presentations by Matt Lepinski BBN Technologies: a) RPKI Architecture Document (draft-ietf-sidr-arch-04.txt): - 04 Document out, differences with 03: Improved abstract and consistency with other SIDR doc. No open issues, please read. Comments?: Sandy - Route Filters and semantic issues raised by Geoff (the list is exclusionary, the issue was raised during the RPSL discussion last time). Matt - Not in the current version, need to have private discussion of how go deal with this issue. Ruediger - Route Filter Use is not real validation but to implement policy. For doing this you can use different sources of information, better if it is good sources. This discussion of what do we do until we get to the final form of validation has not happen yet (will it in this century?). Geoffry Haas - in support, SIDR should talk about create filters from data. RPSEC work leading should talk about using this data for security preference. If a network chooses not to use, that should be fine. Randy Bush - dont think you want to get into what shades of lipstick on the pig?. Matt - The intention of the arch, document is just that the date in the RPKI can be used as an input for policy desicion. Roque - Please do not mention DNSSEC and what happened with trust anchor material information? Matt - Ok. Stephen - We need to keep detailed information in only one document, open to know about which one. The Cert profile version 15 has reasonable information but we need to keep it in one place. Sandy- Architecture document do not normally have formatting information. a) ROA Format document (draft-ietf-sidr-roa-format-04.txt): Version-04. Changes since 03: - Clarified text on ROA validity. - Addresses in ROA must be a subset of EE certificate Prefixes (not need for exact match). RobertK - Currently you can have prefixes overlapping from different ROAs, the problem is that it can be confusing for implementors. One implementation takes it as "wrong.". Ruediger - What is the problem? this can be a feature. I may want to announce the aggregate and have particular policies for some and not all the more specifics. Overlapping ROAs should be allowed. Rob Austein - Now that we have a use for these, I will change the code. S. Kent - How does people feel about inherit bit in the ROA. Looks to us that can be a problem to developers to have those and not the explicit cert. Rob Austein - Agreed may be simpler to implement RobertK - You still need to go up the chain. Rob Austein - This issue is only for ROAs, do not put in more generic doc. Leave it in the ROA doc. Matt - Will take this issue to the list. Randy - Overlapping Prefixes: Will be working with Ruediger on the unusual cases. Do we want to give funny code about this? Sandy - Any harm to overlapping ROAs? Randy - The code, but it is a consequence of funny arch. Matt - Hopefully will discuss this on the list. Other issue: multiple signature proposal, believe there is not consensus to change. Randy - I do not consent. Ruediger - Cases are so rare that I do not consent. Rob Austein - I do not consent. Sandy - As a WG chair I also believe there is not consensus for this. What is the process on for multiple ROA? The ROA draft continue alive but not consensus on adding multiple signatures to the ROAs. Russ (Author CMS) - No problem going that way. Next discussion raised: BOA & ROA ASN=0: Matt - Transition period, ROA for AS = 0. Can we add text that it should be interpreted as "should not be routable". Randy - Fear of manual trust anchor configuration can be a consequence and we will finish similarly to the current bogon filters. S Kent - Unlike BOA during the transition period this idea will not mean a new mechanism, this is zero changes. Sandy - Would it require changes in the validation software? S Kent - NO. Randy - It would require changes in the BGP path selection in routers? S Kent - Maybe. Ruediger - I would like to have detestation as a way to tell "everything should validate PKI", also in the transition I would like to have detestation for things that I know that should not be there. Dave - Is this the same as BOA? S. Kent. - What it says is that the origin ASN for this prefix is 0. Rob Austein - The issue is the semantic in routing that is a different discussion. Roque - Ruediger mentioned that want to have a detestation mechanism, the question is what is he expecting from the RIR when generating ROA ASN=0 or BOA, that impacts our registration software and may have consequences in time to route. Presentation by Stephen Kent from BBN - Certificate Policy document: draft-ietf-sidr-cp-04.txt Thanks comments. Stephen explained the meaning of the CP document and particularly pointed out that this is the one document every party in RPKI agrees to. Changes from version 03: - inclusion of "bogon" route. possibility of different signed objects (not just ROA). Randy: do we need an RFC? Stephen: not in the current text. Randy: So I have to agree to accept signed objects that I do not know its semantics? Stephen: CP area about issuing Certs by CA. Randy: What contract am I making? Stephen: There is no responsibility of the issuer of the Certs on what it is used to signed. You cannot control what the end users do, you can point out what the intend is: routing security. Randy: Do not have problem to make this distinction. Stephen: will take it to the mailing list. - Change Cert. Authorities, added IANA. CP will be co-adminitrated by IANA and the five RIRs. Mark: You gave it to the RIR and you asked for feedback, what is next? Stephen: Would like more participation from the RIR. And listen to their feedback. Randy: Why does the document mentions "default-trust-anchor" that is something that relying party decides. Stephen: It is normal practice to have that information in the CP, the "normally used" but yes the RP may decide. Randy: As it is a touchy issue, please finesse it. Stephen: Will try. Paul Hoffman: We need this, as it is common practice in every CP. RP will like to have as much information as possible in the CP document. Danny McPherson: There are implications on the decision of the trust anchors and would like to have discussion in the IETF. Stephen: I have some slides. - Key changeover. Includes ISP/LIR, etc. Randy: there are also LIR to sub-LIR, needs to get the appropriate text here. - 6.3.2 trying to explain why the RIR cert change periodically while IANA do not, but the language needs to be modified. - Trust anchor material, showed the current practice. Check the new version of the CERT Profile draft. End of Presentation. Question section: Andrei - I apologize for the lack of feedback. The problem is that it is "tricky". Our legal team is checking it, for the time it takes I can see it is not a simple thing. I also believe that the doc. goes to issues that are still "hot discussions". Example, re-allocation policies are still under discussion. Another thing it states that the use is "secure routing", but the trust is that we are talking about "right of use". Can we put it in one page document? we are talking about different laws, etc. Stephen - This is the formal for all PKI. You are correct it is not trivial. If you want to make changes, we are open to receive them. Not a lot of feedback yet. Can we make it in one page document, NO. You need to ask people that already reviewed a CP before to check it. Andrei - The problem is that the standard template takes you to area you do not want to go. Stephen - We can have sections that can be moved from the CP to the CPS which can be regionalized. Andrei - This is an IETF doc. What would be the status after approved? Stephen - After approval will be publicly available. Randy - Check DNS, for DNSSEC is not PKI and do not need a CP. For Andrei, the CP is for relying parties to tell them what we are telling them they can rely on. Feels Sympathy on the concerns but as a RP likes having CP. Russ - One of the reason for having this document agreed by all the parties is that all the material refers to a policy document, and this is that document. Danny - Can you explain your comment to RFC3779 and trust anchors? Stephen - When validating prefixes and ASNs you need on the top a self-signed cert, with RFC3779 extension, not any CA cert. C) New Drafts section: 1) Presentation by John Mohapatra - Juniper: draft-pmohapat-sidr-pfx-validate-00.txt The idea is: given RPKI, what can the router really do? A work in progress, several contributions received. Need a mechanism to differentiate between invalid and legitimate prefixes been announced. Maintain in POP authenticated prefix and AS cache database. You can also have a database inside the router. The drat talks about the database structure. BGP decision process changed to compare the lookup result before LOCAL_PREF. iBGP vs eBGP: No validation on iBGP sessions. Can we do it in real time? looking to performance issues. There may be an overlap with the roa validation document: the draft started from a different angle, what can we really do?, finished with something that has similarities with the roa validation draft. However there are differences: no "linked validation", #states for validation outcomes, BGP Speaker validation dissociated from Database, can work with any database (or data-source), ex RPLS. Future Work: Work on the protocol bits for interaction in-PoP database and in-Speaker database.Also, Talking with the roa validation draft authors to check for possible merge. Danny - Validation side: What about protecting against hijacking a more specific? John - Anything that can be expressed by a ROA can use this mechanism. Danny - What about ASN spoofing? John - Yep that is a problem. Danny - What about soft-reconfiguration, rate limit for the connection to the database, that is something that needs to be deal with. Should I store prefixes that I know are false? Need some guidance in the doc about what to store and implications. Randy - Have serious question about scaling issues. Want to hear about what gears are going to be used. The size of the router that you expects is critical. John - This is a policy mechanism. Ward - The protocol to the BGP Speaker and the PoP Database is it part of the WG work?. I believe so. Sandy - Need to check the charter or include it in the charter. 2) Presenation by Robert Kisteleki from RIPE NCC - (draft-kisteleki-sidr-rpsl-sig-00.txt). Use of RPKI signatures to sign RPSL object. Not specific to one object type. Can have multiple signature and that is helpful for route objects when you can sign by the prefix and the ASN authoritative party. Signature in RPSL "like" format to feed back the database. Some canonization examples shown. Signature formats: chose DKIM format. Where to put the signature? "remarks: Signature is" or new attribute: "signature", may be problem with some legacy software. Example given. Open questions: Multiple signatures? Unicode? Sync with other people that are thinking on the same line. Is there support in the Working Group? Randy - I believe this is valid work however not the proper working group. have too much work here. Sandy - Which WG should be? Randy - Not recommendation. Haas - This looks like another WG. Randy - We are having problem getting our work out. Henk - Some time ago did some RPSL work and were by individual submission. Danny - Need Charter discuss. Geoff (form jabber) - As co-chair I am in favor of picking up this document. Thanks for staying late. Adjourned. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Dec 18 15:45:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31233A687F; Thu, 18 Dec 2008 15:45:02 -0800 (PST) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BEFE328C0EB; Thu, 18 Dec 2008 15:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081218234501.BEFE328C0EB@core3.amsl.com> Date: Thu, 18 Dec 2008 15:45:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpsl-sig-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --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 : Securing RPSL Objects with RPKI Signatures Author(s) : R. Kisteleki, J. Boumans Filename : draft-ietf-sidr-rpsl-sig-00.txt Pages : 11 Date : 2008-12-18 This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpsl-sig-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpsl-sig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-18153823.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Dec 29 10:32:48 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26643A68EF; Mon, 29 Dec 2008 10:32:48 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F6B3A68EF for ; Mon, 29 Dec 2008 10:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6Ozdtq2H8M1 for ; Mon, 29 Dec 2008 10:32:47 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A32993A68A6 for ; Mon, 29 Dec 2008 10:32:47 -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 mBTIWa2Y009540 for ; Mon, 29 Dec 2008 12:32:36 -0600 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 mBTIWb6x016469 for ; Mon, 29 Dec 2008 12:32:37 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.204]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Dec 2008 13:32:36 -0500 Date: Mon, 29 Dec 2008 13:32:36 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 29 Dec 2008 18:32:36.0563 (UTC) FILETIME=[D26D2230:01C969E3] Subject: [sidr] IETF 73 minutes 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org As I have seen no comments on Roque's minutes for IETF 73, I uploaded them without change. The minutes and slides can be viewed at: https://datatracker.ietf.org/meeting/73/materials.html Final corrections to the minutes are due 7 Jan 2009, so I would appreciate any changes being communicated to the list by 5 Jan 2009. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr