From root@core3.amsl.com Tue Mar 2 14:15:31 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C3CED28C188; Tue, 2 Mar 2010 14:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100302221504.C3CED28C188@core3.amsl.com> Date: Tue, 2 Mar 2010 14:15:02 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:15:31 -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 : Validation of Route Origination using the Resource Certificate PKI and ROAs Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-04.txt Pages : 9 Date : 2010-03-02 This document defines the semantics of a Route Origin Authorization in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-04.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-validation-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-02141311.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Mar 2 20:00:01 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A362A3A8A35; Tue, 2 Mar 2010 20:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100303040001.A362A3A8A35@core3.amsl.com> Date: Tue, 2 Mar 2010 20:00:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-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: Wed, 03 Mar 2010 04:00: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 : Validation of Route Origination using the Resource Certificate PKI and ROAs Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-05.txt Pages : 9 Date : 2010-03-02 This document defines the semantics of a Route Origin Authorization in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-05.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-validation-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-02195024.I-D@ietf.org> --NextPart-- From Sandra.Murphy@cobham.com Fri Mar 5 14:04:52 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B0228C393 for ; Fri, 5 Mar 2010 14:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-3YfUZxRt0Y for ; Fri, 5 Mar 2010 14:04:52 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id EAB4C28C12B for ; Fri, 5 Mar 2010 14:04:51 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o25M4sOe020104 for ; Fri, 5 Mar 2010 16:04:54 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o25M4rXi025759 for ; Fri, 5 Mar 2010 16:04:53 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 17:04:52 -0500 Date: Fri, 5 Mar 2010 17:04:52 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Mar 2010 22:04:52.0790 (UTC) FILETIME=[E1D96560:01CABCAF] Subject: [sidr] IETF 77 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: Fri, 05 Mar 2010 22:04:53 -0000 Note the following important dates having to do with the upcoming IETF in Anaheim. 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission Tool. 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. 2010-03-10 (Wednesday): Draft Working Group agendas due by 17:00 PST (01:00 Thursday, March 11 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-12 (Friday): Early Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, March 13 UTC). 2010-03-15 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-03-15 (Monday): Registration cancellation cut-off at 17:00 PDT (24:00 UTC). 2010-03-19 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC). --Sandy From Sandra.Murphy@cobham.com Fri Mar 5 14:05:46 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C820328C393 for ; Fri, 5 Mar 2010 14:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjTwLRTyoHXy for ; Fri, 5 Mar 2010 14:05:45 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 598D128B23E for ; Fri, 5 Mar 2010 14:05:45 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o25M5lkh020112 for ; Fri, 5 Mar 2010 16:05:47 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o25M5lfn025832 for ; Fri, 5 Mar 2010 16:05:47 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 17:05:46 -0500 Date: Fri, 5 Mar 2010 17:05:46 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Mar 2010 22:05:47.0072 (UTC) FILETIME=[02342C00:01CABCB0] Subject: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 05 Mar 2010 22:05:46 -0000 The authors of Certificate Policy (CP) for the Resource PKI (RPKI) have submitted a new version in accordance with comments received in the last call (http://tools.ietf.org/html/draft-ietf-sidr-cp-08). I am opening a last call on this document for one week, ending Friday, March 12. Note that comments on this revision are restricted to whether the issues have been adequately addressed. --Sandy From Sandra.Murphy@cobham.com Fri Mar 5 15:01:56 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE5228C16E for ; Fri, 5 Mar 2010 15:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OcU4KSEvVFF for ; Fri, 5 Mar 2010 15:01:56 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id EFEA728C15C for ; Fri, 5 Mar 2010 15:01:55 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o25N1wLm020731 for ; Fri, 5 Mar 2010 17:01:58 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o25N1wCq027628 for ; Fri, 5 Mar 2010 17:01:58 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 18:01:57 -0500 Date: Fri, 5 Mar 2010 18:01:57 -0500 (Eastern Standard 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: 05 Mar 2010 23:01:57.0906 (UTC) FILETIME=[DB609F20:01CABCB7] 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: Fri, 05 Mar 2010 23:01:57 -0000 In the last call, I noted that this draft had not had a significant amount of review in the wg. In the last IETF meeting, Geoff and I both reiterated the need for comment on all last called drafts. Even so, there has been only four comments on this draft (even counting mine which was made with wg chair hat off). The history of the draft is that it was presented as an individual submission in IETF 66, IETF 71 and IETF 72 (briefly), it was proposed and adopted as a working group draft, and it has not been presented since. The versions that have been submitted since wg adoption have been boilerplate changes and other superficial changes only. In the meantime, many of the drafts on which it relies have changed considerably It is possible that the authors attained perfection without effort in this case. I still would prefer that there was more evidence that the wg had adequately reviewed this document. I can not now judge this draft as having consensus. I have asked all those who responded positively to the call for adoption to review the current draft. I have also asked authors of all drafts that refer to this draft to inform the wg that they have reviewed this draft and it is adequate for use in their work. (I am making an exception where the authors of this draft and a referring draft overlap, of course.) --Sandy From Sandra.Murphy@cobham.com Fri Mar 5 15:02:15 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F48A28C3DF for ; Fri, 5 Mar 2010 15:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLWnA8dwXbyE for ; Fri, 5 Mar 2010 15:02:14 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4168528C15C for ; Fri, 5 Mar 2010 15:02:14 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o25N2G02020739 for ; Fri, 5 Mar 2010 17:02:16 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o25N2G3e027637 for ; Fri, 5 Mar 2010 17:02:16 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 18:02:16 -0500 Date: Fri, 5 Mar 2010 18:02:15 -0500 (Eastern Standard 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: 05 Mar 2010 23:02:16.0328 (UTC) FILETIME=[E65B9880:01CABCB7] 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: Fri, 05 Mar 2010 23:02:15 -0000 The presentations at the IETF meeting and the comments in response to the res-certs last call mentioned no desirable changes in the res-certs draft. But the res-certs authors tell me that they have taken the discussion of the desire for a serial name component to the subject name to heart and plan on making a change to allow this in the res-certs draft. (See issue #8 in the issue tracker and the discussion thread "multi-value distinguished name question", "more CA info", "OpenCA info", and "where to document the new name constraints" in the list archive.) I invite the authors to submit a new version of the draft with this has been addressed. When a new version is available, there will be a short one week last call, with comments restricted to whether the issue has been adequately addressed. --Sandy From Sandra.Murphy@cobham.com Fri Mar 5 15:16:14 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0E03A8710 for ; Fri, 5 Mar 2010 15:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 fMFIMsBlKND7 for ; Fri, 5 Mar 2010 15:16:13 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id DF7133A743D for ; Fri, 5 Mar 2010 15:16:12 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o25NGEE3020854 for ; Fri, 5 Mar 2010 17:16:15 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o25NGEEi028037 for ; Fri, 5 Mar 2010 17:16:15 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 18:16:14 -0500 Date: Fri, 5 Mar 2010 18:16:14 -0500 (Eastern Standard 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: 05 Mar 2010 23:16:14.0567 (UTC) FILETIME=[D9FCB770:01CABCB9] 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, 05 Mar 2010 23:16:14 -0000 The discussion of the provisioning draft has been small but sufficient to make a judgement. A comment from Terry (http://www.ietf.org/mail-archive/web/sidr/current/msg01256.html) produced two different threads of comments. There was a brief but intense exchange between Terry, Rob and Steve in the week following the last call regarding the use of CMS and TLS/HTTPS. That exchange died off without a resolution and recently resumed. Another brief exchange occurred in the last few days of November (starting with a response to Terry http://www.ietf.org/mail-archive/web/sidr/current/msg01422.html) and addressed several matters of terminology in the draft. That discussion also did not seem to reach a conclusion. I invite the authors to work submit a new version of the draft addressing these issues. When a new version is available, there will be a short one week last call, with comments restricted to whether the issues have been adequately addressed. --Sandy From turners@ieca.com Fri Mar 5 15:18:55 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B6B3A8CBC for ; Fri, 5 Mar 2010 15:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 X0GUJ73bTm0K for ; Fri, 5 Mar 2010 15:18:47 -0800 (PST) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id EEC323A8710 for ; Fri, 5 Mar 2010 15:18:44 -0800 (PST) Received: (qmail 20416 invoked from network); 5 Mar 2010 23:18:45 -0000 Received: from thunderfish.local (turners@96.231.117.33 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 05 Mar 2010 15:18:45 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: dgnvt0MVM1lQ3gn6QkyoYmi4VtnUNm2WKkLVhHFLFy5Ike3J04Xuw7LcSfSydF_NhLzAHn2FnlSS3fd.m_NwTVKrpXX_vCz_6MJf.Ro3po3QFBZTUuoJsOLZgZJ_uf4wLKP.YwO59aFiODqKRUFXknl_Q1asq0TR6hRZLz_b6W2ck_mMptIBC.ST.rfD7boBLCMUfCWyyhlItkd72byYGkyBwnOry0Qu5kLVFqU4dF1TBtw2aZnvUXr7l3fFhWDqw1hnn0G4La1OrnTJNaMKrD4DRTTdnpPz5ZxYKrjy_TOD8pjU2oKJg.KBGxa3WbIut3KfLLkUQFR9h9CUiWpaAGu.X3hZBaZ7SbZfrK4c30KpJnTy.Tz.4atymr2LOWWQYN3ISMeqs5dlbfDioSCAG.CdtglUZtJd_nWRL1Db6iJ8PTqjcbtIN0ZiqwDszTPLiwtZW9WAhyOLgcq3 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B919154.1080403@ieca.com> Date: Fri, 05 Mar 2010 18:18:44 -0500 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 05 Mar 2010 23:18:56 -0000 Is there only one RFC 2119 keyword in the ID on purpose (one "MUST" in section 2.3). spt Sandra Murphy wrote: > The authors of Certificate Policy (CP) for the Resource PKI (RPKI) have > submitted a new version in accordance with comments received in the last > call (http://tools.ietf.org/html/draft-ietf-sidr-cp-08). > > I am opening a last call on this document for one week, ending Friday, > March 12. > > Note that comments on this revision are restricted to whether the issues > have been adequately addressed. > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Fri Mar 5 15:19:34 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C5D28C3EB for ; Fri, 5 Mar 2010 15:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uX-vQJ3EpH-L for ; Fri, 5 Mar 2010 15:19:32 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0B86128C3C0 for ; Fri, 5 Mar 2010 15:19:27 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o25NJUZp020866 for ; Fri, 5 Mar 2010 17:19:30 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o25NJUKO028093 for ; Fri, 5 Mar 2010 17:19:30 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 18:19:29 -0500 Date: Fri, 5 Mar 2010 18:19:29 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 05 Mar 2010 23:19:30.0069 (UTC) FILETIME=[4E83F450:01CABCBA] Subject: [sidr] comments on 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: Fri, 05 Mar 2010 23:19:34 -0000 One comment to the list (http://www.ietf.org/mail-archive/web/sidr/current/msg01428.html) mentioned the language used to describe signing objects and certificates. The message suggested that the very precise language be used at the beginning with a statement that the common but imprecise language used elsewhere meant the same thing. As wg chair, I received a strong protest to allowing the imprecise language in the draft and assuring me that this would be raised in IETF last call if allowed. The protester volunteered to work with the authors to provide suggestions for precise language in each use in the draft. --Sandy From trac@tools.ietf.org Fri Mar 5 15:29:20 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181BF3A8DEE for ; Fri, 5 Mar 2010 15:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6aLPsuAf4Vwb for ; Fri, 5 Mar 2010 15:29:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4E4383A7F7A for ; Fri, 5 Mar 2010 15:29:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NngxO-0006F0-1J; Fri, 05 Mar 2010 15:29:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: sandy@sparta.com X-Trac-Project: sidr Date: Fri, 05 Mar 2010 23:29:22 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/16 Message-ID: <055.f375f0b7ed848fcae806723c4a160ef9@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sandy@sparta.com, 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] #16: use of CMS and TLS and HTTPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:29:20 -0000 #16: use of CMS and TLS and HTTPS ------------------------------+--------------------------------------------- Reporter: sandy@… | Owner: Type: task | Status: new Priority: medium | Milestone: Component: arch | Version: Severity: - | Keywords: ------------------------------+--------------------------------------------- Starting with a comment from Terry http://www.ietf.org/mail- archive/web/sidr/current/msg01256.html There was a brief but intense exchange between Terry, Rob and Steve in the week following the last call regarding the use of CMS and TLS/HTTPS. That exchange died off without a resolution but just recently resumed. -- Ticket URL: sidr From trac@tools.ietf.org Fri Mar 5 15:33:35 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6F528C3ED for ; Fri, 5 Mar 2010 15:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwcgzRSrkwZ1 for ; Fri, 5 Mar 2010 15:33:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9848D28C405 for ; Fri, 5 Mar 2010 15:33:17 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nnh1E-0006W2-Jj; Fri, 05 Mar 2010 15:33:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: sandy@sparta.com X-Trac-Project: sidr Date: Fri, 05 Mar 2010 23:33:20 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/17 Message-ID: <055.45732c3e2bb019f9a217c13a54c3d045@tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sandy@sparta.com, 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] #17: editorial concerns for rescerts-provisioning-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:33:35 -0000 #17: editorial concerns for rescerts-provisioning-05.txt -----------------------------------+---------------------------------------- Reporter: sandy@… | Owner: Type: defect | Status: new Priority: medium | Milestone: Component: rescerts-provisioning | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Starting with a comment from Terry http://www.ietf.org/mail- archive/web/sidr/current/msg01256.html, and a response to Terry http://www.ietf.org/mail-archive/web/sidr/current/msg01422.html Another brief exchange occurred in the last few days of November and addressed editorial concerns in the draft. That discussion also did not seem to reach a conclusion. -- Ticket URL: sidr From trac@tools.ietf.org Fri Mar 5 15:34:32 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C71B28C3ED for ; Fri, 5 Mar 2010 15:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRLMvzLKz+vB for ; Fri, 5 Mar 2010 15:34:31 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 98F0828C421 for ; Fri, 5 Mar 2010 15:34:30 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nnh2P-0006bQ-JR; Fri, 05 Mar 2010 15:34:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: sandy@sparta.com X-Trac-Project: sidr Date: Fri, 05 Mar 2010 23:34:33 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/16#comment:1 Message-ID: <064.da5185297a03df1a48f3dc2acedd41a0@tools.ietf.org> References: <055.f375f0b7ed848fcae806723c4a160ef9@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <055.f375f0b7ed848fcae806723c4a160ef9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sandy@sparta.com, 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] #16: use of CMS and TLS and HTTPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:34:32 -0000 #16: use of CMS and TLS and HTTPS -----------------------------------+---------------------------------------- Reporter: sandy@… | Owner: Type: task | Status: new Priority: medium | Milestone: Component: rescerts-provisioning | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Changes (by sandy@…): * component: arch => rescerts-provisioning -- Ticket URL: sidr From trac@tools.ietf.org Fri Mar 5 15:50:37 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B12428C0DE for ; Fri, 5 Mar 2010 15:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVPN8uSZl7M3 for ; Fri, 5 Mar 2010 15:50:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3B4C83A9037 for ; Fri, 5 Mar 2010 15:50:35 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NnhHy-0008DH-I4; Fri, 05 Mar 2010 15:50:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sidr issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: sandy@sparta.com X-Trac-Project: sidr Date: Fri, 05 Mar 2010 23:50:38 -0000 X-URL: http://tools.ietf.org/sidr/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sidr/trac/ticket/18 Message-ID: <055.0dec59c809e4ef0485184c8afd431200@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sandy@sparta.com, 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] #18: language describing signing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:50:37 -0000 #18: language describing signing ------------------------------+--------------------------------------------- Reporter: sandy@… | Owner: Type: enhancement | Status: new Priority: medium | Milestone: Component: repos-struct | Version: Severity: - | Keywords: ------------------------------+--------------------------------------------- One comment to the list (http://www.ietf.org/mail- archive/web/sidr/current/msg01428.html) mentioned the language used in the repos-struct draft to describe signing objects and certificates. Many times the draft uses a common but imprecise terminology that says the certificate is used to sign an object, when actually it is the private key associated with the public key certified by the certificate that is used. -- Ticket URL: sidr From Sandra.Murphy@cobham.com Fri Mar 5 16:02:56 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B4E3A903E for ; Fri, 5 Mar 2010 16:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 SPDGHAj8cQii for ; Fri, 5 Mar 2010 16:02:55 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5A3913A9037 for ; Fri, 5 Mar 2010 16:02:55 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o2602vgD021204 for ; Fri, 5 Mar 2010 18:02:57 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o2602vuh029256 for ; Fri, 5 Mar 2010 18:02:57 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 19:02:57 -0500 Date: Fri, 5 Mar 2010 19:02:56 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 06 Mar 2010 00:02:57.0320 (UTC) FILETIME=[608EE280:01CABCC0] Subject: [sidr] second algorithm and transition process X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 06 Mar 2010 00:02:56 -0000 In the last IETF meeting, Tim Polk speaking as security AD said that the matter of algorithm agility could be addressed by producing a draft describing a second algorithm and a draft describing an algorithm transition process, subject to concurrence by his co-AD. I've not heard from Tim about his co-AD's acceptance of this strategy, but I suggest that we proceed with this. I would like to hear from volunteers who would be willing to take the pen to write either of these drafts. I believe that the second algorithm draft should be straightforward (Tim suggested ECDSA). I don't believe that the transition process is quite so straightforward and I invite everyone to begin to discuss this on list. --Sandy From kent@bbn.com Sat Mar 6 12:22:38 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4EA28C197 for ; Sat, 6 Mar 2010 12:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgi-Ou02UswJ for ; Sat, 6 Mar 2010 12:22:28 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 87D5428C0F0 for ; Sat, 6 Mar 2010 12:22:28 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.242.22.66]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1No0W6-0007Jq-Bz; Sat, 06 Mar 2010 15:22:30 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 6 Mar 2010 15:18:51 -0500 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] second algorithm and transition process X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 06 Mar 2010 20:22:38 -0000 Sandy, I will be happy to work on both drafts, assuming others volunteer :-). Steve From root@core3.amsl.com Mon Mar 8 02:45:03 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 606D33A68AB; Mon, 8 Mar 2010 02:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308104503.606D33A68AB@core3.amsl.com> Date: Mon, 8 Mar 2010 02:45:02 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpsl-sig-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: Mon, 08 Mar 2010 10:45:03 -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 : Securing RPSL Objects with RPKI Signatures Author(s) : R. Kisteleki, J. Boumans Filename : draft-ietf-sidr-rpsl-sig-02.txt Pages : 12 Date : 2010-03-08 This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpsl-sig-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpsl-sig-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08023935.I-D@ietf.org> --NextPart-- From danny@tcb.net Mon Mar 8 06:37:36 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E39103A69BC for ; Mon, 8 Mar 2010 06:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KHaQHZSQ7+D for ; Mon, 8 Mar 2010 06:37:36 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E4C6F3A69B4 for ; Mon, 8 Mar 2010 06:37:35 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id B8A42268674; Mon, 8 Mar 2010 07:37:39 -0700 (MST) Received: from [192.168.1.64] (97-118-239-19.hlrn.qwest.net [97.118.239.19]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 08 Mar 2010 07:37:39 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.118.239.19; client-port=56014; syn-fingerprint=65535:56:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 8 Mar 2010 07:37:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51218418-1F4D-46DF-B4C1-A07F3CCBA8D8@tcb.net> References: To: Samuel Weiler X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] Working Group Last Call for etf-sidr-repos-struct-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:37:37 -0000 Top post only.. =20 I agree with Sam's comments here. Additionally, and not surprisingly, I'd also very much like to see=20 my earlier comments on this document addressed before it warrants=20 cycles for another full review on my part. Thanks,=20 -danny On Nov 25, 2009, at 1:07 PM, Samuel Weiler wrote: > As best I can tell, the technical substance of sidr-repos-struct-03 is = in fine shape. That said, I found the document difficult to review, = largely due to the style of its writing. While I recognize that this = may be merely a matter of stylistic preference, I find the writing = unnecessarily verbose and unapproachable. >=20 > I notice that the only two other WGLC reviews of this doc came from = native English speakers, one of whom has been deeply involved in the = work for years. I think the doc has not gotten adequate review, I think = that is in large part because of the writing. >=20 > I think this document would benefit greatly from an editorial pass, = probably from a different editor. Assuming someone can be found to do = that, I support delaying the publication in the interest of producing a = more readable document. >=20 > And, as I noted in my WGLC review of the architecture draft, I have = some reservations about pushing these docs out without having the = validation algorithm nailed down (including the handling of incremental = deployment). In the case of this document, noting that it has normative = references to the architecture and manifests docs, which are more likely = to see changes from changing the validation scheme, I don't see any harm = in sending it forward. >=20 >=20 > Specific suggestions >=20 > Danny McPherson's comments on ths draft from 3 December 2008 don't = appear to have been incorporated nor responded to on the list. (e.g. = "complete set" is still a strange phrasing, and the spelling nits = haven't been fixed) >=20 > Rsync is not mentioned in the intro. Instead of just referring to = "publication points", adding the concreteness of "rsync" at that stage = would help make the doc clearer. >=20 > Section 1: "A Resource Certificate describes an action by an Issuer = that binds a list of IP address blocks and AS numbers to the Subject of = a certificate, identified by the unique association of the Subject's = private key with the public key contained in the Resource Certificate." = "describes an action"? Surely there's a better way to say that. >=20 > I'm not sure that Section 2.2 paragraph on naming certificates is = consistent with section 4's guidance on persistent naming. Which may be = more about how hard it was to understand section 2.2 than about any real = differences. >=20 >=20 > Nits >=20 > The rsync reference appears to be truncated. >=20 > Spelling: > s/performss/performs/ > s/Becuase/Because/ > s/Whn/When/ > s/traveral/traversal/ > (and there are surely others, including some that Danny pointed out) >=20 > -- Sam >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From root@core3.amsl.com Mon Mar 8 17:00:01 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9FF673A6C54; Mon, 8 Mar 2010 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100309010001.9FF673A6C54@core3.amsl.com> Date: Mon, 8 Mar 2010 17:00:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-cps-irs-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 01:00: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 : Template for an Internet Registry's Certification Practice Statement (CPS) for the Resource PKI (RPKI) Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cps-irs-05.txt Pages : 42 Date : 2010-03-08 This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Registry (e.g., NIR or RIR) that is part of the Resource Public Key Infrastructure (RPKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-05.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-cps-irs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08164637.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Mar 8 17:00:01 2010 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D51FD3A6C5C; Mon, 8 Mar 2010 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100309010001.D51FD3A6C5C@core3.amsl.com> Date: Mon, 8 Mar 2010 17:00:01 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-cps-isp-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 01:00: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 : Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Resource PKI (RPKI) Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cps-isp-04.txt Pages : 43 Date : 2010-03-08 This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Service Provider (ISP) that is part of the Resource Public Key Infrastructure (RPKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-04.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-cps-isp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08165009.I-D@ietf.org> --NextPart-- From gih@apnic.net Mon Mar 8 17:22:21 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194CB3A6B82 for ; Mon, 8 Mar 2010 17:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 h-WiBLARsfOF for ; Mon, 8 Mar 2010 17:22:18 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id E63A33A6AA8 for ; Mon, 8 Mar 2010 17:22:17 -0800 (PST) Received: from aarnet-edm.canberra.aarnet.edu.au (aarnet-edm.canberra.aarnet.edu.au [202.158.221.35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 598B6D5881; Tue, 9 Mar 2010 11:35:57 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Tue, 9 Mar 2010 12:17:19 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8762C772-6F00-4C64-8BE9-29437B6441E2@apnic.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Cc: dkong@bbn.com, skent@bbn.com, rwatro@bbn.com Subject: Re: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Mar 2010 01:22:21 -0000 I do not believe that this document is ready for submission to the IESG. = Some issues still remain with this document, as listed below. Geoff On 06/03/2010, at 9:05 AM, Sandra Murphy wrote: > The authors of Certificate Policy (CP) for the Resource PKI (RPKI) = have submitted a new version in accordance with comments received in the = last call (http://tools.ietf.org/html/draft-ietf-sidr-cp-08). >=20 > I am opening a last call on this document for one week, ending Friday, = March 12. >=20 > Note that comments on this revision are restricted to whether the = issues have been adequately addressed. >=20 1. Introduction, para 1 - is the use of the verb "will" normative (i.e. = MUST), or intentional "SHOULD" or optional" "MAY". I'd like to see the = second sentence changed to say "MAY" or if that is not acceptable, to = say "may" 2. Introduction, para 1 - third sentence - is this "will" more = accurately a "can" 3. Introduction, para1, third sentence - "uniqueness" is not an outcome = of verification of a certificate. It would be more accurate to drop = "uniqueness" from this assertion. 4. section 1.2, para 1. The same assertion is made that associated = certification with uniqueness. The constraint on an address issuer that = creates a unique distribution of resources is not an intrinsic attribute = of certification of the issuance. 5. section 1.4.1 - the document appears to preclude the actions of LIRs = / ISPS in distributing AS numbers. I do not believe that this is = appropriate, nor accurate, in today's environment 6. section 2.2 - is a CA responsible for publishing ALL certifications = it issues, or can it be selective in publication? The section is unclear = on this 7. section 2.2 - a similar question is raised regarding CRLs and = RPKI-signed objects. Is the CA requires to publish ALL such issued = objects? 8 section 2.3 - the document does not specify a CA's actions regarding = the publication of expired and revoked certifications, nor indicate of = the CA's CPS should include such information. 9. section 2.4 - is the "shall" here a "SHALL" in a normative sense or a = "MAY"? 10. section 3.2.1 - is this "will require" a MUST require or a SHOULD = require? 11. section 3.2.2 - is this "will" a MUST, SHOULD or a MAY? 12. section 3.2.3 - is this "will" a MUST, SHOULD or a MAY? 13. section 3.2.5 - is this "will" a MUST, SHOULD or a MAY? - This = occurs in subsequent sections that describe actions of the CA, and the = use of normative language in describing these CA actions is recommended. = These instances are not further flagged here,. 14. sections 3.2 and 3.2 - I am not sure that these need to be separate = - for example is issuance after revocation any different from initial = issuance - i.e. the same criteria of 3.2.1, 3.2.2, 3.2.3 and 3.2.5 = apply, so why is 3.3.2 called out - what new information is being = provided here that is not already provided in the previous section? 15. section 3.4 - why does this section of the text NOT refer to the = actions of a CA as described in sections 3.2.1, 3.2.2, 3.2.3 and 3.2.5? = It appears that revocation is described in more informal terms and = issuance, yet the constraints on the CA to ensure that authenticity of = the request are intended to be the same. 16. section 4.1.1 - normative language required - the "should" referred = to here is unclear. Subsequent sections also use "should" where = normative language would be clearer. 17. section 4.5.2 - this section refers to "all the CAs in the chain = that issued the certificates relevant to the certificate in question" = without further clarification or explanation. In the light of related = work on local TA generation I am left with the question of what exactly = is being referred to here in this "chain"./ I would prefer this term to = be defined. 18. section 4.8 - why is the treatment of augmentation of a subject's = INRs treated differently to reduction in a subject's INRs? While = section 4.8 deals with the steps involved in issuing a new certification = in the case where a subject's INR's are augmented, there is no = corresponding description of the process in reduction, other that the = single sentence in section 4.8.1 that does not refer to any other part = of the CPS. 19 section 4.10 - is it truye to say that "This PKI does not make use of = OCSP or SCVP" or is it more appropriate to state that "RPs SHOULD NOT = rely on the use of OCSP or SCVP"? 20 - section 5.8 "The termination of a CA shall therefore be subject to = the agreement between the issuer and the subscriber and will be = described in the CPS for the issuer." I am finding it difficult to = reconcile this need for "an agreement" in the light of the observation = that where a CA no longer has any INR resources then it cannot function = as a CA in the RPKI, whether or not an agreement is reached, Why then is = an agreement stipulated here? Style comment: Is the use of double ' chars instead of a " or ' char deliberate? For = example, I would've expected to see " marks in section 1.3 when = describing the name of the document, and thereafter when denoting the = use of particular terms. From kseo@bbn.com Mon Mar 8 19:58:57 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7893A6837 for ; Mon, 8 Mar 2010 19:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHKhE9pPCGs3 for ; Mon, 8 Mar 2010 19:58:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1B3E13A67F4 for ; Mon, 8 Mar 2010 19:58:57 -0800 (PST) Received: from [128.89.252.228] (helo=[192.168.1.100]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Noqay-000G2y-JU; Mon, 08 Mar 2010 22:59:00 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B919154.1080403@ieca.com> References: <4B919154.1080403@ieca.com> Date: Mon, 8 Mar 2010 22:58:59 -0500 To: Sean Turner From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Mar 2010 03:58:57 -0000 Hi, Sean, >Is there only one RFC 2119 keyword in the ID on purpose (one "MUST" >in section 2.3). No, my oversight. I was under the impression that the draft needed only the changes that were brought up in the previous WG Last Call and at IETF 76 and consequently didn't do a more global review/editorial pass. So while the current wording reflects the past year's feedback (and maybe folks' desire to be diplomatic), I should have replaced a number of "will"s, "may"s, etc. with RFC 2119 keywords. Thank you, Karen From kseo@bbn.com Mon Mar 8 20:12:38 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1491B3A6834 for ; Mon, 8 Mar 2010 20:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 TCm3j1Ob7gxv for ; Mon, 8 Mar 2010 20:12:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1146A3A67F4 for ; Mon, 8 Mar 2010 20:12:37 -0800 (PST) Received: from [128.89.252.228] (helo=[192.168.1.100]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NoqoC-000G5h-TL; Mon, 08 Mar 2010 23:12:41 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 8 Mar 2010 23:12:39 -0500 To: sidr@ietf.org From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] RPKI CPS templates for RIRs and for ISPs X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Mar 2010 04:12:38 -0000 Folks, We just submitted updated versions of the two CPS template drafts (ISP and Internet Registry). While I did make some keyword changes, I ran out of time so there are still some places where "will"s should be "MUST"s, etc. The CPS revisions (from the last drafts submitted in October 2008) are focussed on trying to bring the two CPS's into alignment with the changes that have been made in the CP. These include but are not limited to: - terminology - assign/allocate --> distribute - AS#, IP address --> Internet Number Resource (INR) - resource/certificate holder --> subscriber - use of the more general term "RPKI-signed" object in place of ROA - removed mention of LIRs, just using ISP - upload/post --> publish to/via - removal of routing and ROA references - shortening RPKI background text - moving a number of details from the CP to the CPS, e.g., - applying for a certificate - circumstances for revocation - CA/RA termination - responsibilities of the relying party - time constraints for publication, notification, etc. - removal of sections marked "omitted" (except for a few where I ran into Microsoft Word problems) - reference to algorithm draft I also spent some time trying to make the two drafts use the same wording where possible. Between that and some of the changes mentioned above, e.g., the removal of the routing/ROA examples/text and the switch to INR (vs "IP address" or "AS# and IP address") the drafts are now very similar. So, it might make sense to combine them and simply have text specific to each case where appropriate. Thank you, Karen From gih@apnic.net Tue Mar 9 12:01:04 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BCB3A6A62 for ; Tue, 9 Mar 2010 12:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOIJVum6XoQo for ; Tue, 9 Mar 2010 12:00:58 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 0745D3A6A30 for ; Tue, 9 Mar 2010 12:00:35 -0800 (PST) Received: from dhcp205.potaroo.net (220-253-241-176.NSW.netspace.net.au [220.253.241.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 77392D58B2; Wed, 10 Mar 2010 06:18:49 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 10 Mar 2010 07:00:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C6E91F4-33B0-4B2E-8324-3FD4D2880E18@apnic.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Mar 2010 20:01:04 -0000 [I have been informed that my note I posted yesterday in response to the = Last Call did not get circulated on the SIDR mailing list - I'll try = once more - Geoff] I do not believe that this document is ready for submission to the IESG. = Some issues still remain with this document, as listed below. Geoff On 06/03/2010, at 9:05 AM, Sandra Murphy wrote: > The authors of Certificate Policy (CP) for the Resource PKI (RPKI) = have submitted a new version in accordance with comments received in the = last call (http://tools.ietf.org/html/draft-ietf-sidr-cp-08). >=20 > I am opening a last call on this document for one week, ending Friday, = March 12. >=20 > Note that comments on this revision are restricted to whether the = issues have been adequately addressed. >=20 1. Introduction, para 1 - is the use of the verb "will" normative (i.e. = MUST), or intentional "SHOULD" or optional" "MAY". I'd like to see the = second sentence changed to say "MAY" or if that is not acceptable, to = say "may" 2. Introduction, para 1 - third sentence - is this "will" more = accurately a "can" 3. Introduction, para1, third sentence - "uniqueness" is not an outcome = of verification of a certificate. It would be more accurate to drop = "uniqueness" from this assertion. 4. section 1.2, para 1. The same assertion is made that associated = certification with uniqueness. The constraint on an address issuer that = creates a unique distribution of resources is not an intrinsic attribute = of certification of the issuance. 5. section 1.4.1 - the document appears to preclude the actions of LIRs = / ISPS in distributing AS numbers. I do not believe that this is = appropriate, nor accurate, in today's environment 6. section 2.2 - is a CA responsible for publishing ALL certifications = it issues, or can it be selective in publication? The section is unclear = on this 7. section 2.2 - a similar question is raised regarding CRLs and = RPKI-signed objects. Is the CA requires to publish ALL such issued = objects? 8 section 2.3 - the document does not specify a CA's actions regarding = the publication of expired and revoked certifications, nor indicate of = the CA's CPS should include such information. 9. section 2.4 - is the "shall" here a "SHALL" in a normative sense or a = "MAY"? 10. section 3.2.1 - is this "will require" a MUST require or a SHOULD = require? 11. section 3.2.2 - is this "will" a MUST, SHOULD or a MAY? 12. section 3.2.3 - is this "will" a MUST, SHOULD or a MAY? 13. section 3.2.5 - is this "will" a MUST, SHOULD or a MAY? - This = occurs in subsequent sections that describe actions of the CA, and the = use of normative language in describing these CA actions is recommended. = These instances are not further flagged here,. 14. sections 3.2 and 3.2 - I am not sure that these need to be separate = - for example is issuance after revocation any different from initial = issuance - i.e. the same criteria of 3.2.1, 3.2.2, 3.2.3 and 3.2.5 = apply, so why is 3.3.2 called out - what new information is being = provided here that is not already provided in the previous section? 15. section 3.4 - why does this section of the text NOT refer to the = actions of a CA as described in sections 3.2.1, 3.2.2, 3.2.3 and 3.2.5? = It appears that revocation is described in more informal terms and = issuance, yet the constraints on the CA to ensure that authenticity of = the request are intended to be the same. 16. section 4.1.1 - normative language required - the "should" referred = to here is unclear. Subsequent sections also use "should" where = normative language would be clearer. 17. section 4.5.2 - this section refers to "all the CAs in the chain = that issued the certificates relevant to the certificate in question" = without further clarification or explanation. In the light of related = work on local TA generation I am left with the question of what exactly = is being referred to here in this "chain"./ I would prefer this term to = be defined. 18. section 4.8 - why is the treatment of augmentation of a subject's = INRs treated differently to reduction in a subject's INRs? While = section 4.8 deals with the steps involved in issuing a new certification = in the case where a subject's INR's are augmented, there is no = corresponding description of the process in reduction, other that the = single sentence in section 4.8.1 that does not refer to any other part = of the CPS. 19 section 4.10 - is it truye to say that "This PKI does not make use of = OCSP or SCVP" or is it more appropriate to state that "RPs SHOULD NOT = rely on the use of OCSP or SCVP"? 20 - section 5.8 "The termination of a CA shall therefore be subject to = the agreement between the issuer and the subscriber and will be = described in the CPS for the issuer." I am finding it difficult to = reconcile this need for "an agreement" in the light of the observation = that where a CA no longer has any INR resources then it cannot function = as a CA in the RPKI, whether or not an agreement is reached, Why then is = an agreement stipulated here? Style comment: Is the use of double ' chars instead of a " or ' char deliberate? For = example, I would've expected to see " marks in section 1.3 when = describing the name of the document, and thereafter when denoting the = use of particular terms. From Sandra.Murphy@cobham.com Tue Mar 9 12:13:25 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A080D3A69EA for ; Tue, 9 Mar 2010 12:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLvvh7zGDkuh for ; Tue, 9 Mar 2010 12:13:22 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8A75A3A6852 for ; Tue, 9 Mar 2010 12:13:21 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o29KDMHi002591; Tue, 9 Mar 2010 14:13:22 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o29KDMFs016677; Tue, 9 Mar 2010 14:13:22 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.130]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 15:13:22 -0500 Date: Tue, 9 Mar 2010 15:13:22 -0500 (Eastern Standard Time) From: Sandra Murphy To: Geoff Huston In-Reply-To: <9C6E91F4-33B0-4B2E-8324-3FD4D2880E18@apnic.net> Message-ID: References: <9C6E91F4-33B0-4B2E-8324-3FD4D2880E18@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: 09 Mar 2010 20:13:22.0464 (UTC) FILETIME=[F7C1AA00:01CABFC4] Cc: sidr@ietf.org Subject: Re: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Mar 2010 20:13:25 -0000 If the "have been informed" was my message today, I was talking about the message you posted Nov 30, the one I attached to my message, in which you said that the authors should address the comments received, pointed to the issue tracker, etc, for the sidr-cp-07 version. --Sandy On Wed, 10 Mar 2010, Geoff Huston wrote: > [I have been informed that my note I posted yesterday in response to the Last Call did not get circulated on the SIDR mailing list - I'll try once more - Geoff] > > > I do not believe that this document is ready for submission to the IESG. Some issues still remain with this document, as listed below. > > Geoff > > On 06/03/2010, at 9:05 AM, Sandra Murphy wrote: > >> The authors of Certificate Policy (CP) for the Resource PKI (RPKI) have submitted a new version in accordance with comments received in the last call (http://tools.ietf.org/html/draft-ietf-sidr-cp-08). >> >> I am opening a last call on this document for one week, ending Friday, March 12. >> >> Note that comments on this revision are restricted to whether the issues have been adequately addressed. >> > > 1. Introduction, para 1 - is the use of the verb "will" normative (i.e. MUST), or intentional "SHOULD" or optional" "MAY". I'd like to see the second sentence changed to say "MAY" or if that is not acceptable, to say "may" > > 2. Introduction, para 1 - third sentence - is this "will" more accurately a "can" > > 3. Introduction, para1, third sentence - "uniqueness" is not an outcome of verification of a certificate. It would be more accurate to drop "uniqueness" from this assertion. > > 4. section 1.2, para 1. The same assertion is made that associated certification with uniqueness. The constraint on an address issuer that creates a unique distribution of resources is not an intrinsic attribute of certification of the issuance. > > 5. section 1.4.1 - the document appears to preclude the actions of LIRs / ISPS in distributing AS numbers. I do not believe that this is appropriate, nor accurate, in today's environment > > 6. section 2.2 - is a CA responsible for publishing ALL certifications it issues, or can it be selective in publication? The section is unclear on this > > 7. section 2.2 - a similar question is raised regarding CRLs and RPKI-signed objects. Is the CA requires to publish ALL such issued objects? > > 8 section 2.3 - the document does not specify a CA's actions regarding the publication of expired and revoked certifications, nor indicate of the CA's CPS should include such information. > > 9. section 2.4 - is the "shall" here a "SHALL" in a normative sense or a "MAY"? > > 10. section 3.2.1 - is this "will require" a MUST require or a SHOULD require? > > 11. section 3.2.2 - is this "will" a MUST, SHOULD or a MAY? > > 12. section 3.2.3 - is this "will" a MUST, SHOULD or a MAY? > > 13. section 3.2.5 - is this "will" a MUST, SHOULD or a MAY? - This occurs in subsequent sections that describe actions of the CA, and the use of normative language in describing these CA actions is recommended. These instances are not further flagged here,. > > 14. sections 3.2 and 3.2 - I am not sure that these need to be separate - for example is issuance after revocation any different from initial issuance - i.e. the same criteria of 3.2.1, 3.2.2, 3.2.3 and 3.2.5 apply, so why is 3.3.2 called out - what new information is being provided here that is not already provided in the previous section? > > 15. section 3.4 - why does this section of the text NOT refer to the actions of a CA as described in sections 3.2.1, 3.2.2, 3.2.3 and 3.2.5? It appears that revocation is described in more informal terms and issuance, yet the constraints on the CA to ensure that authenticity of the request are intended to be the same. > > 16. section 4.1.1 - normative language required - the "should" referred to here is unclear. Subsequent sections also use "should" where normative language would be clearer. > > 17. section 4.5.2 - this section refers to "all the CAs in the chain that issued the certificates relevant to the certificate in question" without further clarification or explanation. In the light of related work on local TA generation I am left with the question of what exactly is being referred to here in this "chain"./ I would prefer this term to be defined. > > 18. section 4.8 - why is the treatment of augmentation of a subject's INRs treated differently to reduction in a subject's INRs? While section 4.8 deals with the steps involved in issuing a new certification in the case where a subject's INR's are augmented, there is no corresponding description of the process in reduction, other that the single sentence in section 4.8.1 that does not refer to any other part of the CPS. > > 19 section 4.10 - is it truye to say that "This PKI does not make use of OCSP or SCVP" or is it more appropriate to state that "RPs SHOULD NOT rely on the use of OCSP or SCVP"? > > 20 - section 5.8 "The termination of a CA shall therefore be subject to the agreement between the issuer and the subscriber and will be described in the CPS for the issuer." I am finding it difficult to reconcile this need for "an agreement" in the light of the observation that where a CA no longer has any INR resources then it cannot function as a CA in the RPKI, whether or not an agreement is reached, Why then is an agreement stipulated here? > > Style comment: > > Is the use of double ' chars instead of a " or ' char deliberate? For example, I would've expected to see " marks in section 1.3 when describing the name of the document, and thereafter when denoting the use of particular terms. > > > From gih@apnic.net Tue Mar 9 13:18:30 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7693A6A4E for ; Tue, 9 Mar 2010 13:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkTG+2YrqjDw for ; Tue, 9 Mar 2010 13:18:23 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id CE42B3A6A36 for ; Tue, 9 Mar 2010 13:18:22 -0800 (PST) Received: from dhcp205.potaroo.net (dhcp205.potaroo.net [203.10.60.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id CDA62D58B2; Wed, 10 Mar 2010 07:36:37 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 10 Mar 2010 08:17:54 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C6E91F4-33B0-4B2E-8324-3FD4D2880E18@apnic.net> To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 09 Mar 2010 21:18:30 -0000 My confusion - sorry for the dup posting. On 10/03/2010, at 7:13 AM, Sandra Murphy wrote: > If the "have been informed" was my message today, I was talking about = the message you posted Nov 30, the one I attached to my message, in = which you said that the authors should address the comments received, = pointed to the issue tracker, etc, for the sidr-cp-07 version. >=20 > --Sandy >=20 > On Wed, 10 Mar 2010, Geoff Huston wrote: >=20 >> [I have been informed that my note I posted yesterday in response to = the Last Call did not get circulated on the SIDR mailing list - I'll try = once more - Geoff] >>=20 >>=20 >> I do not believe that this document is ready for submission to the = IESG. Some issues still remain with this document, as listed below. >>=20 >> Geoff >>=20 >> On 06/03/2010, at 9:05 AM, Sandra Murphy wrote: >>=20 >>> The authors of Certificate Policy (CP) for the Resource PKI (RPKI) = have submitted a new version in accordance with comments received in the = last call (http://tools.ietf.org/html/draft-ietf-sidr-cp-08). >>>=20 >>> I am opening a last call on this document for one week, ending = Friday, March 12. >>>=20 >>> Note that comments on this revision are restricted to whether the = issues have been adequately addressed. >>>=20 >>=20 >> 1. Introduction, para 1 - is the use of the verb "will" normative = (i.e. MUST), or intentional "SHOULD" or optional" "MAY". I'd like to see = the second sentence changed to say "MAY" or if that is not acceptable, = to say "may" >>=20 >> 2. Introduction, para 1 - third sentence - is this "will" more = accurately a "can" >>=20 >> 3. Introduction, para1, third sentence - "uniqueness" is not an = outcome of verification of a certificate. It would be more accurate to = drop "uniqueness" from this assertion. >>=20 >> 4. section 1.2, para 1. The same assertion is made that associated = certification with uniqueness. The constraint on an address issuer that = creates a unique distribution of resources is not an intrinsic attribute = of certification of the issuance. >>=20 >> 5. section 1.4.1 - the document appears to preclude the actions of = LIRs / ISPS in distributing AS numbers. I do not believe that this is = appropriate, nor accurate, in today's environment >>=20 >> 6. section 2.2 - is a CA responsible for publishing ALL = certifications it issues, or can it be selective in publication? The = section is unclear on this >>=20 >> 7. section 2.2 - a similar question is raised regarding CRLs and = RPKI-signed objects. Is the CA requires to publish ALL such issued = objects? >>=20 >> 8 section 2.3 - the document does not specify a CA's actions = regarding the publication of expired and revoked certifications, nor = indicate of the CA's CPS should include such information. >>=20 >> 9. section 2.4 - is the "shall" here a "SHALL" in a normative sense = or a "MAY"? >>=20 >> 10. section 3.2.1 - is this "will require" a MUST require or a SHOULD = require? >>=20 >> 11. section 3.2.2 - is this "will" a MUST, SHOULD or a MAY? >>=20 >> 12. section 3.2.3 - is this "will" a MUST, SHOULD or a MAY? >>=20 >> 13. section 3.2.5 - is this "will" a MUST, SHOULD or a MAY? - This = occurs in subsequent sections that describe actions of the CA, and the = use of normative language in describing these CA actions is recommended. = These instances are not further flagged here,. >>=20 >> 14. sections 3.2 and 3.2 - I am not sure that these need to be = separate - for example is issuance after revocation any different from = initial issuance - i.e. the same criteria of 3.2.1, 3.2.2, 3.2.3 and = 3.2.5 apply, so why is 3.3.2 called out - what new information is being = provided here that is not already provided in the previous section? >>=20 >> 15. section 3.4 - why does this section of the text NOT refer to the = actions of a CA as described in sections 3.2.1, 3.2.2, 3.2.3 and 3.2.5? = It appears that revocation is described in more informal terms and = issuance, yet the constraints on the CA to ensure that authenticity of = the request are intended to be the same. >>=20 >> 16. section 4.1.1 - normative language required - the "should" = referred to here is unclear. Subsequent sections also use "should" where = normative language would be clearer. >>=20 >> 17. section 4.5.2 - this section refers to "all the CAs in the chain = that issued the certificates relevant to the certificate in question" = without further clarification or explanation. In the light of related = work on local TA generation I am left with the question of what exactly = is being referred to here in this "chain"./ I would prefer this term to = be defined. >>=20 >> 18. section 4.8 - why is the treatment of augmentation of a subject's = INRs treated differently to reduction in a subject's INRs? While = section 4.8 deals with the steps involved in issuing a new certification = in the case where a subject's INR's are augmented, there is no = corresponding description of the process in reduction, other that the = single sentence in section 4.8.1 that does not refer to any other part = of the CPS. >>=20 >> 19 section 4.10 - is it truye to say that "This PKI does not make use = of OCSP or SCVP" or is it more appropriate to state that "RPs SHOULD NOT = rely on the use of OCSP or SCVP"? >>=20 >> 20 - section 5.8 "The termination of a CA shall therefore be subject = to the agreement between the issuer and the subscriber and will be = described in the CPS for the issuer." I am finding it difficult to = reconcile this need for "an agreement" in the light of the observation = that where a CA no longer has any INR resources then it cannot function = as a CA in the RPKI, whether or not an agreement is reached, Why then is = an agreement stipulated here? >>=20 >> Style comment: >>=20 >> Is the use of double ' chars instead of a " or ' char deliberate? For = example, I would've expected to see " marks in section 1.3 when = describing the name of the document, and thereafter when denoting the = use of particular terms. >>=20 >>=20 >>=20 From wei.yinxing@zte.com.cn Wed Mar 10 21:55:27 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49FA63A67D9 for ; Wed, 10 Mar 2010 21:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 obgP-zyU1do1 for ; Wed, 10 Mar 2010 21:55:26 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 098003A6916 for ; Wed, 10 Mar 2010 21:55:25 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 469071783260960; Thu, 11 Mar 2010 13:26:19 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.1783260960; Thu, 11 Mar 2010 13:53:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o2B5tA5T022269 for ; Thu, 11 Mar 2010 13:55:13 +0800 (CST) (envelope-from wei.yinxing@zte.com.cn) To: sidr@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Thu, 11 Mar 2010 13:54:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-11 13:55:07, Serialize complete at 2010-03-11 13:55:07 Content-Type: multipart/alternative; boundary="=_alternative 00207D8B482576E3_=" X-MAIL: mse1.zte.com.cn o2B5tA5T022269 Subject: [sidr] draft-wei-sidr-cta-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 11 Mar 2010 05:55:27 -0000 This is a multipart message in MIME format. --=_alternative 00207D8B482576E3_= Content-Type: text/plain; charset="US-ASCII" Hi,all, A new draft for the IETF 77th meeting has been submitted, which can be found at http://tools.ietf.org/id/draft-wei-sidr-cta-00.txt. Title : A cryptographically generated issuer name for trust anchor Author(s) : Y. Wei, S. Duan, H. Wang Filename : draft-wei-sidr-cta-00.txt Pages : 11 Date : 2010-03-01 Any comments are highly welcomed! Best Regards! Yinxing Wei -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00207D8B482576E3_= Content-Type: text/html; charset="US-ASCII"
Hi,all,

A new draft for the IETF 77th meeting has been submitted, which can be found at http://tools.ietf.org/id/draft-wei-sidr-cta-00.txt.

               Title           : A cryptographically generated issuer name for trust anchor
                Author(s)       : Y. Wei, S. Duan, H. Wang
                Filename        : draft-wei-sidr-cta-00.txt
                Pages           : 11
                Date            : 2010-03-01

Any comments are highly welcomed!

Best Regards!

Yinxing Wei

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00207D8B482576E3_=-- From Sandra.Murphy@cobham.com Thu Mar 11 05:31:12 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C293A6778 for ; Thu, 11 Mar 2010 05:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTly-45gArxK for ; Thu, 11 Mar 2010 05:31:11 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id B60B33A672E for ; Thu, 11 Mar 2010 05:31:11 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o2BDVGlf026787 for ; Thu, 11 Mar 2010 07:31:16 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o2BDVGuw024794 for ; Thu, 11 Mar 2010 07:31:16 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Mar 2010 08:31:16 -0500 Date: Thu, 11 Mar 2010 08:31:15 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 11 Mar 2010 13:31:16.0429 (UTC) FILETIME=[20585FD0:01CAC11F] Subject: [sidr] agenda for IETF 77 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 11 Mar 2010 13:31:12 -0000 In my flurry of messages last week, there was supposed to be one containing a request for agenda topics. That got missed, which probably explains why I have received only private requests for agenda topics. I created an agenda from the list of updated drafts as well as the private requests for agenda time. It is now uploaded. We have the two back-to-back meeting slots in the morning of Wed, Mar 24. I have made no attempt to distinguish the slots in the agenda, but if anyone would find it good to have the two slots separated, please reply to the list. If anyone desires to be assigned a slot on the agenda or to be removed from the agenda, please let me know. There is one new topic on the agenda that I was informed of privately, but I do not yet have a draft name to mention. Expect more updates. Revised agendas are due by 15 Mar, to give people time to make their plans, but agenda changes after that are not forbidden by the chair. And there's always the traditional "agenda bashing" first topic. --Sandy From turners@ieca.com Thu Mar 11 13:24:11 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B78B3A694F for ; Thu, 11 Mar 2010 13:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 WVDZm6ONXrAU for ; Thu, 11 Mar 2010 13:24:10 -0800 (PST) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id D56D33A6906 for ; Thu, 11 Mar 2010 13:22:44 -0800 (PST) Received: (qmail 29900 invoked from network); 11 Mar 2010 21:22:47 -0000 Received: from thunderfish.local (turners@96.241.9.87 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 11 Mar 2010 13:22:47 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: drvosjwVM1kpefmUBFDMpcGv2FiSc.y.DzQS8KF3JMbHNVuZsNSnmqP7vTEYS8686MzkIfopdYi.FqzBWKWvfBqUO8y_gJ4kI9BTQc2hc4gckp0iVJb5mqY0n4KjdJ9OMujh_..0C8vBRIYtECZ.kX7LhPhtziHL8Yo5s.PBWezUIUB.KEu2.6W3NNckEpjRolYg3On_FHj9jFvbQlZHj95qb7aBIVPXNvig3NF7LjU3qx8tYxSiOP2fqTRlvc9Ox0w9tMq_mDuuVU6EVT2b8PIpZfbii4bwTSz0TPHSbp0Wr3W4KnZWwj7T9eCDngckrdSTz_B1XfKB2vbLcTSGaxOpsfNVUFuaM3_iBAlVCq_0UFtA0wAnRHfeHdo85MfsMC0ZGMvOkFrLaaRl.lhm7dfb3ZhD0efEa24Me6fcgf4dD72aleOd3Yv0FxWCsM43hgGGRRiyAw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B995F27.7010901@ieca.com> Date: Thu, 11 Mar 2010 16:22:47 -0500 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] second algorithm and transition process X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 11 Mar 2010 21:24:11 -0000 I'd be willing to help. spt Stephen Kent wrote: > Sandy, > > I will be happy to work on both drafts, assuming others volunteer :-). > > Steve > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From wei.yinxing@zte.com.cn Thu Mar 11 17:10:21 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817763A6837; Thu, 11 Mar 2010 17:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.736 X-Spam-Level: X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 qyuBH4UL1-Hy; Thu, 11 Mar 2010 17:10:20 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 7F7203A6809; Thu, 11 Mar 2010 17:10:19 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 469073763365534; Fri, 12 Mar 2010 08:41:13 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.4706319458; Fri, 12 Mar 2010 09:08:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o2C1AK69061715; Fri, 12 Mar 2010 09:10:20 +0800 (CST) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Sandra Murphy MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Fri, 12 Mar 2010 09:10:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-12 09:10:19, Serialize complete at 2010-03-12 09:10:19 Content-Type: multipart/alternative; boundary="=_alternative 00066E01482576E4_=" X-MAIL: mse1.zte.com.cn o2C1AK69061715 Cc: sidr-bounces@ietf.org, sidr@ietf.org Subject: Re: [sidr] agenda for IETF 77 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 12 Mar 2010 01:10:21 -0000 This is a multipart message in MIME format. --=_alternative 00066E01482576E4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBTYW5kcmEgTXVycGh5LCANCg0KSSB1cGxvYWRlZCBhIG5ldyBkcmFmdCBpbiANCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC13ZWktc2lkci1jdGEtMDAudHh0Lg0KQ291bGQgeW91 IGFycmFuZ2UgMTAgbWludXRlcyBmb3IgbWUgdG8gcHJlc2VudCBpdD8gDQoNCiAgICAgICAgICAg ICAgIFRpdGxlICAgICAgICAgICA6IEEgY3J5cHRvZ3JhcGhpY2FsbHkgZ2VuZXJhdGVkIGlzc3Vl ciBuYW1lIA0KZm9yIHRydXN0IGFuY2hvcg0KICAgICAgICAgICAgICAgICBBdXRob3IocykgICAg ICAgOiBZLiBXZWksIFMuIER1YW4sIEguIFdhbmcNCiAgICAgICAgICAgICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtd2VpLXNpZHItY3RhLTAwLnR4dA0KICAgICAgICAgICAgICAgICBQYWdl cyAgICAgICAgICAgOiAxMQ0KICAgICAgICAgICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDEw LTAzLTAxDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYW4gZW5oYW5j ZWQgY2VydGlmaWNhdGUgcHJvZmlsZSBmb3IgdHJ1c3QNCiAgIGFuY2hvcnMsIGluIHdoaWNoIHRo ZSBpc3N1ZXIgZmllbGQgb2YgdGhlIFRBIGNlcnRpZmljYXRlIGlzDQogICBjcnlwdG9ncmFwaGlj YWxseSBnZW5lcmF0ZWQuICBJbiB0aGUgUlBLSSBhcmNoaXRlY3R1cmUsIHRoZSB0cnVzdA0KICAg YW5jaG9yIHVzZXMgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUuICBIb3dldmVyLCB0aGlzIHNvcnQg b2YNCiAgIGNlcnRpZmljYXRlIGlzIHZ1bG5lcmFibGUgdG8gdmFyaW91cyBhdHRhY2tzLiAgRm9y IGV4YW1wbGUsIHRoZQ0KICAgYXR0YWNrZXJzIGNhbiBlYXNpbHkgY3JlYXRlIGl0cyBvd24gcHVi bGljLXByaXZhdGUga2V5IHBhaXIgYW5kDQogICBkZWNsYWltcyB0aGF0IHRoZSBpc3N1ZXIgZmll bGQgYmVsb25ncyB0byBoaW0uICBUaGlzIG1lYW5zIGF0dGFja2Vycw0KICAgY2FuIGVhc2lseSBp bXBlcnNvbmF0ZSB0aGUgdHJ1c3QgYW5jaG9yLiAgVG8gYWRkcmVzcyBpdCwgdGhpcw0KICAgZG9j dW1lbnQgYWRkcyBpZGVudGl0eSBiYXNlZCBjcnlwdG9ncmFwaGljIHRlY2huaXF1ZSB0byB0aGUg c2VsZi0NCiAgIHNpZ25lZCBjZXJ0aWZpY2F0ZS4gIFNpbmNlIHRoZSBpc3N1ZXIgZmllbGQgb2Yg dGhlIHRydXN0IGFuY2hvcidzDQogICBjZXJ0aWZpY2F0ZSBpcyBjcnlwdG9ncmFwaGljYWxseSBn ZW5lcmF0ZWQgZnJvbSB0aGUgdHJ1c3QgYW5jaG9yJ3MNCiAgIHB1YmxpYyBrZXksIHRoZSBhdHRh Y2tlciB3aWxsIG5vdCBiZSBhYmxlIHRvIGNyZWF0ZSBhbm90aGVyIGtleSBwYWlyDQogICBhbmQg ZGVjbGFpbSB0aGF0IHRoZSBpc3N1ZXIgZmllbGQgZ2VuZXJhdGVkIGJ5IHRoZSB0cnVzdCBhbmNo b3INCiAgIGJlbG9uZ3MgdG8gaGltLiAgVGhlcmVmb3JlLCBhdHRhY2tlcnMgY2FuIG5vdCBpbXBl cnNvbmF0ZSB0aGUgdHJ1c3QNCiAgIGFuY2hvci4NCg0KQmVzdCBSZWdhcmRzIQ0KDQpZaW54aW5n IFdlaQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFkZHJlc3M6IFN5c3RlbSBBcmNoaXRlY3R1 cmUgRGVwYXJ0bWVudCwgQ2VudHJhbCBJbnN0aXR1dGUsIFpURSANCkNvcnBvcmF0aW9uDQogICAg ICAgICBSb29tIDJDNCwgTm8uIDY4LCBaaWppbmdodWEgUm9hZCwgWXVodWF0YWkgRGlzdHJpY3Qs IE5hbmppbmcsIA0KQ2hpbmENClppcGNvZGU6IDIxMDAxMg0KT2ZmaWNlIFRlbGVwaG9uZTogKzg2 LTAyNS01Mjg3Nzk5Mw0KTW9iaWxlIFRlbGVwaG9uZTogKzg2LTEzNjExNTE5MzU4DQpGYXg6ICs4 Ni0yNS01Mjg3ODAwOA0KTVNOOiB3ZWl5aW54aW5nQGhvdG1haWwuY29tDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQoNClNhbmRyYSBNdXJwaHkgPHNhbmRyYS5tdXJwaHlAc3BhcnRhLmNv bT4gDQq3orz+yMs6ICBzaWRyLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDMtMTEgMjE6MzENCg0K ytW8/sjLDQpzaWRyQGlldGYub3JnDQqzrcvNDQoNCtb3zOINCltzaWRyXSBhZ2VuZGEgZm9yIElF VEYgNzcNCg0KDQoNCg0KDQoNCkluIG15IGZsdXJyeSBvZiBtZXNzYWdlcyBsYXN0IHdlZWssIHRo ZXJlIHdhcyBzdXBwb3NlZCB0byBiZSBvbmUgDQpjb250YWluaW5nIGEgcmVxdWVzdCBmb3IgYWdl bmRhIHRvcGljcy4gIFRoYXQgZ290IG1pc3NlZCwgd2hpY2ggcHJvYmFibHkgDQpleHBsYWlucyB3 aHkgSSBoYXZlIHJlY2VpdmVkIG9ubHkgcHJpdmF0ZSByZXF1ZXN0cyBmb3IgYWdlbmRhIHRvcGlj cy4NCg0KSSBjcmVhdGVkIGFuIGFnZW5kYSBmcm9tIHRoZSBsaXN0IG9mIHVwZGF0ZWQgZHJhZnRz IGFzIHdlbGwgYXMgdGhlIHByaXZhdGUgDQoNCnJlcXVlc3RzIGZvciBhZ2VuZGEgdGltZS4gIEl0 IGlzIG5vdyB1cGxvYWRlZC4NCg0KV2UgaGF2ZSB0aGUgdHdvIGJhY2stdG8tYmFjayBtZWV0aW5n IHNsb3RzIGluIHRoZSBtb3JuaW5nIG9mIFdlZCwgTWFyIDI0LiANCkkgaGF2ZSBtYWRlIG5vIGF0 dGVtcHQgdG8gZGlzdGluZ3Vpc2ggdGhlIHNsb3RzIGluIHRoZSBhZ2VuZGEsIGJ1dCBpZiANCmFu eW9uZSB3b3VsZCBmaW5kIGl0IGdvb2QgdG8gaGF2ZSB0aGUgdHdvIHNsb3RzIHNlcGFyYXRlZCwg cGxlYXNlIHJlcGx5IHRvIA0KDQp0aGUgbGlzdC4NCg0KSWYgYW55b25lIGRlc2lyZXMgdG8gYmUg YXNzaWduZWQgYSBzbG90IG9uIHRoZSBhZ2VuZGEgb3IgdG8gYmUgcmVtb3ZlZCANCmZyb20gdGhl IGFnZW5kYSwgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQpUaGVyZSBpcyBvbmUgbmV3IHRvcGljIG9u IHRoZSBhZ2VuZGEgdGhhdCBJIHdhcyBpbmZvcm1lZCBvZiBwcml2YXRlbHksIGJ1dCANCg0KSSBk byBub3QgeWV0IGhhdmUgYSBkcmFmdCBuYW1lIHRvIG1lbnRpb24uDQoNCkV4cGVjdCBtb3JlIHVw ZGF0ZXMuICBSZXZpc2VkIGFnZW5kYXMgYXJlIGR1ZSBieSAxNSBNYXIsIHRvIGdpdmUgcGVvcGxl IA0KdGltZSB0byBtYWtlIHRoZWlyIHBsYW5zLCBidXQgYWdlbmRhIGNoYW5nZXMgYWZ0ZXIgdGhh dCBhcmUgbm90IGZvcmJpZGRlbiANCmJ5IHRoZSBjaGFpci4gIEFuZCB0aGVyZSdzIGFsd2F5cyB0 aGUgdHJhZGl0aW9uYWwgImFnZW5kYSBiYXNoaW5nIiBmaXJzdCANCnRvcGljLg0KDQotLVNhbmR5 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lkciBt YWlsaW5nIGxpc3QNCnNpZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lkcg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8g bWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNv bnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20g dGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3 cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBz ZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3Bh bSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00066E01482576E4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgU2FuZHJhIE11cnBoeSwg PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHVwbG9h ZGVkIGEgbmV3IGRyYWZ0IGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC13ZWktc2lk ci1jdGEtMDAudHh0LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Q291bGQgeW91IGFycmFuZ2UgMTAgbWludXRlcyBmb3IgbWUNCnRvIHByZXNlbnQgaXQ/IDwvZm9u dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaXRsZQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA6IDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTM+QSBjcnlwdG9ncmFw aGljYWxseQ0KZ2VuZXJhdGVkIGlzc3VlciBuYW1lIGZvciB0cnVzdCBhbmNob3I8L2ZvbnQ+PC90 dD48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsg OiA8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0zPlkuIFdlaTwvZm9udD48L3R0Pjx0dD48Zm9u dCBzaXplPTI+LA0KPC9mb250PjwvdHQ+PHR0Pjxmb250IHNpemU9Mz5TLiBEdWFuPC9mb250Pjwv dHQ+PHR0Pjxmb250IHNpemU9Mj4sIDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTM+SC4NCldh bmc8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpGaWxlbmFtZSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs6IDwvZm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5kcmFmdC13ZWktc2lkci1jdGEtMDAudHh0PC9mb250Pjx0dD48Zm9udCBzaXplPTI+PGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNClBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAxMTxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpE YXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyMDEwLTAzLTAx PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFi c3RyYWN0PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm9wb3Nlcw0KYW4gZW5oYW5jZWQgY2VydGlmaWNh dGUgcHJvZmlsZSBmb3IgdHJ1c3Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDthbmNob3JzLCBpbiB3aGljaCB0aGUgaXNzdWVyDQpmaWVsZCBv ZiB0aGUgVEEgY2VydGlmaWNhdGUgaXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtjcnlwdG9ncmFwaGljYWxseSBnZW5lcmF0ZWQuDQombmJz cDtJbiB0aGUgUlBLSSBhcmNoaXRlY3R1cmUsIHRoZSB0cnVzdDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2FuY2hvciB1c2VzIHNlbGYtc2ln bmVkDQpjZXJ0aWZpY2F0ZS4gJm5ic3A7SG93ZXZlciwgdGhpcyBzb3J0IG9mPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Y2VydGlmaWNhdGUg aXMgdnVsbmVyYWJsZQ0KdG8gdmFyaW91cyBhdHRhY2tzLiAmbmJzcDtGb3IgZXhhbXBsZSwgdGhl PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 YXR0YWNrZXJzIGNhbiBlYXNpbHkgY3JlYXRlDQppdHMgb3duIHB1YmxpYy1wcml2YXRlIGtleSBw YWlyIGFuZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 ICZuYnNwO2RlY2xhaW1zIHRoYXQgdGhlIGlzc3Vlcg0KZmllbGQgYmVsb25ncyB0byBoaW0uICZu YnNwO1RoaXMgbWVhbnMgYXR0YWNrZXJzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7Y2FuIGVhc2lseSBpbXBlcnNvbmF0ZQ0KdGhlIHRydXN0 IGFuY2hvci4gJm5ic3A7VG8gYWRkcmVzcyBpdCwgdGhpczwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2RvY3VtZW50IGFkZHMgaWRlbnRpdHkN CmJhc2VkIGNyeXB0b2dyYXBoaWMgdGVjaG5pcXVlIHRvIHRoZSBzZWxmLTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3NpZ25lZCBjZXJ0aWZp Y2F0ZS4gJm5ic3A7U2luY2UNCnRoZSBpc3N1ZXIgZmllbGQgb2YgdGhlIHRydXN0IGFuY2hvcidz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 Y2VydGlmaWNhdGUgaXMgY3J5cHRvZ3JhcGhpY2FsbHkNCmdlbmVyYXRlZCBmcm9tIHRoZSB0cnVz dCBhbmNob3InczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwO3B1YmxpYyBrZXksIHRoZSBhdHRhY2tlcg0Kd2lsbCBub3QgYmUgYWJsZSB0byBj cmVhdGUgYW5vdGhlciBrZXkgcGFpcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2FuZCBkZWNsYWltIHRoYXQgdGhlIGlzc3Vlcg0KZmllbGQg Z2VuZXJhdGVkIGJ5IHRoZSB0cnVzdCBhbmNob3I8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtiZWxvbmdzIHRvIGhpbS4gJm5ic3A7VGhlcmVm b3JlLA0KYXR0YWNrZXJzIGNhbiBub3QgaW1wZXJzb25hdGUgdGhlIHRydXN0PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YW5jaG9yLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQmVzdCBSZWdhcmRz ITxicj4NCjxicj4NCllpbnhpbmcgV2VpPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+ DQpBZGRyZXNzOiBTeXN0ZW0gQXJjaGl0ZWN0dXJlIERlcGFydG1lbnQsIENlbnRyYWwgSW5zdGl0 dXRlLCBaVEUgQ29ycG9yYXRpb248YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJv b20gMkM0LCBOby4gNjgsIFppamluZ2h1YSBSb2FkLCBZdWh1YXRhaQ0KRGlzdHJpY3QsIE5hbmpp bmcsIENoaW5hPGJyPg0KWmlwY29kZTogMjEwMDEyPGJyPg0KT2ZmaWNlIFRlbGVwaG9uZTogKzg2 LTAyNS01Mjg3Nzk5Mzxicj4NCk1vYmlsZSBUZWxlcGhvbmU6ICs4Ni0xMzYxMTUxOTM1ODxicj4N CkZheDogKzg2LTI1LTUyODc4MDA4PGJyPg0KTVNOOiB3ZWl5aW54aW5nQGhvdG1haWwuY29tPGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlNhbmRyYSBNdXJwaHkgJmx0O3NhbmRyYS5tdXJwaHlA c3BhcnRhLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPreivP7IyzogJm5ic3A7c2lkci1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDMtMTEgMjE6MzE8L2ZvbnQ+DQo8dGQg d2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+c2lkckBpZXRmLm9y ZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+W3NpZHJdIGFnZW5kYSBmb3IgSUVURiA3NzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SW4gbXkgZmx1cnJ5IG9mIG1lc3NhZ2VzIGxh c3Qgd2VlaywgdGhlcmUgd2FzIHN1cHBvc2VkDQp0byBiZSBvbmUgPGJyPg0KY29udGFpbmluZyBh IHJlcXVlc3QgZm9yIGFnZW5kYSB0b3BpY3MuICZuYnNwO1RoYXQgZ290IG1pc3NlZCwgd2hpY2gg cHJvYmFibHkNCjxicj4NCmV4cGxhaW5zIHdoeSBJIGhhdmUgcmVjZWl2ZWQgb25seSBwcml2YXRl IHJlcXVlc3RzIGZvciBhZ2VuZGEgdG9waWNzLjxicj4NCjxicj4NCkkgY3JlYXRlZCBhbiBhZ2Vu ZGEgZnJvbSB0aGUgbGlzdCBvZiB1cGRhdGVkIGRyYWZ0cyBhcyB3ZWxsIGFzIHRoZSBwcml2YXRl DQo8YnI+DQpyZXF1ZXN0cyBmb3IgYWdlbmRhIHRpbWUuICZuYnNwO0l0IGlzIG5vdyB1cGxvYWRl ZC48YnI+DQo8YnI+DQpXZSBoYXZlIHRoZSB0d28gYmFjay10by1iYWNrIG1lZXRpbmcgc2xvdHMg aW4gdGhlIG1vcm5pbmcgb2YgV2VkLCBNYXIgMjQuDQo8YnI+DQpJIGhhdmUgbWFkZSBubyBhdHRl bXB0IHRvIGRpc3Rpbmd1aXNoIHRoZSBzbG90cyBpbiB0aGUgYWdlbmRhLCBidXQgaWYgPGJyPg0K YW55b25lIHdvdWxkIGZpbmQgaXQgZ29vZCB0byBoYXZlIHRoZSB0d28gc2xvdHMgc2VwYXJhdGVk LCBwbGVhc2UgcmVwbHkNCnRvIDxicj4NCnRoZSBsaXN0Ljxicj4NCjxicj4NCklmIGFueW9uZSBk ZXNpcmVzIHRvIGJlIGFzc2lnbmVkIGEgc2xvdCBvbiB0aGUgYWdlbmRhIG9yIHRvIGJlIHJlbW92 ZWQNCjxicj4NCmZyb20gdGhlIGFnZW5kYSwgcGxlYXNlIGxldCBtZSBrbm93Ljxicj4NCjxicj4N ClRoZXJlIGlzIG9uZSBuZXcgdG9waWMgb24gdGhlIGFnZW5kYSB0aGF0IEkgd2FzIGluZm9ybWVk IG9mIHByaXZhdGVseSwNCmJ1dCA8YnI+DQpJIGRvIG5vdCB5ZXQgaGF2ZSBhIGRyYWZ0IG5hbWUg dG8gbWVudGlvbi48YnI+DQo8YnI+DQpFeHBlY3QgbW9yZSB1cGRhdGVzLiAmbmJzcDtSZXZpc2Vk IGFnZW5kYXMgYXJlIGR1ZSBieSAxNSBNYXIsIHRvIGdpdmUgcGVvcGxlDQo8YnI+DQp0aW1lIHRv IG1ha2UgdGhlaXIgcGxhbnMsIGJ1dCBhZ2VuZGEgY2hhbmdlcyBhZnRlciB0aGF0IGFyZSBub3Qg Zm9yYmlkZGVuDQo8YnI+DQpieSB0aGUgY2hhaXIuICZuYnNwO0FuZCB0aGVyZSdzIGFsd2F5cyB0 aGUgdHJhZGl0aW9uYWwgJnF1b3Q7YWdlbmRhIGJhc2hpbmcmcXVvdDsNCmZpcnN0IDxicj4NCnRv cGljLjxicj4NCjxicj4NCi0tU2FuZHk8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnNpZHIgbWFpbGluZyBsaXN0PGJyPg0Kc2lkckBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcjxicj4N Cjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3Nv bGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29y Z2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNy ZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJz cDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7 YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtp dCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7 c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4N CjwvcHJlPg== --=_alternative 00066E01482576E4_=-- From rcallon@juniper.net Fri Mar 12 07:18:10 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A0C3A6B89 for ; Fri, 12 Mar 2010 07:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 scFn89lKENOO for ; Fri, 12 Mar 2010 07:18:08 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 2198D3A6BCC for ; Fri, 12 Mar 2010 07:03:24 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS5pXvsdMH0FmaYxzj7EZ9qzSdsZzFnGu@postini.com; Fri, 12 Mar 2010 07:03:31 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 12 Mar 2010 06:57:56 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 12 Mar 2010 09:57:55 -0500 From: Ross Callon To: "sidr@ietf.org" Date: Fri, 12 Mar 2010 09:57:53 -0500 Thread-Topic: SIDR Co-chair Thread-Index: AcrB9GRov76hnV6bRz+ZpZRrHY9fmw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB177049A55526328EMBX01WFjnprn_" MIME-Version: 1.0 Cc: Chris Morrow , Adrian Farrel , Sandra Murphy Subject: [sidr] SIDR Co-chair X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 12 Mar 2010 15:18:10 -0000 --_000_DF7F294AF4153D498141CBEFADB177049A55526328EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am very pleased to announce that Chris Morrow has agreed to help out Sand= ra as co-chair of the SIDR working group. Thanks, Ross --_000_DF7F294AF4153D498141CBEFADB177049A55526328EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am very pleased to announce that Chris Morrow has agre= ed to help out Sandra as co-chair of the SIDR working group.

 

Thanks, Ross

--_000_DF7F294AF4153D498141CBEFADB177049A55526328EMBX01WFjnprn_-- From kent@bbn.com Fri Mar 12 11:55:57 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D163A67FC for ; Fri, 12 Mar 2010 11:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, 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 mIAQD5Y3I7Ec for ; Fri, 12 Mar 2010 11:55:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9BBB93A6407 for ; Fri, 12 Mar 2010 11:55:56 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NqAxm-000PqJ-7R; Fri, 12 Mar 2010 14:56:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 12 Mar 2010 14:55:58 -0500 To: wei.yinxing@zte.com.cn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] agenda for IETF 77 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 12 Mar 2010 19:55:57 -0000 I find this document to be very puzzling. The introduction includes some allusions to the local TA management talks that I have made to the SIDR WG (without attribution), but the text contained in this section is inconsistent with the local TA management model I have described. The introduction also talks about attacks on trust anchors, but the arguments are incorrect, e.g., they fail to acknowledge that TAs are to be distributed out-of-band via secure channels. The fundamental notion put forth here appears to be a form of internal consistency check that can be performed on a self-signed TA cert, based on generation of the TA's (issuer) name from an IP address (v4 or v6) or an rfc1822 name. The stated goal (see section 6) is to somehow protect the issuer name of a TA: "Since the issuer name is generated from the key pair, and the certificate is signed [sic] using the key pair, the attacker can not be able to declaim that the issuer name belongs to it." This suggests a fundamental misunderstanding of TA concepts. This makes no sense to me, in several ways: - a TA represented by a self-signed cert has the same name for the subject and issuer, so references to the issuer name only are odd, at best. - resource certs are specified to NOT make use of alternative names, so there is no place for an rfc1822 name in such a cert - resource certs for TAs would contain prefixes, not individual addresses, so there would be no individual v4 or v6 address to use in the algorithm described in section 2.1. A self-signed cert already has a consistency check, based on the fact that the public key contained in the cert must be able to be used to verify the signature on the cert. Because issuer and subject names in the RPKI are not intended to be human meaningful, it is not clear why there is a need to "secure" in some fashion that issuer name in a TA cert. Section 2.1 presents an algorithm that appears to be derived from the CGA algorithm described in RFC 3971. This makes no sense. For example, step 6 talks about duplicate address detection, yet this document is describing how to generate an issuer name for a cert, not an IPv6 address to be used in a network! Section 3.1 references the SIDR-TA I-D, but fails to indicate which form of TA (ETA or RPKI TA) the authors believe would benefit from use of this technique. Section 3.2 has a cryptic description of an extension (not using ASN.1), used to contain a 256-bit random number that is employed in the name generation algorithm (section 2.1). None of this makes any sense to me in the SIDR context. Maye the lack of references to the resource cert profile (draft-ietf-sidr-res-certs-17) is indicative of the serious disconnect I see here. Steve From Sandra.Murphy@cobham.com Sat Mar 13 04:40:06 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE333A67B1 for ; Sat, 13 Mar 2010 04:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, 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 3DnX057rLlh9 for ; Sat, 13 Mar 2010 04:40:05 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 11C8F3A682A for ; Sat, 13 Mar 2010 04:40:04 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o2DCe9oD021121 for ; Sat, 13 Mar 2010 06:40:10 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o2DCeAO3008459 for ; Sat, 13 Mar 2010 06:40:10 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Mar 2010 07:37:14 -0500 Date: Sat, 13 Mar 2010 07:37:14 -0500 (Eastern Standard 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: 13 Mar 2010 12:37:14.0778 (UTC) FILETIME=[E8FF2FA0:01CAC2A9] Subject: Re: [sidr] Working Group Last Call on draft-ietf-sidr-cp-08 X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 13 Mar 2010 12:40:06 -0000 It having passed Mar 12 AOE, the last call has ended. Geoff Houston and Sean Turner both commented on the draft. I thank them both for their comments. The comments had enough weight that I can not declare consensus to request publication of the draft at this time. I ask the authors to consider these comments and to produce a new version of the draft. --Sandy On Fri, 5 Mar 2010, Sandra Murphy wrote: > The authors of Certificate Policy (CP) for the Resource PKI (RPKI) have > submitted a new version in accordance with comments received in the last call > (http://tools.ietf.org/html/draft-ietf-sidr-cp-08). > > I am opening a last call on this document for one week, ending Friday, March > 12. > > Note that comments on this revision are restricted to whether the issues have > been adequately addressed. > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kseo@bbn.com Mon Mar 15 11:32:44 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289983A6BC0 for ; Mon, 15 Mar 2010 11:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, 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 HPljvjrckvL9 for ; Mon, 15 Mar 2010 11:32:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3B1E43A6BBD for ; Mon, 15 Mar 2010 11:32:20 -0700 (PDT) Received: from dhcp89-089-066.bbn.com ([128.89.89.66] helo=[192.168.1.100]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrF5X-000AEX-2I for sidr@core3.amsl.com; Mon, 15 Mar 2010 14:32:27 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 15 Mar 2010 14:32:25 -0500 To: sidr@core3.amsl.com From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] I-D on Local Trust Anchor Management X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Mar 2010 18:32:44 -0000 Folks, Our apologies... The "00" Internet Draft on "Local Trust Anchor Management for the Resource Public Key Infrastructure" didn't make it through the IETF submission system due to a file name error that we didn't catch until too late. We'll re-post the draft as soon as the I-D submission tool is reopened. In the meantime, we've posted the draft at: http://openmap.bbn.com/draft-ieft-rpki-ltamgmt-00.txt Please let us know if you run into any problems accessing the draft. Thank you. Karen From vishwas.ietf@gmail.com Mon Mar 15 11:38:09 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540CC3A6822 for ; Mon, 15 Mar 2010 11:38:09 -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 f3JxEPcru1by for ; Mon, 15 Mar 2010 11:38:08 -0700 (PDT) Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 21FAB3A67DD for ; Mon, 15 Mar 2010 11:38:07 -0700 (PDT) Received: by pzk36 with SMTP id 36so797429pzk.8 for ; Mon, 15 Mar 2010 11:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JlQL4NwgBWdhc+szcuZH7+4LC/HZsFrieC9xPWPmol4=; b=fETjnJfdWBGkzkeSxxUpr2+0gThQkm3Fum5UbeQGlVeAttKNghV1B7kJstZ7XJyTUc bptiu2mwL/zplnZNPL7gTrZEzqFO3PGcDOzLazFtE8Fcb4T5pMuySIJ/74aIjPE7xISu ewXT1fjdpBxIP72vGUAl0PvA1zENFfAJ9N9nA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o/EMhSHWXN/H4rbtcr0BZXZAnjRNthYX/8/5SPGJy1ZzPK80dZlcaze0CiFawVEJIk zDz0lfmABxs8xgohHVBNhd0FHg5nqK77Z2w44BpfMqWypGYUoHc+B9lV5nYF9weyX4L6 IRiN21N/cyl2vTsxFrry4raW1ZsdMs+LC9T28= MIME-Version: 1.0 Received: by 10.142.55.17 with SMTP id d17mr86527wfa.246.1268678295100; Mon, 15 Mar 2010 11:38:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Mar 2010 11:38:15 -0700 Message-ID: <77ead0ec1003151138j67bc22ag4d822dba4b0ade7e@mail.gmail.com> From: Vishwas Manral To: Karen Seo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@core3.amsl.com Subject: Re: [sidr] I-D on Local Trust Anchor Management X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Mar 2010 18:38:09 -0000 Hi Karen, You should name the draft draft-ieft-sidr-rpki-ltamgmt and not draft-ieft-rpki-ltamgmt if it is a working group draft Thanks, Vishwas On Mon, Mar 15, 2010 at 12:32 PM, Karen Seo wrote: > Folks, > > Our apologies... The "00" Internet Draft on "Local Trust Anchor Managemen= t > for the Resource Public Key Infrastructure" didn't make it through the IE= TF > submission system due to a file name error that we didn't catch until too > late. =A0We'll re-post the draft as soon as the I-D submission tool is > reopened. =A0In the meantime, we've posted the draft at: > > =A0 =A0 =A0 =A0http://openmap.bbn.com/draft-ieft-rpki-ltamgmt-00.txt > > Please let us know if you run into any problems accessing the draft. > > Thank you. > Karen > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From Sandra.Murphy@cobham.com Mon Mar 15 11:54:26 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876E13A6B63 for ; Mon, 15 Mar 2010 11:54:26 -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 gvMI0NnDN9MG for ; Mon, 15 Mar 2010 11:54:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id CB3133A6B94 for ; Mon, 15 Mar 2010 11:54: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 o2FIsLd3014457; Mon, 15 Mar 2010 13:54:21 -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 o2FIsLLK031520; Mon, 15 Mar 2010 13:54:21 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.152]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 14:53:22 -0400 Date: Mon, 15 Mar 2010 14:53:22 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Vishwas Manral In-Reply-To: <77ead0ec1003151138j67bc22ag4d822dba4b0ade7e@mail.gmail.com> Message-ID: References: <77ead0ec1003151138j67bc22ag4d822dba4b0ade7e@mail.gmail.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1118005743-31865-1268679202=:5612" X-OriginalArrivalTime: 15 Mar 2010 18:53:22.0391 (UTC) FILETIME=[C92B2670:01CAC470] Cc: sidr@core3.amsl.com Subject: Re: [sidr] I-D on Local Trust Anchor Management X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Mar 2010 18:54:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1118005743-31865-1268679202=:5612 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE It is not a working group draft, so the draft-ietf-sidr- form is not= =20 appropriate. However, draft-reynolds- is the usual form for an individual=20 submittion. Not that it matters that enough to insist on a change, but it= =20 can confuse people. --Sandy On Mon, 15 Mar 2010, Vishwas Manral wrote: > Hi Karen, > > You should name the draft draft-ieft-sidr-rpki-ltamgmt and not > draft-ieft-rpki-ltamgmt if it is a working group draft > > Thanks, > Vishwas > > On Mon, Mar 15, 2010 at 12:32 PM, Karen Seo wrote: >> Folks, >> >> Our apologies... The "00" Internet Draft on "Local Trust Anchor Manageme= nt >> for the Resource Public Key Infrastructure" didn't make it through the I= ETF >> submission system due to a file name error that we didn't catch until to= o >> late. =A0We'll re-post the draft as soon as the I-D submission tool is >> reopened. =A0In the meantime, we've posted the draft at: >> >> =A0 =A0 =A0 =A0http://openmap.bbn.com/draft-ieft-rpki-ltamgmt-00.txt >> >> Please let us know if you run into any problems accessing the draft. >> >> Thank you. >> Karen >> >> >> _______________________________________________ >> 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 > --1118005743-31865-1268679202=:5612-- From kseo@bbn.com Mon Mar 15 13:41:44 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4A93A6824 for ; Mon, 15 Mar 2010 13:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 HXz62DDiFgyt for ; Mon, 15 Mar 2010 13:41:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9D2FA3A67EB for ; Mon, 15 Mar 2010 13:41:43 -0700 (PDT) Received: from dhcp89-089-066.bbn.com ([128.89.89.66] helo=[192.168.1.100]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrH6k-000CB7-Ep; Mon, 15 Mar 2010 16:41:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <77ead0ec1003151138j67bc22ag4d822dba4b0ade7e@mail.gmail.com> Date: Mon, 15 Mar 2010 16:41:48 -0500 To: Vishwas Manral From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@core3.amsl.com Subject: Re: [sidr] I-D on Local Trust Anchor Management X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Mar 2010 20:41:45 -0000 Hi, Vishwas, Sorry for the confusing email and non-standard file naming... My understanding is that although some members of the community requested that BBN write up the local trust anchor management scheme as an I-D, the draft has to go through the usual process of individual submissions (hopefully just one :-)) until approved by the working group for adoption as a working group document. So we'll re-submit the draft as draft-reynolds-[filename].txt as soon as the I-D submission tool is reopened (nominally 3/22). Thank you, Karen >Hi Karen, > >You should name the draft draft-ieft-sidr-rpki-ltamgmt and not >draft-ieft-rpki-ltamgmt if it is a working group draft > >Thanks, >Vishwas > >On Mon, Mar 15, 2010 at 12:32 PM, Karen Seo wrote: >>Folks, >> >>Our apologies... The "00" Internet Draft on "Local Trust Anchor Management >>for the Resource Public Key Infrastructure" didn't make it through the IETF >>submission system due to a file name error that we didn't catch until too >>late. We'll re-post the draft as soon as the I-D submission tool is >>reopened. In the meantime, we've posted the draft at: >> >> http://openmap.bbn.com/draft-ieft-rpki-ltamgmt-00.txt >> >>Please let us know if you run into any problems accessing the draft. >> >>Thank you. >>Karen >> >> >>_______________________________________________ >>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 kseo@bbn.com Mon Mar 15 13:49:33 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1273A6B8D for ; Mon, 15 Mar 2010 13:49:33 -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 iiVuf02Z5T76 for ; Mon, 15 Mar 2010 13:49:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 694963A689F for ; Mon, 15 Mar 2010 13:49:31 -0700 (PDT) Received: from dhcp89-089-066.bbn.com ([128.89.89.66] helo=[192.168.1.100]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrHEI-000CFs-HB; Mon, 15 Mar 2010 16:49:38 -0400 Mime-Version: 1.0 Message-Id: Date: Mon, 15 Mar 2010 16:49:35 -0500 To: Vishwas Manral From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@core3.amsl.com Subject: [sidr] Fwd: I-D on Local Trust Anchor Management X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 15 Mar 2010 20:49:33 -0000 Sorry, after all that, I forgot to put the working group name AFTER the author's name. The name will be draft-reynolds-sidr-[filename]-00.txt. >Envelope-to: kseo@mail.bbn.com >X-Original-To: sidr@core3.amsl.com >Delivered-To: sidr@core3.amsl.com >Date: Mon, 15 Mar 2010 14:32:25 -0500 >To: sidr@core3.amsl.com >From: Karen Seo >Subject: [sidr] I-D on Local Trust Anchor Management >X-BeenThere: sidr@ietf.org >List-Id: Secure Interdomain Routing >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > > >Folks, > >Our apologies... The "00" Internet Draft on "Local Trust Anchor >Management for the Resource Public Key Infrastructure" didn't make >it through the IETF submission system due to a file name error that >we didn't catch until too late. We'll re-post the draft as soon as >the I-D submission tool is reopened. In the meantime, we've posted >the draft at: > > http://openmap.bbn.com/draft-ieft-rpki-ltamgmt-00.txt > >Please let us know if you run into any problems accessing the draft. > >Thank you. >Karen > > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@cobham.com Tue Mar 16 09:23:47 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4293A6BBF for ; Tue, 16 Mar 2010 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=-1.160, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmESs+uEDuvF for ; Tue, 16 Mar 2010 09:23:47 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1BE483A6B95 for ; Tue, 16 Mar 2010 09:23:46 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o2GGNs6H026610 for ; Tue, 16 Mar 2010 11:23:54 -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 o2GGNsdv002971 for ; Tue, 16 Mar 2010 11:23:54 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.152]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 12:23:54 -0400 Date: Tue, 16 Mar 2010 12:23:53 -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: 16 Mar 2010 16:23:54.0363 (UTC) FILETIME=[12386CB0:01CAC525] Subject: [sidr] consensus call on IPR'd technologies X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 16 Mar 2010 16:23:48 -0000 We spent some time before and after the last meeting discussing IPR issues. My view of the discussion is that the working group prefers non-IPR'd technologies if given a choice, but there was no consensus for rejecting IPR'd technologies completely. Therefore, drafts that have IPR claims filed against them can both be adopted as working group work items and be retained as working group work items. --Sandy From Sandra.Murphy@cobham.com Tue Mar 16 09:25:24 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223CA3A6BA1 for ; Tue, 16 Mar 2010 09:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgaOC6SQj8Ug for ; Tue, 16 Mar 2010 09:25:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1E2463A67A1 for ; Tue, 16 Mar 2010 09:25:21 -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 o2GGPTMG026630 for ; Tue, 16 Mar 2010 11:25: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 o2GGPTBR003053 for ; Tue, 16 Mar 2010 11:25:29 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.152]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 12:25:29 -0400 Date: Tue, 16 Mar 2010 12:25:28 -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: 16 Mar 2010 16:25:29.0114 (UTC) FILETIME=[4AB247A0:01CAC525] Subject: [sidr] Discussion point: implementation guidance (draft-ietf-sidr-rpki-manifests-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: Tue, 16 Mar 2010 16:25:24 -0000 wrt: http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-06 I exchanged several messages with a manifest document author asking for help with my confusion regarding some points in this draft, particularly having to do with timing issues in publication of new manifests and in sharing a repository publication point with a different CA cert. It is pretty clear to me that different implementation choices, particularly on re-key of a CA, could make the RPKI system "noisy" (in the term used by my correspondent), producing non-fatal error messages that would need to be inspected and dealt with (and commonly dismissed). I also see no impact on routing (routing does not break) from these implementation decisions, so there the draft could progress as is without harm. But I can see the need for some implementation guidance. The wg list last year engaged in a discussion of synchronization timing recommendations in the res-certs draft. In that discussion, one suggestion was to produce a separate operations guide along the lines of a BCP. It seems to me that this implementation guidance could be similarly separated. What says the wg on the desire for implementation guidance? Needed or not? If needed, what says the wg on the need for separate implementation guidance document(s) vs guidance in the manifest document itself? --Sandy From Sandra.Murphy@cobham.com Tue Mar 16 09:26:11 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0463A6BB6 for ; Tue, 16 Mar 2010 09:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 EyFqFvRZsZZF for ; Tue, 16 Mar 2010 09:26:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3CF7E3A6BB9 for ; Tue, 16 Mar 2010 09:26:05 -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 o2GGQCTC026646 for ; Tue, 16 Mar 2010 11:26:12 -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 o2GGQCcv003101 for ; Tue, 16 Mar 2010 11:26:12 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.152]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 12:26:12 -0400 Date: Tue, 16 Mar 2010 12:26:12 -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: 16 Mar 2010 16:26:12.0364 (UTC) FILETIME=[6479B4C0:01CAC525] Subject: [sidr] discussion topic: validation abstract vs implementation specific (http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-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, 16 Mar 2010 16:26:11 -0000 In the last meeting, George Michaelson and John Scudder had an exchange of comments about the roa-validation draft (now http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-05). John said that the draft lacked specifics for implementers and George said that this was the authors' intent, that the draft should be viewed as an abstract statement of what route validation with the RPKI should mean. We have seen two different proposals for implementing route validation: Ruediger Volk's proposal to use ROAs with existing IRR based filter generation tools (and a mapping from ROAs to IRR objects), and Dave Ward's presentation of a BGP decision process mechanism that uses ROA information. I see no reason to believe that there will never be other proposals for implementing route validation, or that we must decide on a single proposal. Recall that Geoff commented that our charter does call for us to work on router implementation specifics. (He referred to the "Document specific routing functionality modules" part in particular.) I suggest to the working group that we could proceed with the current draft as the abstract model for route validation, and leave open the potential for other drafts that bring proposals for implementation specifics for route validation. (And that we should begin working on such implementation drafts.) --Sandy From randy@psg.com Tue Mar 16 16:02:03 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7243A6824 for ; Tue, 16 Mar 2010 16:02:03 -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 MGkFiRqn4s76 for ; Tue, 16 Mar 2010 16:02:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id F347A3A6818 for ; Tue, 16 Mar 2010 16:02:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrfm5-000GY3-F5; Tue, 16 Mar 2010 23:02:09 +0000 Date: Tue, 16 Mar 2010 16:02:08 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] discussion topic: validation abstract vs implementation specific (http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-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, 16 Mar 2010 23:02:04 -0000 > I suggest to the working group that we could proceed with the current > draft as the abstract model for route validation, and leave open the > potential for other drafts that bring proposals for implementation > specifics for route validation. (And that we should begin working on > such implementation drafts.) having spent the last weeks, and specifically the last two days in the bay area, discussing this with bgp implementors, i can not support this position. we will be presenting a more realistic approach in anaheim. randy From kent@bbn.com Tue Mar 16 17:08:10 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF1B3A6AAD for ; Tue, 16 Mar 2010 17:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.617, 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 rECt0JR8HxpH for ; Tue, 16 Mar 2010 17:08:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id BDAE23A6A70 for ; Tue, 16 Mar 2010 17:08:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.172.188]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrgo3-0003qh-7r; Tue, 16 Mar 2010 20:08:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 16 Mar 2010 20:05:57 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Discussion point: implementation guidance (draft-ietf-sidr-rpki-manifests-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: Wed, 17 Mar 2010 00:08:10 -0000 I think implementation guidance will be useful. to me, a separate doc seems appropriate. Steve From kent@bbn.com Tue Mar 16 17:08:11 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEAA3A6A70 for ; Tue, 16 Mar 2010 17:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.529, 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 gEOqO-KnalLG for ; Tue, 16 Mar 2010 17:08:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4E0AB3A6A7B for ; Tue, 16 Mar 2010 17:08:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.172.188]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nrgo4-0003qh-FG; Tue, 16 Mar 2010 20:08:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 16 Mar 2010 20:06:34 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] discussion topic: validation abstract vs implementation specific (http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-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, 17 Mar 2010 00:08:11 -0000 At 12:26 PM -0400 3/16/10, Sandra Murphy wrote: >In the last meeting, George Michaelson and John Scudder had an >exchange of comments about the roa-validation draft (now >http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-05). John >said that the draft lacked specifics for implementers and George >said that this was the authors' intent, that the draft should be >viewed as an abstract statement of what route validation with the >RPKI should mean. > >We have seen two different proposals for implementing route >validation: Ruediger Volk's proposal to use ROAs with existing IRR >based filter generation tools (and a mapping from ROAs to IRR >objects), and Dave Ward's presentation of a BGP decision process >mechanism that uses ROA information. > >I see no reason to believe that there will never be other proposals >for implementing route validation, or that we must decide on a >single proposal. > >Recall that Geoff commented that our charter does call for us to >work on router implementation specifics. (He referred to the >"Document specific routing functionality modules" part in >particular.) > >I suggest to the working group that we could proceed with the >current draft as the abstract model for route validation, and leave >open the potential for other drafts that bring proposals for >implementation specifics for route validation. (And that we should >begin working on such implementation drafts.) > >--Sandy +1 Steve From pmohapat@cisco.com Tue Mar 16 19:04:12 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410D73A6B8C for ; Tue, 16 Mar 2010 19:04:12 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ouh0F--h8hN5 for ; Tue, 16 Mar 2010 19:04:09 -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 53CC73A6A00 for ; Tue, 16 Mar 2010 19:04:09 -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: AvsEADPVn0urRN+J/2dsb2JhbACbAnOfKJhkhHYEgxo X-IronPort-AV: E=Sophos;i="4.49,654,1262563200"; d="scan'208";a="497799352" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 17 Mar 2010 02:04:18 +0000 Received: from dhcp-171-70-244-174.cisco.com (dhcp-171-70-244-174.cisco.com [171.70.244.174]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2H24IKP009382; Wed, 17 Mar 2010 02:04:18 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: Date: Tue, 16 Mar 2010 19:05:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] discussion topic: validation abstract vs implementation specific (http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-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, 17 Mar 2010 02:04:12 -0000 Hi Sandy, On Mar 16, 2010, at 9:26 AM, Sandra Murphy wrote: > I see no reason to believe that there will never be other proposals = for implementing route validation, or that we must decide on a single = proposal. Do you have a deadline in mind so as to make progress? What's the = motivation to _not_ decide on a single proposal? How do you see the = deployments in multi-proposal model? - Pradosh= From Sandra.Murphy@cobham.com Wed Mar 17 07:35:42 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DC03A6CEF for ; Wed, 17 Mar 2010 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHJFfE2vwnOf for ; Wed, 17 Mar 2010 07:35:41 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7D4FC28C162 for ; Wed, 17 Mar 2010 07:25:03 -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 o2HEPCTk005573; Wed, 17 Mar 2010 09:25:12 -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 o2HEPCK1009467; Wed, 17 Mar 2010 09:25:12 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.152]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 10:25:12 -0400 Date: Wed, 17 Mar 2010 10:25:12 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush 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: 17 Mar 2010 14:25:12.0424 (UTC) FILETIME=[A7A08680:01CAC5DD] Cc: sidr@ietf.org Subject: Re: [sidr] discussion topic: validation abstract vs implementation specific (http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-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, 17 Mar 2010 14:35:42 -0000 Are you requesting a separate time slot on the agenda for this presentation? --Sandy On Tue, 16 Mar 2010, Randy Bush wrote: >> I suggest to the working group that we could proceed with the current >> draft as the abstract model for route validation, and leave open the >> potential for other drafts that bring proposals for implementation >> specifics for route validation. (And that we should begin working on >> such implementation drafts.) > > having spent the last weeks, and specifically the last two days in the > bay area, discussing this with bgp implementors, i can not support this > position. we will be presenting a more realistic approach in anaheim. > > randy > From kent@bbn.com Wed Mar 17 13:06:38 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A813A69F4 for ; Wed, 17 Mar 2010 13:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn9Qwe8qD4Sz for ; Wed, 17 Mar 2010 13:06:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E41A23A69F1 for ; Wed, 17 Mar 2010 13:06:32 -0700 (PDT) Received: from dhcp89-089-168.bbn.com ([128.89.89.168]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NrzVq-0009hI-NX; Wed, 17 Mar 2010 16:06:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 17 Mar 2010 16:02:30 -0400 To: Sandra Murphy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] consensus call on IPR'd technologies X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 17 Mar 2010 20:06:38 -0000 At 12:23 PM -0400 3/16/10, Sandra Murphy wrote: >We spent some time before and after the last meeting discussing IPR issues. > >My view of the discussion is that the working group prefers >non-IPR'd technologies if given a choice, but there was no consensus >for rejecting IPR'd technologies completely. Therefore, drafts that >have IPR claims filed against them can both be adopted as working >group work items and be retained as working group work items. > >--Sandy I agree with your suggested way forward. I contacted the IPR guy cited in the Cisco disclosure, provided citations to previously published work in the area, and requested a clarification of what was being claimed vs. what was acknowledged as prior art. I am disappointed that he has not chosen to reply, after a message in which he asked me to specify the IPR disclosure to which I was responding :-). Steve From kotikalapudi.sriram@nist.gov Thu Mar 18 04:23:31 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8033A6918 for ; Thu, 18 Mar 2010 04:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.734 X-Spam-Level: X-Spam-Status: No, score=-4.734 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 87LU10Ap35nh for ; Thu, 18 Mar 2010 04:23:30 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 92FA33A690B for ; Thu, 18 Mar 2010 04:23:28 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o2IBNSwD031047; Thu, 18 Mar 2010 07:23:28 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 18 Mar 2010 07:23:12 -0400 From: "Sriram, Kotikalapudi" To: "sidr@ietf.org" Date: Thu, 18 Mar 2010 07:23:12 -0400 Thread-Topic: Prefix-Origin Validation Use Cases Thread-Index: AQHKxouEJVs6+6Ahsk+Ru7lp8iI6Wg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Subject: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Mar 2010 11:23:32 -0000 The uses cases listed below pertain to {Prefix, Orgin} validation, and are not yet included in draft-manderson-sidr-usecases-01 http://tools.ietf.org/html/draft-manderson-sidr-usecases-01 We plan to include them in the next updated revision (as a SIDR WG draft) w= hich we=20 (Terry, myself, Russ) expect to submit soon.=20 Your comments are requested. These use cases try to systematically enumerate the situations a relying pa= rty may encounter while receiving a BGP update and making use of ROA inform= ation to interpret the validity of the prefix-origin information in the upd= ate. We systematically enumerate the situations or scenarios but do not mak= e a final recommendation on any RPKI interpretation at this point. We have = included some comments on plausible RPKI recommendations. However, it is fu= lly acknowledged that these recommended RPKI interpretations can be overrid= den by ISP=92s local policy. It would generally be up to an ISP to make cho= ices regarding the interpretation or decision, based on various considerati= ons, including their view of =93Partial Deployment=94, =93Full Deployment= =94 of RPKI, etc.=20 Taxonomy: Update prefix: Prefix seen in an update ROA prefix: Prefix contained in a ROA=20 Covering Prefix: When we say that a ROA prefix is a covering prefix for an = update prefix, what is meant is that the ROA prefix in an exact match or a = less specific when compared to the update prefix. No relevant ROA: It means that there is no ROA that has a covering prefix f= or the update prefix. No other relevant ROA: It means that there is no other ROA (besides any tha= t is(are) already cited) that has a covering prefix for the update prefix=20 1. Covering ROA Prefix, Maxlength Satisfied, and AS Match: ROA: {10.1.0.0/16, maxlength =3D 20, AS64496} Update has {10.1.0.0/17, Origin =3D AS64496} Recommended RPKI prefix-origin validation interpretation: TBC Comment: This is a straight forward prefix-origin validation use case; it f= ollows from the primary intention of creation of ROA by a resource owner. R= ecommended RPKI validation interpretation could be: The announced prefix-or= igin pair is Valid. 2. Covering ROA Prefix, Maxlength Exceeded, and AS Match: ROA: {10.1.0.0/16, maxlength =3D 20, AS64496} Update has {10.1.0.0/22, Origin =3D AS64496} No other relevant ROA Recommended RPKI prefix-origin validation interpretation: TBC Comment: In this case the maxlength specified in the ROA is exceeded by the= update prefix. Recommended RPKI validation interpretation could be: The an= nounced prefix-origin pair is Invalid. 3. Covering ROA Prefix, Maxlength Satisfied, and AS Mismatch: ROA: {10.1.0.0/16, maxlength =3D 24, AS64496} Update has {10.1.88.0/24, Origin =3D AS65551} No other relevant ROA Recommended RPKI prefix-origin validation interpretation: TBC Comment: In this case an AS other than the one specified in the ROA is orig= inating an update. This may be a prefix or subprefix hijack situation. Rec= ommended RPKI validation interpretation could be: The announced prefix-orig= in pair is Invalid. 4. Covering ROA Prefix, Maxlength Exceeded, and AS Mismatch: ROA: {10.1.0.0/16, maxlength =3D 22, AS64496} Update has {10.1.88.0/24, Origin =3D AS65551} No other relevant ROA Recommended RPKI prefix-origin validation interpretation: TBC Comment: In this case the maxlength specified in the ROA is exceeded by the= update prefix, and also an AS other than the one specified in the ROA is o= riginating the update. This may be a subprefix hijack situation. Recommend= ed RPKI validation interpretation could be: The announced prefix-origin pai= r is Invalid. 5. Covering ROA Prefix Not Found: Update has {240.1.1.0/24, Origin =3D AS65551} No relevant ROA Recommended RPKI prefix-origin validation interpretation: TBC Comment: In this case there is no relevant ROA that has a covering prefix f= or the update prefix. It could be a case of prefix or subprefix hijack situ= ation, but this announcement does not contradict any existing ROA. During p= artial deployment, there would be some legitimate prefix-origin announcemen= ts for which ROAs may not have been issued yet. Recommended RPKI validation= interpretation could be: Announced prefix-origin pair has =91no ROA=92. 6. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set of More = Specifics: ROA: {10.1.0.0/18, maxlength =3D 20, AS64496} ROA: {10.1.64.0/18, maxlength =3D 20, AS64496} ROA: {10.1.128.0/18, maxlength =3D 20, AS64496} ROA: {10.1.192.0/18, maxlength =3D 20, AS64496} Update has {10.1.0.0/16, Origin =3D AS64496} No other relevant ROA Recommended RPKI prefix-origin validation interpretation: TBC Comment: In this case the update prefix is an aggregate, and it turns out t= hat there exit ROAs for more specifics which, if combined, can help support= validation of the announced prefix-origin pair. But it is not recommended = that we apply any leniency in this situation. The announced aggregate prefi= x should be required to have a ROA which can be directly used for validatio= n. Recommended RPKI validation interpretation could be: The announced prefi= x-origin pair is Invalid. =20 7. Update has an AS Set as Origin and ROAs Exist for a Covering Set of More= Specifics: ROA: {10.1.0.0/18, maxlength =3D 20, AS64496} ROA: {10.1.64.0/18, maxlength =3D 20, AS64497} ROA: {10.1.128.0/18, maxlength =3D 20, AS64498} ROA: {10.1.192.0/18, maxlength =3D 20, AS64499} Update has {10.1.0.0/16, Origin =3D [AS64496, AS64497, AS64498, AS64497]} No other relevant ROA Recommended RPKI prefix-origin validation interpretation: TBC Comment: In this case the aggregate of the prefixes in the ROAs is a coveri= ng prefix for the update prefix. The ASs in each of the contributing ROAs t= ogether form a set that matches the AS set in the update. An extremely smal= l percentage (~0.1%) of eBGP updates are seen to have AS set in them as ori= gin; this is known as proxy aggregation. It is recommended that announcemen= ts with an AS set as origin should be discouraged. Recommended RPKI validat= ion interpretation could be: The announced prefix-origin pair is Invalid. = =20 From ljb@merit.edu Thu Mar 18 08:32:57 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591A63A6AEC for ; Thu, 18 Mar 2010 08:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeiAB1gYNfAM for ; Thu, 18 Mar 2010 08:32:56 -0700 (PDT) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id 86E4F3A6C33 for ; Thu, 18 Mar 2010 08:32:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJHkoUvGbD6X/2dsb2JhbACbLXOsDYUJiFuEeQQ X-IronPort-AV: E=Sophos;i="4.51,267,1267419600"; d="scan'208";a="27086415" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Mar 2010 11:33:08 -0400 Message-ID: <4BA247B3.1000005@merit.edu> Date: Thu, 18 Mar 2010 11:33:07 -0400 From: Larry Blunk User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "sidr@ietf.org" Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Mar 2010 15:32:57 -0000 Sriram, Kotikalapudi wrote: > The uses cases listed below pertain to {Prefix, Orgin} validation, > and are not yet included in draft-manderson-sidr-usecases-01 > http://tools.ietf.org/html/draft-manderson-sidr-usecases-01 > We plan to include them in the next updated revision (as a SIDR WG draft) which we > (Terry, myself, Russ) expect to submit soon. > Your comments are requested. > > These use cases try to systematically enumerate the situations a relying party may encounter while receiving a BGP update and making use of ROA information to interpret the validity of the prefix-origin information in the update. We systematically enumerate the situations or scenarios but do not make a final recommendation on any RPKI interpretation at this point. We have included some comments on plausible RPKI recommendations. However, it is fully acknowledged that these recommended RPKI interpretations can be overridden by ISP’s local policy. It would generally be up to an ISP to make choices regarding the interpretation or decision, based on various considerations, including their view of “Partial Deployment”, “Full Deployment” of RPKI, etc. > > I'd like to see some mention of scenarios involving customer sessions/small scale peering vs. large-scale peering. Providers may likely wish to have more stringent enforcement on customer sessions where the lack of covering ROA for a prefix is treated as an invalid announcment. Much as those providers who use IRR based filtering do today. I believe this will also help improve deployment. I've also mentioned in the past that I consider the use of maxlength to be potentially dangerous (where the full set of most specifics are not announced) in that I believe it makes hijacking via path manipulation easier. Don't know if that bears mention in this document or perhaps a new one. I'd be willing to write something up if it would be helpful. -Larry Blunk Merit Network From Sandra.Murphy@cobham.com Thu Mar 18 08:45:32 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97CA3A63EC for ; Thu, 18 Mar 2010 08:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.164 X-Spam-Level: X-Spam-Status: No, score=-1.164 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lvfe0rTJppx7 for ; Thu, 18 Mar 2010 08:45:32 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 648663A67D6 for ; Thu, 18 Mar 2010 08:45:30 -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 o2IFjeHB022163; Thu, 18 Mar 2010 10:45:41 -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 o2IFjL2P026395; Thu, 18 Mar 2010 10:45:40 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.152]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Mar 2010 11:45:15 -0400 Date: Thu, 18 Mar 2010 11:45:15 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Larry Blunk In-Reply-To: <4BA247B3.1000005@merit.edu> Message-ID: References: <4BA247B3.1000005@merit.edu> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="158888028-5358-1268926781=:4732" X-OriginalArrivalTime: 18 Mar 2010 15:45:15.0162 (UTC) FILETIME=[00B1EFA0:01CAC6B2] Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Mar 2010 15:45:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --158888028-5358-1268926781=:4732 Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 18 Mar 2010, Larry Blunk wrote: > Sriram, Kotikalapudi wrote: >> The uses cases listed below pertain to {Prefix, Orgin} validation, >> and are not yet included in draft-manderson-sidr-usecases-01 >> http://tools.ietf.org/html/draft-manderson-sidr-usecases-01 >> We plan to include them in the next updated revision (as a SIDR WG draft= )=20 >> which we (Terry, myself, Russ) expect to submit soon. Your comments are= =20 >> requested. >>=20 >> These use cases try to systematically enumerate the situations a relying= =20 >> party may encounter while receiving a BGP update and making use of ROA= =20 >> information to interpret the validity of the prefix-origin information i= n=20 >> the update. We systematically enumerate the situations or scenarios but = do=20 >> not make a final recommendation on any RPKI interpretation at this point= =2E=20 >> We have included some comments on plausible RPKI recommendations. Howeve= r,=20 >> it is fully acknowledged that these recommended RPKI interpretations can= be=20 >> overridden by ISP=92s local policy. It would generally be up to an ISP t= o=20 >> make choices regarding the interpretation or decision, based on various= =20 >> considerations, including their view of =93Partial Deployment=94, =93Ful= l=20 >> Deployment=94 of RPKI, etc. >>=20 > > I'd like to see some mention of scenarios involving customer > sessions/small scale peering vs. large-scale peering. > Providers may likely wish to have more stringent > enforcement on customer sessions where the lack of covering ROA > for a prefix is treated as an invalid announcment. Much as > those providers who use IRR based filtering do today. I believe > this will also help improve deployment. > > I've also mentioned in the past that I consider the use of > maxlength to be potentially dangerous (where the full set > of most specifics are not announced) in that I believe it > makes hijacking via path manipulation easier. Don't know > if that bears mention in this document or perhaps a new one. > I'd be willing to write something up if it would be helpful. That's an interesting statement. If you can substantiate security=20 concerns arising from having a maxlength in the ROA, please do document it= =20 as quickly as possible. Please. ASAP. Do you really mean "hijacking via path manipulation" not "hijacking via=20 origin manipulation"? The sidr wg is not working on path validation at=20 this time, we are working on origin authorization only. So such a comment= =20 might not require a fix to the current documents. But if you can see that a ROA with a maxlength might make it easier for=20 someone to manipulate the remainder of the path somehow, I for one would=20 be interested to hear, anyway. --Sandy > > > -Larry Blunk > Merit Network > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --158888028-5358-1268926781=:4732-- From ljb@merit.edu Thu Mar 18 12:22:19 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F643A6B8E for ; Thu, 18 Mar 2010 12:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.48 X-Spam-Level: X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4M3tv-Fe778 for ; Thu, 18 Mar 2010 12:22:17 -0700 (PDT) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id 69E073A6B96 for ; Thu, 18 Mar 2010 12:22:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH4aokvGbD6X/2dsb2JhbACDC5gic6ltgmGFDYhbgSyCZGkE X-IronPort-AV: E=Sophos;i="4.51,269,1267419600"; d="scan'208";a="27105151" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Mar 2010 15:22:20 -0400 Message-ID: <4BA27D6B.7080207@merit.edu> Date: Thu, 18 Mar 2010 15:22:19 -0400 From: Larry Blunk User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Sandra Murphy References: <4BA247B3.1000005@merit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Mar 2010 19:22:19 -0000 Sandra Murphy wrote: > > > On Thu, 18 Mar 2010, Larry Blunk wrote: > >> Sriram, Kotikalapudi wrote: >>> The uses cases listed below pertain to {Prefix, Orgin} validation, >>> and are not yet included in draft-manderson-sidr-usecases-01 >>> http://tools.ietf.org/html/draft-manderson-sidr-usecases-01 >>> We plan to include them in the next updated revision (as a SIDR WG >>> draft) which we (Terry, myself, Russ) expect to submit soon. Your >>> comments are requested. >>> >>> These use cases try to systematically enumerate the situations a >>> relying party may encounter while receiving a BGP update and making >>> use of ROA information to interpret the validity of the >>> prefix-origin information in the update. We systematically enumerate >>> the situations or scenarios but do not make a final recommendation >>> on any RPKI interpretation at this point. We have included some >>> comments on plausible RPKI recommendations. However, it is fully >>> acknowledged that these recommended RPKI interpretations can be >>> overridden by ISP�s local policy. It would generally be up to an ISP >>> to make choices regarding the interpretation or decision, based on >>> various considerations, including their view of �Partial >>> Deployment�, �Full Deployment� of RPKI, etc. >>> >> >> I'd like to see some mention of scenarios involving customer >> sessions/small scale peering vs. large-scale peering. >> Providers may likely wish to have more stringent >> enforcement on customer sessions where the lack of covering ROA >> for a prefix is treated as an invalid announcment. Much as >> those providers who use IRR based filtering do today. I believe >> this will also help improve deployment. >> >> I've also mentioned in the past that I consider the use of >> maxlength to be potentially dangerous (where the full set >> of most specifics are not announced) in that I believe it >> makes hijacking via path manipulation easier. Don't know >> if that bears mention in this document or perhaps a new one. >> I'd be willing to write something up if it would be helpful. > > That's an interesting statement. If you can substantiate security > concerns arising from having a maxlength in the ROA, please do > document it as quickly as possible. Please. ASAP. > > Do you really mean "hijacking via path manipulation" not "hijacking > via origin manipulation"? The sidr wg is not working on path > validation at this time, we are working on origin authorization only. > So such a comment might not require a fix to the current documents. Yes, specifically origin manipulation (which would be covered by path manipulation) > > But if you can see that a ROA with a maxlength might make it easier > for someone to manipulate the remainder of the path somehow, I for one > would be interested to hear, anyway. Not easier to manipulate the origin, just better results from such techniques. If maxlength is used, but not all the most specifics are actually announced, an attacker could announce a more specific from the block that will pass validation with a manipulated origin. Without a maxlength, they can still manipulate the origin to validate, but they are limited to announcing a prefix of the same length as an existing announcement. Such attacks will likely be considerably more limited in scope of impact than a more specific of an existing announcement. -Larry From roque.ietf@gmail.com Thu Mar 18 14:02:16 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537993A6989 for ; Thu, 18 Mar 2010 14:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV+cWUdwATUR for ; Thu, 18 Mar 2010 14:02:15 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 98F5A3A6988 for ; Thu, 18 Mar 2010 14:02:14 -0700 (PDT) Received: by wyb29 with SMTP id 29so1251734wyb.31 for ; Thu, 18 Mar 2010 14:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3Pi+mttLaAl4xXnWdULaA3rymDCpBlFycp5SngI8JYM=; b=bVdk7KSjDhMtbHvIAQBj5Nw8qv8xdra+m+X17Byr3IvxjT1UHfvzlMK2k58XEVI35l H3k8eX6piuvvmgHeSkEozE4vp192qvdiUisWuGvrFX8j93YjhHokDPqYQR1AiSbL8SUv vNY0cFsLMXjbA7WPnmo+8aopo3MCoMTfK/UBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YLqFmaWBB7C8P3BG5bApojzs31MkQhO09wYWWAW4v2l1HQbALAhukxJvEYGKqwdDmE gENnw7PgEt6o08TEO7JgtQ82FJjIKsTcyZpa4zih3dQCuZr6+AOnfb+Tctu2wzNE/SjU PmuFM8CKIvgy4xvxEcAJZ28NcjdaWFj8NOND4= MIME-Version: 1.0 Received: by 10.216.174.133 with SMTP id x5mr905903wel.55.1268946142502; Thu, 18 Mar 2010 14:02:22 -0700 (PDT) In-Reply-To: <4BA27D6B.7080207@merit.edu> References: <4BA247B3.1000005@merit.edu> <4BA27D6B.7080207@merit.edu> Date: Thu, 18 Mar 2010 22:02:22 +0100 Message-ID: <5f70d8c91003181402h1be9ed85u1d232cf5cbc34fa1@mail.gmail.com> From: Roque Gagliano To: Larry Blunk Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 18 Mar 2010 21:02:16 -0000 Larry, > > Not easier to manipulate the origin, just better results > from such techniques. If maxlength is used, but not > all the most specifics are actually announced, an attacker could > announce a more specific from the block that will > pass validation with a manipulated origin. > Could you please explain what do you mean by "manipulate the origin"? As Sandy mentioned I see cases that you could manipulate the ASN Path and validate. Thanks, Roque. From kotikalapudi.sriram@nist.gov Fri Mar 19 10:19:48 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359E93A6861 for ; Fri, 19 Mar 2010 10:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.361 X-Spam-Level: X-Spam-Status: No, score=-4.361 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 q6XGpOHfbYpG for ; Fri, 19 Mar 2010 10:19:47 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id C2E483A68AC for ; Fri, 19 Mar 2010 10:19:14 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o2JHJJcj001969; Fri, 19 Mar 2010 13:19:19 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Fri, 19 Mar 2010 13:19:19 -0400 From: "Sriram, Kotikalapudi" To: Larry Blunk Date: Fri, 19 Mar 2010 13:19:13 -0400 Thread-Topic: [sidr] Prefix-Origin Validation Use Cases Thread-Index: AcrGsGQIx6vmAvztQCGx2jp3zaepcAA1WBew Message-ID: References: <4BA247B3.1000005@merit.edu> In-Reply-To: <4BA247B3.1000005@merit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Mar 2010 17:19:48 -0000 If some people preferred to see a pdf version of my long first (initial)=20 posting on this topic, here is a link for that: http://www.antd.nist.gov/~ksriram/Prefix_Origin_UseCases.pdf Now to Larry's question: Thanks, Larry, for your comments. I will think about you suggestion about use cases for differentiating small scale peering vs. large-scale peering, and also discuss it with my co-authors. We will report if we can come up with something. I would also like to speak to you about this at the IETF if you plan to att= end. Regarding the maxlength issue, > I consider the use of > maxlength to be potentially dangerous (where the full set > of most specifics are not announced) I have question for you. When YouTube prefix was hijacked,=20 it had to announce /24s and then /25s out of its=20 aggregate /22 in order to recover the traffic. If YouTube registers a ROA with only the /22 and no maxlength, then even its own updates with the more-specifics for recovering=20 the traffic (under hijack) would be dropped. If maxlength is not specified, how do you envision a solution for this? Sriram > -----Original Message----- > From: Larry Blunk [mailto:ljb@merit.edu] > Sent: Thursday, March 18, 2010 11:33 AM > To: Sriram, Kotikalapudi > Cc: sidr@ietf.org > Subject: Re: [sidr] Prefix-Origin Validation Use Cases >=20 > Sriram, Kotikalapudi wrote: > > The uses cases listed below pertain to {Prefix, Orgin} validation, > > and are not yet included in draft-manderson-sidr-usecases-01 > > http://tools.ietf.org/html/draft-manderson-sidr-usecases-01 > > We plan to include them in the next updated revision (as a SIDR WG draf= t) which we > > (Terry, myself, Russ) expect to submit soon. > > Your comments are requested. > > > > These use cases try to systematically enumerate the situations a relyin= g party may > encounter while receiving a BGP update and making use of ROA information = to interpret > the validity of the prefix-origin information in the update. We systemati= cally enumerate the > situations or scenarios but do not make a final recommendation on any RPK= I interpretation > at this point. We have included some comments on plausible RPKI recommend= ations. > However, it is fully acknowledged that these recommended RPKI interpretat= ions can be > overridden by ISP's local policy. It would generally be up to an ISP to m= ake choices > regarding the interpretation or decision, based on various considerations= , including their > view of "Partial Deployment", "Full Deployment" of RPKI, etc. > > > > >=20 > I'd like to see some mention of scenarios involving customer > sessions/small scale peering vs. large-scale peering. > Providers may likely wish to have more stringent > enforcement on customer sessions where the lack of covering ROA > for a prefix is treated as an invalid announcment. Much as > those providers who use IRR based filtering do today. I believe > this will also help improve deployment. >=20 > I've also mentioned in the past that I consider the use of > maxlength to be potentially dangerous (where the full set > of most specifics are not announced) in that I believe it > makes hijacking via path manipulation easier. Don't know > if that bears mention in this document or perhaps a new one. > I'd be willing to write something up if it would be helpful. >=20 >=20 > -Larry Blunk > Merit Network >=20 From ljb@merit.edu Fri Mar 19 12:31:35 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7B93A67EC for ; Fri, 19 Mar 2010 12:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLUQd2uBxZzP for ; Fri, 19 Mar 2010 12:31:34 -0700 (PDT) Received: from thor.merit.edu (thor.merit.edu [198.108.1.14]) by core3.amsl.com (Postfix) with ESMTP id E8CD03A67AE for ; Fri, 19 Mar 2010 12:31:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF1uo0vGbD6X/2dsb2JhbACbQHOsTYUIiFuEegQ X-IronPort-AV: E=Sophos;i="4.51,276,1267419600"; d="scan'208";a="27187570" Received: from ablate.merit.edu ([198.108.62.151]) by thor.merit.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Mar 2010 15:31:47 -0400 Message-ID: <4BA3D122.9000704@merit.edu> Date: Fri, 19 Mar 2010 15:31:46 -0400 From: Larry Blunk User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Sriram, Kotikalapudi" References: <4BA247B3.1000005@merit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Mar 2010 19:31:35 -0000 Sriram, Kotikalapudi wrote: > If some people preferred to see a pdf version of my long first (initial) > posting on this topic, here is a link for that: > http://www.antd.nist.gov/~ksriram/Prefix_Origin_UseCases.pdf > > Now to Larry's question: > > Thanks, Larry, for your comments. > I will think about you suggestion about use cases for differentiating > small scale peering vs. large-scale peering, > and also discuss it with my co-authors. > We will report if we can come up with something. > I would also like to speak to you about this at the IETF if you plan to attend. > Yes, I will be there. > Regarding the maxlength issue, > >> I consider the use of >> maxlength to be potentially dangerous (where the full set >> of most specifics are not announced) >> > I have question for you. > When YouTube prefix was hijacked, > it had to announce /24s and then /25s out of its > aggregate /22 in order to recover the traffic. > If YouTube registers a ROA with only the /22 and no maxlength, > then even its own updates with the more-specifics for recovering > the traffic (under hijack) would be dropped. > If maxlength is not specified, how do you envision > a solution for this? > Yes, I've considered this as a possible argument to using maxlength. And I do see some validity to it in limited or partial deployment scenarios of ROA's. However, you failed to point out that Pakistan Telecom was announcing a /24 more specific out of the /22 aggregate. And this is the main reason why it was so successful. The reason for the /25's being announced by Youtube was to combat Pakistan Telecom's /24. I think the case study helps prove my point if you think about the reverse situation. Namely, that if Pakistan Telecom had been limited to announcing a /22 by a ROA with maxlength 22, they would have likely had more limited success since they would have been competing against the existing /22 from Youtube. Just as Youtube had problems overcoming Pakistan Telecom's /24 with it's own /24 announcement (and ended up using /25's), you can imagine that Pakistan Telecom would have had limited effect if it had been limited to announcing a /22 against Youtube's existing /22 announcement. -Larry > Sriram > > > > >> -----Original Message----- >> From: Larry Blunk [mailto:ljb@merit.edu] >> Sent: Thursday, March 18, 2010 11:33 AM >> To: Sriram, Kotikalapudi >> Cc: sidr@ietf.org >> Subject: Re: [sidr] Prefix-Origin Validation Use Cases >> >> Sriram, Kotikalapudi wrote: >> >>> The uses cases listed below pertain to {Prefix, Orgin} validation, >>> and are not yet included in draft-manderson-sidr-usecases-01 >>> http://tools.ietf.org/html/draft-manderson-sidr-usecases-01 >>> We plan to include them in the next updated revision (as a SIDR WG draft) which we >>> (Terry, myself, Russ) expect to submit soon. >>> Your comments are requested. >>> >>> These use cases try to systematically enumerate the situations a relying party may >>> >> encounter while receiving a BGP update and making use of ROA information to interpret >> the validity of the prefix-origin information in the update. We systematically enumerate the >> situations or scenarios but do not make a final recommendation on any RPKI interpretation >> at this point. We have included some comments on plausible RPKI recommendations. >> However, it is fully acknowledged that these recommended RPKI interpretations can be >> overridden by ISP's local policy. It would generally be up to an ISP to make choices >> regarding the interpretation or decision, based on various considerations, including their >> view of "Partial Deployment", "Full Deployment" of RPKI, etc. >> >>> >> I'd like to see some mention of scenarios involving customer >> sessions/small scale peering vs. large-scale peering. >> Providers may likely wish to have more stringent >> enforcement on customer sessions where the lack of covering ROA >> for a prefix is treated as an invalid announcment. Much as >> those providers who use IRR based filtering do today. I believe >> this will also help improve deployment. >> >> I've also mentioned in the past that I consider the use of >> maxlength to be potentially dangerous (where the full set >> of most specifics are not announced) in that I believe it >> makes hijacking via path manipulation easier. Don't know >> if that bears mention in this document or perhaps a new one. >> I'd be willing to write something up if it would be helpful. >> >> >> -Larry Blunk >> Merit Network >> >> > > From danny@arbor.net Fri Mar 19 15:23:09 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D2D3A6808 for ; Fri, 19 Mar 2010 15:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2no2KiPsaW6 for ; Fri, 19 Mar 2010 15:23:07 -0700 (PDT) Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by core3.amsl.com (Postfix) with ESMTP id BFF9A3A6916 for ; Fri, 19 Mar 2010 15:23:05 -0700 (PDT) Received: from gateout01.mbox.net (gateout01-lo [127.0.0.1]) by gateout01.mbox.net (Postfix) with ESMTP id 5AD68CC6AA; Fri, 19 Mar 2010 22:23:18 +0000 (GMT) Received: from s1hub4.EXCHPROD.USA.NET [165.212.120.254] by gateout01.mbox.net via smtad (C8.MAIN.3.61T) with ESMTPS id XID773ocswXs4308Xo1; Fri, 19 Mar 2010 22:23:18 -0000 X-USANET-Source: 165.212.120.254 IN danny@arbor.net s1hub4.EXCHPROD.USA.NET X-USANET-MsgId: XID773ocswXs4308Xo1 Received: from sslvpn-40.ma.arbor.net (204.118.128.2) by exchange.postoffice.net (10.120.220.34) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 19 Mar 2010 22:22:29 +0000 Message-ID: <4BA3F952.7050602@arbor.net> Date: Fri, 19 Mar 2010 16:23:14 -0600 From: Danny McPherson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Larry Blunk References: <4BA247B3.1000005@merit.edu> <4BA3D122.9000704@merit.edu> In-Reply-To: <4BA3D122.9000704@merit.edu> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Mar 2010 22:23:09 -0000 On 3/19/10 1:31 PM, Larry Blunk wrote: > I think the case study helps prove my point if you think about > the reverse situation. Namely, that if Pakistan Telecom had been > limited to announcing a /22 by a ROA with maxlength 22, they > would have likely had more limited success since they would > have been competing against the existing /22 from Youtube. > Just as Youtube had problems overcoming Pakistan Telecom's > /24 with it's own /24 announcement (and ended up using /25's), you can > imagine that Pakistan Telecom would have had limited > effect if it had been limited to announcing a /22 against > Youtube's existing /22 announcement. Indeed. The only place the argument Sriram is making holds is when you've got limited or partial deployment - -that's Terry's big concern as well, IIRC. I still very much prefer the explicit length model that mirrors prefix filters employed today and 15 years ago. It encourages people to aggregate effectively and mitigates deaggregation incidents. -danny From danny@tcb.net Fri Mar 19 15:28:45 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C79E3A69AA for ; Fri, 19 Mar 2010 15:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.105 X-Spam-Level: X-Spam-Status: No, score=-101.105 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 SG5ILI2ZPp1f for ; Fri, 19 Mar 2010 15:28:45 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 0790B3A6857 for ; Fri, 19 Mar 2010 15:28:45 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0C869268679; Fri, 19 Mar 2010 16:28:58 -0600 (MDT) Received: from sslvpn-40.ma.arbor.net (204.118.128.2 [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; for sidr@ietf.org; Fri, 19 Mar 2010 16:28:57 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=204.118.128.2; client-port=45191; client-dnsfail=204.118.128.2: name server failure; syn-fingerprint=65535:45:1:64:M1360,N,W3,N,N,T,S; data-bytes=0 Message-ID: <4BA3FA96.50402@tcb.net> Date: Fri, 19 Mar 2010 16:28:38 -0600 From: Danny McPherson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: sidr@ietf.org References: <4BA247B3.1000005@merit.edu> <4BA27D6B.7080207@merit.edu> In-Reply-To: <4BA27D6B.7080207@merit.edu> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 19 Mar 2010 22:28:45 -0000 On 3/18/10 1:22 PM, Larry Blunk wrote: > > Not easier to manipulate the origin, just better results > from such techniques. If maxlength is used, but not > all the most specifics are actually announced, an attacker could > announce a more specific from the block that will > pass validation with a manipulated origin. Without a > maxlength, they can still manipulate the origin to validate, but > they are limited to announcing a prefix of the same length > as an existing announcement. Such attacks will likely be > considerably more limited in scope of impact than a more > specific of an existing announcement. It might also be worth noting here that while you're referring to origin *AS*, origin code manipulation in many cases will garner much more diverted traffic, even if prefixes are of equal length. E.g., some large ISPs have been known to reset "incomplete" to "internal" and have dramatic impacts on transited traffic rates.. -danny From randy@psg.com Fri Mar 19 17:12:10 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDA83A6954 for ; Fri, 19 Mar 2010 17:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjXYvlCpUGIy for ; Fri, 19 Mar 2010 17:12:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 15BFD3A6AB2 for ; Fri, 19 Mar 2010 17:12:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NsmIW-00027U-Oy; Sat, 20 Mar 2010 00:12:12 +0000 Date: Fri, 19 Mar 2010 17:12:11 -0700 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: <4BA3FA96.50402@tcb.net> References: <4BA247B3.1000005@merit.edu> <4BA27D6B.7080207@merit.edu> <4BA3FA96.50402@tcb.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Mar 2010 00:12:10 -0000 max-len is at the choice of the issuer of the roa. it is a macro so they do not have to issue all the smaller roas. if they don't want the longer prefixes announced, then they should not issue the roas, whether as individual roas or in the equivalent max-len macro. and the pakistan telkom accident is not a useful analogy. the announcement did not come from the owning asn. randy From ljb@merit.edu Sat Mar 20 07:05:21 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825B13A68CC for ; Sat, 20 Mar 2010 07:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=1.163, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 rn1AcrRE-L3y for ; Sat, 20 Mar 2010 07:05:20 -0700 (PDT) Received: from magus.merit.edu (magus.merit.edu [198.108.1.13]) by core3.amsl.com (Postfix) with ESMTP id BA0353A68B4 for ; Sat, 20 Mar 2010 07:05:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by magus.merit.edu (Postfix) with ESMTP id 467912251E6; Sat, 20 Mar 2010 10:05:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at magus.merit.edu Received: from magus.merit.edu ([127.0.0.1]) by localhost (magus.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9TEgQOaY5s4; Sat, 20 Mar 2010 10:05:35 -0400 (EDT) Received: from crono.merit.edu (crono.merit.edu [198.108.1.12]) by magus.merit.edu (Postfix) with ESMTP id 1F4722251E5; Sat, 20 Mar 2010 10:05:35 -0400 (EDT) Date: Sat, 20 Mar 2010 10:05:35 -0400 (EDT) From: "Larry J. Blunk" To: Randy Bush Message-ID: <1054351642.8758811269093934988.JavaMail.root@crono> In-Reply-To: <959197808.8758421269093518794.JavaMail.root@crono> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [198.108.1.13] X-Mailer: Zimbra 5.0.20_GA_3127.SLES10_64 (ZimbraWebClient - FF3.0 (Win)/5.0.20_GA_3127.SLES10_64) Cc: sidr@ietf.org Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Mar 2010 14:05:21 -0000 ----- "Randy Bush" wrote: > max-len is at the choice of the issuer of the roa. it is a macro so > they do not have to issue all the smaller roas. if they don't want the > longer prefixes announced, then they should not issue the roas, whether > as individual roas or in the equivalent max-len macro. Randy, my point is that one should be careful in the use of maxlen. If you do not intend to actually announce the more specifics on a continuous basis, or only intend to announce a subset of the more specifics, you are opening yourself up to an attack from someone who announces the currently unannounced more specifics (and inserts the correct origin in the path to pass the origin check). > > and the pakistan telkom accident is not a useful analogy. the > announcement did not come from the owning asn. > The lesson was about the danger of more specifics. Would the attack had been as successful if had announced a matching /22 instead of a /24? Imagine a ROA future where Pakistan Telkom replays the attack and inserts the correct origin in the path to match the Youtube ROA. The attack still succeeds if Youtube has a maxlength of 24 for their /22 ROA. It fails if Youtube requires an exact match 22 in their ROA. I would also point out that the AS7007 incident involved more specifics, not just exact match prefix lengths. ROA's give one the ability to specify both origin AS and prefix length. Gratuitous use of maxlength negates the prefix length matching capability of ROA's. -Larry From randy@psg.com Sat Mar 20 09:43:53 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F333A6A89 for ; Sat, 20 Mar 2010 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=-1.583, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB46P-glDRrp for ; Sat, 20 Mar 2010 09:43:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7E6773A6AC3 for ; Sat, 20 Mar 2010 09:43:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nt1mK-0003vj-Nf; Sat, 20 Mar 2010 16:44:00 +0000 Date: Sat, 20 Mar 2010 09:43:54 -0700 Message-ID: From: Randy Bush To: "Larry J. Blunk" In-Reply-To: <1054351642.8758811269093934988.JavaMail.root@crono> References: <959197808.8758421269093518794.JavaMail.root@crono> <1054351642.8758811269093934988.JavaMail.root@crono> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 20 Mar 2010 16:43:53 -0000 > The lesson was about the danger of more specifics. > Would the attack had been as successful if had > announced a matching /22 instead of a /24? Imagine > a ROA future where Pakistan Telkom replays the attack > and inserts the correct origin in the path to match the > Youtube ROA. The attack still succeeds if Youtube > has a maxlength of 24 for their /22 ROA. It fails if > Youtube requires an exact match 22 in their ROA. > > I would also point out that the AS7007 incident involved > more specifics, not just exact match prefix lengths. > ROA's give one the ability to specify both origin AS > and prefix length. Gratuitous use of maxlength > negates the prefix length matching capability of ROA's. your use of the word attack is not appropriate. it was an accident. aside from that, all of this is true. roas simply can not and will not deal with deliberate forging. they do not deal with attacks. they just deal with 99% of the problems we have today, fat fingered accidents. a roa for the /22, with or without roas for the covered /24s would have prevented the pt accident. dealing with attacks is a non-trivial design and engineering problem. if you want to know how hard, i suggest looking at sharon goldberg's work in this area. where roas will fail in even their simple task is more likely roa and certificate expiration and/or invalidation. with some rirs planning on turning certificate and roa issuance into an income stream tied to leasing the address space which they got for free [0], any use of the rpki approach to make routing more resilient is doomed. randy --- [0] - remember all the rir assertions that the rirs abjure all control of routing? well, this is a horrifyingly strong control. From christopher.morrow@gmail.com Sun Mar 21 21:57:10 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7053A67B6 for ; Sun, 21 Mar 2010 21:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.068 X-Spam-Level: X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsqErs2ShYYF for ; Sun, 21 Mar 2010 21:57:10 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id BFA8A3A68E9 for ; Sun, 21 Mar 2010 21:57:09 -0700 (PDT) Received: by iwn27 with SMTP id 27so1444178iwn.5 for ; Sun, 21 Mar 2010 21:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=weXmalbvauqR+AoK07BQlcVsGYaPRtyaaYuqrADPOFk=; b=eQakN1pLJ70g7D9DqFKp0/up4bY8ha1IiZMJwjMoPM8KGnTHtsSh/iFkOHT0lxfMY5 +UF/tiW8Bua2Kev6KnBsj87CktX8O9Z+ezXAbVT7F2HrzAXi4y0scCPlpUWnxVeGrmW2 bHTRTh7A8POcVimo3YiqwjJj8mkeu8rsBS3gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=lbvH4mB9Owom2tN065o6aZ7msF4RonDoGAli45LuORnj/698pwTXP2HEs+sYAM5wTX Ue+NV7t0mepLL38ts3Y/Q/tCjt/gmyN1Akc7Aa6yWhhj7bdq7ITDC4WLUaaJ/1LcvMe6 mS7CdxYavkLU0DbXRhZhD6zWm6BfqNGygcnnw= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.231.182.19 with SMTP id ca19mr1282698ibb.58.1269233843465; Sun, 21 Mar 2010 21:57:23 -0700 (PDT) In-Reply-To: References: <4BA247B3.1000005@merit.edu> <4BA27D6B.7080207@merit.edu> <4BA3FA96.50402@tcb.net> Date: Mon, 22 Mar 2010 00:57:23 -0400 X-Google-Sender-Auth: d40b72d98b24ae8f Message-ID: <75cb24521003212157s5e6e1290v2001d3a1aaace269@mail.gmail.com> From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Prefix-Origin Validation Use Cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 22 Mar 2010 04:57:10 -0000 On Fri, Mar 19, 2010 at 8:12 PM, Randy Bush wrote: > max-len is at the choice of the issuer of the roa. =A0it is a macro so > they do not have to issue all the smaller roas. =A0if they don't want the > longer prefixes announced, then they should not issue the roas, whether > as individual roas or in the equivalent max-len macro. note that in a transitional world there will either be: 1) a chance to put a more specific in un-validated and cause an outage while the signer runs around getting rpki updates flushed thorugh 2) lots of max-len=3D24 roas Once utopia arrives folks could back off to their prefix-len +1 max-len (or something not 'every to the /24'... -chris > and the pakistan telkom accident is not a useful analogy. =A0the > announcement did not come from the owning asn. you say tomato, I say tool of the regime to get a recalcitrants attention... (I really don't know, but the point is likely only the implementor of the change does) -chris From wei.yinxing@zte.com.cn Mon Mar 22 15:07:35 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B693A69BB for ; Mon, 22 Mar 2010 15:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.922 X-Spam-Level: X-Spam-Status: No, score=-98.922 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 uhjX7nLYteGM for ; Mon, 22 Mar 2010 15:07:32 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id AA4F53A6973 for ; Mon, 22 Mar 2010 15:07:27 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 128641783260960; Tue, 23 Mar 2010 06:06:46 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.1783260960; Tue, 23 Mar 2010 06:07:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2MM7e7v019135 for ; Tue, 23 Mar 2010 06:07:40 +0800 (CST) (envelope-from wei.yinxing@zte.com.cn) To: sidr@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wei.yinxing@zte.com.cn Date: Tue, 23 Mar 2010 06:07:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-23 06:07:39, Serialize complete at 2010-03-23 06:07:39 Content-Type: multipart/alternative; boundary="=_alternative 007989CE482576EE_=" X-MAIL: mse2.zte.com.cn o2MM7e7v019135 Subject: [sidr] draft-wei-sidr-cta-00.txt("A cryptographically generated issuer name for trust anchor") will not be presented in this meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 22 Mar 2010 22:07:35 -0000 This is a multipart message in MIME format. --=_alternative 007989CE482576EE_= Content-Type: text/plain; charset="US-ASCII" Dear all, I have requested that the following I-D will not be presented in this meeting. If any questions or comments, we can discuss them offline. *********************************************************************************************************************************** http://www.ietf.org/proceedings/10mar/agenda/sidr.html (c) CGA names for TAs 10 minutes A cryptographically generated issuer name for trust anchor draft-wei-sidr-cta-00.txt http://tools.ietf.org/id/draft-wei-sidr-cta-00.txt Presenter: Yinxing Wei Best Regards! Yinxing Wei -------------------------------------------------------------------------------- Address: System Architecture Department, Central Institute, ZTE Corporation Room 2C4, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China Zipcode: 210012 Office Telephone: +86-025-52877993 Mobile Telephone: +86-13611519358 Fax: +86-25-52878008 MSN: weiyinxing@hotmail.com --------------------------------------------------------------------------------- -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 007989CE482576EE_= Content-Type: text/html; charset="US-ASCII"
 Dear all,

  I have requested that the following I-D will not be presented in this meeting. If any questions or comments, we can discuss them offline.

***********************************************************************************************************************************
http://www.ietf.org/proceedings/10mar/agenda/sidr.html

(c) CGA names for TAs                                     10 minutes
    A cryptographically generated issuer name for trust anchor
   draft-wei-sidr-cta-00.txt
   http://tools.ietf.org/id/draft-wei-sidr-cta-00.txt

   Presenter: Yinxing Wei

Best Regards!

Yinxing Wei
--------------------------------------------------------------------------------
Address: System Architecture Department, Central Institute, ZTE Corporation
        Room 2C4, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China
Zipcode: 210012
Office Telephone: +86-025-52877993
Mobile Telephone: +86-13611519358
Fax: +86-25-52878008
MSN: weiyinxing@hotmail.com
---------------------------------------------------------------------------------
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 007989CE482576EE_=-- From Sandra.Murphy@cobham.com Tue Mar 23 15:43:21 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EBF3A6952 for ; Tue, 23 Mar 2010 15:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxWETLriZXvm for ; Tue, 23 Mar 2010 15:43:21 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2F8D73A68C0 for ; Tue, 23 Mar 2010 15:43: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 o2NMhaoV026461; Tue, 23 Mar 2010 17:43:36 -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 o2NMhaNE016193; Tue, 23 Mar 2010 17:43:36 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.248.12]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Mar 2010 18:43:34 -0400 Date: Tue, 23 Mar 2010 18:43:24 -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: 23 Mar 2010 22:43:36.0120 (UTC) FILETIME=[4618EB80:01CACADA] Cc: Chris Morrow Subject: [sidr] volunteers for minutes taker and jabber scribe X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 23 Mar 2010 22:43:22 -0000 We need volunteers for taking the minutes of the meeting and serving as jabber scribe. It would help considerably if we could have those volunteers identified before the meeting (which is tomorrow, Mar 24, 9:00-11:30). If you are willing to server in either role, please send a message to both co-chairs or the list. --Sandy From mreynold@bbn.com Thu Mar 25 10:35:07 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF023A6B8F for ; Thu, 25 Mar 2010 10:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 QeT2yGdfTNx5 for ; Thu, 25 Mar 2010 10:35:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5E42A3A681C for ; Thu, 25 Mar 2010 10:29:18 -0700 (PDT) Received: from dhcp89-081-145.bbn.com ([128.89.81.145]:2726 helo=mreynoldsxp) by smtp.bbn.com with smtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NuqsF-000GdO-V8 for sidr@ietf.org; Thu, 25 Mar 2010 13:29:39 -0400 Message-ID: From: "Mark Reynolds" To: Date: Thu, 25 Mar 2010 13:29:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0368_01CACC1F.37480640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [sidr] New I-D on Local Trust Anchor Management available X-BeenThere: sidr@ietf.org X-Mailman-Version: 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, 25 Mar 2010 17:35:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0368_01CACC1F.37480640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new I-D, "Local Trust Anchor Management for the Resource Public Key = Infrastructure" is available on ietf.org in the file draft-reynolds-rpki-ltamgmt-00.txt. - Mark Reynolds ------=_NextPart_000_0368_01CACC1F.37480640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A new I-D, "Local Trust Anchor Management for the Resource = Public Key=20 Infrastructure"
is available on ietf.org in the file=20 draft-reynolds-rpki-ltamgmt-00.txt.
 
- Mark Reynolds
 
------=_NextPart_000_0368_01CACC1F.37480640-- From randy@psg.com Sat Mar 27 09:58:14 2010 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E863A69CA for ; Sat, 27 Mar 2010 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.559 X-Spam-Level: X-Spam-Status: No, score=0.559 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGfFaoqEImwn for ; Sat, 27 Mar 2010 09:58:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 0FFE33A67FD for ; Sat, 27 Mar 2010 09:58:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvZLH-0002tA-0A; Sat, 27 Mar 2010 16:58:35 +0000 Date: Sat, 27 Mar 2010 09:58:34 -0700 Message-ID: From: Randy Bush To: Sandy Murphy , Chris Morrow User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: [sidr] draft-ymbk-rpki-rtr-protocol-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: Sat, 27 Mar 2010 16:58:15 -0000 we would like to sumbit draft-ymbk-rpki-rtr-protocol-05.txt as a sidr wg draft on standards track. it needs to be standards track as it is a normative reference from draft-pmohapat-sidr-pfx-validate-04.txt. randy