From sra@hactrn.net Sun Nov 1 11:46:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1293A691E for ; Sun, 1 Nov 2009 11:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8djdNdABSqF for ; Sun, 1 Nov 2009 11:46:18 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 9935C3A6897 for ; Sun, 1 Nov 2009 11:46:18 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 04E5428441 for ; Sun, 1 Nov 2009 19:46:36 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id AB26022807 for ; Sun, 1 Nov 2009 14:46:36 -0500 (EST) Date: Sun, 01 Nov 2009 14:46:36 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091101194636.AB26022807@thrintun.hactrn.net> Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 19:46:19 -0000 Terry, General comments only, I'm not going to attempt a point by point response on a beautiful autumn Sunday when my kids want to go play minigolf. The combination of TLS and CMS was the result of advice the design group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy and I asked them to review this protocol, back in 2007. The two mechanisms serve different purposes. We use CMS for authentication and authorization (is the entity requesting this action authorized to do so? etc). It's also intended to allow for audit: if one is paranoid, one can archive a copy of every CMS message and use it (along with archived PKI material) to prove at some later date that the action was properly authorized. So I view CMS as the main security mechanism here, and the one that's most closely aligned with the underlying semantics. TLS is present mostly to protect against replay attacks and other naughtiness. Our advisors saw our initial attempts to include replay protection in the CMS-signed XML messages and advised us to use existing technology (ie, TLS) instead, which makes some sense. TLS also provides privacy (which it's not clear we need), and helps to limit denial of service attacks to known entities. At this point, having written my own HTTPS implementation and seeing how weak (read: effectively nonexistant) the concept of a session is in HTTPS, I'm not convinced that TLS is providing all that much in the way of useful replay protection. At this point, though, we do have multiple interoperable implementations of this protocol using TLS, so unless it's actively harmful I'd just as soon leave it alone for now. FWIW, though, at least in my implementation, all the AAA logic is tied to CMS, not TLS. The PKI used for this (both CMS and TLS) is not the RPKI, it's a separate PKI (which the design group has been calling the "BPKI", because it mirrors the business relationships between certificate-generating entities). In the abstract, the BPKI can be anything that both parties to a particular conversation are willing to use, as this is only used in pairwise conversations and doesn't transit to third parties. The main thing is that the parent in a parent-child relationship gets to dictate the BPKI model to be used: this pretty much falls out of the hierarchical nature of the system. So my implementation, at least, has a particular model that I use when I'm the parent, and is (I hope) flexible enough to handle whatever model my parent might be using when I'm the child. I can go into more detail on the model I'm using, but I'm not sure that the WG really needs to sign off on that level of detail. The protocol nesting is tedious but straightforward: IP(TCP(TLS(HTTP(CMS(XML(up-down)))))) As far as different security models between this and the rest of the RPKI system: the difference is less extreme than it might at first appear. Other than the TLS wrapper discussed above, everything is object security, using either CMS or X.509-derived objects which were signed to begin with. Hope this helps. --Rob From trac@tools.ietf.org Sun Nov 1 17:28:49 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A713A689B for ; Sun, 1 Nov 2009 17:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9syyxIbmKrI for ; Sun, 1 Nov 2009 17:28:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E88843A6895 for ; Sun, 1 Nov 2009 17:28:48 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N4ljI-0002hP-Dc; Sun, 01 Nov 2009 17:29:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Mon, 02 Nov 2009 01:29:08 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/sidr/trac/ticket/5 Message-ID: <052.721dbbba40a0815464b01261c80ff0bf@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #5: Nit report - terminology X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:28:49 -0000 #5: Nit report - terminology -----------------------------------+---------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: rescerts-provisioning | Version: Severity: In WG Last Call | Keywords: -----------------------------------+---------------------------------------- naming of actors in this document still assumes that ISPs are the children. children might be RIRs (parent IANA), or end sites (parent ISPs or owning non-end user sites (e.g. business subsidiaries or govt structures)). again, i suggest something like 'parent' and 'child', though i am not strongly attached to those words. randy ---------- Yes, in the context of the definition of terms for this document. Would a global replace of "ISP" with "subject" and "IR" with "issuer" be a sufficient resolution of this discussion? Byron ----------- WG discussion appears to have resulted in the recommendation to change the terms used in the draft from "IR" and "ISP" to "Issuer" and "Subject" respectively. -- Ticket URL: sidr From trac@tools.ietf.org Sun Nov 1 17:38:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4B03A687F for ; Sun, 1 Nov 2009 17:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHoRgwggbh4v for ; Sun, 1 Nov 2009 17:38:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 21A463A6873 for ; Sun, 1 Nov 2009 17:38:02 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N4lsD-0005gR-GX; Sun, 01 Nov 2009 17:38:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Mon, 02 Nov 2009 01:38:21 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/6 Message-ID: <052.9fc77ba469900533131b52ddae35af56@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #6: Nit Report - Architecture document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:38:03 -0000 #6: Nit Report - Architecture document -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- * Section 4.3 Access Protocols " Current efforts to implement a repository system use RSYNC [14] as the single access protocol. RSYNC, as used in this implementation, provides all of the above functionality. A document specifying the conventions for use of RSYNC in the PKI will be prepared." I am not aware of rsync being used to upload/change/delete objects in a repository as a single access protocol. My understanding is that rsync is mandated as one of the protocols for download, and at present, the former modification actions are done using Up/down otherwise known as draft-ietf-sidr-rescerts-provisioning-05. * Section 5. Manifests This section enters the discussion that the repository system is untrusted(sic), and the manifests are needed due to attack risks. Yet this isn't further discussed or fleshed out as to why the repo structure is not trusted and potentially why no further effort is made to have a trustable repo structure irrespective of the attack vectors of an untrusted repository system. Terry -- Ticket URL: sidr From gih@apnic.net Sun Nov 1 17:43:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1A73A695E for ; Sun, 1 Nov 2009 17:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.635 X-Spam-Level: ** X-Spam-Status: No, score=2.635 tagged_above=-999 required=5 tests=[AWL=-5.234, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLtTTm+pSqJ1 for ; Sun, 1 Nov 2009 17:42:40 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id F3C573A67FB for ; Sun, 1 Nov 2009 17:42:39 -0800 (PST) Received: from cpe-124-179-26-251.lns6.ken.bigpond.net.au (CPE-124-179-26-251.lns6.ken.bigpond.net.au [124.179.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id CE134D58BE for ; Mon, 2 Nov 2009 11:44:31 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Mon, 2 Nov 2009 12:42:53 +1100 Message-Id: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:43:06 -0000 Hi, I am opening a two week wg call for comments on the adoption of this document as a working group item. The document is available at: http://www.ietf.org/id/draft-manderson-sidr-usecases-01.txt Please respond, either accept or not accept, by Tues Nov 10 2009. As usual, the rules are that silence does not indicate assent, so please actively reply. If you support adoption of this draft as a working group item, please also indicate whether you will be able to work on the draft (contribute or review). --Geoff From gih@apnic.net Sun Nov 1 17:49:18 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB913A685E for ; Sun, 1 Nov 2009 17:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.507 X-Spam-Level: *** X-Spam-Status: No, score=3.507 tagged_above=-999 required=5 tests=[AWL=-4.362, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwH-65aFW3jn for ; Sun, 1 Nov 2009 17:49:18 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id CC3783A6810 for ; Sun, 1 Nov 2009 17:49:17 -0800 (PST) Received: from cpe-124-179-26-251.lns6.ken.bigpond.net.au (CPE-124-179-26-251.lns6.ken.bigpond.net.au [124.179.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8711AD58BE for ; Mon, 2 Nov 2009 11:51:10 +1000 (EST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: Geoff Huston In-Reply-To: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> Date: Mon, 2 Nov 2009 12:49:33 +1100 Content-Transfer-Encoding: 7bit Message-Id: <8CE242B1-05C5-4550-BB66-1FE76DEA22D6@apnic.net> References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:49:18 -0000 Obviously my skills at elementary addition are to be found wanting! Two weeks from today is Tuesday November 17th. My apologies for any confusion here - this call will run from now until November 17th regards, Geoff On 02/11/2009, at 12:42 PM, Geoff Huston wrote: > Hi, > > I am opening a two week wg call for comments on the adoption of this > document as a working group item. > > The document is available at: > > http://www.ietf.org/id/draft-manderson-sidr-usecases-01.txt > > Please respond, either accept or not accept, by Tues Nov 10 2009. > > As usual, the rules are that silence does not indicate assent, so > please actively reply. > > If you support adoption of this draft as a working group item, > please also indicate whether you will be able to work on the draft > (contribute or review). > > --Geoff > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Sun Nov 1 17:56:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC613A6809 for ; Sun, 1 Nov 2009 17:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 v2ptN87lnSTt for ; Sun, 1 Nov 2009 17:56:19 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id C100A3A67E3 for ; Sun, 1 Nov 2009 17:56:19 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Sun, 1 Nov 2009 17:56:39 -0800 From: Terry Manderson To: Rob Austein , "sidr@ietf.org" Date: Sun, 1 Nov 2009 17:56:37 -0800 Thread-Topic: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt Thread-Index: AcpbLBVuyL+6MJEAQ7Gvd88dAK3FQwAM6DA8 Message-ID: In-Reply-To: <20091101194636.AB26022807@thrintun.hactrn.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 01:56:20 -0000 Hi Rob, On 2/11/09 5:46 AM, "Rob Austein" wrote: >=20 > The combination of TLS and CMS was the result of advice the design > group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy > and I asked them to review this protocol, back in 2007. The two > mechanisms serve different purposes. >=20 > We use CMS for authentication and authorization (is the entity > requesting this action authorized to do so? etc). It's also intended Ack. > to allow for audit: if one is paranoid, one can archive a copy of > every CMS message and use it (along with archived PKI material) to > prove at some later date that the action was properly authorized. So > I view CMS as the main security mechanism here, and the one that's > most closely aligned with the underlying semantics. Right, I also have a similar PoV. Although, and it may be an academic distinction - my reading is that if the XML operations are not truly idempotent then the 'CMS Signing Time' would have been a more pragmatic implementation. Was that analysis done? (apologies if it was, I quickly checked list archives but couldn't see if the question had been asked) >=20 > TLS is present mostly to protect against replay attacks and other > naughtiness. Our advisors saw our initial attempts to include replay > protection in the CMS-signed XML messages and advised us to use o.k. BTW is the rescerts-provisioning-05 RFC4346 is specified. RFC4346 is obsoleted by RFC5246. So if you do authentication and authorisation in the CMS, why do you need 2 way identification at the HTTPS layer if it's just for privacy? ie authentication of both parties versus server authentication with an unauthenticated client? (RFC5246 App F.) > existing technology (ie, TLS) instead, which makes some sense. ... I'm not sure why though.. :-( Maybe you can explain that to me over a beer. > TLS > also provides privacy (which it's not clear we need), and helps to > limit denial of service attacks to known entities. ummm Does it?=20 >=20 > At this point, having written my own HTTPS implementation and seeing > how weak (read: effectively nonexistant) the concept of a session is > in HTTPS, I'm not convinced that TLS is providing all that much in the > way of useful replay protection. > At this point, though, we do have > multiple interoperable implementations of this protocol using TLS, so > unless it's actively harmful I'd just as soon leave it alone for now. Maybe just a refocus on ''why'' TLS is used, and to what extent, given othe= r architecture parts. >=20 > FWIW, though, at least in my implementation, all the AAA logic is tied > to CMS, not TLS. Yes.. and having run your code I see that, which is why I ask some of the questions. >=20 > The PKI used for this (both CMS and TLS) is not the RPKI, it's a > separate PKI (which the design group has been calling the "BPKI", Maybe a clarification then required so people don't start trying to plug RPKI certs into provisioning engines for CMS? > because it mirrors the business relationships between > certificate-generating entities). In the abstract, the BPKI can be > anything that both parties to a particular conversation are willing to > use, as this is only used in pairwise conversations and doesn't > transit to third parties. The main thing is that the parent in a > parent-child relationship gets to dictate the BPKI model to be used: > this pretty much falls out of the hierarchical nature of the system. > So my implementation, at least, has a particular model that I use when > I'm the parent, and is (I hope) flexible enough to handle whatever > model my parent might be using when I'm the child. I can go into > more detail on the model I'm using, but I'm not sure that the WG > really needs to sign off on that level of detail. I think something, at some stage, might need to be documented given that th= e BPKI (as you put it) seems to be a first order layer for the conversation. (although note my comments above about the necessity for 2-way identification given the authentication/authorisation is done in CMS) >=20 > The protocol nesting is tedious but straightforward: >=20 > IP(TCP(TLS(HTTP(CMS(XML(up-down)))))) So, given that ASN.1 is fully capable of describing the data going back and forth (up/down). Why add the extra XML blob? btw, I think the draft needs to also reference the ITU' (nee CCITT) Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)= . >=20 > As far as different security models between this and the rest of the > RPKI system: the difference is less extreme than it might at first > appear. Other than the TLS wrapper discussed above, everything is > object security, using either CMS or X.509-derived objects which were > signed to begin with. thinking from a different point of view - noting that the draft is using HTTPS with identification of server and client, for replay and privacy - wh= y not consider the W3Cs XML Signature Syntax? >=20 > Hope this helps. >=20 Sure does. Hope you had fun playing mini-golf. Terry From randy@psg.com Mon Nov 2 08:09:23 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A781028C10B for ; Mon, 2 Nov 2009 08:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 MqgW3rn7lqyw for ; Mon, 2 Nov 2009 08:09:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id B247F28C0ED for ; Mon, 2 Nov 2009 08:09:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N4zTH-000Jij-Dt; Mon, 02 Nov 2009 16:09:31 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 241B42BDA586; Mon, 2 Nov 2009 11:09:31 -0500 (EST) Date: Mon, 02 Nov 2009 11:09:31 -0500 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-cp-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:09:23 -0000 >>>> Perhaps " Names for IANA and RIRs will be meaningless directory >>>> distinguished ....." >>> We can add some more text to make such this is unambiguous. >>we are consciously not proscribing 'meaningful' names for other IRs? > we are consciously proscribing 'meaningful' names for ALL subjects. > I interpreted Terry's comment to mean that he believed that we were > not clear that this proscription applied to IANA and RIRs as well. cool randy From kent@bbn.com Mon Nov 2 08:25:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2BE3A682E for ; Mon, 2 Nov 2009 08:25: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 IInzE-SLB3TA for ; Mon, 2 Nov 2009 08:25:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 676FB3A689F for ; Mon, 2 Nov 2009 08:25:43 -0800 (PST) Received: from dhcp89-089-021.bbn.com ([128.89.89.21]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N4zS0-00032q-9u; Mon, 02 Nov 2009 11:08:12 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 2 Nov 2009 10:32:12 -0500 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-cp-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:25:44 -0000 At 10:24 AM +0900 10/31/09, Randy Bush wrote: > >> Perhaps " Names for IANA and RIRs will be meaningless directory >>> distinguished ....." >> We can add some more text to make such this is unambiguous. > >we are consciously not proscribing 'meaningful' names for other IRs? > >randy we are consciously proscribing 'meaningful' names for ALL subjects. I interpreted Terry's comment to mean that he believed that we were not clear that this proscription applied to IANA and RIRs as well. Steve From kent@bbn.com Mon Nov 2 08:25:47 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91A13A689F for ; Mon, 2 Nov 2009 08:25:47 -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 hz3EW7nEiUs5 for ; Mon, 2 Nov 2009 08:25:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A7AEE28C15D for ; Mon, 2 Nov 2009 08:25:42 -0800 (PST) Received: from dhcp89-089-021.bbn.com ([128.89.89.21]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N4zS2-00032q-AS for sidr@ietf.org; Mon, 02 Nov 2009 11:08:14 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20091101194636.AB26022807@thrintun.hactrn.net> References: <20091101194636.AB26022807@thrintun.hactrn.net> Date: Mon, 2 Nov 2009 11:07:40 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:25:47 -0000 Folks, I want to add a few comments to Rob's message about use of CMS and TLS for the up/down protocol. As Rob noted, Russ and I suggested this combination of protocols for use here. CMS provides the base security for transactions, affording integrity and authenticity via the signature applied to the CMS payload. TLS offers an opportunity to implement a coarse level of access control, and session-level integrity, authentication, and anti-replay, with confidentiality as a side-effect (that may or may not be needed). I am not sure what motivates Rob to say that he is not convinced about the extent of the session security offered by HTTPS. (Is it related to the session resumption feature in TLS?) Anyway, by using TLS one can restrict access to repository serves to the set of entities to whom certs have been issued in the BPKI, which is potentially helpful. Steve From sra@hactrn.net Mon Nov 2 08:49:38 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D1728C153 for ; Mon, 2 Nov 2009 08:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce9vavwEbDvZ for ; Mon, 2 Nov 2009 08:49:38 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id E863B28C156 for ; Mon, 2 Nov 2009 08:49:37 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 9CD9728441 for ; Mon, 2 Nov 2009 16:49:56 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1E29B22807 for ; Mon, 2 Nov 2009 11:49:56 -0500 (EST) Date: Mon, 02 Nov 2009 11:49:55 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20091101194636.AB26022807@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091102164956.1E29B22807@thrintun.hactrn.net> Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:49:39 -0000 At Sun, 1 Nov 2009 17:56:37 -0800, Terry Manderson wrote: > > > to allow for audit: if one is paranoid, one can archive a copy of > > every CMS message and use it (along with archived PKI material) to > > prove at some later date that the action was properly authorized. So > > I view CMS as the main security mechanism here, and the one that's > > most closely aligned with the underlying semantics. > > Right, I also have a similar PoV. Although, and it may be an academic > distinction - my reading is that if the XML operations are not truly > idempotent then the 'CMS Signing Time' would have been a more pragmatic > implementation. Don't think I follow. CMS profile for this draft specifies use of signing time (and, optionally, binary time). You need a signature that covers both the timestamp and the dated material to be audited, which this profile provides. Am I missing something? > So if you do authentication and authorisation in the CMS, why do you need 2 > way identification at the HTTPS layer if it's just for privacy? TLS without checking signatures gives you a secure channel to an unknown entity. Professor Moriarty speaks TLS too. > > The protocol nesting is tedious but straightforward: > > > > IP(TCP(TLS(HTTP(CMS(XML(up-down)))))) > > So, given that ASN.1 is fully capable of describing the data going back and > forth (up/down). Why add the extra XML blob? Primarily because there is running code using XML, secondarily because XML is somewhat easier to code and debug. > thinking from a different point of view - noting that the draft is > using HTTPS with identification of server and client, for replay and > privacy - why not consider the W3Cs XML Signature Syntax? Considered and rejected, because it's broken. The XML world doesn't really have the concept of a single canonical format, and the attempt to reconcile that world view with the requirements of digital signatures resulted in a protocol in which otherwise valid signatures can fail to validate because of disagreements about the canonical form of the signed data. From kotikalapudi.sriram@nist.gov Mon Nov 2 09:00:11 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F1028C12C for ; Mon, 2 Nov 2009 09:00:11 -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 6iq1sWbOQWV7 for ; Mon, 2 Nov 2009 09:00:09 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 775A83A6A61 for ; Mon, 2 Nov 2009 09:00:09 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA2H0FOr004067 for ; Mon, 2 Nov 2009 12:00:15 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Mon, 2 Nov 2009 12:00:09 -0500 From: "Sriram, Kotikalapudi" To: "sidr@ietf.org" Date: Mon, 2 Nov 2009 12:00:14 -0500 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: AcoaleygDsqS59PwRrm7UTq9gWVMjhBRpK4g Message-ID: References: <20090811143335.055773F463@pecan.tislabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:00:11 -0000 Comments on the -03 version: Section 4.1 is a bit confusing because it does not seem to take ROA prefix = maxlength into consideration or fails to make any mention of it. Several of= the statements in this section do not make it clear what implication maxle= ngth has on prefix matching. For example, does definition of "covering agg= regate" include the case when the update (route) prefix length is longer th= an maxlength? In my understanding, ROA prefix is not a _covering_ aggregate= if the update prefix length exceeds maxlength, unless purposefully defined= otherwise. "Covering Aggregate" should be clearly defined in Section 2, ex= plicitly stating what role maxlength plays, before getting into any descrip= tion of algorithms.=20 In my opinion, Section 2 already provides coverage for partial deployment f= or the case of prefixes that are not included in any ROA. Steps 1 and 2 of = the algorithm on page 4 take care of this case of partial deployment. So ha= ving a modified algorithm in Section 4 seems redundant. The discussion part= of Section 4 is relevant and can be suitably edited and moved to Section 2= .=20 The algorithm in this ID and also that in draft-pmohapat-sidr-pfx-validate-= 03 do not cover another case of partial deployment where suballocations leg= itimately originate from a different AS and while a parent prefix has a ROA= with ISP's AS origin, the suballocation (customer's) has no ROA registered= yet. Please see slide 4 in link below (I had emailed this to SIDR list soo= n after the SIDR WG meeting in Stockholm): http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf=20 I admit that I am a bit torn about how to cater to this type of partial dep= loyment condition. One way out is to have a deadline prior to which the val= idation decisions would be soft ("unknown") for this case and then the hard= decision ("invalid") kicks in after the deadline (again see my slides; use= of BOA may be helpful but not essential as discussed in my slide #6).=20 There is substantial commonality in the problem space addressed as well as = the solution (algorithm) described between the two documents: draft-pmohapa= t-sidr-pfx-validate-03 and draft-ietf-sidr-roa-validation-03. Sriram K. Sriram +1 301 975 3793 http://www.antd.nist.gov/~ksriram/ From kotikalapudi.sriram@nist.gov Mon Nov 2 09:11:35 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33D413A6A1B for ; Mon, 2 Nov 2009 09:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 e55sJCqOulAd for ; Mon, 2 Nov 2009 09:11:34 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id E04753A68E7 for ; Mon, 2 Nov 2009 09:11:33 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA2HBjf2004365 for ; Mon, 2 Nov 2009 12:11:45 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 2 Nov 2009 12:11:45 -0500 From: "Sriram, Kotikalapudi" To: "sidr@ietf.org" Date: Mon, 2 Nov 2009 12:11:44 -0500 Thread-Topic: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document Thread-Index: AcpZeRJOWf8qcwXJSPGj1FSLDJuM+QCZWNAg Message-ID: References: <4AEA821D.7040305@apnic.net> <4AEB07E9.7010107@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:11:35 -0000 At the end of Section 4, you may consider adding a sentence to the effect: = It is expected that the AGGREGATOR AS will have a ROA registered that permi= ts the AGGREGATOR AS to originate the aggregate prefix.=20 The following comments are similar to what I have observed for draft-ietf-s= idr-roa-validation-03: There is substantial commonality in the problem space addressed as well as = the solution (algorithm) described between the two documents: draft-pmohapa= t-sidr-pfx-validate-03 and draft-ietf-sidr-roa-validation-03. The algorithm in this ID and also that in draft-ietf-sidr-roa-validation-03= do not cover another case of partial deployment where suballocations legit= imately originate from a different AS and while a parent prefix has a ROA w= ith ISP's AS origin, the suballocation (customer's) has no ROA registered y= et. Please see slide 4 in link below (I had emailed this to SIDR list soon = after the SIDR WG meeting in Stockholm): http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf=20 I must admit that I am a bit torn about how to cater to this type of partia= l deployment condition. One way out is to have a deadline prior to which th= e validation decisions would be soft ("not found") for this case and then t= he hard decision ("invalid") kicks in after the deadline (again see my slid= es; use of BOA or ROA with AS0 may be helpful but not essential as discusse= d in my slides 5 and 6).=20 Sriram K. Sriram +1 301 975 3793 http://www.antd.nist.gov/~ksriram/=20 From sra@hactrn.net Mon Nov 2 09:19:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CF53A68DB for ; Mon, 2 Nov 2009 09:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlJ63NI-IrMV for ; Mon, 2 Nov 2009 09:19:05 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 7E7933A68D0 for ; Mon, 2 Nov 2009 09:19:05 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 4D0222847E for ; Mon, 2 Nov 2009 17:19:25 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D38A722807 for ; Mon, 2 Nov 2009 12:19:24 -0500 (EST) Date: Mon, 02 Nov 2009 12:19:24 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20091101194636.AB26022807@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091102171924.D38A722807@thrintun.hactrn.net> Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 17:19:06 -0000 At Mon, 2 Nov 2009 11:07:40 -0500, Steve Kent wrote: > > I am not sure what motivates Rob to say that he is not convinced > about the extent of the session security offered by HTTPS. (Is it > related to the session resumption feature in TLS?) Nope. It's related to HTTP not really having any such thing as a session to protect. It is of course possible that we all (or perhaps just I) misunderstood your advice, in which case please expound. From ljb@merit.edu Mon Nov 2 10:40:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C0203A63EB for ; Mon, 2 Nov 2009 10:40:56 -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 gY0PLo0N9FaX for ; Mon, 2 Nov 2009 10:40:52 -0800 (PST) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id AB4D028C1B9 for ; Mon, 2 Nov 2009 10:40:52 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMe27krGbD6X/2dsb2JhbADQEgEJhHmITIJTgWkE X-IronPort-AV: E=Sophos;i="4.44,668,1249272000"; d="scan'208";a="16927061" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Nov 2009 13:41:12 -0500 Message-ID: <4AEF27C8.5050502@merit.edu> Date: Mon, 02 Nov 2009 13:41:12 -0500 From: Larry Blunk User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: <4AEA821D.7040305@apnic.net> <4AEB07E9.7010107@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 18:40:56 -0000 Sriram, Kotikalapudi wrote: > At the end of Section 4, you may consider adding a sentence to the effect: It is expected that the AGGREGATOR AS will have a ROA registered that permits the AGGREGATOR AS to originate the aggregate prefix. > > The following comments are similar to what I have observed for draft-ietf-sidr-roa-validation-03: > > There is substantial commonality in the problem space addressed as well as the solution (algorithm) described between the two documents: draft-pmohapat-sidr-pfx-validate-03 and draft-ietf-sidr-roa-validation-03. > > The algorithm in this ID and also that in draft-ietf-sidr-roa-validation-03 do not cover another case of partial deployment where suballocations legitimately originate from a different AS and while a parent prefix has a ROA with ISP's AS origin, the suballocation (customer's) has no ROA registered yet. Please see slide 4 in link below (I had emailed this to SIDR list soon after the SIDR WG meeting in Stockholm): > http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf > I must admit that I am a bit torn about how to cater to this type of partial deployment condition. One way out is to have a deadline prior to which the validation decisions would be soft ("not found") for this case and then the hard decision ("invalid") kicks in after the deadline (again see my slides; use of BOA or ROA with AS0 may be helpful but not essential as discussed in my slides 5 and 6). > > Sriram > K. Sriram > +1 301 975 3793 > http://www.antd.nist.gov/~ksriram/ > _______________________________________________ > I don't find the partial deployment scenario to be particularly compelling. I'm having difficulty seeing many providers issuing EE Cert's to customers for sub-allocations from the provider's address space. The common case will likely be providers creating ROA's themselves for their sub-allocated multi-homing customer space. If you are creating a ROA for the aggregate, why would you not also create ROA's for the more specifics at the same time? In the few cases where a provider may issue an EE Cert to the customer, it seems unlikely they would issue one before a customer is ready to create ROA's. This is not like DNSSEC where there are existing delegation chains to deal with -- it's greenfield. Given the whole point of EE Cert's is to create ROA's, why would you request one if you were not prepared to create ROA's. -Larry From Sandra.Murphy@cobham.com Mon Nov 2 12:15:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA89D3A68D8 for ; Mon, 2 Nov 2009 12:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 ofn3-VvURUuD for ; Mon, 2 Nov 2009 12:15:02 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5AB3E3A68C7 for ; Mon, 2 Nov 2009 12:15:02 -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 nA2KFL8v022439; Mon, 2 Nov 2009 14:15:21 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA2KFL9m014354; Mon, 2 Nov 2009 14:15:21 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.77]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 15:15:21 -0500 Date: Mon, 2 Nov 2009 16:15:21 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Larry Blunk In-Reply-To: <4AEF27C8.5050502@merit.edu> Message-ID: References: <4AEA821D.7040305@apnic.net> <4AEB07E9.7010107@joelhalpern.com> <4AEF27C8.5050502@merit.edu> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Nov 2009 20:15:21.0429 (UTC) FILETIME=[34340850:01CA5BF9] Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 20:15:03 -0000 On Mon, 2 Nov 2009, Larry Blunk wrote: > Sriram, Kotikalapudi wrote: >> At the end of Section 4, you may consider adding a sentence to the effect: >> It is expected that the AGGREGATOR AS will have a ROA registered that >> permits the AGGREGATOR AS to originate the aggregate prefix. >> The following comments are similar to what I have observed for >> draft-ietf-sidr-roa-validation-03: >> >> There is substantial commonality in the problem space addressed as well as >> the solution (algorithm) described between the two documents: >> draft-pmohapat-sidr-pfx-validate-03 and draft-ietf-sidr-roa-validation-03. >> >> The algorithm in this ID and also that in draft-ietf-sidr-roa-validation-03 >> do not cover another case of partial deployment where suballocations >> legitimately originate from a different AS and while a parent prefix has a >> ROA with ISP's AS origin, the suballocation (customer's) has no ROA >> registered yet. Please see slide 4 in link below (I had emailed this to >> SIDR list soon after the SIDR WG meeting in Stockholm): >> http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf I must >> admit that I am a bit torn about how to cater to this type of partial >> deployment condition. One way out is to have a deadline prior to which the >> validation decisions would be soft ("not found") for this case and then the >> hard decision ("invalid") kicks in after the deadline (again see my slides; >> use of BOA or ROA with AS0 may be helpful but not essential as discussed in >> my slides 5 and 6). >> Sriram >> K. Sriram >> +1 301 975 3793 >> http://www.antd.nist.gov/~ksriram/ >> _______________________________________________ >> > > I don't find the partial deployment scenario to be > particularly compelling. I'm having difficulty > seeing many providers issuing EE Cert's to customers for > sub-allocations from the provider's address space. The > common case will likely be providers creating ROA's themselves > for their sub-allocated multi-homing customer space. If you are > creating a ROA for the aggregate, why would you not also > create ROA's for the more specifics at the same time? I don't understand your comment. The architecture talks about providers issuing CA-certs for its customers, not EE-certs. Is the EE-cert vs CA-cert distinction important to your point? I ask, because depending on your view, one might say that a provider would *never* issue an EE-cert to its customer. If the customer is capable of doing RPKI things, the provider would issue the CA-cert to the customer then the customer would issue the EE-cert and sign the ROA. If the customer was not capable, then the provider is the one that would both issue the EE-cert and sign the ROA. If a customer is multi-homed, then then there is a route through another provider. That route may appear with the customer's AS as the origin or with another provider's AS listed as the origin. Are you suggesting that the clueless customer's provider would sign a ROA for just its own AS to originate the more specific prefix? For the customer's AS to originate the more specific prefix? For the other provider to originate the more specific prefix? > > In the few cases where a provider may issue an EE Cert to > the customer, it seems unlikely they would issue > one before a customer is ready to create ROA's. This > is not like DNSSEC where there are existing delegation > chains to deal with -- it's greenfield. Given the whole > point of EE Cert's is to create ROA's, why would you request > one if you were not prepared to create ROA's. > Again, if the customer is ready to create ROAs, then I'm not sure why you are saying that the provider would issue an EE-cert to the customer. Are you suggesting that the customer would be ready to sign ROAs but not issue its own EE-cert from a CA-cert issued by its provider? If you mean CA-cert, then I agree that a provider may not issue a CA-cert for the more specific when the customer is not ready to sign ROAs. The provider can issue an EE-cert for the more specific under its own CA-cert. And if the customer is ready to sign ROAs then the provider will (if willing) issue a CA-cert for the customer. Of course, the partial deployment issue is what we are going to do with the customer is not ready for RPKI activity. Looking at this a couple of times, I'm still not sure what you mean here. > > -Larry > > > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From ljb@merit.edu Mon Nov 2 12:59:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC833A6A3C for ; Mon, 2 Nov 2009 12:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.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 YzZlF9StI90x for ; Mon, 2 Nov 2009 12:59:28 -0800 (PST) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id E9C263A697E for ; Mon, 2 Nov 2009 12:59:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id F22A42254D0; Mon, 2 Nov 2009 15:59:47 -0500 (EST) X-Virus-Scanned: amavisd-new at magus.merit.edu Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcJI+Bj7L6LQ; Mon, 2 Nov 2009 15:59:47 -0500 (EST) Received: from crono.merit.edu (crono.merit.edu [198.108.1.12]) by magus.merit.edu (Postfix) with ESMTP id 463562252D2; Mon, 2 Nov 2009 15:59:47 -0500 (EST) Date: Mon, 2 Nov 2009 15:59:47 -0500 (EST) From: "Larry J. Blunk" To: Sandra Murphy Message-ID: <742173602.6653341257195587203.JavaMail.root@crono> In-Reply-To: <1512357819.6652881257195497426.JavaMail.root@crono> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [198.108.1.13] X-Mailer: Zimbra 5.0.18_GA_3011.SLES10_64 (ZimbraWebClient - FF3.0 (Win)/5.0.18_GA_3011.SLES10_64) Cc: Kotikalapudi Sriram , sidr@ietf.org Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 20:59:29 -0000 ----- "Sandra Murphy" wrote: > On Mon, 2 Nov 2009, Larry Blunk wrote: > > > Sriram, Kotikalapudi wrote: > >> At the end of Section 4, you may consider adding a sentence to the > effect: > >> It is expected that the AGGREGATOR AS will have a ROA registered > that > >> permits the AGGREGATOR AS to originate the aggregate prefix. > >> The following comments are similar to what I have observed for > >> draft-ietf-sidr-roa-validation-03: > >> > >> There is substantial commonality in the problem space addressed as > well as > >> the solution (algorithm) described between the two documents: > >> draft-pmohapat-sidr-pfx-validate-03 and > draft-ietf-sidr-roa-validation-03. > >> > >> The algorithm in this ID and also that in > draft-ietf-sidr-roa-validation-03 > >> do not cover another case of partial deployment where > suballocations > >> legitimately originate from a different AS and while a parent > prefix has a > >> ROA with ISP's AS origin, the suballocation (customer's) has no ROA > > >> registered yet. Please see slide 4 in link below (I had emailed > this to > >> SIDR list soon after the SIDR WG meeting in Stockholm): > >> http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf I > must > >> admit that I am a bit torn about how to cater to this type of > partial > >> deployment condition. One way out is to have a deadline prior to > which the > >> validation decisions would be soft ("not found") for this case and > then the > >> hard decision ("invalid") kicks in after the deadline (again see my > slides; > >> use of BOA or ROA with AS0 may be helpful but not essential as > discussed in > >> my slides 5 and 6). > >> Sriram > >> K. Sriram > >> +1 301 975 3793 > >> http://www.antd.nist.gov/~ksriram/ > >> _______________________________________________ > >> > > > > I don't find the partial deployment scenario to be > > particularly compelling. I'm having difficulty > > seeing many providers issuing EE Cert's to customers for > > sub-allocations from the provider's address space. The > > common case will likely be providers creating ROA's themselves > > for their sub-allocated multi-homing customer space. If you are > > creating a ROA for the aggregate, why would you not also > > create ROA's for the more specifics at the same time? > > I don't understand your comment. > > The architecture talks about providers issuing CA-certs for its customers, > not EE-certs. Is the EE-cert vs CA-cert distinction important to your > point? > > I ask, because depending on your view, one might say that a provider would > *never* issue an EE-cert to its customer. If the customer is capable of > doing RPKI things, the provider would issue the CA-cert to the customer > then the customer would issue the EE-cert and sign the ROA. If the > customer was not capable, then the provider is the one that would both > issue the EE-cert and sign the ROA. Sorry, got my cert's mixed up. I meant that I suspect most providers will not issue CA-cert's to customers. > > If a customer is multi-homed, then then there is a route through another > provider. That route may appear with the customer's AS as the origin or > with another provider's AS listed as the origin. Yes, multi-origin multi-homing happens, but the general case is single origin multi-homing. So the common case will be signing a ROA for that single origin which is unlikely to change. > > Are you suggesting that the clueless customer's provider would sign a ROA > for just its own AS to originate the more specific prefix? For the > customer's AS to originate the more specific prefix? For the other > provider to originate the more specific prefix? If you are using PA space to multihome, then you are going to have to play by the provider's rules. If the provider does not allow multihoming using their space, that's their right. You can either get PI space or get another provider. Do you think clueless customers will want to deal with signing ROA's? In most cases, I suspect not. If a provider allows customers to multi-home from the provider's address space, it seems eminently reasonable that they would also be willing to sign ROA's for that space with the customer's AS. Why wouldn't they? In the case of multi-origin multi-homing using PA space, you are talking about a very small subset. For the providers who allow such configurations, yes I fully expect them to sign the ROA's. Be aware that many providers will simply tell customers to go get their own AS and/or their own PI space. -Larry > > > > > > > In the few cases where a provider may issue an EE Cert to > > the customer, it seems unlikely they would issue > > one before a customer is ready to create ROA's. This > > is not like DNSSEC where there are existing delegation > > chains to deal with -- it's greenfield. Given the whole > > point of EE Cert's is to create ROA's, why would you request > > one if you were not prepared to create ROA's. > > > > Again, if the customer is ready to create ROAs, then I'm not sure why > you > are saying that the provider would issue an EE-cert to the customer. > Are > you suggesting that the customer would be ready to sign ROAs but not > issue > its own EE-cert from a CA-cert issued by its provider? > > If you mean CA-cert, then I agree that a provider may not issue a > CA-cert > for the more specific when the customer is not ready to sign ROAs. > The > provider can issue an EE-cert for the more specific under its own > CA-cert. > And if the customer is ready to sign ROAs then the provider will (if > willing) issue a CA-cert for the customer. > > Of course, the partial deployment issue is what we are going to do > with > the customer is not ready for RPKI activity. > > Looking at this a couple of times, I'm still not sure what you mean > here. > > > > > > > -Larry > > > > > > > > > > > > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > From Sandra.Murphy@cobham.com Mon Nov 2 13:09:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4083A6808 for ; Mon, 2 Nov 2009 13:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 dn7AsQ0nstNy for ; Mon, 2 Nov 2009 13:09:04 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B633A3A67E7 for ; Mon, 2 Nov 2009 13:09:04 -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 nA2L9Oqd023591; Mon, 2 Nov 2009 15:09:24 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA2L9Mni017106; Mon, 2 Nov 2009 15:09:24 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.77]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 16:09:22 -0500 Date: Mon, 2 Nov 2009 17:09:21 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Larry J. Blunk" In-Reply-To: <742173602.6653341257195587203.JavaMail.root@crono> Message-ID: References: <742173602.6653341257195587203.JavaMail.root@crono> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Nov 2009 21:09:22.0216 (UTC) FILETIME=[BFDCE280:01CA5C00] Cc: Kotikalapudi Sriram , sidr@ietf.org Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:09:05 -0000 On Mon, 2 Nov 2009, Larry J. Blunk wrote: > > ----- "Sandra Murphy" wrote: > >> On Mon, 2 Nov 2009, Larry Blunk wrote: >> >>> Sriram, Kotikalapudi wrote: > > If you are using PA space to multihome, > then you are going to have to play by the provider's rules. > If the provider does not allow multihoming using their > space, that's their right. You can either get PI > space or get another provider. Do you think clueless > customers will want to deal with signing ROA's? In > most cases, I suspect not. If a provider allows customers > to multi-home from the provider's address space, it seems eminently > reasonable that they would also be willing to sign ROA's > for that space with the customer's AS. Why wouldn't they? > > In the case of multi-origin multi-homing using PA > space, you are talking about a very small subset. > For the providers who allow such configurations, yes > I fully expect them to sign the ROA's. Be aware that > many providers will simply tell customers to go get > their own AS and/or their own PI space. This fits my model and what several others have suggested as well. What is your opinion of a level down from there - clueless customers multihomed clueless customers? I've heard that while a relationship exists between provider and customer, that's not likely between provider and customer's customers through which the ROAs could be requested or automatically created on certain events. (Not expressing an opinion here, just exploring the wg's opinion.) --Sandy > > -Larry > > > >> From kent@bbn.com Mon Nov 2 13:45:27 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 660103A682B for ; Mon, 2 Nov 2009 13:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KMxbG0DPB8Gb for ; Mon, 2 Nov 2009 13:45:26 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9974C3A67A2 for ; Mon, 2 Nov 2009 13:45:26 -0800 (PST) Received: from dhcp89-089-021.bbn.com ([128.89.89.21]:49187) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N54if-0005pC-BR; Mon, 02 Nov 2009 16:45:45 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20091102171924.D38A722807@thrintun.hactrn.net> References: <20091101194636.AB26022807@thrintun.hactrn.net> <20091102171924.D38A722807@thrintun.hactrn.net> Date: Mon, 2 Nov 2009 16:45:37 -0500 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 21:45:27 -0000 At 12:19 PM -0500 11/2/09, Rob Austein wrote: >At Mon, 2 Nov 2009 11:07:40 -0500, Steve Kent wrote: >> >> I am not sure what motivates Rob to say that he is not convinced >> about the extent of the session security offered by HTTPS. (Is it >> related to the session resumption feature in TLS?) > >Nope. It's related to HTTP not really having any such thing as a >session to protect. It is of course possible that we all (or perhaps >just I) misunderstood your advice, in which case please expound. In the TLS context I think of a session as the set of traffic sent after the TLS handshake completes and before a new handshake occurs, between the same pair of IP addresses. Yes, there is no explicit end of session message in TLS, which makes it hard to define the end of a session. However, if a server times out an inactive session, the client will need to perform a handshake to re-establish it, so there is an opportunity for the server to unilaterally end a session at any time. Since the goal of using TLS here is to help protect servers, this seems like a reasonable strategy. (And as I noted above, a session resumption request by a client can always be rejected by a server.) Any received traffic that is not protected under the keys established at the start of the session will be rejected. I assume that a new handshake should cause the old keys to be replaced. So the server is well-positioned to decide when a session has ended. Is your point is that the handshake imposes a crypto processing burden on the server, and that this reduces the DoS benefits? Note that there there are a number of hardware options available to off-load the processing associated with the handshake. Steve From sra@hactrn.net Mon Nov 2 14:23:13 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39523A6831 for ; Mon, 2 Nov 2009 14:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZJsQX9d2XQl for ; Mon, 2 Nov 2009 14:23:12 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 66AF73A67A8 for ; Mon, 2 Nov 2009 14:23:12 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id B12F328441 for ; Mon, 2 Nov 2009 22:23:31 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6CEEC22807 for ; Mon, 2 Nov 2009 17:23:31 -0500 (EST) Date: Mon, 02 Nov 2009 17:23:31 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20091101194636.AB26022807@thrintun.hactrn.net> <20091102171924.D38A722807@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091102222331.6CEEC22807@thrintun.hactrn.net> Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 22:23:13 -0000 At Mon, 2 Nov 2009 16:45:37 -0500, Steve Kent wrote: > > At 12:19 PM -0500 11/2/09, Rob Austein wrote: > >At Mon, 2 Nov 2009 11:07:40 -0500, Steve Kent wrote: > >> > >> I am not sure what motivates Rob to say that he is not convinced > >> about the extent of the session security offered by HTTPS. (Is it > >> related to the session resumption feature in TLS?) > > > >Nope. It's related to HTTP not really having any such thing as a > >session to protect. It is of course possible that we all (or perhaps > >just I) misunderstood your advice, in which case please expound. > > In the TLS context I think of a session as the set of traffic sent > after the TLS handshake completes and before a new handshake occurs, > between the same pair of IP addresses. Yes, there is no explicit end > of session message in TLS, which makes it hard to define the end of a > session. However, if a server times out an inactive session, the > client will need to perform a handshake to re-establish it, so there > is an opportunity for the server to unilaterally end a session at any > time. Since the goal of using TLS here is to help protect servers, > this seems like a reasonable strategy. (And as I noted above, a > session resumption request by a client can always be rejected by a > server.) Any received traffic that is not protected under the keys > established at the start of the session will be rejected. I assume > that a new handshake should cause the old keys to be replaced. So the > server is well-positioned to decide when a session has ended. I think we are talking slightly past each other, and have been on this topic all along. I said "HTTP", you seem to have read "TLS". HTTP has no real notion of a session. Even with persistent HTTP connections, the server is free to blow away the connection after the first request/response cycle completes. There's some attempt at letting the server tell the client what timer value the server is using, but between the mishmash of HTTP versions doing things different ways and the ad hoc nature of early attempts to support persistent connections, the advice I was able to find all said to ignore that. So all a client can really do is request a persistent connection if for some reason it wants one, and hope for the best. This means that a client can't rely on the server ever leaving the connection open for more than one request/response cycle, so the notion of insisting that a series of request/response cycles MUST happen in the same "session" to avoid replay is a bad fit. Wrapping HTTP in TLS doesn't fix HTTP's weird semantics. Most web-based protocols that implement sessions do so on top of this entire mess, using cookies or URL tricks or application data. At the moment we're not doing any of that. Remember that the reason we were originally told to use TLS here was replay protection. I know you keep saying server protection, but that's not how we originally got here. I'm not seeing much replay protection in what we've implemented to date, which concerns me, as we added a fairly heavyweight mechanism that as far as I can tell has not solved the original problem. My implementation uses OpenSSL's TLS code directly, thus I could, in theory, peek at TLS session data structures and hook into OpenSSL's TLS callbacks to figure out whether this is the same TLS session or not, using your definition of "session" (above). Sounds a bit painful, but is probably doable. Question is whether it's worth it, or whether there's some better way to handle the threats. I'll let APNIC speak to how much of a problem this would be for them. From kent@bbn.com Mon Nov 2 14:57:36 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE02F3A684A for ; Mon, 2 Nov 2009 14:57:36 -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 hhEgvgDfMEiS for ; Mon, 2 Nov 2009 14:57:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 70F543A6823 for ; Mon, 2 Nov 2009 14:57:35 -0800 (PST) Received: from dhcp89-089-021.bbn.com ([128.89.89.21]:49196) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N55qU-0007LT-Bt; Mon, 02 Nov 2009 17:57:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20091102222331.6CEEC22807@thrintun.hactrn.net> References: <20091101194636.AB26022807@thrintun.hactrn.net> <20091102171924.D38A722807@thrintun.hactrn.net> <20091102222331.6CEEC22807@thrintun.hactrn.net> Date: Mon, 2 Nov 2009 17:56:39 -0500 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 22:57:36 -0000 At 5:23 PM -0500 11/2/09, Rob Austein wrote: >... > >I think we are talking slightly past each other, and have been on this >topic all along. I said "HTTP", you seem to have read "TLS". What Russ and I proposed was TLS, so that's why I am talking about TLS. I'm not sure when the suggestion to use TLS was translated into HTTPS. >... > >Remember that the reason we were originally told to use TLS here was >replay protection. I know you keep saying server protection, but >that's not how we originally got here. I'm not seeing much replay >protection in what we've implemented to date, which concerns me, as we >added a fairly heavyweight mechanism that as far as I can tell has not >solved the original problem. My recollection differs somewhat. I think what Russ and I suggested was using TLS to enable session-level protection, which includes two-way authentication at the time of session creation (as an input to access control for the server), session integrity (i.e., dropped or re-ordered packets are detectable), and session authentication (i.e., all packets belonging to the same session are verified as such). Anti-replay at the session level and within a session are two facets of this protection suite. Steve From sra@hactrn.net Mon Nov 2 15:27:28 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B443A689A for ; Mon, 2 Nov 2009 15:27:28 -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.301, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLnMzmeot+AB for ; Mon, 2 Nov 2009 15:27:28 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id B637C3A6841 for ; Mon, 2 Nov 2009 15:27:27 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 1A3ED28477 for ; Mon, 2 Nov 2009 23:27:47 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id CA7ED22807 for ; Mon, 2 Nov 2009 18:27:46 -0500 (EST) Date: Mon, 02 Nov 2009 18:27:46 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20091101194636.AB26022807@thrintun.hactrn.net> <20091102171924.D38A722807@thrintun.hactrn.net> <20091102222331.6CEEC22807@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091102232746.CA7ED22807@thrintun.hactrn.net> Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 23:27:28 -0000 At Mon, 2 Nov 2009 17:56:39 -0500, Steve Kent wrote: > > >I think we are talking slightly past each other, and have been on this > >topic all along. I said "HTTP", you seem to have read "TLS". > > What Russ and I proposed was TLS, so that's why I am talking about TLS. > I'm not sure when the suggestion to use TLS was translated into HTTPS. The protocol you reviewed back in 2007 was already running over HTTP, so when you started talking about TLS, everybody interpreted it in the context of the existing HTTP-based protocol and heard it as HTTPS. > >Remember that the reason we were originally told to use TLS here was > >replay protection. I know you keep saying server protection, but > >that's not how we originally got here. I'm not seeing much replay > >protection in what we've implemented to date, which concerns me, as we > >added a fairly heavyweight mechanism that as far as I can tell has not > >solved the original problem. > > My recollection differs somewhat. I think what Russ and I suggested > was using TLS to enable session-level protection, which includes > two-way authentication at the time of session creation (as an input > to access control for the server), session integrity (i.e., dropped > or re-ordered packets are detectable), and session authentication > (i.e., all packets belonging to the same session are verified as > such). Anti-replay at the session level and within a session are two > facets of this protection suite. I assume you mean PDUs throughout here, not IP packets. Your description makes some sense, but is not what I think we heard at the time. I think you're more concerned about channel-level access control here than I am (as I said to Terry, the access control I care about all hinges on the CMS signatures). It is of course possible that you're right about this and I'm wrong. In any case, I agree that if we had done what you describe here, replay protection would have fallen out of it as one of the consequences. But the real question now is where do we go from here, given that we have interoperable implementations that didn't do it this way. Do you agree with my concern that what we ended up doing does not provide replay protection? From kotikalapudi.sriram@nist.gov Mon Nov 2 19:10:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B474D3A680A for ; Mon, 2 Nov 2009 19:10: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 r5nwjLx9ETff for ; Mon, 2 Nov 2009 19:10:54 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 7DE933A6809 for ; Mon, 2 Nov 2009 19:10:54 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA33B3kk029374; Mon, 2 Nov 2009 22:11:03 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Mon, 2 Nov 2009 22:10:58 -0500 From: "Sriram, Kotikalapudi" To: Sandra Murphy , "Larry J. Blunk" Date: Mon, 2 Nov 2009 22:10:57 -0500 Thread-Topic: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document Thread-Index: AcpcANRFPn8dEf4+TGy/ZXYgmG/VqgAMHFJ+ Message-ID: References: <742173602.6653341257195587203.JavaMail.root@crono>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 03:10:55 -0000 Larry: I appreciate the information/thoughts you have shared.=20 It would be fine if it (the ROA registrations) plays out the way you envisi= on it should. As Sandy mentioned, there are instances of sub-suballocations and sub-sub-s= uballocations etc.=20 as can be gleaned from examples at this link: http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20091030.1800.h= tml http://stats.research.icann.org/bgp/ Sriram ________________________________________ From: Sandra Murphy [sandy@sparta.com] Sent: Monday, November 02, 2009 4:09 PM To: Larry J. Blunk Cc: Sriram, Kotikalapudi; sidr@ietf.org Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG docu= ment On Mon, 2 Nov 2009, Larry J. Blunk wrote: > > ----- "Sandra Murphy" wrote: > >> On Mon, 2 Nov 2009, Larry Blunk wrote: >> >>> Sriram, Kotikalapudi wrote: > > If you are using PA space to multihome, > then you are going to have to play by the provider's rules. > If the provider does not allow multihoming using their > space, that's their right. You can either get PI > space or get another provider. Do you think clueless > customers will want to deal with signing ROA's? In > most cases, I suspect not. If a provider allows customers > to multi-home from the provider's address space, it seems eminently > reasonable that they would also be willing to sign ROA's > for that space with the customer's AS. Why wouldn't they? > > In the case of multi-origin multi-homing using PA > space, you are talking about a very small subset. > For the providers who allow such configurations, yes > I fully expect them to sign the ROA's. Be aware that > many providers will simply tell customers to go get > their own AS and/or their own PI space. This fits my model and what several others have suggested as well. What is your opinion of a level down from there - clueless customers multihomed clueless customers? I've heard that while a relationship exists between provider and customer, that's not likely between provider and customer's customers through which the ROAs could be requested or automatically created on certain events. (Not expressing an opinion here, just exploring the wg's opinion.) --Sandy > > -Larry > > > >> From kent@bbn.com Tue Nov 3 10:00:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B033A6A4A for ; Tue, 3 Nov 2009 10:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss3d4rW28HCS for ; Tue, 3 Nov 2009 10:00:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C800E28C0F7 for ; Tue, 3 Nov 2009 10:00:41 -0800 (PST) Received: from dhcp89-089-021.bbn.com ([128.89.89.21]:49212) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N5Ngj-0002Wy-Ay; Tue, 03 Nov 2009 13:01:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20091102232746.CA7ED22807@thrintun.hactrn.net> References: <20091101194636.AB26022807@thrintun.hactrn.net> <20091102171924.D38A722807@thrintun.hactrn.net> <20091102222331.6CEEC22807@thrintun.hactrn.net> <20091102232746.CA7ED22807@thrintun.hactrn.net> Date: Tue, 3 Nov 2009 11:51:09 -0500 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 18:00:42 -0000 At 6:27 PM -0500 11/2/09, Rob Austein wrote: >At Mon, 2 Nov 2009 17:56:39 -0500, Steve Kent wrote: >> >> >I think we are talking slightly past each other, and have been on this >> >topic all along. I said "HTTP", you seem to have read "TLS". >> >> What Russ and I proposed was TLS, so that's why I am talking about TLS. >> I'm not sure when the suggestion to use TLS was translated into HTTPS. > >The protocol you reviewed back in 2007 was already running over HTTP, >so when you started talking about TLS, everybody interpreted it in the >context of the existing HTTP-based protocol and heard it as HTTPS. Fair enough. >.. > >I assume you mean PDUs throughout here, not IP packets. Your >description makes some sense, but is not what I think we heard at the >time. I think you're more concerned about channel-level access >control here than I am (as I said to Terry, the access control I care >about all hinges on the CMS signatures). It is of course possible >that you're right about this and I'm wrong. In any case, I agree that >if we had done what you describe here, replay protection would have >fallen out of it as one of the consequences. yes, I mean PDUs, since TLS runs on top of IP and TCP. >But the real question now is where do we go from here, given that we >have interoperable implementations that didn't do it this way. > >Do you agree with my concern that what we ended up doing does not >provide replay protection? Not sure that I do. I understand your comment that HTTP per se has no real session flavor. Not surprising since it was designed to support stateless query/response exchanges. That was changed as cookies were added to enable better support of state, without changing the base protocol in a fundamental way. I am not enough of an HTTP guy to know what are appropriate ways to get the session flavor that we want, taking advantage of the TLS/HTTPS combination. I'm tempted to suggest use of IPsec, but I'm biased :-). Steve From ggm+ietf@apnic.net Tue Nov 3 14:07:56 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAAFA28B56A for ; Tue, 3 Nov 2009 14:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps2Kv9ZYGjam for ; Tue, 3 Nov 2009 14:07:56 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 048E53A67A2 for ; Tue, 3 Nov 2009 14:07:56 -0800 (PST) Received: from dynamic129.apnic.net (dynamic129.apnic.net [203.119.42.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2479AD5900; Wed, 4 Nov 2009 08:16:57 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: George Michaelson In-Reply-To: Date: Wed, 4 Nov 2009 08:08:14 +1000 Content-Transfer-Encoding: 7bit Message-Id: <493B7AB9-A182-4298-9490-7D92E4CC8393@apnic.net> References: <742173602.6653341257195587203.JavaMail.root@crono>, To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1076) Cc: sidr Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:07:56 -0000 Sriram, I have discussed this by email with my co-author who is in transit. Please find out reply interpolated below, with apologies for delay. -George > From: "Sriram, Kotikalapudi" > Date: 3 November 2009 4:00:14 AM AEDT > To: "sidr@ietf.org" > Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation > > Comments on the -03 version: > > Section 4.1 is a bit confusing because it does not seem to take ROA > prefix maxlength into consideration or fails to make any mention of > it. Yes, you are right - it could be clearer that "More Specific than ROA" in the table and the text that says "more specific than the ROA" means a prefix length that is greater than the ROA's maxLength value. That is clear in section 2, step 3, but not specifically reiterated in section 4.1 > Several of the statements in this section do not make it clear what > implication maxlength has on prefix matching. For example, does > definition of "covering aggregate" include the case when the update > (route) prefix length is longer than maxlength? "Covering aggregate" is used twice in the draft - once in section 2 to describe the set of ROAs that are potential candidates to validate a route object, and again in section 4 to describe the validation of a single route object. The context of use in the two sections is different, and we (the authors) had felt that the text was sufficitly clear, but evidently that was not a good assumption. > In my understanding, ROA prefix is not a _covering_ aggregate if the > update prefix length exceeds maxlength, unless purposefully defined > otherwise. It would help if you gave an example here. We are lost in understanding your question. > "Covering Aggregate" should be clearly defined in Section 2, > explicitly stating what role maxlength plays, before getting into > any description of algorithms. The role of maxlength is clearly described in step 3 of section 2, but your point about "covering aggregate" not being well defined is a good point. Perhaps an example would help with the text. > > In my opinion, Section 2 already provides coverage for partial > deployment for the case of prefixes that are not included in any > ROA. Steps 1 and 2 of the algorithm on page 4 take care of this case > of partial deployment. So having a modified algorithm in Section 4 > seems redundant. The discussion part of Section 4 is relevant and > can be suitably edited and moved to Section 2. Section 4 does not present a modified algorithm. Section 4 explains the derivation of the "unknown" outcome of step 2 of section 2. From kent@bbn.com Wed Nov 4 09:27:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC043A683D for ; Wed, 4 Nov 2009 09:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137, 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 7ZkbArsWQLaH for ; Wed, 4 Nov 2009 09:27:04 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 179783A6832 for ; Wed, 4 Nov 2009 09:27:04 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.2]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N5jdk-0005i3-Ab for sidr@ietf.org; Wed, 04 Nov 2009 12:27:24 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 4 Nov 2009 12:25:35 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-954766852==_ma============" Subject: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:27:05 -0000 --============_-954766852==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Changed status to be Best Current Practice from Informational (consistent with eventual BCP designation) In Section 1.7 revised text (removed references to SIDR WG) RPKI signed object - Digitally signed data object (other than a certificate or CRL) declared to be such by a standards track RFC, and that can be validated using certificates issued under this PKI. ------ Section 1.4.4 revised text (removed references to SIDR WG) An RPKI signed object is a digitally-signed object, declared to be such by a standards track RFC. ------- Section 9.12.1 revised text (removed reference to RIRs and IANA, replaced with IETF) The procedure for amending this CP is via written notice from the IETF in the form of a new Standards Track, BCP RFC that updates or obsoletes this document. ------ Sectioon 9.12.2 revised text (removed reference to RIRs and IANA, replaced with IETF) The IETF will provide at least one month's advance notice of any changes to this CP. ------- Section 9.12.3 revised text (removed reference to RIRs and IANA, replaced with IETF) If the IETF judges that changes to the CP do not materially reduce the acceptability of certificates issued for RPKI purposes, there will be no change to the CP OID. If the IETF judges that changes to the CP do materially change the the acceptability of certificates for RPKI purposes, then there will be a new CP OID. Section 13.2 (removed last two informative references) --============_-954766852==_ma============ Content-Type: text/html; charset="us-ascii" CP changes in response to WGLC comments
Changed status to be Best Current Practice from Informational (consistent with eventual BCP designation)


In Section 1.7 revised text (removed references to SIDR WG)

RPKI signed object - Digitally signed data object (other than a
certificate or CRL) declared to be such by a standards track RFC,
and that can be validated using certificates issued under this PKI.

------

Section 1.4.4 revised text (removed references to SIDR WG)

An RPKI signed object is a digitally-signed object, declared to be such by a standards track RFC.

-------

Section 9.12.1 revised text (removed reference to RIRs and IANA, replaced with IETF)

The procedure for amending this CP is via written notice from the IETF in the form of a new Standards Track, BCP RFC that updates or obsoletes this document.

------

Sectioon 9.12.2 revised text (removed reference to RIRs and IANA, replaced with IETF)

The IETF will provide at least one month's advance notice of any changes to this CP.
-------

Section 9.12.3 revised text (removed reference to RIRs and IANA, replaced with IETF)

If the IETF judges that changes to the CP do not materially reduce the acceptability of certificates issued for RPKI purposes, there will be no change to the CP OID. If the IETF judges that changes to the CP do materially change the the acceptability of certificates for RPKI purposes, then there will be a new CP OID.

Section 13.2 (removed last two informative references)
--============_-954766852==_ma============-- From jcurran@istaff.org Wed Nov 4 09:53:34 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1CC3A6817 for ; Wed, 4 Nov 2009 09:53:34 -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 oaSroNkTbFUB for ; Wed, 4 Nov 2009 09:53:33 -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 507503A67E5 for ; Wed, 4 Nov 2009 09:53:33 -0800 (PST) Received: from 72-254-50-165.client.stsn.net ([72.254.50.165] helo=[10.0.62.15]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1N5k3N-000OcK-28; Wed, 04 Nov 2009 12:53:54 -0500 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-5--122858949 From: John Curran In-Reply-To: Date: Wed, 4 Nov 2009 09:53:35 -0800 Message-Id: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> References: To: Stephen Kent X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:53:34 -0000 --Apple-Mail-5--122858949 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Steve - In general, these changes are fine, and address the naming parent/ child/IANA/RIR/ISP name game issue. One issue which is raised is that a RPKI service provider now may be made subject (with one month's notice) to changes to the CP made by the IETF. As the CP specifies operational practices, this has potential to be impacting for the RPKI service provider and ISP's relying upon such certs. In order to protect those relying ISPs in the case of a CP change which causes RPKI providers to exit the business, the 9.12.2 implementation time period to should be long enough to allow ISP's to move to an RPKI providers now complying with the new CP document. I'd recommend 6 months advance notice rather than one for this reason. Thanks, /John On Nov 4, 2009, at 9:25 AM, Stephen Kent wrote: > Changed status to be Best Current Practice from Informational > (consistent with eventual BCP designation) > > > In Section 1.7 revised text (removed references to SIDR WG) > > RPKI signed object - Digitally signed data object (other than a > certificate or CRL) declared to be such by a standards track RFC, > and that can be validated using certificates issued under this PKI. > > ------ > > Section 1.4.4 revised text (removed references to SIDR WG) > > An RPKI signed object is a digitally-signed object, declared to be > such by a standards track RFC. > > ------- > > Section 9.12.1 revised text (removed reference to RIRs and IANA, > replaced with IETF) > > The procedure for amending this CP is via written notice from the > IETF in the form of a new Standards Track, BCP RFC that updates or > obsoletes this document. > > ------ > > Sectioon 9.12.2 revised text (removed reference to RIRs and IANA, > replaced with IETF) > > The IETF will provide at least one month's advance notice of any > changes to this CP. > ------- > > Section 9.12.3 revised text (removed reference to RIRs and IANA, > replaced with IETF) > > If the IETF judges that changes to the CP do not materially reduce > the acceptability of certificates issued for RPKI purposes, there > will be no change to the CP OID. If the IETF judges that changes to > the CP do materially change the the acceptability of certificates > for RPKI purposes, then there will be a new CP OID. > > Section 13.2 (removed last two informative references) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-5--122858949 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Steve - 
 
  In = general, these changes are fine, and address the naming = parent/child/IANA/RIR/ISP name game = issue.

  One issue which is raised is = that a RPKI service provider now may be made subject (with one month's = notice) to changes to the CP made by the IETF.  As the CP specifies = operational practices, this has potential to be impacting for the RPKI = service provider and ISP's relying upon such certs.   In order to = protect those relying ISPs in the case of a CP change which causes RPKI = providers to exit the business, the 9.12.2 implementation time period to = should be long enough to allow ISP's to move to an RPKI providers now = complying with the new CP document.  I'd recommend 6 months advance = notice rather than one for this = reason.

Thanks,
/John


On Nov 4, 2009, at 9:25 AM, Stephen Kent = wrote:

Changed status to = be Best Current = Practice from = Informational (consistent with eventual BCP = designation)


In Section 1.7 = revised text (removed references to SIDR = WG)

RPKI signed object - Digitally signed = data object (other than a
certificate or CRL) declared = to be such by a standards track RFC,
and that can be = validated using certificates issued under this = PKI.

------

Section = 1.4.4 revised text (removed references to SIDR = WG)

An RPKI signed object is a = digitally-signed object, declared to be such by a standards track = RFC.

-------

Section= 9.12.1 revised text (removed reference to RIRs and IANA, replaced with = IETF)

The procedure = for amending this CP is via written notice from the IETF in the form of = a new Standards Track, BCP RFC that updates or obsoletes this = document.

------

<= div>Sectioon 9.12.2 revised text (removed reference to RIRs and IANA, = replaced with IETF)

The IETF will provide at least one month's advance = notice of any changes to this CP.
-------

Secti= on 9.12.3 revised text (removed reference to RIRs and IANA, replaced = with IETF)

If the = IETF judges that changes to the CP do not materially reduce the = acceptability of certificates issued for RPKI purposes, there will be no = change to the CP OID. If the IETF judges that changes to the CP do = materially change the the acceptability of certificates for RPKI = purposes, then there will be a new CP = OID.

Section 13.2 (removed last two = informative = references)
_______________________________________________
sidr = mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

= --Apple-Mail-5--122858949-- From randy@psg.com Wed Nov 4 10:05:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CCD28C0DB for ; Wed, 4 Nov 2009 10:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 VqmSLvTTtJPn for ; Wed, 4 Nov 2009 10:05:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 460A73A6922 for ; Wed, 4 Nov 2009 10:05:19 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5kEk-0002ph-FD; Wed, 04 Nov 2009 18:05:38 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 37E482BE1A35; Wed, 4 Nov 2009 12:05:38 -0600 (CST) Date: Wed, 04 Nov 2009 12:05:38 -0600 Message-ID: From: Randy Bush To: John Curran In-Reply-To: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:05:20 -0000 > In general, these changes are fine, and address the naming parent/ > child/IANA/RIR/ISP name game issue. yep, all good > One issue which is raised is that a RPKI service provider now may > be made subject (with one month's notice) to changes to the CP made by > the IETF. As the CP specifies operational practices, this has > potential to be impacting for the RPKI service provider and ISP's > relying upon such certs. amusing that you use the term ISP when you like the document getting rid of proper noun taxa. > In order to protect those relying ISPs in the case of a CP change > which causes RPKI providers to exit the business, the 9.12.2 > implementation time period to should be long enough to allow ISP's to > move to an RPKI providers now complying with the new CP document. I'd > recommend 6 months advance notice rather than one for this reason. i am confused. i do not understand the relationship of a parent going out of business (irrespective of reason) with the time for an rpki instance to meet a new cp. seems to me thatm if my parent goes out of business, the scramble is to build the peerings with the parent(s) to which my grandparent swings the resources from which my resources are drawn. randy From Sandra.Murphy@cobham.com Wed Nov 4 10:30:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8D528C106 for ; Wed, 4 Nov 2009 10:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 hmicIu8t-o2I for ; Wed, 4 Nov 2009 10:30:28 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id CF18628C0DB for ; Wed, 4 Nov 2009 10:30: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 nA4IUmWs020659; Wed, 4 Nov 2009 12:30:48 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA4IUmaq005759; Wed, 4 Nov 2009 12:30:48 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.77]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 13:30:48 -0500 Date: Wed, 4 Nov 2009 14:30:47 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 04 Nov 2009 18:30:48.0565 (UTC) FILETIME=[EE1C7250:01CA5D7C] Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:30:29 -0000 On Wed, 4 Nov 2009, Randy Bush wrote: >> In general, these changes are fine, and address the naming parent/ >> child/IANA/RIR/ISP name game issue. > > yep, all good > >> One issue which is raised is that a RPKI service provider now may >> be made subject (with one month's notice) to changes to the CP made by >> the IETF. As the CP specifies operational practices, this has >> potential to be impacting for the RPKI service provider and ISP's >> relying upon such certs. > > amusing that you use the term ISP when you like the document getting rid > of proper noun taxa. > >> In order to protect those relying ISPs in the case of a CP change >> which causes RPKI providers to exit the business, the 9.12.2 >> implementation time period to should be long enough to allow ISP's to >> move to an RPKI providers now complying with the new CP document. I'd >> recommend 6 months advance notice rather than one for this reason. > > i am confused. i do not understand the relationship of a parent going > out of business (irrespective of reason) with the time for an rpki > instance to meet a new cp. > > seems to me thatm if my parent goes out of business, the scramble is to > build the peerings with the parent(s) to which my grandparent swings the > resources from which my resources are drawn. Randy, as I read John's note, when he says "RPKI service provider" he means the CertsRUs business which the ISP has outsourced all its cert handling activity to. It sounds to me like you were reading that as an upstream ISP. --Sandy > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Wed Nov 4 11:03:43 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6F33A69FB for ; Wed, 4 Nov 2009 11:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 oq8dvUcuLxzK for ; Wed, 4 Nov 2009 11:03:42 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2ECC13A69FA for ; Wed, 4 Nov 2009 11:03:42 -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 nA4J43Xa021266; Wed, 4 Nov 2009 13:04:03 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA4J40ie007565; Wed, 4 Nov 2009 13:04:03 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.77]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 14:03:59 -0500 Date: Wed, 4 Nov 2009 15:03:59 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Jared Mauch In-Reply-To: Message-ID: References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <11856BC4-5462-4AB1-A175-D6D70EE10B63@apnic.net> <89658BEC-0F8E-44E6-81E9-5010A1FF7523@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 04 Nov 2009 19:03:59.0725 (UTC) FILETIME=[90EF59D0:01CA5D81] Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr-arch-09 refresh cycle time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:03:43 -0000 I can understand these concerns. Would you rather see the wg try: (a) concentrated redesign (to what, I have no idea) (b) operational guidance to operators of how to manage this risk - get new certs out before the route that relies on it, etc. (There's already been discussion of an operational use document.) (c) create a way to carry info inband for emergencies (transitively - inducing work even on those who do not yet understand during initial deployment). Which of these (or something else) is the right wg direction, in your mind? --Sandy On Sat, 31 Oct 2009, Jared Mauch wrote: > On Oct 31, 2009, at 10:07 AM, Danny McPherson wrote: > >> >> One might suspect there are some things we can learn from >> this: >> >> http://tools.ietf.org/html/rfc4641 >> >> In particular, when *contrasting* even initial operational >> practices with preceding recommendations made in theoretical >> environments, a disparity usually emerges. >> >> I share concerns about frequency of publication and fetching >> functions. In particular, this was one of the larger reasons >> why folks stopped using IRR-based prefix lists in practice. It's >> a real PITA when intermediate ASes haven't updated policies for >> newly announced prefixes in a stateful protocol such as BGP. The >> originator announces the route, the route is dropped by peers >> because it's not permitted in the import policy, then the policy >> is updated eventually after corresponding IRR objects were fetched >> and the route is now permitted in policy, but stateful BGP doesn't >> reannounce the route, so the route had to be "bounced" somehow >> along the path, or at the origin, or a session reset to trigger >> a new update once the policy has been updated. >> >> Of course, we have BGP route refresh today, and implementations >> arguably should store an "invalid" route in an Adj-RIB-In and >> denote as such - but that does introduce cost (and a potential >> attack vector) as well. As Randy pointed out, and Curtis and I >> have stated (and lived firsthand together :-/) many times, the >> ripple effects associated with disjoint and autonomous application >> of policy derived from IRR (or RPKI) like systems are quite an >> operations nightmare in practice, and should be given heavy >> consideration here. > > I certainly echo these comments and concerns. > > - Jared _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Wed Nov 4 11:41:00 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538A93A67B3 for ; Wed, 4 Nov 2009 11:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 CsvmtXO1BvYd for ; Wed, 4 Nov 2009 11:40:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 0A4953A67AB for ; Wed, 4 Nov 2009 11:40:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5ljJ-00034S-VW; Wed, 04 Nov 2009 19:41:18 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 111672BE1C9E; Wed, 4 Nov 2009 13:41:17 -0600 (CST) Date: Wed, 04 Nov 2009 13:41:16 -0600 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:41:00 -0000 >> i am confused. i do not understand the relationship of a parent going >> out of business (irrespective of reason) with the time for an rpki >> instance to meet a new cp. >> >> seems to me thatm if my parent goes out of business, the scramble is to >> build the peerings with the parent(s) to which my grandparent swings the >> resources from which my resources are drawn. > > Randy, as I read John's note, when he says "RPKI service provider" he > means the CertsRUs business which the ISP has outsourced all its cert > handling activity to. > > It sounds to me like you were reading that as an upstream ISP. oops! sorreeee. but, in that case, is not the largest part of the problem still getting the grandparent(s) to swing the covering resource set(s) to new parent(s)? is not the cp-compliance issue but one very small part of of the criteria on which i and my grandparent(s) choose new parent(s)? randy From jcurran@istaff.org Wed Nov 4 11:45:21 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A383A67AB for ; Wed, 4 Nov 2009 11:45:21 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzk1B21YU8u8 for ; Wed, 4 Nov 2009 11:45:21 -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 E57A73A6782 for ; Wed, 4 Nov 2009 11:45:20 -0800 (PST) Received: from 72-254-50-165.client.stsn.net ([72.254.50.165] helo=[10.0.62.15]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1N5lnZ-000P9k-Pr; Wed, 04 Nov 2009 14:45:42 -0500 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: John Curran In-Reply-To: Date: Wed, 4 Nov 2009 11:45:40 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> To: Randy Bush X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:45:21 -0000 On Nov 4, 2009, at 10:05 AM, Randy Bush wrote: > > ... > seems to me thatm if my parent goes out of business, the scramble is > to > build the peerings with the parent(s) to which my grandparent swings > the > resources from which my resources are drawn. Correct; I agree that's the desired result, regardless of parent failure. My point is that 1 month is a very short time to implement potentially significant operational changes from an updated CP, so unless there's a reason for such a short time frame I'd recommend something longer. /John From randy@psg.com Wed Nov 4 11:52:21 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC613A6784 for ; Wed, 4 Nov 2009 11:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 DrbAxbhV2skp for ; Wed, 4 Nov 2009 11:52:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A8CAF3A6782 for ; Wed, 4 Nov 2009 11:52:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5luL-00037K-3w; Wed, 04 Nov 2009 19:52:41 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 320F52BE1DB3; Wed, 4 Nov 2009 13:52:40 -0600 (CST) Date: Wed, 04 Nov 2009 13:52:40 -0600 Message-ID: From: Randy Bush To: John Curran In-Reply-To: References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:52:21 -0000 > My point is that 1 month is a very short time to implement potentially > significant operational changes from an updated CP, so unless there's > a reason for such a short time frame I'd recommend something longer. but, in the real world, is cp-compliance a major criterion on which i will move to/from a rpki provider? i suspect it will be down in the weeds, and reliability/reputation, price, ease of operation, ... will predominate. otoh, i can see that an rpki-provider might want longer than a month to implement a new set of ops requirements. but does not the current ietf process provide years? randy From jcurran@istaff.org Wed Nov 4 11:55:14 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49A33A63D3 for ; Wed, 4 Nov 2009 11:55:14 -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 28xnnuI3I09c for ; Wed, 4 Nov 2009 11:55:14 -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 1836D3A67B3 for ; Wed, 4 Nov 2009 11:55:14 -0800 (PST) Received: from 72-254-50-165.client.stsn.net ([72.254.50.165] helo=[10.0.62.15]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1N5lx8-000PCk-JJ; Wed, 04 Nov 2009 14:55:35 -0500 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: John Curran In-Reply-To: Date: Wed, 4 Nov 2009 11:55:31 -0800 Content-Transfer-Encoding: 7bit Message-Id: <9DCA8161-5A5D-4B04-A2A8-34B340214F41@istaff.org> References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> To: Randy Bush X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:55:14 -0000 On Nov 4, 2009, at 11:41 AM, Randy Bush wrote: > ... > but, in that case, is not the largest part of the problem still > getting > the grandparent(s) to swing the covering resource set(s) to new > parent(s)? is not the cp-compliance issue but one very small part > of of > the criteria on which i and my grandparent(s) choose new parent(s)? Use case: 1) New CP comes out and specifies minimum standards in the area of Facility, Management, And Operational Controls (rather the delegation of such to the CPS) 2) Existing RPKI service providers need to assess this and decide implications therein 3) If existing RPKI providers can't/won't meet the requirements, and exit the business, they want to do so within 1 month due to 9.12.2 (to prevent having non-CP compliant certs out there) You've got the time left over, after the RPKI service provider exits the field, to scramble with the grandparent to select new service providers... Hence, my suggestion that 30 days notice is rather short. /John From jcurran@istaff.org Wed Nov 4 11:58:00 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3896B28C125 for ; Wed, 4 Nov 2009 11:58:00 -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 YQRdVrPf8KsP for ; Wed, 4 Nov 2009 11:57:59 -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 81A3628C114 for ; Wed, 4 Nov 2009 11:57:59 -0800 (PST) Received: from 72-254-50-165.client.stsn.net ([72.254.50.165] helo=[10.0.62.15]) by midgard.seastrom.com with esmtpsa (TLSv1:AES128-SHA:128) (authenticated id=box0219) id 1N5lzn-000PDX-VS; Wed, 04 Nov 2009 14:58:20 -0500 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: John Curran In-Reply-To: Date: Wed, 4 Nov 2009 11:58:16 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3FED2E21-9C78-484D-8D26-10B3F8A4106A@istaff.org> References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> To: Randy Bush X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 19:58:00 -0000 On Nov 4, 2009, at 11:52 AM, Randy Bush wrote: > > otoh, i can see that an rpki-provider might want longer than a month > to > implement a new set of ops requirements. but does not the current > ietf > process provide years? You can't invest in the deployment of some types of requirements (liability, costs) until the need is certain, i.e. post approval. Randy - Can you explain the concerns with having a longer time period in the document? /John From randy@psg.com Wed Nov 4 12:19:33 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1600A28C0EE for ; Wed, 4 Nov 2009 12:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 XfUVRLXxTXCq for ; Wed, 4 Nov 2009 12:19:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2CC4D28C0E8 for ; Wed, 4 Nov 2009 12:19:32 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5mKe-0003CU-Or; Wed, 04 Nov 2009 20:19:53 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 7310D2BE1FBA; Wed, 4 Nov 2009 14:19:52 -0600 (CST) Date: Wed, 04 Nov 2009 14:19:52 -0600 Message-ID: From: Randy Bush To: John Curran In-Reply-To: <3FED2E21-9C78-484D-8D26-10B3F8A4106A@istaff.org> <9DCA8161-5A5D-4B04-A2A8-34B340214F41@istaff.org> References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> <3FED2E21-9C78-484D-8D26-10B3F8A4106A@istaff.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:19:33 -0000 > You can't invest in the deployment of some types of requirements > (liability, costs) until the need is certain, i.e. post approval. so we have noticed :( > Can you explain the concerns with having a longer time period in the > document? as we deploy, if we find a serious ops problem that means a change to the cp, it would be good to have it fixed very quickly. then again, it's the running code that really needs to be fixed. otoh, as the cp carries a legal liability tie-in, i can see that the rpki provider wants a long window in which both old and new requirement sets are valid. > Use case: > > 1) New CP comes out and specifies minimum standards in the area of > Facility, Management, And Operational Controls (rather the delegation > of such to the CPS) > > 2) Existing RPKI service providers need to assess this and decide > implications therein > > 3) If existing RPKI providers can't/won't meet the requirements, and > exit the business, they want to do so within 1 month due to 9.12.2 (to > prevent having non-CP compliant certs out there) > > You've got the time left over, after the RPKI service provider exits > the field, to scramble with the grandparent to select new service > providers... if someone mid-chain turns off, certs/roas below will no longer validate. so swinging from the grandparent must be make before break. > Hence, my suggestion that 30 days notice is rather short. i have no strong disagreement with a wider window. i remain confused by your characterization of the need. randy From kent@bbn.com Wed Nov 4 12:26:47 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD28A3A67FA for ; Wed, 4 Nov 2009 12:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xxpJ7Vy0SMu for ; Wed, 4 Nov 2009 12:26:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E82A23A63D3 for ; Wed, 4 Nov 2009 12:26:46 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.2]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N5mRf-0001w9-AN; Wed, 04 Nov 2009 15:27:07 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> Date: Wed, 4 Nov 2009 15:27:04 -0500 To: John Curran From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:26:47 -0000 At 9:53 AM -0800 11/4/09, John Curran wrote: >Steve - > > In general, these changes are fine, and address the naming >parent/child/IANA/RIR/ISP name game issue. > > One issue which is raised is that a RPKI service provider now may >be made subject (with one month's notice) to changes to the CP made >by the IETF. As the CP specifies operational practices, this has >potential to be impacting for the RPKI service provider and ISP's >relying upon such certs. In order to protect those relying ISPs in >the case of a CP change which causes RPKI providers to exit the >business, the 9.12.2 implementation time period to should be long >enough to allow ISP's to move to an RPKI providers now complying >with the new CP document. I'd recommend 6 months advance notice >rather than one for this reason. > >Thanks, >/John John, Fair point. I thought about the 1 month value when I was editing the text, having not looked at it for a long time. I thought that the IESG/RFC process was sufficiently long that anyone who was watching would have a lot more than 1 month advance notice :-). However, not everyone who might be affected would necessarily be tracking a proposed change, and the change would, not be definite until approved by the IESG. So, I think this is very reasonable change this value to be 6 months. Steve From randy@psg.com Wed Nov 4 12:27:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6383A6915 for ; Wed, 4 Nov 2009 12:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 GZK6wgXAWEXs for ; Wed, 4 Nov 2009 12:27:55 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id D0DF53A690F for ; Wed, 4 Nov 2009 12:27:54 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5mSl-0003E0-J6; Wed, 04 Nov 2009 20:28:15 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 4CF9B2BE20D5; Wed, 4 Nov 2009 14:28:15 -0600 (CST) Date: Wed, 04 Nov 2009 14:28:15 -0600 Message-ID: From: Randy Bush To: John Curran In-Reply-To: References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> <3FED2E21-9C78-484D-8D26-10B3F8A4106A@istaff.org> <9DCA8161-5A5D-4B04-A2A8-34B340214F41@istaff.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:27:55 -0000 >> You've got the time left over, after the RPKI service provider exits >> the field, to scramble with the grandparent to select new service >> providers... > if someone mid-chain turns off, certs/roas below will no longer > validate. so swinging from the grandparent must be make before break. following this line of thought, should an rpki provider be required to give a significant re-parenting time window before stopping service? randy From kotikalapudi.sriram@nist.gov Wed Nov 4 12:46:51 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE01428C0E4 for ; Wed, 4 Nov 2009 12:46:51 -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 waqJ-xxlA6rz for ; Wed, 4 Nov 2009 12:46:50 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 71ED93A63D3 for ; Wed, 4 Nov 2009 12:46:50 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nA4KkZXL008048; Wed, 4 Nov 2009 15:46:36 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 4 Nov 2009 15:46:35 -0500 From: "Sriram, Kotikalapudi" To: George Michaelson Date: Wed, 4 Nov 2009 15:46:34 -0500 Thread-Topic: [sidr] revision to draft-ietf-sidr-roa-validation Thread-Index: Acpc0frewJ2z0Xm+SNCy+W6RPtz6VgAuL5TQ Message-ID: References: <742173602.6653341257195587203.JavaMail.root@crono>, <88B0213A-28BC-4861-8DA9-5C1A43FA3C98@apnic.net> In-Reply-To: <88B0213A-28BC-4861-8DA9-5C1A43FA3C98@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: sidr Subject: Re: [sidr] revision to draft-ietf-sidr-roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 20:46:51 -0000 > -----Original Message----- > From: George Michaelson [mailto:ggm+ap-lists@apnic.net] > Sent: Tuesday, November 03, 2009 5:06 PM >=20 >> From: "Sriram, Kotikalapudi" >> Date: 3 November 2009 4:00:14 AM AEDT >> In my understanding, ROA prefix is not a _covering_ aggregate if the >> update prefix length exceeds maxlength, unless purposefully defined >> otherwise. >It would help if you gave an example here. We are lost in >understanding your question. Thanks, George, for your responses to my previous email. In the following, I elaborate on my thinking while stepping through several= =20 validation use cases / examples, and I have a new question as well towards the end. (Later I will discuss with Terry Manderson about incorporating=20 these use cases also into our draft-manderson-sidr-usecases-01.txt;=20 these are not included there yet.) Examples (Validation use cases): Use case 1: ROA: {129.6.0.0/16, maxlength =3D 18, AS49} Update has {129.6.0.0/17, Origin =3D AS49} Here the ROA prefix is a covering prefix for the update prefix -- this is o= bvious. Use case 2: ROA: {129.6.0.0/16, maxlength =3D 18, AS49} Update has {129.6.5.0/24, Origin =3D AS49} (A) Do we still consider the ROA prefix a covering prefix for the update pr= efix? Or, (B) Do we consider it not a covering ROA prefix because the update pre= fix length is longer than the maxlength allowed in the ROA? =20 I think the answer is (A) for the following reasons (in a moment we will=20 enumerate additional use cases): In use case 2, we want the validation result to be Invalid. The algorithm will determine that the ROA prefix is a covering prefix=20 for the update prefix. But it will also determine that the ROA maxlength=20 is exceeded by the update prefix length; so the validation result is "Inval= id." In all use cases below, let us assume that we use definition (A) -=20 that is, ROA prefix is considered a covering match or covering aggregate=20 if the update prefix matches or is a more specific; the maxlength considera= tion is deferred at this stage and will be applied separately as part of the val= idation process. =20 Use case 3: HERE IS WHERE THE DISTINCTION IN "COVERING PREFIX or AGGREGATE"= DEFINITIONS BEGINS TO MATTER ROA: {129.6.0.0/16, maxlength =3D 18, AS49} Update has {129.6.5.0/24, Origin =3D AS42} (Note: Different origin) In use case 3, we want the validation result to be Invalid. The algorithm will determine that the ROA prefix is a covering prefix=20 for the update prefix. But it will also determine that the ROA maxlength=20 is exceeded by the update prefix length, and also determine that the origin is mismatched. So the result is "Invalid= ." (Here, clearly, the suspicion is that of a subprefix hijack situation.) =20 Use case 4: Giving an AS the benefit of doubt (partial deployment) ROA: {129.6.0.0/16, maxlength =3D 18, AS49} - not directly relevant for th= is use case.=20 Update has {74.63.16.0/24, Origin =3D AS42} (Note: Completely different prefix and origin - ROA listed is not=20 directly relevant anyway) (Note: There is no ROA in the entire repository that validates or invalidat= es=20 this update. We give the AS42 the benefit of doubt during=20 partial deployment; probably it has not yet upgraded to RPKI capability!) In use case 4, we want the validation result to be "Unknown". The algorithm determines that a ROA with a covering prefix for the=20 update prefix DOES NOT exist. So it concludes that possibly a ROA has not been registered yet. The result of validation: "Unknown" Use case 5: Here it is doubtful if "AS should be given the benefit of doub= t" ROA: {70.40.0.0/21, maxlength =3D 24, AS42} Update has {74.63.16.0/24, Origin =3D AS42} This use case is still a logical progression from previous use cases, but h= ere=20 I have a NEW QUESTION that we have not considered so far (IMHO).=20 (Note: Completely different prefix, but origin is the same as in another RO= A) (Note: There is no ROA in the repository that has a covering prefix=20 or aggregate for the update prefix. So there is no ROA that=20 validates or invalidates this update. However, here we hesitate to give=20 the AS42 the benefit of doubt; because we have evidence by observing=20 another ROA that AS42 or its ISP has RPKI capability!) I think your algorithm as well as that of draft-pmohapat-sidr-pfx-validate-= 03.txt will treat this update softly and the validation results will be=20 "Unknown" or "Not Found", respectively. But I think we may want the validation result in this case to be "Invalid". Question is: AS42 or its ISP evidently has RPKI capability;=20 so why did it register a ROA for one prefix (namely, 70.40.0.0/21)=20 that it originates but not for another prefix 74.63.16.0/24=20 which it is also trying to originate? =20 Caveat: AS42 might have been suballocated the prefix 74.63.16.0/24=20 from a different ISP who is clueless about RPKI. Is there a reasonable case here for validation result to be "Unknown" or should the result be "In= valid"?=20 I would like to request some discussion from the WG members on this questio= n. Sriram From kent@bbn.com Wed Nov 4 13:03:54 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD6F3A689F for ; Wed, 4 Nov 2009 13:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 mSpsCueTQGQq for ; Wed, 4 Nov 2009 13:03:53 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5326F3A6814 for ; Wed, 4 Nov 2009 13:03:53 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.2]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N5n1Z-0002yA-Al; Wed, 04 Nov 2009 16:04:13 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 4 Nov 2009 16:03:28 -0500 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: [sidr] CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 21:03:54 -0000 Terry, IN a message on 10/28 you said: >* Section 4.6.1-3 I'd like it made clear that renewal be only to the same >subscriber. eg the subscriber before and after renewal is the same. At >present it says that only the valid subscriber may request renewal, but >allows a new private key. I think there is too much wriggle room in that for >a subscriber to renew with someone else's private key. I reviewed the CP text and I think this is clear. Specifically 4.6.2 says: "Only the certificate holder or the issuing CA may initiate the renewal process." And 4.6.3 says: "Renewal procedures must ensure that the person or organization seeking to renew a certificate is in fact the subscriber (or authorized by the subscriber) of the certificate and the legitimate holder of the INR associated with the renewed certificate." I think these two text sections already address the issue you raised. Steve From terry.manderson@icann.org Wed Nov 4 16:17:52 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BCD03A689A for ; Wed, 4 Nov 2009 16:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 eP2hINQyhlWy for ; Wed, 4 Nov 2009 16:17:51 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id CEC3D3A682B for ; Wed, 4 Nov 2009 16:17:51 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 4 Nov 2009 16:18:14 -0800 From: Terry Manderson To: Stephen Kent Date: Wed, 4 Nov 2009 16:18:12 -0800 Thread-Topic: CP comments Thread-Index: AcpdkmovHZqaL4jVRb6f7fJbydQFIwAGwuXJ Message-ID: In-Reply-To: Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] CP comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 00:17:52 -0000 Hi Steve, Thanks for reviewing my concerns. Appears I must have skipped a paragraph in reading. Thanks Terry On 5/11/09 7:03 AM, "Stephen Kent" wrote: > Terry, >=20 > IN a message on 10/28 you said: >=20 >> * Section 4.6.1-3 I'd like it made clear that renewal be only to the sam= e >> subscriber. eg the subscriber before and after renewal is the same. At >> present it says that only the valid subscriber may request renewal, but >> allows a new private key. I think there is too much wriggle room in that= for >> a subscriber to renew with someone else's private key. >=20 >=20 > I reviewed the CP text and I think this is clear. >=20 > Specifically 4.6.2 says: "Only the certificate holder or the issuing > CA may initiate the renewal process." >=20 > And 4.6.3 says: "Renewal procedures must ensure that the person or > organization > seeking to renew a certificate is in fact the subscriber (or > authorized by the subscriber) of the certificate and the legitimate > holder of the INR associated with the renewed certificate." >=20 > I think these two text sections already address the issue you raised. >=20 > Steve From schnizlein@isoc.org Wed Nov 4 17:24:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A398028C0E6 for ; Wed, 4 Nov 2009 17:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83zm-1Rl5F7g for ; Wed, 4 Nov 2009 17:24:18 -0800 (PST) Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) by core3.amsl.com (Postfix) with ESMTP id C777D3A6842 for ; Wed, 4 Nov 2009 17:24:18 -0800 (PST) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 543BF1B4025 for ; Wed, 4 Nov 2009 20:24:39 -0500 (EST) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: schnizlein-AT-isoc.org) with ESMTPSA id 4591F1B4006 for ; Wed, 4 Nov 2009 20:24:39 -0500 (EST) Message-Id: <815A540B-900C-43EC-9FE8-CF63E5AB8B05@isoc.org> From: John Schnizlein To: sidr@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Nov 2009 20:24:34 -0500 X-Mailer: Apple Mail (2.936) Subject: [sidr] ISOC roundtable on Securing Routing Information X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 01:24:19 -0000 The consensus report on the roundtable discussion on Securing Routing Information is available at http://www.isoc.org/educpillar/resources/docs/routingroundtable_200909.pdf There appears to be interest in this working group on the subject. John From robert@ripe.net Thu Nov 5 00:49:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E03728C190 for ; Thu, 5 Nov 2009 00:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[AWL=2.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9H4VNizdvcd for ; Thu, 5 Nov 2009 00:49:54 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id B1E5628C19B for ; Thu, 5 Nov 2009 00:49:54 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N5y2k-0006e9-OH for sidr@ietf.org; Thu, 05 Nov 2009 09:50:16 +0100 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id B2DB62F592 for ; Thu, 5 Nov 2009 09:50:10 +0100 (CET) Message-ID: <4AF291C2.6000103@ripe.net> Date: Thu, 05 Nov 2009 09:50:10 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2741b58fd9b5461a19096b2d2e12ca09db7 Subject: [sidr] TA questions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 08:49:55 -0000 Hi, I'm proxying two questions from our development team regarding the TA draft: 1) How do the authors envision key roll overs for the RTA? Even though the draft allows for re-publication of the self-signed RTA with new resources, it does not seem to address key roll overs for that RTA. It seems one would have to publish a new ETA to support this, which would make invalidating the previous RTA (if that's ever needed) difficult. 2) Can we have a more clear pointer the RTACMS object for relying parties? The current proposal has the ETA CA point to a directory. See page 7 of the draft for an ascii-art representation of this. This means that relying parties will have to find the actual RTACMS object in this directory themselves. Probably rsync the whole thing and loop over the entries to figure out which is which. Robert From robert@ripe.net Thu Nov 5 00:58:09 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612F53A6993 for ; Thu, 5 Nov 2009 00:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL70xJdMLzB6 for ; Thu, 5 Nov 2009 00:58:08 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 7A8183A6990 for ; Thu, 5 Nov 2009 00:58:08 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N5yAg-0006yF-Ah; Thu, 05 Nov 2009 09:58:29 +0100 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 4C09C2F583; Thu, 5 Nov 2009 09:58:22 +0100 (CET) Message-ID: <4AF293AE.7050403@ripe.net> Date: Thu, 05 Nov 2009 09:58:22 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Randy Bush References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <4AE854D9.8040103@ripe.net> <4AE947CA.1070603@ripe.net> <4AE98CE2.3080708@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f98dc466a6c4e5e48043905d8dbf7bd3 Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr-arch-09 refresh cycle time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 08:58:09 -0000 Randy Bush wrote: >> That is only true if the thing you're propagating has to travel hop by >> hop to the bottom of the hierarchy. So the question still stands: what >> is this "thing" that you think propagates slowly, and why does it have >> to propagate hop by hop? > > incorrect or missing cert high in chain which needs delegation fix down > the chain so end site can get a fixed roa out there. remember, my > routing depends on that roa. and arin has extreme cases of depth, > though i think we will find itu-rir- to be the more > common cases. > > it's max time to repair which worries me. > > randy I understand this concern, but how likely is it that there is an "incorrect or missing cert high in chain" which needs fixing within one cycle? In the case of missing resources, it's very unlikely that someone deep down in the chain suddenly realises "oh, I need more resource from my grand-grand-grandparent NOW!". In the case of overclaiming, it's enough if any one in the chain shrinks their resources, the effect is visible in one cycle. So I'm not convinced that multi-cycle propagation this is an issue. Robert From randy@psg.com Thu Nov 5 01:01:10 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF033A692F for ; Thu, 5 Nov 2009 01:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 0nPd4CucbvKY for ; Thu, 5 Nov 2009 01:01:09 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A66D73A68B0 for ; Thu, 5 Nov 2009 01:01:09 -0800 (PST) Received: from ip67-91-170-251.z170-91-67.customer.algx.net ([67.91.170.251] helo=rmac.local) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N5yDi-0005Yy-DV; Thu, 05 Nov 2009 09:01:30 +0000 Message-ID: <4AF29469.8060209@psg.com> Date: Thu, 05 Nov 2009 03:01:29 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Robert Kisteleki References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <4AE854D9.8040103@ripe.net> <4AE947CA.1070603@ripe.net> <4AE98CE2.3080708@ripe.net> <4AF293AE.7050403@ripe.net> In-Reply-To: <4AF293AE.7050403@ripe.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr-arch-09 refresh cycle time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 09:01:10 -0000 Robert Kisteleki wrote: > Randy Bush wrote: >>> That is only true if the thing you're propagating has to travel hop by >>> hop to the bottom of the hierarchy. So the question still stands: what >>> is this "thing" that you think propagates slowly, and why does it have >>> to propagate hop by hop? >> >> incorrect or missing cert high in chain which needs delegation fix down >> the chain so end site can get a fixed roa out there. remember, my >> routing depends on that roa. and arin has extreme cases of depth, >> though i think we will find itu-rir- to be the more >> common cases. >> >> it's max time to repair which worries me. >> >> randy > > I understand this concern, but how likely is it that there is an > "incorrect or missing cert high in chain" which needs fixing within one > cycle? > > In the case of missing resources, it's very unlikely that someone deep > down in the chain suddenly realises "oh, I need more resource from my > grand-grand-grandparent NOW!". In the case of overclaiming, it's enough > if any one in the chain shrinks their resources, the effect is visible > in one cycle. think someone high in chain issues cert no longer covering youtube. randy From robert@ripe.net Thu Nov 5 01:04:37 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202BF3A68B7 for ; Thu, 5 Nov 2009 01:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.885 X-Spam-Level: X-Spam-Status: No, score=-8.885 tagged_above=-999 required=5 tests=[AWL=1.714, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0axzvXIqyKQ for ; Thu, 5 Nov 2009 01:04:36 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 6225A3A686A for ; Thu, 5 Nov 2009 01:04:36 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N5yGy-0007Hf-I1; Thu, 05 Nov 2009 10:04:57 +0100 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 838D32F592; Thu, 5 Nov 2009 10:04:52 +0100 (CET) Message-ID: <4AF29534.6050107@ripe.net> Date: Thu, 05 Nov 2009 10:04:52 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Randy Bush References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <4AE854D9.8040103@ripe.net> <4AE947CA.1070603@ripe.net> <4AE98CE2.3080708@ripe.net> <4AF293AE.7050403@ripe.net> <4AF29469.8060209@psg.com> In-Reply-To: <4AF29469.8060209@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274863079e547d90022f00de53cf2a08a27 Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr-arch-09 refresh cycle time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 09:04:37 -0000 >> In the case of missing resources, it's very unlikely that someone deep >> down in the chain suddenly realises "oh, I need more resource from my >> grand-grand-grandparent NOW!". In the case of overclaiming, it's enough >> if any one in the chain shrinks their resources, the effect is visible >> in one cycle. > > think someone high in chain issues cert no longer covering youtube. > > randy So they did cover it for a while, then the resource was dropped from their cert, yes? That means that cert was revoked on that level, and a new one issued. Local issue, does not propagate, therefore can be fixed immediately. Robert From mlepinski@bbn.com Thu Nov 5 12:11:58 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACB33A67AB for ; Thu, 5 Nov 2009 12: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=[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 nQRlD-Ws+Asi for ; Thu, 5 Nov 2009 12:11:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5FF253A68A0 for ; Thu, 5 Nov 2009 12:11:56 -0800 (PST) Received: from mail.bbn.com ([128.33.0.48]) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1N68gs-0003EJ-Au; Thu, 05 Nov 2009 15:12:18 -0500 Received: from [128.89.255.173] (helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N68gs-00071o-5T; Thu, 05 Nov 2009 15:12:18 -0500 Message-ID: <4AF330AC.7040809@bbn.com> Date: Thu, 05 Nov 2009 15:08:12 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandra Murphy References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <11856BC4-5462-4AB1-A175-D6D70EE10B63@apnic.net> <89658BEC-0F8E-44E6-81E9-5010A1FF7523@tcb.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr-arch-09 refresh cycle time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:11:58 -0000 With regards to the frequency with which relying parties fetch data from the repository system (be that authoritative publication points or caches operated by ISPs or RIRs), there appears to be a trade-off between "max time to fix a problem" vs "work required by the repository system and the relying parties". From this thread, it seems that there isn't an obvious right answer with regards to how often relying parties should query the repository system, but that there are risks associated with queries that are too frequent or too infrequent. To me, it seems that the best way to address this problem is to publish an "operational practices" document of some sort that documents this (and other) operational concerns and recommends practices to mitigate such risks. [That is, Sandy's (b) option]. With regards to the architecture document (which I would very much like to see leave the working group in near future), I believe the best way forward is for the architecture document to be silent on this issue. For example, consider the following text for Section 6 (last paragraph on page 15 of the arch-09): "Note that since relying parties will perform these operations regularly, it is more efficient for the relying party to request from the repository system only those objects that have changed since the relying party last updated its local cache. A relying party shall choose the frequency with which it downloads and validates updates from the repository system." - Matt Lepinski Sandra Murphy wrote: > I can understand these concerns. > > Would you rather see the wg try: > > (a) concentrated redesign (to what, I have no idea) > > (b) operational guidance to operators of how to manage this risk - get > new certs out before the route that relies on it, > etc. (There's already been discussion of an operational use document.) > > (c) create a way to carry info inband for emergencies (transitively - > inducing work even on those who do not yet understand during initial > deployment). > > Which of these (or something else) is the right wg direction, in your > mind? > > --Sandy > > > On Sat, 31 Oct 2009, Jared Mauch wrote: > >> On Oct 31, 2009, at 10:07 AM, Danny McPherson wrote: >> >>> >>> One might suspect there are some things we can learn from >>> this: >>> >>> http://tools.ietf.org/html/rfc4641 >>> >>> In particular, when *contrasting* even initial operational >>> practices with preceding recommendations made in theoretical >>> environments, a disparity usually emerges. >>> >>> I share concerns about frequency of publication and fetching >>> functions. In particular, this was one of the larger reasons >>> why folks stopped using IRR-based prefix lists in practice. It's >>> a real PITA when intermediate ASes haven't updated policies for >>> newly announced prefixes in a stateful protocol such as BGP. The >>> originator announces the route, the route is dropped by peers >>> because it's not permitted in the import policy, then the policy >>> is updated eventually after corresponding IRR objects were fetched >>> and the route is now permitted in policy, but stateful BGP doesn't >>> reannounce the route, so the route had to be "bounced" somehow >>> along the path, or at the origin, or a session reset to trigger >>> a new update once the policy has been updated. >>> >>> Of course, we have BGP route refresh today, and implementations >>> arguably should store an "invalid" route in an Adj-RIB-In and >>> denote as such - but that does introduce cost (and a potential >>> attack vector) as well. As Randy pointed out, and Curtis and I >>> have stated (and lived firsthand together :-/) many times, the >>> ripple effects associated with disjoint and autonomous application >>> of policy derived from IRR (or RPKI) like systems are quite an >>> operations nightmare in practice, and should be given heavy >>> consideration here. >> >> >> I certainly echo these comments and concerns. >> >> - Jared _______________________________________________ >> 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 Sandra.Murphy@cobham.com Thu Nov 5 12:22:50 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982B33A691D for ; Thu, 5 Nov 2009 12:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 Ikrmy2P0AalU for ; Thu, 5 Nov 2009 12:22:49 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9FE9E3A67AF for ; Thu, 5 Nov 2009 12:22: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 nA5KNBsP005445 for ; Thu, 5 Nov 2009 14:23:11 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA5KNBco023994 for ; Thu, 5 Nov 2009 14:23:11 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.77]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 15:22:51 -0500 Date: Thu, 5 Nov 2009 16:22:51 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Nov 2009 20:22:51.0976 (UTC) FILETIME=[BFFD4C80:01CA5E55] Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:22:50 -0000 As I review the thread, there were two calls for adoption (one from a co-author), one call for non-adoption, two responders that were uncertain because of the IPR issues, and three calls for identification of differences between the pfx-validate draft and roa-validation. Then there followed a discusion of the content of the draft, not the adoption of the draft. (I'm sorry to say that I participated in that.) That discussion effectively hijacked the thread. I can't call that wg consensus for adoption. Neither can I call it rejection of the idea of adoption. It is clear to me that there is considerable interest in this topic in the wg. The wg would like to understand the validation approach(es) more completely. I believe that the validation approach is extremely important to BGP security and clear specification of the validation approach is needed for interoperability. Would the authors prefer to describe, compare, and contrast their validation algorithms for the working group? Would they prefer that some volunteer do that? --Sandy On Tue, 27 Oct 2009, Sandra Murphy wrote: > > I am opening a two week wg call for comments on the adoption of this document > as a working group item. > > This is a new version of the draft that was presented at the last IETF > meeting (http://tools.ietf.org/agenda/75/slides/sidr-8.pdf). Potential > adoption of the pfx-validate draft as a working group document was mentioned > at that time. > > The document is available at: > > http://www.ietf.org/id/draft-pmohapat-sidr-pfx-validate-03.txt > > Please respond, either accept or not accept, by Tues Nov 3 2009. > > As usual, the rules are that silence does not indicate assent, so please > actively reply. > > If you support adoption of this draft as a working group item, please also > indicate whether you will be able to work on the draft (contribute or > review). > > --Sandy > > > On Tue, 27 Oct 2009, Pradosh Mohapatra (pmohapat) wrote: > >> The authors would like to request that >> draft-pmohapat-sidr-pfx-validate-03.txt be adopted as a SIDR WG >> document. >> >> Thanks, >> - Pradosh >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > From mlepinski@bbn.com Thu Nov 5 12:50:17 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E593A63D3 for ; Thu, 5 Nov 2009 12:50:17 -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 7vnriy9feTPm for ; Thu, 5 Nov 2009 12:50:16 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 037C53A68C8 for ; Thu, 5 Nov 2009 12:50:16 -0800 (PST) Received: from mail.bbn.com ([128.33.0.48]) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1N69Hx-0004Bv-B8; Thu, 05 Nov 2009 15:50:37 -0500 Received: from [128.89.255.173] (helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N69Hx-0003i0-81; Thu, 05 Nov 2009 15:50:37 -0500 Message-ID: <4AF339A7.9020504@bbn.com> Date: Thu, 05 Nov 2009 15:46:31 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terry Manderson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-roa-format-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 20:50:17 -0000 Terry, Can you elaborate on what you'd like to see in section 3 of the document? My interpretation of your comment is that you would like to see a prescribed (or recommended) order for the checks performed in ROA validation. I am reluctant to put in such a prescribed ordering in this document for two reasons: (1) It doesn't affect ROA semantics or the interoperation of relying party software with ROA producing software; (2) I don't think there is an obviously correct order (in particular, there exist multiple relying party implementations today and I do not believe that they all perform the checks in the same order). With regards to number (2) above, to minimize the time to process a set of ROAs one must consider both the probability that a check succeeds (in general, checks that are likely to fail should be performed sooner) and the cost of performing a given check at a given point in the processing (in general, inexpensive checks should be performed before expensive ones). The former probability depends on the population of invalid ROAs (e.g., what will be the greatest source of invalid ROAs in the system? ... perhaps expired/revoked end-entity certificates?) The latter cost is highly implementation dependent (e.g., the cost to validate the end-entity certificate will greatly depend on the data structures that are used to store and process certificates). In any case, if the working group feels that there is a clear recommended processing order that we can provide in Section 3 that will increase the likelihood the implementors produce efficient software, then please send some text and I'd be happy to insert it. - Matt Lepinski Terry Manderson wrote: >I support this document going forward. > >the only comment I have is that I'd prefer to see a preference order in >validation (section 3) to help relying party S/W writers to make efficient >choices in the validation path - but that isn't a stopping block for me. > >Cheers >Terry > >On 28/10/09 12:48 PM, "Geoff Huston" wrote: > > > >>The WG chairs have received a Working Group Last Call request from the >>authors of draft-ietf-sidr-roa-format-06.txt. >> >>The document (and the draft history) is at >>http://tools.ietf.org/html/draft-ietf-sidr-roa-format-06 >> >>The Last Call will end as of the close of business on Monday 23rd >>November - this is a longer period than a conventional 2 week last >>call period in order to include the forthcoming SIDR WG meeting at >>IETF 76. >> >>The intended status of this document is proposed standard. >> >>As usual, please address all comments to the WG mailing list, and >>please be clear in your comments to this last call if you are >>supporting the document's submission to the IESG or if you are >>opposed, or if you are not expressing a view either way. As there are >>a number of documents that are being last-called at this point in time >>it would be appreciated if responses could clearly identify which >>document is being referred to. >> >>Also with this note I would like to request the document's authors to >>prepare an interoperability report. >> >>Thanks, >> >> Geoff >> >> WG Co-CHair hat ON >> >>_______________________________________________ >>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 terry.manderson@icann.org Thu Nov 5 15:54:24 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1050E28C10D for ; Thu, 5 Nov 2009 15:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 6Xv+kYXJVQxr for ; Thu, 5 Nov 2009 15:54:23 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 523A528C0CF for ; Thu, 5 Nov 2009 15:54:23 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 5 Nov 2009 15:54:46 -0800 From: Terry Manderson To: Matt Lepinski Date: Thu, 5 Nov 2009 15:54:44 -0800 Thread-Topic: [sidr] Working Group Last Call - draft-ietf-sidr-roa-format-06.txt Thread-Index: AcpeWa32iAmonsJbT3O+wGt+f8WPXQAGar87 Message-ID: In-Reply-To: <4AF339A7.9020504@bbn.com> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-roa-format-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:54:24 -0000 Matt, In hindsight I think that any recommendations of ordering should exist in some other document (akin to the one you alluded to in the thread on sidr-arch-09 refresh cycle) which covers more operational aspects. Cheers Terry On 6/11/09 6:46 AM, "Matt Lepinski" wrote: > Terry, >=20 > Can you elaborate on what you'd like to see in section 3 of the document? >=20 [..] >=20 > In any case, if the working group feels that there is a clear > recommended processing order that we can provide in Section 3 that will > increase the likelihood the implementors produce efficient software, > then please send some text and I'd be happy to insert it. >=20 > - Matt Lepinski >=20 From terry.manderson@icann.org Thu Nov 5 15:54:24 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E816A28C10D for ; Thu, 5 Nov 2009 15:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Hgu7xfxfL43K for ; Thu, 5 Nov 2009 15:54:24 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 494B328C0CF for ; Thu, 5 Nov 2009 15:54:24 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 5 Nov 2009 15:54:47 -0800 From: Terry Manderson To: Matt Lepinski , Sandra Murphy Date: Thu, 5 Nov 2009 15:54:45 -0800 Thread-Topic: [sidr] sidr-arch-09 refresh cycle time Thread-Index: AcpeVFblBq0WMacXTQikNgsA9C6KJgAHwKl9 Message-ID: In-Reply-To: <4AF330AC.7040809@bbn.com> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] sidr-arch-09 refresh cycle time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 23:54:25 -0000 Matt, I think this is sensible. Terry On 6/11/09 6:08 AM, "Matt Lepinski" wrote: >=20 > "Note that since relying parties will perform these operations > regularly, it is more efficient for the relying party to request from > the repository system only those objects that have changed since the > relying party last updated its local cache. A relying party shall > choose the frequency with which it downloads and validates updates > from the repository system." >=20 >=20 From gih@apnic.net Fri Nov 6 01:03:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F9228C146 for ; Fri, 6 Nov 2009 01:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NlQ2YZPyimm for ; Fri, 6 Nov 2009 01:03:57 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 0FE3928C122 for ; Fri, 6 Nov 2009 01:03:56 -0800 (PST) Received: from dynamic135.apnic.net (dynamic135.apnic.net [203.119.42.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 763BFD58FB; Fri, 6 Nov 2009 19:13:14 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 6 Nov 2009 20:04:12 +1100 Message-Id: <6929FFAD-6200-4422-AE1C-05176A0139EC@apnic.net> To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [sidr] IETF 76 SIDR WG Agenda X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 09:03:57 -0000 Hi, There have been no further requests for changes after I had posted the draft agenda a few weeks back, so here's the agenda we'll run with on Monday with some likely timings added Could all presenters get their slides to myself and Sandy by Sunday PM (JP time!) so that they can be available online before the start of the SIDR session on Monday at 9:00 am See you then thanks, Geoff SIDR Working Group Chairs: Sandy Murphy, Geoff Huston Session: MONDAY, November 9, 2009 0900-1130 Morning Session I, Acacia 2 WG Resources: http://tools.ietf.org/wg/sidr/ Agenda: -- Administrivia (5 minutes) blue sheets, scribe victimization, etc. -- WG Document Status (75 minutes) Last Call Summary - chairs Reports on Updated WG Drafts (by the draft authors) RPKI Architecture - draft-ietf-sidr-arch-08.txt - Stephen Kent CP - draft-ietf-sidr-cp-06.txt - Stephen Kent CPS-IR - draft-ietf-sidr-cps-irs-04.txt - Stephen Kent CPS-ISP - draft-ietf-sidr-cps-isp-03.txt - Stephen Kent Manifests - draft-ietf-sidr-rpki-manifests-05.txt - Matt Lepinski ROA Format - draft-ietf-sidr-roa-format-05.txt - Matt Lepinski Repository Structure - draft-ietf-sidr-repos-struct-03.txt - George Michaelson Certificate Profile - draft-ietf-sidr-res-certs-17.txt - George Michaelson ROA Validation - draft-ietf-sidr-roa-validation-03.txt - George Michaelson TA - draft-ietf-sidr-ta-02.txt - George Michaelson Provisioning Protocol - draft-ietf-sidr-rescerts- provisioning-02.txt - Byron Ellacot RPKI Algorithms - draft-ietf-sidr-rpki-algs-00.txt - Geoff Huston -- New Work (30 minutes) Update on Use Cases - draft-manderson-sidr-usecases-01.txt - Terry Manderson Local TA Management - Steve Kent -- RPKI Operators Roundtable Report and Discussion (30+ minutes) Report - Ruediger Volk Discussion - John Schnizlein From kent@bbn.com Fri Nov 6 04:20:49 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079183A67F5 for ; Fri, 6 Nov 2009 04:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 HUUMhiB+6kKG for ; Fri, 6 Nov 2009 04:20:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5E57C3A67E1 for ; Fri, 6 Nov 2009 04:20:48 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.242.52.232]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N6NoU-0001ku-AK; Fri, 06 Nov 2009 07:21:10 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6929FFAD-6200-4422-AE1C-05176A0139EC@apnic.net> References: <6929FFAD-6200-4422-AE1C-05176A0139EC@apnic.net> Date: Fri, 6 Nov 2009 07:21:08 -0500 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] IETF 76 SIDR WG Agenda X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 12:20:49 -0000 Geoff, I will brief the CP status, but there have been no CPS changes, so I am not planning to discuss the CPS. Steve From wwwrun@core3.amsl.com Fri Nov 6 10:41:20 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 589C93A694F; Fri, 6 Nov 2009 10:41:20 -0800 (PST) To: ggm@apnic.net,gih@apnic.net From: IETF Secretariat Message-Id: <20091106184120.589C93A694F@core3.amsl.com> Date: Fri, 6 Nov 2009 10:41:20 -0800 (PST) Cc: sidr@ietf.org, adrian.farrel@huawei.com, sandy@tislabs.com, ipr-announce@ietf.org Subject: [sidr] Posting of IPR Disclosure related to Cisco's Statement of IPR claimed in draft-ietf-sidr-roa-validation-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 18:41:20 -0000 Dear George Michaelson, Geoff Huston: An IPR disclosure that pertains to your Internet-Draft entitled "Validation of Route Origination in BGP using the Resource Certificate PKI and ROAs" (draft-ietf-sidr-roa-validation) was submitted to the IETF Secretariat on 2009-11-02 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1204/). The title of the IPR disclosure is "Cisco's Statement of IPR claimed in draft-ietf-sidr-roa-validation-03.txt." The IETF Secretariat From ljb@merit.edu Fri Nov 6 12:54:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3EC028C1C4 for ; Fri, 6 Nov 2009 12:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 ccwB2mUe0U51 for ; Fri, 6 Nov 2009 12:54:43 -0800 (PST) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id 092E728C1C3 for ; Fri, 6 Nov 2009 12:54:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGsc9ErGbD6X/2dsb2JhbADOWYYYiEyEPgQ X-IronPort-AV: E=Sophos;i="4.44,695,1249272000"; d="scan'208";a="17215805" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Nov 2009 15:54:53 -0500 Message-ID: <4AF48D1C.4040107@merit.edu> Date: Fri, 06 Nov 2009 15:54:52 -0500 From: Larry Blunk User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: <742173602.6653341257195587203.JavaMail.root@crono>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 20:54:44 -0000 Sriram, I think you are missing my point. I'm aware of these sub-allocations, but I don't agree that providers SHOULD or MUST issue CA-Certs for these suballocations, which seems to be the assumption of some. Rather, it is my feeling that we can only assume the provider MAY issue a CA-Cert for the sub-allocations. If they choose not to issue a CA-Cert to a customer, I believe it is reasonable to assume they will still issue ROA's for the routes that are being announced by the customers at the time the ROA for the aggregate announcement is issued. I'm not fond of partial deployment scenarios where the more specifics are not registered until some unspecified later date. It will be difficult to go back and get all the more specifics registered later if there are significant numbers of them. It should be relatively straightforward to construct tools to assist providers with issuing ROA's for the more specifics at the time the ROA for the aggregate announcement is being issued. It's my understanding (please correct me if I'm wrong) that by issuing a CA-Cert a provider is not only giving the customer authority to register their own ROA's, but to also issue ROA's or CA-Cert's for customers of the customer (and so on). I suspect many providers would be reluctant to grant this level of authority over the PA space they have assigned. -Larry Sriram, Kotikalapudi wrote: > Larry: > > I appreciate the information/thoughts you have shared. > It would be fine if it (the ROA registrations) plays out the way you envision it should. > > As Sandy mentioned, there are instances of sub-suballocations and sub-sub-suballocations etc. > as can be gleaned from examples at this link: > http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20091030.1800.html > http://stats.research.icann.org/bgp/ > > Sriram > ________________________________________ > From: Sandra Murphy [sandy@sparta.com] > Sent: Monday, November 02, 2009 4:09 PM > To: Larry J. Blunk > Cc: Sriram, Kotikalapudi; sidr@ietf.org > Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document > > On Mon, 2 Nov 2009, Larry J. Blunk wrote: > > >> ----- "Sandra Murphy" wrote: >> >> >>> On Mon, 2 Nov 2009, Larry Blunk wrote: >>> >>> >>>> Sriram, Kotikalapudi wrote: >>>> > > > > >> If you are using PA space to multihome, >> then you are going to have to play by the provider's rules. >> If the provider does not allow multihoming using their >> space, that's their right. You can either get PI >> space or get another provider. Do you think clueless >> customers will want to deal with signing ROA's? In >> most cases, I suspect not. If a provider allows customers >> to multi-home from the provider's address space, it seems eminently >> reasonable that they would also be willing to sign ROA's >> for that space with the customer's AS. Why wouldn't they? >> >> In the case of multi-origin multi-homing using PA >> space, you are talking about a very small subset. >> For the providers who allow such configurations, yes >> I fully expect them to sign the ROA's. Be aware that >> many providers will simply tell customers to go get >> their own AS and/or their own PI space. >> > > This fits my model and what several others have suggested as well. > > What is your opinion of a level down from there - clueless customers > multihomed clueless customers? I've heard that while a relationship > exists between provider and customer, that's not likely between provider > and customer's customers through which the ROAs could be requested or > automatically created on certain events. > > (Not expressing an opinion here, just exploring the wg's opinion.) > > --Sandy > > >> -Larry >> >> >> >> > > > From ggm@apnic.net Fri Nov 6 14:26:01 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076DC3A67FA for ; Fri, 6 Nov 2009 14:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.25 X-Spam-Level: ** X-Spam-Status: No, score=2.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, RELAY_IS_222=2.179] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1tBFYtb+c9z for ; Fri, 6 Nov 2009 14:26:00 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4A4E93A67AD for ; Fri, 6 Nov 2009 14:25:59 -0800 (PST) Received: from [222.128.255.149] (unknown [222.128.255.149]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4A98AD58FF; Sat, 7 Nov 2009 08:35:21 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: George Michaelson In-Reply-To: <4AF291C2.6000103@ripe.net> Date: Sat, 7 Nov 2009 06:26:16 +0800 Content-Transfer-Encoding: 7bit Message-Id: <85B2D08D-62B3-4CDA-B8BA-E2357AEAE805@apnic.net> References: <4AF291C2.6000103@ripe.net> To: Robert Kisteleki X-Mailer: Apple Mail (2.1076) Cc: "sidr@ietf.org" Subject: Re: [sidr] TA questions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:26:01 -0000 On 05/11/2009, at 4:50 PM, Robert Kisteleki wrote: > Hi, > > I'm proxying two questions from our development team regarding the > TA draft: > > 1) How do the authors envision key roll overs for the RTA? > > Even though the draft allows for re-publication of the self-signed > RTA with new resources, it does not seem to address key roll overs > for that RTA. It seems one would have to publish a new ETA to > support this, which would make invalidating the previous RTA (if > that's ever needed) difficult. Nowhere in the document does it say that the ETA and RTA keys are linked. Therefore it's not clear to me *WHY* the ETA has to necessarily roll when an RTA re-keys. If an RTA publisher wanted to roll their RTA key, then it seems feasible by having the ETA simply use the key conservatively and assume an indefinite lifetime. The important caveat is that the RTA should be treated with the same level of respect as any trust anchor. > > 2) Can we have a more clear pointer the RTACMS object for relying > parties? > > The current proposal has the ETA CA point to a directory. See page 7 > of the draft for an ascii-art representation of this. This means > that relying parties will have to find the actual RTACMS object in > this directory themselves. Probably rsync the whole thing and loop > over the entries to figure out which is which. Robert, the ETA certificate has an SIA. The ETA SIA *should* point to a directory, which will contain a CMS object, and a CRL. It *can* contain the ETA too. What else does this directory contain, that a relying party is not interested in seeing? Relying party software, assuming it trusts this ETA, periodically scans this SIA space and picks up all valid CMS signed objects and loads the payload RTAs, again assuming that it trusts the ETA. It needs to see the CRL too. CMS is quite recognisable, testable, provable. Thats the whole point. The ETA can be signing over more than one RTA (for instance, key rollover) so there can be more than one CMS bundle to be seen, signed by the ETA. -George From jared@puck.nether.net Fri Nov 6 14:50:41 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECBD3A682A for ; Fri, 6 Nov 2009 14:50:41 -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 wlyOi75v8Qiv for ; Fri, 6 Nov 2009 14:50:27 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 71A093A67B0 for ; Fri, 6 Nov 2009 14:50:27 -0800 (PST) Received: from [192.168.1.194] (211-9-51-233.cust.bit-drive.ne.jp [211.9.51.233]) (authenticated bits=0) by puck.nether.net (8.14.3/8.12.9) with ESMTP id nA6MpPkt003065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Nov 2009 17:51:27 -0500 (EST) (envelope-from jared@puck.nether.net) Message-Id: From: Jared Mauch To: Larry Blunk In-Reply-To: <4AF48D1C.4040107@merit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 7 Nov 2009 07:21:11 +0900 References: <742173602.6653341257195587203.JavaMail.root@crono>, <4AF48D1C.4040107@merit.edu> X-Mailer: iPhone Mail (7D11) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (puck.nether.net [204.42.254.5]); Fri, 06 Nov 2009 17:51:28 -0500 (EST) Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:50:41 -0000 I share the comments and concerns of Larry but want to take it a step further. There will not be anything but partial deployment for years to come. Trying to transfer costs to ISPs that are unwilling or unable to issue certs is going to be an ongoing challenge. See everyone soon! Jared Mauch On Nov 7, 2009, at 5:54 AM, Larry Blunk wrote: > > Sriram, > I think you are missing my point. I'm aware of these > sub-allocations, but I don't agree that providers SHOULD > or MUST issue CA-Certs for these suballocations, which seems > to be the assumption of some. Rather, it is my feeling > that we can only assume the provider MAY issue a CA-Cert for > the sub-allocations. > > If they choose not to issue a CA-Cert to a customer, I believe it is > reasonable to assume they will still issue ROA's for the routes > that are being announced by the customers at the time the ROA > for the aggregate announcement is issued. I'm not fond > of partial deployment scenarios where the more specifics > are not registered until some unspecified later date. It will be > difficult to go back and get all the more specifics registered > later if there are significant numbers of them. It should be > relatively straightforward to construct tools to assist providers > with issuing ROA's for the more specifics at the time the ROA > for the aggregate announcement is being issued. > > It's my understanding (please correct me if I'm wrong) > that by issuing a CA-Cert a provider is > not only giving the customer authority to register their own > ROA's, but to also issue ROA's or CA-Cert's for > customers of the customer (and so on). I suspect many providers > would > be reluctant to grant this level of authority over the PA space > they have assigned. > > > -Larry > > > > Sriram, Kotikalapudi wrote: >> Larry: >> >> I appreciate the information/thoughts you have shared. It would be >> fine if it (the ROA registrations) plays out the way you envision >> it should. >> >> As Sandy mentioned, there are instances of sub-suballocations and >> sub-sub-suballocations etc. as can be gleaned from examples at this >> link: >> http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20091030.1800.html >> http://stats.research.icann.org/bgp/ >> >> Sriram >> ________________________________________ >> From: Sandra Murphy [sandy@sparta.com] >> Sent: Monday, November 02, 2009 4:09 PM >> To: Larry J. Blunk >> Cc: Sriram, Kotikalapudi; sidr@ietf.org >> Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR >> WG document >> >> On Mon, 2 Nov 2009, Larry J. Blunk wrote: >> >> >>> ----- "Sandra Murphy" wrote: >>> >>> >>>> On Mon, 2 Nov 2009, Larry Blunk wrote: >>>> >>>> >>>>> Sriram, Kotikalapudi wrote: >>>>> >> >> >> >> >>> If you are using PA space to multihome, >>> then you are going to have to play by the provider's rules. >>> If the provider does not allow multihoming using their >>> space, that's their right. You can either get PI >>> space or get another provider. Do you think clueless >>> customers will want to deal with signing ROA's? In >>> most cases, I suspect not. If a provider allows customers >>> to multi-home from the provider's address space, it seems eminently >>> reasonable that they would also be willing to sign ROA's >>> for that space with the customer's AS. Why wouldn't they? >>> >>> In the case of multi-origin multi-homing using PA >>> space, you are talking about a very small subset. >>> For the providers who allow such configurations, yes >>> I fully expect them to sign the ROA's. Be aware that >>> many providers will simply tell customers to go get >>> their own AS and/or their own PI space. >>> >> >> This fits my model and what several others have suggested as well. >> >> What is your opinion of a level down from there - clueless customers >> multihomed clueless customers? I've heard that while a relationship >> exists between provider and customer, that's not likely between >> provider >> and customer's customers through which the ROAs could be requested or >> automatically created on certain events. >> >> (Not expressing an opinion here, just exploring the wg's opinion.) >> >> --Sandy >> >> >>> -Larry >>> >>> >>> >>> >> >> >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From ljb@merit.edu Fri Nov 6 17:06:34 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16CB3A690F for ; Fri, 6 Nov 2009 17:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 XAhvfQOAeVhS for ; Fri, 6 Nov 2009 17:06:33 -0800 (PST) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id 8D8D23A68F9 for ; Fri, 6 Nov 2009 17:06:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 18EF5225711; Fri, 6 Nov 2009 20:06:57 -0500 (EST) X-Virus-Scanned: amavisd-new at magus.merit.edu Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XONlRryj0oPW; Fri, 6 Nov 2009 20:06:56 -0500 (EST) Received: from crono.merit.edu (crono.merit.edu [198.108.1.12]) by magus.merit.edu (Postfix) with ESMTP id 7D1D4225326; Fri, 6 Nov 2009 20:06:56 -0500 (EST) Date: Fri, 6 Nov 2009 20:06:56 -0500 (EST) From: "Larry J. Blunk" To: Jared Mauch Message-ID: <559456921.7184541257556016379.JavaMail.root@crono> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [198.108.1.13] X-Mailer: Zimbra 5.0.18_GA_3011.SLES10_64 (ZimbraWebClient - FF3.0 (Win)/5.0.18_GA_3011.SLES10_64) Cc: Kotikalapudi Sriram , sidr@ietf.org Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 01:06:35 -0000 Sorry, should have provided more context. I was referring to the particular "Partial Adoption" scenario presented in http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf. Where more specifics of a registered ROA (that do not not have a matching ROA) are not invalidated for a certain grace period. This dramatically limits the value of ROA's and it will be difficult to end the grace period if there are significant numbers of more specifics of ROA's that are unregistered. It seems to me if you are unprepared to register ROA's for all the more specifics of an aggregate ROA, it would be better to hold off on registering the ROA for the aggregate until all the more specific ROA's are in place. -Larry a certain grace period. ----- "Jared Mauch" wrote: > I share the comments and concerns of Larry but want to take it a step > > further. There will not be anything but partial deployment for years > > to come. Trying to transfer costs to ISPs that are unwilling or unable > > to issue certs is going to be an ongoing challenge. > > See everyone soon! > > Jared Mauch > > On Nov 7, 2009, at 5:54 AM, Larry Blunk wrote: > > > > > Sriram, > > I think you are missing my point. I'm aware of these > > sub-allocations, but I don't agree that providers SHOULD > > or MUST issue CA-Certs for these suballocations, which seems > > to be the assumption of some. Rather, it is my feeling > > that we can only assume the provider MAY issue a CA-Cert for > > the sub-allocations. > > > > If they choose not to issue a CA-Cert to a customer, I believe it > is > > reasonable to assume they will still issue ROA's for the routes > > that are being announced by the customers at the time the ROA > > for the aggregate announcement is issued. I'm not fond > > of partial deployment scenarios where the more specifics > > are not registered until some unspecified later date. It will be > > difficult to go back and get all the more specifics registered > > later if there are significant numbers of them. It should be > > relatively straightforward to construct tools to assist providers > > with issuing ROA's for the more specifics at the time the ROA > > for the aggregate announcement is being issued. > > > > It's my understanding (please correct me if I'm wrong) > > that by issuing a CA-Cert a provider is > > not only giving the customer authority to register their own > > ROA's, but to also issue ROA's or CA-Cert's for > > customers of the customer (and so on). I suspect many providers > > would > > be reluctant to grant this level of authority over the PA space > > they have assigned. > > > > > > -Larry > > > > > > > > Sriram, Kotikalapudi wrote: > >> Larry: > >> > >> I appreciate the information/thoughts you have shared. It would be > > >> fine if it (the ROA registrations) plays out the way you envision > > >> it should. > >> > >> As Sandy mentioned, there are instances of sub-suballocations and > > >> sub-sub-suballocations etc. as can be gleaned from examples at this > > >> link: > >> > http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20091030.1800.html > >> http://stats.research.icann.org/bgp/ > >> > >> Sriram > >> ________________________________________ > >> From: Sandra Murphy [sandy@sparta.com] > >> Sent: Monday, November 02, 2009 4:09 PM > >> To: Larry J. Blunk > >> Cc: Sriram, Kotikalapudi; sidr@ietf.org > >> Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR > > >> WG document > >> > >> On Mon, 2 Nov 2009, Larry J. Blunk wrote: > >> > >> > >>> ----- "Sandra Murphy" wrote: > >>> > >>> > >>>> On Mon, 2 Nov 2009, Larry Blunk wrote: > >>>> > >>>> > >>>>> Sriram, Kotikalapudi wrote: > >>>>> > >> > >> > >> > >> > >>> If you are using PA space to multihome, > >>> then you are going to have to play by the provider's rules. > >>> If the provider does not allow multihoming using their > >>> space, that's their right. You can either get PI > >>> space or get another provider. Do you think clueless > >>> customers will want to deal with signing ROA's? In > >>> most cases, I suspect not. If a provider allows customers > >>> to multi-home from the provider's address space, it seems > eminently > >>> reasonable that they would also be willing to sign ROA's > >>> for that space with the customer's AS. Why wouldn't they? > >>> > >>> In the case of multi-origin multi-homing using PA > >>> space, you are talking about a very small subset. > >>> For the providers who allow such configurations, yes > >>> I fully expect them to sign the ROA's. Be aware that > >>> many providers will simply tell customers to go get > >>> their own AS and/or their own PI space. > >>> > >> > >> This fits my model and what several others have suggested as well. > >> > >> What is your opinion of a level down from there - clueless > customers > >> multihomed clueless customers? I've heard that while a > relationship > >> exists between provider and customer, that's not likely between > >> provider > >> and customer's customers through which the ROAs could be requested > or > >> automatically created on certain events. > >> > >> (Not expressing an opinion here, just exploring the wg's opinion.) > >> > >> --Sandy > >> > >> > >>> -Larry > >>> > >>> > >>> > >>> > >> > >> > >> > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Fri Nov 6 18:56:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94A63A679F for ; Fri, 6 Nov 2009 18:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 zWA4ijwF6UZH for ; Fri, 6 Nov 2009 18:56:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BF1083A6835 for ; Fri, 6 Nov 2009 18:56:56 -0800 (PST) Received: from ip67-91-170-251.z170-91-67.customer.algx.net ([67.91.170.251] helo=rmac.local) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N6bUM-000DBa-7u; Sat, 07 Nov 2009 02:57:18 +0000 Message-ID: <4AF4E20D.5010503@psg.com> Date: Fri, 06 Nov 2009 20:57:17 -0600 From: Randy Bush User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Larry J. Blunk" References: <559456921.7184541257556016379.JavaMail.root@crono> In-Reply-To: <559456921.7184541257556016379.JavaMail.root@crono> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 02:56:57 -0000 > It seems to me if you are unprepared to register ROA's for > all the more specifics of an aggregate ROA, it would be better > to hold off on registering the ROA for the aggregate until all > the more specific ROA's are in place. of course. which is why i will issue roas for those of my children too occupied with other things to do it for themselves. because i certainly want to roa the aggregate to prevent hijacking of static customers, my own infrastructure, and unused space without having to issue 42 stupid little roas. randy From robert@ripe.net Sat Nov 7 01:23:23 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350F228C0EB for ; Sat, 7 Nov 2009 01:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.17 X-Spam-Level: X-Spam-Status: No, score=-4.17 tagged_above=-999 required=5 tests=[AWL=-3.429, 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 67SWa6SQhemQ for ; Sat, 7 Nov 2009 01:23:22 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 1874D28C0E9 for ; Sat, 7 Nov 2009 01:23:22 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N6hWB-00056t-Dx; Sat, 07 Nov 2009 10:23:40 +0100 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 7F7CE2F583; Sat, 7 Nov 2009 10:23:34 +0100 (CET) Message-ID: <4AF53C94.6070307@ripe.net> Date: Sat, 07 Nov 2009 18:23:32 +0900 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: George Michaelson References: <4AF291C2.6000103@ripe.net> <85B2D08D-62B3-4CDA-B8BA-E2357AEAE805@apnic.net> In-Reply-To: <85B2D08D-62B3-4CDA-B8BA-E2357AEAE805@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274b1db02f4a847118a091914b6c667243f Cc: "sidr@ietf.org" Subject: Re: [sidr] TA questions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 09:23:23 -0000 George Michaelson wrote: > > On 05/11/2009, at 4:50 PM, Robert Kisteleki wrote: > >> Hi, >> >> I'm proxying two questions from our development team regarding the TA >> draft: >> >> 1) How do the authors envision key roll overs for the RTA? >> >> Even though the draft allows for re-publication of the self-signed RTA >> with new resources, it does not seem to address key roll overs for >> that RTA. It seems one would have to publish a new ETA to support >> this, which would make invalidating the previous RTA (if that's ever >> needed) difficult. > > Nowhere in the document does it say that the ETA and RTA keys are > linked. Therefore it's not clear to me *WHY* the ETA has to necessarily > roll when an RTA re-keys. > > If an RTA publisher wanted to roll their RTA key, then it seems feasible > by having the ETA simply use the key conservatively and assume an > indefinite lifetime. The important caveat is that the RTA should be > treated with the same level of respect as any trust anchor. The document does say that there is one SIA for the ETA. It also says that one CMS bag can contain exactly one RTA. So the only option to publish more RTAs (while doing a rollover, or just because) is to publish multiple bags at the SIA location. Is that the intention? I'm wondering if that's enough if the RTA needs an unplanned key rollover, for which there could be better support. >> 2) Can we have a more clear pointer the RTACMS object for relying >> parties? >> >> The current proposal has the ETA CA point to a directory. See page 7 >> of the draft for an ascii-art representation of this. This means that >> relying parties will have to find the actual RTACMS object in this >> directory themselves. Probably rsync the whole thing and loop over the >> entries to figure out which is which. > > Robert, the ETA certificate has an SIA. The ETA SIA *should* point to a > directory, which will contain a CMS object, and a CRL. It *can* contain > the ETA too. What else does this directory contain, that a relying party > is not interested in seeing? Perhaps an mpeg of the cat? Why does the RP need to download everything and check which one looks like a CMS object, which is a CRL and what's unimportant, after? > Relying party software, assuming it trusts this ETA, periodically scans > this SIA space and picks up all valid CMS signed objects and loads the > payload RTAs, again assuming that it trusts the ETA. It needs to see the > CRL too. > > CMS is quite recognisable, testable, provable. Thats the whole point. > The ETA can be signing over more than one RTA (for instance, key > rollover) so there can be more than one CMS bundle to be seen, signed by > the ETA. The document is not clear on whether there could be multiple CMS bags in the directory pointed to by the ETA SIA. But even when this is corrected, we still have the recognition problem stated above. This is what I'm after here. Robert > -George From sra@hactrn.net Sat Nov 7 04:52:17 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17113A6801 for ; Sat, 7 Nov 2009 04:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkzuRTD-hhk2 for ; Sat, 7 Nov 2009 04:52:12 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id B2E823A67B8 for ; Sat, 7 Nov 2009 04:52:11 -0800 (PST) Received: from angband.hactrn.net (host-112-244.meeting.ietf.org [133.93.112.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 1CD932844C for ; Sat, 7 Nov 2009 12:52:35 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 8D31D15F111 for ; Fri, 6 Nov 2009 22:33:30 +0000 (UTC) Date: Sat, 07 Nov 2009 07:33:30 +0900 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4AE75809.4050808@bbn.com> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091106223330.8D31D15F111@angband.hactrn.net> Subject: Re: [sidr] sidr-arch-09 refresh cycle time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 12:52:17 -0000 [Catching up on back mail while in transit to Hiroshima...] At Tue, 27 Oct 2009 16:28:57 -0400, Matt Lepinski wrote: > > Here, I understand that "everyone hitting the repository system at once" > is a bad outcome regardless of the frequency that we recommend. That is, > regardless of whether we recommend "once per day", "once per month", or > "eight times daily" we will likely see problems with too much server > load at midnight. If anyone can recommend text to avoid this phenomena > (i.e., to encourage people to spread out their queries to the repository > system), please send text. FWIW: rcynic has a "jitter" mechanism which delays startup (and thus the rsync hit on servers) by a pseudo-random amount of time in the range [0..n], where n defaults to ten minutes. The important part is that this behavior is on by default, so a user has to read the documentation (or at least the usage message) to disable it. How much it helps, and whether a different value of n would be better, I dunno, but it was trivial to implement, and one could easily extend it slightly to log dire warnings or flat out refuse to run for too-small values of n. From Sandra.Murphy@cobham.com Sat Nov 7 08:28:46 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE633A6A1F for ; Sat, 7 Nov 2009 08:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXUUoUu+TINU for ; Sat, 7 Nov 2009 08:28:45 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4EC483A6A0B for ; Sat, 7 Nov 2009 08:28:45 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nA7GT9f0027560; Sat, 7 Nov 2009 10:29:09 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA7GT6Ix032402; Sat, 7 Nov 2009 10:29:06 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Nov 2009 11:26:23 -0500 Date: Sat, 7 Nov 2009 12:26:19 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Larry J. Blunk" In-Reply-To: <559456921.7184541257556016379.JavaMail.root@crono> Message-ID: References: <559456921.7184541257556016379.JavaMail.root@crono> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Nov 2009 16:26:23.0873 (UTC) FILETIME=[0C0C1710:01CA5FC7] Cc: sidr@ietf.org, Kotikalapudi Sriram Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 16:28:46 -0000 On Fri, 6 Nov 2009, Larry J. Blunk wrote: > > Sorry, should have provided more context. I was referring to > the particular "Partial Adoption" scenario presented in > http://www.antd.nist.gov/~ksriram/SIDR_ROA_BOA_Interpretation.pdf. > Where more specifics of a registered ROA (that do not not have > a matching ROA) are not invalidated for a certain grace period. > This dramatically limits the value of ROA's and it will be > difficult to end the grace period if there are significant > numbers of more specifics of ROA's that are unregistered. > > It seems to me if you are unprepared to register ROA's for > all the more specifics of an aggregate ROA, it would be better > to hold off on registering the ROA for the aggregate until all > the more specific ROA's are in place. I haven't figured out yet what you mean about registering ROAs for the more specifics. If you have sub-allocated to a customer and you want to register a ROA for that more specific, would you register the ROA with your AS or your customer's AS (or your customer's backup upstream). --Sandy > > -Larry > > > > a certain grace period. > > ----- "Jared Mauch" wrote: > >> I share the comments and concerns of Larry but want to take it a step >> >> further. There will not be anything but partial deployment for years >> >> to come. Trying to transfer costs to ISPs that are unwilling or unable >> >> to issue certs is going to be an ongoing challenge. >> >> See everyone soon! >> >> Jared Mauch >> >> On Nov 7, 2009, at 5:54 AM, Larry Blunk wrote: >> >>> >>> Sriram, >>> I think you are missing my point. I'm aware of these >>> sub-allocations, but I don't agree that providers SHOULD >>> or MUST issue CA-Certs for these suballocations, which seems >>> to be the assumption of some. Rather, it is my feeling >>> that we can only assume the provider MAY issue a CA-Cert for >>> the sub-allocations. >>> >>> If they choose not to issue a CA-Cert to a customer, I believe it >> is >>> reasonable to assume they will still issue ROA's for the routes >>> that are being announced by the customers at the time the ROA >>> for the aggregate announcement is issued. I'm not fond >>> of partial deployment scenarios where the more specifics >>> are not registered until some unspecified later date. It will be >>> difficult to go back and get all the more specifics registered >>> later if there are significant numbers of them. It should be >>> relatively straightforward to construct tools to assist providers >>> with issuing ROA's for the more specifics at the time the ROA >>> for the aggregate announcement is being issued. >>> >>> It's my understanding (please correct me if I'm wrong) >>> that by issuing a CA-Cert a provider is >>> not only giving the customer authority to register their own >>> ROA's, but to also issue ROA's or CA-Cert's for >>> customers of the customer (and so on). I suspect many providers >>> would >>> be reluctant to grant this level of authority over the PA space >>> they have assigned. >>> >>> >>> -Larry >>> >>> >>> >>> Sriram, Kotikalapudi wrote: >>>> Larry: >>>> >>>> I appreciate the information/thoughts you have shared. It would be >> >>>> fine if it (the ROA registrations) plays out the way you envision >> >>>> it should. >>>> >>>> As Sandy mentioned, there are instances of sub-suballocations and >> >>>> sub-sub-suballocations etc. as can be gleaned from examples at this >> >>>> link: >>>> >> http://stats.research.icann.org/bgp/cidr-map/origin-map.bgp.20091030.1800.html >>>> http://stats.research.icann.org/bgp/ >>>> >>>> Sriram >>>> ________________________________________ >>>> From: Sandra Murphy [sandy@sparta.com] >>>> Sent: Monday, November 02, 2009 4:09 PM >>>> To: Larry J. Blunk >>>> Cc: Sriram, Kotikalapudi; sidr@ietf.org >>>> Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR >> >>>> WG document >>>> >>>> On Mon, 2 Nov 2009, Larry J. Blunk wrote: >>>> >>>> >>>>> ----- "Sandra Murphy" wrote: >>>>> >>>>> >>>>>> On Mon, 2 Nov 2009, Larry Blunk wrote: >>>>>> >>>>>> >>>>>>> Sriram, Kotikalapudi wrote: >>>>>>> >>>> >>>> >>>> >>>> >>>>> If you are using PA space to multihome, >>>>> then you are going to have to play by the provider's rules. >>>>> If the provider does not allow multihoming using their >>>>> space, that's their right. You can either get PI >>>>> space or get another provider. Do you think clueless >>>>> customers will want to deal with signing ROA's? In >>>>> most cases, I suspect not. If a provider allows customers >>>>> to multi-home from the provider's address space, it seems >> eminently >>>>> reasonable that they would also be willing to sign ROA's >>>>> for that space with the customer's AS. Why wouldn't they? >>>>> >>>>> In the case of multi-origin multi-homing using PA >>>>> space, you are talking about a very small subset. >>>>> For the providers who allow such configurations, yes >>>>> I fully expect them to sign the ROA's. Be aware that >>>>> many providers will simply tell customers to go get >>>>> their own AS and/or their own PI space. >>>>> >>>> >>>> This fits my model and what several others have suggested as well. >>>> >>>> What is your opinion of a level down from there - clueless >> customers >>>> multihomed clueless customers? I've heard that while a >> relationship >>>> exists between provider and customer, that's not likely between >>>> provider >>>> and customer's customers through which the ROAs could be requested >> or >>>> automatically created on certain events. >>>> >>>> (Not expressing an opinion here, just exploring the wg's opinion.) >>>> >>>> --Sandy >>>> >>>> >>>>> -Larry >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 curtis@occnc.com Sat Nov 7 12:18:59 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D6428C1A0 for ; Sat, 7 Nov 2009 12:18:59 -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 9Z5tLEDjGwWI for ; Sat, 7 Nov 2009 12:18:59 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 9594F28C0F3 for ; Sat, 7 Nov 2009 12:18:55 -0800 (PST) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id nA7KJIsu036934; Sat, 7 Nov 2009 15:19:18 -0500 (EST) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <200911072019.nA7KJIsu036934@harbor.orleans.occnc.com> To: Larry Blunk From: Curtis Villamizar In-reply-to: Your message of "Fri, 06 Nov 2009 15:54:52 EST." <4AF48D1C.4040107@merit.edu> Date: Sat, 07 Nov 2009 15:19:18 -0500 Sender: curtis@occnc.com Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 20:18:59 -0000 In message <4AF48D1C.4040107@merit.edu> Larry Blunk writes: > > It's my understanding (please correct me if I'm wrong) > that by issuing a CA-Cert a provider is > not only giving the customer authority to register their own > ROA's, but to also issue ROA's or CA-Cert's for > customers of the customer (and so on). I suspect many providers would > be reluctant to grant this level of authority over the PA space > they have assigned. And the CA-Cert is not revokable? Curtis From roque@lacnic.net Sat Nov 7 14:01:43 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 133523A687C for ; Sat, 7 Nov 2009 14:01:43 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkEmPMQfpRkN for ; Sat, 7 Nov 2009 14:01:42 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id E52E23A67B6 for ; Sat, 7 Nov 2009 14:01:40 -0800 (PST) Received: from [IPv6:2001:dfb::112:225:4bff:fec7:7866] (unknown [IPv6:2001:dfb:0:112:225:4bff:fec7:7866]) by mail.lacnic.net.uy (Postfix) with ESMTP id 3BCF9308499; Sat, 7 Nov 2009 20:01:56 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-16-150114058 From: Roque Gagliano In-Reply-To: <85B2D08D-62B3-4CDA-B8BA-E2357AEAE805@apnic.net> Date: Sun, 8 Nov 2009 06:43:08 +0900 Message-Id: <3BEFC2E4-B923-4485-951C-B743CEADF444@lacnic.net> References: <4AF291C2.6000103@ripe.net> <85B2D08D-62B3-4CDA-B8BA-E2357AEAE805@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1076) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Cc: "sidr@ietf.org" Subject: [sidr] TA document review X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 22:01:43 -0000 --Apple-Mail-16-150114058 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, Here are some comments on the document, some reflects the conflict that Robert mentioned about being more clear that one EE ETA cert is valid at any particular time, some are typos. Roque. -------------------- 2.1. A Compound Trust Anchor Structure The ETA issues a CRL and one EE certificate. (Roque) I believe it needs to be explained that more than one ETA EE cert may be issued during the life-time of the ETA CA however at any particular moment there is only one valid EE cert. 4.2. RPKI Trust Anchor Object Validation 2. Use the public key in the EE certificate to verify the signature on the RTA Trust Anchor Object. (Roque) s/EE certificate/ETA EE certificate * Each time an RTA certificate is re-issued, or prior to the expiration of the ETA EE certificate, the ETA generates a Cryptographic Message Syntax (CMS) [RFC3852] signed-data object, the payload of which is an RTA certificate. (Roque) If the ETA EE cert validity period is identical to the RTA validity period as stated in a previous bullet, the second condition ("prior to the expiration of the ETA EE certificate") would be the same as in the following section: "If a trust anchor chooses to reissue its RTA certificate before the expiration of that certificate." 5. Relying Party use of Trust Anchor Material * The ETA's CRL and CMS objects are retrieved from the publication point referenced by the SIA in the ETA certificate. (Roque) s/CMS objects/CMS object Relying Parties SHOULD perform this retrieval and validation operation at intervals no less frequent than the nextUpdate time of the published ETA CRL, and SHOULD perform the retrieval operation prior to the expiration of the ETA EE certificate, or upon revocation of the ETA EE certificate. (Roque) If the retrieval operation is for both the CRL and the CMS, I do not understand the last sentence because the RP is not aware of the revocation until it has retrieve the CRL and in at that time it already has the new CMS. So, I would: s/, or upon revocation of the ETA EE certificate// -------------------- ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-16-150114058 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 2.1.  A Compound Trust Anchor = Structure

The ETA issues a CRL and = one EE certificate. 


4.2.  RPKI Trust Anchor Object = Validation

          signature on = the RTA Trust Anchor Object.



         = expiration of the ETA EE certificate, the ETA generates a
         object, the = payload of which is an RTA certificate.
(Roque) If the ETA EE cert validity period is = identical to the RTA validity period as stated in a previous bullet, the = second condition ("prior to the expiration of the ETA EE certificate") = would be the same as in the following section:
"If = a trust anchor chooses to reissue its RTA certificate before the = expiration of that certificate." 


      *  The = ETA's CRL and CMS objects are retrieved from the
(Roque) s/CMS objects/CMS = object

   operation at intervals no less = frequent than the nextUpdate time of
   the published ETA CRL, = and SHOULD perform the retrieval operation
   prior to the = expiration of the ETA EE certificate, or upon revocation
(Roque) If the retrieval operation is for both = the CRL and the CMS, I do not understand the last sentence because the = RP is not aware of the revocation until it has retrieve the CRL and in = at that time it already has the new CMS. So, I would:

s/, or upon revocation of the ETA = EE certificate//


------------------= --




-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE

= --Apple-Mail-16-150114058-- From roque@lacnic.net Sat Nov 7 14:01:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D93C28C112 for ; Sat, 7 Nov 2009 14:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 5ykucA7RrOBP for ; Sat, 7 Nov 2009 14:01:42 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [200.7.84.3]) by core3.amsl.com (Postfix) with ESMTP id B3EEB3A6826 for ; Sat, 7 Nov 2009 14:01:41 -0800 (PST) Received: from [IPv6:2001:dfb::112:225:4bff:fec7:7866] (unknown [IPv6:2001:dfb:0:112:225:4bff:fec7:7866]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7CFDD3084E8; Sat, 7 Nov 2009 20:02:04 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-17-150166768 From: Roque Gagliano In-Reply-To: Date: Sun, 8 Nov 2009 06:44:00 +0900 Message-Id: References: <34E65839-50AA-401B-84AD-9B78D3B4B1AD@istaff.org> <3FED2E21-9C78-484D-8D26-10B3F8A4106A@istaff.org> <9DCA8161-5A5D-4B04-A2A8-34B340214F41@istaff.org> To: Randy Bush X-Mailer: Apple Mail (2.1076) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: roque@lacnic.net Cc: sidr@ietf.org Subject: Re: [sidr] CP changes in response to WGLC comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 22:01:48 -0000 --Apple-Mail-17-150166768 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Randy, > > following this line of thought, should an rpki provider be required to > give a significant re-parenting time window before stopping service? > Wouldn't that be part of their private contractual relationship? Roque > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --Apple-Mail-17-150166768 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

following this = line of thought, should an rpki provider be required to
give a = significant re-parenting time window before stopping = service?


Wouldn't that be = part of their private contractual = relationship? 

Roque

randy
______________________________________________= _
sidr mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr



-------------------------------------------------------------<= /div>
Roque Gagliano
LACNIC
GPG = Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 = 6CEE

= --Apple-Mail-17-150166768-- From kent@bbn.com Sat Nov 7 16:28:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBD23A67D3 for ; Sat, 7 Nov 2009 16:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 69UjLo4NLuDN for ; Sat, 7 Nov 2009 16:28:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8BEE73A67F0 for ; Sat, 7 Nov 2009 16:28:47 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.112.234]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N6veU-0003ww-B3; Sat, 07 Nov 2009 19:29:06 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <200911072019.nA7KJIsu036934@harbor.orleans.occnc.com> References: <200911072019.nA7KJIsu036934@harbor.orleans.occnc.com> Date: Sat, 7 Nov 2009 19:10:25 -0500 To: curtis@occnc.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 00:28:48 -0000 At 3:19 PM -0500 11/7/09, Curtis Villamizar wrote: >In message <4AF48D1C.4040107@merit.edu> >Larry Blunk writes: >> >> It's my understanding (please correct me if I'm wrong) >> that by issuing a CA-Cert a provider is >> not only giving the customer authority to register their own >> ROA's, but to also issue ROA's or CA-Cert's for >> customers of the customer (and so on). I suspect many providers would >> be reluctant to grant this level of authority over the PA space >> they have assigned. > > >And the CA-Cert is not revokable? > >Curtis Yes, the CA cert can be revoked. Also, if we wanted to provide the ISP with additional controls, there is a cert path length as part of the basic constraints extension that is in the RPKI profile (although the path length field is currently deprecated). This field allows an issuer to restrict the issuance of CA certs below the CA certs that it issued. Steve From robert@ripe.net Sat Nov 7 19:03:41 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9A43A6905 for ; Sat, 7 Nov 2009 19:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.718 X-Spam-Level: X-Spam-Status: No, score=-8.718 tagged_above=-999 required=5 tests=[AWL=1.881, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yikbtauz3fgh for ; Sat, 7 Nov 2009 19:03:40 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 439BC3A67CF for ; Sat, 7 Nov 2009 19:03:40 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N6y4I-0007WA-Ei; Sun, 08 Nov 2009 04:04:00 +0100 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 3C6F62F583; Sun, 8 Nov 2009 04:03:52 +0100 (CET) Message-ID: <4AF63517.3000605@ripe.net> Date: Sun, 08 Nov 2009 12:03:51 +0900 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roque Gagliano References: <4AF291C2.6000103@ripe.net> <85B2D08D-62B3-4CDA-B8BA-E2357AEAE805@apnic.net> <3BEFC2E4-B923-4485-951C-B743CEADF444@lacnic.net> In-Reply-To: <3BEFC2E4-B923-4485-951C-B743CEADF444@lacnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2740a08001fa1d71e63e247bed126110587 Cc: George Michaelson , "sidr@ietf.org" Subject: Re: [sidr] TA document review X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 03:03:41 -0000 Roque Gagliano wrote: > 2.1. A Compound Trust Anchor Structure > > The ETA issues a CRL and one EE certificate. > > (Roque) I believe it needs to be explained that more than one ETA EE > cert may be issued during the life-time of the ETA CA however at any > particular moment there is only one valid EE cert. In light of the recent discussion, this is not necessarily true. If (I mean, if) the solution to multiple RTAs is multiple CMS objects, then ther wil be multiple ETA EEs. Note that I'm not in favor of that solution, but we're not yet in solution space. > 5. Relying Party use of Trust Anchor Material > > * The ETA's CRL and CMS objects are retrieved from the > publication point referenced by the SIA in the ETA certificate. > (Roque) s/CMS objects/CMS object Probably not, see above. There may be multiple CMS objects and one CRL. Robert From randy@psg.com Sun Nov 8 02:03:51 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA173A69E4 for ; Sun, 8 Nov 2009 02:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 o7inLjHz3TQu for ; Sun, 8 Nov 2009 02:03:45 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id BE0ED3A687F for ; Sun, 8 Nov 2009 02:03:45 -0800 (PST) Received: from 167.103.180.203.e.iijmobile.jp ([203.180.103.167]) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N74cu-000Hh0-Lj; Sun, 08 Nov 2009 10:04:05 +0000 Message-ID: <4AF6978A.8080000@psg.com> Date: Sun, 08 Nov 2009 19:03:54 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sandra Murphy References: <559456921.7184541257556016379.JavaMail.root@crono> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kotikalapudi Sriram , sidr@ietf.org Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 10:03:51 -0000 > If you have sub-allocated to a customer and you want to register a ROA > for that more specific, would you register the ROA with your AS or your > customer's AS (or your customer's backup upstream). would it not be most useful to issue the roa for the AS which will announce the prefix? what am i missing here? randy From Sandra.Murphy@cobham.com Sun Nov 8 10:25:53 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86663A67D8 for ; Sun, 8 Nov 2009 10:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 3mplE85UMT0h for ; Sun, 8 Nov 2009 10:25:53 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id E6EA73A67C0 for ; Sun, 8 Nov 2009 10:25:52 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nA8IQFN0008170; Sun, 8 Nov 2009 12:26:15 -0600 Received: from cronus.sandiego.ads.sparta.com ([157.185.24.3]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA8IQEKt019025; Sun, 8 Nov 2009 12:26:15 -0600 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by cronus.sandiego.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 10:26:14 -0800 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 13:22:13 -0500 Date: Sun, 8 Nov 2009 13:22:09 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <6929FFAD-6200-4422-AE1C-05176A0139EC@apnic.net> Message-ID: References: <6929FFAD-6200-4422-AE1C-05176A0139EC@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Nov 2009 18:22:13.0362 (UTC) FILETIME=[64ADB520:01CA60A0] Cc: sidr@ietf.org Subject: Re: [sidr] IETF 76 SIDR WG Agenda X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 18:25:54 -0000 Thanks to Jared for pointing out that the version numbers in the agenda have not kept pace with the last flurry of updates. The agenda with corrected version numbers is below. A new version has been uploaded to the meeting site. --Sandy SIDR Working Group Chairs: Sandy Murphy, Geoff Huston Session: MONDAY, November 9, 2009 0900-1130 Morning Session I, Acacia 2 WG Resources: http://tools.ietf.org/wg/sidr/ Agenda: -- Administrivia (5 minutes) blue sheets, scribe victimization, etc. -- WG Document Status (75 minutes) Last Call Summary - chairs Reports on Updated WG Drafts (by the draft authors) RPKI Architecture - draft-ietf-sidr-arch-09.txt - Stephen Kent CP - draft-ietf-sidr-cp-07.txt - Stephen Kent CPS-IR - draft-ietf-sidr-cps-irs-04.txt - Stephen Kent CPS-ISP - draft-ietf-sidr-cps-isp-03.txt - Stephen Kent Manifests - draft-ietf-sidr-rpki-manifests-05.txt - Matt Lepinski ROA Format - draft-ietf-sidr-roa-format-06.txt - Matt Lepinski Repository Structure - draft-ietf-sidr-repos-struct-03.txt - George Michaelson Certificate Profile - draft-ietf-sidr-res-certs-17.txt - George Michaelson ROA Validation - draft-ietf-sidr-roa-validation-03.txt - George Michaelson TA - draft-ietf-sidr-ta-02.txt - George Michaelson Provisioning Protocol - draft-ietf-sidr-rescerts-provisioning-05.txt - Byron Ellacot RPKI Algorithms - draft-ietf-sidr-rpki-algs-00.txt - Geoff Huston -- New Work (30 minutes) Update on Use Cases - draft-manderson-sidr-usecases-01.txt - Terry Manderson Local TA Management - Steve Kent -- RPKI Operators Roundtable Report and Discussion (30+ minutes) Report - Ruediger Volk Discussion - John Schnizlein From Sandra.Murphy@cobham.com Sun Nov 8 13:04:34 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBC73A685B for ; Sun, 8 Nov 2009 13:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UChgeqVIQeF2 for ; Sun, 8 Nov 2009 13:04:34 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id E2E243A67B8 for ; Sun, 8 Nov 2009 13:04:33 -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 nA8L4wqi008787 for ; Sun, 8 Nov 2009 15:04:58 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA8L4wBk021226 for ; Sun, 8 Nov 2009 15:04:58 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 16:04:11 -0500 Date: Sun, 8 Nov 2009 16:04:08 -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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Nov 2009 21:04:11.0721 (UTC) FILETIME=[05459B90:01CA60B7] Subject: [sidr] minues taker and jabber scribe volunteers needed X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 21:04:34 -0000 We will need a minutes taker and a jabber scribe for the meeting. Consider volunteering. Both are necessary functions. I would not like to proceed without either. We'll see if the RFID experiment ends up being of benefit to the jabber scribing. --Sandy From weiler@watson.org Sun Nov 8 17:43:04 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033523A68CC for ; Sun, 8 Nov 2009 17:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 gK0nWzT2XiWX for ; Sun, 8 Nov 2009 17:43:03 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 4DA753A6814 for ; Sun, 8 Nov 2009 17:43:03 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nA91hE8N049425; Sun, 8 Nov 2009 20:43:14 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nA91hDWD049422; Sun, 8 Nov 2009 20:43:14 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 8 Nov 2009 20:43:13 -0500 (EST) From: Samuel Weiler To: Geoff Huston In-Reply-To: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> Message-ID: References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Sun, 08 Nov 2009 20:43:14 -0500 (EST) Cc: sidr@ietf.org Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:43:04 -0000 On Mon, 2 Nov 2009, Geoff Huston wrote: > If you support adoption of this draft as a working group item, please also > indicate whether you will be able to work on the draft (contribute or > review). Please adopt this draft as a WG item. I'm happy to contribute and/or review. -- Sam From kawamucho@mesh.ad.jp Sun Nov 8 17:46:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8636C3A67F3 for ; Sun, 8 Nov 2009 17:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pud+8kv4HoS for ; Sun, 8 Nov 2009 17:46:41 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 69ECF3A6823 for ; Sun, 8 Nov 2009 17:46:41 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.161]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id nA91l34h021972; Mon, 9 Nov 2009 10:47:03 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id nA91l3t17818; Mon, 9 Nov 2009 10:47:03 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id nA91l3Sp017986; Mon, 9 Nov 2009 10:47:03 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id nA91l3jT005606; Mon, 9 Nov 2009 10:47:03 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id nA91l3dA006108; Mon, 9 Nov 2009 10:47:03 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id nA91l3AK005894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 10:47:03 +0900 Message-ID: <4AF77496.60302@mesh.ad.jp> Date: Mon, 09 Nov 2009 10:47:02 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Geoff Huston References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> <8CE242B1-05C5-4550-BB66-1FE76DEA22D6@apnic.net> In-Reply-To: <8CE242B1-05C5-4550-BB66-1FE76DEA22D6@apnic.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:46:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think this work is important in that it gives a guidance for operators like me. +1 for adoption. Seiichi Geoff Huston wrote: > Obviously my skills at elementary addition are to be found wanting! > > Two weeks from today is Tuesday November 17th. > > My apologies for any confusion here - this call will run from now until > November 17th > > > regards, > > Geoff > > > > > On 02/11/2009, at 12:42 PM, Geoff Huston wrote: > >> Hi, >> >> I am opening a two week wg call for comments on the adoption of this >> document as a working group item. >> >> The document is available at: >> >> http://www.ietf.org/id/draft-manderson-sidr-usecases-01.txt >> >> Please respond, either accept or not accept, by Tues Nov 10 2009. >> >> As usual, the rules are that silence does not indicate assent, so >> please actively reply. >> >> If you support adoption of this draft as a working group item, please >> also indicate whether you will be able to work on the draft >> (contribute or review). >> >> --Geoff >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkr3dJYACgkQcrhTYfxyMkKv/wCfS3F3HDauI3SV+7LIe570w98n tbwAnRLWdosIaGIUjUQNBeZ3ypRbJulI =0IY2 -----END PGP SIGNATURE----- From kent@bbn.com Sun Nov 8 18:23:37 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784FF3A68EE for ; Sun, 8 Nov 2009 18:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 lG8y9Sn7kxNm for ; Sun, 8 Nov 2009 18:23:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D65173A68E6 for ; Sun, 8 Nov 2009 18:23:36 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N7JvF-0008Rn-B4 for sidr@ietf.org; Sun, 08 Nov 2009 21:24:01 -0500 Mime-Version: 1.0 Message-Id: Date: Sun, 8 Nov 2009 21:07:47 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] use cases draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:23:37 -0000 I believe that the WG should pursue development of a "use cases" document. Steve From robertl@apnic.net Sun Nov 8 19:05:18 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7843E3A689A for ; Sun, 8 Nov 2009 19:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2glZ7TV-OqYR for ; Sun, 8 Nov 2009 19:05:17 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id AD84E3A67E2 for ; Sun, 8 Nov 2009 19:05:16 -0800 (PST) Received: from [203.119.42.172] (dynamic172.apnic.net [203.119.42.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id BAE96D5900; Mon, 9 Nov 2009 13:14:53 +1000 (EST) Message-ID: <4AF78702.4060004@apnic.net> Date: Mon, 09 Nov 2009 13:05:38 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18) Gecko/20081105 Lightning/0.9 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Geoff Huston References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> In-Reply-To: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAMAAABg3Am1AAAAGFBMVEUbGxs1NTVVVVVycnKO jo6tra3MzMzg4OAC8PijAAACVElEQVR42pWVW3bjMAxDKT6U/e94AJBWXLcfHrRJpBhXoKjj2D7Q hqoyI8Jv4vTxTW6b4ZLOcD6do3XzA1g9qEKK0orGmeSuWGIHKCZE1KZkwgtA4oOzwjsMB4DRehID ULFgqc+ls49gwOami0xcwI41ipkfFRzWTWKlqZCi1ZpwRVRGQtHXG6gqRyHtN1tH1X0gMF0x+pPV 5fKs+/pSfh4yrh8AmvD11C9gM8CjQERgv+ds5/TiCWTSwYjKjc7kD8ViCT8AnzOBdppreyOOnSVc iLrkI/j3+g2E9fTItHjbEmVrcAfWmlFRTOhhJgImIUv/Uph57VmAS1+JWTt82brC8gCIHQub0yWl gAXAG5AGABGcBp0NdIs2zxjwXZGBVBIYUwL8DuhUhPEuOGePAAhllAUdAtzSMl0OgMANQAiIPXdZ GV6KKwCxMATBzaVTTOwISQCkDe6wORG91zVJARioOQK6Zzw3ekaV0gHKg0oCImKXr/wFxAMIAgrw rDAYngm9a/sCBbF3jojlDaj8KS8agGmA7jcAr8K1cXWHJmCAbIBT+Um4tekoES6dCgV4KxFBj86S IQcwdbkB/2pVyUQ7pOGpaLpaBI6i6IrZhLJcwCz1TFBEDDHt8gkIXTjAUYV6OgoBE6DsEKDnxgCW Kr7tNE0AgXtbPRrAxRi1p3TDzcEc4MjMco9ZjgTg8h/gKf465/d54GZXESr7DyD4a5vZ/m0vVE3I X/ZGG5oHiL3T/uCPcntPLBX0Hgh2y18DVf3AfQ/sD/U+IUoPKvsPLV/2p/4BtMMZxXNLW/wAAAAA SUVORK5CYII= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:05:18 -0000 Please accept, I'm happy to review. Rob -- Robert Loomans email: robertl@apnic.net Senior Software Engineer, APNIC sip: robertl@voip.apnic.net http://www.apnic.net/ phone: +61 7 3858 3100 From danny@tcb.net Sun Nov 8 20:49:18 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2261928C154 for ; Sun, 8 Nov 2009 20:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOtaugDEk5Pm for ; Sun, 8 Nov 2009 20:49:17 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 760E728C0DF for ; Sun, 8 Nov 2009 20:49:17 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 8725126866A; Sun, 8 Nov 2009 21:49:43 -0700 (MST) Received: from host-16-199.meeting.ietf.org (host-16-199.meeting.ietf.org [133.93.16.199]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sun, 08 Nov 2009 21:49:43 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=133.93.16.199; client-port=60041; syn-fingerprint=65535:49:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: Danny McPherson In-Reply-To: Date: Sun, 8 Nov 2009 21:49:25 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4BB9BC07-A981-4576-B30D-F5B524AAF2F2@tcb.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] use cases draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:49:18 -0000 On Nov 8, 2009, at 7:07 PM, Stephen Kent wrote: > I believe that the WG should pursue development of a "use cases" > document. I agree... -danny From terry.manderson@icann.org Sun Nov 8 22:42:08 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35363A6A83 for ; Sun, 8 Nov 2009 22:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Yf3lt-CdgoGX for ; Sun, 8 Nov 2009 22:42:08 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id EE9EF3A6920 for ; Sun, 8 Nov 2009 22:42:07 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 8 Nov 2009 22:42:34 -0800 From: Terry Manderson To: "sidr@ietf.org" Date: Sun, 8 Nov 2009 22:42:32 -0800 Thread-Topic: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document Thread-Index: AcpZdsD6Dq/5M6guQpmAVCIjhfo0CgHkQ9G8 Message-ID: In-Reply-To: <4AEB07E9.7010107@joelhalpern.com> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:42:08 -0000 I've been thinking this over and spoken to some people who understand this position better than I, and my position has shifted as I don't feel that an IPR statement _changes_ the content of the ID, although it _may_ affect the content of other drafts and IDs when the IPR is publically visible. At some stage there may be a discussion of like documents but that shouldn't, in my opinion, hinder the review of draft-pmohapat-sidr-pfx-validate and I feel i= t is within charter as so I support its adoption as a WG item and am willing to review even though the discussion and WG status request was hijacked and the due date for the topic has expired. That said, can I ask - for future use and reference - the WG-chairs to seek a WG consensus on how it deals with IPR? Cheers Terry On 31/10/09 1:36 AM, "Joel M. Halpern" wrote: > General comment: > The US Patent office procedures are such that there is a delay between > filing and public disclosure of applications. That may be applicable her= e. >=20 > the IETF procedures specifically ask folks to tell us about such patent > applications, if they think they apply. However, we understand that we > can not get details at that point. >=20 > If we treat such disclosure as a priori blocked of WG consideration of a > document, we invite denial of service attacks on our work. If this > document were being last called, then the question would be > significantly more complicated. But we are only at WG adoption, as a > starting point for work on a topic. >=20 > (This is separate from the additional, relevant, question that Robert ask= s.) >=20 > Yours, > Joel M. Halpern >=20 > Robert Loomans wrote: >> Terry Manderson wrote: >>> I feel unable to say either way at present. >>>=20 >> ... >>> A direct link to the Patent Application would be appreciated! >>=20 >> Ditto. I'm reluctant to take any stance on this draft without more >> information on what the patent claims. >>=20 >> Additionally, I'd like to see a clear statement as to what this draft >> says for which the existing draft-ietf-sidr-roa-validation is insufficie= nt. >>=20 >> Rob >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Mon Nov 9 16:42:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23FD3A68B3 for ; Mon, 9 Nov 2009 16:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 nqR0Ync4ZlVs for ; Mon, 9 Nov 2009 16:42:04 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BA7F53A689C for ; Mon, 9 Nov 2009 16:42:04 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N7eoY-00011M-BJ for sidr@ietf.org; Mon, 09 Nov 2009 19:42:30 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 9 Nov 2009 19:30:12 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] multi-value distinguished name question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 00:42:05 -0000 Tim Polk asked David Cooper (a NIST colleague) to check on the question that was raised during our meeting yesterday morning. The question was whether, if we require Subject and Issuer names in X.509 certs to be either just a CN or a CN plus a serialNumber (as a set), one could use commonly available CA software generate certs. The answer is that both OpenSSL and an NSS can do this. OpenSSL required some configuration effort, but David provided the details of the config params in his response! I will check with someone who knows about OpenCA, to see what they say. Steve From housley@vigilsec.com Mon Nov 9 17:44:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32CB23A69DF for ; Mon, 9 Nov 2009 17:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVHwVGN8Cvvn for ; Mon, 9 Nov 2009 17:44:41 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 4805E3A67AF for ; Mon, 9 Nov 2009 17:44:41 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C5B179A4783; Mon, 9 Nov 2009 20:45:18 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id DYhv9MG4Qcel; Mon, 9 Nov 2009 20:45:03 -0500 (EST) Received: from THINKPADR52.vigilsec.com (host-20-160.meeting.ietf.org [133.93.20.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A3F2C9A4785; Mon, 9 Nov 2009 20:45:13 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Nov 2009 20:44:53 -0500 To: Stephen Kent ,sidr@ietf.org From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091110014513.A3F2C9A4785@odin.smetech.net> Subject: Re: [sidr] multi-value distinguished name question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:44:42 -0000 Every time I have seen the use of more than one element in the set, people get confused, which in turn results in more complexity, at least in the user interfaces. Why accept this complexity? I'm not seeing an offsetting benefit. Russ At 07:30 PM 11/9/2009, Stephen Kent wrote: >Tim Polk asked David Cooper (a NIST colleague) to check on the >question that was raised during our meeting yesterday morning. The >question was whether, if we require Subject and Issuer names in >X.509 certs to be either just a CN or a CN plus a serialNumber (as a >set), one could use commonly available CA software generate certs. >The answer is that both OpenSSL and an NSS can do this. OpenSSL >required some configuration effort, but David provided the details >of the config params in his response! > >I will check with someone who knows about OpenCA, to see what they say. > >Steve >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Mon Nov 9 17:53:40 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6896E28C12E for ; Mon, 9 Nov 2009 17:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 AZo+BA5sgE1d for ; Mon, 9 Nov 2009 17:53:39 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B83BF28C12D for ; Mon, 9 Nov 2009 17:53:39 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N7fvp-0001z7-CM for sidr@ietf.org; Mon, 09 Nov 2009 20:54:06 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 9 Nov 2009 20:54:02 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] more CA info X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 01:53:40 -0000 Carl Wallace checked and confirms that the Entrust CA product also is capable of generating certs with names of the desired format. Steve From kent@bbn.com Mon Nov 9 18:00:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E70A3A6AA9 for ; Mon, 9 Nov 2009 18:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 2NPcZStj8S0F for ; Mon, 9 Nov 2009 18:00:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CAA333A69EF for ; Mon, 9 Nov 2009 18:00:02 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N7g20-00023E-CT; Mon, 09 Nov 2009 21:00:29 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20091110014513.A3F2C9A4785@odin.smetech.net> References: <20091110014513.A3F2C9A4785@odin.smetech.net> Date: Mon, 9 Nov 2009 21:00:23 -0500 To: Russ Housley From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] multi-value distinguished name question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:00:03 -0000 At 8:44 PM -0500 11/9/09, Russ Housley wrote: >Every time I have seen the use of more than one element in the set, >people get confused, which in turn results in more complexity, at >least in the user interfaces. Why accept this complexity? I'm not >seeing an offsetting benefit. > >Russ I admit that we could do it either way, but so far we have seen no CAs that can't do the set. If we choose to represent the two attributes (that need not always be present) as two RDNs, we would have to decide on the order. I'm not wedded to the set representation; I just prefer it from a semantic perspective. Steve From gih@apnic.net Mon Nov 9 19:59:10 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2983A69CF for ; Mon, 9 Nov 2009 19:59:10 -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 pBGU0K9DMHTB for ; Mon, 9 Nov 2009 19:59:09 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 629343A694D for ; Mon, 9 Nov 2009 19:59:08 -0800 (PST) Received: from host-112-64.meeting.ietf.org (host-112-64.meeting.ietf.org [133.93.112.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 450B1D58C4; Tue, 10 Nov 2009 14:08:52 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Geoff Huston In-Reply-To: Date: Tue, 10 Nov 2009 14:59:25 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] multi-value distinguished name question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:59:10 -0000 WG co-chair hat OFF Steve, I wonder if you wiould mind forwarding on such configuration details to this list? Also, this appears to require a documentation change in the res-cert draft - is that that case? If so what alternate wording is required for the Issuer and subject name section? regards, Geoff WG co-chair hat OFF On 10/11/2009, at 11:30 AM, Stephen Kent wrote: > Tim Polk asked David Cooper (a NIST colleague) to check on the > question that was raised during our meeting yesterday morning. The > question was whether, if we require Subject and Issuer names in X. > 509 certs to be either just a CN or a CN plus a serialNumber (as a > set), one could use commonly available CA software generate certs. > The answer is that both OpenSSL and an NSS can do this. OpenSSL > required some configuration effort, but David provided the details > of the config params in his response! > > I will check with someone who knows about OpenCA, to see what they > say. > > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Mon Nov 9 23:12:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0933A69DC for ; Mon, 9 Nov 2009 23:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, 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 NsZL95Tm473p for ; Mon, 9 Nov 2009 23:12:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CEE4C3A68CB for ; Mon, 9 Nov 2009 23:12:44 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.112.234]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N7kuc-0006GR-AO; Tue, 10 Nov 2009 02:13:11 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 10 Nov 2009 02:13:06 -0500 To: Geoff Huston From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-954285306==_ma============" Cc: sidr@ietf.org Subject: Re: [sidr] multi-value distinguished name question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:12:46 -0000 --============_-954285306==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Geoff, Here are the details provided by David: ------------------------------ Using OpenSSL 1.0.0-beta3 15 Jul 2009: openssl req -out sidr.req -newkey rsa:2048 -keyout sidr.key -config ./openssl.cnf -multivalue-rdn -subj "/CN=SIDR test+serialNumber=4" openssl ca -in sidr.req -out sidr.pem -config openssl.cnf -preserveDN NSS 3.12.3: certutil -N -d temp/ certutil -R -k rsa -g 2048 -s "CN=SIDRtest, dc=example, dc=com" -d temp/ -o ta.req certutil -C -i ta.req -x -d temp/ -o ta.cer -m 0 certutil -A -n "SIDRTA" -t "TC,TC,TC" -d temp/ -i ta.cer certutil -R -k rsa -g 2048 -s "serialNumber=5+CN=SIDR test" -d temp/ -o sidr.req certutil -C -c "SIDRTA" -i sidr.req -o sidr_NSS.cer -m 8 -d temp/ ---------- As for the rescerts I-D, I don't think it needs to change, because it refers to the arch doc for subject and issuer name conventions. However, that document is not specific about how to organize the common name and serial number attributes when they both appear in a Subject or Issuer name. We have the option to move the details into the cert profile, or put more details into the arch doc. Steve --============_-954285306==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] multi-value distinguished name question
Geoff,

Here are the details provided by David:

------------------------------
Using OpenSSL 1.0.0-beta3 15 Jul 2009:
openssl req -out sidr.req -newkey rsa:2048 -keyout sidr.key -config ./openssl.cnf -multivalue-rdn -subj "/CN=SIDR test+serialNumber=4"
openssl ca -in sidr.req -out sidr.pem -config openssl.cnf -preserveDN
NSS 3.12.3:
certutil -N -d temp/
certutil -R -k rsa -g 2048 -s "CN=SIDRtest, dc=example, dc=com" -d temp/ -o ta.req
certutil -C -i ta.req -x -d temp/ -o ta.cer -m 0
certutil -A -n "SIDRTA" -t "TC,TC,TC" -d temp/ -i ta.cer
certutil -R -k rsa -g 2048 -s "serialNumber=5+CN=SIDR test" -d temp/ -o sidr.req
    certutil -C -c "SIDRTA" -i sidr.req -o sidr_NSS.cer -m 8 -d temp/

----------

As for the rescerts I-D, I don't think it needs to change, because it refers to the arch doc for subject and issuer name conventions.  However, that document is not specific about how to organize the common name and serial number attributes when they both appear in a Subject or Issuer name.

We have the option to move the details into the cert profile, or put more details into the arch doc.

Steve
--============_-954285306==_ma============-- From gih@apnic.net Tue Nov 10 01:05:58 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0674D3A6A10 for ; Tue, 10 Nov 2009 01:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, 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 byMliQpGPXVx for ; Tue, 10 Nov 2009 01:05:57 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4C15C3A68B9 for ; Tue, 10 Nov 2009 01:05:56 -0800 (PST) Received: from host-16-221.meeting.ietf.org (host-16-221.meeting.ietf.org [133.93.16.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 7F35BD58C4; Tue, 10 Nov 2009 19:15:43 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Geoff Huston In-Reply-To: Date: Tue, 10 Nov 2009 20:06:13 +1100 Content-Transfer-Encoding: 7bit Message-Id: <83E6C8CB-DDD5-4353-A514-A7661F9596A7@apnic.net> References: To: Stephen Kent X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] multi-value distinguished name question X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 09:05:58 -0000 WG co-chair hat off On 10/11/2009, at 6:13 PM, Stephen Kent wrote: > Geoff, > > Here are the details provided by David: > > ------------------------------ > Using OpenSSL 1.0.0-beta3 15 Jul 2009: > openssl req -out sidr.req -newkey rsa:2048 -keyout sidr.key - > config ./openssl.cnf -multivalue-rdn -subj "/CN=SIDR test > +serialNumber=4" > openssl ca -in sidr.req -out sidr.pem -config openssl.cnf -preserveDN > NSS 3.12.3: > certutil -N -d temp/ > certutil -R -k rsa -g 2048 -s "CN=SIDRtest, dc=example, dc=com" -d > temp/ -o ta.req > certutil -C -i ta.req -x -d temp/ -o ta.cer -m 0 > certutil -A -n "SIDRTA" -t "TC,TC,TC" -d temp/ -i ta.cer > certutil -R -k rsa -g 2048 -s "serialNumber=5+CN=SIDR test" -d temp/ > -o sidr.req > certutil -C -c "SIDRTA" -i sidr.req -o sidr_NSS.cer -m 8 -d temp/ > > ---------- > > As for the rescerts I-D, I don't think it needs to change, because > it refers to the arch doc for subject and issuer name conventions. > However, that document is not specific about how to organize the > common name and serial number attributes when they both appear in a > Subject or Issuer name. > > We have the option to move the details into the cert profile, or put > more details into the arch doc. And the option to place these details in the resource certificate profile document, of course. Still speaking as an individual, and not a wg co-chair, I'm not sure myself where would be the most obvious place to put this, where "most obvious" is from the perspective of a future reader / implementor. regards, Geoff WG co-chair hat off From Sandra.Murphy@cobham.com Tue Nov 10 10:48:50 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755CB28C1BB for ; Tue, 10 Nov 2009 10:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 a7yuYTpadtix for ; Tue, 10 Nov 2009 10:48:49 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 92F3128C0F9 for ; Tue, 10 Nov 2009 10:48:48 -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 nAAInF5n003707 for ; Tue, 10 Nov 2009 12:49:15 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAAInFAs002469 for ; Tue, 10 Nov 2009 12:49:15 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:49:09 -0500 Date: Tue, 10 Nov 2009 13:49:06 -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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Nov 2009 18:49:10.0238 (UTC) FILETIME=[7D3CE7E0:01CA6236] Subject: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:48:50 -0000 One of the questions that we did not get to in the meeting Monday was a question of IPR. An IPR claim has been registered against the wg draft draft-ietf-sidr-roa-validation-03.txt. IPR issues were specifically mentioned as a deterrent in a recent call for wg adoption of a draft. I'd like the wg to consider the wg stance on working on IPR'd technologies. We can reject such work, we can allow such work, we can allow it with stipulations as to the acceptable terms, etc. Express your opinion of what you would like to see and why. --Sandy From Sandra.Murphy@cobham.com Tue Nov 10 10:52:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615D53A6784 for ; Tue, 10 Nov 2009 10:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 NZl59iyHYHRd for ; Tue, 10 Nov 2009 10:52:05 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 749A93A6781 for ; Tue, 10 Nov 2009 10:52:05 -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 nAAIqWmG003791 for ; Tue, 10 Nov 2009 12:52:32 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAAIqWp3002671 for ; Tue, 10 Nov 2009 12:52:32 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:52:31 -0500 Date: Tue, 10 Nov 2009 13:52:28 -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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 10 Nov 2009 18:52:31.0973 (UTC) FILETIME=[F57B3950:01CA6236] Subject: [sidr] implementation - work for the working group? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 18:52:06 -0000 There have been two presentations to this working group in past IETF meetings suggesting mechanisms for implementations of the BGP route decision based on the RPKI. The first was Ruediger Volk's presentation at IETF72 that suggested a way to map ROAs to IRR route objects so as to feed into existing operator tools. (http://tools.ietf.org/agenda/72/slides/sidr-6.pdf) The second was David Ward's presentation at IETF75 that suggested a way to use prefix -> origin AS maps (possibly produced from ROAs) in the BGP decision process. (http://tools.ietf.org/agenda/75/slides/sidr-8.pdf) Obviously people are beginning to work on implementations, but we presently have no work going on concerning implementation. So the question is - does the wg believe that working on implementations of use of the RPKI and ROAs should be a work item for this wg? That is, should the wg produce implementation specs? --Sandy From gih@apnic.net Tue Nov 10 11:46:03 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C337F3A6806 for ; Tue, 10 Nov 2009 11:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5YfZgDnwXyU for ; Tue, 10 Nov 2009 11:46:02 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 7C3513A67A8 for ; Tue, 10 Nov 2009 11:46:00 -0800 (PST) Received: from host-112-64.meeting.ietf.org (host-112-64.meeting.ietf.org [133.93.112.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 62EA6D58CB; Wed, 11 Nov 2009 05:55:50 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Geoff Huston In-Reply-To: Date: Wed, 11 Nov 2009 06:46:20 +1100 Content-Transfer-Encoding: 7bit Message-Id: <0C38341C-719B-4FA5-BEE9-D9CB5DE79515@apnic.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] implementation - work for the working group? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:46:03 -0000 On 11/11/2009, at 5:52 AM, Sandra Murphy wrote: > There have been two presentations to this working group in past IETF > meetings suggesting mechanisms for implementations of the BGP route > decision based on the RPKI. The first was Ruediger Volk's > presentation at IETF72 that suggested a way to map ROAs to IRR route > objects so as to feed into existing operator tools. (http://tools.ietf.org/agenda/72/slides/sidr-6.pdf > ) The second was David Ward's presentation at IETF75 that suggested > a way to use prefix -> origin AS maps (possibly produced from ROAs) > in the BGP decision process. (http://tools.ietf.org/agenda/75/slides/sidr-8.pdf > ) > > Obviously people are beginning to work on implementations, but we > presently have no work going on concerning implementation. So the > question is - does the wg believe that working on implementations of > use of the RPKI and ROAs should be a work item for this wg? That > is, should the wg produce implementation specs? > WG co-chair hat ON Sandy, I am assuming your posting is made in the context of a co-chair of this working group. When I read the questions you have posed in your note, the first thing I asked myself was: "Isn't this specification of mechanisms within the scope of the charter already?" (http://www.ietf.org/dyn/wg/charter/sidr-charter.html ) I'd like to briefly explore your question to the WG a little further within the particular context of the WG charter, as questions related to whether a WG adopts particular work items or not is, conventionally for me in any case, equivalently phrased as a WG charter discussion. I note in particular the following text in the charter: "The SIDR working group will develop security mechanisms which fulfill those requirements which have been agreed on by the RPSEC working group. In developing these mechanisms, the SIDR working group will take practical deployability into consideration." and "The SIDR working group is charged with the following tasks: [...] Document specific routing functionality modules within this architecture that are designed to address specific secure routing requirements as they are determined by the RPSEC Working Group" I had assumed when reading this charter as an agenda for my efforts in co-chairing this WG that the specification of specific mechanisms that apply a validation framework to the information that is passed within the inter-domain routing environment is already within the scope of work for which this WG is chartered. Furthermore, if this WG does not, or can not, deliver on this task then the WG would reasonably need to provide reasons as to why it was not intending to fulfil this particular aspect of its charter. If your question to the working group is motivated by a different interpretation of the current charter that specifically precludes such efforts related to the specification of such mechanisms it would be extremely helpful to understand what particular interpretation you have applied to the SIDR charter to reach such a conclusion. It would also be helpful to me as a co-chair, and I assume helpful to the members of the WG as well, to understand a little more as to your motivation for posing this question to the WG, and the implications, as you see it, in terms of the chartered activity for this WG if there is some rough consensus for, or rough consensus against, the final question you have posed to the WG. (As this appears to be a WG charter topic I have included our Routing AD into the conversation - I am sure that he will be able to provide helpful guidance as appropriate here.) It is also possible that you could've been saying: "While the WG did not have a clear consensus view on adoption of a draft relating to a security mechanism in BGP in recent weeks, this WG co-chair like to encourage work on implementation of specific mechanisms, and in particular would like to encourage the submission of material relating to specification of mechanisms that build upon the validation framework that is being specified in SIDR." If thats the case then my comment is that I found the use of rhetorical questions was far more confusing than helpful in conveying such a message. regards, Geoff WG co-chair hat ON From ggm@apnic.net Tue Nov 10 15:51:45 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C3628C0D0 for ; Tue, 10 Nov 2009 15:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mlOBSm4Kw+U for ; Tue, 10 Nov 2009 15:51:44 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id EAA7028C0EF for ; Tue, 10 Nov 2009 15:51:41 -0800 (PST) Received: from host-112-209.meeting.ietf.org (host-112-209.meeting.ietf.org [133.93.112.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 09FC1D58CB; Wed, 11 Nov 2009 10:01:33 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 11 Nov 2009 08:52:02 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:51:45 -0000 On 11/11/2009, at 3:49 AM, Sandra Murphy wrote: > One of the questions that we did not get to in the meeting Monday was = a question of IPR. >=20 > An IPR claim has been registered against the wg draft = draft-ietf-sidr-roa-validation-03.txt. IPR issues were specifically = mentioned as a deterrent in a recent call for wg adoption of a draft. Because that is my understanding of the choice facing the IETF in all = WG, that if faced with work which makes no IPR claim, and work which = does, the IETF is entitled to, and in fact often does, preference the = work with no IPR claim. >=20 > I'd like the wg to consider the wg stance on working on IPR'd = technologies. We can reject such work, we can allow such work, we can = allow it with stipulations as to the acceptable terms, etc. >=20 > Express your opinion of what you would like to see and why. I would like to see my voluntary contribution in the IETF be made in the = spirit of openness and benefit to all. My personal preference is not to = work on technologies which are encumbered by other people's IPR. Of course your question is motivated by specifics. I would like to try = and address the specifics. In that spirit Sandy, I regard draft-pmohapat-sidr-pfx-validate as a = functional attack or a kind of "DOS" on IETF process. =20 In effect, by disclosing an IPR claim, and then extending it in an = apparently capricious fashion to a current WG document that did not = reflect the non-IETF contributions of any Cisco-employees, namely = draft-ietf-sidr-roa-validation, the IPR claimants appear to be = attempting some form of hijack of the IETF process. When Cisco employees = attend IETF, and participate in the mailing lists, their contributions = made openly are done so under the conditions of the 'note well' and so = do not (in my opinion) buttress their IPR claim. If they have a moral = right to recognition in the draft, I am happy to discuss this. My co-author and I have discussed this IPR issue, and we specifically = disclaim any personal IPR over the concepts that we believe reflect the = WG's considerations on our document. This of course does not mean that = these concepts are not subject to IPR claims, but Steve Kent's postings = regarding prior art appear to be extremely relevant to the draft I = co-authored, and the extension of the IPR claim by Cisco over this = particular draft is not helpful. I feel that this document is a reflection of ideas discussed openly in = this WG, for a very long time, and I have already informed at least one = potential prior-art holder that I and my co-author do not claim any = rights over any technology or ideas in this document and nor does our = employer. If draft-pmohapat-sidr-pfx-validate was revised to reflect mechanisms, = without claiming to define semantics, if it cited the existing WG draft = which is on semantics and not mechanisms, recognised the contributions = made to that draft by open WG process, and assuming that it also = reflected the large body of prior art in routing security, I think a = draft on mechanisms should be adopted. -George PS this is my individual response, and does not necessarily reflect the = views of my co-author except where clearly stated. From randy@psg.com Tue Nov 10 18:32:18 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13223A6BD8 for ; Tue, 10 Nov 2009 18:32: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 Dp1g0Pg4oSoh for ; Tue, 10 Nov 2009 18:32:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 2A1923A6BD4 for ; Tue, 10 Nov 2009 18:32:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N830k-00047g-9x; Wed, 11 Nov 2009 02:32:42 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id A7AFB2BFAE8C; Wed, 11 Nov 2009 11:32:41 +0900 (JST) Date: Wed, 11 Nov 2009 11:32:41 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 02:32:19 -0000 george, if you think that the two drafts cover much the same technology, and you accept the sad reality that sometimes technologies in the ietf suffer ipr attacks, can you explain why are you angry that the same ipr attack is directed at the two drafts you think are similar? randy From ggm@apnic.net Tue Nov 10 19:14:54 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008813A67D2 for ; Tue, 10 Nov 2009 19:14:54 -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 E5Ox6qnStrZY for ; Tue, 10 Nov 2009 19:14:53 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 268273A6855 for ; Tue, 10 Nov 2009 19:14:52 -0800 (PST) Received: from host-112-209.meeting.ietf.org (host-112-209.meeting.ietf.org [133.93.112.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B909BD58C1; Wed, 11 Nov 2009 13:24:44 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 11 Nov 2009 12:15:13 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2E82F928-2F4C-4C77-8772-A7A277463990@apnic.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:14:54 -0000 On 11/11/2009, at 11:32 AM, Randy Bush wrote: > george, >=20 > if you think that the two drafts cover much the same technology, and = you > accept the sad reality that sometimes technologies in the ietf suffer > ipr attacks, can you explain why are you angry that the same ipr = attack > is directed at the two drafts you think are similar? >=20 > randy If you think that, then say so. Please don't "put words in my mouth" Randy. I don't agree with these = statements and I don't want anyone to believe that because YOU said it, = that it characterises how I feel. The roa-validation draft I co-authored covered semantics of a ROA, while = the other draft appeared to toe-tread on this work and then describe a = mechanism of implementation. =46rom my perspective there is an important = distinction that was mentioned on the WG meeting on Monday between = semantic interpretation and mechanism. So I disagree with your opening = assertion. I think we have a conceptual problem here. You see two drafts, both 'victims' of an IPR attack. I see a different thing. I see a causal chain 1) a draft is written by Geoff and myself in 2008. 2) in 2009 a draft is authored by Cisco and others. 3) in 2009 that draft is marked as having IPR claims attached to it, by = Cisco. ie, they claim IPR over a draft *of their own authorship* 4) later in 2009 our original 2008 draft is notified it now is covered = by these IPR claims. This was delivered to me after the initial = lodgement relating to the Cisco authored draft. It appears to be an = afterthought. Again, can I stress that this is my own personal view. -George= From ggm+ietf@apnic.net Tue Nov 10 19:31:59 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D913A6BBE for ; Tue, 10 Nov 2009 19:31:59 -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 PLvdcmWIjmz6 for ; Tue, 10 Nov 2009 19:31:58 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id E979C28C288 for ; Tue, 10 Nov 2009 19:31:57 -0800 (PST) Received: from host-112-209.meeting.ietf.org (host-112-209.meeting.ietf.org [133.93.112.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 7E38CD58C1; Wed, 11 Nov 2009 13:41:51 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 11 Nov 2009 12:32:20 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <109B65A2-5E5F-413D-8883-B91B4F9BDB9A@apnic.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:31:59 -0000 On 11/11/2009, at 11:32 AM, Randy Bush wrote: > george, >=20 > if you think that the two drafts cover much the same technology, and = you > accept the sad reality that sometimes technologies in the ietf suffer > ipr attacks, can you explain why are you angry that the same ipr = attack > is directed at the two drafts you think are similar? >=20 > randy If you think that, then say so. Please don't "put words in my mouth" Randy. I don't agree with these = statements and I don't want anyone to believe that because YOU said it, = that it characterises how I feel. The roa-validation draft I co-authored covered semantics of a ROA, while = the other draft appeared to toe-tread on this work and then describe a = mechanism of implementation. =46rom my perspective there is an important = distinction that was mentioned on the WG meeting on Monday between = semantic interpretation and mechanism. So I disagree with your opening = assertion. I think we have a conceptual problem here. You see two drafts, both 'victims' of an IPR attack. I see a different thing. I see a causal chain 1) a draft is written by Geoff and myself in 2008. 2) in 2009 a draft is authored by Cisco and others. 3) in 2009 that draft is marked as having IPR claims attached to it, by = Cisco. ie, they claim IPR over a draft *of their own authorship* 4) later in 2009 our original 2008 draft is notified it now is covered = by these IPR claims. This was delivered to me after the initial = lodgement relating to the Cisco authored draft. It appears to be an = afterthought. Again, can I stress that this is my own personal view. -George= From Sandra.Murphy@cobham.com Tue Nov 10 19:42:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080C33A68CE for ; Tue, 10 Nov 2009 19:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 TKr9EBAEhw3O for ; Tue, 10 Nov 2009 19:42:22 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C62333A6A62 for ; Tue, 10 Nov 2009 19:42:22 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nAB3ghbw010610; Tue, 10 Nov 2009 21:42:43 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAB3ghPl021494; Tue, 10 Nov 2009 21:42:43 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 22:42:42 -0500 Date: Tue, 10 Nov 2009 22:42:36 -0500 (Eastern Standard Time) From: Sandra Murphy To: George Michaelson In-Reply-To: <2E82F928-2F4C-4C77-8772-A7A277463990@apnic.net> Message-ID: References: <2E82F928-2F4C-4C77-8772-A7A277463990@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 11 Nov 2009 03:42:43.0014 (UTC) FILETIME=[0656DE60:01CA6281] Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:42:26 -0000 On Wed, 11 Nov 2009, George Michaelson wrote: > > On 11/11/2009, at 11:32 AM, Randy Bush wrote: > >> george, >> >> if you think that the two drafts cover much the same technology, and you >> accept the sad reality that sometimes technologies in the ietf suffer >> ipr attacks, can you explain why are you angry that the same ipr attack >> is directed at the two drafts you think are similar? >> >> randy > > If you think that, then say so. > > Please don't "put words in my mouth" Randy. I don't agree with these statements and I don't want anyone to believe that because YOU said it, that it characterises how I feel. > > The roa-validation draft I co-authored covered semantics of a ROA, while the other draft appeared to toe-tread on this work and then describe a mechanism of implementation. From my perspective there is an important distinction that was mentioned on the WG meeting on Monday between semantic interpretation and mechanism. So I disagree with your opening assertion. > > I think we have a conceptual problem here. > > You see two drafts, both 'victims' of an IPR attack. > > I see a different thing. I see a causal chain > > 1) a draft is written by Geoff and myself in 2008. > > 2) in 2009 a draft is authored by Cisco and others. 2008, actually. The -00 draft was submitted Oct 08. --Sandy > > 3) in 2009 that draft is marked as having IPR claims attached to it, by Cisco. ie, they claim IPR over a draft *of their own authorship* > > 4) later in 2009 our original 2008 draft is notified it now is covered by these IPR claims. This was delivered to me after the initial lodgement relating to the Cisco authored draft. It appears to be an afterthought. > > Again, can I stress that this is my own personal view. > > -George From ggm+ietf@apnic.net Tue Nov 10 19:47:46 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5028B3A6947 for ; Tue, 10 Nov 2009 19:47:46 -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 RLSJH52zsCtn for ; Tue, 10 Nov 2009 19:47:45 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id ABAB63A68CE for ; Tue, 10 Nov 2009 19:47:44 -0800 (PST) Received: from host-112-209.meeting.ietf.org (host-112-209.meeting.ietf.org [133.93.112.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A1DFAD58C1; Wed, 11 Nov 2009 13:57:38 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 11 Nov 2009 12:48:07 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0C96AB4C-3FC6-41AB-A942-6A10025DB4DA@apnic.net> References: <2E82F928-2F4C-4C77-8772-A7A277463990@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:47:46 -0000 On 11/11/2009, at 12:42 PM, Sandra Murphy wrote: >=20 >=20 > On Wed, 11 Nov 2009, George Michaelson wrote: >> 2) in 2009 a draft is authored by Cisco and others. >=20 > 2008, actually. The -00 draft was submitted Oct 08. >=20 > --Sandy >=20 I apologize. I stand corrected. Submitted Oct 08.=20 The Draft I co-authored was submitted August 08.=20 The IPR filing and subsequent application to the draft I co-authored was = 2009 was it not? -George= From Sandra.Murphy@cobham.com Tue Nov 10 19:54:47 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933573A68C6 for ; Tue, 10 Nov 2009 19:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 5KCb0AU3kPLE for ; Tue, 10 Nov 2009 19:54:46 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9CE023A6901 for ; Tue, 10 Nov 2009 19:54:41 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nAB3t7Ux010670; Tue, 10 Nov 2009 21:55:07 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAB3t7h3021670; Tue, 10 Nov 2009 21:55:07 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 22:55:06 -0500 Date: Tue, 10 Nov 2009 22:54:59 -0500 (Eastern Standard Time) From: Sandra Murphy To: George Michaelson In-Reply-To: <0C96AB4C-3FC6-41AB-A942-6A10025DB4DA@apnic.net> Message-ID: References: <2E82F928-2F4C-4C77-8772-A7A277463990@apnic.net> <0C96AB4C-3FC6-41AB-A942-6A10025DB4DA@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 11 Nov 2009 03:55:06.0488 (UTC) FILETIME=[C17BFF80:01CA6282] Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:54:47 -0000 On Wed, 11 Nov 2009, George Michaelson wrote: > > On 11/11/2009, at 12:42 PM, Sandra Murphy wrote: > >> >> >> On Wed, 11 Nov 2009, George Michaelson wrote: >>> 2) in 2009 a draft is authored by Cisco and others. >> >> 2008, actually. The -00 draft was submitted Oct 08. >> >> --Sandy >> > > I apologize. I stand corrected. Submitted Oct 08. > > The Draft I co-authored was submitted August 08. > > The IPR filing and subsequent application to the draft I co-authored was 2009 was it not? Initial filing was Nov 08. --Sandy > > -George From ggm+ietf@apnic.net Tue Nov 10 20:35:10 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15A13A67EB for ; Tue, 10 Nov 2009 20:35:10 -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 yerK9FOXri4e for ; Tue, 10 Nov 2009 20:35:10 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 2C2B23A67AF for ; Tue, 10 Nov 2009 20:35:09 -0800 (PST) Received: from host-24-67.meeting.ietf.org (host-24-67.meeting.ietf.org [133.93.24.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B44D7D58C1; Wed, 11 Nov 2009 14:45:02 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <0C96AB4C-3FC6-41AB-A942-6A10025DB4DA@apnic.net> Date: Wed, 11 Nov 2009 13:35:30 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E82F928-2F4C-4C77-8772-A7A277463990@apnic.net> <0C96AB4C-3FC6-41AB-A942-6A10025DB4DA@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] wg consideration of IPR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 04:35:11 -0000 I must apologize to the WG for having made a mistake in my dates. I have = post-dated the work Geoff and I submitted, which actually hit the IETF = draft status in February 2008. I wish to revise my statements. 1) Geoff and I co-authored an individual submission in February of 2008. draft-huston-sidr-roa-validation-00 this was subsequently adopted August 7 2008 draft-ietf-sidr-roa-validation-00 2) Pradosh Mohapatra and John Scudder edited a draft dated October 27, = 2008 draft-pmohapat-sidr-pfx-validate-00 3) In November 2008, Cisco filed IPR in respect of this draft. This is = what I can tell from looking in the IETF IPR disclosure system. I = received no notification of this, relating to my work. 4) In October 2009, I became aware of a Cisco IPR claim in respect of draft-pmohapat-sidr-pfx-validate-00 The IPR statement was lodged with the IETF dated November 18 2008. 5) In November 2009 I received direct notification from Cisco/IETF that = the IPR claim was also applied to the draft I co-authored.=20 This is an IPR statement dated November 2 2009 So, thats the time sequence as I see it, based on what I can recall from = emails to sidr WG, personal mail, and the drafts found online. -George Again, this is my personal opinion. I speak for nobody else in this = matter. =09 From jgs@juniper.net Tue Nov 10 21:54:47 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0FA3A68C8 for ; Tue, 10 Nov 2009 21:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 jUzc0GzHny6q for ; Tue, 10 Nov 2009 21:54:46 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id B20363A6916 for ; Tue, 10 Nov 2009 21:54:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSvpRvVvp9dUmWMlssNUKxAbr5Xe9mQNf@postini.com; Tue, 10 Nov 2009 21:55:12 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Tue, 10 Nov 2009 21:52:28 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:52:28 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:52:28 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 21:52:27 -0800 Received: from jgs-sslvpn-nc.jnpr.net (jgs-sslvpn-nc.jnpr.net [172.23.8.196]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id nAB5qQj58322; Tue, 10 Nov 2009 21:52:27 -0800 (PST) (envelope-from jgs@juniper.net) From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 11 Nov 2009 14:52:26 +0900 Message-ID: <9DAD8E4B-17A5-4358-87A0-1314FDE68F9C@juniper.net> To: George Michaelson , Geoff Huston MIME-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 11 Nov 2009 05:52:27.0898 (UTC) FILETIME=[267DE5A0:01CA6293] Cc: sidr@ietf.org Subject: [sidr] Comments on draft-ietf-sidr-roa-validation-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 05:54:47 -0000 George and Geoff -- Some comments, questions, and nits for you (in that order). Comment: I think this text, from S 4.1, is not quite right: This approach to route object origination validation uses a model of "positive security" attestations, where information that cannot be validated within the RPKI framework is intended to interpreted by a RP as invalid information. Unless you interpret "unknown" as being a flavor of "invalid" (which would be terribly confusing!) this conflicts with S 2. It would have been right to say something to the effect of "... information that conflicts with validation data within the RPKI framework ...". I think you could make this change without loss of generality. Comment: I think you've already gotten feedback on the list suggesting that S 4.1 needs more clarity regarding the effect of maxLength. I agree. Comment: Given that you discuss BGP at some length, I think you need to talk about the case where the origin AS can't be determined, specifically where the AS_PATH starts with an AS_SET. (The same criticism applies to draft-pmohapat.) This is actually a somewhat vexing problem because on one hand, "unknown" seems the only reasonable outcome for such a route, but on the other, that would seem to provide an easy vector for an attacker to always be able to get his route to be ranked as "unknown" instead of "invalid". Then again, as we know origin authentication alone is trivially easy to attack so I think this is not too much of a practical concern. Comment: In S 4.3 I find this to be unclear: * It is a matter of local configuration as to whether ROA validation is performed on a per-AS basis rather than a per-BGP speaker, and the appropriate mechanisms to support a de-coupled framework of validation of ROAs and the loading of outcomes into BGP speakers are not considered here. In fact I only finally got after hearing George's presentation, that what you mean is whether validation is done on the router or in some off-box server. I think the red herring was the "per-AS" language. Question: S 4.2 says "... or even if the maxLength element were to be omitted from the ROA". Does the definition of a ROA even allow for that? I thought maxLength was a mandatory element (though I admit I haven't checked). Depending on the answer you might remove the clause. Nit: I found your use of the term "route object" confusing given earlier uses of the term to mean something different (e.g. in the IRR). How about using the term defined in RFC 4271 Section 1.1: Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message. The path is the information reported in the path attributes field of the same UPDATE message. You could refer to this as "BGP Route" to disambiguate it from any other meaning of "route". If you don't want to do this you might at least note up front that your use of "route object" is the same as "route" as defined in 4271 S1.1. Nit: S 4.1 "Routes objects that describe..." should be "Route objects that describe..." Or of course, just "Routes that describe" if you choose to adopt my suggestion above. Regards, --John From trac@tools.ietf.org Wed Nov 11 03:28:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C28F3A6953 for ; Wed, 11 Nov 2009 03:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJLZ+rKwK1GQ for ; Wed, 11 Nov 2009 03:28:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 50CB23A6A6F for ; Wed, 11 Nov 2009 03:28:18 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8BNW-0003Kb-Db; Wed, 11 Nov 2009 03:28:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Wed, 11 Nov 2009 11:28:46 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/7 Message-ID: <052.ce169896207bf3ff9ee2966f4857e842@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #7: nits for roa-validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:28:19 -0000 #7: nits for roa-validation --------------------------------+------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: roa-validation | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- reported by John Scudder: Comment: I think this text, from S 4.1, is not quite right: This approach to route object origination validation uses a model of "positive security" attestations, where information that cannot be validated within the RPKI framework is intended to interpreted by a RP as invalid information. Unless you interpret "unknown" as being a flavor of "invalid" (which would be terribly confusing!) this conflicts with S 2. It would have been right to say something to the effect of "... information that conflicts with validation data within the RPKI framework ...". I think you could make this change without loss of generality. Comment: I think you've already gotten feedback on the list suggesting that S 4.1 needs more clarity regarding the effect of maxLength. I agree. Comment: Given that you discuss BGP at some length, I think you need to talk about the case where the origin AS can't be determined, specifically where the AS_PATH starts with an AS_SET. (The same criticism applies to draft-pmohapat.) This is actually a somewhat vexing problem because on one hand, "unknown" seems the only reasonable outcome for such a route, but on the other, that would seem to provide an easy vector for an attacker to always be able to get his route to be ranked as "unknown" instead of "invalid". Then again, as we know origin authentication alone is trivially easy to attack so I think this is not too much of a practical concern. Comment: In S 4.3 I find this to be unclear: * It is a matter of local configuration as to whether ROA validation is performed on a per-AS basis rather than a per-BGP speaker, and the appropriate mechanisms to support a de-coupled framework of validation of ROAs and the loading of outcomes into BGP speakers are not considered here. In fact I only finally got after hearing George's presentation, that what you mean is whether validation is done on the router or in some off-box server. I think the red herring was the "per-AS" language. Question: S 4.2 says "... or even if the maxLength element were to be omitted from the ROA". Does the definition of a ROA even allow for that? I thought maxLength was a mandatory element (though I admit I haven't checked). Depending on the answer you might remove the clause. Nit: I found your use of the term "route object" confusing given earlier uses of the term to mean something different (e.g. in the IRR). How about using the term defined in RFC 4271 Section 1.1: Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destinations are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Information (NLRI) field of an UPDATE message. The path is the information reported in the path attributes field of the same UPDATE message. You could refer to this as "BGP Route" to disambiguate it from any other meaning of "route". If you don't want to do this you might at least note up front that your use of "route object" is the same as "route" as defined in 4271 S1.1. Nit: S 4.1 "Routes objects that describe..." should be "Route objects that describe..." Or of course, just "Routes that describe" if you choose to adopt my suggestion above. Regards, --John -- Ticket URL: sidr From trac@tools.ietf.org Wed Nov 11 03:41:58 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC2D3A6A86 for ; Wed, 11 Nov 2009 03:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHgTfbvyaKOC for ; Wed, 11 Nov 2009 03:41:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 02DFB3A6967 for ; Wed, 11 Nov 2009 03:41:58 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8Bak-00047c-AH; Wed, 11 Nov 2009 03:42:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Wed, 11 Nov 2009 11:42:26 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/8 Message-ID: <052.c1394f1f0cdd92b7c28c41039a0bf64c@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #8: Distinguished Names in the RPKI X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:41:59 -0000 #8: Distinguished Names in the RPKI -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: enhancement | Status: new Priority: medium | Milestone: Component: res-certs | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- reported by Steve Kent: Tim Polk asked David Cooper (a NIST colleague) to check on the question that was raised during our meeting yesterday morning. The question was whether, if we require Subject and Issuer names in X.509 certs to be either just a CN or a CN plus a serialNumber (as a set), one could use commonly available CA software generate certs. The answer is that both OpenSSL and an NSS can do this. OpenSSL required some configuration effort, but David provided the details of the config params in his response! this related to arch and res-cert drafts - one, or both need to reflect this structure if adopted -- Ticket URL: sidr From trac@tools.ietf.org Wed Nov 11 03:49:07 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AC13A694A for ; Wed, 11 Nov 2009 03:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-YPUihxzGTc for ; Wed, 11 Nov 2009 03:49:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id F1F8C3A680D for ; Wed, 11 Nov 2009 03:49:06 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8Bhf-0002fl-Ao; Wed, 11 Nov 2009 03:49:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Wed, 11 Nov 2009 11:49:35 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/9 Message-ID: <052.ca9ad92ff2f02764f9981b0f526eafac@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #9: TA nits X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:49:07 -0000 #9: TA nits --------------------------------+------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: medium | Milestone: Component: ta | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Reported by Roque Gagliano 2.1. A Compound Trust Anchor Structure The ETA issues a CRL and one EE certificate. (Roque) I believe it needs to be explained that more than one ETA EE cert may be issued during the life-time of the ETA CA however at any particular moment there is only one valid EE cert. 4.2. RPKI Trust Anchor Object Validation 2. Use the public key in the EE certificate to verify the signature on the RTA Trust Anchor Object. (Roque) s/EE certificate/ETA EE certificate * Each time an RTA certificate is re-issued, or prior to the expiration of the ETA EE certificate, the ETA generates a Cryptographic Message Syntax (CMS) [RFC3852] signed-data object, the payload of which is an RTA certificate. (Roque) If the ETA EE cert validity period is identical to the RTA validity period as stated in a previous bullet, the second condition ("prior to the expiration of the ETA EE certificate") would be the same as in the following section: "If a trust anchor chooses to reissue its RTA certificate before the expiration of that certificate." 5. Relying Party use of Trust Anchor Material * The ETA's CRL and CMS objects are retrieved from the publication point referenced by the SIA in the ETA certificate. (Roque) s/CMS objects/CMS object Relying Parties SHOULD perform this retrieval and validation operation at intervals no less frequent than the nextUpdate time of the published ETA CRL, and SHOULD perform the retrieval operation prior to the expiration of the ETA EE certificate, or upon revocation of the ETA EE certificate. (Roque) If the retrieval operation is for both the CRL and the CMS, I do not understand the last sentence because the RP is not aware of the revocation until it has retrieve the CRL and in at that time it already has the new CMS. So, I would: s/, or upon revocation of the ETA EE certificate// -- Ticket URL: sidr From trac@tools.ietf.org Wed Nov 11 03:57:44 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1126728C2A5 for ; Wed, 11 Nov 2009 03:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rs0kz-heTLY for ; Wed, 11 Nov 2009 03:57:43 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 4CB8E3A688D for ; Wed, 11 Nov 2009 03:57:43 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8Bpz-00057n-KP; Wed, 11 Nov 2009 03:58:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Wed, 11 Nov 2009 11:58:11 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/2#comment:1 Message-ID: <061.badbd3f92650cc2738f4fbefa75777d2@tools.ietf.org> References: <052.947c78bd70e89e1731e39d171c3df515@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <052.947c78bd70e89e1731e39d171c3df515@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #2: Objection noted to operational considerations in architecture document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 11:57:44 -0000 #2: Objection noted to operational considerations in architecture document -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Comment(by gih@…): - Matt Lepinski (6/11) With regards to the frequency with which relying parties fetch data from the repository system (be that authoritative publication points or caches operated by ISPs or RIRs), there appears to be a trade-off between "max time to fix a problem" vs "work required by the repository system and the relying parties". From this thread, it seems that there isn't an obvious right answer with regards to how often relying parties should query the repository system, but that there are risks associated with queries that are too frequent or too infrequent. To me, it seems that the best way to address this problem is to publish an "operational practices" document of some sort that documents this (and other) operational concerns and recommends practices to mitigate such risks. [That is, Sandy's (b) option]. With regards to the architecture document (which I would very much like to see leave the working group in near future), I believe the best way forward is for the architecture document to be silent on this issue. For example, consider the following text for Section 6 (last paragraph on page 15 of the arch-09): "Note that since relying parties will perform these operations regularly, it is more efficient for the relying party to request from the repository system only those objects that have changed since the relying party last updated its local cache. A relying party shall choose the frequency with which it downloads and validates updates from the repository system." -- Ticket URL: sidr From trac@tools.ietf.org Wed Nov 11 04:00:22 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93AD3A6A7A for ; Wed, 11 Nov 2009 04:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ee3cbHIg7YmA for ; Wed, 11 Nov 2009 04:00:21 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id C37843A6961 for ; Wed, 11 Nov 2009 04:00:21 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8BsY-00081l-6A; Wed, 11 Nov 2009 04:00:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Wed, 11 Nov 2009 12:00:50 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/3#comment:1 Message-ID: <061.af4b8b42303f6d2493cb681288dff9a9@tools.ietf.org> References: <052.43219578bfb8d05913d47e8738305d11@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <052.43219578bfb8d05913d47e8738305d11@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #3: Nit Report - CP draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:00:22 -0000 #3: Nit Report - CP draft -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: cp | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Comment(by gih@…): Steve Kent (5/11) IN a message on 10/28 you said: * Section 4.6.1-3 I'd like it made clear that renewal be only to the same subscriber. eg the subscriber before and after renewal is the same. At present it says that only the valid subscriber may request renewal, but allows a new private key. I think there is too much wriggle room in that for a subscriber to renew with someone else's private key. I reviewed the CP text and I think this is clear. Specifically 4.6.2 says: "Only the certificate holder or the issuing CA may initiate the renewal process." And 4.6.3 says: "Renewal procedures must ensure that the person or organization seeking to renew a certificate is in fact the subscriber (or authorized by the subscriber) of the certificate and the legitimate holder of the INR associated with the renewed certificate." I think these two text sections already address the issue you raised. -- Ticket URL: sidr From kent@bbn.com Wed Nov 11 13:06:15 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053C13A68EE for ; Wed, 11 Nov 2009 13:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 NBOh7t3WfvwZ for ; Wed, 11 Nov 2009 13:06:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4500A3A6864 for ; Wed, 11 Nov 2009 13:06:14 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.112.234]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8KOn-0002GW-Cj for sidr@ietf.org; Wed, 11 Nov 2009 16:06:42 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 11 Nov 2009 16:06:38 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] OpenCA info X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 21:06:15 -0000 I checked with Max Pala, and he confirmed that the OpenCA software (an open source CA package) is also capable of generating a Subject or Issuer name that is just a single set consisting of a common name attribute and the serial number attribute. with this info I think we are safe to proceed to mandate this name format. I agree with Russ' observation that this is not a common format and that it might confuse a user viewing it. However, since these names are not intended to be human meaningful, and will not be popping in in a browser or an S/MIME message, I don't think this is a serious concern. Steve From ggm+ietf@apnic.net Wed Nov 11 15:05:40 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489873A6B52 for ; Wed, 11 Nov 2009 15:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 B2cCvZvwoUSx for ; Wed, 11 Nov 2009 15:05:39 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8E5C83A68FC for ; Wed, 11 Nov 2009 15:05:38 -0800 (PST) Received: from host-112-209.meeting.ietf.org (host-112-209.meeting.ietf.org [133.93.112.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 37A46D58C4; Thu, 12 Nov 2009 09:15:36 +1000 (EST) From: George Michaelson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 08:06:00 +0900 Message-Id: To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [sidr] where to document the new name constraints X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:05:40 -0000 The options for documenting this aspect of distinguished name structure = for the RPKI are to place this in either the CP, the architecture, or = the certificate profile documents.=20 It is important to think about this from the perspective of a future = reader of the RPKI documents. In that context, it seems to me that this is clearly a profile = constraint, and thus should be with the other format constraints over = names and structural elements in the certificate profile draft.=20 Therefore, I wish to advocate to the WG that this name constraint for = both Issuer, and Subject names in RPKI certificates be documented in the = res-cert profile document. Sorry for a late addition to this document in WGLC Steve, but I think = this is necessary. cheers -George= From kent@bbn.com Wed Nov 11 16:59:36 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4373A68DE for ; Wed, 11 Nov 2009 16:59:36 -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 TQ2yMVY2hp5m for ; Wed, 11 Nov 2009 16:59:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9D4713A6828 for ; Wed, 11 Nov 2009 16:59:35 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8O2c-0006p6-CN; Wed, 11 Nov 2009 20:00:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 Nov 2009 19:04:28 -0500 To: George Michaelson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] where to document the new name constraints X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 00:59:36 -0000 At 8:06 AM +0900 11/12/09, George Michaelson wrote: >The options for documenting this aspect of distinguished name >structure for the RPKI are to place this in either the CP, the >architecture, or the certificate profile documents. > >It is important to think about this from the perspective of a future >reader of the RPKI documents. > >In that context, it seems to me that this is clearly a profile >constraint, and thus should be with the other format constraints >over names and structural elements in the certificate profile draft. > >Therefore, I wish to advocate to the WG that this name constraint >for both Issuer, and Subject names in RPKI certificates be >documented in the res-cert profile document. > >Sorry for a late addition to this document in WGLC Steve, but I >think this is necessary. > >cheers > >-George I do not disagree with your analysis. Steve From trac@tools.ietf.org Thu Nov 12 03:24:17 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98ED83A6A63 for ; Thu, 12 Nov 2009 03:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOfKCQEoLavB for ; Thu, 12 Nov 2009 03:24:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E3ECA3A69DE for ; Thu, 12 Nov 2009 03:24:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8XnA-0005sj-Sc; Thu, 12 Nov 2009 03:24:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Thu, 12 Nov 2009 11:24:44 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/10 Message-ID: <052.9ebf03e9e891d8dc05ff816d0f2ee3b0@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #10: Notice of changes to the CP - time for such notice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 11:24:17 -0000 #10: Notice of changes to the CP - time for such notice -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: medium | Milestone: Component: cp | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Reported by John Curran 5/11 One issue which is raised is that a RPKI service provider now may be made subject (with one month's notice) to changes to the CP made by the IETF. As the CP specifies operational practices, this has potential to be impacting for the RPKI service provider and ISP's relying upon such certs. In order to protect those relying ISPs in the case of a CP change which causes RPKI providers to exit the business, the 9.12.2 implementation time period to should be long enough to allow ISP's to move to an RPKI providers now complying with the new CP document. I'd recommend 6 months advance notice rather than one for this reason. Thanks, /John John, Fair point. I thought about the 1 month value when I was editing the text, having not looked at it for a long time. I thought that the IESG/RFC process was sufficiently long that anyone who was watching would have a lot more than 1 month advance notice :-). However, not everyone who might be affected would necessarily be tracking a proposed change, and the change would, not be definite until approved by the IESG. So, I think this is very reasonable change this value to be 6 months. Steve -- Ticket URL: sidr From trac@tools.ietf.org Thu Nov 12 03:28:07 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF97528C0EA for ; Thu, 12 Nov 2009 03:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9OC8RKJygpo for ; Thu, 12 Nov 2009 03:28:07 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 35EE53A6A43 for ; Thu, 12 Nov 2009 03:28:07 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N8Xqu-0001xJ-Gy; Thu, 12 Nov 2009 03:28:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Thu, 12 Nov 2009 11:28:36 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/3#comment:2 Message-ID: <061.e47b8cb7721898afc5998509b23c125e@tools.ietf.org> References: <052.43219578bfb8d05913d47e8738305d11@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <052.43219578bfb8d05913d47e8738305d11@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #3: Nit Report - CP draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 11:28:08 -0000 #3: Nit Report - CP draft -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: cp | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Comment(by gih@…): Proposed changes: Steve Kent 5/11 Changed status to be Best Current Practice from Informational (consistent with eventual BCP designation) In Section 1.7 revised text (removed references to SIDR WG) RPKI signed object - Digitally signed data object (other than a certificate or CRL) declared to be such by a standards track RFC, and that can be validated using certificates issued under this PKI. ------ Section 1.4.4 revised text (removed references to SIDR WG) An RPKI signed object is a digitally-signed object, declared to be such by a standards track RFC. ------- Section 9.12.1 revised text (removed reference to RIRs and IANA, replaced with IETF) The procedure for amending this CP is via written notice from the IETF in the form of a new Standards Track, BCP RFC that updates or obsoletes this document. ------ Sectioon 9.12.2 revised text (removed reference to RIRs and IANA, replaced with IETF) The IETF will provide at least one month's advance notice of any changes to this CP. ------- Section 9.12.3 revised text (removed reference to RIRs and IANA, replaced with IETF) If the IETF judges that changes to the CP do not materially reduce the acceptability of certificates issued for RPKI purposes, there will be no change to the CP OID. If the IETF judges that changes to the CP do materially change the the acceptability of certificates for RPKI purposes, then there will be a new CP OID. Section 13.2 (removed last two informative references) -- Ticket URL: sidr From Sandra.Murphy@cobham.com Tue Nov 17 16:10:37 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35233A6879 for ; Tue, 17 Nov 2009 16:10: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 XSK0caFzes5X for ; Tue, 17 Nov 2009 16:10:35 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3F16D3A67B3 for ; Tue, 17 Nov 2009 16:10:35 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nAI0ARMr005555; Tue, 17 Nov 2009 18:10:27 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAI0AOuU019824; Tue, 17 Nov 2009 18:10:24 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.106]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 19:10:24 -0500 Date: Tue, 17 Nov 2009 19:10:23 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <8CE242B1-05C5-4550-BB66-1FE76DEA22D6@apnic.net> Message-ID: References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> <8CE242B1-05C5-4550-BB66-1FE76DEA22D6@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Nov 2009 00:10:24.0495 (UTC) FILETIME=[867B5FF0:01CA67E3] Cc: sidr@ietf.org Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:10:37 -0000 Reminder to all that this draft is supposed to expire today. There have been no calls against adoption, and five calls for adoption. If you have an opinion to express, please get it in quickly. --Sandy On Mon, 2 Nov 2009, Geoff Huston wrote: > Obviously my skills at elementary addition are to be found wanting! > > Two weeks from today is Tuesday November 17th. > > My apologies for any confusion here - this call will run from now until > November 17th > > > regards, > > Geoff > > > > > On 02/11/2009, at 12:42 PM, Geoff Huston wrote: > >> Hi, >> >> I am opening a two week wg call for comments on the adoption of this >> document as a working group item. >> >> The document is available at: >> >> http://www.ietf.org/id/draft-manderson-sidr-usecases-01.txt >> >> Please respond, either accept or not accept, by Tues Nov 10 2009. >> >> As usual, the rules are that silence does not indicate assent, so please >> actively reply. >> >> If you support adoption of this draft as a working group item, please also >> indicate whether you will be able to work on the draft (contribute or >> review). >> >> --Geoff >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Tue Nov 17 16:18:38 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310E63A6B32 for ; Tue, 17 Nov 2009 16:18: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 6aKJO9rk4lLi for ; Tue, 17 Nov 2009 16:18:36 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C0A623A6ADF for ; Tue, 17 Nov 2009 16:18:36 -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 nAI0IYsO005651 for ; Tue, 17 Nov 2009 18:18:34 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAI0IYSD020058 for ; Tue, 17 Nov 2009 18:18:34 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.106]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 19:18:33 -0500 Date: Tue, 17 Nov 2009 19:18:33 -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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Nov 2009 00:18:33.0888 (UTC) FILETIME=[AA2ED200:01CA67E4] Subject: [sidr] reminder about slate of WGLC in progress X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:18:38 -0000 This is a reminder that you should be reviewing the following documents and sending comments to this list. To quote Geoff: "Please be clear in your comments to this last call if you are supporting the document's submission to the IESG or if you are opposed, or if you are not expressing a view either way." The last call closes on Mon 23 Nov 2009. 1. A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-17 http://tools.ietf.org/wg/sidr/draft-ietf-sidr-res-certs/ (Intended status: Standards Track) 2. Certificate Policy (CP) for the Resource PKI (RPKI) draft-ietf-sidr-cp-07.txt http://tools.ietf.org/wg/sidr/draft-ietf-sidr-cp/ (Intended Status: Informational) 3. A Profile for Route Origin Authorizations (ROAs) draft-ietf-sidr-roa-format-06.txt http://tools.ietf.org/wg/sidr/draft-ietf-sidr-roa-format/ (Intended Status: Proposed Standard) 4. An Infrastructure to Support Secure Internet Routing draft-ietf-sidr-arch-09.txt http://tools.ietf.org/wg/sidr/draft-ietf-sidr-arch/ (Intended status: Informational) 5. A Protocol for Provisioning Resource Certificates draft-ietf-sidr-rescerts-provisioning-05.txt http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rescerts-provisioning/ (Intended status: Standards Track) 6. A Profile for Resource Certificate Repository Structure draft-ietf-sidr-repos-struct-03.txt http://tools.ietf.org/wg/sidr/draft-ietf-sidr-repos-struct/ (Intended status: BCP) --Sandy From gih@apnic.net Tue Nov 17 16:18:50 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F163A6B36 for ; Tue, 17 Nov 2009 16:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkvA2tjIscGy for ; Tue, 17 Nov 2009 16:18:49 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 384373A6ADF for ; Tue, 17 Nov 2009 16:18:48 -0800 (PST) Received: from dynamic134.apnic.net (dynamic134.apnic.net [203.119.42.134]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A496DD590A; Wed, 18 Nov 2009 10:28:56 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 18 Nov 2009 11:18:38 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> <8CE242B1-05C5-4550-BB66-1FE76DEA22D6@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:18:50 -0000 WG co-chair hat ON Thank you for the reminder Sandy. I was waiting for the 17th of November to pass in all parts of the world = before making a consensus call on adoption as a working group document, = allowing for the (admittedly unlikely) possibility of a last second = flurry of objections to this proposed action. I'll post a summary of my = view of the WG consensus on this call for document adoption in about 24 = hours or so from now. Geoff WG co-chair hat ON On 18/11/2009, at 11:10 AM, Sandra Murphy wrote: > Reminder to all that this draft is supposed to expire today. There = have been no calls against adoption, and five calls for adoption. If = you have an opinion to express, please get it in quickly. >=20 > --Sandy >=20 >=20 > On Mon, 2 Nov 2009, Geoff Huston wrote: >=20 >> Obviously my skills at elementary addition are to be found wanting! >>=20 >> Two weeks from today is Tuesday November 17th. >>=20 >> My apologies for any confusion here - this call will run from now = until November 17th >>=20 >>=20 >> regards, >>=20 >> Geoff >>=20 >>=20 >>=20 >>=20 >> On 02/11/2009, at 12:42 PM, Geoff Huston wrote: >>=20 >>> Hi, >>> I am opening a two week wg call for comments on the adoption of this = document as a working group item. >>> The document is available at: >>>=20 >>> http://www.ietf.org/id/draft-manderson-sidr-usecases-01.txt >>> Please respond, either accept or not accept, by Tues Nov 10 2009. >>> As usual, the rules are that silence does not indicate assent, so = please actively reply. >>> If you support adoption of this draft as a working group item, = please also indicate whether you will be able to work on the draft = (contribute or review). >>> --Geoff >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Tue Nov 17 16:21:04 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9707C3A6B32 for ; Tue, 17 Nov 2009 16:21:04 -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 KbfCioJ0-5cf for ; Tue, 17 Nov 2009 16:21:03 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8C6603A6B36 for ; Tue, 17 Nov 2009 16:21:03 -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 nAI0KxwY005668; Tue, 17 Nov 2009 18:20:59 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAI0KxY7020091; Tue, 17 Nov 2009 18:21:00 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.106]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2009 19:20:59 -0500 Date: Tue, 17 Nov 2009 19:20:59 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: Message-ID: References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> <8CE242B1-05C5-4550-BB66-1FE76DEA22D6@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 18 Nov 2009 00:20:59.0749 (UTC) FILETIME=[011F7150:01CA67E5] Cc: sidr@ietf.org Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:21:04 -0000 On Tue, 17 Nov 2009, Sandra Murphy wrote: > Reminder to all that this draft is supposed to expire today. There have been So sorry - the draft is not supposed to expire today, the call for adoption is supposed to end today. I wish my typing would match my thinking. --Sandy > no calls against adoption, and five calls for adoption. If you have an > opinion to express, please get it in quickly. > > --Sandy > > > On Mon, 2 Nov 2009, Geoff Huston wrote: > >> Obviously my skills at elementary addition are to be found wanting! >> >> Two weeks from today is Tuesday November 17th. >> >> My apologies for any confusion here - this call will run from now until >> November 17th >> >> >> regards, >> >> Geoff >> >> >> >> >> On 02/11/2009, at 12:42 PM, Geoff Huston wrote: >> >>> Hi, >>> >>> I am opening a two week wg call for comments on the adoption of this >>> document as a working group item. >>> >>> The document is available at: >>> >>> http://www.ietf.org/id/draft-manderson-sidr-usecases-01.txt >>> >>> Please respond, either accept or not accept, by Tues Nov 10 2009. >>> >>> As usual, the rules are that silence does not indicate assent, so please >>> actively reply. >>> >>> If you support adoption of this draft as a working group item, please also >>> indicate whether you will be able to work on the draft (contribute or >>> review). >>> >>> --Geoff >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From gih@apnic.net Tue Nov 17 16:39:28 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B573A6A4C for ; Tue, 17 Nov 2009 16:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8MNMnxWQTAg for ; Tue, 17 Nov 2009 16:39:27 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 872A63A67B3 for ; Tue, 17 Nov 2009 16:39:26 -0800 (PST) Received: from dynamic134.apnic.net (dynamic134.apnic.net [203.119.42.134]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0500BD590A; Wed, 18 Nov 2009 10:49:35 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 18 Nov 2009 11:39:17 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rob Austein , Stephen Kent , Matt Lepinski X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:39:28 -0000 WG co-chair hat OFF This is a posting made in my role as a document co-author, and not as a = co-chair of the WG In reviewing the manifest document I notice that the document in its = current version defines a manifest as an RPKI construct. I have two = questions about this: 1. Should the manifest document be constrained in this manner as being = exclusively an RPKI construct, or should the reference to exclusive use = by the RPKI be removed such that the manifest is defined in a manner = that is agnostic to the context of the PKI in which the manifest may be = used, so that any CA may use a manifest? 2. In the context of the RPKI should the manifest document used a SHOULD = to specify that the resources in the RPKI EE certificate used to = validate the manifest's signature be specified using the inherit bit = setting of the RFC3779 extensions? Do any of the document's co-authors, or any WG folk, have an opinion of = either or both of these questions that they'd like to share? thanks, Geoff WG co-chair hat OFF From robert@ripe.net Wed Nov 18 03:26:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0263A6B2D for ; Wed, 18 Nov 2009 03:26: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 tXJDNaDLSVI5 for ; Wed, 18 Nov 2009 03:26:29 -0800 (PST) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id E89F73A6A25 for ; Wed, 18 Nov 2009 03:26:28 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NAifo-0003Zb-VO; Wed, 18 Nov 2009 12:26:14 +0100 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id DF90C2F583; Wed, 18 Nov 2009 12:26:08 +0100 (CET) Message-ID: <4B03D9D0.6030309@ripe.net> Date: Wed, 18 Nov 2009 12:26:08 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Geoff Huston References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2746958a74f13824bd7f2a5932168572fba Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:26:30 -0000 Geoff Huston wrote: > WG co-chair hat OFF > > This is a posting made in my role as a document co-author, and not as a > co-chair of the WG > > In reviewing the manifest document I notice that the document in its > current version defines a manifest as an RPKI construct. I have two > questions about this: > > 1. Should the manifest document be constrained in this manner as being > exclusively an RPKI construct, or should the reference to exclusive use > by the RPKI be removed such that the manifest is defined in a manner that > is agnostic to the context of the PKI in which the manifest may be used, > so that any CA may use a manifest? > > 2. In the context of the RPKI should the manifest document used a SHOULD > to specify that the resources in the RPKI EE certificate used to validate > the manifest's signature be specified using the inherit bit setting of > the RFC3779 extensions? > > Do any of the document's co-authors, or any WG folk, have an opinion of > either or both of these questions that they'd like to share? > > thanks, > > Geoff > > WG co-chair hat OFF I think there's a benefit of allowing this construct to be used in an RPKI related, but not strictly RPKI repository, or even in an RPKI unrelated context. So I'd be in favor of making it more generic (see 1), which also means relaxing the rules on the EE cert (see 2). Robert From robertl@apnic.net Wed Nov 18 15:19:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA42A3A6B02 for ; Wed, 18 Nov 2009 15:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF7t9oogqVml for ; Wed, 18 Nov 2009 15:19:18 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C23413A677D for ; Wed, 18 Nov 2009 15:19:17 -0800 (PST) Received: from [203.119.42.143] (dynamic143.apnic.net [203.119.42.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 003B1D58C4; Thu, 19 Nov 2009 09:29:31 +1000 (EST) Message-ID: <4B0480F1.3060304@apnic.net> Date: Thu, 19 Nov 2009 09:19:13 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18) Gecko/20081105 Lightning/0.9 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Geoff Huston References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAMAAABg3Am1AAAAGFBMVEUbGxs1NTVVVVVycnKO jo6tra3MzMzg4OAC8PijAAACVElEQVR42pWVW3bjMAxDKT6U/e94AJBWXLcfHrRJpBhXoKjj2D7Q hqoyI8Jv4vTxTW6b4ZLOcD6do3XzA1g9qEKK0orGmeSuWGIHKCZE1KZkwgtA4oOzwjsMB4DRehID ULFgqc+ls49gwOami0xcwI41ipkfFRzWTWKlqZCi1ZpwRVRGQtHXG6gqRyHtN1tH1X0gMF0x+pPV 5fKs+/pSfh4yrh8AmvD11C9gM8CjQERgv+ds5/TiCWTSwYjKjc7kD8ViCT8AnzOBdppreyOOnSVc iLrkI/j3+g2E9fTItHjbEmVrcAfWmlFRTOhhJgImIUv/Uph57VmAS1+JWTt82brC8gCIHQub0yWl gAXAG5AGABGcBp0NdIs2zxjwXZGBVBIYUwL8DuhUhPEuOGePAAhllAUdAtzSMl0OgMANQAiIPXdZ GV6KKwCxMATBzaVTTOwISQCkDe6wORG91zVJARioOQK6Zzw3ekaV0gHKg0oCImKXr/wFxAMIAgrw rDAYngm9a/sCBbF3jojlDaj8KS8agGmA7jcAr8K1cXWHJmCAbIBT+Um4tekoES6dCgV4KxFBj86S IQcwdbkB/2pVyUQ7pOGpaLpaBI6i6IrZhLJcwCz1TFBEDDHt8gkIXTjAUYV6OgoBE6DsEKDnxgCW Kr7tNE0AgXtbPRrAxRi1p3TDzcEc4MjMco9ZjgTg8h/gKf465/d54GZXESr7DyD4a5vZ/m0vVE3I X/ZGG5oHiL3T/uCPcntPLBX0Hgh2y18DVf3AfQ/sD/U+IUoPKvsPLV/2p/4BtMMZxXNLW/wAAAAA SUVORK5CYII= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:19:20 -0000 Geoff Huston wrote: > 2. In the context of the RPKI should the manifest document used a > SHOULD to specify that the resources in the RPKI EE certificate used > to validate the manifest's signature be specified using the inherit > bit setting of the RFC3779 extensions? I agree with this: A MUST would be too strong here; I believe that a SHOULD is appropriate. Rob -- Robert Loomans email: robertl@apnic.net Senior Software Engineer, APNIC sip: robertl@voip.apnic.net http://www.apnic.net/ phone: +61 7 3858 3100 From ggm@apnic.net Wed Nov 18 19:30:28 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7923A68D0 for ; Wed, 18 Nov 2009 19:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T14gzr9cN3Y2 for ; Wed, 18 Nov 2009 19:30:28 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 3B8ED3A692E for ; Wed, 18 Nov 2009 19:30:25 -0800 (PST) Received: from dynamic237.apnic.net (dynamic237.apnic.net [203.119.42.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 8F685D58C4; Thu, 19 Nov 2009 13:40:41 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Thu, 19 Nov 2009 13:30:18 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0A956CA4-5B4A-4B3C-BC97-68F5742EC4F6@apnic.net> References: To: Geoff Huston X-Mailer: Apple Mail (2.1077) Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 03:30:29 -0000 Not wanting to put words in his mouth, I believe Steve has said that the = manifest, or something very similar in terms of a formally signed = statement of what IS in a repository, as opposed to a CRL as a mechanism = to deprecate what should NOT be in a repository, was a concept raised = during early phases of X509 design, and dropped for various reasons. So, = there is some sense that this is a general purpose, useful thing, and in = that context, I am attracted to generalizing words around it in SIDR = drafts, so that should it become more common in other PKI contexts, = there is good support for it from tools. Therefore, I think it would be best to remove strong normative = requirements for RFC3779 extensions in EE certificates from the = manifest, unless there is a clear reason relating to RPKI facing = context, in which case it would be nice to find words which make it = plain that an OID, or Version, or some other reference clarifies why the = RPKI Manifest Certificate has mandatory elements which a more general = manifest might not have. Maybe a mechanism like tying the OID of the certificate used to an OID = in the Manifest itself, so that its clear the certificates context = defines why 3779 is relevant? Thats a reasonably low-level cost in = ASN.1. -George= From gih@apnic.net Thu Nov 19 03:36:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C713A6907 for ; Thu, 19 Nov 2009 03:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds9eD5RjMMJt for ; Thu, 19 Nov 2009 03:36:42 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 261983A6924 for ; Thu, 19 Nov 2009 03:36:41 -0800 (PST) Received: from [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a] (unknown [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id DF866D58CB; Thu, 19 Nov 2009 21:46:57 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> Date: Thu, 19 Nov 2009 22:36:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B08A3D4-04BE-4244-BB7A-E3B2C5FF7BC4@apnic.net> References: <4159038A-5F92-4B4D-944F-92DFE0AC398F@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Cc: Russ White Subject: Re: [sidr] Call for WG adoption of draft-manderson-sidr-usecases-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 11:36:43 -0000 WG co-chair hat ON Hi, In response to this call for WG adoption of this document, I have seen 5 = postings of support for this adoption of this draft and none opposed in = the two week period. The postings in support were received from Seiichi = Kawamura, Rob Loomans, Sam Weiler, Steve Kent and Danny McPherson. I am of the view that this is sufficient demonstration of a consensus of = the WG to accept this draft as a WG document. Authors, could you please resubmit this draft as a SIDR draft at your = convenience? thanks, Geoff WG co-chair hat ON On 02/11/2009, at 12:42 PM, Geoff Huston wrote: > Hi, >=20 > I am opening a two week wg call for comments on the adoption of this = document as a working group item. >=20 > The document is available at: >=20 > http://www.ietf.org/id/draft-manderson-sidr-usecases-01.txt >=20 > Please respond, either accept or not accept, by Tues Nov 17 2009. >=20 > As usual, the rules are that silence does not indicate assent, so = please actively reply. >=20 > If you support adoption of this draft as a working group item, please = also indicate whether you will be able to work on the draft (contribute = or review). >=20 > --Geoff > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Fri Nov 20 13:52:14 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC5328C11D for ; Fri, 20 Nov 2009 13:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYvwvg3E5TvN for ; Fri, 20 Nov 2009 13:52:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A87663A67CC for ; Fri, 20 Nov 2009 13:52:13 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.3]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NBbOh-0000ck-AA; Fri, 20 Nov 2009 16:52:07 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 20 Nov 2009 16:51:45 -0500 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:52:14 -0000 At 11:39 AM +1100 11/18/09, Geoff Huston wrote: >WG co-chair hat OFF > >This is a posting made in my role as a document co-author, and not >as a co-chair of the WG > >In reviewing the manifest document I notice that the document in its >current version defines a manifest as an RPKI construct. I have two >questions about this: > >1. Should the manifest document be constrained in this manner as >being exclusively an RPKI construct, or should the reference to >exclusive use by the RPKI be removed such that the manifest is >defined in a manner that is agnostic to the context of the PKI in >which the manifest may be used, so that any CA may use a manifest? > >2. In the context of the RPKI should the manifest document used a >SHOULD to specify that the resources in the RPKI EE certificate used >to validate the manifest's signature be specified using the inherit >bit setting of the RFC3779 extensions? > >Do any of the document's co-authors, or any WG folk, have an opinion >of either or both of these questions that they'd like to share? > >thanks, > > Geoff > >WG co-chair hat OFF I agree that the manifest structure is more general than the RPKI context. However, if we choose to make the manifest document generic, we probably need another document that profiles it for the RPKI. Steve From gih@apnic.net Fri Nov 20 16:18:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5FA3A6808 for ; Fri, 20 Nov 2009 16:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFV9y4Be+OPq for ; Fri, 20 Nov 2009 16:18:25 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 763F23A67BE for ; Fri, 20 Nov 2009 16:18:24 -0800 (PST) Received: from [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a] (unknown [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4874BD58CA; Sat, 21 Nov 2009 10:28:50 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 21 Nov 2009 11:18:17 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B72EF6F-EFE7-48EE-BA73-7AEBAB4C89BA@apnic.net> References: To: Stephen Kent X-Mailer: Apple Mail (2.1077) Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:18:26 -0000 On 21/11/2009, at 8:51 AM, Stephen Kent wrote: > At 11:39 AM +1100 11/18/09, Geoff Huston wrote: >> WG co-chair hat OFF >>=20 >> This is a posting made in my role as a document co-author, and not as = a co-chair of the WG >>=20 >> In reviewing the manifest document I notice that the document in its = current version defines a manifest as an RPKI construct. I have two = questions about this: >>=20 >> 1. Should the manifest document be constrained in this manner as = being exclusively an RPKI construct, or should the reference to = exclusive use by the RPKI be removed such that the manifest is defined = in a manner that is agnostic to the context of the PKI in which the = manifest may be used, so that any CA may use a manifest? >>=20 >> 2. In the context of the RPKI should the manifest document used a = SHOULD to specify that the resources in the RPKI EE certificate used to = validate the manifest's signature be specified using the inherit bit = setting of the RFC3779 extensions? >>=20 >> Do any of the document's co-authors, or any WG folk, have an opinion = of either or both of these questions that they'd like to share? >>=20 >> thanks, >>=20 >> Geoff >>=20 >> WG co-chair hat OFF >=20 > I agree that the manifest structure is more general than the RPKI = context. >=20 > However, if we choose to make the manifest document generic, we = probably need another document that profiles it for the RPKI. >=20 > Steve WG co-chair hat OFF This is a posting made in my role as a document co-author, and not as a = co-chair of the WG. Thanks for this comment Steve. I am happy to attempt to redraft the = manifest as a more generic document that describes a manifest in terms = of a list of published products of a CA, with a signature that is = verified using an EE certificate that is a subordinate product of that = CA. At this stage I'm of the view that the only RPKI-specific profile would = be to say that the RPKI EE cert SHOULD use the inherit bit in the = RFC3779 extension, and this seeems such a small profile component that = it could fit into the res-cert profile draft in its own section. regards, Geoff WG co-chair hat OFF From randy@psg.com Fri Nov 20 16:41:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E443A686B for ; Fri, 20 Nov 2009 16:41: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=[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 ipHSrotgtTId for ; Fri, 20 Nov 2009 16:41:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 649463A67B2 for ; Fri, 20 Nov 2009 16:41:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NBe2O-0006pU-GN; Sat, 21 Nov 2009 00:41:16 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id DF3452C272CD; Sat, 21 Nov 2009 09:41:15 +0900 (JST) Date: Sat, 21 Nov 2009 09:41:15 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:41:26 -0000 > I agree that the manifest structure is more general than the RPKI > context. is that a problem for this wg? i.e. should this, rather narrowly focused wg, be doing this work. we could miss a lot and step on others' toes. randy From kent@bbn.com Sat Nov 21 05:05:32 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7F63A68F9 for ; Sat, 21 Nov 2009 05:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YkL2YIqxn4j for ; Sat, 21 Nov 2009 05:05:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4B2F73A682E for ; Sat, 21 Nov 2009 05:05:31 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.3]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NBpeZ-0005B4-Bw; Sat, 21 Nov 2009 08:05:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 21 Nov 2009 08:05:25 -0500 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 13:05:32 -0000 At 9:41 AM +0900 11/21/09, Randy Bush wrote: > > I agree that the manifest structure is more general than the RPKI >> context. > >is that a problem for this wg? i.e. should this, rather narrowly >focused wg, be doing this work. we could miss a lot and step on others' >toes. > >randy In principle I agree, but since the toes in question would be in PKIX, I feel comfortable with a more generic version of manifests. Nonetheless, if we pursue this path, I will bring the document to the attention of PKIX and ask that folks review it and comment during IETF LC. Steve From randy@psg.com Sat Nov 21 16:15:50 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8429A3A69FB for ; Sat, 21 Nov 2009 16:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIkiQCBJbg0I for ; Sat, 21 Nov 2009 16:15:49 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 908683A699E for ; Sat, 21 Nov 2009 16:15:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NC07E-000Agh-5K; Sun, 22 Nov 2009 00:15:44 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id E2C9F2C2A68A; Sat, 21 Nov 2009 23:49:31 +0900 (JST) Date: Sat, 21 Nov 2009 23:49:31 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 00:15:50 -0000 >>> I agree that the manifest structure is more general than the RPKI >>> context. >> is that a problem for this wg? i.e. should this, rather narrowly >> focused wg, be doing this work. we could miss a lot and step on >> others' toes. > In principle I agree, but since the toes in question would be in PKIX, I > feel comfortable with a more generic version of manifests. Nonetheless, > if we pursue this path, I will bring the document to the attention of > PKIX and ask that folks review it and comment during IETF LC. let me be less subtle it might be polite to run that plan by at least tim and stefan randy From kent@bbn.com Sun Nov 22 06:12:22 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFB43A6852 for ; Sun, 22 Nov 2009 06:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 PPkFTNZCh97z for ; Sun, 22 Nov 2009 06:12:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9D9033A6820 for ; Sun, 22 Nov 2009 06:12:21 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.3]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NCDAn-0000hH-Ao; Sun, 22 Nov 2009 09:12:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 22 Nov 2009 09:02:44 -0500 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 14:12:22 -0000 At 11:49 PM +0900 11/21/09, Randy Bush wrote: > >>> I agree that the manifest structure is more general than the RPKI >>>> context. >>> is that a problem for this wg? i.e. should this, rather narrowly >>> focused wg, be doing this work. we could miss a lot and step on >>> others' toes. >> In principle I agree, but since the toes in question would be in PKIX, I >> feel comfortable with a more generic version of manifests. Nonetheless, >> if we pursue this path, I will bring the document to the attention of >> PKIX and ask that folks review it and comment during IETF LC. > >let me be less subtle > >it might be polite to run that plan by at least tim and stefan > >randy Thanks for the clarification. Steve From tim@ripe.net Mon Nov 23 00:28:29 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D261D3A68A6 for ; Mon, 23 Nov 2009 00:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4Pe5MoDdz-M for ; Mon, 23 Nov 2009 00:28:28 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 1C36E28C10B for ; Mon, 23 Nov 2009 00:28:28 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NCUHU-0006jc-Qk; Mon, 23 Nov 2009 09:28:20 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id C72442F593; Mon, 23 Nov 2009 09:28:20 +0100 (CET) Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NCUHU-0001eV-Nv; Mon, 23 Nov 2009 09:28:20 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1--662657280 From: Tim Bruijnzeels In-Reply-To: <7B72EF6F-EFE7-48EE-BA73-7AEBAB4C89BA@apnic.net> Date: Mon, 23 Nov 2009 09:28:20 +0100 Message-Id: <9D9A3B23-2CB8-4165-A603-104F58E25340@ripe.net> References: <7B72EF6F-EFE7-48EE-BA73-7AEBAB4C89BA@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1077) X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07195e6814290608e6ac82f6fd20b738a91a Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:28:29 -0000 --Apple-Mail-1--662657280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Nov 21, 2009, at 1:18 AM, Geoff Huston wrote: >=20 > On 21/11/2009, at 8:51 AM, Stephen Kent wrote: >=20 >> At 11:39 AM +1100 11/18/09, Geoff Huston wrote: >>> WG co-chair hat OFF >>>=20 >>> This is a posting made in my role as a document co-author, and not = as a co-chair of the WG >>>=20 >>> In reviewing the manifest document I notice that the document in its = current version defines a manifest as an RPKI construct. I have two = questions about this: >>>=20 >>> 1. Should the manifest document be constrained in this manner as = being exclusively an RPKI construct, or should the reference to = exclusive use by the RPKI be removed such that the manifest is defined = in a manner that is agnostic to the context of the PKI in which the = manifest may be used, so that any CA may use a manifest? >>>=20 >>> 2. In the context of the RPKI should the manifest document used a = SHOULD to specify that the resources in the RPKI EE certificate used to = validate the manifest's signature be specified using the inherit bit = setting of the RFC3779 extensions? >>>=20 >>> Do any of the document's co-authors, or any WG folk, have an opinion = of either or both of these questions that they'd like to share? >>>=20 >>> thanks, >>>=20 >>> Geoff >>>=20 >>> WG co-chair hat OFF >>=20 >> I agree that the manifest structure is more general than the RPKI = context. As one of the developers working on the RPKI solution at RIPE NCC I = agree with this. >>=20 >> However, if we choose to make the manifest document generic, we = probably need another document that profiles it for the RPKI. >>=20 >> Steve >=20 > WG co-chair hat OFF >=20 > This is a posting made in my role as a document co-author, and not as = a co-chair of the WG. >=20 > Thanks for this comment Steve. I am happy to attempt to redraft the = manifest as a more generic document that describes a manifest in terms = of a list of published products of a CA, with a signature that is = verified using an EE certificate that is a subordinate product of that = CA. >=20 > At this stage I'm of the view that the only RPKI-specific profile = would be to say that the RPKI EE cert SHOULD use the inherit bit in the = RFC3779 extension, and this seeems such a small profile component that = it could fit into the res-cert profile draft in its own section. >=20 I agree. In effect this would allow for a more generic use of the = manifests without impacting the rpki structure that was envisioned. As others suggested cooperation with the PKIX wg is probably advised. = But since I have not (yet) been very actively involved in the IETF WGs = and processes I will leave this discussion to the more experienced = people among us. Regards, Tim > regards, >=20 > Geoff >=20 > WG co-chair hat OFF >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr Tim Bruijnzeels Senior Software Developer RIPE NCC tim@ripe.net +31 20 535 4309 --Apple-Mail-1--662657280 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 21/11/2009, = at 8:51 AM, Stephen Kent wrote:

At = 11:39 AM +1100 11/18/09, Geoff Huston wrote:
WG co-chair hat = OFF

This is a posting made in my = role as a document co-author, and not as a co-chair of the = WG

In reviewing the manifest = document I notice that the document in its current version defines a = manifest as an RPKI construct. I have two questions about =  this:

1. Should the manifest document = be constrained in this manner as being exclusively an RPKI construct, or = should the reference to exclusive use by the RPKI be removed such that = the manifest is defined in a manner that is agnostic to the context of = the PKI in which the manifest may be used, so that any CA may use a = manifest?

2. In the context of the RPKI = should the manifest document used a SHOULD to specify that the resources = in the RPKI EE certificate used to validate the manifest's signature be = specified using the inherit bit setting of the RFC3779 = extensions?

Do any of the document's = co-authors, or any WG folk, have an opinion of either or both of these = questions that they'd like to = share?

thanks,

= Geoff

WG co-chair hat = OFF

I agree that = the manifest structure is more general than the RPKI = context.

As = one of the developers working on the RPKI solution at RIPE NCC I agree = with this.



However, if we choose to make the manifest document = generic, we probably need another document that profiles it for the = RPKI.

Steve

WG co-chair hat OFF

This = is a posting made in my role as a document co-author, and not as a = co-chair of the WG.

Thanks for this comment Steve. I am happy to = attempt to redraft the manifest as a more generic document that = describes a manifest in terms of a list of published products of a CA, = with a signature that is verified using an EE certificate that is a = subordinate product of that CA.

At this stage I'm of the view = that the only RPKI-specific profile would be to say that the RPKI EE = cert SHOULD use the inherit bit in the RFC3779 extension, and this = seeems such a small profile component that it could fit into the = res-cert profile draft in its own = section.


I agree. In = effect this would allow for a more generic use of the manifests without = impacting the rpki structure that was = envisioned.

As others suggested cooperation = with the PKIX wg is probably advised. But since I have not (yet) been = very actively involved in the IETF WGs and processes I will leave this = discussion to the more experienced people among = us.

Regards,

Tim
regards,

=   Geoff

WG co-chair hat = OFF



_______________________________________________
sidr= mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr

Tim Bruijnzeels
Senior Software = Developer
RIPE NCC

+31 20 535 = 4309




= --Apple-Mail-1--662657280-- From sra@hactrn.net Mon Nov 23 13:08:12 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0EB3A66B4 for ; Mon, 23 Nov 2009 13:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.907 X-Spam-Level: * X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuksrbd4lRBB for ; Mon, 23 Nov 2009 13:08:12 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id C7A6F3A6A0C for ; Mon, 23 Nov 2009 13:08:11 -0800 (PST) Received: from angband.hactrn.net (c-98-235-6-210.hsd1.pa.comcast.net [98.235.6.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6DD2528449 for ; Mon, 23 Nov 2009 21:08:05 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 9DBA115F0BF for ; Mon, 23 Nov 2009 21:07:57 +0000 (UTC) Date: Mon, 23 Nov 2009 16:07:57 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091123210757.9DBA115F0BF@angband.hactrn.net> Subject: Re: [sidr] Working Group Last Call for draft-ietf-sidr-res-certs-17 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:08:12 -0000 I support this draft. I've read it many times in the past, and have implemented almost all of it (no CRMF), but, as often happens when re-reading an old document, I found a new issue, which could be construed as a nit if the authors agree that my rephrasing is what they meant. Section 3.9.7: In this profile a single reference object to publication location of the immediate superior certificate MUST be used, except in the case where a CA distributes its public key in the form of a "self-signed" certificate, in which case the AIA field SHOULD be omitted. I think we need to change "MUST be used" to "MUST be present". "MUST be used" could be construed as constraining relying party behavior, which would rule out mechanisms such as Steve Kent's algorithm for constructing a local trust anchor. Since the choice of a trust anchor is, ultimately, up to the relying party, not the issuer, I don't think it's reasonable for the profile to constrain the relying party in this way. So it's ok to require the issuer to supply the AIA, but not to require the relying party to use it. From sra@hactrn.net Mon Nov 23 13:26:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050973A68B3 for ; Mon, 23 Nov 2009 13:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.907 X-Spam-Level: * X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VePSefIXIAYi for ; Mon, 23 Nov 2009 13:26:25 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 351E13A66B4 for ; Mon, 23 Nov 2009 13:26:25 -0800 (PST) Received: from angband.hactrn.net (c-98-235-6-210.hsd1.pa.comcast.net [98.235.6.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id E79652844C for ; Mon, 23 Nov 2009 21:26:20 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 95E8F15F0BF for ; Mon, 23 Nov 2009 21:26:02 +0000 (UTC) Date: Mon, 23 Nov 2009 16:26:02 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091123212602.95E8F15F0BF@angband.hactrn.net> Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-roa-format-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:26:26 -0000 I have read (and implemented) this document, and support it going forward. My only comment from this review is that the text "If it is present it MUST be ignored by the relying party" in sections 2.1.6.4.3 and 2.1.6.4.4 is perhaps a bit strong. The text immediately following in both cases is fine, and I believe expresses the real intent here: that relying parties not use these timestamp fields in determining whether a ROA is valid. As stated, however, this could be construed as forbidding an application that uses ROAs from using that field for any purposes whatsoever, which seems excessive. From sra@hactrn.net Mon Nov 23 14:11:22 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F078C3A6A18 for ; Mon, 23 Nov 2009 14:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.184 X-Spam-Level: ** X-Spam-Status: No, score=2.184 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0CdyNg-ujfG for ; Mon, 23 Nov 2009 14:11:21 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 92F133A6A0C for ; Mon, 23 Nov 2009 14:11:21 -0800 (PST) Received: from angband.hactrn.net (c-98-235-6-210.hsd1.pa.comcast.net [98.235.6.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 79C3B2844C for ; Mon, 23 Nov 2009 22:11:16 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 6575615F0BF for ; Mon, 23 Nov 2009 22:07:39 +0000 (UTC) Date: Mon, 23 Nov 2009 17:07:39 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091123220740.6575615F0BF@angband.hactrn.net> Subject: Re: [sidr] Working Group Last Call for draft-ietf-sidr-repos-struct-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 22:11:23 -0000 I have read this document (and implemented something that I think is compatible with it) and support it going forward. From sra@hactrn.net Mon Nov 23 15:26:07 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3223A6919 for ; Mon, 23 Nov 2009 15:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.815 X-Spam-Level: * X-Spam-Status: No, score=1.815 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tvEWqkS5Ggn for ; Mon, 23 Nov 2009 15:26:06 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 79B6A3A68F7 for ; Mon, 23 Nov 2009 15:26:06 -0800 (PST) Received: from angband.hactrn.net (c-98-235-6-210.hsd1.pa.comcast.net [98.235.6.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id D39022844E for ; Mon, 23 Nov 2009 23:26:00 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 3554715F0BF for ; Mon, 23 Nov 2009 23:25:56 +0000 (UTC) Date: Mon, 23 Nov 2009 18:25:56 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091123232557.3554715F0BF@angband.hactrn.net> Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-arch-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 23:26:07 -0000 I have read this draft, believe that (with one exception, below) it's consistent with my implementation, and think it should go forward. The one exception is section 4.3 on access protocol, already noted in WG trac ticket #6. Terry's right here, the draft is wrong, and the authors have already agreed to fix it, so I have no further issue. From sra@hactrn.net Tue Nov 24 12:31:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8053A68B7 for ; Tue, 24 Nov 2009 12:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGiM5H8K87gm for ; Tue, 24 Nov 2009 12:31:19 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 398A53A6878 for ; Tue, 24 Nov 2009 12:31:19 -0800 (PST) Received: from angband.hactrn.net (c-98-235-6-210.hsd1.pa.comcast.net [98.235.6.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 9998A28449 for ; Tue, 24 Nov 2009 20:31:13 +0000 (UTC) Received: from angband.hactrn.net (localhost [IPv6:::1]) by angband.hactrn.net (Postfix) with ESMTP id 81CA715F0BF for ; Tue, 24 Nov 2009 20:31:06 +0000 (UTC) Date: Tue, 24 Nov 2009 15:31:06 -0500 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20091124203106.81CA715F0BF@angband.hactrn.net> Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:31:20 -0000 Speaking as one of Geoff's co-authors, and with no intention of offending anyone: I would be ok with minor changes to the current doc that made it possible for others to reuse this work if they so desire, but I am not all that thrilled by the idea of pushing this work into the PKIX WG as a solution in search of additional problems, and I don't want to do anything to the current spec that would complicate RPKI use of it. I think my last point (not wanting to complicate RPKI use) can be addressed by nailing down the RPKI profile of the mechanism, if we go that way. I am more concerned with why we are attempting to generalize this spec at this point in time: has anybody outside the SIDR WG requested generalization? Who's the customer here, and what are the customer's requirements? Bottom line: I don't want the SIDR work to get bogged down a well-intentioned attempt to save some unspecified party from a problem that party is not aware of having. If there's some trivial change we can make that costs us nothing and makes life easier for hypothetical others fine, but not if it's going to slow us down. From kent@bbn.com Tue Nov 24 13:15:18 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859793A6877 for ; Tue, 24 Nov 2009 13:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 APif1+-pvbtr for ; Tue, 24 Nov 2009 13:15:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A85BC3A68D5 for ; Tue, 24 Nov 2009 13:15:17 -0800 (PST) Received: from dhcp89-089-105.bbn.com ([128.89.89.105]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1ND2J6-0007wO-Ct; Tue, 24 Nov 2009 15:48:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20091124203106.81CA715F0BF@angband.hactrn.net> References: <20091124203106.81CA715F0BF@angband.hactrn.net> Date: Tue, 24 Nov 2009 15:46:25 -0500 To: Rob Austein From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:15:18 -0000 At 3:31 PM -0500 11/24/09, Rob Austein wrote: >Speaking as one of Geoff's co-authors, and with no intention of >offending anyone: I would be ok with minor changes to the current doc >that made it possible for others to reuse this work if they so desire, >but I am not all that thrilled by the idea of pushing this work into >the PKIX WG as a solution in search of additional problems, and I >don't want to do anything to the current spec that would complicate >RPKI use of it. I don't anticipate that we would move the doc to PKIX. I have alerted my co-chair and the cognizant AD of this discussion, and am awaiting responses from them. I too do not want to delay this document in any significant fashion, as a side-effect of making it more generic. Steve From Sandra.Murphy@cobham.com Tue Nov 24 13:21:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E164A3A6917 for ; Tue, 24 Nov 2009 13:21: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 RTpQQoPO6LZn for ; Tue, 24 Nov 2009 13:21:57 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 04B1F3A6908 for ; Tue, 24 Nov 2009 13:21:56 -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 nAOLLm0E031923; Tue, 24 Nov 2009 15:21:48 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAOLLmTP020748; Tue, 24 Nov 2009 15:21:48 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.106]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 16:21:48 -0500 Date: Tue, 24 Nov 2009 16:21:48 -0500 (Eastern Standard Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <20091124203106.81CA715F0BF@angband.hactrn.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 24 Nov 2009 21:21:48.0448 (UTC) FILETIME=[21BD5A00:01CA6D4C] Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:21:58 -0000 On Tue, 24 Nov 2009, Stephen Kent wrote: > At 3:31 PM -0500 11/24/09, Rob Austein wrote: >> Speaking as one of Geoff's co-authors, and with no intention of >> offending anyone: I would be ok with minor changes to the current doc >> that made it possible for others to reuse this work if they so desire, >> but I am not all that thrilled by the idea of pushing this work into >> the PKIX WG as a solution in search of additional problems, and I >> don't want to do anything to the current spec that would complicate >> RPKI use of it. > > I don't anticipate that we would move the doc to PKIX. I have alerted my > co-chair and the cognizant AD of this discussion, and am awaiting responses > from them. I too do not want to delay this document in any significant > fashion, > as a side-effect of making it more generic. Is there any reason why a more general/generic document could not be produced later, with back references to the existing document as a profile? That presumes of course that the generalization maintains backward compatibility to the existing document. I also am reluctant to tread water waiting on this. --Sandy > > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From terry.manderson@icann.org Tue Nov 24 16:29:41 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13533A67DF for ; Tue, 24 Nov 2009 16:29:41 -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 DKQMUjoOEVgG for ; Tue, 24 Nov 2009 16:29:41 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 487533A67BD for ; Tue, 24 Nov 2009 16:29:41 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 24 Nov 2009 16:29:37 -0800 From: Terry Manderson To: Rob Austein , "sidr@ietf.org" Date: Tue, 24 Nov 2009 16:29:34 -0800 Thread-Topic: [sidr] Question about manifest document Thread-Index: AcptRSEGVUmdtAv+TPC6nXbMylJqBAAITuBm Message-ID: In-Reply-To: <20091124203106.81CA715F0BF@angband.hactrn.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:29:42 -0000 On 25/11/09 6:31 AM, "Rob Austein" wrote: > Speaking as one of Geoff's co-authors, and with no intention of > offending anyone: I would be ok with minor changes to the current doc > that made it possible for others to reuse this work if they so desire, > but I am not all that thrilled by the idea of pushing this work into > the PKIX WG as a solution in search of additional problems, and I > don't want to do anything to the current spec that would complicate > RPKI use of it. I'm in agreement with Rob on this. Best to not go looking for more problems that the manifest _might_ fix in the future. If such problems arise, then the PKIX chairs are clearly aware of this work (noting Steve's response) and can advise accordingly. Cheers Terry From tim@ripe.net Wed Nov 25 00:55:58 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909D93A6867 for ; Wed, 25 Nov 2009 00:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2aZMyWu1v7h for ; Wed, 25 Nov 2009 00:55:57 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 7E8943A682B for ; Wed, 25 Nov 2009 00:55:57 -0800 (PST) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NDDf1-00077m-Mb; Wed, 25 Nov 2009 09:55:39 +0100 Received: from ayeaye.ripe.net (ayeaye.ripe.net [193.0.1.103]) by herring.ripe.net (Postfix) with ESMTP id A742B2F583; Wed, 25 Nov 2009 09:55:39 +0100 (CET) Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1NDDf1-0008QW-KQ; Wed, 25 Nov 2009 09:55:39 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Wed, 25 Nov 2009 09:55:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E62B2DF-E1B3-4776-AADB-9E3B4BCBE990@ripe.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1077) X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719f23639436417ac2b7d5ed0149dab41a0 Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:55:58 -0000 Hi, On Nov 25, 2009, at 1:29 AM, Terry Manderson wrote: >=20 >=20 > On 25/11/09 6:31 AM, "Rob Austein" wrote: >=20 >> Speaking as one of Geoff's co-authors, and with no intention of >> offending anyone: I would be ok with minor changes to the current doc >> that made it possible for others to reuse this work if they so = desire, >> but I am not all that thrilled by the idea of pushing this work into >> the PKIX WG as a solution in search of additional problems, and I >> don't want to do anything to the current spec that would complicate >> RPKI use of it. >=20 > I'm in agreement with Rob on this. Best to not go looking for more = problems > that the manifest _might_ fix in the future. >=20 To be specific I see a potential use of these manifests without the = RFC3779 extension in the context of the compound trust anchor as = described in the draft-ietf-sidr-ta. This would allow the 'eta' to = publish a manifest for the rtacms object(s). However, I received signals that having this manifest there in the first = place may not be desirable and I do agree that delays to get this = document finalised should be avoided. Cheers, Tim > If such problems arise, then the PKIX chairs are clearly aware of this = work > (noting Steve's response) and can advise accordingly. >=20 > Cheers > Terry >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr Tim Bruijnzeels Senior Software Developer RIPE NCC tim@ripe.net +31 20 535 4309 From weiler@watson.org Wed Nov 25 03:25:54 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C7B28C213 for ; Wed, 25 Nov 2009 03:25:54 -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 QRX0kQtuyvuj for ; Wed, 25 Nov 2009 03:25:53 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 732933A69BF for ; Wed, 25 Nov 2009 03:25:53 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nAPBPmEq082942 for ; Wed, 25 Nov 2009 06:25:48 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nAPBPlmS082938 for ; Wed, 25 Nov 2009 06:25:47 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 25 Nov 2009 06:25:47 -0500 (EST) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> Message-ID: References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 25 Nov 2009 06:25:48 -0500 (EST) Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-arch-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:25:54 -0000 First, many thanks to the editors of the architecture document. For as dense as it is, it's readable. There are a couple of "gotta-fix" nits, as well as a broader concern that lead me to say "not yet" to this doc. The fix-it items: Section 4.3 (access protocols): the rsync item, as noted by others. 4.3 also uses 2119 language to specify requirements for (current and future) access protocols. I'm not convinced that language is appropriate for these requirements. 5 (Manifests) allows an EE cert to sign multiple manifests. That seems inconsistent with section 2.3 re: one-to-one correspondence. The broader concern: I continue to lack confidence that our validation algorithm is complete, particularly when we look at incremental deployment. That leads me to wonder whether changes to the validation model will lead us to changes in the data. There's a reason the architecture doc has normative references to so many other active sidr docs, including ones that aren't yet to the point of WGLC, and I'm uneasy about pushing this doc out until I'm more confident about the validation model. This doc doesn't talk in depth about incremental deployment. Instead, it uses 2119 MUSTs to describe a full-deployment world (e.g., in 7.2.3, "A holder of a portable IP address space allocation MUST authorize one or more ASes to originate routes to these prefixes.") I'd prefer to see this doc acknowledge the existence of partial deployment and explain how it will work. (Will it? If so, how?) For example: the document never clearly states what (if anything) signals that the set of ROAs for a given address block is complete. Maybe we need to say "we're not yet defining a signal for 'this is the complete set of ROAs'; that's be in a different doc", but it's a glaring omission. This document also asks IANA to issue RPKI certs. I'm leery of asking them to do that when I still have doubts about the completeness of the architecture. Should we be pushing out the doc calling on IANA to deploy when the other bits aren't done yet? And the little stuff: 3.2 "There is no independent method of invoking a ROA." s/invoking/revoking/, perhaps? Section 7.1: "However, if the certificates for these allocations contain different validity intervals, creating a certificate that combines them might create problems, and thus is NOT RECOMMENDED." Doesn't this problem arise when the underlying validity (e.g. the validity of the assignment/allocation/etc.) intervals vary, rather than the cert validity intervals? Perhaps this could be clearer. 7.2 "Furthermore, a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation." Is this reflected in the validation drafts? It should be likely be repeated in section 3 or 4 of the ROA format doc. -- Sam From weiler@watson.org Wed Nov 25 03:26:00 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AA328C21D for ; Wed, 25 Nov 2009 03:26:00 -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 TEF0l0JzRPyb for ; Wed, 25 Nov 2009 03:26:00 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id F33C528C21C for ; Wed, 25 Nov 2009 03:25:59 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nAPBPsoA082963 for ; Wed, 25 Nov 2009 06:25:54 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nAPBPsOL082960 for ; Wed, 25 Nov 2009 06:25:54 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 25 Nov 2009 06:25:54 -0500 (EST) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 25 Nov 2009 06:25:54 -0500 (EST) Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-roa-format-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:26:00 -0000 I have reviewed the ROA format draft. In, general, I'm fine with sending it to the IESG now. Thanks again to the editors for putting together a readable doc. As with the architecture document, I have some reservations about publishing the data format documents before the validation algorithm is solid, but I suspect this doc won't need to change. It might be worthwhile to repeat in section 3 (validation) the requirement from section 7.2 of the architecture draft that "...a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation." -- Sam From kent@bbn.com Wed Nov 25 06:18:31 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AA03A68D6 for ; Wed, 25 Nov 2009 06:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 M-mhK9-rvBDk for ; Wed, 25 Nov 2009 06:18:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2F3BE3A68AB for ; Wed, 25 Nov 2009 06:18:30 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NDIhM-0007Yd-AQ; Wed, 25 Nov 2009 09:18:24 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20091124203106.81CA715F0BF@angband.hactrn.net> Date: Wed, 25 Nov 2009 09:18:10 -0500 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:18:31 -0000 Sandy, I have already back from my PKIX co-chair, who said: >Steve, > >I assume this was addressed primarily to Tim, but for the record, I have no >objections to this. > >/Stefan So I don't believe that we will incur any significant delays from PKIX (or the cognizant SEC AD) if we choose to publish a more generic version of the manifest doc. That said, I am amenable to either approach to publication. Steve From kent@bbn.com Wed Nov 25 06:18:32 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C013A28C232 for ; Wed, 25 Nov 2009 06:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 9IZ5ZtUwjOHr for ; Wed, 25 Nov 2009 06:18:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D77453A68AB for ; Wed, 25 Nov 2009 06:18:31 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NDIhN-0007Yd-Ai; Wed, 25 Nov 2009 09:18:26 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20091124203106.81CA715F0BF@angband.hactrn.net> Date: Wed, 25 Nov 2009 09:18:10 -0500 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:18:32 -0000 At 4:21 PM -0500 11/24/09, Sandra Murphy wrote: >>... > > >Is there any reason why a more general/generic document could not be >produced later, with back references to the existing document as a >profile? One might try to do that, although it would be procedurally "backwards" :-). > >That presumes of course that the generalization maintains backward >compatibility to the existing document. Profiles are more specific, so the more general manifest would be a superset of the RPKI manifest. Not sure if that would qualify as "backwards compatible" or not. steve From Sandra.Murphy@cobham.com Wed Nov 25 07:31:40 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5094B28C260 for ; Wed, 25 Nov 2009 07:31:40 -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 zyYtt-UyoM+I for ; Wed, 25 Nov 2009 07:31:39 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5683528C256 for ; Wed, 25 Nov 2009 07:31:39 -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 nAPFVUEp007511; Wed, 25 Nov 2009 09:31:30 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAPFVUb2014878; Wed, 25 Nov 2009 09:31:30 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.106]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 10:31:30 -0500 Date: Wed, 25 Nov 2009 10:31:30 -0500 (Eastern Standard Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <20091124203106.81CA715F0BF@angband.hactrn.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Nov 2009 15:31:30.0474 (UTC) FILETIME=[5C76C8A0:01CA6DE4] Cc: sidr@ietf.org Subject: Re: [sidr] Question about manifest document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:31:40 -0000 On Wed, 25 Nov 2009, Stephen Kent wrote: > At 4:21 PM -0500 11/24/09, Sandra Murphy wrote: >>> ... >> >> >> Is there any reason why a more general/generic document could not be >> produced later, with back references to the existing document as a profile? > > One might try to do that, although it would be procedurally "backwards" :-). I recognize that. Perhaps we are not so interested in procedural purity than in procedural progress. > >> >> That presumes of course that the generalization maintains backward >> compatibility to the existing document. > > > Profiles are more specific, so the more general manifest would be a superset > of the RPKI manifest. Not sure if that would qualify as "backwards > compatible" or not. I was projecting in the future that work on a more general manifest might end up not quite being a superset of the current manifest. WG are so unpredictable. Hence my statement that the development of the general manifest might not retain compatibility with the current document. Hypothesizing only. --Sandy > > steve > From weiler@watson.org Wed Nov 25 12:07:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7EA3A6AB4 for ; Wed, 25 Nov 2009 12:07: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=[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 NPGHMPXp-5O9 for ; Wed, 25 Nov 2009 12:07:25 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 226C03A6B43 for ; Wed, 25 Nov 2009 12:07:06 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nAPK71en054021 for ; Wed, 25 Nov 2009 15:07:01 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nAPK71pi054017 for ; Wed, 25 Nov 2009 15:07:01 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 25 Nov 2009 15:07:01 -0500 (EST) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 25 Nov 2009 15:07:01 -0500 (EST) Subject: Re: [sidr] Working Group Last Call for etf-sidr-repos-struct-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 20:07:26 -0000 As best I can tell, the technical substance of sidr-repos-struct-03 is in fine shape. That said, I found the document difficult to review, largely due to the style of its writing. While I recognize that this may be merely a matter of stylistic preference, I find the writing unnecessarily verbose and unapproachable. I notice that the only two other WGLC reviews of this doc came from native English speakers, one of whom has been deeply involved in the work for years. I think the doc has not gotten adequate review, I think that is in large part because of the writing. I think this document would benefit greatly from an editorial pass, probably from a different editor. Assuming someone can be found to do that, I support delaying the publication in the interest of producing a more readable document. And, as I noted in my WGLC review of the architecture draft, I have some reservations about pushing these docs out without having the validation algorithm nailed down (including the handling of incremental deployment). In the case of this document, noting that it has normative references to the architecture and manifests docs, which are more likely to see changes from changing the validation scheme, I don't see any harm in sending it forward. Specific suggestions Danny McPherson's comments on ths draft from 3 December 2008 don't appear to have been incorporated nor responded to on the list. (e.g. "complete set" is still a strange phrasing, and the spelling nits haven't been fixed) Rsync is not mentioned in the intro. Instead of just referring to "publication points", adding the concreteness of "rsync" at that stage would help make the doc clearer. Section 1: "A Resource Certificate describes an action by an Issuer that binds a list of IP address blocks and AS numbers to the Subject of a certificate, identified by the unique association of the Subject's private key with the public key contained in the Resource Certificate." "describes an action"? Surely there's a better way to say that. I'm not sure that Section 2.2 paragraph on naming certificates is consistent with section 4's guidance on persistent naming. Which may be more about how hard it was to understand section 2.2 than about any real differences. Nits The rsync reference appears to be truncated. Spelling: s/performss/performs/ s/Becuase/Because/ s/Whn/When/ s/traveral/traversal/ (and there are surely others, including some that Danny pointed out) -- Sam From trac@tools.ietf.org Thu Nov 26 14:48:16 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DCF3A687E for ; Thu, 26 Nov 2009 14:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpDQJkxZu9S7 for ; Thu, 26 Nov 2009 14:48:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id B1BD73A67C0 for ; Thu, 26 Nov 2009 14:48:15 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NDn8E-0006Ry-DK; Thu, 26 Nov 2009 14:48:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Thu, 26 Nov 2009 22:48:10 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/1#comment:2 Message-ID: <061.00655337b6f34233eefabe52117b86cb@tools.ietf.org> References: <052.0ec5e3e54b1c816be6856d2e6ce4f2fd@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <052.0ec5e3e54b1c816be6856d2e6ce4f2fd@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #1: Nit Report X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 22:48:16 -0000 #1: Nit Report -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: gih@… Type: defect | Status: closed Priority: minor | Milestone: Component: rpki-manifests | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by gih@…): * status: assigned => closed * resolution: => fixed Comment: revision has been made to the forthcoming -06 version of this draft. -- Ticket URL: sidr From trac@tools.ietf.org Thu Nov 26 19:41:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEDA3A67EE for ; Thu, 26 Nov 2009 19:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEMyDCfwZanH for ; Thu, 26 Nov 2009 19:41:04 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id E37C63A63D3 for ; Thu, 26 Nov 2009 19:41:04 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NDrhb-00026Q-ME; Thu, 26 Nov 2009 19:40:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Fri, 27 Nov 2009 03:40:59 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/11 Message-ID: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 03:41:05 -0000 #11: Nit Report - provisioning protocol -----------------------------------+---------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: medium | Milestone: Component: rescerts-provisioning | Version: Severity: In WG Last Call | Keywords: -----------------------------------+---------------------------------------- Oppose.. Firstly, my initial observation is that the 'XML in ANS1 in CMS (signed)' transported in mutually validated and authenticated(*) HTTPS/TLS sessions appears somewhat weighty to cover MiTM/Repla given other parts of the entire RPKI system don't seem to have been given the same attention and remain untrusted? (*) you mean cross-certified? or some other way of mutually authenticated? Secondly, since this uses a PKI of some description, where is the description of the PKI (and CP?) for the signing of the CMS blobs and the PKI (and CP) for the TLS sessions. Are they the same? not the same? RPKI certs used? etc. Are there multiple fully interoperable server and client codebases based on this? Why I ask is the XML and the basic operations (list, issue, revoke) is simple enough - the killer space would be getting the multiple signing events right. ie which cert is used for the CMS, which is used for the TLS.. and the ASN.1/CMS combo in order. lastly, the draft suggests "the server MUST NOT accept a client's request unless it has generated and sent a response to the client's previous request" - it appeard the _assumption_ made is that the client deals with the resources of only one entity. What if it deals with more? What if the ISP is representative of multiple organisations and wishes to do multiple updates in parallel? On to my nits: section 3.2: Please specify here the version of XML schema that this draft in its common message format uses (not just describes) and the section (section 4) that contains the xml schema. I think that it needs to be done prior to the introduction of the template and template values. http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a pretty 404, but a 404 nevertheless) So the namespace is invalid. I think I would like to see a summary table of all of the HTTP response codes used by this protocol. Section 3.5.1 Looks like a wayward "]": ski="encoded hash of the subject public key]" /> Cheers Terry -- Ticket URL: sidr From trac@tools.ietf.org Thu Nov 26 19:42:37 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE553A67EE for ; Thu, 26 Nov 2009 19:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMWyyUDYhJ2h for ; Thu, 26 Nov 2009 19:42:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 8B8CD3A67C1 for ; Thu, 26 Nov 2009 19:42:36 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NDrj5-00052e-HI; Thu, 26 Nov 2009 19:42:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Fri, 27 Nov 2009 03:42:31 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/11#comment:1 Message-ID: <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> References: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 03:42:37 -0000 #11: Nit Report - provisioning protocol -----------------------------------+---------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: medium | Milestone: Component: rescerts-provisioning | Version: Severity: In WG Last Call | Keywords: -----------------------------------+---------------------------------------- Comment(by gih@…): The combination of TLS and CMS was the result of advice the design group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy and I asked them to review this protocol, back in 2007. The two mechanisms serve different purposes. We use CMS for authentication and authorization (is the entity requesting this action authorized to do so? etc). It's also intended to allow for audit: if one is paranoid, one can archive a copy of every CMS message and use it (along with archived PKI material) to prove at some later date that the action was properly authorized. So I view CMS as the main security mechanism here, and the one that's most closely aligned with the underlying semantics. TLS is present mostly to protect against replay attacks and other naughtiness. Our advisors saw our initial attempts to include replay protection in the CMS-signed XML messages and advised us to use existing technology (ie, TLS) instead, which makes some sense. TLS also provides privacy (which it's not clear we need), and helps to limit denial of service attacks to known entities. At this point, having written my own HTTPS implementation and seeing how weak (read: effectively nonexistant) the concept of a session is in HTTPS, I'm not convinced that TLS is providing all that much in the way of useful replay protection. At this point, though, we do have multiple interoperable implementations of this protocol using TLS, so unless it's actively harmful I'd just as soon leave it alone for now. FWIW, though, at least in my implementation, all the AAA logic is tied to CMS, not TLS. The PKI used for this (both CMS and TLS) is not the RPKI, it's a separate PKI (which the design group has been calling the "BPKI", because it mirrors the business relationships between certificate-generating entities). In the abstract, the BPKI can be anything that both parties to a particular conversation are willing to use, as this is only used in pairwise conversations and doesn't transit to third parties. The main thing is that the parent in a parent-child relationship gets to dictate the BPKI model to be used: this pretty much falls out of the hierarchical nature of the system. So my implementation, at least, has a particular model that I use when I'm the parent, and is (I hope) flexible enough to handle whatever model my parent might be using when I'm the child. I can go into more detail on the model I'm using, but I'm not sure that the WG really needs to sign off on that level of detail. The protocol nesting is tedious but straightforward: IP(TCP(TLS(HTTP(CMS(XML(up-down)))))) As far as different security models between this and the rest of the RPKI system: the difference is less extreme than it might at first appear. Other than the TLS wrapper discussed above, everything is object security, using either CMS or X.509-derived objects which were signed to begin with. Hope this helps. --Rob -- Ticket URL: sidr From randy@psg.com Thu Nov 26 20:34:41 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3183A6891 for ; Thu, 26 Nov 2009 20:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, J_CHICKENPOX_72=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 7xgOVOLJQsYe for ; Thu, 26 Nov 2009 20:34:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 3984A3A67BD for ; Thu, 26 Nov 2009 20:34:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDsXQ-000OSK-Bm for sidr@ietf.org; Fri, 27 Nov 2009 04:34:32 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id D46C52C4B552 for ; Fri, 27 Nov 2009 13:34:31 +0900 (JST) Date: Fri, 27 Nov 2009 13:34:31 +0900 Message-ID: From: Randy Bush To: sidr@ietf.org In-Reply-To: <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> References: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 04:34:41 -0000 > Comment(by gih@=E2=80=A6): >=20 > The combination of TLS and CMS was the result of advice the design > group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy > and I asked them to review this protocol, back in 2007. The two > mechanisms serve different purposes. and mis-attributed copies of email we have already read helps the technical work how? randy From gih@apnic.net Thu Nov 26 21:25:48 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985E43A6778 for ; Thu, 26 Nov 2009 21:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAzaOQRVrQcr for ; Thu, 26 Nov 2009 21:25:48 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id E8EB93A63D3 for ; Thu, 26 Nov 2009 21:25:46 -0800 (PST) Received: from [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a] (unknown [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 94CB4D5911 for ; Fri, 27 Nov 2009 15:36:50 +1000 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1077) From: Geoff Huston In-Reply-To: Date: Fri, 27 Nov 2009 16:25:38 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <695F3A87-E833-46E2-B233-8B4F9F2F6F79@apnic.net> References: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 05:25:48 -0000 On 27/11/2009, at 3:34 PM, Randy Bush wrote: >> Comment(by gih@=85): >>=20 >> The combination of TLS and CMS was the result of advice the design >> group got from Steve Bellovin, Steve Kent, and Russ Housley when = Randy >> and I asked them to review this protocol, back in 2007. The two >> mechanisms serve different purposes. >=20 > and mis-attributed copies of email we have already read helps the > technical work how? I'm sorry if this caused any confusion to WG members. I copied a message = in to the issues tracker to ensure that it was captured in the tracker, = and the notification of the action is sent to the WG mailer. There may = be more tracker notices as I work through the blacklog of WG last call = comments that have been made on the mailing list and attempt to capture = them in the tracker. Geoff=20 Not sure it this is a WG co-chair or not posting. Either way is fine = by me. From randy@psg.com Thu Nov 26 23:20:31 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC96A3A6853 for ; Thu, 26 Nov 2009 23:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 8fXiLQ60WXwe for ; Thu, 26 Nov 2009 23:20:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id A69333A67F4 for ; Thu, 26 Nov 2009 23:20:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDv7t-000OoO-TR; Fri, 27 Nov 2009 07:20:22 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 632162C4BCD9; Fri, 27 Nov 2009 16:20:21 +0900 (JST) Date: Fri, 27 Nov 2009 16:20:21 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <695F3A87-E833-46E2-B233-8B4F9F2F6F79@apnic.net> References: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> <695F3A87-E833-46E2-B233-8B4F9F2F6F79@apnic.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 07:20:31 -0000 >> and mis-attributed copies of email we have already read helps the >> technical work how? > I'm sorry if this caused any confusion to WG members. I copied a > message in to the issues tracker to ensure that it was captured in the > tracker, and the notification of the action is sent to the WG > mailer. There may be more tracker notices as I work through the > blacklog of WG last call comments that have been made on the mailing > list and attempt to capture them in the tracker. before i put this tracker thing in my .procmailrc, where's the win? the mailing list archive is broken? randy From gih@apnic.net Fri Nov 27 01:13:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80643A6783 for ; Fri, 27 Nov 2009 01:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il-67udKqzZ0 for ; Fri, 27 Nov 2009 01:13:19 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 9E3783A677D for ; Fri, 27 Nov 2009 01:13:15 -0800 (PST) Received: from [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a] (unknown [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 1C653D590F for ; Fri, 27 Nov 2009 19:24:20 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Geoff Huston In-Reply-To: Date: Fri, 27 Nov 2009 20:13:07 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> <695F3A87-E833-46E2-B233-8B4F9F2F6F79@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 09:13:26 -0000 On 27/11/2009, at 6:20 PM, Randy Bush wrote: >>> and mis-attributed copies of email we have already read helps the >>> technical work how? >> I'm sorry if this caused any confusion to WG members. I copied a >> message in to the issues tracker to ensure that it was captured in the >> tracker, and the notification of the action is sent to the WG >> mailer. There may be more tracker notices as I work through the >> blacklog of WG last call comments that have been made on the mailing >> list and attempt to capture them in the tracker. > > before i put this tracker thing in my .procmailrc, where's the win? the > mailing list archive is broken? > The issue tracker was set up in response to requests on the WG mailer: http://www.ietf.org/mail-archive/web/sidr/current/msg01075.html http://www.ietf.org/mail-archive/web/sidr/current/msg01076.html http://www.ietf.org/mail-archive/web/sidr/current/msg01103.html I understand that Sandy requested the tools team to set it up. Geoff WG co-chair hat ON From randy@psg.com Fri Nov 27 02:14:26 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AD53A67EC for ; Fri, 27 Nov 2009 02:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 n2-vHXwt57-r for ; Fri, 27 Nov 2009 02:14:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 1043C3A6783 for ; Fri, 27 Nov 2009 02:14:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NDxqC-000PgH-7Z; Fri, 27 Nov 2009 10:14:16 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id B1FAD2C4D0EB; Fri, 27 Nov 2009 19:14:15 +0900 (JST) Date: Fri, 27 Nov 2009 19:14:15 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: References: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> <695F3A87-E833-46E2-B233-8B4F9F2F6F79@apnic.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 10:14:26 -0000 >> before i put this tracker thing in my .procmailrc, where's the win? the >> mailing list archive is broken? > The issue tracker was set up in response to requests on the WG mailer: now that we have assigned the blame (and my memory is not that sandy was the one who pushed it), can we answer my question? where is the win in repeating emails already in the archive? actually, no need. i have procmailed it. life is simple. randy From Sandra.Murphy@cobham.com Fri Nov 27 06:51:25 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3DF3A6A5E for ; Fri, 27 Nov 2009 06:51: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=[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 0+1dh5lBsZJN for ; Fri, 27 Nov 2009 06:51:24 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B50563A6A4A for ; Fri, 27 Nov 2009 06:51: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 nAREp6kK022508; Fri, 27 Nov 2009 08:51:07 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nAREp3S6001116; Fri, 27 Nov 2009 08:51:06 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 09:51:01 -0500 Date: Fri, 27 Nov 2009 09:50:58 -0500 (Eastern Standard Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <052.e19551270069ce47e815a6afc48b906c@tools.ietf.org> <061.2791458f78f5858183f7313a454ae6fe@tools.ietf.org> <695F3A87-E833-46E2-B233-8B4F9F2F6F79@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Nov 2009 14:51:02.0107 (UTC) FILETIME=[09DEE2B0:01CA6F71] Cc: sidr@ietf.org Subject: Re: [sidr] #11: Nit Report - provisioning protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 14:51:25 -0000 On Fri, 27 Nov 2009, Randy Bush wrote: >>> before i put this tracker thing in my .procmailrc, where's the win? the >>> mailing list archive is broken? >> The issue tracker was set up in response to requests on the WG mailer: > > now that we have assigned the blame (and my memory is not that sandy was > the one who pushed it), can we answer my question? where is the win in > repeating emails already in the archive? Sandy did not "push" it, Sany merely responded to a request from the wg to enable access to the tools team's issue tracker service. There are wg who have found the issue tracking to be useful. I've no experience myself, so have no opinion for or against. Issue tracking is a way to ensure that comments raised on the list are addressed in new versions or remain open. The post to the wg mailing list of each new issue registered is an automatic part of the issue tracking service (I believe). Issues do not need to be raised on the mailing list to be entered into the tracker, so the notification to the list is not necessarily redundant. --Sandy > > actually, no need. i have procmailed it. life is simple. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From trac@tools.ietf.org Sun Nov 29 12:45:41 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECD83A69D5 for ; Sun, 29 Nov 2009 12:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFl8Cw9OCKKm for ; Sun, 29 Nov 2009 12:45:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id B67C13A69D0 for ; Sun, 29 Nov 2009 12:45:40 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NEqeE-0003GV-BF; Sun, 29 Nov 2009 12:45:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Sun, 29 Nov 2009 20:45:34 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/12 Message-ID: <052.c0e926ec1d6c73a46354af50593a3faf@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #12: Comment X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 20:45:41 -0000 #12: Comment -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: trivial | Milestone: Component: roa-format | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Sam Weiler reported: It might be worthwhile to repeat in section 3 (validation) the requirement from section 7.2 of the architecture draft that "...a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation." -- Ticket URL: sidr From trac@tools.ietf.org Sun Nov 29 12:47:07 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D0428C0CE for ; Sun, 29 Nov 2009 12:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmZZwE7M+YyA for ; Sun, 29 Nov 2009 12:47:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 9CA513A69C6 for ; Sun, 29 Nov 2009 12:47:06 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NEqfb-0004O3-Sj; Sun, 29 Nov 2009 12:46:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Sun, 29 Nov 2009 20:46:59 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/13 Message-ID: <052.4eedd1afd1834f676527074fa485e362@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #13: Nit Report - ROA Format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 20:47:07 -0000 #13: Nit Report - ROA Format -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: roa-format | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Rob Austein reported: My only comment from this review is that the text "If it is present it MUST be ignored by the relying party" in sections 2.1.6.4.3 and 2.1.6.4.4 is perhaps a bit strong. The text immediately following in both cases is fine, and I believe expresses the real intent here: that relying parties not use these timestamp fields in determining whether a ROA is valid. As stated, however, this could be construed as forbidding an application that uses ROAs from using that field for any purposes whatsoever, which seems excessive. -- Ticket URL: sidr From trac@tools.ietf.org Sun Nov 29 12:51:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6784128C0CF for ; Sun, 29 Nov 2009 12:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8IZ8LlG7sOO for ; Sun, 29 Nov 2009 12:51:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 7D8963A6842 for ; Sun, 29 Nov 2009 12:51:05 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NEqjT-00015R-7b; Sun, 29 Nov 2009 12:50:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Sun, 29 Nov 2009 20:50:59 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/4#comment:1 Message-ID: <061.427643ea11ff127907a77740e21fe84c@tools.ietf.org> References: <052.b0834831a1a149b987cdbc3904e5b82d@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <052.b0834831a1a149b987cdbc3904e5b82d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #4: Nit Report - ROA Format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 20:51:06 -0000 #4: Nit Report - ROA Format -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: roa-format | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Comment(by gih@…): Matt Lepinski has said on the mailing list: My interpretation of your comment is that you would like to see a prescribed (or recommended) order for the checks performed in ROA validation. I am reluctant to put in such a prescribed ordering in this document for two reasons: (1) It doesn't affect ROA semantics or the interoperation of relying party software with ROA producing software; (2) I don't think there is an obviously correct order (in particular, there exist multiple relying party implementations today and I do not believe that they all perform the checks in the same order). With regards to number (2) above, to minimize the time to process a set of ROAs one must consider both the probability that a check succeeds (in general, checks that are likely to fail should be performed sooner) and the cost of performing a given check at a given point in the processing (in general, inexpensive checks should be performed before expensive ones). The former probability depends on the population of invalid ROAs (e.g., what will be the greatest source of invalid ROAs in the system? ... perhaps expired/revoked end-entity certificates?) The latter cost is highly implementation dependent (e.g., the cost to validate the end-entity certificate will greatly depend on the data structures that are used to store and process certificates). In any case, if the working group feels that there is a clear recommended processing order that we can provide in Section 3 that will increase the likelihood the implementors produce efficient software, then please send some text and I'd be happy to insert it. -- Ticket URL: sidr From trac@tools.ietf.org Sun Nov 29 12:53:13 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9373A69D8 for ; Sun, 29 Nov 2009 12:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UESEeN6KPPPS for ; Sun, 29 Nov 2009 12:53:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 0812A3A69A5 for ; Sun, 29 Nov 2009 12:53:13 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NEqlW-0004VQ-PW; Sun, 29 Nov 2009 12:53:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Sun, 29 Nov 2009 20:53:06 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/4#comment:2 Message-ID: <061.293e73c70469cbeeb31aac6cf6a5a82d@tools.ietf.org> References: <052.b0834831a1a149b987cdbc3904e5b82d@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <052.b0834831a1a149b987cdbc3904e5b82d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: Re: [sidr] #4: Nit Report - ROA Format X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 20:53:13 -0000 #4: Nit Report - ROA Format -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: enhancement | Status: closed Priority: trivial | Milestone: Component: roa-format | Version: Severity: In WG Last Call | Resolution: wontfix Keywords: | -----------------------------+---------------------------------------------- Changes (by gih@…): * status: new => closed * resolution: => wontfix Comment: Terry has responded - In hindsight I think that any recommendations of ordering should exist in some other document (akin to the one you alluded to in the thread on sidr-arch-09 refresh cycle) which covers more operational aspects. -- Ticket URL: sidr From gih@apnic.net Sun Nov 29 13:03:31 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB413A69DA for ; Sun, 29 Nov 2009 13:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.148 X-Spam-Level: *** X-Spam-Status: No, score=3.148 tagged_above=-999 required=5 tests=[AWL=-5.598, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr+ZLo331SYN for ; Sun, 29 Nov 2009 13:03:25 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 9216B3A681F for ; Sun, 29 Nov 2009 13:03:24 -0800 (PST) Received: from cpe-58-170-59-21.lns2.woo.bigpond.net.au (CPE-58-170-59-21.lns2.woo.bigpond.net.au [58.170.59.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A1360D58CE; Mon, 30 Nov 2009 07:14:42 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 30 Nov 2009 08:03:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Cc: dkong@bbn.com, skent@bbn.com Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-roa-format-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 21:03:31 -0000 WG Co-Chair hat ON I have seen three comments on this draft in response to this WG last = call - which is perhaps on the very lower bound of what could be = considered an acceptable demonstration of WG consensus with the = document. There have been positive responses in favour of moving this document = forward from Terry Manderson, Sam Weiler and Rob Austein. The review comments received have been entered into the tracker as = tickets #4, #12, and #13.=20 It appears ticket #4 has resolved without requiring a change to the = document, but the comments in tickets #12 and #13 (those made by Sam and = Rob) are outstanding. I would like to request the document's authors to respond to these = comments, either in the tracker on on the mailing list, and provide an = indication whether a further revision of the document is considered = necessary to address these review comments. It appears appropriate to = review the WG consensus position following the authors' response to = these two outstanding review comments. Also, I'd like to remind the authors of the previous request for an = interoperability report. thanks Geoff WG Co-Chair hat ON On 28/10/2009, at 1:48 PM, Geoff Huston wrote: > The WG chairs have received a Working Group Last Call request from the = authors of draft-ietf-sidr-roa-format-06.txt. >=20 > The document (and the draft history) is at = http://tools.ietf.org/html/draft-ietf-sidr-roa-format-06 >=20 > The Last Call will end as of the close of business on Monday 23rd = November - this is a longer period than a conventional 2 week last call = period in order to include the forthcoming SIDR WG meeting at IETF 76. >=20 > The intended status of this document is proposed standard. >=20 > As usual, please address all comments to the WG mailing list, and = please be clear in your comments to this last call if you are supporting = the document's submission to the IESG or if you are opposed, or if you = are not expressing a view either way. As there are a number of documents = that are being last-called at this point in time it would be appreciated = if responses could clearly identify which document is being referred to. >=20 > Also with this note I would like to request the document's authors to = prepare an interoperability report. >=20 > Thanks, >=20 > Geoff >=20 > WG Co-CHair hat ON >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From trac@tools.ietf.org Sun Nov 29 13:49:43 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9219F3A68AF for ; Sun, 29 Nov 2009 13:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJEBTpAAv4zu for ; Sun, 29 Nov 2009 13:49:42 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id B3BDC3A635F for ; Sun, 29 Nov 2009 13:49:42 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NEreB-0004a5-IM; Sun, 29 Nov 2009 13:49:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Sun, 29 Nov 2009 21:49:35 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/14 Message-ID: <052.73a5d24491bf1c029291209fd86b270c@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #14: Nit Report - architecture document X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 21:49:43 -0000 #14: Nit Report - architecture document -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Sam Weiler has noted Section 4.3 (access protocols): the rsync item, as noted by others. 4.3 also uses 2119 language to specify requirements for (current and future) access protocols. I'm not convinced that language is appropriate for these requirements. 5 (Manifests) allows an EE cert to sign multiple manifests. That seems inconsistent with section 2.3 re: one-to-one correspondence. 3.2 "There is no independent method of invoking a ROA." s/invoking/revoking/, perhaps? Section 7.1: "However, if the certificates for these allocations contain different validity intervals, creating a certificate that combines them might create problems, and thus is NOT RECOMMENDED." Doesn't this problem arise when the underlying validity (e.g. the validity of the assignment/allocation/etc.) intervals vary, rather than the cert validity intervals? Perhaps this could be clearer. 7.2 "Furthermore, a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation." Is this reflected in the validation drafts? It should be likely be repeated in section 3 or 4 of the ROA format doc. -- Ticket URL: sidr From trac@tools.ietf.org Sun Nov 29 13:51:16 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379E73A68AF for ; Sun, 29 Nov 2009 13:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtQJbGxdM82Z for ; Sun, 29 Nov 2009 13:51:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 703363A635F for ; Sun, 29 Nov 2009 13:51:15 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NErfh-0006Bh-6b; Sun, 29 Nov 2009 13:51:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: gih@apnic.net X-Trac-Project: sidr Date: Sun, 29 Nov 2009 21:51:09 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/15 Message-ID: <052.062853ba1431a6971528e1892907bfab@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: gih@apnic.net, sidr@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sidr@ietf.org Subject: [sidr] #15: Incremental deployment concerns X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 21:51:16 -0000 #15: Incremental deployment concerns -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: medium | Milestone: Component: arch | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Sam Welier has noted the following concerns: The broader concern: I continue to lack confidence that our validation algorithm is complete, particularly when we look at incremental deployment. That leads me to wonder whether changes to the validation model will lead us to changes in the data. There's a reason the architecture doc has normative references to so many other active sidr docs, including ones that aren't yet to the point of WGLC, and I'm uneasy about pushing this doc out until I'm more confident about the validation model. This doc doesn't talk in depth about incremental deployment. Instead, it uses 2119 MUSTs to describe a full-deployment world (e.g., in 7.2.3, "A holder of a portable IP address space allocation MUST authorize one or more ASes to originate routes to these prefixes.") I'd prefer to see this doc acknowledge the existence of partial deployment and explain how it will work. (Will it? If so, how?) For example: the document never clearly states what (if anything) signals that the set of ROAs for a given address block is complete. Maybe we need to say "we're not yet defining a signal for 'this is the complete set of ROAs'; that's be in a different doc", but it's a glaring omission. This document also asks IANA to issue RPKI certs. I'm leery of asking them to do that when I still have doubts about the completeness of the architecture. Should we be pushing out the doc calling on IANA to deploy when the other bits aren't done yet? -- Ticket URL: sidr From gih@apnic.net Sun Nov 29 14:01:38 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCC73A69E8 for ; Sun, 29 Nov 2009 14:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.268 X-Spam-Level: **** X-Spam-Status: No, score=4.268 tagged_above=-999 required=5 tests=[AWL=-4.478, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnZ+SgYnW2Tv for ; Sun, 29 Nov 2009 14:01:37 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 191C63A69DA for ; Sun, 29 Nov 2009 14:01:36 -0800 (PST) Received: from cpe-58-170-59-21.lns2.woo.bigpond.net.au (CPE-58-170-59-21.lns2.woo.bigpond.net.au [58.170.59.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 6C04ED58CE; Mon, 30 Nov 2009 08:12:55 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> Date: Mon, 30 Nov 2009 09:01:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <78023D66-2B3D-4C07-9146-10EE2902B102@apnic.net> References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Cc: skent@bbn.com Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-arch-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 22:01:38 -0000 WG co-chair hat ON The WGLC of this document as a proposed BCP has now finished I observed on the mailing list five WG members who responded to this = last call. No response was in favour of progressing the document as it = stands.=20 Tickets #2, #6, #14 and #15 contain a record of the issues that have = been raised in these responses I would like to request the document's authors to respond to these = issues, either in the tracker on on the mailing list, and revise the = document as considered necessary to address these review comments.=20 A further WGLC will be made on a revised version of this draft. Thanks, Geoff WG co-chair hat ON On 28/10/2009, at 1:50 PM, Geoff Huston wrote: > The WG chairs have received a Working Group Last Call request from the = authors of draft-ietf-sidr-arch-09.txt. >=20 > The document (and the draft history) is at = http://tools.ietf.org/html/draft-ietf-sidr-roa-arch-09 >=20 > The Last Call will end as of the close of business on Monday 23rd = November - this is a longer period than a conventional 2 week last call = period in order to include the forthcoming SIDR WG meeting at IETF 76. >=20 > The intended status of this document is informational. >=20 > As usual, please address all comments to the WG mailing list, and = please be clear in your comments to this last call if you are supporting = the document's submission to the IESG or if you are opposed, or if you = are not expressing a view either way. As there are a number of documents = that are being last-called at this point in time it would be appreciated = if responses could clearly identify which document is being referred to. >=20 >=20 > Thanks, >=20 > Geoff >=20 > WG Co-CHair hat ON >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From bje@apnic.net Sun Nov 29 15:45:59 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754C13A686E for ; Sun, 29 Nov 2009 15:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcB-4vXTkeqH for ; Sun, 29 Nov 2009 15:45:58 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 6153A3A68C7 for ; Sun, 29 Nov 2009 15:45:56 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:21f:f3ff:fe8b:8df6] (unknown [IPv6:2001:dc0:a000:4:21f:f3ff:fe8b:8df6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D8675D58CE; Mon, 30 Nov 2009 09:57:14 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Byron Ellacott In-Reply-To: Date: Mon, 30 Nov 2009 09:45:45 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <38F7F7DA-BE49-4694-9432-29DABBAA1E16@apnic.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1077) Cc: "sra@isc.org" , "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 23:45:59 -0000 Hi Terry, On 30/10/2009, at 2:00 PM, Terry Manderson wrote: > Oppose.. >=20 > Firstly, my initial observation is that the 'XML in ANS1 in CMS = (signed)' > transported in mutually validated and authenticated(*) HTTPS/TLS = sessions > appears somewhat weighty to cover MiTM/Repla given other parts of the = entire > RPKI system don't seem to have been given the same attention and = remain > untrusted? >=20 > (*) you mean cross-certified? or some other way of mutually = authenticated? I think this has already been sufficiently discussed by the WG, I won't = add further to it here. > Secondly, since this uses a PKI of some description, where is the > description of the PKI (and CP?) for the signing of the CMS blobs and = the > PKI (and CP) for the TLS sessions. Are they the same? not the same? = RPKI > certs used? etc. This is addressed in the final bullet point of section 2, which states = that this is outside the scope of this specification. I believe Rob also addressed this in his = earlier response. > Are there multiple fully interoperable server and client codebases = based on > this? Why I ask is the XML and the basic operations (list, issue, = revoke) is > simple enough - the killer space would be getting the multiple signing > events right. ie which cert is used for the CMS, which is used for the = TLS.. > and the ASN.1/CMS combo in order. Again I believe Rob has talked about this. > lastly, the draft suggests "the server MUST NOT accept a client's = request > unless it has generated and sent a response to the client's previous > request" - it appeard the _assumption_ made is that the client deals = with > the resources of only one entity. What if it deals with more? What if = the > ISP is representative of multiple organisations and wishes to do = multiple > updates in parallel? The terminology in section 1.1 defines a client as a unitary resource = holder. If one ISP is representative of multiple entities it will take = the part of multiple clients. > section 3.2: >=20 > Please specify here the version of XML schema that this draft in its = common > message format uses (not just describes) and the section (section 4) = that > contains the xml schema. I think that it needs to be done prior to the > introduction of the template and template values. The document notes in section 4 that this is a "RelaxNG compact form = schema". For future note, should it become necessary to provide a = reference to this schema, http://www.relaxng.org/compact-20021121.htmlis = the syntax specification document for RNG-C. > http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a = pretty > 404, but a 404 nevertheless) So the namespace is invalid. The relevant observation here is that in XML the "namespace name, to = serve its intended purpose, should have the characteristics of = uniqueness and persistence. It is not a goal that it be directly usable = for retrieval of a schema (if any exists)." [Section 3, "Declaring = Namespaces", http://www.w3.org/TR/xml-names/] > I think I would like to see a summary table of all of the HTTP = response > codes used by this protocol. Its not clear how a reproduction of section 10 of RFC2616 would assist = the reader of this document. > Section 3.5.1 >=20 > Looks like a wayward "]": >=20 > ski=3D"encoded hash of the subject public key]" /> Noted as a nit to be corrected in the next version. Thanks, Byron _____________________________________________________________________ Byron Ellacott email: bje@apnic.net Technical Area Manager, APNIC sip: bje@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 From terry.manderson@icann.org Sun Nov 29 19:27:35 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0412A3A683D for ; Sun, 29 Nov 2009 19:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 sy0KwP5D8e7n for ; Sun, 29 Nov 2009 19:27:33 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id E03633A6819 for ; Sun, 29 Nov 2009 19:27:33 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sun, 29 Nov 2009 19:27:27 -0800 From: Terry Manderson To: Byron Ellacott Date: Sun, 29 Nov 2009 19:27:24 -0800 Thread-Topic: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt Thread-Index: AcpxTiEdkl2FJZUjTWSOCBne9QRFWwAHudOJ Message-ID: In-Reply-To: <38F7F7DA-BE49-4694-9432-29DABBAA1E16@apnic.net> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sra@isc.org" , "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 03:27:35 -0000 Byron, On 30/11/09 9:45 AM, "Byron Ellacott" wrote: [..] >=20 >> lastly, the draft suggests "the server MUST NOT accept a client's reques= t >> unless it has generated and sent a response to the client's previous >> request" - it appeard the _assumption_ made is that the client deals wit= h >> the resources of only one entity. What if it deals with more? What if th= e >> ISP is representative of multiple organisations and wishes to do multipl= e >> updates in parallel? >=20 > The terminology in section 1.1 defines a client as a unitary resource hol= der. I just re-read section 1.1 and I did not see the words you write above. I note that it does say the ISP assumes the role of the client, and the ISP is the subject of a resource certificate. I think that definition should be made clearer that it is singular relationship. (ie I would much rather your words above in the terminology) > If one ISP is representative of multiple entities it will take the part o= f > multiple clients. What I _think_ you mean is if one ISP is representative, but not necessaril= y the subject of, multiple resource certificates. I highlight this as while you moot that the CA which drives the https/CMS signing the client definition is bonded to the resource certificate - efficiencies of issuing https/cms certs can be made. >=20 >> section 3.2: >>=20 >> Please specify here the version of XML schema that this draft in its com= mon >> message format uses (not just describes) and the section (section 4) tha= t >> contains the xml schema. I think that it needs to be done prior to the >> introduction of the template and template values. >=20 > The document notes in section 4 that this is a "RelaxNG compact form sche= ma". > For future note, should it become necessary to provide a reference to thi= s > schema, http://www.relaxng.org/compact-20021121.htmlis the syntax > specification document for RNG-C. I think you missed my initial point. I'm after a brief intro at sections 3.= 2 telling me there is a complete schema v1 at section 4, of which of which these templates are derived from. It seems disjointed to me to start introducing XML templates without letting me know that a full schema exists just 10 pages ahead. Additionally, since you provide a reference for RelaxNG, no such reference exists in the references section of the draft. Please correct. >=20 >> http://www.apnic.net/specs/rescerts/up-down/ responds with a 404 (a pret= ty >> 404, but a 404 nevertheless) So the namespace is invalid. >=20 > The relevant observation here is that in XML the "namespace name, to serv= e its > intended purpose, should have the characteristics of uniqueness and > persistence. It is not a goal that it be directly usable for retrieval of= a > schema (if any exists)." [Section 3, "Declaring Namespaces", > http://www.w3.org/TR/xml-names/] ack.. although people expect it. ie no-one cares if you do, it's just irritating if you don't. (ie great, I can grab it from there with a wget an= d not have to cut-n-paste with clean-up from the ID) >=20 >> I think I would like to see a summary table of all of the HTTP response >> codes used by this protocol. >=20 > Its not clear how a reproduction of section 10 of RFC2616 would assist th= e > reader of this document. Are you saying that all the current implementations of server and client us= e all the HTTP error codes? including redirection? 206 partial content? (whic= h would invalid in the CMS structure??) Why would the server generate a 502 bad gateway? Answer - it wouldn't / shouldn't act as a gateway.. So to eliminate all those silly possibilities you wouldn't need to reproduce the entire section 10. Just the ones that ar= e actually used in earnest. The document mentions only one error code. "HTTP 400 Bad Data" .. Are you intentionally diverging from RFC2616's "400 Bad Request"? .. and in my mind by only seeing one http error code mentioned - it draws my mind to the "is that it?" question. (hence why I asked for a summary) My guess is that the response/error code list would be a small list and worth the effort. >=20 >> Section 3.5.1 >>=20 >> Looks like a wayward "]": >>=20 >> ski=3D"encoded hash of the subject public key]" /> >=20 > Noted as a nit to be corrected in the next version. >=20 Thanks Terry From randy@psg.com Sun Nov 29 22:14:25 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827CD3A6821 for ; Sun, 29 Nov 2009 22:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 98tOoaM339r7 for ; Sun, 29 Nov 2009 22:14:15 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id DA55E3A6914 for ; Sun, 29 Nov 2009 22:14:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NEzWJ-000BzK-Qv; Mon, 30 Nov 2009 06:13:59 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 34C492C67ECE; Mon, 30 Nov 2009 15:13:59 +0900 (JST) Date: Mon, 30 Nov 2009 15:13:58 +0900 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: <38F7F7DA-BE49-4694-9432-29DABBAA1E16@apnic.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sra@isc.org" , "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 06:14:26 -0000 > I note that it does say the ISP assumes the role of the client, and the ISP > is the subject of a resource certificate. what is the client is not an isp, e.g. an RIR, NIR, end site, ...? randy From bje@apnic.net Sun Nov 29 22:28:59 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F493A6919 for ; Sun, 29 Nov 2009 22:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drZ44-jQlqfy for ; Sun, 29 Nov 2009 22:28:58 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 7F4DD3A6821 for ; Sun, 29 Nov 2009 22:28:57 -0800 (PST) Received: from [IPv6:2001:dc0:a000:4:21f:f3ff:fe8b:8df6] (unknown [IPv6:2001:dc0:a000:4:21f:f3ff:fe8b:8df6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 85BEBD58CE; Mon, 30 Nov 2009 16:40:19 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Byron Ellacott In-Reply-To: Date: Mon, 30 Nov 2009 16:28:48 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <38F7F7DA-BE49-4694-9432-29DABBAA1E16@apnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1077) Cc: "sra@isc.org" , "sidr@ietf.org" Subject: Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 06:28:59 -0000 Hi Randy, On 30/11/2009, at 4:13 PM, Randy Bush wrote: >> I note that it does say the ISP assumes the role of the client, and = the ISP >> is the subject of a resource certificate. >=20 > what is the client is not an isp, e.g. an RIR, NIR, end site, ...? I'm using the current terminology of the document to discuss Terry's = concerns, but we will be changing to the terminology of "Subject" and = "Issuer" in the next version of the document. This is noted at: http://trac.tools.ietf.org/wg/sidr/trac/ticket/5 Byron _____________________________________________________________________ Byron Ellacott email: bje@apnic.net Technical Area Manager, APNIC sip: bje@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 From kent@bbn.com Mon Nov 30 05:49:30 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9573A6923 for ; Mon, 30 Nov 2009 05:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 BaJ6nGmhg7EH for ; Mon, 30 Nov 2009 05:49:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3C2743A6932 for ; Mon, 30 Nov 2009 05:49:29 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.236.246.158]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NF6cz-0007Iz-BA for sidr@ietf.org; Mon, 30 Nov 2009 08:49:21 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 30 Nov 2009 08:49:18 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] manifests X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:49:30 -0000 Folks, I just re-read the manifest document and I no longer believe that we ought to try to make it more general at this time. In particular, the notion of one-time use certs and multiple-use certs seems a bit RPKI-specific, but appears throughout the document. So, in the interest of getting this document out the door shortly, I suggest that we publish it and, if there is interest, folks can generate a more general version later, as Sandy and Randy have suggested. Steve