From kent@bbn.com Tue Oct 6 07:25: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 E93EB3A690F for ; Tue, 6 Oct 2009 07:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=-0.908, 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 BAPafxrDZSs3 for ; Tue, 6 Oct 2009 07:25:32 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 25E093A68F3 for ; Tue, 6 Oct 2009 07:25:32 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MvA4J-0007iV-Ee; Tue, 06 Oct 2009 09:27:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> Date: Tue, 6 Oct 2009 09:28:52 -0400 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:25:33 -0000 At 4:15 PM +1000 9/21/09, Terry Manderson wrote: >On 19/09/2009, at 3:23 AM, Stephen Kent wrote: > >> >>We were told over a year ago that, because of legitimate transfers, >>looking for duplicates was bad idea, in the repository system. So, >>I'm not sure if we want to do it in the 'assimilated relying party >>rpki.' >> > >So legitimate transfers will breed duplicates? My recollection of >that discussion that there would be timing in place that certificate >validity times would be tuned (with sparse use of CRLs) to effect >the transfers. Or am I mistaken? I have been told that it is likely that certs issued in conjunction with transfers will overlap in validity intervals. >I think, if anywhere you needed to go looking for duplicates it >would be the relying party software (either your software or rcynic) >before it mades it to the router "decision" Yes, and I was referring to RP software trying to look for duplicates in the certs it downloads. >>... > >If your software can change the contents of the 3779 extensions, >would it not be a simple exercise to change the SIA value? The model for our local TA management system does not require any changes to SIA values, because all of the changes are purely local. And, as I noted, 3rd party CAs are not consistent with the CP. Steve From kent@bbn.com Tue Oct 6 07:25: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 46D5728C1BD for ; Tue, 6 Oct 2009 07:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6dAbRuNI1Me for ; Tue, 6 Oct 2009 07:25:34 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 890CD28C1A4 for ; Tue, 6 Oct 2009 07:25:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MvA4M-0007iV-F8; Tue, 06 Oct 2009 09:27:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4AB24A1A.1030100@ripe.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <4AB24A1A.1030100@ripe.net> Date: Tue, 6 Oct 2009 09:39:25 -0400 To: Andrei Robachevsky From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:25:35 -0000 At 4:39 PM +0200 9/17/09, Andrei Robachevsky wrote: >Stephen Kent wrote on 16-09-2009 17:53: >[...] >> >> Statements about perceived trust in TAs are useful in PKIs that anoint >> 3rd parties as TAs, independent of real world authorization. The RPLI is >> not such a PKI. Instead it seeks to have the real world entities that >> manage allocation of resources act as CAs. I would urge us to NOT try to >> make the RPKI into a trusted 3rd party PKI. >> > >I agree. However, I envisage a scenario when the RP in your local TA >management scheme announces itself globally as a root CA/TA. And then >the question arises how one can distinguish between these ersatz RPKIs >and associated stuff (repositories, ROAs, etc.)? > >> Steve > >Andrei Andrie, The local TA management mechanisms I described makes no provisions for advertising TAs to a larger community. Any means of doing this are outside the scope of the mechanism. If an entity has the authority to convince other entities (in some domain) to accept it's vision of the RPKI, based on applying local TA management mechanisms, then it can do so, but how it does so it outside of the local TA management mechanism. Steve From kent@bbn.com Tue Oct 6 07:25: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 57A6428C1CC for ; Tue, 6 Oct 2009 07:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 InDAKkzI-aXz for ; Tue, 6 Oct 2009 07:25:37 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9A91F28C1C9 for ; Tue, 6 Oct 2009 07:25:37 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.26.228]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MvA4L-0007iV-Ek; Tue, 06 Oct 2009 09:27:09 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4AB76272.2090206@cryptocom.ru> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <4AB76272.2090206@cryptocom.ru> Date: Tue, 6 Oct 2009 09:30:37 -0400 To: Basil Dolmatov From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-957283266==_ma============" Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:25:38 -0000 --============_-957283266==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 3:24 PM +0400 9/21/09, Basil Dolmatov wrote: >Stephen Kent =D4=CB=AF=C2=DA: >> If folks want, I can prepare an=20 >>(informational) I-D that describes_ one_ way of=20 >>managing TA locally, as per my presentation at=20 >>the SIDR meeting. > >Folks want. > >It would be a nice reference point and would=20 >save a lot of explanations in future deployment. > >dol@ We will generate an I-D. Steve --============_-957283266==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sidr] Controlling routing (was Re: WG Chair Affiliati
At 3:24 PM +0400 9/21/09, Basil Dolmatov wrote:
Stephen Kent =D4=CB=AF=C2=DA:
 If folks want, I can prepare an (informational) I-D that describes_ one_ way of managing TA locally, as per my presentation at the SIDR meeting.

=46olks want.

It would be a nice reference point and would save a lot of explanations in future deployment.

dol@

We will generate an I-D.

Steve
--============_-957283266==_ma============-- From terry@terrym.net Tue Oct 6 19:03: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 A4B4E28C1D0 for ; Tue, 6 Oct 2009 19:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dznWFoNrS5se for ; Tue, 6 Oct 2009 19:03:40 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id E2FFD28C208 for ; Tue, 6 Oct 2009 19:03:39 -0700 (PDT) Received: by ewy10 with SMTP id 10so4884339ewy.9 for ; Tue, 06 Oct 2009 19:05:15 -0700 (PDT) Received: by 10.216.87.7 with SMTP id x7mr438728wee.53.1254881115310; Tue, 06 Oct 2009 19:05:15 -0700 (PDT) Received: from ?192.168.1.103? ([114.77.128.245]) by mx.google.com with ESMTPS id f13sm904256gvd.6.2009.10.06.19.05.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 06 Oct 2009 19:05:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Terry manderson In-Reply-To: Date: Wed, 7 Oct 2009 12:05:06 +1000 Content-Transfer-Encoding: 7bit Message-Id: <3C8D3368-49EC-4E79-BB83-062CA8278DA2@terrym.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> To: Stephen Kent X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 02:03:53 -0000 On 06/10/2009, at 11:28 PM, Stephen Kent wrote: >> >> So legitimate transfers will breed duplicates? My recollection of >> that discussion that there would be timing in place that >> certificate validity times would be tuned (with sparse use of CRLs) >> to effect the transfers. Or am I mistaken? > > I have been told that it is likely that certs issued in conjunction > with transfers will overlap in validity intervals. > so two organisations, at some point in time, will have the ability to issue valid and conflicting statements. I think that is really hairy. I can guess it was for the concern of maintaining connectivity, ie not creating break scenarios. But to me it appears to muddy the water. Surely there are better ways to achieve a low impact transfer? ie place an embargo on ROA/BOA creation for a time slice either side of the transfer. That would have the effect of degrading the trust statement, but not conflicting it nor breaking routing, for the period of transfer.. But still allows a clear delineation of 'ownership'. Although I'm not sure if that is in the IETF bailiwick to discuss. Maybe since having global operations impact it is. > >>> ... >> >> If your software can change the contents of the 3779 extensions, >> would it not be a simple exercise to change the SIA value? > > The model for our local TA management system does not require any > changes to SIA values, because all of the changes are purely local. > And, as I noted, 3rd party CAs are not consistent with the CP. My thoughts would be that a local TA would also run a local repository for itself, and any subordinate entities. Cheers Terry From robert@ripe.net Wed Oct 7 09:45: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 D52943A67DB for ; Wed, 7 Oct 2009 09:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.817 X-Spam-Level: X-Spam-Status: No, score=-7.817 tagged_above=-999 required=5 tests=[AWL=2.782, 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 9FFDZQTPeygt for ; Wed, 7 Oct 2009 09:45:46 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id A78BC3A6805 for ; Wed, 7 Oct 2009 09:45:45 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MvZfa-0006E7-Vd; Wed, 07 Oct 2009 18:47:24 +0200 Received: from Kistel-Mac.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id B83102F583; Wed, 7 Oct 2009 18:47:18 +0200 (CEST) Message-ID: <4ACCC616.6060405@ripe.net> Date: Wed, 07 Oct 2009 17:47:18 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Terry manderson References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> <3C8D3368-49EC-4E79-BB83-062CA8278DA2@terrym.net> In-Reply-To: <3C8D3368-49EC-4E79-BB83-062CA8278DA2@terrym.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274ebb9335620b45ea9e6feafa326e47dc5 Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 16:45:46 -0000 Terry, see below... Terry manderson wrote: > > On 06/10/2009, at 11:28 PM, Stephen Kent wrote: > >>> >>> So legitimate transfers will breed duplicates? My recollection of >>> that discussion that there would be timing in place that certificate >>> validity times would be tuned (with sparse use of CRLs) to effect the >>> transfers. Or am I mistaken? >> >> I have been told that it is likely that certs issued in conjunction >> with transfers will overlap in validity intervals. >> > > so two organisations, at some point in time, will have the ability to > issue valid and conflicting statements. They have that ability today, it is being used and it's useful. Would you want to take that ability away from them, should they want to use RPKI? > I think that is really hairy. I can guess it was for the concern of > maintaining connectivity, ie not creating break scenarios. But to me it > appears to muddy the water. Surely there are better ways to achieve a > low impact transfer? ie place an embargo on ROA/BOA creation for a time > slice either side of the transfer. That would have the effect of > degrading the trust statement, but not conflicting it nor breaking > routing, for the period of transfer.. But still allows a clear > delineation of 'ownership'. Suppose you're ISP1, and want to sell some part of your clients to ISP2 (this happens: mergers, splits, you name it). In other words, you want to transfer a live, routed and used chunk of space to another party. How would you execute this while ROAs are in place? If you think about it you'll realize that there have to be multiple ROAs which overlap in terms of validity time, otherwise you introduce exact timing, which sounds pretty difficult to execute with 30K+ participants. Of course the whole story is a lot easier if you don't need to keep the network alive. Robert From jared@puck.nether.net Wed Oct 7 10:02: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 5EB683A6884 for ; Wed, 7 Oct 2009 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTKvGP3HgLHy for ; Wed, 7 Oct 2009 10:02:39 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 4EFC83A6827 for ; Wed, 7 Oct 2009 10:02:39 -0700 (PDT) Received: from rev-204-42-254-133.dhcp.nether.net (rev-204-42-254-133.dhcp.nether.net [204.42.254.133]) (authenticated bits=0) by puck.nether.net (8.14.3/8.12.9) with ESMTP id n97H5eNJ042907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Oct 2009 13:05:40 -0400 (EDT) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jared Mauch In-Reply-To: <4ACCC616.6060405@ripe.net> Date: Wed, 7 Oct 2009 13:04:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> <3C8D3368-49EC-4E79-BB83-062CA8278DA2@terrym.net> <4ACCC616.6060405@ripe.net> To: Robert Kisteleki X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (puck.nether.net [204.42.254.5]); Wed, 07 Oct 2009 13:05:40 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:02:40 -0000 On Oct 7, 2009, at 12:47 PM, Robert Kisteleki wrote: > Terry, see below... > > Terry manderson wrote: >> On 06/10/2009, at 11:28 PM, Stephen Kent wrote: >>>> >>>> So legitimate transfers will breed duplicates? My recollection of >>>> that discussion that there would be timing in place that >>>> certificate validity times would be tuned (with sparse use of >>>> CRLs) to effect the transfers. Or am I mistaken? >>> >>> I have been told that it is likely that certs issued in >>> conjunction with transfers will overlap in validity intervals. >>> >> so two organisations, at some point in time, will have the ability >> to issue valid and conflicting statements. > > They have that ability today, it is being used and it's useful. > Would you want to take that ability away from them, should they want > to use RPKI? > >> I think that is really hairy. I can guess it was for the concern of >> maintaining connectivity, ie not creating break scenarios. But to >> me it appears to muddy the water. Surely there are better ways to >> achieve a low impact transfer? ie place an embargo on ROA/BOA >> creation for a time slice either side of the transfer. That would >> have the effect of degrading the trust statement, but not >> conflicting it nor breaking routing, for the period of transfer.. >> But still allows a clear delineation of 'ownership'. > > Suppose you're ISP1, and want to sell some part of your clients to > ISP2 (this happens: mergers, splits, you name it). In other words, > you want to transfer a live, routed and used chunk of space to > another party. How would you execute this while ROAs are in place? > If you think about it you'll realize that there have to be multiple > ROAs which overlap in terms of validity time, otherwise you > introduce exact timing, which sounds pretty difficult to execute > with 30K+ participants. > > Of course the whole story is a lot easier if you don't need to keep > the network alive. Operators will always opt to keep their network alive, anything that risks keeping the network operational will have a hard time finding a place in networks. I can think of other cases I'm not going to enumerate here, but typically transfers of customers and space take months if not years to sort out, while actual network control may happen more immediately. I think we still have customers on "NTT" space that are homed on the Cogent network from some prior transfers. - Jared From danny@tcb.net Wed Oct 7 10: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 883743A6884 for ; Wed, 7 Oct 2009 10:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEJWuxLnMuCh for ; Wed, 7 Oct 2009 10:11:57 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id CF3A83A67CF for ; Wed, 7 Oct 2009 10:11:57 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 12ED32684EA; Wed, 7 Oct 2009 11:13:38 -0600 (MDT) Received: from jchouinard-sim-318.eng.ellacoya.com (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 07 Oct 2009 11:13:37 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=58768; syn-fingerprint=65535:56:1:64:M1408,N,W3,N,N,T,S; 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: <4ACCC616.6060405@ripe.net> Date: Wed, 7 Oct 2009 11:13:37 -0600 Content-Transfer-Encoding: 7bit Message-Id: <9E438B12-35BC-4D80-9AFF-648E1846E719@tcb.net> References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> <3C8D3368-49EC-4E79-BB83-062CA8278DA2@terrym.net> <4ACCC616.6060405@ripe.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:11:58 -0000 On Oct 7, 2009, at 10:47 AM, Robert Kisteleki wrote: > Suppose you're ISP1, and want to sell some part of your clients to > ISP2 (this happens: mergers, splits, you name it). In other words, > you want to transfer a live, routed and used chunk of space to > another party. How would you execute this while ROAs are in place? ISP1 would issue ROAs with ISP2 as authorized origin AS for prefixes in question, no? > If you think about it you'll realize that there have to be multiple > ROAs which overlap in terms of validity time, otherwise you > introduce exact timing, which sounds pretty difficult to execute > with 30K+ participants. My concern isn't about collision/overlap of ROAs at the bottom of the RPKI hierarchy, that seems perfectly reasonably to me if the operator so chooses. My concern is about resolution of collisions among TAs and CERTs at the top, in particular when the TAs are NOT congruent to the address allocation hierarchy - how does a relying party elsewhere resolve this when the TA and allocation hierarchy are not congruent (not to mention implications on attack surface as a result). -danny From terry.manderson@icann.org Wed Oct 7 17:39: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 1995A3A6856 for ; Wed, 7 Oct 2009 17:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 0ezFt16lq7LH for ; Wed, 7 Oct 2009 17:39:22 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 569DF3A67A3 for ; Wed, 7 Oct 2009 17:39:22 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 7 Oct 2009 17:41:03 -0700 From: Terry Manderson To: Robert Kisteleki , Terry Manderson Date: Wed, 7 Oct 2009 17:41:03 -0700 Thread-Topic: [sidr] Controlling routing (was Re: WG Chair Affiliation) Thread-Index: AcpHbgHWBD6IQNMTQW2lE8un9t5hjwAQgGLj Message-ID: In-Reply-To: <4ACCC616.6060405@ripe.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: "sidr@ietf.org" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 00:39:23 -0000 Hi Robert, On 8/10/09 2:47 AM, "Robert Kisteleki" wrote: [..] >>=20 >> so two organisations, at some point in time, will have the ability to >> issue valid and conflicting statements. >=20 > They have that ability today, it is being used and it's useful. Would you > want to take that ability away from them, should they want to use RPKI? >=20 There are differences to what actions result from "statements" today, versu= s what actions will occur in RPKI given the WG stance (which I don't agree with) on ROA interpretation. If you have two certificates that overlap in validity time, say for 10/8, the following can occur: The first certificate holder issues only a ROA for 10/8 maxLength 8 @AS1 an= d originates 10/8 from AS1 The second certificate holder issues only a ROA for 10/8 maxLength 24 @AS3 and originates 10.1.1/24 from AS3 (ie some migration strategy) Depending on which certificate the Relying Party believes, they might rejec= t (based on current WG interpretation of a ROA) the other valid announcements at their router. (at least that is how I'm reading it - please correct me i= f askew) If you approach this as a 'not found' interpretation - as originally writte= n - this becomes near moot. >=20 > Suppose you're ISP1, and want to sell some part of your clients to ISP2 > (this happens: mergers, splits, you name it). In other words, you want to > transfer a live, routed and used chunk of space to another party. How wou= ld > you execute this while ROAs are in place? If you think about it you'll > realize that there have to be multiple ROAs which overlap in terms of > validity time, otherwise you introduce exact timing, which sounds pretty > difficult to execute with 30K+ participants. >=20 Transferring networks (ie changing the AS origination of a prefix) and transferring ownership doesn't need to be done at the same time. If it is I suspect you probably won't be keeping the network alive. The exact timing that you speak of is coordinated in advance through notBefore and notAfter times of the two resource certificates. I would thin= k that in your example, assuming that only ownership is being transferred, an= d not origination, ISP1 and ISP2 would make their ROAs match (or be non existent) for the ownership settlement time as to not upset routing. Terry From terry.manderson@icann.org Wed Oct 7 17:45: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 4DE5528C197 for ; Wed, 7 Oct 2009 17:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 EKYGBWAmLQYI for ; Wed, 7 Oct 2009 17:45:12 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 6E0AA28C1F1 for ; Wed, 7 Oct 2009 17:45:12 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 7 Oct 2009 17:46:53 -0700 From: Terry Manderson To: Jared Mauch , Robert Kisteleki Date: Wed, 7 Oct 2009 17:46:52 -0700 Thread-Topic: [sidr] Controlling routing (was Re: WG Chair Affiliation) Thread-Index: AcpHcES2++usOMb7R/uXlF7sXKQ3PgAQI6zN 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] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 00:45:13 -0000 On 8/10/09 3:04 AM, "Jared Mauch" wrote: >=20 > Operators will always opt to keep their network alive, anything that > risks keeping the network operational will have a hard time finding a > place in networks. >=20 > I can think of other cases I'm not going to enumerate here, but Actually, for the benefit of the use-cases draft, could you? > typically transfers of customers and space take months if not years to > sort out, while actual network control may happen more immediately. I right, so "ownership" happens at a different time and space to network origination? (That's been my experience, being in active takeovers of companies where not upsetting the network and customers was the highest priority - but still making sure the control was in hand) > think we still have customers on "NTT" space that are homed on the > Cogent network from some prior transfers. >=20 Can you elaborate in terms of ISP1 and ISP2 to protect the innocent? Ie provide action timing? what happened when? Cheers Terry From terry.manderson@icann.org Wed Oct 7 17:55: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 1AECB3A68C2 for ; Wed, 7 Oct 2009 17:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 MYjvvfJlAJ3k for ; Wed, 7 Oct 2009 17:55:10 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 621D73A686E for ; Wed, 7 Oct 2009 17:55:10 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 7 Oct 2009 17:56:51 -0700 From: Terry Manderson To: Danny McPherson , "sidr@ietf.org" Date: Wed, 7 Oct 2009 17:56:51 -0700 Thread-Topic: [sidr] Controlling routing (was Re: WG Chair Affiliation) Thread-Index: AcpHcZQxMXi48OA4TsW/hDJGj9m90wAQKQ8t Message-ID: In-Reply-To: <9E438B12-35BC-4D80-9AFF-648E1846E719@tcb.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] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 00:55:11 -0000 On 8/10/09 3:13 AM, "Danny McPherson" wrote: >=20 >=20 > On Oct 7, 2009, at 10:47 AM, Robert Kisteleki wrote: >=20 >> Suppose you're ISP1, and want to sell some part of your clients to >> ISP2 (this happens: mergers, splits, you name it). In other words, >> you want to transfer a live, routed and used chunk of space to >> another party. How would you execute this while ROAs are in place? >=20 > ISP1 would issue ROAs with ISP2 as authorized origin AS for > prefixes in question, no? right.. and further make the ROAs match before and after settlement as to not upset the network. >=20 >> If you think about it you'll realize that there have to be multiple >> ROAs which overlap in terms of validity time, otherwise you >> introduce exact timing, which sounds pretty difficult to execute >> with 30K+ participants. >=20 > My concern isn't about collision/overlap of ROAs at the bottom > of the RPKI hierarchy, that seems perfectly reasonably to me if > the operator so chooses. But what decision should the relying party make? in other words how does th= e relying party know that collision was intentional? >=20 > My concern is about resolution of collisions among TAs and CERTs > at the top, in particular when the TAs are NOT congruent to the > address allocation hierarchy - how does a relying party elsewhere > resolve this when the TA and allocation hierarchy are not congruent > (not to mention implications on attack surface as a result). I suspect, the only answer to this is a trusted TA repository that blesses the TAs so that all the Relying Parties can at least start from a cogent position. I can hear the groans of discomfort now.. :-) Cheers Terry From danny@tcb.net Wed Oct 7 18:12: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 848163A68C2 for ; Wed, 7 Oct 2009 18:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yT61hcRGQLl for ; Wed, 7 Oct 2009 18:12:43 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id CB4123A677E for ; Wed, 7 Oct 2009 18:12:43 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id CDDEB2684EA; Wed, 7 Oct 2009 19:14:24 -0600 (MDT) Received: from jchouinard-sim-318.eng.ellacoya.com (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 07 Oct 2009 19:14:24 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=51167; syn-fingerprint=65535:56:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Danny McPherson In-Reply-To: Date: Wed, 7 Oct 2009 19:14:22 -0600 Content-Transfer-Encoding: 7bit Message-Id: <27624407-A7D9-4FD3-A8D2-120EAB150CAB@tcb.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1076) Cc: "sidr@ietf.org" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:12:44 -0000 On Oct 7, 2009, at 6:56 PM, Terry Manderson wrote: >> My concern isn't about collision/overlap of ROAs at the bottom >> of the RPKI hierarchy, that seems perfectly reasonably to me if >> the operator so chooses. > > But what decision should the relying party make? in other words how > does the > relying party know that collision was intentional? I'd think it wouldn't matter with the RP, if the ROAs are there then accept those prefixes from the specified Origin AS - even if multiple - i.e., doesn't a valid ROA imply it was intentional ;-) > I suspect, the only answer to this is a trusted TA repository that > blesses > the TAs so that all the Relying Parties can at least start from a > cogent > position. I can hear the groans of discomfort now.. :-) Indeed.. -danny From terry.manderson@icann.org Wed Oct 7 18:21: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 F2B143A6829 for ; Wed, 7 Oct 2009 18:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 y02eJGQWEHxr for ; Wed, 7 Oct 2009 18:21:50 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 50E7E3A63EB for ; Wed, 7 Oct 2009 18:21:50 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 7 Oct 2009 18:23:31 -0700 From: Terry Manderson To: Danny McPherson Date: Wed, 7 Oct 2009 18:23:30 -0700 Thread-Topic: [sidr] Controlling routing (was Re: WG Chair Affiliation) Thread-Index: AcpHtLjAP02c9XuaRbGFg5fyr00W0AAATjD1 Message-ID: In-Reply-To: <27624407-A7D9-4FD3-A8D2-120EAB150CAB@tcb.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: "sidr@ietf.org" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:21:51 -0000 On 8/10/09 11:14 AM, "Danny McPherson" wrote: >>=20 >> But what decision should the relying party make? in other words how >> does the >> relying party know that collision was intentional? >=20 > I'd think it wouldn't matter with the RP, if the ROAs > are there then accept those prefixes from the specified > Origin AS - even if multiple - i.e., doesn't a valid > ROA imply it was intentional ;-) >=20 Sorry, my response was poorly worded. My position is that we probably shouldn't allow a system into play that can produce a fully ambiguous result. T. From danny@tcb.net Wed Oct 7 18:34: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 925563A67BD for ; Wed, 7 Oct 2009 18:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYLYBduGVRGZ for ; Wed, 7 Oct 2009 18:34:14 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 8B5DB3A6895 for ; Wed, 7 Oct 2009 18:33:51 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BBCE02684EA; Wed, 7 Oct 2009 19:35:32 -0600 (MDT) Received: from jchouinard-sim-318.eng.ellacoya.com (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 07 Oct 2009 19:35:32 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=51431; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Danny McPherson In-Reply-To: Date: Wed, 7 Oct 2009 19:35:31 -0600 Content-Transfer-Encoding: 7bit Message-Id: <674DDBF2-0545-4683-94CA-3F87DEA267AF@tcb.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:34:15 -0000 On Oct 7, 2009, at 6:41 PM, Terry Manderson wrote: > > Depending on which certificate the Relying Party believes, they > might reject > (based on current WG interpretation of a ROA) the other valid > announcements > at their router. (at least that is how I'm reading it - please > correct me if > askew) But they're not mutually exclusive, the RP would surely permit both, no? -danny From jared@puck.nether.net Wed Oct 7 18:34:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E30E3A684E for ; Wed, 7 Oct 2009 18:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ofhet9SPhpl for ; Wed, 7 Oct 2009 18:34:38 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 2F12C3A67AB for ; Wed, 7 Oct 2009 18:34:38 -0700 (PDT) Received: from rev-204-42-254-133.dhcp.nether.net (rev-204-42-254-133.dhcp.nether.net [204.42.254.133]) (authenticated bits=0) by puck.nether.net (8.14.3/8.12.9) with ESMTP id n981abd3056107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Oct 2009 21:36:37 -0400 (EDT) (envelope-from jared@puck.nether.net) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Jared Mauch In-Reply-To: Date: Wed, 7 Oct 2009 21:35:10 -0400 Content-Transfer-Encoding: 7bit Message-Id: <48C46B72-D6E7-47C4-AA7C-90D59DED3B46@puck.nether.net> References: To: Terry Manderson X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (puck.nether.net [204.42.254.5]); Wed, 07 Oct 2009 21:36:37 -0400 (EDT) Cc: "sidr@ietf.org" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:34:39 -0000 On Oct 7, 2009, at 8:46 PM, Terry Manderson wrote: > On 8/10/09 3:04 AM, "Jared Mauch" wrote: > >> >> Operators will always opt to keep their network alive, anything that >> risks keeping the network operational will have a hard time finding a >> place in networks. >> >> I can think of other cases I'm not going to enumerate here, but > > Actually, for the benefit of the use-cases draft, could you? Take the end of EUNet as an example. There were some kind souls that kept the network up and running, and there were users behind the network. This space was routed by a variety of providers in the aftermath. The business risks would be higher today as a result (as a customer) and as someone trying to capture the business in the aftermath, there would be incredible pressure to get things done ASAP to bring a new customer online, possibly with their "old" space as the proper owner is not around to assert control/authority/objections. >> typically transfers of customers and space take months if not years >> to >> sort out, while actual network control may happen more >> immediately. I > > right, so "ownership" happens at a different time and space to network > origination? (That's been my experience, being in active takeovers of > companies where not upsetting the network and customers was the > highest > priority - but still making sure the control was in hand) > This varies from company-to-company. I've seen it on the large telco scale and the small regional ISP scale over the years. Sometimes old staff is laid off as part of an asset acquisition, so it's hard to show proper authority for a period of time with your suppliers/vendors (SPs/RIR, etc)... >> think we still have customers on "NTT" space that are homed on the >> Cogent network from some prior transfers. >> > > Can you elaborate in terms of ISP1 and ISP2 to protect the innocent? > Ie provide action timing? what happened when? I think that real-life examples help explain the practicality of the process that ends up happening. We continue to forward security and abuse complaints as a part of the legacy. That happened in December 2004. Five years later there are still customers covered by this agreement. Have to run for now, but this should help.... - Jared From danny@tcb.net Wed Oct 7 18:36: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 3DE493A684B for ; Wed, 7 Oct 2009 18:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQN+NoUXrZFx for ; Wed, 7 Oct 2009 18:36:27 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 9FBB83A67E3 for ; Wed, 7 Oct 2009 18:36:27 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D315C2684EA; Wed, 7 Oct 2009 19:38:08 -0600 (MDT) Received: from jchouinard-sim-318.eng.ellacoya.com (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 07 Oct 2009 19:38:08 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=51441; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; 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: Wed, 7 Oct 2009 19:38:08 -0600 Content-Transfer-Encoding: 7bit Message-Id: <5E168679-B109-4203-A94B-160FC582ABA9@tcb.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:36:28 -0000 On Oct 7, 2009, at 7:23 PM, Terry Manderson wrote: > Sorry, my response was poorly worded. > > My position is that we probably shouldn't allow a system into play > that can > produce a fully ambiguous result. Hrmm.. You mean like the current routing system - where at this moment I see ~2086 (same length) prefixes that have multiple origin ASes - I'd hope that the RPKI would support AT LEAST this, but the reality is that a layer abstracted, it's likely to need to be considerably more flexible. -danny From terry@terrym.net Wed Oct 7 18:49: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 4C2583A67BD for ; Wed, 7 Oct 2009 18:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDHdyVaSK8P9 for ; Wed, 7 Oct 2009 18:49:25 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 567AF3A67AB for ; Wed, 7 Oct 2009 18:49:25 -0700 (PDT) Received: by ewy4 with SMTP id 4so2480327ewy.37 for ; Wed, 07 Oct 2009 18:51:04 -0700 (PDT) Received: by 10.216.88.10 with SMTP id z10mr238285wee.108.1254966663810; Wed, 07 Oct 2009 18:51:03 -0700 (PDT) Received: from ?192.168.1.103? ([114.77.128.245]) by mx.google.com with ESMTPS id m5sm25326gve.11.2009.10.07.18.51.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 18:51:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Terry manderson In-Reply-To: <674DDBF2-0545-4683-94CA-3F87DEA267AF@tcb.net> Date: Thu, 8 Oct 2009 11:50:55 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: <674DDBF2-0545-4683-94CA-3F87DEA267AF@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:49:26 -0000 On 08/10/2009, at 11:35 AM, Danny McPherson wrote: > > On Oct 7, 2009, at 6:41 PM, Terry Manderson wrote: > >> >> Depending on which certificate the Relying Party believes, they >> might reject >> (based on current WG interpretation of a ROA) the other valid >> announcements >> at their router. (at least that is how I'm reading it - please >> correct me if >> askew) > > But they're not mutually exclusive, the RP would surely > permit both, no? > The relying party shouldn't have 'both' - I think having two unique valid resource certificates from separate or the same issuer that contains the same resources is flawed. Terry From terry.manderson@icann.org Wed Oct 7 18:51: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 076673A6828 for ; Wed, 7 Oct 2009 18:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 ZxIRRHEJglC6 for ; Wed, 7 Oct 2009 18:51:42 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 5B0763A67AB for ; Wed, 7 Oct 2009 18:51:42 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 7 Oct 2009 18:53:23 -0700 From: Terry Manderson To: Danny McPherson , "sidr@ietf.org" Date: Wed, 7 Oct 2009 18:53:21 -0700 Thread-Topic: [sidr] Controlling routing (was Re: WG Chair Affiliation) Thread-Index: AcpHuAsoeE2vSdpFS+qaAG35Gdj3qAAAhHcf Message-ID: In-Reply-To: <5E168679-B109-4203-A94B-160FC582ABA9@tcb.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] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:51:43 -0000 On 8/10/09 11:38 AM, "Danny McPherson" wrote: >=20 > Hrmm.. You mean like the current routing system - where at > this moment I see ~2086 (same length) prefixes that have multiple no. That is not what I mean. > origin ASes - I'd hope that the RPKI would support AT LEAST this, > but the reality is that a layer abstracted, it's likely to need > to be considerably more flexible. >=20 The issue at hand is two different owners of a resource being able to say different things about that resource. Terry From danny@tcb.net Wed Oct 7 19:03: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 770423A684B for ; Wed, 7 Oct 2009 19:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CWC4slHb97Y for ; Wed, 7 Oct 2009 19:03:04 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id CD2313A677E for ; Wed, 7 Oct 2009 19:03:04 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 190332684EA; Wed, 7 Oct 2009 20:04:46 -0600 (MDT) Received: from jchouinard-sim-318.eng.ellacoya.com (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 07 Oct 2009 20:04:46 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=52058; syn-fingerprint=65535:56:1:64:M1408,N,W3,N,N,T,S; 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: Wed, 7 Oct 2009 20:04:44 -0600 Content-Transfer-Encoding: 7bit Message-Id: <9A9F224F-09BA-4947-B6A6-246385290A4D@tcb.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 02:03:05 -0000 On Oct 7, 2009, at 7:53 PM, Terry Manderson wrote: > > The issue at hand is two different owners of a resource being able > to say > different things about that resource. But that's not what I said - I said to make this work you'd have the EE ("owner") issue two ROAs, one for each origin - there's still only one "owner" at any given instant and that "owner" would surely work with the acquiring or acquired entities to accommodate such a request -- if routing the prefix(es) in question required this. This seems straight-forward to me.. -danny From terry.manderson@icann.org Wed Oct 7 19:12: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 DE6F93A6838 for ; Wed, 7 Oct 2009 19:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 K1H1r1PaVXxK for ; Wed, 7 Oct 2009 19:12:36 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 471943A67B5 for ; Wed, 7 Oct 2009 19:12:36 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 7 Oct 2009 19:14:17 -0700 From: Terry Manderson To: Danny McPherson , "sidr@ietf.org" Date: Wed, 7 Oct 2009 19:14:15 -0700 Thread-Topic: [sidr] Controlling routing (was Re: WG Chair Affiliation) Thread-Index: AcpHu8N+uDQJfpd9Rby1hhtYdr5qbwAAUT4S Message-ID: In-Reply-To: <9A9F224F-09BA-4947-B6A6-246385290A4D@tcb.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] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 02:12:37 -0000 On 8/10/09 12:04 PM, "Danny McPherson" wrote: >=20 > But that's not what I said - I said to make this work you'd > have the EE ("owner") issue two ROAs, one for each origin - yes. but predicated on one owner and not two. I think we are at the same place :-) > there's still only one "owner" at any given instant and that > "owner" would surely work with the acquiring or acquired entities > to accommodate such a request -- if routing the prefix(es) in > question required this. >=20 Yes. > This seems straight-forward to me.. yes.. I think I must have misinterpreted your direction, I thought you were wanting overlapping validity. Terry From danny@tcb.net Wed Oct 7 19:20: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 40A123A6838 for ; Wed, 7 Oct 2009 19:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+1Vn-l5i9n8 for ; Wed, 7 Oct 2009 19:20:49 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 9C1243A67B5 for ; Wed, 7 Oct 2009 19:20:49 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id B98B92684EA; Wed, 7 Oct 2009 20:22:30 -0600 (MDT) Received: from jchouinard-sim-318.eng.ellacoya.com (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 07 Oct 2009 20:22:30 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=52689; syn-fingerprint=65535:56:1:64:M1408,N,W3,N,N,T,S; 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: Wed, 7 Oct 2009 20:22:21 -0600 Content-Transfer-Encoding: 7bit Message-Id: <5AE09FBE-AA30-4196-875C-4E142665DED3@tcb.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 02:20:50 -0000 On Oct 7, 2009, at 8:14 PM, Terry Manderson wrote: >> >> But that's not what I said - I said to make this work you'd >> have the EE ("owner") issue two ROAs, one for each origin - > > yes. but predicated on one owner and not two. I think we are at the > same > place :-) Yep, and one minor clarification here to the above: Because there's a one-one mapping between EE certs and ROAs the resource holder would have to issue an EE & ROA (or resource cert and expect the recipient to issue their own EEs and ROAs for the prefix(es), if the operator wants to loosen things up a bit during transitions) for each prefix/origin pair) -- but there's still only one "owner" (resource holder) at any instant -- even though there may be multiple ASes originating a given prefix (or subsets). > yes.. I think I must have misinterpreted your direction, I thought > you were > wanting overlapping validity. Nope.. The issue of handling "staged ROAs for transition" and subsequent pollution in an automated RPKI will be interesting, that's for sure.. -danny From robert@ripe.net Thu Oct 8 01:38:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E007D3A6AB4 for ; Thu, 8 Oct 2009 01:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.126 X-Spam-Level: X-Spam-Status: No, score=-8.126 tagged_above=-999 required=5 tests=[AWL=2.473, 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 YTlOi1s6eNPQ for ; Thu, 8 Oct 2009 01:38:39 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id B35463A6935 for ; Thu, 8 Oct 2009 01:38:38 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1MvoXg-000812-Ee; Thu, 08 Oct 2009 10:40:13 +0200 Received: from Kistel-Mac.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id E656C2F583; Thu, 8 Oct 2009 10:40:03 +0200 (CEST) Message-ID: <4ACDA563.9060407@ripe.net> Date: Thu, 08 Oct 2009 09:40:03 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Danny McPherson References: <200909140015.n8E0Fais044750@harbor.orleans.occnc.com> <48DA8F07-CC0A-4CFA-9153-0565854832E0@virtualized.org> <6C269E52-839E-46F4-9DB1-449CB2376099@isoc.org> <9720E2F2-DE1E-4C82-9639-FB2FAC13048B@terrym.net> <82809A1B-AA9E-4EEA-821F-AC985F4CF1B7@terrym.net> <82841276-06EC-4A20-A26A-1FA75BCF7E5E@terrym.net> <1DBB285F-BFEA-4AF3-9544-FD780C5B3684@terrym.net> <3C8D3368-49EC-4E79-BB83-062CA8278DA2@terrym.net> <4ACCC616.6060405@ripe.net> <9E438B12-35BC-4D80-9AFF-648E1846E719@tcb.net> In-Reply-To: <9E438B12-35BC-4D80-9AFF-648E1846E719@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27495beffbff3cc5d5f446a387ad812723d Cc: "sidr@ietf.org" Subject: Re: [sidr] Controlling routing (was Re: WG Chair Affiliation) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 08:38:40 -0000 Danny McPherson wrote: > > On Oct 7, 2009, at 10:47 AM, Robert Kisteleki wrote: > >> Suppose you're ISP1, and want to sell some part of your clients to >> ISP2 (this happens: mergers, splits, you name it). In other words, you >> want to transfer a live, routed and used chunk of space to another >> party. How would you execute this while ROAs are in place? > > ISP1 would issue ROAs with ISP2 as authorized origin AS for > prefixes in question, no? As a first step, yes. And then what? Ultimately, the goal is to transfer "ownership" of the prefix to ISP2, not jus allow them to route it. Therefore at some point, ISP2 itself will want to make a ROA for it. Here is when the timing tricks don't work. >> If you think about it you'll realize that there have to be multiple >> ROAs which overlap in terms of validity time, otherwise you introduce >> exact timing, which sounds pretty difficult to execute with 30K+ >> participants. > > My concern isn't about collision/overlap of ROAs at the bottom > of the RPKI hierarchy, that seems perfectly reasonably to me if > the operator so chooses. Ack. > My concern is about resolution of collisions among TAs and CERTs > at the top, in particular when the TAs are NOT congruent to the > address allocation hierarchy - how does a relying party elsewhere > resolve this when the TA and allocation hierarchy are not congruent > (not to mention implications on attack surface as a result). If you accept, as above, that at lower nodes may need to have overlaps, and furthermore accept that allocation is hierarchical (which is the reason to use CAs, after all), then the logical conclusion is that the overlaps appear at higher levels too. Even at the "top", TA level, whoever those are. Robert > -danny From gih@apnic.net Wed Oct 14 21:36: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 4675B3A6995 for ; Wed, 14 Oct 2009 21:36:21 -0700 (PDT) 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_40=-0.185, 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 88BeQIrBQjTu for ; Wed, 14 Oct 2009 21:36:20 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 5400B3A6993 for ; Wed, 14 Oct 2009 21:36:20 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 98A9AD58C2 for ; Thu, 15 Oct 2009 14:36:06 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 15 Oct 2009 15:36:18 +1100 Message-Id: To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [sidr] Call for agenda items for IETF-76 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2009 04:36:21 -0000 Hi, Its that time again when the agenda for the IETF 76 meeting needs to be assembled. (Actually, we're RUNNING late, so this message is slightly urgent!) Who has material to present to the WG at this meeting? The agendas are due in at the end of this week (16th October) , so a prompt response from folk who have material to present would be very much appreciated. thanks, Geoff (co-chair hat on) From gih@apnic.net Thu Oct 15 15:03: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 22E1528C181 for ; Thu, 15 Oct 2009 15:03:50 -0700 (PDT) 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_91=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 oAZ6uPrEHNdY for ; Thu, 15 Oct 2009 15:03:49 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id B03A528C172 for ; Thu, 15 Oct 2009 15:03:48 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id E2388D587D for ; Fri, 16 Oct 2009 08:03:41 +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: Date: Fri, 16 Oct 2009 09:03:49 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] Call for agenda items for IETF-76 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2009 22:03:50 -0000 Hi, Thanks to those folk who were able to respond so quickly to the call for agenda items of the SIDR Meeting Given that the IETF schedule says: "2009-10-16 (Friday): Final agenda to be published"I'll submit the following as the proposed agenda for the meeting, but I'm sure we still have a day or two to make further changes to the agenda if there are other items folk want to talk about thanks, Geoff (co-chair hat on) 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 blue sheets, scribe victimization, etc. -- WG Document Status Reports on Updated Drafts (by the draft authors) Repository Structure - draft-ietf-sidr-repos-struct-03.txt Certificate Profile - draft-ietf-sidr-res-certs-17.txt Provisioning Protocol - draft-ietf-sidr-rescerts- provisioning-02.txt ROA Validation - draft-ietf-sidr-roa-validation-03.txt RPKI Algorithms - draft-ietf-sidr-rpki-algs-00.txt Manifests - draft-ietf-sidr-rpki-manifests-05.txt TA - draft-ietf-sidr-ta-02.txt Status of other WG Drafts RPKI Architecture - draft-ietf-sidr-arch-08.txt Bogons - draft-ietf-sidr-bogons-03.txt CP - draft-ietf-sidr-cp-06.txt CPS-IR - draft-ietf-sidr-cps-irs-04.txt CPS-ISP - draft-ietf-sidr-cps-isp-03.txt ROA Format - draft-ietf-sidr-roa-format-05.txt RPSL Signatures - draft-ietf-sidr-rpsl-sig-01.txt -- New Work Update on Use Cases draft (also request for WG adoption) draft-manderson-sidr-usecases-00.txt Terry Manderson Local TA Management presentation on draft in progress Steve Kent -- RPKI Operators Roundtable Report and Discussion Report: Ruediger Volk Discussion: John Schnizlein From gih@apnic.net Thu Oct 15 16:51: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 B3FAA3A68BE for ; Thu, 15 Oct 2009 16:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBILTOXQwQuR for ; Thu, 15 Oct 2009 16:51:18 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C9D523A688C for ; Thu, 15 Oct 2009 16:51:17 -0700 (PDT) Received: from dhcp096.yarralumla.aarnet.edu.au (dhcp096.yarralumla.aarnet.edu.au [192.94.63.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0FD31D587D; Fri, 16 Oct 2009 09:51:12 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 16 Oct 2009 10:51:14 +1100 Message-Id: To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: "John G. Scudder" Subject: [sidr] Agenda for IETF 76 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Oct 2009 23:51:19 -0000 John Scudder has just pointed out to me that I have managed to confuse myself thoroughly over the various IETF 76 deadlines! Thanks John. :-) We evidently have until October 28 to complete the agenda, so the door is still open for agenda items - please let myself and Sandy know if you have anything you want to add to the existing draft agenda. thanks, Geoff co-chair hat ON From kent@bbn.com Fri Oct 16 13:00:02 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 EA10628C0F5 for ; Fri, 16 Oct 2009 13:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_20=-0.74, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ghXds7yi3V1 for ; Fri, 16 Oct 2009 13:00:02 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0D5E13A6893 for ; Fri, 16 Oct 2009 13:00:02 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.242.20.116]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mys1u-0008HY-Fv for sidr@ietf.org; Fri, 16 Oct 2009 15:00:03 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 15 Oct 2009 15:28:35 -0400 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] CRL management options X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 16 Oct 2009 20:00:03 -0000 Folks, At the RIPE meeting in Lisbon last week, there was some discussion about how relying parties (e.g. ISPs) might like to see reason codes used in the CRLs issued in the RPKI. The concern motivating this is a situation in which a CA (e.g., an RIR or an ISP) might be forced to revoke a cert for a customer because of some form of legal pressure, e.g., an effort to shut down a phishing site. The argument is that if an RIR were able to insert a reason code in the CRL entry for such a revocation, an ISP would be able to decide whether to accept or ignore the CRL entry in question. The relevant X,509 and PKIX standards allow for such a capability, but we removed it for the RPKI cert/CRL profile, because we didn't see a need for such codes. The codes can be used on a per-CRL entry basis, so only when a cert is revoked for a reason that the AC elects to note would a code be inserted into the CRL entry for the revoked cert. (As a side note, I made a brief presentation describing how cert validation software for the RPKI could offer RPs various options for dealing with expired and revoked certs, to address similar concerns. These options do not require any changes to the cert/CRL profile, but they also do not offer an automated capability for selective CRL entry processing.) There are some costs associated with offering this option: - we make CRL processing more complex for all relying parties (relative to the current profile). the reason is that if we include this feature as part of the profile, ALL RPs MUST be prepared to process CRLs that make use of the feature. There is no requirement that ANY CA make use of the feature; it would be up to each CA and would be reflected in the CPS for the CA - it is not clear if law enforcement authorities would allow a CA (e.g., an RIR or an ISP) to mark a CRL in this fashion once they understood the potential implication. The CA could cite its CPS as mandating that it follow this procedure, as a defense of the practice, but who knows if this would suffice. - reason codes are defined by an ENUMERATED data type. This means that there is a list of codes, each identified y an integer, and no provision for defining private reason codes. The list was motivated by the financial services industry, so there i no code that matches the notion of "the men in black made me do it." I note that the value "7" has no reason code assigned to it, but to use it for this purpose would be wrong :-). So, before we ask Geoff to modify the Cert/CRL profile to allow for reasons codes, I'd like to get some sense of whether the WG feels this is a reasonable path to follow. Steve From andrei@ripe.net Tue Oct 20 13:50: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 7B7113A69A6 for ; Tue, 20 Oct 2009 13:50:21 -0700 (PDT) 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=[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 VugSG3HUhf-h for ; Tue, 20 Oct 2009 13:50:20 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id 027773A6864 for ; Tue, 20 Oct 2009 13:50:20 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N0Leu-0003QE-On; Tue, 20 Oct 2009 22:50:26 +0200 Received: from eth-0-19-e3-5-73-a4.dhcp.nanog.merit.net (andrei.vpn.ripe.net [193.0.21.36]) by herring.ripe.net (Postfix) with ESMTP id E5F262F583; Tue, 20 Oct 2009 22:50:19 +0200 (CEST) Message-ID: <4ADE228B.50904@ripe.net> Date: Tue, 20 Oct 2009 22:50:19 +0200 From: Andrei Robachevsky User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 4330a47f43bd7e517cd9d6f2bba43afb6245f659a31f26711c5900524866667b Cc: sidr@ietf.org Subject: Re: [sidr] CRL management options X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Oct 2009 20:50:21 -0000 Steve, Stephen Kent wrote on 15-10-2009 21:28: > Folks, > > At the RIPE meeting in Lisbon last week, there was some discussion about > how relying parties (e.g. ISPs) might like to see reason codes used in > the CRLs issued in the RPKI. The concern motivating this is a situation > in which a CA (e.g., an RIR or an ISP) might be forced to revoke a cert > for a customer because of some form of legal pressure, e.g., an effort > to shut down a phishing site. The argument is that if an RIR were able > to insert a reason code in the CRL entry for such a revocation, an ISP > would be able to decide whether to accept or ignore the CRL entry in > question. The relevant X,509 and PKIX standards allow for such a > capability, but we removed it for the RPKI cert/CRL profile, because we > didn't see a need for such codes. The codes can be used on a per-CRL > entry basis, so only when a cert is revoked for a reason that the AC > elects to note would a code be inserted into the CRL entry for the > revoked cert. > I thing such feature may be useful as a general communication capability of a CA to the RPs. Although maybe not exactly as a secret protocol behind the LEAs backs :) However, I don't think we should go ahead and modify the profile, mainly for the reason that we won't be able to get it right at this point in time. I don't think we can create realistic scenarios for usage of this feature, and consistent interpretation of the reason codes is essential (as opposed to per CA/CPS). If we feel that we may not have enough time to introduce this feature when needed, I am fine with reserving this in the profile, but providing no guidance on how to process/interpret it (or rather advise not to process the code). Out of curiosity - how do the reason codes inform the validation process in the conventional PKI? > > (As a side note, I made a brief presentation describing how cert > validation software for the RPKI could offer RPs various options for > dealing with expired and revoked certs, to address similar concerns. > These options do not require any changes to the cert/CRL profile, but > they also do not offer an automated capability for selective CRL entry > processing.) > > There are some costs associated with offering this option: > > - we make CRL processing more complex for all relying parties > (relative to the current profile). the reason is that if we include this > feature as part of the profile, ALL RPs MUST be prepared to process CRLs > that make use of the feature. There is no requirement that ANY CA make > use of the feature; it would be up to each CA and would be reflected in > the CPS for the CA > > - it is not clear if law enforcement authorities would allow a CA > (e.g., an RIR or an ISP) to mark a CRL in this fashion once they > understood the potential implication. The CA could cite its CPS as > mandating that it follow this procedure, as a defense of the practice, > but who knows if this would suffice. > > - reason codes are defined by an ENUMERATED data type. This means > that there is a list of codes, each identified y an integer, and no > provision for defining private reason codes. The list was motivated by > the financial services industry, so there i no code that matches the > notion of "the men in black made me do it." I note that the value "7" > has no reason code assigned to it, but to use it for this purpose would > be wrong :-). > > So, before we ask Geoff to modify the Cert/CRL profile to allow for > reasons codes, I'd like to get some sense of whether the WG feels this > is a reasonable path to follow. > > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr Andrei From root@core3.amsl.com Wed Oct 21 12:30:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 90A0D3A693E; Wed, 21 Oct 2009 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091021193001.90A0D3A693E@core3.amsl.com> Date: Wed, 21 Oct 2009 12:30:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action: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: Wed, 21 Oct 2009 19:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Certificate Policy (CP) for the Resource PKI (RPKI) Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cp-07.txt Pages : 38 Date : 2009-10-21 This document describes the certificate policy for a PKI used to support attestations about Internet resource holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this distribution. These certificates will enable verification that the holder of the associated private key has been allocated the resources indicated in the certificate, and is the current, unique holder of these resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-cp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-21121957.I-D@ietf.org> --NextPart-- From Sandra.Murphy@cobham.com Thu Oct 22 03:07: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 EDB8D3A68A5 for ; Thu, 22 Oct 2009 03:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2OffXIGvplS for ; Thu, 22 Oct 2009 03:07:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1CA113A62C1 for ; Thu, 22 Oct 2009 03:07:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9MA7Wf9001526 for ; Thu, 22 Oct 2009 05:07:32 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9MA7WHs023378 for ; Thu, 22 Oct 2009 05:07:32 -0500 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); Thu, 22 Oct 2009 06:07:30 -0400 Date: Thu, 22 Oct 2009 06:07:27 -0400 (Eastern Daylight 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: 22 Oct 2009 10:07:32.0104 (UTC) FILETIME=[783F6880:01CA52FF] Subject: [sidr] remaining important dates X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 22 Oct 2009 10:07:25 -0000 There are a few important dates approaching for the upcoming IETF meeting: In particular, let the chairs know if you would like time on the agenda (first draft due next Wednesday). 2009-10-26 (Monday): Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT) 2009-10-28 (Wednesday): Draft Working Group agendas due by 17:00 PDT (24:00 UTC/GMT) 2009-10-30 (Friday): Early Bird registration and payment cut-off at 17:00 PDT (24:00 UTC/GMT) 2009-11-02 (Monday): Revised Working Group agendas due by 17:00 PST (01:00 Tuesday, November 3 UTC/GMT) 2009-11-02 (Monday): Registration cancellation cut-off at 17:00 PST (01:00 Tuesday, November 3 UTC/GMT) 2009-11-06 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local Hiroshima time (00:00 PST, 08:00 UTC/GMT) --Sandy From Sandra.Murphy@cobham.com Thu Oct 22 12:23: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 A720028C1A7 for ; Thu, 22 Oct 2009 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21vsFJMSn54R for ; Thu, 22 Oct 2009 12:23:20 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3DAB628C1A6 for ; Thu, 22 Oct 2009 12:23:20 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9MJNRvc010264 for ; Thu, 22 Oct 2009 14:23:27 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9MJNRpR013942 for ; Thu, 22 Oct 2009 14:23:27 -0500 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); Thu, 22 Oct 2009 15:23:27 -0400 Date: Thu, 22 Oct 2009 15:23:25 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 22 Oct 2009 19:23:27.0239 (UTC) FILETIME=[21751970:01CA534D] Subject: Re: [sidr] remaining important dates X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 22 Oct 2009 19:23:21 -0000 I seem to have confused folks. Geoff did already solicit agenda items and posted a draft agenda. I'm doing the nagging remind-everyone thing of all deadline dates. A draft agenda is posted. But there is still time to get a slot on the agenda if you want one. The agenda deadlines have not passed. And there are other deadlines below as well to pay attention to. --Sandy On Thu, 22 Oct 2009, Sandra Murphy wrote: > There are a few important dates approaching for the upcoming IETF meeting: > > In particular, let the chairs know if you would like time on the agenda > (first draft due next Wednesday). > > 2009-10-26 (Monday): Internet Draft final submission cut-off by 17:00 PDT > (24:00 UTC/GMT) > > 2009-10-28 (Wednesday): Draft Working Group agendas due by 17:00 PDT (24:00 > UTC/GMT) > > 2009-10-30 (Friday): Early Bird registration and payment cut-off at 17:00 PDT > (24:00 UTC/GMT) > > 2009-11-02 (Monday): Revised Working Group agendas due by 17:00 PST (01:00 > Tuesday, November 3 UTC/GMT) > > 2009-11-02 (Monday): Registration cancellation cut-off at 17:00 PST (01:00 > Tuesday, November 3 UTC/GMT) > > 2009-11-06 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 > local Hiroshima time (00:00 PST, 08:00 UTC/GMT) > > > > > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From weiler@watson.org Thu Oct 22 23:48: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 67EF13A69AA for ; Thu, 22 Oct 2009 23:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 gTuQS8vC+kiT for ; Thu, 22 Oct 2009 23:48:20 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 90DCC3A69A3 for ; Thu, 22 Oct 2009 23:48:20 -0700 (PDT) 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 n9N6mSJE078703; Fri, 23 Oct 2009 02:48:28 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n9N6mSFm078699; Fri, 23 Oct 2009 02:48:28 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 23 Oct 2009 02:48:28 -0400 (EDT) From: Samuel Weiler To: "Pradosh Mohapatra (pmohapat)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5434D742@xmb-sjc-215.amer.cisco.com> Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D5434D742@xmb-sjc-215.amer.cisco.com> 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.0.1 (fledge.watson.org [127.0.0.1]); Fri, 23 Oct 2009 02:48:28 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] FYI: I-D Action:draft-pmohapat-sidr-pfx-validate-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 06:48:21 -0000 Comments on this draft: In section 2, "covering" and "matching" are used without definition. What do YOU mean by covering in this context? In the document, please define or cite a definition. In section 5, repeat the informative reference to [I-D.ymbk-rpki-rtr-protocol] as a suggested protocol. How does the route preference (preferring "valid" over "not found" over "invalid") interact with the preference for the longest prefix? If I have an invalid /16, does it still take precedence over a valid /8? (That may be another way of getting at the problems discussed in the thread about this doc in November 2008.) -- Sam From weiler@watson.org Fri Oct 23 11:25: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 AD09B3A6972 for ; Fri, 23 Oct 2009 11:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCs4p13Nczog for ; Fri, 23 Oct 2009 11:25:18 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id E768D3A696B for ; Fri, 23 Oct 2009 11:25:17 -0700 (PDT) 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 n9NIPQM1068403; Fri, 23 Oct 2009 14:25:26 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n9NIPQ4k068399; Fri, 23 Oct 2009 14:25:26 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 23 Oct 2009 14:25:26 -0400 (EDT) From: Samuel Weiler To: "Pradosh Mohapatra (pmohapat)" , Rachel Albright , standards-ipr@cisco.com In-Reply-To: Message-ID: References: <04CAD96D4C5A3D48B1919248A8FE0D5434D742@xmb-sjc-215.amer.cisco.com> 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.0.1 (fledge.watson.org [127.0.0.1]); Fri, 23 Oct 2009 14:25:26 -0400 (EDT) Cc: sidr@ietf.org Subject: [sidr] IPR claims on draft-pmohapat-sidr-pfx-validate-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:25:18 -0000 Could you be more specific about which parts of the above draft are being claimed as IPR? Would that IPR claim also apply to draft-ietf-sidr-roa-validation-03? -- Sam From weiler@watson.org Fri Oct 23 11:59: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 1E0643A6856 for ; Fri, 23 Oct 2009 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 Z1lZN1s0AYCb for ; Fri, 23 Oct 2009 11:59:52 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 2D0033A6986 for ; Fri, 23 Oct 2009 11:59:52 -0700 (PDT) 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 n9NIwJTo073309; Fri, 23 Oct 2009 14:58:19 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n9NIwJvf073306; Fri, 23 Oct 2009 14:58:19 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 23 Oct 2009 14:58:19 -0400 (EDT) From: Samuel Weiler To: Terry Manderson 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.0.1 (fledge.watson.org [127.0.0.1]); Fri, 23 Oct 2009 14:58:19 -0400 (EDT) Cc: "sidr@ietf.org" Subject: Re: [sidr] Use cases for RPKI in SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:59:53 -0000 On Mon, 15 Jun 2009, Terry Manderson wrote: > This might then be used by the WG and authors of other drafts to ask > questions pertaining to the completeness, direction, and applicability of > the work from a clear use case basis. ... > The draft is attached for your review, and the authors and I would be most > appreciative if you could read this document and either before, or at, IETF > 75 provide your comments. This document is a useful contribution. My hope is that we will use this document as a template to generate examples of how to satisfy each use given a set of validation rules. From that, we can see if the validation rules (and the artitecture generally) let us satisfy the full set of cases we care about. For the RPKI, sections 3 and 5 are useful. I have basically ignored section 4. On to the specifics: Observation: Most of the Section 3 cases speak about which routes one wishes to have accepted (or chosen) and make no explicit statement about which routes one wants to have rejected. I think it would be useful to include such statements, perhaps as "attack" case. This may result in an effectively two-dimensional table of cases. I believe the "partial deployment use cases" of section 5 are critical to the success of the RPKI, and I think the set of cases here is too limited. For instance, a variation on 5.1 ("parent does not do RPKI") is "other upstream(s) don't do RPKI". Perhaps we could generate these by going through the section 3 cases and, for each one, add the permutations of which parties do and don't support the RPKI. Sadly, when combined with the above, that could give us a three dimensional space to work in, but most of the section 3 cases involve only one party, so the problem should be tractable. Perhaps some of this expansion could be rolled into the next revision. -- Sam From sra@hactrn.net Fri Oct 23 12:03: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 DEB6E3A6856 for ; Fri, 23 Oct 2009 12:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-QNSFSe2PjK for ; Fri, 23 Oct 2009 12:03:44 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id E52623A682F for ; Fri, 23 Oct 2009 12:03:43 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 19D252844F; Fri, 23 Oct 2009 19:03:54 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C275122807; Fri, 23 Oct 2009 15:03:53 -0400 (EDT) Date: Fri, 23 Oct 2009 15:03:53 -0400 From: Rob Austein To: Stephen Kent 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: <20091023190353.C275122807@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] CRL management options X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 23 Oct 2009 19:03:45 -0000 At Thu, 15 Oct 2009 15:28:35 -0400, Steve Kent wrote: > ... > There are some costs associated with offering this option: Another issue besides the one you listed: reason codes would further complicate the software that has to generate all the certificates and ROAs, perhaps significantly (haven't analyzed in detail yet). Right now, we revoke certificates when resources shrink, when we're rolling keys and want to kill off any certificates signed by the old one, or when a child entity goes away. The last case most closely corresponds to the hypothetical situation in which you might want to use these reason codes, but note that reason codes would change the requirements: one would have to keep a tombstone for children that have gone away, so that you know why, so that you know whether to use a reason code and, if so what reason code to use. Given this and the other problems you listed, I do not think it would be productive to extend the CRL profile to allow reason codes, at least not at this time. I can see revisiting the issue after we have some operational experience, but I see little value in opening this can of worms at this time. From pmohapat@cisco.com Fri Oct 23 14:09: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 CF6523A68C0 for ; Fri, 23 Oct 2009 14:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4B5zAddbumM for ; Fri, 23 Oct 2009 14:09:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 14A0C3A6851 for ; Fri, 23 Oct 2009 14:09:29 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEu44UqrRN+K/2dsb2JhbADCJ5gvhD8E X-IronPort-AV: E=Sophos;i="4.44,614,1249257600"; d="scan'208";a="198650732" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 23 Oct 2009 21:09:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9NL9eZN001501; Fri, 23 Oct 2009 21:09:40 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 14:09:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2009 14:09:38 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A7930AE@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] FYI: I-D Action:draft-pmohapat-sidr-pfx-validate-02.txt Thread-Index: AcpTrNTvB8QhspHuTUCJOIBRLo8HagAcy+wg References: <04CAD96D4C5A3D48B1919248A8FE0D5434D742@xmb-sjc-215.amer.cisco.com> From: "Pradosh Mohapatra (pmohapat)" To: "Samuel Weiler" X-OriginalArrivalTime: 23 Oct 2009 21:09:40.0016 (UTC) FILETIME=[22577300:01CA5425] Cc: sidr@ietf.org Subject: Re: [sidr] FYI: I-D Action:draft-pmohapat-sidr-pfx-validate-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 21:09:29 -0000 Hi Sam, | In section 2, "covering" and "matching" are used without definition. | What do YOU mean by covering in this context? In the document, please | define or cite a definition. |=20 | In section 5, repeat the informative reference to | [I-D.ymbk-rpki-rtr-protocol] as a suggested protocol. Ack on both of these. I am updating the draft to issue a new version as we speak and will take care of these. | How does the route preference (preferring "valid" over "not found" | over "invalid") interact with the preference for the longest prefix? | If I have an invalid /16, does it still take precedence over a valid | /8? (That may be another way of getting at the problems discussed in | the thread about this doc in November 2008.) Yes. And my answer is going to be the same ;-) The /16 and /8 are different routes/paths and the validity state is determined separately. If all the paths for the /16 route on a router are invalid, the route itself is not going to be present in forwarding (barring knobs of course). In that case, yes, the /8 route will be effective for all traffic that would have otherwise matched the /16. - Pradosh From terry.manderson@icann.org Sat Oct 24 04:12:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1BA3A6807 for ; Sat, 24 Oct 2009 04:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TehlcYeqOGEB for ; Sat, 24 Oct 2009 04:12:39 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 1142B3A67CF for ; Sat, 24 Oct 2009 04:12:39 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Sat, 24 Oct 2009 04:12:50 -0700 From: Terry Manderson To: Samuel Weiler Date: Sat, 24 Oct 2009 04:12:47 -0700 Thread-Topic: [sidr] Use cases for RPKI in SIDR Thread-Index: AcpUGDqsnB3htJOZQumBP/Uclus8WwAgq/cg 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] Use cases for RPKI in SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 11:12:40 -0000 Hi Sam, On 24/10/09 4:58 AM, "Samuel Weiler" wrote: > On Mon, 15 Jun 2009, Terry Manderson wrote: >=20 >=20 >=20 > For the RPKI, sections 3 and 5 are useful. I have basically ignored > section 4. >=20 > On to the specifics: >=20 > Observation: Most of the Section 3 cases speak about which routes one > wishes to have accepted (or chosen) and make no explicit statement > about which routes one wants to have rejected. I think it would be > useful to include such statements, perhaps as "attack" case. This may > result in an effectively two-dimensional table of cases. >=20 That will be covered in -02, Just waiting on convergence with my co-authors= . I expect to upload before the deadline. > I believe the "partial deployment use cases" of section 5 are critical > to the success of the RPKI, and I think the set of cases here is too > limited. For instance, a variation on 5.1 ("parent does not do RPKI") > is "other upstream(s) don't do RPKI". Perhaps we could generate these > by going through the section 3 cases and, for each one, add the > permutations of which parties do and don't support the RPKI. Sadly, > when combined with the above, that could give us a three dimensional > space to work in, but most of the section 3 cases involve only one > party, so the problem should be tractable. yes.. there is some expansion needed and I don't think _all of it_ will mak= e it to -02. If you take a look at the origin maps at http://stats.research.icann.org/bgp/ and then arbitrarily pick a start poin= t (AS) for RPKI deployment - the permutations swings wildly on what outcome you might allow for route validity.. For example do you want 8.6.241.0/24 to be a valid route table entry if AS3356 only creates a ROA for 8.0.0.0/8? (refer to the origin map) in partial deployment? So I have been purposefully parsimonious in -02 in that section. >=20 > Perhaps some of this expansion could be rolled into the next revision. >=20 Cheers Terry From mlepinski@bbn.com Mon Oct 26 14:38: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 E94C728C189 for ; Mon, 26 Oct 2009 14:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niUTyePGHpHd for ; Mon, 26 Oct 2009 14:38:49 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3A9A428C183 for ; Mon, 26 Oct 2009 14:38:49 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1N2XHJ-0006jk-C8 for sidr@ietf.org; Mon, 26 Oct 2009 17:39:01 -0400 Received: from [128.89.255.39] (helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N2XHJ-0000i1-Hf for sidr@ietf.org; Mon, 26 Oct 2009 17:39:01 -0400 Message-ID: <4AE6160D.8000503@bbn.com> Date: Mon, 26 Oct 2009 17:35:09 -0400 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: "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Updates: sidr-arch-09 and roa-format-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 26 Oct 2009 21:38:50 -0000 I have just submitted updates to draft-ietf-sidr-arch and draft-ietf-roa-format The only substanative change to the roa-format draft was to reference the algorithm and key size specifications in draft-ietf-sidr-rpki-algs (as is currently done in the rpki-manifests document). The only substanative change to the architecture draft was to incorporate a suggestion from Randy Bush that entities who are actually using RPKI data for routing SHOULD be fetching fresh data from the repositories at least once every three hours. Additionally, I made a number of very small edits (i.e., bug fixes) to both documents. Thanks to Larry Blunk, Roque Gagliano, Charlie Gardner and Randy Bush for helpful comments and reviews. Both of these drafts appear to be quite stable and I know of no open issues in either document. From root@core3.amsl.com Mon Oct 26 14:45:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C255F3A681E; Mon, 26 Oct 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026214501.C255F3A681E@core3.amsl.com> Date: Mon, 26 Oct 2009 14:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action: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, 26 Oct 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Route Origin Authorizations (ROAs) Author(s) : M. Lepinski, et al. Filename : draft-ietf-sidr-roa-format-06.txt Pages : 14 Date : 2009-10-26 This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26143853.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 14:45:01 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D7B6928C173; Mon, 26 Oct 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026214501.D7B6928C173@core3.amsl.com> Date: Mon, 26 Oct 2009 14:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action: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, 26 Oct 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : An Infrastructure to Support Secure Internet Routing Author(s) : M. Lepinski, S. Kent Filename : draft-ietf-sidr-arch-09.txt Pages : 24 Date : 2009-10-26 This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; and a distributed repository system for storing and disseminating the data objects that comprise the PKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-arch-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26143900.I-D@ietf.org> --NextPart-- From gih@apnic.net Mon Oct 26 16:24: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 3A5EF3A69D0 for ; Mon, 26 Oct 2009 16:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcORJTT5oR2h for ; Mon, 26 Oct 2009 16:24:14 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id B5A913A69CF for ; Mon, 26 Oct 2009 16:24:13 -0700 (PDT) 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 406B9D58BE; Tue, 27 Oct 2009 09:25:23 +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: <4AE6160D.8000503@bbn.com> Date: Tue, 27 Oct 2009 10:24:24 +1100 Content-Transfer-Encoding: 7bit Message-Id: <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> References: <4AE6160D.8000503@bbn.com> To: Matt Lepinski X-Mailer: Apple Mail (2.1076) Cc: "sidr@ietf.org" Subject: [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: Mon, 26 Oct 2009 23:24:15 -0000 WG Co-Chair Hat OFF Hi Matt, > entities who are actually using RPKI data for routing SHOULD be > fetching fresh data from the repositories at least once every three > hours. > 3 hours? At a first pass that seems very frequent. From a server's perspective if there are 30,000 AS's out there and each is running a local cache and each is a distinct relying party of the RPKI system, then the local hit rate at the server would be 3 per second, assuming that all the relying parties evenly spread their load (which is a pretty wild assumption - the worst case is that all 30,000 attempt to resync at the 3 hour clock chime point) Assuming that a repository sweep with no updates takes 30 seconds to complete then the server would have an average load of some 90 concurrent sync sessions. If there is a local rekey then the refresh would also imply a reload of all the signed products at this repository publication point. Assuming that this would then take 3 minutes to download, then the rekey load per server would be of the order of 540 concurrent rsync sessions as an average load. These load numbers appear to me to be somewhat large. From the relying party's perspective if there are 30,000 distinct RPKI repository publication points, and a serial form of local synchronisation using a top-down tree walk then the same set of assumptions imply that the relying party's perspective then it needs to process the synchronisation with the remote cache (including minimally the manifest crypto calculation at a rate of 3 per second. Assuming that there are 200,000 distinct ROAs out there that are re- validated at each fetch then once more the numbers imply that a 3 hour refresh would infer that the relying party would need to validate 200,000 ROAS in 10,800 seconds. That probably needs some pretty quick hardware. These numbers are pretty much a toss at a dart board, and the draft's authors' may well be using a different scale model to justify this recommended time cycle. What numbers did you have in mind Matt that would make this "SHOULD" 3 hour refresh cycle feasible in a big-I Internet scenario of universal use? Geoff WG Co-Chair hat off From Sandra.Murphy@cobham.com Mon Oct 26 16:52: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 C738328C43C for ; Mon, 26 Oct 2009 16:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZRB+bE3m1uu for ; Mon, 26 Oct 2009 16:52:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A30BA3A695F for ; Mon, 26 Oct 2009 16:52:57 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9QNqvkc029276; Mon, 26 Oct 2009 18:52:58 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9QNqvwv006472; Mon, 26 Oct 2009 18:52:57 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 19:52:57 -0400 Date: Mon, 26 Oct 2009 19:52:57 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> Message-ID: References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@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: 26 Oct 2009 23:52:57.0306 (UTC) FILETIME=[713883A0:01CA5697] 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: Mon, 26 Oct 2009 23:52:58 -0000 Geoff, I thought the reason for using (and mandating) rsync was precisely to avoid re-load of the whole data space on each synchronization. If so, what estimates would you use of how much of the space would be new (what Matt calls "fresh") data at each synchronization time point? --Sandy (This is a clarification query, which might be viewed as co-chair hat on or member hat on, or both, your choice.) On Tue, 27 Oct 2009, Geoff Huston wrote: > WG Co-Chair Hat OFF > > Hi Matt, > > > >> entities who are actually using RPKI data for routing SHOULD be fetching >> fresh data from the repositories at least once every three hours. >> > > 3 hours? > > At a first pass that seems very frequent. > > From a server's perspective if there are 30,000 AS's out there and each is > running a local cache and each is a distinct relying party of the RPKI > system, then the local hit rate at the server would be 3 per second, assuming > that all the relying parties evenly spread their load (which is a pretty wild > assumption - the worst case is that all 30,000 attempt to resync at the 3 > hour clock chime point) Assuming that a repository sweep with no updates > takes 30 seconds to complete then the server would have an average load of > some 90 concurrent sync sessions. If there is a local rekey then the refresh > would also imply a reload of all the signed products at this repository > publication point. Assuming that this would then take 3 minutes to download, > then the rekey load per server would be of the order of 540 concurrent rsync > sessions as an average load. These load numbers appear to me to be somewhat > large. > > From the relying party's perspective if there are 30,000 distinct RPKI > repository publication points, and a serial form of local synchronisation > using a top-down tree walk then the same set of assumptions imply that the > relying party's perspective then it needs to process the synchronisation with > the remote cache (including minimally the manifest crypto calculation at a > rate of 3 per second. Assuming that there are 200,000 distinct ROAs out there > that are re-validated at each fetch then once more the numbers imply that a 3 > hour refresh would infer that the relying party would need to validate > 200,000 ROAS in 10,800 seconds. That probably needs some pretty quick > hardware. > > These numbers are pretty much a toss at a dart board, and the draft's > authors' may well be using a different scale model to justify this > recommended time cycle. What numbers did you have in mind Matt that would > make this "SHOULD" 3 hour refresh cycle feasible in a big-I Internet scenario > of universal use? > > > Geoff > > WG Co-Chair hat off > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Mon Oct 26 21:07: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 B62FB3A680E for ; Mon, 26 Oct 2009 21:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qecs77iapPPJ for ; Mon, 26 Oct 2009 21:07:36 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 1693C3A6804 for ; Mon, 26 Oct 2009 21:07:36 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 26 Oct 2009 21:07:50 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Mon, 26 Oct 2009 21:07:48 -0700 Thread-Topic: New version of draft-manderson-sidr-usecases Thread-Index: AcpWuwsvjRWxEFTaLE+1dtm3EnsYyg== Message-ID: 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: [sidr] New version of draft-manderson-sidr-usecases X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 04:07:36 -0000 WG,=20 An update to draft-manderson-sidr-usecases has been uploaded, you will find the text here: http://tools.ietf.org/id/draft-manderson-sidr-usecases-01.tx= t This version is on the agenda for discussion in Hiroshima. Thanks to all who have read, reviewed, and provided feedback on the -00 version. Cheers Terry From terry.manderson@icann.org Mon Oct 26 21:40: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 470903A6924 for ; Mon, 26 Oct 2009 21:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuQY6nTV1dvt for ; Mon, 26 Oct 2009 21:40:07 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 3D58F3A684D for ; Mon, 26 Oct 2009 21:40:07 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 26 Oct 2009 21:40:21 -0700 From: Terry Manderson To: Sandra Murphy , Geoff Huston Date: Mon, 26 Oct 2009 21:40:19 -0700 Thread-Topic: [sidr] sidr-arch-09 refresh cycle time Thread-Index: AcpWl63W7xl4U1ubQK+c8fyDWRgP2wAJ+g+R 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] 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: Tue, 27 Oct 2009 04:40:09 -0000 On 27/10/09 9:52 AM, "Sandra Murphy" wrote: > Geoff, I thought the reason for using (and mandating) rsync was precisely > to avoid re-load of the whole data space on each synchronization. The same thing can be achieved with manifests and any download protocol would suffice. (one might also hope that the download protocol provides a reasonable protection from MiTM attacks (sorry, I digress) ;) >=20 > If so, what estimates would you use of how much of the space would be new > (what Matt calls "fresh") data at each synchronization time point? Wouldn't that depend on the frequency of change & publication adopted by th= e issuing CA in its CPS, and indeed how much change is expected at that CA? This, I think, is a really fuzzy area - a more frequent time looks like a nicer 'catch-all' for aspects of CA cycles or local time-zone differences o= f (say) midnight. However, I feel less than convinced that specifying an actual frequency is warranted. My recommendation would be for the relying party to assess it's own fetch cycle time on how it wishes for RPKI adjustments to affect its own routing system. Regardless of the adopted cycle time, the repositories are just going to have to scale to meet it, be that 24hrs, 12hrs, 3hrs, or 30 mins (in the extreme). Cheers Terry >=20 > --Sandy >=20 > (This is a clarification query, which might be viewed as co-chair hat on > or member hat on, or both, your choice.) >=20 > On Tue, 27 Oct 2009, Geoff Huston wrote: >=20 >> WG Co-Chair Hat OFF >>=20 >> Hi Matt, >>=20 >>=20 >>=20 >>> entities who are actually using RPKI data for routing SHOULD be fetchin= g >>> fresh data from the repositories at least once every three hours. >>>=20 >>=20 >> 3 hours? >>=20 >> At a first pass that seems very frequent. >>=20 >> From a server's perspective if there are 30,000 AS's out there and each = is >> running a local cache and each is a distinct relying party of the RPKI >> system, then the local hit rate at the server would be 3 per second, ass= uming >> that all the relying parties evenly spread their load (which is a pretty= wild >> assumption - the worst case is that all 30,000 attempt to resync at the = 3 >> hour clock chime point) Assuming that a repository sweep with no updates >> takes 30 seconds to complete then the server would have an average load = of >> some 90 concurrent sync sessions. If there is a local rekey then the ref= resh >> would also imply a reload of all the signed products at this repository >> publication point. Assuming that this would then take 3 minutes to downl= oad, >> then the rekey load per server would be of the order of 540 concurrent r= sync >> sessions as an average load. These load numbers appear to me to be somew= hat >> large. >>=20 >> From the relying party's perspective if there are 30,000 distinct RPKI >> repository publication points, and a serial form of local synchronisatio= n >> using a top-down tree walk then the same set of assumptions imply that t= he >> relying party's perspective then it needs to process the synchronisation= with >> the remote cache (including minimally the manifest crypto calculation at= a >> rate of 3 per second. Assuming that there are 200,000 distinct ROAs out = there >> that are re-validated at each fetch then once more the numbers imply tha= t a 3 >> hour refresh would infer that the relying party would need to validate >> 200,000 ROAS in 10,800 seconds. That probably needs some pretty quick >> hardware. >>=20 >> These numbers are pretty much a toss at a dart board, and the draft's >> authors' may well be using a different scale model to justify this >> recommended time cycle. What numbers did you have in mind Matt that woul= d >> make this "SHOULD" 3 hour refresh cycle feasible in a big-I Internet sce= nario >> of universal use? >>=20 >>=20 >> Geoff >>=20 >> WG Co-Chair hat off >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 Mon Oct 26 22: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 6725A3A6852 for ; Mon, 26 Oct 2009 22:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFd+mdSZew2h for ; Mon, 26 Oct 2009 22:04:36 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 53DD73A67F2 for ; Mon, 26 Oct 2009 22:04:21 -0700 (PDT) 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 EF572D58C7; Tue, 27 Oct 2009 15:05:30 +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, 27 Oct 2009 16:04:31 +1100 Content-Transfer-Encoding: 7bit Message-Id: <9C62872D-10E3-418F-AA0B-0AAB19D82D4B@apnic.net> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1076) 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: Tue, 27 Oct 2009 05:04:37 -0000 WG Chair Hat Off On 27/10/2009, at 10:52 AM, Sandra Murphy wrote: > Geoff, I thought the reason for using (and mandating) rsync was > precisely to avoid re-load of the whole data space on each > synchronization. I thought so too. > > If so, what estimates would you use of how much of the space would > be new (what Matt calls "fresh") data at each synchronization time > point? > The numbers I guessed at below assumed rsync-like behaviour. An alternative approach would be based on a relying party retrieving the manifest of the publication point and performing the comparison of the local store state with the repository based on the manifest data. At the level of approximation I was using to query this suggested refresh frequency I do not think that it would make very much difference to the load guesstimates. Geoff (This is a clarification response, which is not made in my role as a co-chair.) > --Sandy > > (This is a clarification query, which might be viewed as co-chair > hat on or member hat on, or both, your choice.) > > On Tue, 27 Oct 2009, Geoff Huston wrote: > >> WG Co-Chair Hat OFF >> >> Hi Matt, >> >> >> >>> entities who are actually using RPKI data for routing SHOULD be >>> fetching fresh data from the repositories at least once every >>> three hours. >> >> 3 hours? >> >> At a first pass that seems very frequent. >> >> From a server's perspective if there are 30,000 AS's out there and >> each is running a local cache and each is a distinct relying party >> of the RPKI system, then the local hit rate at the server would be >> 3 per second, assuming that all the relying parties evenly spread >> their load (which is a pretty wild assumption - the worst case is >> that all 30,000 attempt to resync at the 3 hour clock chime point) >> Assuming that a repository sweep with no updates takes 30 seconds >> to complete then the server would have an average load of some 90 >> concurrent sync sessions. If there is a local rekey then the >> refresh would also imply a reload of all the signed products at >> this repository publication point. Assuming that this would then >> take 3 minutes to download, then the rekey load per server would be >> of the order of 540 concurrent rsync sessions as an average load. >> These load numbers appear to me to be somewhat large. >> >> From the relying party's perspective if there are 30,000 distinct >> RPKI repository publication points, and a serial form of local >> synchronisation using a top-down tree walk then the same set of >> assumptions imply that the relying party's perspective then it >> needs to process the synchronisation with the remote cache >> (including minimally the manifest crypto calculation at a rate of 3 >> per second. Assuming that there are 200,000 distinct ROAs out there >> that are re-validated at each fetch then once more the numbers >> imply that a 3 hour refresh would infer that the relying party >> would need to validate 200,000 ROAS in 10,800 seconds. That >> probably needs some pretty quick hardware. >> >> These numbers are pretty much a toss at a dart board, and the >> draft's authors' may well be using a different scale model to >> justify this recommended time cycle. What numbers did you have in >> mind Matt that would make this "SHOULD" 3 hour refresh cycle >> feasible in a big-I Internet scenario of universal use? >> >> >> Geoff >> >> WG Co-Chair hat off >> >> >> >> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr From robertl@apnic.net Mon Oct 26 23:06: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 6066E3A6887 for ; Mon, 26 Oct 2009 23:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.684 X-Spam-Level: * X-Spam-Status: No, score=1.684 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 Au3UwlsMK-Un for ; Mon, 26 Oct 2009 23:06:11 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C81153A687D for ; Mon, 26 Oct 2009 23:06:10 -0700 (PDT) Received: from [203.119.42.207] (dynamic207.apnic.net [203.119.42.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 03CDFD58C8; Tue, 27 Oct 2009 16:07:21 +1000 (EST) Message-ID: <4AE68DDD.4020403@apnic.net> Date: Tue, 27 Oct 2009 16:06:21 +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: Terry Manderson 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: "" 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: Tue, 27 Oct 2009 06:06:12 -0000 > Regardless of the adopted cycle time, the repositories are just going to > have to scale to meet it, be that 24hrs, 12hrs, 3hrs, or 30 mins (in the > extreme). ... and there will always be jokers who put * * * * * in their crontab and run it every minute... However, if the suggested best practice (and the default installed by relying party tools) is 12 hours, say, then a large percentage of installations will be using 12 hours, because people don't bother to change defaults. 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 mlepinski@bbn.com Tue Oct 27 13:32:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6E028C158 for ; Tue, 27 Oct 2009 13:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DbDVQIMGaaq for ; Tue, 27 Oct 2009 13:32:38 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CCDC728C146 for ; Tue, 27 Oct 2009 13:32:37 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1N2sip-0000bt-At; Tue, 27 Oct 2009 16:32:51 -0400 Received: from [128.89.255.77] (helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N2sip-00077M-47; Tue, 27 Oct 2009 16:32:51 -0400 Message-ID: <4AE75809.4050808@bbn.com> Date: Tue, 27 Oct 2009 16:28:57 -0400 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: Geoff Huston References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> In-Reply-To: <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> 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: Tue, 27 Oct 2009 20:32:39 -0000 Geoff, I'm happy to accept that the new wording is poor, but I'm pretty sure the old wording was also bad, and I think this discussion is important. The old wording could easily be interpreted to suggest that once per day was the correct frequency for pulling from a repository. (That is, I believe the previous version was making a de facto recommendation for a default behaivor of one pull every 24 hours ... there wasn't a RECOMMEND in the text, but we all know that examples tend to be normative in this type of document.) 1) So the first implicit question is: Should the working group be making a recommendation as to the frequency with which a relying party pulls from the repository? Or equivalently: Is there a "wrong" frequency that people might use if we didn't give them any guidence? It seems that retreiving updates "too frequently" (e.g., every 5 minutes) strains the repository system and that retreiving updates "too infrequently" (e.g., monthly) means that when I inject a new ROA into the system, it will take "unacceptably long" for this information to propogate to the relying parties that make use of this information. Therefore, we should have text in the document that articulates some middle ground that we believe is reasonable for the Internet. (I make no claims that the current text in the document achieves this goal.) 2) The second question is: If we make a recommendation regarding frequency with which relying parties should pull updates, what frequency should we recommend. 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. I agree that there are roughly 30,000 AS numbers visible in BGP, so it's reasonable to assume on the order of 30,000 relying parties who will be routinely querying the repository system. We might also assume that 30,000 is a reasonable order of magnitude for the number of CAs in the RPKI (we might easily average 2 CAs per AS, but surely not 10 CAs per AS). However, one thing that wasn't clear from reading your analysis was how many CAs a given repository server would be hosting. If a server run by a large ISP or an RIR was providing a cache of all RPKI data, then clients would have longer connections to this server (as they could retrieve much of the data they need in one place), but they would be unlikely to receive requests from all 30,000 relying parties (e.g. an ISP might provide a complete cache for their customers but for non-customers they would typically only serve data for which they are authoritative). Alternatively, if a server is only serving data for a small subset of the CAs in the RPKI, then it might receive requests from all relying parties, but those sessions would tend to be short (especially when nothing has changed). In any case, I believe the way forward (with regards to server load) is to answer the question, "How many simultaneous connections are reasonable for a server that hosts publication points for X CAs?" and then work backwards from there to determine if a given interval of relying party requests is reasonable from the server standpoint. I admit that I haven't completely thought through re-key, but I'll try to dig up some rough connection-time numbers based on our relying party software, and do a few back-of-the envolope computations. With regards to client load, I'm not convinced that there's any problem with frequent queries to the repository system. If the relying party queries a publication point and rsync determines that nothing has changed, then no changes are required to ethe relying party's local cache and no cryptographic calculations are required. If something has changed, then the relying party has to perform validation (which includes cryptographic signature verification) on the manifest and any new objects that have been added. (Additionally, there may be resulting changes to the client's local cache ... e.g., if a new CRL revokes a previously valid certificate ... but such changes don't require new cryptographic computations, and so I believe the bottleneck is going to be the one or two signature verifications per object changed [1]). Now the point from the relying party side is that if 5,000 manifests change and 10,000 signed objects are added to the repository system on a given day, then the relying party needs to do roughly 30,000 signature verifications regardless of whether it learns of all these changes at once, or whether it learns of them in small batches throughout the course of the day. Therefore, I don't see how making frequent checks for new data has a significant impact on the relying party's processing load. Finally, in addition to server and relying party processing loads, one must also look at the benefit of frequent repository fetches. Keep in mind, that a relying party has no way of distinguishing the following two events: (A) a route advertisement is originated by an AS that is authorized to advertise the route, but the relying party hasn't fetched recently enough to obtain the new ROA; and (B) a route advertisement is originated by an unauthorized entity that is attempting to hijack address space. In this discussion, it is also important to note that manifests can gaurantee that the relying party received all signed objects that existed at the moment that the manifest was published (i.e., a manifest can detect malicious deletion of data from a repository or corruption of data in transit) but the manifest says nothing about data that may have been added since the manifest was issued. This is why there is benefit in a relying party going back to the publication point perioidically to see whether a new manifest has been issued. In any case, it's good to know that we'll have plenty to talk about in Hiroshima. - Matt Lepinski Geoff Huston wrote: > WG Co-Chair Hat OFF > > Hi Matt, > > > >> entities who are actually using RPKI data for routing SHOULD be >> fetching fresh data from the repositories at least once every three >> hours. >> > > 3 hours? > > At a first pass that seems very frequent. > > From a server's perspective if there are 30,000 AS's out there and > each is running a local cache and each is a distinct relying party of > the RPKI system, then the local hit rate at the server would be 3 per > second, assuming that all the relying parties evenly spread their > load (which is a pretty wild assumption - the worst case is that all > 30,000 attempt to resync at the 3 hour clock chime point) Assuming > that a repository sweep with no updates takes 30 seconds to complete > then the server would have an average load of some 90 concurrent sync > sessions. If there is a local rekey then the refresh would also imply > a reload of all the signed products at this repository publication > point. Assuming that this would then take 3 minutes to download, then > the rekey load per server would be of the order of 540 concurrent > rsync sessions as an average load. These load numbers appear to me to > be somewhat large. > > From the relying party's perspective if there are 30,000 distinct > RPKI repository publication points, and a serial form of local > synchronisation using a top-down tree walk then the same set of > assumptions imply that the relying party's perspective then it needs > to process the synchronisation with the remote cache (including > minimally the manifest crypto calculation at a rate of 3 per second. > Assuming that there are 200,000 distinct ROAs out there that are re- > validated at each fetch then once more the numbers imply that a 3 > hour refresh would infer that the relying party would need to > validate 200,000 ROAS in 10,800 seconds. That probably needs some > pretty quick hardware. > > These numbers are pretty much a toss at a dart board, and the draft's > authors' may well be using a different scale model to justify this > recommended time cycle. What numbers did you have in mind Matt that > would make this "SHOULD" 3 hour refresh cycle feasible in a big-I > Internet scenario of universal use? > > > Geoff > > WG Co-Chair hat off > > > > > > From gih@apnic.net Tue Oct 27 13:59: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 7C2673A6998 for ; Tue, 27 Oct 2009 13:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=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 iF55AKqe719L for ; Tue, 27 Oct 2009 13:59:21 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 3034D3A68C3 for ; Tue, 27 Oct 2009 13:59:19 -0700 (PDT) Received: from [58.163.110.235] (unknown [58.163.110.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 42028D58C7; Wed, 28 Oct 2009 07:00:35 +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: <4AE75809.4050808@bbn.com> Date: Wed, 28 Oct 2009 07:59:30 +1100 Content-Transfer-Encoding: 7bit Message-Id: <961EE7F7-5E07-48F6-817F-487C802CD088@apnic.net> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> To: Matt Lepinski X-Mailer: Apple Mail (2.1076) 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: Tue, 27 Oct 2009 20:59:24 -0000 WG Co-chair hat OFF Matt, > > I'm happy to accept that the new wording is poor, but I'm pretty > sure the old wording was also bad, and I think this discussion is > important. Please do not misunderstand me - I was not implicitly expressing a preference for the old wording when I questioned the change you've made to this version draft. What I was wondering about was the viability in terms of both server load and relying party actions in a fully populated system if the relying parties implemented such a recommendation with a three hour refresh cycle time, and I was wondering about the query load on the server under an idealized load model and the viability of the relying party to complete a sweep of a fully populated and fully distributed repository publication system within a 3 hour time period. You have raised some good questions in your note: 1) So the first implicit question is: Should the working group be making a recommendation as to the frequency with which a relying party pulls from the repository? 2) The second question is: If we make a recommendation regarding frequency with which relying parties should pull updates, what frequency should we recommend. And perhaps I could add a third, on a more procedural note: 3) Should such operational recommendations be made in an architecture document or collected together in an operational guidelines document? The original rough guesstimates about load in my response to your original note to the WG were just that, and doubtless an answer to question 2 would benefit form some more detailed analysis of a number of possible deployment scenarios, as you have also noted. Whether the recommendation needs to encompass a worst case deployment scenario, or to what extent any such recommendation is affected by the nature of the deployed environment of certificate and signed object publication points probably merits some study in the WG as well. The "currency" of the data and the "responsiveness" of the system of changes are to my mind important topics. Given that the repository publication system is passive, in that new data cannot be pushed to replying parties, but instead relies on the actions of replying parties to discover a change, then the recommendations to relying parties, and the associated implications of overall system load are all relevant considerations here. Geoff WG Co-chair hat OFF From ggm+ietf@apnic.net Tue Oct 27 16:45: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 BC73A3A69D4 for ; Tue, 27 Oct 2009 16:45:51 -0700 (PDT) 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 CrW85nD4IfdG for ; Tue, 27 Oct 2009 16:45:51 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id CA0D83A65A6 for ; Tue, 27 Oct 2009 16:45:50 -0700 (PDT) Received: from dynamic187.apnic.net (dynamic187.apnic.net [203.119.42.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id B8955D58C7; Wed, 28 Oct 2009 09:47:05 +1000 (EST) From: George Michaelson Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 28 Oct 2009 09:46:02 +1000 Message-Id: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> To: Sandra Murphy Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:45:51 -0000 I wish to request you as as working group chair to conduct a Working Group Last call on the following documents of which I am a co-author: draft-ietf-sidr-res-certs-17 draft-ietf-sidr-repos-struct-03.txt draft-ietf-sidr-roa-validation-03.txt -George From bje@apnic.net Tue Oct 27 16:56: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 19B243A6A89 for ; Tue, 27 Oct 2009 16:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXbUi8REL-BC for ; Tue, 27 Oct 2009 16:56:40 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id E11333A69D0 for ; Tue, 27 Oct 2009 16:56:39 -0700 (PDT) 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 A8692D58C7; Wed, 28 Oct 2009 09:57:57 +1000 (EST) From: Byron Ellacott Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 28 Oct 2009 09:56:53 +1000 Message-Id: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> To: sandy@sparta.com Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: [sidr] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 23:56:41 -0000 Sandy, with your WG chair hat on, could you please issue a WG Last Call on the following document: draft-ietf-sidr-rescerts-provisioning-05.txt I am a co-author of this document. 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 ggm@apnic.net Tue Oct 27 17:44: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 0207A28C14F for ; Tue, 27 Oct 2009 17:44:49 -0700 (PDT) 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 bb5jFV+ZpF5l for ; Tue, 27 Oct 2009 17:44:47 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8407628C119 for ; Tue, 27 Oct 2009 17:44:46 -0700 (PDT) Received: from dynamic187.apnic.net (dynamic187.apnic.net [203.119.42.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C4A7DD58C7; Wed, 28 Oct 2009 10:46:03 +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: <4AE75809.4050808@bbn.com> Date: Wed, 28 Oct 2009 10:44:59 +1000 Content-Transfer-Encoding: 7bit Message-Id: <11856BC4-5462-4AB1-A175-D6D70EE10B63@apnic.net> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> To: Matt Lepinski X-Mailer: Apple Mail (2.1076) 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, 28 Oct 2009 00:44:49 -0000 Matt, If you don't mind I'd like to add some input to this discussion too. On 28/10/2009, at 6:28 AM, Matt Lepinski wrote: > Geoff, > > I'm happy to accept that the new wording is poor, but I'm pretty > sure the old wording was also bad, and I think this discussion is > important. > > The old wording could easily be interpreted to suggest that once per > day was the correct frequency for pulling from a repository. (That > is, I believe the previous version was making a de facto > recommendation for a default behaivor of one pull every 24 hours ... > there wasn't a RECOMMEND in the text, but we all know that examples > tend to be normative in this type of document.) > > 1) So the first implicit question is: Should the working group be > making a recommendation as to the frequency with which a relying > party pulls from the repository? I think we have to think about it, yes. But in what document? Why in an Architecture document, this close to 'closure' ? > > Or equivalently: Is there a "wrong" frequency that people might use > if we didn't give them any guidence? > > It seems that retreiving updates "too frequently" (e.g., every 5 > minutes) strains the repository system and that retreiving updates > "too infrequently" (e.g., monthly) means that when I inject a new > ROA into the system, it will take "unacceptably long" for this > information to propogate to the relying parties that make use of > this information. Therefore, we should have text in the document > that articulates some middle ground that we believe is reasonable > for the Internet. (I make no claims that the current text in the > document achieves this goal.) > > 2) The second question is: If we make a recommendation regarding > frequency with which relying parties should pull updates, what > frequency should we recommend. The goal set earlier on in the life of this project was to stabilize the system in two complete 24h work cycles of the repository system as a whole. And yes, this was predicated on a MINIMUM of one fetch per 24h per RP. At least, thats what I understood. Maybe I was wrong? If certification-active 'producers' approach each other in the provisioning process at least 4 times a day, and this is suitably spread into 24h, I believe that we satisfy this 2x 24h cycle time goal, for relying parties, for the expected 'depth' maximums in the observed allocation hierarchy today. I have not seen any discussion which suggests either we're changing from 2 x 24h relying party cycles, or from an expected depth of at worst 8 levels of delegation. (there might well be deeper trees. I expect that they lie in the margins of global routing. I also believe now that the tree will be far shallower, for the overwhelming majority of the space) So, I don't understand why we've moved to 3 hourly cycle time for RPs. I don't see where this came from. > > 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. Well, the discussed approach informally has been to use a simple randomization mechanism to select a cron time in the 24h window, such that people choose a start time at random, and then cycle in a reasonable sub-multiple of that time. This has worked for other processes historically. Here is one example, from a google search: http://www.moundalexis.com/archives/000076.php Its not directly what I mean, but I am sure people can go back into their UUCP dial-sync days, or USENET call memory-stack, and remember approaches for doing this. Or, a provider could publish a simple 'pick a token' system and advise RPs to go there, and be assigned a random slot for fetch to balance load. I don't think we can recommend a fetch cycle period until we understand the dynamics of change in the repository. So I'd pose questions at this time: what rate of delay against a change in the repository is acceptable to an RP? what impact does depth in the tree have on change? how many cycles of update are allowed to pass before the tree is considered 'stable' against significant change? is this in fact not deterministic but depends on context which is out of scope? > > I agree that there are roughly 30,000 AS numbers visible in BGP, so > it's reasonable to assume on the order of 30,000 relying parties who > will be routinely querying the repository system. We might also > assume that 30,000 is a reasonable order of magnitude for the number > of CAs in the RPKI (we might easily average 2 CAs per AS, but surely > not 10 CAs per AS). Certainly when I modelled a large tree, these numbers were of the order of magnitude I modelled. I think I did around 10,000 distinct CAs. > > However, one thing that wasn't clear from reading your analysis was > how many CAs a given repository server would be hosting. If a server > run by a large ISP or an RIR was providing a cache of all RPKI data, > then clients would have longer connections to this server (as they > could retrieve much of the data they need in one place), but they > would be unlikely to receive requests from all 30,000 relying > parties (e.g. an ISP might provide a complete cache for their > customers but for non-customers they would typically only serve data > for which they are authoritative). Alternatively, if a server is > only serving data for a small subset of the CAs in the RPKI, then it > might receive requests from all relying parties, but those sessions > would tend to be short (especially when nothing has changed). RIRs have of the order 2000-5000 direct entities who they will be issuing CA certificates to. If they run hosted portals, its numbers of this magnitude which potentially could seek to use a hosted portal for EE certificate facing activity. I don't believe individual entities below the RIR level face administering CA spaces of this complexity. I think they are more probably under the 100 to 1000 CA/EE level. If people believe they want to host third party solutions, then I think the size lies anywhere between the 1-10 and the 30,000 level. "it depends" Aggregated repositories would of course have different dynamics of change. > > In any case, I believe the way forward (with regards to server load) > is to answer the question, "How many simultaneous connections are > reasonable for a server that hosts publication points for X CAs?" > and then work backwards from there to determine if a given interval > of relying party requests is reasonable from the server standpoint. > I admit that I haven't completely thought through re-key, but I'll > try to dig up some rough connection-time numbers based on our > relying party software, and do a few back-of-the envolope > computations. This would be good. But, I don't think it goes to an architecture question. I think it would be far better to do this work, and draft an operational guidelines document instead which puts this experience into a context which is more ameanable to change over time. > > With regards to client load, I'm not convinced that there's any > problem with frequent queries to the repository system. If the > relying party queries a publication point and rsync determines that > nothing has changed, then no changes are required to ethe relying > party's local cache and no cryptographic calculations are required. Please bear in mind that some amount of held state exists server side to determine what has changed. It might be a file-system walk and on- demand checks on files, for stat() information. it might be a simple DB lookup. But in either case, its not 'for free' -some level of work is being done. And, held TCP/IP session state. Is this of the same order of magnitude as running a web server? I think that it very probably is. Particularly ones which are doing dynamic content serve, rather than simple cached state. Their solutions (million-chickens, reverse caches, memcached ...) are probably applicable here. > If something has changed, then the relying party has to perform > validation (which includes cryptographic signature verification) on > the manifest and any new objects that have been added. > (Additionally, there may be resulting changes to the client's local > cache ... e.g., if a new CRL revokes a previously valid > certificate ... but such changes don't require new cryptographic > computations, and so I believe the bottleneck is going to be the one > or two signature verifications per object changed [1]). Now the > point from the relying party side is that if 5,000 manifests change > and 10,000 signed objects are added to the repository system on a > given day, then the relying party needs to do roughly 30,000 > signature verifications regardless of whether it learns of all these > changes at once, or whether it learns of them in small batches > throughout the course of the day. Therefore, I don't see how making > frequent checks for new data has a significant impact on the relying > party's processing load. I'm also unsure from this sum what the benefit of frequent checks was. Is it faster completion of the cycle time around re-key? Whats it benefiting? > > Finally, in addition to server and relying party processing loads, > one must also look at the benefit of frequent repository fetches. > Keep in mind, that a relying party has no way of distinguishing the > following two events: (A) a route advertisement is originated by an > AS that is authorized to advertise the route, but the relying party > hasn't fetched recently enough to obtain the new ROA; and (B) a > route advertisement is originated by an unauthorized entity that is > attempting to hijack address space. In this discussion, it is also > important to note that manifests can gaurantee that the relying > party received all signed objects that existed at the moment that > the manifest was published (i.e., a manifest can detect malicious > deletion of data from a repository or corruption of data in transit) > but the manifest says nothing about data that may have been added > since the manifest was issued. This is why there is benefit in a > relying party going back to the publication point perioidically to > see whether a new manifest has been issued. > > In any case, it's good to know that we'll have plenty to talk about > in Hiroshima. Yes. I think there is a discussion here. If we could abstract these questions to a yet-to-be-done Operations document, I think we could continue to talk about Architecture documents as plausibly 'done' and this means we can progress WGLC. What do you think? -George > > - Matt Lepinski From pmohapat@cisco.com Tue Oct 27 17:44: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 BB8F628C17A for ; Tue, 27 Oct 2009 17:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcujJ-Tiz3IS for ; Tue, 27 Oct 2009 17:44:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 139D428C173 for ; Tue, 27 Oct 2009 17:44:52 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK4w50qrR7Hu/2dsb2JhbADBN5hShD8E X-IronPort-AV: E=Sophos;i="4.44,636,1249257600"; d="scan'208";a="419357696" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2009 00:45:06 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9S0j7Nr010923 for ; Wed, 28 Oct 2009 00:45:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 17:45:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 17:45:05 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document Thread-Index: AcpXZ+P9h4NViJeUSiW2j9ttTapi4g== From: "Pradosh Mohapatra (pmohapat)" To: X-OriginalArrivalTime: 28 Oct 2009 00:45:07.0012 (UTC) FILETIME=[E5158040:01CA5767] Subject: [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: Wed, 28 Oct 2009 00:44:53 -0000 The authors would like to request that draft-pmohapat-sidr-pfx-validate-03.txt be adopted as a SIDR WG document. Thanks, - Pradosh From randy@psg.com Tue Oct 27 18:23: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 930183A69E2 for ; Tue, 27 Oct 2009 18:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGED4FRbOOiN for ; Tue, 27 Oct 2009 18:23:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CE2733A6860 for ; Tue, 27 Oct 2009 18:23:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2xGP-000MCO-4W; Wed, 28 Oct 2009 01:23:49 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 9176E2BBB245; Wed, 28 Oct 2009 10:23:48 +0900 (JST) Date: Wed, 28 Oct 2009 10:23:48 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@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] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:23:38 -0000 > draft-ietf-sidr-roa-validation-03.txt i object to last call on this. there is a conflicting draft, and one not by a wg co-chair. randy From randy@psg.com Tue Oct 27 18:25: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 9C2843A6860 for ; Tue, 27 Oct 2009 18:25:57 -0700 (PDT) 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 t0r1Q39KXxn6 for ; Tue, 27 Oct 2009 18:25:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id B91793A692A for ; Tue, 27 Oct 2009 18:25:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2xIf-000MCx-B6; Wed, 28 Oct 2009 01:26:09 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id CA5802BBB263; Wed, 28 Oct 2009 10:26:08 +0900 (JST) Date: Wed, 28 Oct 2009 10:26:08 +0900 Message-ID: From: Randy Bush To: "Pradosh Mohapatra (pmohapat)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> 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] 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: Wed, 28 Oct 2009 01:25:57 -0000 > The authors would like to request that > draft-pmohapat-sidr-pfx-validate-03.txt be adopted as a SIDR WG > document. i support this randy From randy@psg.com Tue Oct 27 18:30: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 E763828C15E for ; Tue, 27 Oct 2009 18:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 5mpDvQheHSLf for ; Tue, 27 Oct 2009 18:30:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 0AB1E28C159 for ; Tue, 27 Oct 2009 18:30:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2xNB-000MDx-RG; Wed, 28 Oct 2009 01:30:49 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 50DFA2BBB2F2; Wed, 28 Oct 2009 10:30:49 +0900 (JST) Date: Wed, 28 Oct 2009 10:30:49 +0900 Message-ID: From: Randy Bush To: Byron Ellacott In-Reply-To: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> References: <65A69177-0471-45C0-945E-ACB55A84599D@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] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:30:38 -0000 > Sandy, with your WG chair hat on, could you please issue a WG Last > Call on the following document: > draft-ietf-sidr-rescerts-provisioning-05.txt still reading, but ... 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 From ggm@apnic.net Tue Oct 27 18:41: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 1FB0628C168 for ; Tue, 27 Oct 2009 18:41:52 -0700 (PDT) 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 5XqfthdrhqZP for ; Tue, 27 Oct 2009 18:41:51 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 8DF8C28C12E for ; Tue, 27 Oct 2009 18:41:50 -0700 (PDT) Received: from dynamic187.apnic.net (dynamic187.apnic.net [203.119.42.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 96592D58C7 for ; Wed, 28 Oct 2009 11:43:08 +1000 (EST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: George Michaelson In-Reply-To: Date: Wed, 28 Oct 2009 11:42:04 +1000 Content-Transfer-Encoding: 7bit Message-Id: <01F0BA28-7271-4444-9A08-146145E1A46D@apnic.net> References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [sidr] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:41:52 -0000 On 28/10/2009, at 11:30 AM, Randy Bush wrote: >> Sandy, with your WG chair hat on, could you please issue a WG Last >> Call on the following document: >> draft-ietf-sidr-rescerts-provisioning-05.txt > > still reading, but ... > > 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 I don't see the acronym RIR anywhere in the document. There is one reference to regional internet registry policy documents. It does talk about LIR, and IR, and ISP. I would have thought that IANA, the RIRs and LIRs are conceptually at least one of LIR and IR in this context. So, are you just saying you want these specific terms replaced by more neutral 'parent' and 'child' (or likewise, similar, roget-thesaurus- time) terms? section 1.1 terminology seems to me to be quite good actually: 1.1 Terminology (elided) Additional terms used in this document are: "IR" an abbreviation of "Internet Registry", using in the context of this document as an entity undertaking the role of resource issuer. An IR is a Certificate Authority, and can issue Resource Certificates. "ISP" an abbreviation of "Internet Service Provider", using in the context of this document as an entity undertaking the role of resource recipient who is the subject of a Resource Certificate. An ISP may be issued with a CA-enabled certificate, allowing the entity to also assume the role of an IR. "resource class" a resource class refers to a collection of resources that can be certified in a single resource certificate by an issuer. "server" in the context of this client/server protocol specification, the IR assumes the role of the "server." "client" in the context of this client/server protocol specification, the ISP assumes the role of the "client." So, contextually, an entity is referred to as a client when it faces up, which is broadly speaking what most ISPs will do *in the context of their own routing announcements* at least. When they operate as agents issuing certificates, they are in the role of an IR. -And that is what the "ISP" terminology section says: "An ISP may be issued with a CA-enabled certificate, allowing the entity to also assume the role of an IR." I'm not an author of this draft btw. -george From Sandra.Murphy@cobham.com Tue Oct 27 18:47: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 266693A6A91 for ; Tue, 27 Oct 2009 18:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtXh2ESj-v13 for ; Tue, 27 Oct 2009 18:47:08 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4D11F3A69D8 for ; Tue, 27 Oct 2009 18:47:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9S1l0ge013410; Tue, 27 Oct 2009 20:47:00 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9S1l1UP019656; Tue, 27 Oct 2009 20:47:01 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 21:47:01 -0400 Date: Tue, 27 Oct 2009 21:47:00 -0400 (Eastern Daylight Time) From: Sandra Murphy To: "Pradosh Mohapatra (pmohapat)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> 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: 28 Oct 2009 01:47:01.0006 (UTC) FILETIME=[8ACC02E0:01CA5770] 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: Wed, 28 Oct 2009 01:47:09 -0000 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 ggm+ietf@apnic.net Tue Oct 27 18:47: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 D44C628C174 for ; Tue, 27 Oct 2009 18:47:49 -0700 (PDT) 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 WVAjtEBwiwoG for ; Tue, 27 Oct 2009 18:47:49 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id E030C28C12E for ; Tue, 27 Oct 2009 18:47:48 -0700 (PDT) Received: from dynamic187.apnic.net (dynamic187.apnic.net [203.119.42.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 281DBD58C7; Wed, 28 Oct 2009 11:49:07 +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, 28 Oct 2009 11:48:02 +1000 Content-Transfer-Encoding: 7bit Message-Id: <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:47:49 -0000 On 28/10/2009, at 11:23 AM, Randy Bush wrote: >> draft-ietf-sidr-roa-validation-03.txt > > i object to last call on this. there is a conflicting draft, and one > not by a wg co-chair. > > randy The conflicting draft has an outstanding IPR claim, which has not been discussed or addressed by the authors (which includes yourself Randy) The draft has only just been proposed for adoption. Can you explain what aspect of process prevents a WG co-chair from authorship of documents in the WG? -George From randy@psg.com Tue Oct 27 18:53: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 D09803A69D8 for ; Tue, 27 Oct 2009 18:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76l0X-eujRSD for ; Tue, 27 Oct 2009 18:53:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 1190928C178 for ; Tue, 27 Oct 2009 18:53:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2xjL-000MIF-B5; Wed, 28 Oct 2009 01:53:43 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id BF9842BBB4D1; Wed, 28 Oct 2009 10:53:42 +0900 (JST) Date: Wed, 28 Oct 2009 10:53:42 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <0952A4E7-B089-424E-ADD5-2A6D98956668@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] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:53:30 -0000 >> i object to last call on this. there is a conflicting draft, and one >> not by a wg co-chair. > The conflicting draft has an outstanding IPR claim, which has not been > discussed or addressed by the authors (which includes yourself Randy) this is just part of normal life in the ietf. you might wait to learn what ipr is claimed before lynching anyone. > The draft has only just been proposed for adoption. so? > Can you explain what aspect of process prevents a WG co-chair from > authorship of documents in the WG? the particular wg co-chair is a co-author on both drafts. but you might find somewhat relevant. randy From Sandra.Murphy@cobham.com Tue Oct 27 18:55: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 330683A69D0 for ; Tue, 27 Oct 2009 18:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgAcmE1W9GVj for ; Tue, 27 Oct 2009 18:55:49 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 59A183A688F for ; Tue, 27 Oct 2009 18:55:49 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9S1u1L5013458; Tue, 27 Oct 2009 20:56:01 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9S1u0Rs019821; Tue, 27 Oct 2009 20:56:01 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 21:56:00 -0400 Date: Tue, 27 Oct 2009 21:56:00 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Oct 2009 01:56:00.0838 (UTC) FILETIME=[CC8FD660:01CA5771] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:55:50 -0000 On Wed, 28 Oct 2009, Randy Bush wrote: >>> i object to last call on this. there is a conflicting draft, and one >>> not by a wg co-chair. >> The conflicting draft has an outstanding IPR claim, which has not been >> discussed or addressed by the authors (which includes yourself Randy) > > this is just part of normal life in the ietf. you might wait to learn > what ipr is claimed before lynching anyone. > >> The draft has only just been proposed for adoption. > > so? > >> Can you explain what aspect of process prevents a WG co-chair from >> authorship of documents in the WG? > > the particular wg co-chair is a co-author on both drafts. but you might > find > somewhat relevant. Not in the current version of the pfx-validate draft. --Sandy > > randy > From ggm+ietf@apnic.net Tue Oct 27 19:02:02 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 106243A6938 for ; Tue, 27 Oct 2009 19:02:02 -0700 (PDT) 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 DAKk4TjYrYxQ for ; Tue, 27 Oct 2009 19:02:01 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 0084A3A681B for ; Tue, 27 Oct 2009 19:02:00 -0700 (PDT) Received: from dynamic187.apnic.net (dynamic187.apnic.net [203.119.42.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 4B926D58C7; Wed, 28 Oct 2009 12:03:16 +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, 28 Oct 2009 12:02:11 +1000 Content-Transfer-Encoding: 7bit Message-Id: <6907475D-3695-4A78-9C72-14E20601F975@apnic.net> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 02:02:02 -0000 On 28/10/2009, at 11:53 AM, Randy Bush wrote: >>> i object to last call on this. there is a conflicting draft, and >>> one >>> not by a wg co-chair. >> The conflicting draft has an outstanding IPR claim, which has not >> been >> discussed or addressed by the authors (which includes yourself Randy) > > this is just part of normal life in the ietf. you might wait to learn > what ipr is claimed before lynching anyone. > I am not lynching anyone. Sam Weiler mailed the list last week on this issue and I haven't seen a reply. Don't you think its relevant? I think its relevant to WG adoption. >> The draft has only just been proposed for adoption. > > so? It seems a little odd to promote a 'conflicting draft' as a WGLC blocker when it hasn't even adopted as a WG item. > >> Can you explain what aspect of process prevents a WG co-chair from >> authorship of documents in the WG? > > the particular wg co-chair is a co-author on both drafts. Wrong. go re-read the authors section of 03. The same edit which added you as an author removed Geoff. > but you might > find > somewhat relevant. > > randy I don't see anything relevant there. Its your own personal opinion, and its on the record. Shame on you Randy, for hijacking WG process for a personal agenda. -George From jisrar@cisco.com Tue Oct 27 19:02: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 4EA163A6A43 for ; Tue, 27 Oct 2009 19:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUzkDAkgq8Mu for ; Tue, 27 Oct 2009 19:02:12 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5F8413A681B for ; Tue, 27 Oct 2009 19:02:12 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADlD50pAZnwM/2dsb2JhbADBRZhThD8E X-IronPort-AV: E=Sophos;i="4.44,636,1249257600"; d="scan'208";a="65237446" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Oct 2009 02:02:26 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9S22Q7Z025634 for ; Wed, 28 Oct 2009 02:02:26 GMT Received: from xmb-rtp-206.amer.cisco.com ([64.102.31.32]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:02:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 22:02:22 -0400 Message-ID: <5DE18DE501A5434980E9AF87A61E66DC09836B0B@xmb-rtp-206.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document Thread-Index: AcpXZ+P9h4NViJeUSiW2j9ttTapi4gACsd9A References: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> From: "Junaid Israr (jisrar)" To: "Pradosh Mohapatra (pmohapat)" , X-OriginalArrivalTime: 28 Oct 2009 02:02:26.0485 (UTC) FILETIME=[B26CE650:01CA5772] 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: Wed, 28 Oct 2009 02:02:13 -0000 I support this. -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Pradosh Mohapatra (pmohapat) Sent: Tuesday, October 27, 2009 8:45 PM To: sidr@ietf.org Subject: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document 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 randy@psg.com Tue Oct 27 19:04: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 5523D3A688F for ; Tue, 27 Oct 2009 19:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 KgFPu32+0fHn for ; Tue, 27 Oct 2009 19:04:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 6F2163A69D8 for ; Tue, 27 Oct 2009 19:04:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2xta-000MLk-NK; Wed, 28 Oct 2009 02:04:18 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 372CF2BBB53B; Wed, 28 Oct 2009 11:04:18 +0900 (JST) Date: Wed, 28 Oct 2009 11:04:18 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: <01F0BA28-7271-4444-9A08-146145E1A46D@apnic.net> References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> <01F0BA28-7271-4444-9A08-146145E1A46D@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] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 02:04:07 -0000 >> 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. > > I don't see the acronym RIR anywhere in the document. There is one > reference to regional internet registry policy documents. perhaps reading my message again, and more slowly, would be helpful. randy From Sandra.Murphy@cobham.com Tue Oct 27 19:04: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 AEA113A688F for ; Tue, 27 Oct 2009 19:04:25 -0700 (PDT) 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 NiYtl3wwpzO5 for ; Tue, 27 Oct 2009 19:04:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id C138C3A69D8 for ; Tue, 27 Oct 2009 19:04:24 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9S24bK0013501; Tue, 27 Oct 2009 21:04:37 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9S24bqH019948; Tue, 27 Oct 2009 21:04:37 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:04:37 -0400 Date: Tue, 27 Oct 2009 22:04:36 -0400 (Eastern Daylight Time) From: Sandra Murphy To: George Michaelson In-Reply-To: <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> Message-ID: References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Oct 2009 02:04:37.0263 (UTC) FILETIME=[006009F0:01CA5773] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 02:04:25 -0000 On Wed, 28 Oct 2009, George Michaelson wrote: > > On 28/10/2009, at 11:23 AM, Randy Bush wrote: > >>> draft-ietf-sidr-roa-validation-03.txt >> >> i object to last call on this. there is a conflicting draft, and one >> not by a wg co-chair. >> >> randy > > > The conflicting draft has an outstanding IPR claim, which has not been > discussed or addressed by the authors (which includes yourself Randy) The IPR Disclosure can be seen at: https://datatracker.ietf.org/ipr/1028/ > > The draft has only just been proposed for adoption. > > Can you explain what aspect of process prevents a WG co-chair from authorship > of documents in the WG? > > -George From randy@psg.com Tue Oct 27 19:09: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 1BEA53A6A98 for ; Tue, 27 Oct 2009 19:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 bHMtUrP2m-gm for ; Tue, 27 Oct 2009 19:09:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5828A3A6A90 for ; Tue, 27 Oct 2009 19:09:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N2xyT-000MNY-TA; Wed, 28 Oct 2009 02:09:22 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 614282BBB5C1; Wed, 28 Oct 2009 11:09:21 +0900 (JST) Date: Wed, 28 Oct 2009 11:09:21 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: <6907475D-3695-4A78-9C72-14E20601F975@apnic.net> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> <6907475D-3695-4A78-9C72-14E20601F975@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] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 02:09:09 -0000 >> the particular wg co-chair is a co-author on both drafts. > Wrong. go re-read the authors section of 03. The same edit which added > you as an author removed Geoff. whoops! well, at least i did contribute to it. > Shame on you Randy, for hijacking WG process for a personal agenda. even if true, which it is not, this would be far from new to this wg. randy From Sandra.Murphy@cobham.com Tue Oct 27 19:22: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 6B43828C0DB for ; Tue, 27 Oct 2009 19:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 lEnvDODkJOrZ for ; Tue, 27 Oct 2009 19:22:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 898CD3A6A92 for ; Tue, 27 Oct 2009 19:22:00 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9S2MDpC013573; Tue, 27 Oct 2009 21:22:13 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9S2MDLm020251; Tue, 27 Oct 2009 21:22:13 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:22:13 -0400 Date: Tue, 27 Oct 2009 22:22:12 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <0952A4E7-B089-424E-ADD5-2A6D98956668@apnic.net> <6907475D-3695-4A78-9C72-14E20601F975@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Oct 2009 02:22:13.0067 (UTC) FILETIME=[75AEF1B0:01CA5775] Cc: sidr@ietf.org Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 02:22:01 -0000 On Wed, 28 Oct 2009, Randy Bush wrote: >>> the particular wg co-chair is a co-author on both drafts. >> Wrong. go re-read the authors section of 03. The same edit which added >> you as an author removed Geoff. > > whoops! well, at least i did contribute to it. > >> Shame on you Randy, for hijacking WG process for a personal agenda. > > even if true, which it is not, this would be far from new to this wg. Guys, guys, guys. We are going to have a lot of work to do in the next few weeks. With decent respect for people's time, please keep the off-topic comments off-list. --Sandy > > randy > From gih@apnic.net Tue Oct 27 19:43: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 1CE723A6A9D for ; Tue, 27 Oct 2009 19:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AViUrhoRzYul for ; Tue, 27 Oct 2009 19:43:28 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 140F228C0EF for ; Tue, 27 Oct 2009 19:43:27 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a] (unknown [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C148DD58C7; Wed, 28 Oct 2009 12:44:43 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 28 Oct 2009 13:43:38 +1100 Message-Id: <53807227-4AE4-4271-93AA-351E6E51E296@apnic.net> To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: dkong@bbn.com, skent@bbn.com, rwatro@bbn.com Subject: [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: Wed, 28 Oct 2009 02:43:29 -0000 The WG chairs have received a Working Group Last Call request from the authors of draft-ietf-sidr-cp-07.txt. The document (and the draft history) is at http://tools.ietf.org/html/draft-ietf-sidr-cp-07.txt 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. 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. thanks Geoff WG Co-CHair hat ON From gih@apnic.net Tue Oct 27 19:48: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 E75B428C0ED for ; Tue, 27 Oct 2009 19:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtGcSrDqtda7 for ; Tue, 27 Oct 2009 19:48:11 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id DE32728C129 for ; Tue, 27 Oct 2009 19:48:09 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a] (unknown [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 21A26D58C9; Wed, 28 Oct 2009 12:49:25 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 28 Oct 2009 13:48:19 +1100 Message-Id: To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: dkong@bbn.com, skent@bbn.com Subject: [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, 28 Oct 2009 02:48:12 -0000 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 From gih@apnic.net Tue Oct 27 19:50: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 A1E853A6805 for ; Tue, 27 Oct 2009 19:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjMMgvq0HSc4 for ; Tue, 27 Oct 2009 19:50:00 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 985623A66B4 for ; Tue, 27 Oct 2009 19:49:59 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a] (unknown [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D9839D58CD; Wed, 28 Oct 2009 12:51:17 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 28 Oct 2009 13:50:12 +1100 Message-Id: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: skent@bbn.com Subject: [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, 28 Oct 2009 02:50:00 -0000 The WG chairs have received a Working Group Last Call request from the authors of draft-ietf-sidr-arch-09.txt. The document (and the draft history) is at http://tools.ietf.org/html/draft-ietf-sidr-roa-arch-09 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 informational. 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. Thanks, Geoff WG Co-CHair hat ON From Sandra.Murphy@cobham.com Tue Oct 27 19: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 1919928C150 for ; Tue, 27 Oct 2009 19:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Eavh5f6L2zTr for ; Tue, 27 Oct 2009 19:52:20 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3D13428C0EF for ; Tue, 27 Oct 2009 19:52:20 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9S2qPZe013679; Tue, 27 Oct 2009 21:52:25 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9S2qPJM020685; Tue, 27 Oct 2009 21:52:25 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:52:25 -0400 Date: Tue, 27 Oct 2009 22:52:25 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> Message-ID: References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 28 Oct 2009 02:52:25.0610 (UTC) FILETIME=[AE0B0EA0:01CA5779] Cc: skent@bbn.com, sidr@ietf.org 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, 28 Oct 2009 02:52:21 -0000 On Wed, 28 Oct 2009, Geoff Huston wrote: > The WG chairs have received a Working Group Last Call request from the > authors of draft-ietf-sidr-arch-09.txt. > > The document (and the draft history) is at > http://tools.ietf.org/html/draft-ietf-sidr-roa-arch-09 I'm pretty sure Geoff means: http://tools.ietf.org/html/draft-ietf-sidr-arch-09 --Sandy > > 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 informational. > > 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. > > > Thanks, > > Geoff > > WG Co-CHair hat ON > From gih@apnic.net Tue Oct 27 20:07: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 E69983A681E for ; Tue, 27 Oct 2009 20:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDMRVp0ZIDxE for ; Tue, 27 Oct 2009 20:07:24 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id DCD183A681B for ; Tue, 27 Oct 2009 20:07:23 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a] (unknown [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2B59BD58C7; Wed, 28 Oct 2009 13:08:42 +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, 28 Oct 2009 14:07:37 +1100 Content-Transfer-Encoding: 7bit Message-Id: <216784D2-728E-4983-9258-320CCA4448B2@apnic.net> References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1076) Cc: skent@bbn.com, sidr@ietf.org 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, 28 Oct 2009 03:07:25 -0000 Indeed I did! Thanks for the correction. Geoff On 28/10/2009, at 1:52 PM, Sandra Murphy wrote: > > > On Wed, 28 Oct 2009, Geoff Huston wrote: > >> The WG chairs have received a Working Group Last Call request from >> the authors of draft-ietf-sidr-arch-09.txt. >> >> The document (and the draft history) is at http://tools.ietf.org/html/draft-ietf-sidr-roa-arch-09 > > I'm pretty sure Geoff means: > > http://tools.ietf.org/html/draft-ietf-sidr-arch-09 > > --Sandy > > >> >> 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 informational. >> >> 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. >> >> >> Thanks, >> >> Geoff >> >> WG Co-CHair hat ON >> From ggm@apnic.net Tue Oct 27 20:27: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 500173A676A for ; Tue, 27 Oct 2009 20:27:08 -0700 (PDT) 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 uKFrFgK5YPv6 for ; Tue, 27 Oct 2009 20:27:07 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id DE3E53A680D for ; Tue, 27 Oct 2009 20:27:06 -0700 (PDT) Received: from dynamic221.apnic.net (dynamic221.apnic.net [203.119.42.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 64767D58C7; Wed, 28 Oct 2009 13:28:25 +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, 28 Oct 2009 13:27:20 +1000 Content-Transfer-Encoding: 7bit Message-Id: <3E3914C4-EE67-4B0F-94FD-F693578CF3CD@apnic.net> References: <04CAD96D4C5A3D48B1919248A8FE0D540A843031@xmb-sjc-215.amer.cisco.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1076) 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: Wed, 28 Oct 2009 03:27:08 -0000 For the record, I object. the filed IPR claim at the IETF site is vague and does not provide sufficient details to isolate the claim at the US patent office. I visited the US patent office and searched in the "PAIR" system and it replied: Sorry, the entered Application Number "12/243767" is not available. The number may have been incorrectly typed, or assigned to an application that is not yet available for public inspection. -George On 28/10/2009, at 11:47 AM, 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 >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Tue Oct 27 22:04: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 B07893A69F5 for ; Tue, 27 Oct 2009 22:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 uVuyj5toLdAl for ; Tue, 27 Oct 2009 22:04:55 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A63553A69E0 for ; Tue, 27 Oct 2009 22:04:55 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9S55928014141 for ; Wed, 28 Oct 2009 00:05:09 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9S559RD022357 for ; Wed, 28 Oct 2009 00:05:09 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 01:05:09 -0400 Date: Wed, 28 Oct 2009 01:05:08 -0400 (Eastern Daylight 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: 28 Oct 2009 05:05:09.0113 (UTC) FILETIME=[38A92E90:01CA578C] Subject: [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: Wed, 28 Oct 2009 05:04:56 -0000 The WG chairs have received a Working Group Last Call request from an author of A Profile for Resource Certificate Repository Structure draft-ietf-sidr-repos-struct-03.txt which has an intended status of BCP. All versions, past and present, are available at http://tools.ietf.org/html/draft-ietf-sidr-repos-struct-03 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. 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. This draft has not seen consistent attention from the working group. It was discussed at IETF-71 and IETF-72 as an individual draft but has not been discussed in a meeting since its adoption as a wg draft (Aug 08). There's been little discussion on the list about this draft and the last occurred long ago. The -03 version differs little from the previous (Oct 08) version (differences are mostly due to whitespace and boilerplate). That might just indicate that there is no controversy. But lack of comment makes consensus hard to judge. I would like to have more positive feedback from people who have read the draft carefully and support its submission. --Sandy From Sandra.Murphy@cobham.com Tue Oct 27 22:05: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 774653A69E0 for ; Tue, 27 Oct 2009 22:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 B5Si5jShAXdu for ; Tue, 27 Oct 2009 22:05:11 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3419028C0F6 for ; Tue, 27 Oct 2009 22:05:11 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9S55PLn014145 for ; Wed, 28 Oct 2009 00:05:25 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9S55Pdk022363 for ; Wed, 28 Oct 2009 00:05:25 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 01:05:25 -0400 Date: Wed, 28 Oct 2009 01:05:25 -0400 (Eastern Daylight 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: 28 Oct 2009 05:05:25.0456 (UTC) FILETIME=[4266ED00:01CA578C] Subject: [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: Wed, 28 Oct 2009 05:05:12 -0000 The WG chairs have received a Working Group Last Call request from an author of A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-17.txt which has an intended status of Standard Track. All versions, past and present, are available at http://tools.ietf.org/html/draft-ietf-sidr-res-certs-17 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. 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 for the other Standards Track documents, the chairs would like to request the document's authors to prepare an interoperability report. --Sandy From rgaglian@fing.edu.uy Wed Oct 28 06:26: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 9A3423A697E for ; Wed, 28 Oct 2009 06:26:44 -0700 (PDT) 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 Z74jV1C+eOmE for ; Wed, 28 Oct 2009 06:26:43 -0700 (PDT) Received: from davinci.fing.edu.uy (smtp.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id 4189C3A687C for ; Wed, 28 Oct 2009 06:26:42 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (85-7-200.lacnic.net.uy [200.7.85.188] (may be forged)) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id n9SDPw5Y028080; Wed, 28 Oct 2009 11:26:00 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-16--743716347 From: Roque Gagliano In-Reply-To: <11856BC4-5462-4AB1-A175-D6D70EE10B63@apnic.net> Date: Wed, 28 Oct 2009 11:25:57 -0200 Message-Id: <4CC212B0-4501-41B4-8F67-8D68CF0DC748@fing.edu.uy> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <11856BC4-5462-4AB1-A175-D6D70EE10B63@apnic.net> To: George Michaelson , Matt Lepinski X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Wed, 28 Oct 2009 11:26:02 -0200 (UYST) X-Scanned-By: MIMEDefang 2.63 on 164.73.32.2 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, 28 Oct 2009 13:26:44 -0000 --Apple-Mail-16--743716347 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi George/Matt, On Oct 27, 2009, at 10:44 PM, George Michaelson wrote: > The goal set earlier on in the life of this project was to stabilize > the system in two complete 24h work cycles of the repository system > as a whole. And yes, this was predicated on a MINIMUM of one fetch > per 24h per RP. > > At least, thats what I understood. Maybe I was wrong? > That was my understanding too and that is the requirement we considered when building our system. We are populating the repository 4 times a day. I believe we are too early in the game to tighter operational practices, particularly in a document that we are about to ship out. As Robert points out, applications will be shipped with a default fetching cycle independently of what a particular CPS mentions. We will have to live with this... Roque. --Apple-Mail-16--743716347 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = George/Matt,

On Oct 27, 2009, at 10:44 PM, George = Michaelson wrote:
The goal set = earlier on in the life of this project was to stabilize the system in = two complete 24h work cycles of the repository system as a whole. And = yes, this was predicated on a MINIMUM of one fetch per 24h per = RP.

At least, thats what I understood. Maybe I was = wrong?


That was my = understanding too and that is the requirement we considered = when building our system. We are populating the repository 4 times = a day.

I believe we are too early in the game = to tighter operational practices, particularly in a document that we are = about to ship out. 

As Robert points out, = applications will be shipped with a default fetching cycle independently = of what a particular CPS mentions. We will have to live with = this...

Roque.
= --Apple-Mail-16--743716347-- From robert@ripe.net Wed Oct 28 07:27: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 603B828C1B1 for ; Wed, 28 Oct 2009 07:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPKYR0UWlBpZ for ; Wed, 28 Oct 2009 07:27:31 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 278183A68E6 for ; Wed, 28 Oct 2009 07:27:31 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N39Uv-0006fT-I2; Wed, 28 Oct 2009 15:27:43 +0100 Received: from Kistel-Mac.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id 788002F592; Wed, 28 Oct 2009 15:27:37 +0100 (CET) Message-ID: <4AE854D9.8040103@ripe.net> Date: Wed, 28 Oct 2009 15:27:37 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Matt Lepinski References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> In-Reply-To: <4AE75809.4050808@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a27408502def1afff6946f7bf0a109c53d8c 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, 28 Oct 2009 14:27:32 -0000 Hi, Matt Lepinski wrote: > 2) The second question is: If we make a recommendation regarding > frequency with which relying parties should pull updates, what frequency > should we recommend. > > 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. Keep in mind that "midnight" is a relative term, so this is not as bad as it sounds. > I agree that there are roughly 30,000 AS numbers visible in BGP, so it's > reasonable to assume on the order of 30,000 relying parties who will be > routinely querying the repository system. We might also assume that > 30,000 is a reasonable order of magnitude for the number of CAs in the > RPKI (we might easily average 2 CAs per AS, but surely not 10 CAs per AS). Do you have any supporting evidence to this claim "but surely not 10 CAs per AS"? > In any case, I believe the way forward (with regards to server load) is > to answer the question, "How many simultaneous connections are > reasonable for a server that hosts publication points for X CAs?" and > then work backwards from there to determine if a given interval of > relying party requests is reasonable from the server standpoint. I admit > that I haven't completely thought through re-key, but I'll try to dig up > some rough connection-time numbers based on our relying party software, > and do a few back-of-the envolope computations. There are other inputs to this calculation, not just the number of CAs. For example, the number of certificates issued per CA, and in close relation, the frequency with which the set of issued certificates changes, can vary wildly (for a potential single root it's probably a few, for an RIR it's thousands, for an LIR/ISP it's likely only a few). > With regards to client load, I'm not convinced that there's any problem > with frequent queries to the repository system. If the relying party > queries a publication point and rsync determines that nothing has > changed, then no changes are required to ethe relying party's local > cache and no cryptographic calculations are required. If something has While this in itself is true, you have to keep in mind that manifests and CRLs have to be regularly re-issued, so even if nothing substantial has changed, you do have to validate objects (and _then_ you'll realize that nothing really changed). > changed, then the relying party has to perform validation (which > includes cryptographic signature verification) on the manifest and any > new objects that have been added. (Additionally, there may be resulting > changes to the client's local cache ... e.g., if a new CRL revokes a > previously valid certificate ... but such changes don't require new > cryptographic computations, and so I believe the bottleneck is going to > be the one or two signature verifications per object changed [1]). Now > the point from the relying party side is that if 5,000 manifests change > and 10,000 signed objects are added to the repository system on a given > day, then the relying party needs to do roughly 30,000 signature > verifications regardless of whether it learns of all these changes at > once, or whether it learns of them in small batches throughout the > course of the day. Therefore, I don't see how making frequent checks for > new data has a significant impact on the relying party's processing load. That depends on how expensive the null operation is (ie. rsync figuring out that nothing has changed). I have no idea, but for a popular repository, such as an RIR's might be, it is probably not trivial. So experiencing it less frequently is useful. > In any case, it's good to know that we'll have plenty to talk about in > Hiroshima. Indeed! Robert > - Matt Lepinski From gih@apnic.net Wed Oct 28 12:19: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 ACD0E28C12C for ; Wed, 28 Oct 2009 12:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-DvieKS0AtX for ; Wed, 28 Oct 2009 12:19:27 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id A1A5A3A6778 for ; Wed, 28 Oct 2009 12:19:26 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a] (unknown [IPv6:2001:dc0:2001:10:226:8ff:fee7:7f2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 09E35D5833; Thu, 29 Oct 2009 05:20:46 +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: <53807227-4AE4-4271-93AA-351E6E51E296@apnic.net> Date: Thu, 29 Oct 2009 06:19:36 +1100 Content-Transfer-Encoding: 7bit Message-Id: <906F0474-64A6-478E-927C-14E0C91B1416@apnic.net> References: <53807227-4AE4-4271-93AA-351E6E51E296@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) Cc: dkong@bbn.com, skent@bbn.com, rwatro@bbn.com 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: Wed, 28 Oct 2009 19:19:27 -0000 On 28/10/2009, at 1:43 PM, Geoff Huston wrote: > The WG chairs have received a Working Group Last Call request from > the authors of draft-ietf-sidr-cp-07.txt. > > The document (and the draft history) is at http://tools.ietf.org/html/draft-ietf-sidr-cp-07.txt > > 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. > > 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. > Please note that that the draft's authors have advised me that the intended form of publication of this draft as a BCP. regards, Geoff WG C0-Chait hat ON From trac@tools.ietf.org Wed Oct 28 12:25: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 1367C3A69A9 for ; Wed, 28 Oct 2009 12:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.124, 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 q+PfidrmUHNk for ; Wed, 28 Oct 2009 12:25:12 -0700 (PDT) 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 F33E128C244 for ; Wed, 28 Oct 2009 12:24:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3E8k-00034p-H9; Wed, 28 Oct 2009 12:25:02 -0700 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, 28 Oct 2009 19:25:02 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/1 Message-ID: <052.0ec5e3e54b1c816be6856d2e6ce4f2fd@tools.ietf.org> X-Trac-Ticket-ID: 1 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] #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: Wed, 28 Oct 2009 19:25:13 -0000 #1: Nit Report -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: rpki-manifests | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Quoting form the document, section 8.5: If there exist files listed on the manifest that do not appear in the repository, then these objects are likely to have been improperly (via malice or accident) deleted from the manifest. That really should read "... deleted from the repository.", right? Cheers, Robert -- Ticket URL: sidr From trac@tools.ietf.org Wed Oct 28 12:25: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 5CB8628C239 for ; Wed, 28 Oct 2009 12:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, 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 e2UJqSWt33UU for ; Wed, 28 Oct 2009 12:25:15 -0700 (PDT) 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 95A593A6836 for ; Wed, 28 Oct 2009 12:25:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3E9A-0003MF-Cv; Wed, 28 Oct 2009 12:25:28 -0700 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, 28 Oct 2009 19:25:28 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/1#comment:1 Message-ID: <061.61e30de69ff85f74206ca0b0e52c4820@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: Wed, 28 Oct 2009 19:25:16 -0000 #1: Nit Report -----------------------------+---------------------------------------------- Reporter: gih@… | Owner: gih@… Type: defect | Status: assigned Priority: minor | Milestone: Component: rpki-manifests | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Changes (by gih@…): * owner: => gih@… * status: new => assigned -- Ticket URL: sidr From jgs@bgp.nu Wed Oct 28 13:18: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 2185C28C1CB for ; Wed, 28 Oct 2009 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVsMWOLEMIzD for ; Wed, 28 Oct 2009 13:18:06 -0700 (PDT) Received: from bgp.nu (bgp.nu [216.117.214.198]) by core3.amsl.com (Postfix) with ESMTP id 81B4128C155 for ; Wed, 28 Oct 2009 13:18:06 -0700 (PDT) Received: from jgs-sslvpn-nc.jnpr.net (nat-service4.juniper.net [66.129.225.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 6B72F16144BD; Wed, 28 Oct 2009 15:18:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "John G. Scudder" In-Reply-To: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> Date: Wed, 28 Oct 2009 16:18:19 -0400 Content-Transfer-Encoding: 7bit Message-Id: <6B493774-4EEC-4A9B-8218-C4116776D830@bgp.nu> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:18:07 -0000 George and all, On Oct 27, 2009, at 7:46 PM, George Michaelson wrote: > I wish to request you as as working group chair to conduct a Working > Group Last call on the following documents of which I am a co-author: ... > draft-ietf-sidr-roa-validation-03.txt This draft says that its intended status is Informational. Does that correctly represent what you think should happen with this document? I.e., that it be published as an RFC but not as any kind of a standard? (See also the RFC 2026 definition of "Informational".) If so that would seem to suggest that the apparent conflict with draft- pmohapat-sidr-pfx-validate-03.txt is moot, since an Informative document, strictly speaking, can't conflict with a Standards Track document. Thanks, --John From ggm+ietf@apnic.net Wed Oct 28 15:48: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 560873A6A3A for ; Wed, 28 Oct 2009 15:48:06 -0700 (PDT) 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 ZZS0+NqZb1ey for ; Wed, 28 Oct 2009 15:48:05 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 573F03A6781 for ; Wed, 28 Oct 2009 15:48:05 -0700 (PDT) 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 C233FD5833; Thu, 29 Oct 2009 08:49:26 +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: <6B493774-4EEC-4A9B-8218-C4116776D830@bgp.nu> Date: Thu, 29 Oct 2009 08:48:16 +1000 Content-Transfer-Encoding: 7bit Message-Id: <5F4D3F03-55CB-458B-B8C3-E11D34614D42@apnic.net> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <6B493774-4EEC-4A9B-8218-C4116776D830@bgp.nu> To: John G. Scudder X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 22:48:06 -0000 On 29/10/2009, at 6:18 AM, John G. Scudder wrote: > George and all, > > On Oct 27, 2009, at 7:46 PM, George Michaelson wrote: >> I wish to request you as as working group chair to conduct a >> Working Group Last call on the following documents of which I am a >> co-author: > ... >> draft-ietf-sidr-roa-validation-03.txt > > This draft says that its intended status is Informational. Does > that correctly represent what you think should happen with this > document? I.e., that it be published as an RFC but not as any kind > of a standard? (See also the RFC 2026 definition of "Informational".) > > If so that would seem to suggest that the apparent conflict with > draft-pmohapat-sidr-pfx-validate-03.txt is moot, since an > Informative document, strictly speaking, can't conflict with a > Standards Track document. > > Thanks, > Thanks for this observation John. If I understand this right, surely this means that Randy's WGLC objection to draft-ietf-sidr-roa- validation-03.txt is therefore moot, as there is no apparent conflict. cheers -George > --John From randy@psg.com Wed Oct 28 16:32: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 9D3193A6944 for ; Wed, 28 Oct 2009 16:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYaNQwr6s+aQ for ; Wed, 28 Oct 2009 16:32:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CB2773A67FC for ; Wed, 28 Oct 2009 16:32:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3I07-0000gj-Tm for sidr@ietf.org; Wed, 28 Oct 2009 23:32:24 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 6954C2BBEECB for ; Thu, 29 Oct 2009 08:32:23 +0900 (JST) Date: Thu, 29 Oct 2009 08:32:23 +0900 Message-ID: From: Randy Bush To: sidr In-Reply-To: <4AE854D9.8040103@ripe.net> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <4AE854D9.8040103@ripe.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 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, 28 Oct 2009 23:32:11 -0000 folk going down this rathole might consider two things rpki-rtr suggests that the number of global fetchers will be radically lest than the number of global asns there might be ca chain depth of 3-6 for which a 24 hour cycle would mean a three day delay, making operators remember curtis unfondly randy From ggm@apnic.net Wed Oct 28 16:54: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 C68FE3A693C for ; Wed, 28 Oct 2009 16:54:38 -0700 (PDT) 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.000, 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 bSTkFIBLeht9 for ; Wed, 28 Oct 2009 16:54:38 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id C0F1D3A693B for ; Wed, 28 Oct 2009 16:54:36 -0700 (PDT) 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 DC084D58CA for ; Thu, 29 Oct 2009 09:56:00 +1000 (EST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: George Michaelson In-Reply-To: Date: Thu, 29 Oct 2009 09:54:49 +1000 Content-Transfer-Encoding: 7bit Message-Id: <2E677999-C1B0-4288-9D3B-E2FC00FCC571@apnic.net> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <4AE854D9.8040103@ripe.net> To: sidr X-Mailer: Apple Mail (2.1076) 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, 28 Oct 2009 23:54:38 -0000 On 29/10/2009, at 9:32 AM, Randy Bush wrote: > folk going down this rathole might consider two things > > rpki-rtr suggests that the number of global fetchers will be > radically > lest than the number of global asns > > there might be ca chain depth of 3-6 for which a 24 hour cycle would > mean a three day delay, making operators remember curtis unfondly > > randy We modelled producer timing on a particular view of the world. I don't have a problem that the view of the world has changed, and that consumer-side timing issues have to be re-considered. I *think* that even bearing them in mind, the producer side modelling is still probably valid. If anyone thinks that producers need to be advised to rendezvous more than 4x in a 24h period, I think it would help to know. I don't think we're in crisis point for it going up btw, but I do think that the cost of processing will come into the limits on this at some point. In any case, I think abstracting this into operational practice statements is better than wedging it into architecture. There is an aspect of the times for re-publication which are published in certificates and manifests and CRLS defining the lower bound: everyone has to go fetch inside a cycle time which will respect them, or wear the consequences for things falling out-of-age. But the upper bound sanity check, the 'avoid excess work' isn't so clear to me right now. -G From ggm@apnic.net Wed Oct 28 18:38: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 CF4D13A6359 for ; Wed, 28 Oct 2009 18:38:27 -0700 (PDT) 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 eBUJ9HJKyeMR for ; Wed, 28 Oct 2009 18:38:27 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id B96603A67FA for ; Wed, 28 Oct 2009 18:38:26 -0700 (PDT) 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 70046D5833; Thu, 29 Oct 2009 11:39:49 +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: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> Date: Thu, 29 Oct 2009 11:38:37 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> To: Geoff Huston X-Mailer: Apple Mail (2.1076) Cc: sidr 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: Thu, 29 Oct 2009 01:38:27 -0000 On 28/10/2009, at 12: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. > > The document (and the draft history) is at http://tools.ietf.org/html/draft-ietf-sidr-roa-arch-09 > > 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 informational. > > 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. > > > Thanks, > > Geoff > > WG Co-CHair hat ON > I object to this document as it stands. I believe the document needs to have the 3 hour time cycle removed, and some form of operational guidelines placed in a distinct document (whether 3 hours, or some other time, is up to that document) -George From bje@apnic.net Wed Oct 28 18:43: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 AD45D3A68F6 for ; Wed, 28 Oct 2009 18:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG8LKcRKVXgw for ; Wed, 28 Oct 2009 18:43:46 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 77FEE3A6359 for ; Wed, 28 Oct 2009 18:43:46 -0700 (PDT) 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 9DE81D58C7; Thu, 29 Oct 2009 11:45:11 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Byron Ellacott In-Reply-To: Date: Thu, 29 Oct 2009 11:44:00 +1000 Content-Transfer-Encoding: 7bit Message-Id: <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@apnic.net> References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 01:43:47 -0000 Randy, On 28/10/2009, at 11:30 AM, Randy Bush wrote: > 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)). I believe section 1.1 entirely addresses this point. The definition of IR does not preclude service providers, nor does the definition of ISP preclude either regional internet registries or end sites. Summarised, they are: IR : an entity undertaking the role of resource issuer. ISP : an entity undertaking the role of resource recipient who is the subject of a Resource Certificate. 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 randy@psg.com Wed Oct 28 18:45: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 0C0043A68F6 for ; Wed, 28 Oct 2009 18:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol9UlCxa4QdN for ; Wed, 28 Oct 2009 18:45:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 0A4D73A6359 for ; Wed, 28 Oct 2009 18:45:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3K4s-0001Oh-Li; Thu, 29 Oct 2009 01:45:26 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 1F0A42BBFA3E; Thu, 29 Oct 2009 10:45:26 +0900 (JST) Date: Thu, 29 Oct 2009 10:45:25 +0900 Message-ID: From: Randy Bush To: Byron Ellacott In-Reply-To: <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@apnic.net> References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@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] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 01:45:15 -0000 >> 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)). > > I believe section 1.1 entirely addresses this point. The definition > of IR does not preclude service providers, nor does the definition of > ISP preclude either regional internet registries or end sites. > Summarised, they are: > > IR : an entity undertaking the role of resource issuer. > ISP : an entity undertaking the role of resource recipient who is the > subject of a Resource Certificate. dear apnic mafia, these are well-known terms. please leave the goalposts in place. randy From robertl@apnic.net Wed Oct 28 19:23: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 9C5A83A69E2 for ; Wed, 28 Oct 2009 19:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAdGUnX9ccFB for ; Wed, 28 Oct 2009 19:23:27 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id A26003A69DB for ; Wed, 28 Oct 2009 19:23:25 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:222:41ff:fe20:b4c1] (unknown [IPv6:2001:dc0:a000:4:222:41ff:fe20:b4c1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 81370D5833; Thu, 29 Oct 2009 12:24:49 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Robert Loomans In-Reply-To: Date: Thu, 29 Oct 2009 12:23:37 +1000 Content-Transfer-Encoding: 7bit Message-Id: <50E411BE-2BDA-4D97-9EAB-E8892D6B2E57@apnic.net> References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> To: George Michaelson X-Mailer: Apple Mail (2.1076) Cc: sidr 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: Thu, 29 Oct 2009 02:23:28 -0000 On 29/10/2009, at 11:38, George Michaelson wrote: > > I object to this document as it stands. > > I believe the document needs to have the 3 hour time cycle removed, > and some form of operational guidelines placed in a distinct > document (whether 3 hours, or some other time, is up to that document) > > Seconded. I think that this (and similar guesstimates) should be in an operational document. For reference, the relevant text is in section 6: > 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 may > choose any frequency it desires for downloading and validating > updates from the repository. However, any relying party that uses > RPKI data as an input to operational routing decisions (e.g., ISPs, > RIRs, NIRs) SHOULD download and validate updates at least once > every > three hours. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 From trac@tools.ietf.org Wed Oct 28 19:36: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 D1C3028C103 for ; Wed, 28 Oct 2009 19:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 3lgWgaQlNGaM for ; Wed, 28 Oct 2009 19:36:25 -0700 (PDT) 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 0F6AD28C0DB for ; Wed, 28 Oct 2009 19:36:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3KsR-0002en-MG; Wed, 28 Oct 2009 19:36:39 -0700 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, 29 Oct 2009 02:36:39 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/2 Message-ID: <052.947c78bd70e89e1731e39d171c3df515@tools.ietf.org> X-Trac-Ticket-ID: 2 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] #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: Thu, 29 Oct 2009 02:36:25 -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: -----------------------------+---------------------------------------------- The document needs to have the 3 hour time cycle removed, and some form of operational guidelines placed in a distinct document (whether 3 hours, or some other time, is up to that document). George Michaelson For reference, the relevant text is in section 6: 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 may choose any frequency it desires for downloading and validating updates from the repository. However, any relying party that uses RPKI data as an input to operational routing decisions (e.g., ISPs, RIRs, NIRs) SHOULD download and validate updates at least once every three hours. Rob -- Ticket URL: sidr From jmh@joelhalpern.com Wed Oct 28 20:38: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 C6D903A680D for ; Wed, 28 Oct 2009 20:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 zpIVseB+fv6b for ; Wed, 28 Oct 2009 20:38:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 0B92E3A67B8 for ; Wed, 28 Oct 2009 20:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1CC0B32317AF; Wed, 28 Oct 2009 20:38:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-240.clppva.btas.verizon.net [71.161.50.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 5D17832317AB; Wed, 28 Oct 2009 20:38:48 -0700 (PDT) Message-ID: <4AE90E4A.4050200@joelhalpern.com> Date: Wed, 28 Oct 2009 23:38:50 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Randy Bush References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@apnic.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] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 03:38:33 -0000 The quote provided does not match the wording in the draft. Please, this argument is vituperative enough. We need to quote accurately. What the document actually says is that ISP stands for "Internet Service Provider" (so far, so good. That is what it stands for.) It then goes on to say "using in the context of this document as an entity undertaking the role of..." Similarly, it says that IR is an "Internet Registry". If it is the intention to assert that Internet Registries are the resoruce issuers, and ISPs are the resource recipients. Then we should say that explicitly. If that is not the intention (and Randy is clearly asking that it not be, and someone responding seemed to be trying to say that it did not have to be), then we must not use the terms IR and ISP for those roles. We should not use terms with clear and relevant existing meanings unless our intention is to deliberately conflate the meanings. Yours, Joel Randy Bush wrote: >>> 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)). >> I believe section 1.1 entirely addresses this point. The definition >> of IR does not preclude service providers, nor does the definition of >> ISP preclude either regional internet registries or end sites. >> Summarised, they are: >> >> IR : an entity undertaking the role of resource issuer. >> ISP : an entity undertaking the role of resource recipient who is the >> subject of a Resource Certificate. ... > these are well-known terms. please leave the goalposts in place. > > randy From terry.manderson@icann.org Wed Oct 28 20:52: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 28F5E28C124 for ; Wed, 28 Oct 2009 20:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjfbh3anruyB for ; Wed, 28 Oct 2009 20:52:42 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 5AB4528C0ED for ; Wed, 28 Oct 2009 20:52:42 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 28 Oct 2009 20:52:58 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Wed, 28 Oct 2009 20:52:56 -0700 Thread-Topic: [sidr] Working Group Last Call - draft-ietf-sidr-cp-07.txt Thread-Index: AcpXeIVQh0VcKmJZRAqBBlhqgUb02AA0scET Message-ID: In-Reply-To: <53807227-4AE4-4271-93AA-351E6E51E296@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 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: Thu, 29 Oct 2009 03:52:43 -0000 Oppose. Although opposition is based on a small number of nits: * Section 1.7, page 11. "RPKI signed Object" ... "declared to be such by a standards track RFC issued by the SIDR WG" Over time, the SIDR WG may not exist, or the name could change, or valid RPKI objects come from other WG's. Perhaps 'issued by the IETF' * Section 3.1.1 Types of names. I think the section should it clear that names for the top level are meaningless as covered in sidr-arch. It touches briefly on this in 3.1.3 "(and Issuer)" but appears in my reading to be ambiguous. Perhaps " Names for IANA and RIRs will be meaningless directory distinguished ....." * 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 fo= r a subscriber to renew with someone else's private key. * Sections 9.12.1, 9.12.2, 9.12.3.. If the CP is administered by the IESG (section 1.6.1) shouldn't that also be reflected here? Cheers Terry On 28/10/09 12:43 PM, "Geoff Huston" wrote: > The WG chairs have received a Working Group Last Call request from the > authors of draft-ietf-sidr-cp-07.txt. >=20 > The document (and the draft history) is at > http://tools.ietf.org/html/draft-ietf-sidr-cp-07.txt >=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 > 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. >=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 trac@tools.ietf.org Wed Oct 28 21:26: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 6B9103A68B8 for ; Wed, 28 Oct 2009 21:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, 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 wQDE+u0KSaRk for ; Wed, 28 Oct 2009 21:26:32 -0700 (PDT) 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 B9C073A67A6 for ; Wed, 28 Oct 2009 21:26:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3Mb2-0005YB-EP; Wed, 28 Oct 2009 21:26:48 -0700 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, 29 Oct 2009 04:26:48 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/3 Message-ID: <052.43219578bfb8d05913d47e8738305d11@tools.ietf.org> X-Trac-Ticket-ID: 3 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] #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, 29 Oct 2009 04:26:33 -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: -----------------------------+---------------------------------------------- Oppose. Although opposition is based on a small number of nits: * Section 1.7, page 11. "RPKI signed Object" ... "declared to be such by a standards track RFC issued by the SIDR WG" Over time, the SIDR WG may not exist, or the name could change, or valid RPKI objects come from other WG's. Perhaps 'issued by the IETF' * Section 3.1.1 Types of names. I think the section should it clear that names for the top level are meaningless as covered in sidr-arch. It touches briefly on this in 3.1.3 "(and Issuer)" but appears in my reading to be ambiguous. Perhaps " Names for IANA and RIRs will be meaningless directory distinguished ....." * 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. * Sections 9.12.1, 9.12.2, 9.12.3.. If the CP is administered by the IESG (section 1.6.1) shouldn't that also be reflected here? Cheers Terry -- Ticket URL: sidr From terry.manderson@icann.org Wed Oct 28 21:47: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 3587B3A6961 for ; Wed, 28 Oct 2009 21:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNo1tyrTU55t for ; Wed, 28 Oct 2009 21:47:29 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 7893F3A68C6 for ; Wed, 28 Oct 2009 21:47:29 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 28 Oct 2009 21:47:45 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Wed, 28 Oct 2009 21:47:42 -0700 Thread-Topic: [sidr] Working Group Last Call - draft-ietf-sidr-roa-format-06.txt Thread-Index: AcpXeS3XKHUuTnUsSUed+HafE3eHYwA2cUY5 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 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, 29 Oct 2009 04:47:30 -0000 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. >=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 rcallon@juniper.net Wed Oct 28 21:51: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 81EE73A695C for ; Wed, 28 Oct 2009 21:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 DjWIzlWnDHK4 for ; Wed, 28 Oct 2009 21:51:21 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 4D1C53A676A for ; Wed, 28 Oct 2009 21:51:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSukfUO1XH6gNHgPvy/gDMprqjyTgUIy8@postini.com; Wed, 28 Oct 2009 21:51:37 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Oct 2009 21:50:43 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 29 Oct 2009 00:50:42 -0400 From: Ross Callon To: "John G. Scudder" , George Michaelson Date: Thu, 29 Oct 2009 00:50:41 -0400 Thread-Topic: [sidr] Request for WGLC Thread-Index: AcpYC86S+VAAhd43QlWYvFgNLg/QWwAROcOA Message-ID: References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <6B493774-4EEC-4A9B-8218-C4116776D830@bgp.nu> In-Reply-To: <6B493774-4EEC-4A9B-8218-C4116776D830@bgp.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 04:51:22 -0000 > If so that would seem to suggest that the apparent conflict with > draft-pmohapat-sidr-pfx-validate-03.txt is moot, since an Informative > document, strictly speaking, can't conflict with a Standards Track =20 > document. > > Thanks, > > --John If someone wanted to publish an informational document which gave a new ver= sion of BGP which is incompatible with existing deployed BGP, then I would = expect that people would care a lot. If they argued "the new incompatible v= ersion of BGP is informational, so it is fine", I don't think that this wou= ld make most people happy (and as AD this argument by itself wouldn't make = me happy).=20 Thus I don't think that it is true that "an Informative document, strictly = speaking, can't conflict with a Standards Track document".=20 It is true that there have been cases of multiple incompatible experimental= protocols published, but this is usually requires quite a bit of thought t= o make sure that there is a good reason to have multiple incompatible proto= cols. It is also true that there are cases where a protocol or an architect= ure that enjoys rough consensus of the WG will in some sense overtake a com= petitive document that did not enjoy rough consensus of the WG, but this of= course requires judgment of the WG (which for example might be determined = in WG discussions and a WG last call). Ross (speaking as AD)=20 From trac@tools.ietf.org Wed Oct 28 21:52: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 2F9223A68C9 for ; Wed, 28 Oct 2009 21:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, 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 oMSMSOrHyvdU for ; Wed, 28 Oct 2009 21:52:22 -0700 (PDT) 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 87CFE3A676A for ; Wed, 28 Oct 2009 21:52:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3N02-0008Ca-Mc; Wed, 28 Oct 2009 21:52:38 -0700 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, 29 Oct 2009 04:52:38 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/4 Message-ID: <052.b0834831a1a149b987cdbc3904e5b82d@tools.ietf.org> X-Trac-Ticket-ID: 4 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] #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: Thu, 29 Oct 2009 04:52:23 -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: -----------------------------+---------------------------------------------- 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 -- Ticket URL: sidr From terry.manderson@icann.org Wed Oct 28 22:56: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 31E2D3A6863 for ; Wed, 28 Oct 2009 22:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSd7UxrG5XgQ for ; Wed, 28 Oct 2009 22:56:40 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 5D96E3A66B4 for ; Wed, 28 Oct 2009 22:56:40 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 28 Oct 2009 22:56:56 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Wed, 28 Oct 2009 22:56:54 -0700 Thread-Topic: [sidr] Working Group Last Call - draft-ietf-sidr-arch-09.txt Thread-Index: AcpXeW4gT64qJX52QGiRC3qXnAaDMAA4y+Zr Message-ID: In-Reply-To: <1CCB8133-6C27-480B-8A9A-196927F526C9@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 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: Thu, 29 Oct 2009 05:56:41 -0000 Oppose. the following, I think, needs attention. * 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 repositor= y system. Terry On 28/10/09 12: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 terry.manderson@icann.org Wed Oct 28 23:11: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 0E1D03A683A for ; Wed, 28 Oct 2009 23:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYJ96KA6VSAX for ; Wed, 28 Oct 2009 23:11:40 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 4ADC33A69E0 for ; Wed, 28 Oct 2009 23:11:40 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 28 Oct 2009 23:11:56 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Wed, 28 Oct 2009 23:11:53 -0700 Thread-Topic: [sidr] Working Group Last Call for draft-ietf-sidr-repos-struct-03.txt Thread-Index: AcpXjEgbX6SSIRS0Q+CgUqMKmPbRHQA0m14Q 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 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: Thu, 29 Oct 2009 06:11:41 -0000 I support this document going forward.. Ideally I would like the draft to handle corruption avoidance instead of just corruption detection (section 6: security section), But I think that might be better dealt elsewhere than in the structure of the repo. Terry On 28/10/09 3:05 PM, "Sandra Murphy" wrote: > The WG chairs have received a Working Group Last Call request from an > author of >=20 > A Profile for Resource Certificate Repository Structure >=20 > draft-ietf-sidr-repos-struct-03.txt >=20 > which has an intended status of BCP. >=20 > All versions, past and present, are available at >=20 > http://tools.ietf.org/html/draft-ietf-sidr-repos-struct-03 >=20 >=20 > The Last Call will end as of the close of business on Monday 23rd Novembe= r > - 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 > 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 no= t > expressing a view either way. >=20 > This draft has not seen consistent attention from the working group. It > was discussed at IETF-71 and IETF-72 as an individual draft but has not > been discussed in a meeting since its adoption as a wg draft (Aug 08). > There's been little discussion on the list about this draft and the last > occurred long ago. The -03 version differs little from the previous (Oct > 08) version (differences are mostly due to whitespace and boilerplate). >=20 > That might just indicate that there is no controversy. But lack of > comment makes consensus hard to judge. >=20 > I would like to have more positive feedback from people who have read the > draft carefully and support its submission. >=20 > --Sandy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Wed Oct 28 23:22: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 23F053A683A for ; Wed, 28 Oct 2009 23:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqgohlEKH4Gw for ; Wed, 28 Oct 2009 23:22:35 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 6F5213A67AE for ; Wed, 28 Oct 2009 23:22:35 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 28 Oct 2009 23:22:51 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Wed, 28 Oct 2009 23:22:48 -0700 Thread-Topic: [sidr] Working Group Last Call for draft-ietf-sidr-res-certs-17 Thread-Index: AcpXjFHSOFkqNgZjRIGd2+/tX86sIAA0+oqs 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 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: Thu, 29 Oct 2009 06:22:36 -0000 I support this document moving forward as-is. Cheers Terry On 28/10/09 3:05 PM, "Sandra Murphy" wrote: > The WG chairs have received a Working Group Last Call request from an > author of >=20 > A Profile for X.509 PKIX Resource Certificates >=20 > draft-ietf-sidr-res-certs-17.txt >=20 > which has an intended status of Standard Track. >=20 >=20 > All versions, past and present, are available at >=20 > http://tools.ietf.org/html/draft-ietf-sidr-res-certs-17 >=20 >=20 > The Last Call will end as of the close of business on Monday 23rd Novembe= r > - 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 > 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 no= t > expressing a view either way. >=20 > As for the other Standards Track documents, the chairs would like to > request the document's authors to prepare an interoperability report. >=20 >=20 >=20 > --Sandy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Thu Oct 29 00:15: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 E47B33A6887 for ; Thu, 29 Oct 2009 00:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CD2CVkog4-r for ; Thu, 29 Oct 2009 00:15:49 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 58FB63A6A78 for ; Thu, 29 Oct 2009 00:15:49 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 29 Oct 2009 00:16:05 -0700 From: Terry Manderson To: "sidr@ietf.org" Date: Thu, 29 Oct 2009 00:16:04 -0700 Thread-Topic: Request for adoption as a WG itm Thread-Index: AcpYZ6zzMq3cbQ/aG0e9MvP1haciig== Message-ID: 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: [sidr] Request for adoption as a WG itm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 07:15:50 -0000 Chairs, The authors of draft-manderson-sidr-usecases-01.txt would like to request that this ID be adopted as a WG item. We acknowledge that there is a lot of work yet to be done on this document however we believe that the areas to be completed should come at the direction of the work group based on existing drafts under discussion. Cheers Terry=20 From jgs@juniper.net Thu Oct 29 00:30: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 EDF6E3A689B for ; Thu, 29 Oct 2009 00:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 cXd3TPPfumk4 for ; Thu, 29 Oct 2009 00:30:54 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 14B813A68CE for ; Thu, 29 Oct 2009 00:30:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSulEur26kMtXL8L3WLyoxHb2enujoJ0X@postini.com; Thu, 29 Oct 2009 00:31:10 PDT 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; Thu, 29 Oct 2009 00:27:29 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 00:27:29 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 00:27:28 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 00:27:28 -0700 Received: from jgs-sslvpn-nc.jnpr.net (jgs-sslvpn-nc.jnpr.net [172.23.4.146]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n9T7RQj76729; Thu, 29 Oct 2009 00:27:26 -0700 (PDT) (envelope-from jgs@juniper.net) MIME-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes From: "John G. Scudder" In-Reply-To: Date: Thu, 29 Oct 2009 03:27:25 -0400 Content-Transfer-Encoding: 7bit Message-ID: <35C7FBFA-031C-42B5-8739-E58CC219C253@juniper.net> References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> <6B493774-4EEC-4A9B-8218-C4116776D830@bgp.nu> To: Ross Callon X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 29 Oct 2009 07:27:28.0305 (UTC) FILETIME=[44D43A10:01CA5869] Cc: "sidr@ietf.org" Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 07:30:55 -0000 Ross, On Oct 29, 2009, at 12:50 AM, Ross Callon wrote: ... > Thus I don't think that it is true that "an Informative document, > strictly speaking, can't conflict with a Standards Track document". Makes sense; I shouldn't have said otherwise. Let me try a different tack and simply ask why draft-ietf-sidr-roa- validation-03 is intended as Informational and not Standards Track. Regards, --John From robert@ripe.net Thu Oct 29 00:44: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 BA7063A69DE for ; Thu, 29 Oct 2009 00:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.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 GiWxMAcD9uK6 for ; Thu, 29 Oct 2009 00:44:08 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ripe.net [193.0.19.66]) by core3.amsl.com (Postfix) with ESMTP id E48D53A6884 for ; Thu, 29 Oct 2009 00:44:07 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postgirl.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N3Pg4-0005PT-6z; Thu, 29 Oct 2009 08:44:17 +0100 Received: from Kistel-Mac.local (cat.ripe.net [193.0.1.249]) by herring.ripe.net (Postfix) with ESMTP id 25D6D2F583; Thu, 29 Oct 2009 08:44:12 +0100 (CET) Message-ID: <4AE947CA.1070603@ripe.net> Date: Thu, 29 Oct 2009 08:44:10 +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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2740e1d061cfd5190f87a71957870260038 Cc: sidr 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, 29 Oct 2009 07:44:08 -0000 Randy Bush wrote: > folk going down this rathole might consider two things > > rpki-rtr suggests that the number of global fetchers will be radically > lest than the number of global asns > > there might be ca chain depth of 3-6 for which a 24 hour cycle would > mean a three day delay, making operators remember curtis unfondly > > randy Randy, could you elaborate in which case does this transitive property apply, that makes something longer to propagate on a deeper hierarchy? Is it rekey, re-issue, revocation, or some kind or relying party check? Thanks, Robert From randy@psg.com Thu Oct 29 05:30: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 8AC583A67A1 for ; Thu, 29 Oct 2009 05:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCkh5DQBfeys for ; Thu, 29 Oct 2009 05:30:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 636F13A683D for ; Thu, 29 Oct 2009 05:30:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3U8w-0003HB-QZ; Thu, 29 Oct 2009 12:30:18 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 50F072BC29A6; Thu, 29 Oct 2009 21:30:18 +0900 (JST) Date: Thu, 29 Oct 2009 21:30:18 +0900 Message-ID: From: Randy Bush To: Robert Kisteleki In-Reply-To: <4AE947CA.1070603@ripe.net> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <4AE854D9.8040103@ripe.net> <4AE947CA.1070603@ripe.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 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, 29 Oct 2009 12:30:06 -0000 > Randy, could you elaborate in which case does this transitive property > apply, that makes something longer to propagate on a deeper hierarchy? Is it > rekey, re-issue, revocation, or some kind or relying party check? as ggm said, probably better than i can, a week or two after philly. if we have a parent-child chain of length L and each runs as a batch at some time interval T, then the mean time to propagate is (T/2)*(N-1) randy From randy@psg.com Thu Oct 29 05:32: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 3B7003A682E for ; Thu, 29 Oct 2009 05:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qTi5XP7561E for ; Thu, 29 Oct 2009 05:32:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id C80833A67A1 for ; Thu, 29 Oct 2009 05:32:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3UBc-0003Hz-Ob; Thu, 29 Oct 2009 12:33:04 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id CBCDE2BC2A18; Thu, 29 Oct 2009 21:33:03 +0900 (JST) Date: Thu, 29 Oct 2009 21:33:03 +0900 Message-ID: From: Randy Bush To: Robert Kisteleki In-Reply-To: References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <4AE854D9.8040103@ripe.net> <4AE947CA.1070603@ripe.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 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, 29 Oct 2009 12:32:55 -0000 sorry. late here. > as ggm said, probably better than i can, a week or two after philly. > > if we have a parent-child chain of length L and each runs as a batch at > some time interval T, then the mean time to propagate is (T/2)*(N-1) s/N/L/ randy From robert@ripe.net Thu Oct 29 05:38: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 04ADB3A696A for ; Thu, 29 Oct 2009 05:38:59 -0700 (PDT) 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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VCBLhjNE+hM for ; Thu, 29 Oct 2009 05:38:58 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 1C6433A67A1 for ; Thu, 29 Oct 2009 05:38:58 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1N3UHL-0008WM-RI; Thu, 29 Oct 2009 13:39:05 +0100 Received: from Kistel-Mac.local (dog.ripe.net [193.0.1.217]) by herring.ripe.net (Postfix) with ESMTP id D72FD2F583; Thu, 29 Oct 2009 13:38:58 +0100 (CET) Message-ID: <4AE98CE2.3080708@ripe.net> Date: Thu, 29 Oct 2009 13:38:58 +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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274f5f3d865d14b9bbe73a5549e5e94c8af Cc: sidr 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, 29 Oct 2009 12:38:59 -0000 Randy Bush wrote: >> Randy, could you elaborate in which case does this transitive property >> apply, that makes something longer to propagate on a deeper hierarchy? Is it >> rekey, re-issue, revocation, or some kind or relying party check? > > as ggm said, probably better than i can, a week or two after philly. > > if we have a parent-child chain of length L and each runs as a batch at > some time interval T, then the mean time to propagate is (T/2)*(N-1) > > randy 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? I don't mean this as a quiz; so far the use cases I could come up with do not have this property, so I'm wondering if such a thing really exists. Robert From Sandra.Murphy@cobham.com Thu Oct 29 07:50: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 732B828C0E4 for ; Thu, 29 Oct 2009 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 WpcA+uSpsMw6 for ; Thu, 29 Oct 2009 07:50:48 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8BCAF28C0D7 for ; Thu, 29 Oct 2009 07:50:48 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9TEp0rZ002380; Thu, 29 Oct 2009 09:51:00 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9TEojvu016414; Thu, 29 Oct 2009 09:50:57 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 10:50:45 -0400 Date: Thu, 29 Oct 2009 10:50:45 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Byron Ellacott In-Reply-To: <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@apnic.net> Message-ID: References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 Oct 2009 14:50:45.0397 (UTC) FILETIME=[31EE6450:01CA58A7] Cc: sidr@ietf.org Subject: Re: [sidr] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 14:50:49 -0000 On Thu, 29 Oct 2009, Byron Ellacott wrote: > Randy, > > On 28/10/2009, at 11:30 AM, Randy Bush wrote: > >> 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)). > > I believe section 1.1 entirely addresses this point. The definition of IR > does not preclude service providers, nor does the definition of ISP preclude > either regional internet registries or end sites. Summarised, they are: > > IR : an entity undertaking the role of resource issuer. > ISP : an entity undertaking the role of resource recipient who is the subject > of a Resource Certificate. Under this definition of ISP, would an RIR that received resources from IANA and received a resource certificate for those resources be an ISP? If not, why not? --Sandy > > 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 Sandra.Murphy@cobham.com Thu Oct 29 14:56: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 CFE3B3A6800 for ; Thu, 29 Oct 2009 14:56:55 -0700 (PDT) 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 pq6ijSTUAgSN for ; Thu, 29 Oct 2009 14:56:54 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B166F3A6840 for ; Thu, 29 Oct 2009 14:56:54 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9TLv9na010199; Thu, 29 Oct 2009 16:57:09 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9TLv8oC004985; Thu, 29 Oct 2009 16:57:09 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:57:08 -0400 Date: Thu, 29 Oct 2009 17:57:08 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Byron Ellacott In-Reply-To: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> Message-ID: References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 29 Oct 2009 21:57:08.0634 (UTC) FILETIME=[C2BA8FA0:01CA58E2] Cc: sidr@ietf.org Subject: Re: [sidr] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:56:55 -0000 My apologies - in watching the discussion about this draft I missed the fact that I did not issue the last call. coming right up. --Sandy On Wed, 28 Oct 2009, Byron Ellacott wrote: > Sandy, with your WG chair hat on, could you please issue a WG Last Call on > the following document: > > draft-ietf-sidr-rescerts-provisioning-05.txt > > I am a co-author of this document. > > 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 Sandra.Murphy@cobham.com Thu Oct 29 14:57: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 F3FD83A6A17 for ; Thu, 29 Oct 2009 14:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 MeFxbLZls-SK for ; Thu, 29 Oct 2009 14:57:15 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1F7DF3A6800 for ; Thu, 29 Oct 2009 14:57:15 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n9TLvTTQ010203; Thu, 29 Oct 2009 16:57:29 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n9TLvTuV005004; Thu, 29 Oct 2009 16:57:29 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.88]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:57:29 -0400 Date: Thu, 29 Oct 2009 17:57:29 -0400 (Eastern Daylight 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: 29 Oct 2009 21:57:29.0010 (UTC) FILETIME=[CEDFB120:01CA58E2] Cc: sra@isc.org Subject: [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: Thu, 29 Oct 2009 21:57:16 -0000 This WG chair has received a Working Group Last Call request from an author of A Protocol for Provisioning Resource Certificates draft-ietf-sidr-rescerts-provisioning-05.txt which has an intended status of Standard Track. All versions, past and present, are available at http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rescerts-provisioning 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. 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 for the other Standards Track documents, the chairs would like to request the document's authors to prepare an interoperability report. --Sandy From randy@psg.com Thu Oct 29 15:09: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 16D7B3A68A6 for ; Thu, 29 Oct 2009 15:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 FNfr6AiiY17j for ; Thu, 29 Oct 2009 15:09:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 4D7EA3A688C for ; Thu, 29 Oct 2009 15:09:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3dBY-0004nh-UY; Thu, 29 Oct 2009 22:09:37 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 66AEF2BC3F07; Fri, 30 Oct 2009 07:09:36 +0900 (JST) Date: Fri, 30 Oct 2009 07:09:36 +0900 Message-ID: From: Randy Bush To: George Michaelson In-Reply-To: References: <1CCB8133-6C27-480B-8A9A-196927F526C9@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 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: Thu, 29 Oct 2009 22:09:24 -0000 > I believe the document needs to have the 3 hour time cycle removed, > and some form of operational guidelines placed in a distinct document > (whether 3 hours, or some other time, is up to that document) i suspect it belongs in the CP, but am not sure. randy From randy@psg.com Thu Oct 29 15:15: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 D612A3A6800 for ; Thu, 29 Oct 2009 15:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 F9OIAHC-Qk5T for ; Thu, 29 Oct 2009 15:15:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id ED9533A67ED for ; Thu, 29 Oct 2009 15:15:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3dHR-0004od-2l; Thu, 29 Oct 2009 22:15:41 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 86D372BC3FFB; Fri, 30 Oct 2009 07:15:40 +0900 (JST) Date: Fri, 30 Oct 2009 07:15:40 +0900 Message-ID: From: Randy Bush To: Robert Kisteleki In-Reply-To: <4AE98CE2.3080708@ripe.net> 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> 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 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, 29 Oct 2009 22:15:26 -0000 > 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 From bje@apnic.net Thu Oct 29 18:00: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 2C7933A67FC for ; Thu, 29 Oct 2009 18:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f9s23IHcEWC for ; Thu, 29 Oct 2009 18:00:57 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id E0D763A680A for ; Thu, 29 Oct 2009 18:00:56 -0700 (PDT) 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 6F1CAD58BE; Fri, 30 Oct 2009 11:02:17 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Byron Ellacott In-Reply-To: Date: Fri, 30 Oct 2009 11:01:01 +1000 Content-Transfer-Encoding: 7bit Message-Id: <960F8BAD-43ED-4EA9-A022-E2CAD9751E45@apnic.net> References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1076) Cc: sidr@ietf.org Subject: Re: [sidr] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 01:00:58 -0000 On 30/10/2009, at 12:50 AM, Sandra Murphy wrote: > On Thu, 29 Oct 2009, Byron Ellacott wrote: > >> On 28/10/2009, at 11:30 AM, Randy Bush wrote: >> >>> 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)). >> >> I believe section 1.1 entirely addresses this point. The >> definition of IR does not preclude service providers, nor does the >> definition of ISP preclude either regional internet registries or >> end sites. Summarised, they are: >> >> IR : an entity undertaking the role of resource issuer. >> ISP : an entity undertaking the role of resource recipient who is >> the subject of a Resource Certificate. > > Under this definition of ISP, would an RIR that received resources > from IANA and received a resource certificate for those resources be > an ISP? 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 _____________________________________________________________________ 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 randy@psg.com Thu Oct 29 18:03: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 E3B993A68FB for ; Thu, 29 Oct 2009 18:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 lPKGRdGf+Y0S for ; Thu, 29 Oct 2009 18:03:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 0F7203A6851 for ; Thu, 29 Oct 2009 18:03:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N3ftg-00066i-6H; Fri, 30 Oct 2009 01:03:20 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 9E0FE2BC5FD9; Fri, 30 Oct 2009 10:03:19 +0900 (JST) Date: Fri, 30 Oct 2009 10:03:19 +0900 Message-ID: From: Randy Bush To: Byron Ellacott In-Reply-To: <960F8BAD-43ED-4EA9-A022-E2CAD9751E45@apnic.net> References: <65A69177-0471-45C0-945E-ACB55A84599D@apnic.net> <86AFFC12-1D74-4A95-9E63-C610EE20AE7A@apnic.net> <960F8BAD-43ED-4EA9-A022-E2CAD9751E45@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] Request for Last Call on draft-ietf-sidr-rescerts-provisioning-05 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 01:03:08 -0000 > Would a global replace of "ISP" with "subject" and "IR" with "issuer" > be a sufficient resolution of this discussion? makes sense to me, especially in the two level case. when you get to three or more, you may want grandchild/grandparent etc. the key point is that it is turtles all the way down. randy From terry.manderson@icann.org Thu Oct 29 21:00: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 862C93A67FF for ; Thu, 29 Oct 2009 21:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWJQ+dN6m5oR for ; Thu, 29 Oct 2009 21:00:24 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 72FAD3A67EF for ; Thu, 29 Oct 2009 21:00:24 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 29 Oct 2009 21:00:41 -0700 From: Terry Manderson To: Sandra Murphy , "sidr@ietf.org" Date: Thu, 29 Oct 2009 21:00:39 -0700 Thread-Topic: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt Thread-Index: AcpY4t7fD5rgvADSRUmQI9T/kiP44AAMqvah 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: "sra@isc.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: Fri, 30 Oct 2009 04:00:25 -0000 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 entir= e 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) i= s 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=3D"encoded hash of the subject public key]" /> Cheers Terry On 30/10/09 7:57 AM, "Sandra Murphy" wrote: > This WG chair has received a Working Group Last Call request from an > author of >=20 > A Protocol for Provisioning Resource Certificates >=20 > draft-ietf-sidr-rescerts-provisioning-05.txt >=20 > which has an intended status of Standard Track. >=20 >=20 > All versions, past and present, are available at >=20 > http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rescerts-provision= ing >=20 > The Last Call will end as of the close of business on Monday 23rd Novembe= r > - 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 > 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 no= t > expressing a view either way. >=20 > As for the other Standards Track documents, the chairs would like to > request the document's authors to prepare an interoperability report. >=20 >=20 >=20 > --Sandy >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From terry.manderson@icann.org Thu Oct 29 22:48: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 25B043A683B for ; Thu, 29 Oct 2009 22:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZuKtfY+ZpPa for ; Thu, 29 Oct 2009 22:48:44 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 61E7A3A67B2 for ; Thu, 29 Oct 2009 22:48:44 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.233]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 29 Oct 2009 22:49:01 -0700 From: Terry Manderson To: Sandra Murphy , "Pradosh Mohapatra (pmohapat)" Date: Thu, 29 Oct 2009 22:49:00 -0700 Thread-Topic: [sidr] draft-pmohapat-sidr-pfx-validate-03.txt as SIDR WG document Thread-Index: AcpXcKZn+ed0Ci1yQFih0R5Jb5EajgBtAc18 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] 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, 30 Oct 2009 05:48:45 -0000 I feel unable to say either way at present. The IPR disclosure at https://datatracker.ietf.org/ipr/1028/ highlights the US Patent Application Serial No. 12/243,767. In searching for this, at the USPTO I cannot find any relevant documents with that serial. I did try searching for "Cisco" as the named party - but it returned far more applications than I am willing to read through... A direct link to the Patent Application would be appreciated! Cheers Terry=20 On 28/10/09 11:47 AM, "Sandra Murphy" wrote: >=20 >=20 > I am opening a two week wg call for comments on the adoption of this > document as a working group item. >=20 > 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. >=20 > The document is available at: >=20 > http://www.ietf.org/id/draft-pmohapat-sidr-pfx-validate-03.txt >=20 > Please respond, either accept or not accept, by Tues Nov 3 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 als= o > indicate whether you will be able to work on the draft (contribute > or review). >=20 > --Sandy >=20 >=20 > On Tue, 27 Oct 2009, Pradosh Mohapatra (pmohapat) wrote: >=20 >> The authors would like to request that >> draft-pmohapat-sidr-pfx-validate-03.txt be adopted as a SIDR WG >> document. >>=20 >> Thanks, >> - Pradosh >> _______________________________________________ >> 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 robertl@apnic.net Thu Oct 29 23:05: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 40D153A6852 for ; Thu, 29 Oct 2009 23:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 tagged_above=-999 required=5 tests=[AWL=0.929, 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 NbbX3V5zc-cR for ; Thu, 29 Oct 2009 23:05:03 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id A47833A681E for ; Thu, 29 Oct 2009 23:05:02 -0700 (PDT) Received: from [203.119.42.208] (dynamic208.apnic.net [203.119.42.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2A89ED58BE; Fri, 30 Oct 2009 16:06:35 +1000 (EST) Message-ID: <4AEA821D.7040305@apnic.net> Date: Fri, 30 Oct 2009 16:05:17 +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: "sidr@ietf.org" 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 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, 30 Oct 2009 06:05:04 -0000 Terry Manderson wrote: > I feel unable to say either way at present. > ... > > A direct link to the Patent Application would be appreciated! Ditto. I'm reluctant to take any stance on this draft without more information on what the patent claims. 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 insufficient. 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 robertl@apnic.net Thu Oct 29 23:14: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 ED7913A680C for ; Thu, 29 Oct 2009 23:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[AWL=0.465, 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 z3FMygyMwlsf for ; Thu, 29 Oct 2009 23:14:24 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 695C53A63D3 for ; Thu, 29 Oct 2009 23:14:23 -0700 (PDT) Received: from [203.119.42.208] (dynamic208.apnic.net [203.119.42.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id AC468D58BE for ; Fri, 30 Oct 2009 16:15:56 +1000 (EST) Message-ID: <4AEA844F.4040805@apnic.net> Date: Fri, 30 Oct 2009 16:14:39 +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: sidr@ietf.org References: <5AE60ADD-C62F-4BD7-AA81-F84ECB79CDD2@apnic.net> 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 Subject: Re: [sidr] Request for WGLC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 06:14:25 -0000 Randy Bush wrote: >> draft-ietf-sidr-roa-validation-03.txt > > i object to last call on this. there is a conflicting draft, and one > not by a wg co-chair. As I understand it the WGLC for draft-ietf-sidr-roa-validation should be evaluated on the draft's own merits: If there are specific conflicts between this and draft-pmohapat-sidr-pfx-validate, could you please state what the difference of opinion is. If they simply cover the same ground, please say why the existing WG draft is insufficient. In either case, this would help clarify whether draft-ietf-sidr-roa-validation is sufficient as-is, needs nit fixes, or more. Thanks, 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 jmh@joelhalpern.com Fri Oct 30 08:35: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 48BF23A698B for ; Fri, 30 Oct 2009 08:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG5K5rtrr+Tr for ; Fri, 30 Oct 2009 08:35:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 996CD3A69AB for ; Fri, 30 Oct 2009 08:35:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1303A32317B3 for ; Fri, 30 Oct 2009 08:36:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-240.clppva.btas.verizon.net [71.161.50.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 9ADF932317AF for ; Fri, 30 Oct 2009 08:36:07 -0700 (PDT) Message-ID: <4AEB07E9.7010107@joelhalpern.com> Date: Fri, 30 Oct 2009 11:36:09 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: "sidr@ietf.org" References: <4AEA821D.7040305@apnic.net> In-Reply-To: <4AEA821D.7040305@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 30 Oct 2009 15:35:51 -0000 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 here. 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. 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. (This is separate from the additional, relevant, question that Robert asks.) Yours, Joel M. Halpern Robert Loomans wrote: > Terry Manderson wrote: >> I feel unable to say either way at present. >> > ... >> A direct link to the Patent Application would be appreciated! > > Ditto. I'm reluctant to take any stance on this draft without more > information on what the patent claims. > > 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 insufficient. > > Rob > From weiler@watson.org Fri Oct 30 08:47: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 39D803A69AF for ; Fri, 30 Oct 2009 08:47:12 -0700 (PDT) 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 U0qLjW12YWYf for ; Fri, 30 Oct 2009 08:47:11 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 643F73A6969 for ; Fri, 30 Oct 2009 08:47:11 -0700 (PDT) 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 n9UFlRg5080794 for ; Fri, 30 Oct 2009 11:47:27 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n9UFlRC4080791 for ; Fri, 30 Oct 2009 11:47:27 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 30 Oct 2009 11:47:27 -0400 (EDT) From: Samuel Weiler To: "sidr@ietf.org" In-Reply-To: <4AEA821D.7040305@apnic.net> Message-ID: References: <4AEA821D.7040305@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.0.1 (fledge.watson.org [127.0.0.1]); Fri, 30 Oct 2009 11:47:27 -0400 (EDT) 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, 30 Oct 2009 15:47:12 -0000 On Fri, 30 Oct 2009, Robert Loomans wrote: > 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 insufficient. I'll second this portion of Rob's note: I'd like some help understanding the differences in technical substance between these two documents. -- Sam From kent@bbn.com Fri Oct 30 08:51: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 4A5233A6802 for ; Fri, 30 Oct 2009 08:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 SycBnzroJx6z for ; Fri, 30 Oct 2009 08:51:10 -0700 (PDT) Received: from mx3.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0DB183A6828 for ; Fri, 30 Oct 2009 08:51:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N3tl5-0002JO-CM; Fri, 30 Oct 2009 11:51:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1CCB8133-6C27-480B-8A9A-196927F526C9@apnic.net> Date: Fri, 30 Oct 2009 11:51:20 -0400 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: George Michaelson , sidr 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: Fri, 30 Oct 2009 15:51:11 -0000 At 7:09 AM +0900 10/30/09, Randy Bush wrote: > > I believe the document needs to have the 3 hour time cycle removed, >> and some form of operational guidelines placed in a distinct document >> (whether 3 hours, or some other time, is up to that document) > >i suspect it belongs in the CP, but am not sure. > >randy I don't think this is a CP topic, because we're recommending a frequency of RP accesses to the repository. The CP could have addressed the complimentary topic of the frequency of CRL and cert publication, but Andrei convinced us that this should be left to the CPS of each CA. I think the arch doc could contain a paragraph discussing the issue, and proposing a default (for the reasons Rob cited) but not mandating a specific download frequency. Steve From weiler@watson.org Fri Oct 30 08:52: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 427433A6968 for ; Fri, 30 Oct 2009 08:52:05 -0700 (PDT) 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 BIE1JwRBY7Tu for ; Fri, 30 Oct 2009 08:52:04 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 67B0C3A6859 for ; Fri, 30 Oct 2009 08:52:04 -0700 (PDT) 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 n9UFqLVh081402; Fri, 30 Oct 2009 11:52:21 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n9UFqLFY081399; Fri, 30 Oct 2009 11:52:21 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 30 Oct 2009 11:52:20 -0400 (EDT) From: Samuel Weiler To: "Joel M. Halpern" In-Reply-To: <4AEB07E9.7010107@joelhalpern.com> Message-ID: References: <4AEA821D.7040305@apnic.net> <4AEB07E9.7010107@joelhalpern.com> 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.0.1 (fledge.watson.org [127.0.0.1]); Fri, 30 Oct 2009 11:52:21 -0400 (EDT) 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, 30 Oct 2009 15:52:05 -0000 On Fri, 30 Oct 2009, Joel M. Halpern wrote: > 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. HOWEVER: we have a technically similar draft that has been proposed for WGLC, and we have not heard a definitive statement about whether the IPR claims on draft-pmohapat-sidr-pfx-validate-03 would also apply to draft-ietf-sidr-roa-validation-03.txt. (I asked on this list last week.) Which doesn't complicate the adoption of this draft, but it might well complicate the WGLC on the current WG document. -- Sam From kent@bbn.com Fri Oct 30 13:45: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 B473E3A67F3 for ; Fri, 30 Oct 2009 13:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 o+CNIIcXYxeP for ; Fri, 30 Oct 2009 13:45:31 -0700 (PDT) Received: from mx3.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DDA583A6778 for ; Fri, 30 Oct 2009 13:45:31 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37614 helo=[192.168.1.5]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N3yLz-0001sS-C8; Fri, 30 Oct 2009 16:45:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 30 Oct 2009 16:45:45 -0400 To: Terry Manderson 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: Fri, 30 Oct 2009 20:45:32 -0000 At 8:52 PM -0700 10/28/09, Terry Manderson wrote: >Oppose. > >Although opposition is based on a small number of nits: > >* Section 1.7, page 11. "RPKI signed Object" ... "declared to be such by a >standards track RFC issued by the SIDR WG" > >Over time, the SIDR WG may not exist, or the name could change, or valid >RPKI objects come from other WG's. Perhaps 'issued by the IETF' Good point re the longevity of SIDR, but we need to be careful to not allow arbitrary definition of such objects. >* Section 3.1.1 Types of names. > >I think the section should it clear that names for the top level are >meaningless as covered in sidr-arch. It touches briefly on this in 3.1.3 >"(and Issuer)" but appears in my reading to be ambiguous. > >Perhaps " Names for IANA and RIRs will be meaningless directory >distinguished ....." We can add some more text to make such this is unambiguous. >* 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. The term "renewal" in the PKI space always means that the same subject is represented. the text in 3.2.1 mandates use of "proof of possession" mechanism for cert issuance, so it cannot be someone else's private key. we can say the same thing for renewal to ensure that this is not ambiguous. >* Sections 9.12.1, 9.12.2, 9.12.3.. If the CP is administered by the IESG >(section 1.6.1) shouldn't that also be reflected here? yes, those sections should have been updated as well. That was an oversight. Steve From kent@bbn.com Fri Oct 30 13: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 EFCB23A6A19 for ; Fri, 30 Oct 2009 13:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 cVvUiKmbLJye for ; Fri, 30 Oct 2009 13:48:16 -0700 (PDT) Received: from mx3.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 30E343A6778 for ; Fri, 30 Oct 2009 13:48:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55172 helo=[192.168.1.5]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N3yOf-0001vO-9h; Fri, 30 Oct 2009 16:48:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 30 Oct 2009 16:48:30 -0400 To: Terry Manderson 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-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: Fri, 30 Oct 2009 20:48:17 -0000 At 10:56 PM -0700 10/28/09, Terry Manderson wrote: >Oppose. > >the following, I think, needs attention. > >* 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. OK. The text should characterize rsync as being used for read access, and not for R/W. >* 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. Any widely distributed repository system will never be trusted to a high degree. The same threat model that motivates using DNESEC motivates using manifests. Steve From randy@psg.com Fri Oct 30 18:11: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 69ED63A6AB7 for ; Fri, 30 Oct 2009 18:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 YAKgMinGpbjD for ; Fri, 30 Oct 2009 18:11:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7B1823A6781 for ; Fri, 30 Oct 2009 18:11:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N42VO-000A4z-EC; Sat, 31 Oct 2009 01:11:46 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id E0F6D2BCB387; Sat, 31 Oct 2009 10:11:45 +0900 (JST) Date: Sat, 31 Oct 2009 10:11:45 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: <1CCB8133-6C27-480B-8A9A-196927F526C9@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: George Michaelson , sidr 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: Sat, 31 Oct 2009 01:11:36 -0000 > I don't think this is a CP topic, because we're recommending a > frequency of RP accesses to the repository. point taken. this makes sense. > The CP could have addressed the complimentary topic of the frequency > of CRL and cert publication, but Andrei convinced us that this should > be left to the CPS of each CA. color me quite unconvinced. this is a global internet. as someone betting my routing on roas, i don't care which IR in the chain caused the delay, as i can not route on blame. randy From randy@psg.com Fri Oct 30 18:24: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 D04F33A6ABD for ; Fri, 30 Oct 2009 18:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 xq1xtr800G2e for ; Fri, 30 Oct 2009 18:24:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id E6CA13A6781 for ; Fri, 30 Oct 2009 18:24:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1N42hh-000A7F-Aa; Sat, 31 Oct 2009 01:24:29 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id C425B2BCB506; Sat, 31 Oct 2009 10:24:28 +0900 (JST) Date: Sat, 31 Oct 2009 10:24:28 +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] 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: Sat, 31 Oct 2009 01:24:22 -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? randy From danny@tcb.net Sat Oct 31 07:07: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 D3CC33A680C for ; Sat, 31 Oct 2009 07:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=1.119, 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 6+e53X5qrXjJ for ; Sat, 31 Oct 2009 07:07:37 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 1199C3A67F0 for ; Sat, 31 Oct 2009 07:07:37 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id E29482684EA; Sat, 31 Oct 2009 08:07:54 -0600 (MDT) Received: from [192.168.1.64] (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sat, 31 Oct 2009 08:07:54 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=62667; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Content-Type: text/plain; charset=us-ascii; format=flowed Mime-Version: 1.0 (Apple Message framework v1076) From: Danny McPherson In-Reply-To: <11856BC4-5462-4AB1-A175-D6D70EE10B63@apnic.net> Date: Sat, 31 Oct 2009 08:07:54 -0600 Content-Transfer-Encoding: 7bit Message-Id: <89658BEC-0F8E-44E6-81E9-5010A1FF7523@tcb.net> References: <4AE6160D.8000503@bbn.com> <38FCEA94-4D74-47F0-BD36-B42338474C2E@apnic.net> <4AE75809.4050808@bbn.com> <11856BC4-5462-4AB1-A175-D6D70EE10B63@apnic.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1076) 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, 31 Oct 2009 14:07:38 -0000 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. -danny From jared@puck.nether.net Sat Oct 31 09:22: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 5C0733A67FD for ; Sat, 31 Oct 2009 09:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5P74YVasO8O for ; Sat, 31 Oct 2009 09:22:35 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by core3.amsl.com (Postfix) with ESMTP id 41AE13A6783 for ; Sat, 31 Oct 2009 09:22:35 -0700 (PDT) Received: from [10.52.41.100] (mobile-166-137-137-047.mycingular.net [166.137.137.47]) (authenticated bits=0) by puck.nether.net (8.14.3/8.12.9) with ESMTP id n9VGN5bn093437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 31 Oct 2009 12:23:09 -0400 (EDT) (envelope-from jared@puck.nether.net) From: Jared Mauch To: Danny McPherson In-Reply-To: <89658BEC-0F8E-44E6-81E9-5010A1FF7523@tcb.net> X-Mailer: iPhone Mail (7D11) 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> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 31 Oct 2009 12:22:49 -0400 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (puck.nether.net [204.42.254.5]); Sat, 31 Oct 2009 12:23:12 -0400 (EDT) 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: Sat, 31 Oct 2009 16:22:36 -0000 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