From rogaglia@cisco.com Thu Jan 3 03:36:53 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A50821F8AA3 for ; Thu, 3 Jan 2013 03:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wpHlNrpMrTF for ; Thu, 3 Jan 2013 03:36:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C187F21F8AB7 for ; Thu, 3 Jan 2013 03:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1173; q=dns/txt; s=iport; t=1357213013; x=1358422613; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nHGQnP37Fn8KBySWPZ4zdulcIS1yuqA3wYMxi+Gc+a4=; b=DEGKUrfdDKh8yEMqEnzngFn8BdKLB6Ak10gOGgc626fqp6xE7m6Bo/y1 4AlEZBVzyyyJZPiPEg5Z+6PpAljGCv1kZdPks08f2e3OwgpxGdlspNhVe UZJFF/CVQ5yeNKm6nNSSOPYFHktntxBBv3ENGoOBGA749CDc3u8cX0dcy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACFt5VCtJV2b/2dsb2JhbABFgX+7TxZzgh4BAQEDATpECwIBCCIUEDIlAgQbDod3BrVekDlhA6ZUgnSBaiQY X-IronPort-AV: E=Sophos;i="4.84,402,1355097600"; d="scan'208";a="158400148" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jan 2013 11:36:52 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r03BapVe014238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 3 Jan 2013 11:36:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.49]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 05:36:51 -0600 From: "Roque Gagliano (rogaglia)" To: sidr wg list Thread-Topic: [sidr] the need for speed Thread-Index: AQHN6aafMhyjxuRB10mn8NjzGVNKCQ== Date: Thu, 3 Jan 2013 11:36:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.79] Content-Type: text/plain; charset="us-ascii" Content-ID: <1CA35379BD2CD24991B281F29D797953@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 11:36:53 -0000 I want to echo Randy's comment on this paragraph.=20 > i am confident that the folk providing third-party mitigation services > are clever enough to figure out their own hacks around this problem, and > we do not need to second guess what might best work for them. Lets keep in mind that for origin validation (the work already published an= d in deployment phase) we are talking about a very small use-case that runs= at "human" speed (from detection to operational services there will be hum= an interventions). Some hacks mentioned on the list include: - Education: clear procedure at the provider's website/first customer cont= act that required new ROA creation with mitigation provider AS to accelerat= e propagation. - Announce the prefixes under attack maintaining the origin AS from the or= iginal server (hack the path) - Increase the number of direct peers. The provider may negotiate with its= peers filtering exemptions in their direct links. Particularly this is a d= ifferentiation aspect for mitigation providers as many of them show that th= ey have scrambling location nearby the main botnets hubs on the web.=20 Roque.= From kent@bbn.com Thu Jan 3 10:20:45 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B6E21F8CBE; Thu, 3 Jan 2013 10:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqyZmjw8J98o; Thu, 3 Jan 2013 10:20:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 03C9021F8CBB; Thu, 3 Jan 2013 10:20:41 -0800 (PST) Received: from dhcp89-089-242.bbn.com ([128.89.89.242]:52601) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TqpPD-000KWl-E3; Thu, 03 Jan 2013 13:20:39 -0500 Message-ID: <50E5CBF7.7040603@bbn.com> Date: Thu, 03 Jan 2013 13:20:39 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: ietf@ietf.org, sidr Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Last Call: (Algorithm Agility Procedure for RPKI.) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 18:20:45 -0000 The tech report cited in Eric's message is not a critique of the SIDR algorithm agility document that is the subject if this last call. The tech report is a critique of the overall SIDR repository system and object retrieval paradigm, with an emphasis on the speed with which relying parties (principally ISPs) will be able to acquire RPKI data. The RPKI repository system is defined in RFC 6481; the RP object retrieval approach is described in RFC 6480. The tech report includes assumptions about the addition of many instances of additional objects (router certs) to the RPKI repository system, but these assumptions are based on I-Ds that are in process in SIDR, and thus may be the more appropriate focus of the report, in terms of responses. The tech report includes no specific criticisms of the algorithm agility mechanism described by the I-D in IETF LC, nor does it suggest any changes to this doc. An extensive discussion of the tech report took place on the SIDR list, in early December. That discussion also did not suggest any proposed changes to the algorithm agility doc. Thus the authors do not plan to make any changes as a result of this comment being posted during IETF LC. Steve Kent (on behalf of Roque Gagliano and Sean Turner) From andy@arin.net Thu Jan 3 14:54:03 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979A421F8D26 for ; Thu, 3 Jan 2013 14:54:03 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQgBcPZQ2Ats for ; Thu, 3 Jan 2013 14:54:03 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 0C35C21F8DD5 for ; Thu, 3 Jan 2013 14:54:03 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 9EC99213644; Thu, 3 Jan 2013 17:54:02 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 2EE5E213623 for ; Thu, 3 Jan 2013 17:54:02 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.18) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 3 Jan 2013 17:53:33 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.55]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Thu, 3 Jan 2013 17:53:48 -0500 From: Andy Newton To: sidr wg Thread-Topic: New Version Notification for draft-newton-sidr-policy-qualifiers-01.txt Thread-Index: AQHN6gUxlPQzhpFH3kinT1OykCbfbw== Date: Thu, 3 Jan 2013 22:53:48 +0000 Message-ID: <62D9228640AC7F49B2DD9ED0C9CE60E578993977@CHAXCH01.corp.arin.net> In-Reply-To: <20130103225148.10691.29488.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] FW: New Version Notification for draft-newton-sidr-policy-qualifiers-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:54:03 -0000 This incorporates the feedback I received from the -00. -andy On 1/3/13 5:51 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-newton-sidr-policy-qualifiers-01.txt >has been successfully submitted by Andrew Lee Newton and posted to the >IETF repository. > >Filename: draft-newton-sidr-policy-qualifiers >Revision: 01 >Title: Policy Qualifiers in RPKI Certificates >Creation date: 2013-01-03 >WG ID: Individual Submission >Number of pages: 9 >URL: =20 >http://www.ietf.org/internet-drafts/draft-newton-sidr-policy-qualifiers-01 >.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-newton-sidr-policy-qualifiers >Htmlized: =20 >http://tools.ietf.org/html/draft-newton-sidr-policy-qualifiers-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-newton-sidr-policy-qualifiers-01 > >Abstract: > This document updates RFC 6487 by clarifying the inclusion of policy > qualifiers in the certificate policies extension of RPKI resource > certificates. > > =20 > =20 > > >The IETF Secretariat > > From internet-drafts@ietf.org Mon Jan 7 09:01:07 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B4A21F8930; Mon, 7 Jan 2013 09:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB7CPwIBZGJo; Mon, 7 Jan 2013 09:01:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B168721F84DB; Mon, 7 Jan 2013 09:00:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107170046.8252.42868.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 09:00:46 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:01:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-10.txt Pages : 31 Date : 2013-01-07 Abstract: This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-algorithm-agility-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rogaglia@cisco.com Mon Jan 7 09:02:20 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB821F88C7; Mon, 7 Jan 2013 09:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTsgpc6K2BHd; Mon, 7 Jan 2013 09:02:15 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1516A21F87CB; Mon, 7 Jan 2013 09:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9407; q=dns/txt; s=iport; t=1357578130; x=1358787730; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GXlFyDWWao8Fv1mH31NYx5bRK2kYbtN/C/DNyweZf2s=; b=ExqQM+Ai0bb1rwoaphcxs7gIgSuLOJbhMgZvatQAoVEzwSBqlY/TtxlM UlWg1kbuT8Dt3VGualf/BRJg+/Bg8BEPFmwx0auF1vRJpzd/xbTeTSRzM 96gXfFsJiOHzSxWqWYQuTnSG5hsMmEYnAErTrPgxFZCT7e1CXQahfQr1d A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABP+6lCtJV2Z/2dsb2JhbABFvVQWc4IeAQEBAwEnEzgHBQcEAgEIEQQBAQsUCQcyFAkIAgQOBQiICQa1UoxSg2JhA5JYk3yCdIFoIhw X-IronPort-AV: E=Sophos;i="4.84,424,1355097600"; d="scan'208";a="159663149" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jan 2013 17:02:09 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r07H29YA021607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jan 2013 17:02:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.194]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 11:02:08 -0600 From: "Roque Gagliano (rogaglia)" To: "Black, David" Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: AQHN7Pi5+smgNyB5VUaCZdHrAxAE8A== Date: Mon, 7 Jan 2013 17:02:07 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <50E1E8D0.5010204@bbn.com> <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.20.110] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gen-art@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:02:20 -0000 David, I just published version 10 of the document with all the agreed changes. Th= anks again for your review. Roque On Dec 31, 2012, at 8:57 PM, "Black, David" wrote: > Steve, >=20 > This all looks good; thanks for the quick response. >=20 >>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, B >>> and C) from prior sections. >=20 >> I have deleted all references to Alg Suite C throughout the doc, and >> revised the text accordingly. >=20 > Magnificent - that'll be a significant improvement. >=20 >>> Starting in Section 4.3.1, there are a number of uses of "will be" >>> (future tense) in the milestone and phase descriptions. All of >>> these uses of "will be" should be reviewed to determine whether >>> "MUST be" is appropriate, e.g., as appears to be the case for >>> this sentence in 4.3.1: >>>=20 >>> Additionally, the new algorithm transition timeline document will be >>> published with the following information: >=20 >> I agree that "will be" needs to be changed to "MUST be" in a few places, >> starting on page 5 (Section 2) where the need to update the CP and to pu= blish an >> alg transition timetable are first mentioned. An examination of the rest= of the >> doc shows that this change need be applied only when the alg transition = doc is >> mentioned. >=20 > That sounds reasonable. >=20 >>> Section 3 Definitions: Is there any concern about possible >>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>> The draft is clear on what Suite B means for RPKI, but I suspect >>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>=20 >> We defined what "Suite B" is in the terminology section, so I >> think no further clarification is required here. >=20 > That's ok with me, but I thought it was worth asking. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Monday, December 31, 2012 2:35 PM >> To: Black, David >> Cc: rogaglia@cisco.com; Sean Turner; gen-art@ietf.org; sidr@ietf.org; St= ewart >> Bryant >> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>=20 >> David, >>=20 >>> The draft is generally well-written and clear, but has an unfortunate >>> nomenclature change problem that is the primary open issue[*]. >>>=20 >>> Major issues: >>>=20 >>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, B >>> and C) from prior sections. >>=20 >> I have deleted all references to Alg Suite C throughout the doc, and >> revised the text accordingly. >>=20 >>> This also affects Sections 6 and 7. >>> I have classified this as a major issue as I believe it introduces >>> severe lack of clarity (and potential ambiguity) into the following >>> two paragraphs in Section 7: >>>=20 >>> During Phase 1, a CA that revokes a certificate under Suite A SHOULD >>> revoke the corresponding certificate under Suite B, if that >>> certificate exists. During Phase 4, a CA that revokes a certificate >>> under Suite A SHOULD revoke the corresponding certificate under Suit= e >>> C, if that certificate exists. >>>=20 >>> During Phase 1, a CA may revoke certificates under Suite B without >>> revoking them under Suite A, since the Suite B products are for test >>> purposes. During Phase 4 a CA may revoke certificates issued under >>> Suite C without revoking them under Suite A, since Suite C products >>> are being deprecated. >> fixed. >>> Despite the use of three letters (A, B and C), there are only two >>> algorithm suites involved, and different instances of Suite A refer to >>> different algorithm suites. In each paragraph, the first instance of >>> "Suite A" refers to the same algorithm suite as "Suite C", and the >>> second instance of "Suite A" refers to the same algorithm suite >>> as "Suite B". >>>=20 >>> It would be much better and clearer to not change the meaning of the >>> algorithm suite names until the EOL date. In addition, this change >>> should enable removal of the Suite C concept from this draft. >> fixed >>> I >>> strongly recommend removing the Suite C concept, as the C-A-B >>> chronological order of suite introduction dates seems counter-intuitive= . >> Done. >>>=20 >>> Minor issues: >>>=20 >>> Starting in Section 4.3.1, there are a number of uses of "will be" >>> (future tense) in the milestone and phase descriptions. All of >>> these uses of "will be" should be reviewed to determine whether >>> "MUST be" is appropriate, e.g., as appears to be the case for >>> this sentence in 4.3.1: >>>=20 >>> Additionally, the new algorithm transition timeline document will be >>> published with the following information: >> I agree that "will be" needs to be changed to "MUST be" in a few places, >> starting on page 5 (Section 2) where the need to update the CP and to >> publish an >> alg transition timetable are first mentioned. An examination of the rest >> of the >> doc shows that this change need be applied only when the alg transition >> doc is >> mentioned. >>> When "MUST be" is not appropriate, present tense (i.e., "is") is >>> preferable. >> fixed. >>>=20 >>> Nits/editorial: >>>=20 >>> Abstract: The following two sentences don't quite line up: >>>=20 >>> The process >>> is expected to be completed in a time scale of months or years. >>> Consequently, no emergency transition is specified. >>>=20 >>> Also, section 4.2 indicates that a multi-year transition timeframe >>> is expected, which suggests that "months" is not appropriate in >>> the abstract. Suggested rephrasing: >>>=20 >>> The time available to complete the transition process >>> is expected to be several years. >>> Consequently, no emergency transition process is specified. >> fixed. >>> Section 2. Introduction: The first sentence in the last paragraph >>> mentions a forthcoming BCP on transition timetable. The rest of >>> that paragraph implies that the BCP is for a single transition, as >>> opposed to being a BCP for transitions in general. It would be >>> helpful to clarify that at the start of the paragraph, e.g., >>> by adding "For each algorithm transition," to the start of the >>> paragraph. >> fixed. >>> Section 3 Definitions: Is there any concern about possible >>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>> The draft is clear on what Suite B means for RPKI, but I suspect >>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >> We defined what "Suite B" is in the terminology section, so I >> think no further clarification is required here. >>> Describing Phase 0 as both the steady state of the RPKI and the first >>> phase of transition is confusing (e.g., in 4.3). It would be clearer >>> if Phase 0 began with publication of the updated RPKI algorithm >>> document (Milestone 1) and that the activities that are unchanged >>> from steady state were described as not changing in phase 0. >> we need to be able to refer to steady state, separate from the >> first milestone in the transition process, but I agree that referring to >> it as the first phase of the transition process is confusing. I have >> changed the text accordingly. >>> Starting near the end of section 4.3, the three characters >>> |-> are used in figures to represent an RPKI hierarchy relationship; >>> that relationship should be defined and/or explained before it is used. >>> For clarity, I'd suggest swapping the order of the two paragraphs >>> above that figure in 4.3 and making the following change at the end >>> of the paragraph that is moved down (addition of the word >>> "certificate" is the important change): >>>=20 >>> OLD >>> and shows the relationship between three CAs (X, Y, and Z) that form >>> a chain. >>> NEW >>> and shows the relationships among the three CAs (X, Y, and Z) >>> that participate in a certificate chain. >>>=20 >>> Subsequent uses of |-> seemed clear to me. >> I'll defer to Roque here, as the repository representation is his design= . >>> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at >>> independent publication points, but does not make it clear that this >>> recommendation applies beyond phase 2. I suggest adding text to >>> make that clear - a reference to Section 9 (which is clear about >>> this) may be useful as part of that text. >> I have added a forward pointer to Section 9 here. >>> In Section 6, please expand the ROA acronym on first use and consider >>> whether it should be defined in Section 3. I'm also assuming that the >>> ASN acronym is intended to refer to ASN.1 content; if not, that >>> acronym also needs attention. >> ASN =3D Autonomous System Number. I expended the acronym as it appears >> only here. I added a ROA definition to Section 3. >>> idnits 2.12.13 found a couple of minor nits: >>>=20 >>> ** There is 1 instance of too long lines in the document, the longest= one >>> being 23 characters in excess of 72. >> I'll let Roque address this issue. >>>=20 >>> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 key= word, >> but >>> does not include the phrase in its RFC 2119 key words list. >> fixed. >>=20 >=20 From rogaglia@cisco.com Mon Jan 7 09:05:26 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1FC21F88CA for ; Mon, 7 Jan 2013 09:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.099 X-Spam-Level: X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1f8oM5xD4P3 for ; Mon, 7 Jan 2013 09:05:26 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55A21F88C7 for ; Mon, 7 Jan 2013 09:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1871; q=dns/txt; s=iport; t=1357578326; x=1358787926; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pMpAtQ6lC98ZSXAw7I8UB55rqg8dEw05prjpjZpyiqw=; b=FUKz5s/twsXcSv4ksY/8hqAJk5VklFUGrNZGm+YPcNXnhYbu3HXH+5Le P1WdvdooRpZv6Xe1fgtv7kQM3XA7U49qZwAAc4GhgMLNYixL4KOyNGDiV 8Wdbdm+K/CrFjkAO15wH5l6eQ29k7oaunEYgJLG6UvIVONt0wIztjq+IX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOj+6lCtJXG//2dsb2JhbABFg2y5aBZzgh4BAQEDAQEBATc0GwIBCCIUECcLJQIEEwgBiAgGBwW1R5A0YQOXJ48tgnSCJg X-IronPort-AV: E=Sophos;i="4.84,424,1355097600"; d="scan'208";a="159683350" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jan 2013 17:05:25 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r07H5Psl005245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Jan 2013 17:05:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.194]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 11:05:25 -0600 From: "Roque Gagliano (rogaglia)" To: "sidr@ietf.org" Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-10.txt Thread-Index: AQHN7PkuNeNeZ4qItUq0Fa1uC09DXw== Date: Mon, 7 Jan 2013 17:05:24 +0000 Message-ID: References: <20130107170046.8252.42868.idtracker@ietfa.amsl.com> In-Reply-To: <20130107170046.8252.42868.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.20.110] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DDBD52426EE8644B759F8CE760F7CBE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:05:26 -0000 Dear WG, This version basically addresses the comments from the Gen-Area Directorate= . Roque On Jan 7, 2013, at 6:00 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Secure Inter-Domain Routing Working Grou= p of the IETF. >=20 > Title : Algorithm Agility Procedure for RPKI. > Author(s) : Roque Gagliano > Stephen Kent > Sean Turner > Filename : draft-ietf-sidr-algorithm-agility-10.txt > Pages : 31 > Date : 2013-01-07 >=20 > Abstract: > This document specifies the process that Certification Authorities > (CAs) and Relying Parties (RPs) participating in the Resource Public > Key Infrastructure (RPKI) will need to follow to transition to a new > (and probably cryptographically stronger) algorithm set. The process > is expected to be completed in a time scale of several years. > Consequently, no emergency transition is specified. The transition > procedure defined in this document supports only a top-down migration > (parent migrates before children). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-10 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-algorithm-agility-10 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From david.black@emc.com Mon Jan 7 09:17:09 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048D921F85B3; Mon, 7 Jan 2013 09:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2unHjYd5rj8; Mon, 7 Jan 2013 09:17:07 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11521F854D; Mon, 7 Jan 2013 09:17:07 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r07HGsUA006090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2013 12:16:55 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 7 Jan 2013 12:16:41 -0500 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r07HGeTI013965; Mon, 7 Jan 2013 12:16:40 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub33.corp.emc.com ([::1]) with mapi; Mon, 7 Jan 2013 12:16:39 -0500 From: "Black, David" To: "Roque Gagliano (rogaglia)" Date: Mon, 7 Jan 2013 12:16:38 -0500 Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: AQHN7Pi5+smgNyB5VUaCZdHrAxAE8Jg+GzWQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287DB29CE@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <50E1E8D0.5010204@bbn.com> <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "gen-art@ietf.org" , "sidr@ietf.org" , "Black, David" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:17:09 -0000 Roque, That new version looks good. Could you also take a look at this editorial suggestion that Steve deferred to you?: Starting near the end of section 4.3, the three characters |-> are used in figures to represent an RPKI hierarchy relationship; that relationship should be defined and/or explained before it is used. For clarity, I'd suggest swapping the order of the two paragraphs above that figure in 4.3 and making the following change at the end of the paragraph that is moved down (addition of the word "certificate" is the important change): OLD and shows the relationship between three CAs (X, Y, and Z) that form a chain. NEW and shows the relationships among the three CAs (X, Y, and Z) that participate in a certificate chain. Subsequent uses of |-> seemed clear to me. Thanks, --David > -----Original Message----- > From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] > Sent: Monday, January 07, 2013 12:02 PM > To: Black, David > Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; gen-art@ietf.or= g; > sidr@ietf.org; Stewart Bryant (stbryant) > Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >=20 > David, >=20 > I just published version 10 of the document with all the agreed changes. > Thanks again for your review. >=20 > Roque >=20 >=20 > On Dec 31, 2012, at 8:57 PM, "Black, David" wrote: >=20 > > Steve, > > > > This all looks good; thanks for the quick response. > > > >>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, = B > >>> and C) from prior sections. > > > >> I have deleted all references to Alg Suite C throughout the doc, and > >> revised the text accordingly. > > > > Magnificent - that'll be a significant improvement. > > > >>> Starting in Section 4.3.1, there are a number of uses of "will be" > >>> (future tense) in the milestone and phase descriptions. All of > >>> these uses of "will be" should be reviewed to determine whether > >>> "MUST be" is appropriate, e.g., as appears to be the case for > >>> this sentence in 4.3.1: > >>> > >>> Additionally, the new algorithm transition timeline document will = be > >>> published with the following information: > > > >> I agree that "will be" needs to be changed to "MUST be" in a few place= s, > >> starting on page 5 (Section 2) where the need to update the CP and to > publish an > >> alg transition timetable are first mentioned. An examination of the re= st of > the > >> doc shows that this change need be applied only when the alg transitio= n doc > is > >> mentioned. > > > > That sounds reasonable. > > > >>> Section 3 Definitions: Is there any concern about possible > >>> confusion of the use of "Suite B" in this draft with NSA Suite B? > >>> The draft is clear on what Suite B means for RPKI, but I suspect > >>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. > >> > >> We defined what "Suite B" is in the terminology section, so I > >> think no further clarification is required here. > > > > That's ok with me, but I thought it was worth asking. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Stephen Kent [mailto:kent@bbn.com] > >> Sent: Monday, December 31, 2012 2:35 PM > >> To: Black, David > >> Cc: rogaglia@cisco.com; Sean Turner; gen-art@ietf.org; sidr@ietf.org; > Stewart > >> Bryant > >> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 > >> > >> David, > >> > >>> The draft is generally well-written and clear, but has an unfortunate > >>> nomenclature change problem that is the primary open issue[*]. > >>> > >>> Major issues: > >>> > >>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, = B > >>> and C) from prior sections. > >> > >> I have deleted all references to Alg Suite C throughout the doc, and > >> revised the text accordingly. > >> > >>> This also affects Sections 6 and 7. > >>> I have classified this as a major issue as I believe it introduces > >>> severe lack of clarity (and potential ambiguity) into the following > >>> two paragraphs in Section 7: > >>> > >>> During Phase 1, a CA that revokes a certificate under Suite A SHOU= LD > >>> revoke the corresponding certificate under Suite B, if that > >>> certificate exists. During Phase 4, a CA that revokes a certifica= te > >>> under Suite A SHOULD revoke the corresponding certificate under Su= ite > >>> C, if that certificate exists. > >>> > >>> During Phase 1, a CA may revoke certificates under Suite B without > >>> revoking them under Suite A, since the Suite B products are for te= st > >>> purposes. During Phase 4 a CA may revoke certificates issued unde= r > >>> Suite C without revoking them under Suite A, since Suite C product= s > >>> are being deprecated. > >> fixed. > >>> Despite the use of three letters (A, B and C), there are only two > >>> algorithm suites involved, and different instances of Suite A refer t= o > >>> different algorithm suites. In each paragraph, the first instance of > >>> "Suite A" refers to the same algorithm suite as "Suite C", and the > >>> second instance of "Suite A" refers to the same algorithm suite > >>> as "Suite B". > >>> > >>> It would be much better and clearer to not change the meaning of the > >>> algorithm suite names until the EOL date. In addition, this change > >>> should enable removal of the Suite C concept from this draft. > >> fixed > >>> I > >>> strongly recommend removing the Suite C concept, as the C-A-B > >>> chronological order of suite introduction dates seems counter-intuiti= ve. > >> Done. > >>> > >>> Minor issues: > >>> > >>> Starting in Section 4.3.1, there are a number of uses of "will be" > >>> (future tense) in the milestone and phase descriptions. All of > >>> these uses of "will be" should be reviewed to determine whether > >>> "MUST be" is appropriate, e.g., as appears to be the case for > >>> this sentence in 4.3.1: > >>> > >>> Additionally, the new algorithm transition timeline document will = be > >>> published with the following information: > >> I agree that "will be" needs to be changed to "MUST be" in a few place= s, > >> starting on page 5 (Section 2) where the need to update the CP and to > >> publish an > >> alg transition timetable are first mentioned. An examination of the re= st > >> of the > >> doc shows that this change need be applied only when the alg transitio= n > >> doc is > >> mentioned. > >>> When "MUST be" is not appropriate, present tense (i.e., "is") is > >>> preferable. > >> fixed. > >>> > >>> Nits/editorial: > >>> > >>> Abstract: The following two sentences don't quite line up: > >>> > >>> The process > >>> is expected to be completed in a time scale of months or years. > >>> Consequently, no emergency transition is specified. > >>> > >>> Also, section 4.2 indicates that a multi-year transition timeframe > >>> is expected, which suggests that "months" is not appropriate in > >>> the abstract. Suggested rephrasing: > >>> > >>> The time available to complete the transition process > >>> is expected to be several years. > >>> Consequently, no emergency transition process is specified. > >> fixed. > >>> Section 2. Introduction: The first sentence in the last paragraph > >>> mentions a forthcoming BCP on transition timetable. The rest of > >>> that paragraph implies that the BCP is for a single transition, as > >>> opposed to being a BCP for transitions in general. It would be > >>> helpful to clarify that at the start of the paragraph, e.g., > >>> by adding "For each algorithm transition," to the start of the > >>> paragraph. > >> fixed. > >>> Section 3 Definitions: Is there any concern about possible > >>> confusion of the use of "Suite B" in this draft with NSA Suite B? > >>> The draft is clear on what Suite B means for RPKI, but I suspect > >>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. > >> We defined what "Suite B" is in the terminology section, so I > >> think no further clarification is required here. > >>> Describing Phase 0 as both the steady state of the RPKI and the first > >>> phase of transition is confusing (e.g., in 4.3). It would be clearer > >>> if Phase 0 began with publication of the updated RPKI algorithm > >>> document (Milestone 1) and that the activities that are unchanged > >>> from steady state were described as not changing in phase 0. > >> we need to be able to refer to steady state, separate from the > >> first milestone in the transition process, but I agree that referring = to > >> it as the first phase of the transition process is confusing. I have > >> changed the text accordingly. > >>> Starting near the end of section 4.3, the three characters > >>> |-> are used in figures to represent an RPKI hierarchy relationship; > >>> that relationship should be defined and/or explained before it is use= d. > >>> For clarity, I'd suggest swapping the order of the two paragraphs > >>> above that figure in 4.3 and making the following change at the end > >>> of the paragraph that is moved down (addition of the word > >>> "certificate" is the important change): > >>> > >>> OLD > >>> and shows the relationship between three CAs (X, Y, and Z) that fo= rm > >>> a chain. > >>> NEW > >>> and shows the relationships among the three CAs (X, Y, and Z) > >>> that participate in a certificate chain. > >>> > >>> Subsequent uses of |-> seemed clear to me. > >> I'll defer to Roque here, as the repository representation is his desi= gn. > >>> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at > >>> independent publication points, but does not make it clear that this > >>> recommendation applies beyond phase 2. I suggest adding text to > >>> make that clear - a reference to Section 9 (which is clear about > >>> this) may be useful as part of that text. > >> I have added a forward pointer to Section 9 here. > >>> In Section 6, please expand the ROA acronym on first use and consider > >>> whether it should be defined in Section 3. I'm also assuming that th= e > >>> ASN acronym is intended to refer to ASN.1 content; if not, that > >>> acronym also needs attention. > >> ASN =3D Autonomous System Number. I expended the acronym as it appears > >> only here. I added a ROA definition to Section 3. > >>> idnits 2.12.13 found a couple of minor nits: > >>> > >>> ** There is 1 instance of too long lines in the document, the longe= st > one > >>> being 23 characters in excess of 72. > >> I'll let Roque address this issue. > >>> > >>> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 k= eyword, > >> but > >>> does not include the phrase in its RFC 2119 key words list. > >> fixed. > >> > > >=20 From rogaglia@cisco.com Mon Jan 7 09:52:27 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9949021F88D1; Mon, 7 Jan 2013 09:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.932 X-Spam-Level: X-Spam-Status: No, score=-11.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c66nAcsjYxo; Mon, 7 Jan 2013 09:52:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 25E9121F88CB; Mon, 7 Jan 2013 09:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11636; q=dns/txt; s=iport; t=1357581146; x=1358790746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uakiFMjmEOusOPdhDyiLEi04cWfmr0TWY/PnxrIhpwM=; b=mfF+xPkhLEP8yZQD+iesFl6BpeR7KQOHVDopMeqvd+v01t/D4W85FD5M uod1+eP43iklT9B/HD+0S0Y6eFmvvocQEtX1LCXWaFswllIcqD1nIBJgW qYLW8lR+3rObaLNY0mHKhXa/3cGDGPC0cRU0FTBMNMZZvaoeQboQT8DCY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAEL61CtJXG+/2dsb2JhbABFvVQWc4IeAQEBAwEnEzgHBQcEAgEIEQQBAQEKFAkHMhQJCAIEDgUIiAkGtV+MUoNiYQOSWJN8gnSBaCIc X-IronPort-AV: E=Sophos;i="4.84,425,1355097600"; d="scan'208";a="159735026" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jan 2013 17:52:01 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r07Hq1mR016404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jan 2013 17:52:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.194]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 11:52:01 -0600 From: "Roque Gagliano (rogaglia)" To: "Black, David" Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: AQHN7Pi5+smgNyB5VUaCZdHrAxAE8A== Date: Mon, 7 Jan 2013 17:52:00 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <50E1E8D0.5010204@bbn.com> <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287DB29CE@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287DB29CE@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.20.110] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gen-art@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 17:52:27 -0000 Hi David, On Jan 7, 2013, at 6:16 PM, "Black, David" wrote: > Roque, >=20 > That new version looks good. Could you also take a look at this editoria= l > suggestion that Steve deferred to you?: >=20 Ok, sorry about that. > Starting near the end of section 4.3, the three characters > |-> are used in figures to represent an RPKI hierarchy relationship; > that relationship should be defined and/or explained before it is used. The idea in the different figures is that the vertical alignment differenti= ates the different publication points. What about adding the following text?=20 "The vertical alignment in the figure distinguishes between the different p= ublication points and the characters '|->' are used for visualization purpo= se." > For clarity, I'd suggest swapping the order of the two paragraphs > above that figure in 4.3 and making the following change at the end > of the paragraph that is moved down (addition of the word > "certificate" is the important change): All done and thanks. Roque > OLD > and shows the relationship between three CAs (X, Y, and Z) that form > a chain. > NEW > and shows the relationships among the three CAs (X, Y, and Z) > that participate in a certificate chain. >=20 > Subsequent uses of |-> seemed clear to me. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] >> Sent: Monday, January 07, 2013 12:02 PM >> To: Black, David >> Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; gen-art@ietf.o= rg; >> sidr@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>=20 >> David, >>=20 >> I just published version 10 of the document with all the agreed changes. >> Thanks again for your review. >>=20 >> Roque >>=20 >>=20 >> On Dec 31, 2012, at 8:57 PM, "Black, David" wrote: >>=20 >>> Steve, >>>=20 >>> This all looks good; thanks for the quick response. >>>=20 >>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, = B >>>>> and C) from prior sections. >>>=20 >>>> I have deleted all references to Alg Suite C throughout the doc, and >>>> revised the text accordingly. >>>=20 >>> Magnificent - that'll be a significant improvement. >>>=20 >>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>> (future tense) in the milestone and phase descriptions. All of >>>>> these uses of "will be" should be reviewed to determine whether >>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>> this sentence in 4.3.1: >>>>>=20 >>>>> Additionally, the new algorithm transition timeline document will b= e >>>>> published with the following information: >>>=20 >>>> I agree that "will be" needs to be changed to "MUST be" in a few place= s, >>>> starting on page 5 (Section 2) where the need to update the CP and to >> publish an >>>> alg transition timetable are first mentioned. An examination of the re= st of >> the >>>> doc shows that this change need be applied only when the alg transitio= n doc >> is >>>> mentioned. >>>=20 >>> That sounds reasonable. >>>=20 >>>>> Section 3 Definitions: Is there any concern about possible >>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>>=20 >>>> We defined what "Suite B" is in the terminology section, so I >>>> think no further clarification is required here. >>>=20 >>> That's ok with me, but I thought it was worth asking. >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Stephen Kent [mailto:kent@bbn.com] >>>> Sent: Monday, December 31, 2012 2:35 PM >>>> To: Black, David >>>> Cc: rogaglia@cisco.com; Sean Turner; gen-art@ietf.org; sidr@ietf.org; >> Stewart >>>> Bryant >>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>>=20 >>>> David, >>>>=20 >>>>> The draft is generally well-written and clear, but has an unfortunate >>>>> nomenclature change problem that is the primary open issue[*]. >>>>>=20 >>>>> Major issues: >>>>>=20 >>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A, = B >>>>> and C) from prior sections. >>>>=20 >>>> I have deleted all references to Alg Suite C throughout the doc, and >>>> revised the text accordingly. >>>>=20 >>>>> This also affects Sections 6 and 7. >>>>> I have classified this as a major issue as I believe it introduces >>>>> severe lack of clarity (and potential ambiguity) into the following >>>>> two paragraphs in Section 7: >>>>>=20 >>>>> During Phase 1, a CA that revokes a certificate under Suite A SHOUL= D >>>>> revoke the corresponding certificate under Suite B, if that >>>>> certificate exists. During Phase 4, a CA that revokes a certificat= e >>>>> under Suite A SHOULD revoke the corresponding certificate under Sui= te >>>>> C, if that certificate exists. >>>>>=20 >>>>> During Phase 1, a CA may revoke certificates under Suite B without >>>>> revoking them under Suite A, since the Suite B products are for tes= t >>>>> purposes. During Phase 4 a CA may revoke certificates issued under >>>>> Suite C without revoking them under Suite A, since Suite C products >>>>> are being deprecated. >>>> fixed. >>>>> Despite the use of three letters (A, B and C), there are only two >>>>> algorithm suites involved, and different instances of Suite A refer t= o >>>>> different algorithm suites. In each paragraph, the first instance of >>>>> "Suite A" refers to the same algorithm suite as "Suite C", and the >>>>> second instance of "Suite A" refers to the same algorithm suite >>>>> as "Suite B". >>>>>=20 >>>>> It would be much better and clearer to not change the meaning of the >>>>> algorithm suite names until the EOL date. In addition, this change >>>>> should enable removal of the Suite C concept from this draft. >>>> fixed >>>>> I >>>>> strongly recommend removing the Suite C concept, as the C-A-B >>>>> chronological order of suite introduction dates seems counter-intuiti= ve. >>>> Done. >>>>>=20 >>>>> Minor issues: >>>>>=20 >>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>> (future tense) in the milestone and phase descriptions. All of >>>>> these uses of "will be" should be reviewed to determine whether >>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>> this sentence in 4.3.1: >>>>>=20 >>>>> Additionally, the new algorithm transition timeline document will b= e >>>>> published with the following information: >>>> I agree that "will be" needs to be changed to "MUST be" in a few place= s, >>>> starting on page 5 (Section 2) where the need to update the CP and to >>>> publish an >>>> alg transition timetable are first mentioned. An examination of the re= st >>>> of the >>>> doc shows that this change need be applied only when the alg transitio= n >>>> doc is >>>> mentioned. >>>>> When "MUST be" is not appropriate, present tense (i.e., "is") is >>>>> preferable. >>>> fixed. >>>>>=20 >>>>> Nits/editorial: >>>>>=20 >>>>> Abstract: The following two sentences don't quite line up: >>>>>=20 >>>>> The process >>>>> is expected to be completed in a time scale of months or years. >>>>> Consequently, no emergency transition is specified. >>>>>=20 >>>>> Also, section 4.2 indicates that a multi-year transition timeframe >>>>> is expected, which suggests that "months" is not appropriate in >>>>> the abstract. Suggested rephrasing: >>>>>=20 >>>>> The time available to complete the transition process >>>>> is expected to be several years. >>>>> Consequently, no emergency transition process is specified. >>>> fixed. >>>>> Section 2. Introduction: The first sentence in the last paragraph >>>>> mentions a forthcoming BCP on transition timetable. The rest of >>>>> that paragraph implies that the BCP is for a single transition, as >>>>> opposed to being a BCP for transitions in general. It would be >>>>> helpful to clarify that at the start of the paragraph, e.g., >>>>> by adding "For each algorithm transition," to the start of the >>>>> paragraph. >>>> fixed. >>>>> Section 3 Definitions: Is there any concern about possible >>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>> We defined what "Suite B" is in the terminology section, so I >>>> think no further clarification is required here. >>>>> Describing Phase 0 as both the steady state of the RPKI and the first >>>>> phase of transition is confusing (e.g., in 4.3). It would be clearer >>>>> if Phase 0 began with publication of the updated RPKI algorithm >>>>> document (Milestone 1) and that the activities that are unchanged >>>>> from steady state were described as not changing in phase 0. >>>> we need to be able to refer to steady state, separate from the >>>> first milestone in the transition process, but I agree that referring = to >>>> it as the first phase of the transition process is confusing. I have >>>> changed the text accordingly. >>>>> Starting near the end of section 4.3, the three characters >>>>> |-> are used in figures to represent an RPKI hierarchy relationship; >>>>> that relationship should be defined and/or explained before it is use= d. >>>>> For clarity, I'd suggest swapping the order of the two paragraphs >>>>> above that figure in 4.3 and making the following change at the end >>>>> of the paragraph that is moved down (addition of the word >>>>> "certificate" is the important change): >>>>>=20 >>>>> OLD >>>>> and shows the relationship between three CAs (X, Y, and Z) that for= m >>>>> a chain. >>>>> NEW >>>>> and shows the relationships among the three CAs (X, Y, and Z) >>>>> that participate in a certificate chain. >>>>>=20 >>>>> Subsequent uses of |-> seemed clear to me. >>>> I'll defer to Roque here, as the repository representation is his desi= gn. >>>>> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at >>>>> independent publication points, but does not make it clear that this >>>>> recommendation applies beyond phase 2. I suggest adding text to >>>>> make that clear - a reference to Section 9 (which is clear about >>>>> this) may be useful as part of that text. >>>> I have added a forward pointer to Section 9 here. >>>>> In Section 6, please expand the ROA acronym on first use and consider >>>>> whether it should be defined in Section 3. I'm also assuming that th= e >>>>> ASN acronym is intended to refer to ASN.1 content; if not, that >>>>> acronym also needs attention. >>>> ASN =3D Autonomous System Number. I expended the acronym as it appears >>>> only here. I added a ROA definition to Section 3. >>>>> idnits 2.12.13 found a couple of minor nits: >>>>>=20 >>>>> ** There is 1 instance of too long lines in the document, the longes= t >> one >>>>> being 23 characters in excess of 72. >>>> I'll let Roque address this issue. >>>>>=20 >>>>> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 ke= yword, >>>> but >>>>> does not include the phrase in its RFC 2119 key words list. >>>> fixed. >>>>=20 >>>=20 >>=20 >=20 From david.black@emc.com Mon Jan 7 10:54:21 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AD221F8994; Mon, 7 Jan 2013 10:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI-uNCa0LaSU; Mon, 7 Jan 2013 10:54:20 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4C04921F89FC; Mon, 7 Jan 2013 10:54:19 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r07IsBrn031074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2013 13:54:12 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 7 Jan 2013 13:54:01 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r07IrxZn028984; Mon, 7 Jan 2013 13:53:59 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Mon, 7 Jan 2013 13:53:59 -0500 From: "Black, David" To: "Roque Gagliano (rogaglia)" Date: Mon, 7 Jan 2013 13:53:56 -0500 Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: AQHN7Pi5+smgNyB5VUaCZdHrAxAE8Jg+K20w Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287DB2A22@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <50E1E8D0.5010204@bbn.com> <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287DB29CE@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "gen-art@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 18:54:21 -0000 Hi Roque, > "The vertical alignment in the figure distinguishes between the different > publication points and the characters '|->' are used for visualization > purpose." I think there's more going on than just publication point change. Here's the entire figure, plus the one existing sentence about the '|->' notation: CA X-Certificate-Algorithm-Suite-A (Cert-XA) | |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) |-> CA-Z-Signed-Objects-Algorithm-Suite-A |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) |-> CA-Y-Signed-Objects-Algorithm-Suite-A |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) |-> CA-X-Signed-Objects-Algorithm-Suite-A Note: Cert-XA represent the certificate for CA X, that is signed using the algorithm suite A. I believe that the private key corresponding to Cert-XA is used to sign Cert-YA, e.g., so that Cert-XA is involved in the path validation of Cert-YA. It looks like that's part of the relationship represented by '|->' and (if so) I would like to see a statement to that effect in addition to your proposed text about different publication points. Thanks, --David > -----Original Message----- > From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] > Sent: Monday, January 07, 2013 12:52 PM > To: Black, David > Cc: Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; gen-art@ietf.or= g; > sidr@ietf.org; Stewart Bryant (stbryant) > Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >=20 > Hi David, >=20 > On Jan 7, 2013, at 6:16 PM, "Black, David" wrote: >=20 > > Roque, > > > > That new version looks good. Could you also take a look at this editor= ial > > suggestion that Steve deferred to you?: > > >=20 > Ok, sorry about that. >=20 > > Starting near the end of section 4.3, the three characters > > |-> are used in figures to represent an RPKI hierarchy relationship; > > that relationship should be defined and/or explained before it is used. >=20 > The idea in the different figures is that the vertical alignment > differentiates the different publication points. >=20 > What about adding the following text? >=20 > "The vertical alignment in the figure distinguishes between the different > publication points and the characters '|->' are used for visualization > purpose." >=20 >=20 > > For clarity, I'd suggest swapping the order of the two paragraphs > > above that figure in 4.3 and making the following change at the end > > of the paragraph that is moved down (addition of the word > > "certificate" is the important change): >=20 > All done and thanks. >=20 > Roque >=20 > > OLD > > and shows the relationship between three CAs (X, Y, and Z) that form > > a chain. > > NEW > > and shows the relationships among the three CAs (X, Y, and Z) > > that participate in a certificate chain. > > > > Subsequent uses of |-> seemed clear to me. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] > >> Sent: Monday, January 07, 2013 12:02 PM > >> To: Black, David > >> Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; gen-art@ietf= .org; > >> sidr@ietf.org; Stewart Bryant (stbryant) > >> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 > >> > >> David, > >> > >> I just published version 10 of the document with all the agreed change= s. > >> Thanks again for your review. > >> > >> Roque > >> > >> > >> On Dec 31, 2012, at 8:57 PM, "Black, David" wrot= e: > >> > >>> Steve, > >>> > >>> This all looks good; thanks for the quick response. > >>> > >>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A= , B > >>>>> and C) from prior sections. > >>> > >>>> I have deleted all references to Alg Suite C throughout the doc, and > >>>> revised the text accordingly. > >>> > >>> Magnificent - that'll be a significant improvement. > >>> > >>>>> Starting in Section 4.3.1, there are a number of uses of "will be" > >>>>> (future tense) in the milestone and phase descriptions. All of > >>>>> these uses of "will be" should be reviewed to determine whether > >>>>> "MUST be" is appropriate, e.g., as appears to be the case for > >>>>> this sentence in 4.3.1: > >>>>> > >>>>> Additionally, the new algorithm transition timeline document will= be > >>>>> published with the following information: > >>> > >>>> I agree that "will be" needs to be changed to "MUST be" in a few pla= ces, > >>>> starting on page 5 (Section 2) where the need to update the CP and t= o > >> publish an > >>>> alg transition timetable are first mentioned. An examination of the = rest > of > >> the > >>>> doc shows that this change need be applied only when the alg transit= ion > doc > >> is > >>>> mentioned. > >>> > >>> That sounds reasonable. > >>> > >>>>> Section 3 Definitions: Is there any concern about possible > >>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? > >>>>> The draft is clear on what Suite B means for RPKI, but I suspect > >>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. > >>>> > >>>> We defined what "Suite B" is in the terminology section, so I > >>>> think no further clarification is required here. > >>> > >>> That's ok with me, but I thought it was worth asking. > >>> > >>> Thanks, > >>> --David > >>> > >>>> -----Original Message----- > >>>> From: Stephen Kent [mailto:kent@bbn.com] > >>>> Sent: Monday, December 31, 2012 2:35 PM > >>>> To: Black, David > >>>> Cc: rogaglia@cisco.com; Sean Turner; gen-art@ietf.org; sidr@ietf.org= ; > >> Stewart > >>>> Bryant > >>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 > >>>> > >>>> David, > >>>> > >>>>> The draft is generally well-written and clear, but has an unfortuna= te > >>>>> nomenclature change problem that is the primary open issue[*]. > >>>>> > >>>>> Major issues: > >>>>> > >>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A= , B > >>>>> and C) from prior sections. > >>>> > >>>> I have deleted all references to Alg Suite C throughout the doc, and > >>>> revised the text accordingly. > >>>> > >>>>> This also affects Sections 6 and 7. > >>>>> I have classified this as a major issue as I believe it introduces > >>>>> severe lack of clarity (and potential ambiguity) into the following > >>>>> two paragraphs in Section 7: > >>>>> > >>>>> During Phase 1, a CA that revokes a certificate under Suite A SHO= ULD > >>>>> revoke the corresponding certificate under Suite B, if that > >>>>> certificate exists. During Phase 4, a CA that revokes a certific= ate > >>>>> under Suite A SHOULD revoke the corresponding certificate under S= uite > >>>>> C, if that certificate exists. > >>>>> > >>>>> During Phase 1, a CA may revoke certificates under Suite B withou= t > >>>>> revoking them under Suite A, since the Suite B products are for t= est > >>>>> purposes. During Phase 4 a CA may revoke certificates issued und= er > >>>>> Suite C without revoking them under Suite A, since Suite C produc= ts > >>>>> are being deprecated. > >>>> fixed. > >>>>> Despite the use of three letters (A, B and C), there are only two > >>>>> algorithm suites involved, and different instances of Suite A refer= to > >>>>> different algorithm suites. In each paragraph, the first instance o= f > >>>>> "Suite A" refers to the same algorithm suite as "Suite C", and the > >>>>> second instance of "Suite A" refers to the same algorithm suite > >>>>> as "Suite B". > >>>>> > >>>>> It would be much better and clearer to not change the meaning of th= e > >>>>> algorithm suite names until the EOL date. In addition, this change > >>>>> should enable removal of the Suite C concept from this draft. > >>>> fixed > >>>>> I > >>>>> strongly recommend removing the Suite C concept, as the C-A-B > >>>>> chronological order of suite introduction dates seems counter-intui= tive. > >>>> Done. > >>>>> > >>>>> Minor issues: > >>>>> > >>>>> Starting in Section 4.3.1, there are a number of uses of "will be" > >>>>> (future tense) in the milestone and phase descriptions. All of > >>>>> these uses of "will be" should be reviewed to determine whether > >>>>> "MUST be" is appropriate, e.g., as appears to be the case for > >>>>> this sentence in 4.3.1: > >>>>> > >>>>> Additionally, the new algorithm transition timeline document will= be > >>>>> published with the following information: > >>>> I agree that "will be" needs to be changed to "MUST be" in a few pla= ces, > >>>> starting on page 5 (Section 2) where the need to update the CP and t= o > >>>> publish an > >>>> alg transition timetable are first mentioned. An examination of the = rest > >>>> of the > >>>> doc shows that this change need be applied only when the alg transit= ion > >>>> doc is > >>>> mentioned. > >>>>> When "MUST be" is not appropriate, present tense (i.e., "is") is > >>>>> preferable. > >>>> fixed. > >>>>> > >>>>> Nits/editorial: > >>>>> > >>>>> Abstract: The following two sentences don't quite line up: > >>>>> > >>>>> The process > >>>>> is expected to be completed in a time scale of months or years. > >>>>> Consequently, no emergency transition is specified. > >>>>> > >>>>> Also, section 4.2 indicates that a multi-year transition timeframe > >>>>> is expected, which suggests that "months" is not appropriate in > >>>>> the abstract. Suggested rephrasing: > >>>>> > >>>>> The time available to complete the transition process > >>>>> is expected to be several years. > >>>>> Consequently, no emergency transition process is specified. > >>>> fixed. > >>>>> Section 2. Introduction: The first sentence in the last paragraph > >>>>> mentions a forthcoming BCP on transition timetable. The rest of > >>>>> that paragraph implies that the BCP is for a single transition, as > >>>>> opposed to being a BCP for transitions in general. It would be > >>>>> helpful to clarify that at the start of the paragraph, e.g., > >>>>> by adding "For each algorithm transition," to the start of the > >>>>> paragraph. > >>>> fixed. > >>>>> Section 3 Definitions: Is there any concern about possible > >>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? > >>>>> The draft is clear on what Suite B means for RPKI, but I suspect > >>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. > >>>> We defined what "Suite B" is in the terminology section, so I > >>>> think no further clarification is required here. > >>>>> Describing Phase 0 as both the steady state of the RPKI and the fir= st > >>>>> phase of transition is confusing (e.g., in 4.3). It would be clear= er > >>>>> if Phase 0 began with publication of the updated RPKI algorithm > >>>>> document (Milestone 1) and that the activities that are unchanged > >>>>> from steady state were described as not changing in phase 0. > >>>> we need to be able to refer to steady state, separate from the > >>>> first milestone in the transition process, but I agree that referrin= g to > >>>> it as the first phase of the transition process is confusing. I have > >>>> changed the text accordingly. > >>>>> Starting near the end of section 4.3, the three characters > >>>>> |-> are used in figures to represent an RPKI hierarchy relationship= ; > >>>>> that relationship should be defined and/or explained before it is u= sed. > >>>>> For clarity, I'd suggest swapping the order of the two paragraphs > >>>>> above that figure in 4.3 and making the following change at the end > >>>>> of the paragraph that is moved down (addition of the word > >>>>> "certificate" is the important change): > >>>>> > >>>>> OLD > >>>>> and shows the relationship between three CAs (X, Y, and Z) that f= orm > >>>>> a chain. > >>>>> NEW > >>>>> and shows the relationships among the three CAs (X, Y, and Z) > >>>>> that participate in a certificate chain. > >>>>> > >>>>> Subsequent uses of |-> seemed clear to me. > >>>> I'll defer to Roque here, as the repository representation is his de= sign. > >>>>> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at > >>>>> independent publication points, but does not make it clear that thi= s > >>>>> recommendation applies beyond phase 2. I suggest adding text to > >>>>> make that clear - a reference to Section 9 (which is clear about > >>>>> this) may be useful as part of that text. > >>>> I have added a forward pointer to Section 9 here. > >>>>> In Section 6, please expand the ROA acronym on first use and consid= er > >>>>> whether it should be defined in Section 3. I'm also assuming that = the > >>>>> ASN acronym is intended to refer to ASN.1 content; if not, that > >>>>> acronym also needs attention. > >>>> ASN =3D Autonomous System Number. I expended the acronym as it appea= rs > >>>> only here. I added a ROA definition to Section 3. > >>>>> idnits 2.12.13 found a couple of minor nits: > >>>>> > >>>>> ** There is 1 instance of too long lines in the document, the long= est > >> one > >>>>> being 23 characters in excess of 72. > >>>> I'll let Roque address this issue. > >>>>> > >>>>> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 = keyword, > >>>> but > >>>>> does not include the phrase in its RFC 2119 key words list. > >>>> fixed. > >>>> > >>> > >> > > >=20 From rogaglia@cisco.com Tue Jan 8 03:02:20 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF95021F8EE5; Tue, 8 Jan 2013 03:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRTztUlOHzBq; Tue, 8 Jan 2013 03:02:19 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5721F8E1C; Tue, 8 Jan 2013 03:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15098; q=dns/txt; s=iport; t=1357642938; x=1358852538; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4EeEz29b6e5RdhH0U7CcdGaM+ZahgyjxIHSGDzm/AS8=; b=QeQATxIzUxMzb7osVYGoX9Q/B+6+I6dwvk8g9IBphXq7ye0gpFkPzfgm N5+R1mwiWwd6BGqg7i3eTWAQKW2JIU9ucRLPsY9lSDMksKJZ4o77oMWSi +SFhvnsqcVOiBt6XKJ7771b13L68mD/cK+s0aZ2ESxjwvpLCVQb8EG7cO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO7761CtJV2a/2dsb2JhbABEvVYWc4IeAQEBAwEnEzgHBQcEAgEIEQQBAQEKFAkHMhQJCAIEDgUIiAkGqgiNNYxSg2JhA5JYk3yCdIFoAh4CBBg X-IronPort-AV: E=Sophos;i="4.84,430,1355097600"; d="scan'208";a="159772716" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jan 2013 11:02:17 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r08B2Hkf009295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jan 2013 11:02:17 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.7]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 05:02:17 -0600 From: "Roque Gagliano (rogaglia)" To: "Black, David" Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: AQHN7Pi5+smgNyB5VUaCZdHrAxAE8A== Date: Tue, 8 Jan 2013 11:02:16 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <50E1E8D0.5010204@bbn.com> <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287DB29CE@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287DB2A22@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287DB2A22@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.46] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gen-art@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 11:02:20 -0000 Hi David, I got your point. What about this text for that paragraph? "The following figure illustrates the format used to describe signed object= s in the repository. It reflects the algorithm suites in use, and shows the= relationship between three CAs (X, Y, and Z) that form a certificate chain= . The vertical alignment in the figure distinguishes between objects signed= by the same CA using the same private key. The vertical alignment also rep= resents the composition of the different publication points as a component = of the RPKI repository. The characters "|->" are used for visualization pur= pose. As an example taken from the figure, the objects CA-Y-Certificate-Alg= orithm-Suite-A, CA-X-CRL-Algorithm-Suite-A and CA-X-Signed-Objects-Algorit= hm-Suite-A are all signed using the private key corresponding to CA-X-Certi= ficate-Algorithm-Suite-A and published at that CA correspondent publication= point." Roque On Jan 7, 2013, at 7:53 PM, "Black, David" wrote: > Hi Roque, >=20 >> "The vertical alignment in the figure distinguishes between the differen= t >> publication points and the characters '|->' are used for visualization >> purpose." >=20 > I think there's more going on than just publication point change. >=20 > Here's the entire figure, plus the one existing sentence about > the '|->' notation: >=20 > CA X-Certificate-Algorithm-Suite-A (Cert-XA) > | > |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) > |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) > |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) > |-> CA-Z-Signed-Objects-Algorithm-Suite-A > |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) > |-> CA-Y-Signed-Objects-Algorithm-Suite-A > |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) > |-> CA-X-Signed-Objects-Algorithm-Suite-A >=20 > Note: Cert-XA represent the certificate for CA X, that is signed > using the algorithm suite A. >=20 > I believe that the private key corresponding to Cert-XA is used to sign > Cert-YA, e.g., so that Cert-XA is involved in the path validation of > Cert-YA. It looks like that's part of the relationship represented by > '|->' and (if so) I would like to see a statement to that effect in > addition to your proposed text about different publication points. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] >> Sent: Monday, January 07, 2013 12:52 PM >> To: Black, David >> Cc: Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; gen-art@ietf.o= rg; >> sidr@ietf.org; Stewart Bryant (stbryant) >> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>=20 >> Hi David, >>=20 >> On Jan 7, 2013, at 6:16 PM, "Black, David" wrote: >>=20 >>> Roque, >>>=20 >>> That new version looks good. Could you also take a look at this editor= ial >>> suggestion that Steve deferred to you?: >>>=20 >>=20 >> Ok, sorry about that. >>=20 >>> Starting near the end of section 4.3, the three characters >>> |-> are used in figures to represent an RPKI hierarchy relationship; >>> that relationship should be defined and/or explained before it is used. >>=20 >> The idea in the different figures is that the vertical alignment >> differentiates the different publication points. >>=20 >> What about adding the following text? >>=20 >> "The vertical alignment in the figure distinguishes between the differen= t >> publication points and the characters '|->' are used for visualization >> purpose." >>=20 >>=20 >>> For clarity, I'd suggest swapping the order of the two paragraphs >>> above that figure in 4.3 and making the following change at the end >>> of the paragraph that is moved down (addition of the word >>> "certificate" is the important change): >>=20 >> All done and thanks. >>=20 >> Roque >>=20 >>> OLD >>> and shows the relationship between three CAs (X, Y, and Z) that form >>> a chain. >>> NEW >>> and shows the relationships among the three CAs (X, Y, and Z) >>> that participate in a certificate chain. >>>=20 >>> Subsequent uses of |-> seemed clear to me. >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] >>>> Sent: Monday, January 07, 2013 12:02 PM >>>> To: Black, David >>>> Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; gen-art@ietf= .org; >>>> sidr@ietf.org; Stewart Bryant (stbryant) >>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>>=20 >>>> David, >>>>=20 >>>> I just published version 10 of the document with all the agreed change= s. >>>> Thanks again for your review. >>>>=20 >>>> Roque >>>>=20 >>>>=20 >>>> On Dec 31, 2012, at 8:57 PM, "Black, David" wrot= e: >>>>=20 >>>>> Steve, >>>>>=20 >>>>> This all looks good; thanks for the quick response. >>>>>=20 >>>>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A= , B >>>>>>> and C) from prior sections. >>>>>=20 >>>>>> I have deleted all references to Alg Suite C throughout the doc, and >>>>>> revised the text accordingly. >>>>>=20 >>>>> Magnificent - that'll be a significant improvement. >>>>>=20 >>>>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>>>> (future tense) in the milestone and phase descriptions. All of >>>>>>> these uses of "will be" should be reviewed to determine whether >>>>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>>>> this sentence in 4.3.1: >>>>>>>=20 >>>>>>> Additionally, the new algorithm transition timeline document will = be >>>>>>> published with the following information: >>>>>=20 >>>>>> I agree that "will be" needs to be changed to "MUST be" in a few pla= ces, >>>>>> starting on page 5 (Section 2) where the need to update the CP and t= o >>>> publish an >>>>>> alg transition timetable are first mentioned. An examination of the = rest >> of >>>> the >>>>>> doc shows that this change need be applied only when the alg transit= ion >> doc >>>> is >>>>>> mentioned. >>>>>=20 >>>>> That sounds reasonable. >>>>>=20 >>>>>>> Section 3 Definitions: Is there any concern about possible >>>>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>>>>=20 >>>>>> We defined what "Suite B" is in the terminology section, so I >>>>>> think no further clarification is required here. >>>>>=20 >>>>> That's ok with me, but I thought it was worth asking. >>>>>=20 >>>>> Thanks, >>>>> --David >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Stephen Kent [mailto:kent@bbn.com] >>>>>> Sent: Monday, December 31, 2012 2:35 PM >>>>>> To: Black, David >>>>>> Cc: rogaglia@cisco.com; Sean Turner; gen-art@ietf.org; sidr@ietf.org= ; >>>> Stewart >>>>>> Bryant >>>>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>>>>=20 >>>>>> David, >>>>>>=20 >>>>>>> The draft is generally well-written and clear, but has an unfortuna= te >>>>>>> nomenclature change problem that is the primary open issue[*]. >>>>>>>=20 >>>>>>> Major issues: >>>>>>>=20 >>>>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (A= , B >>>>>>> and C) from prior sections. >>>>>>=20 >>>>>> I have deleted all references to Alg Suite C throughout the doc, and >>>>>> revised the text accordingly. >>>>>>=20 >>>>>>> This also affects Sections 6 and 7. >>>>>>> I have classified this as a major issue as I believe it introduces >>>>>>> severe lack of clarity (and potential ambiguity) into the following >>>>>>> two paragraphs in Section 7: >>>>>>>=20 >>>>>>> During Phase 1, a CA that revokes a certificate under Suite A SHOU= LD >>>>>>> revoke the corresponding certificate under Suite B, if that >>>>>>> certificate exists. During Phase 4, a CA that revokes a certifica= te >>>>>>> under Suite A SHOULD revoke the corresponding certificate under Su= ite >>>>>>> C, if that certificate exists. >>>>>>>=20 >>>>>>> During Phase 1, a CA may revoke certificates under Suite B without >>>>>>> revoking them under Suite A, since the Suite B products are for te= st >>>>>>> purposes. During Phase 4 a CA may revoke certificates issued unde= r >>>>>>> Suite C without revoking them under Suite A, since Suite C product= s >>>>>>> are being deprecated. >>>>>> fixed. >>>>>>> Despite the use of three letters (A, B and C), there are only two >>>>>>> algorithm suites involved, and different instances of Suite A refer= to >>>>>>> different algorithm suites. In each paragraph, the first instance o= f >>>>>>> "Suite A" refers to the same algorithm suite as "Suite C", and the >>>>>>> second instance of "Suite A" refers to the same algorithm suite >>>>>>> as "Suite B". >>>>>>>=20 >>>>>>> It would be much better and clearer to not change the meaning of th= e >>>>>>> algorithm suite names until the EOL date. In addition, this change >>>>>>> should enable removal of the Suite C concept from this draft. >>>>>> fixed >>>>>>> I >>>>>>> strongly recommend removing the Suite C concept, as the C-A-B >>>>>>> chronological order of suite introduction dates seems counter-intui= tive. >>>>>> Done. >>>>>>>=20 >>>>>>> Minor issues: >>>>>>>=20 >>>>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>>>> (future tense) in the milestone and phase descriptions. All of >>>>>>> these uses of "will be" should be reviewed to determine whether >>>>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>>>> this sentence in 4.3.1: >>>>>>>=20 >>>>>>> Additionally, the new algorithm transition timeline document will = be >>>>>>> published with the following information: >>>>>> I agree that "will be" needs to be changed to "MUST be" in a few pla= ces, >>>>>> starting on page 5 (Section 2) where the need to update the CP and t= o >>>>>> publish an >>>>>> alg transition timetable are first mentioned. An examination of the = rest >>>>>> of the >>>>>> doc shows that this change need be applied only when the alg transit= ion >>>>>> doc is >>>>>> mentioned. >>>>>>> When "MUST be" is not appropriate, present tense (i.e., "is") is >>>>>>> preferable. >>>>>> fixed. >>>>>>>=20 >>>>>>> Nits/editorial: >>>>>>>=20 >>>>>>> Abstract: The following two sentences don't quite line up: >>>>>>>=20 >>>>>>> The process >>>>>>> is expected to be completed in a time scale of months or years. >>>>>>> Consequently, no emergency transition is specified. >>>>>>>=20 >>>>>>> Also, section 4.2 indicates that a multi-year transition timeframe >>>>>>> is expected, which suggests that "months" is not appropriate in >>>>>>> the abstract. Suggested rephrasing: >>>>>>>=20 >>>>>>> The time available to complete the transition process >>>>>>> is expected to be several years. >>>>>>> Consequently, no emergency transition process is specified. >>>>>> fixed. >>>>>>> Section 2. Introduction: The first sentence in the last paragraph >>>>>>> mentions a forthcoming BCP on transition timetable. The rest of >>>>>>> that paragraph implies that the BCP is for a single transition, as >>>>>>> opposed to being a BCP for transitions in general. It would be >>>>>>> helpful to clarify that at the start of the paragraph, e.g., >>>>>>> by adding "For each algorithm transition," to the start of the >>>>>>> paragraph. >>>>>> fixed. >>>>>>> Section 3 Definitions: Is there any concern about possible >>>>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>>>> We defined what "Suite B" is in the terminology section, so I >>>>>> think no further clarification is required here. >>>>>>> Describing Phase 0 as both the steady state of the RPKI and the fir= st >>>>>>> phase of transition is confusing (e.g., in 4.3). It would be clear= er >>>>>>> if Phase 0 began with publication of the updated RPKI algorithm >>>>>>> document (Milestone 1) and that the activities that are unchanged >>>>>>> from steady state were described as not changing in phase 0. >>>>>> we need to be able to refer to steady state, separate from the >>>>>> first milestone in the transition process, but I agree that referrin= g to >>>>>> it as the first phase of the transition process is confusing. I have >>>>>> changed the text accordingly. >>>>>>> Starting near the end of section 4.3, the three characters >>>>>>> |-> are used in figures to represent an RPKI hierarchy relationship= ; >>>>>>> that relationship should be defined and/or explained before it is u= sed. >>>>>>> For clarity, I'd suggest swapping the order of the two paragraphs >>>>>>> above that figure in 4.3 and making the following change at the end >>>>>>> of the paragraph that is moved down (addition of the word >>>>>>> "certificate" is the important change): >>>>>>>=20 >>>>>>> OLD >>>>>>> and shows the relationship between three CAs (X, Y, and Z) that fo= rm >>>>>>> a chain. >>>>>>> NEW >>>>>>> and shows the relationships among the three CAs (X, Y, and Z) >>>>>>> that participate in a certificate chain. >>>>>>>=20 >>>>>>> Subsequent uses of |-> seemed clear to me. >>>>>> I'll defer to Roque here, as the repository representation is his de= sign. >>>>>>> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at >>>>>>> independent publication points, but does not make it clear that thi= s >>>>>>> recommendation applies beyond phase 2. I suggest adding text to >>>>>>> make that clear - a reference to Section 9 (which is clear about >>>>>>> this) may be useful as part of that text. >>>>>> I have added a forward pointer to Section 9 here. >>>>>>> In Section 6, please expand the ROA acronym on first use and consid= er >>>>>>> whether it should be defined in Section 3. I'm also assuming that = the >>>>>>> ASN acronym is intended to refer to ASN.1 content; if not, that >>>>>>> acronym also needs attention. >>>>>> ASN =3D Autonomous System Number. I expended the acronym as it appea= rs >>>>>> only here. I added a ROA definition to Section 3. >>>>>>> idnits 2.12.13 found a couple of minor nits: >>>>>>>=20 >>>>>>> ** There is 1 instance of too long lines in the document, the longe= st >>>> one >>>>>>> being 23 characters in excess of 72. >>>>>> I'll let Roque address this issue. >>>>>>>=20 >>>>>>> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 k= eyword, >>>>>> but >>>>>>> does not include the phrase in its RFC 2119 key words list. >>>>>> fixed. >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From eosterweil@verisign.com Wed Jan 9 07:43:14 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA08921F84F3 for ; Wed, 9 Jan 2013 07:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPjgGMPU0xup for ; Wed, 9 Jan 2013 07:43:14 -0800 (PST) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2921F849A for ; Wed, 9 Jan 2013 07:43:13 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUO2QEQfeXnHLDO4fnnD61lS2qw3vzCqk@postini.com; Wed, 09 Jan 2013 07:43:14 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r09FhABL029262 for ; Wed, 9 Jan 2013 10:43:13 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jan 2013 10:43:10 -0500 From: Eric Osterweil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Jan 2013 10:43:10 -0500 Message-Id: To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 09 Jan 2013 15:43:10.0511 (UTC) FILETIME=[070CB3F0:01CDEE80] Subject: [sidr] GB records X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:43:14 -0000 Hey everyone, Has anyone done any work deploying ghostbusters records yet? In doing = some implementation I found myself yearning for some examples... :) If there are any opportune examples, could someone give me a pointer = (off list would be fine). Thanks in advance, Eric= From randy@psg.com Wed Jan 9 16:47:57 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CB811E809B for ; Wed, 9 Jan 2013 16:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53kla3v0oNtN for ; Wed, 9 Jan 2013 16:47:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9845311E8097 for ; Wed, 9 Jan 2013 16:47:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tt6JG-00021I-0k; Thu, 10 Jan 2013 00:47:54 +0000 Date: Thu, 10 Jan 2013 09:47:53 +0900 Message-ID: From: Randy Bush To: Eric Osterweil 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.7 - "Harue") Content-Type: multipart/mixed; boundary="Multipart_Thu_Jan_10_09:47:52_2013-1" Cc: sidr wg list Subject: Re: [sidr] GB records X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 00:47:57 -0000 --Multipart_Thu_Jan_10_09:47:52_2013-1 Content-Type: text/plain; charset=US-ASCII > Has anyone done any work deploying ghostbusters records yet? yes > If there are any opportune examples --Multipart_Thu_Jan_10_09:47:52_2013-1 Content-Type: image/png Content-Disposition: inline; filename="altCA.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAPMAAADzAQAAAAB7jR2SAAAACXBIWXMAAAsSAAALEgHS3X78AAAF fklEQVRYhe2ZMY6sOhBFCxGQwQaQ2IYzbwk20DQbgC2RsQ1LbAAyBwj/U+6e/1/w9RLqZQ+1Zqa5 SMauurdu1Uj6/SV/8T+MHyJDKqftKlL5lnJJ3ezL2cuwSmGBn+kaNmliGONVxO5d7WcMtYRxA7LA 13aIafbpcKwZeseD3S1l2ngvIzyx7DWu7LI8UzdF6avQ2OEvt6ftEimnWM6VFNs+O541wjm/eL24 kVi2PNfuXAPB+fV8n+Aa/639n88v+fEE57p9eW6s39a+JTiH414Y/8vvR/jh5eWlWMtDWqmkFpYV /hhiKEzwqkyrNFtatrbQbaW7IqP3t+tOE9yFYm3rqhWXZiF/07LuZ9qn2C0W+C37u2JD++HJNfhd nlEpzluMJrgLtYOCO4kgnsgH6A4ROdTGBJf9rropsWAQpylQE64EXT7xf4qfWxBfLqvU1T4L/C7f Tl6ubQiXBZ7gWRQl94aK8ArQjlghKqGxwJG9InJ+MFvEXVJdL+kWTd5yscDvimpwDUklqufwXPn2 msu9fPjxGHehWSXvhpNTfs+uu9nfdg0WOGpxKOFILjTjKsgs9AOKxHa0wPnNyrOwIGHXyqYhWncK 6WSCo3zsLyJUqCCRIVbsGC35xOcxnq4Xmet3QCLDBd2H9UKrRhN82xfIXbUo0+zZHF/JsvJ2abLA yV/IQcFHv8cN5aN+htqnNydqgScKJpqk0YAoaaH+yNUkMs4Gv0X9ywLLt25Gq6TtKxnh31c/nuKH p2CqYLOzMba1dGfcZ1xY+ub3UxzDglRECK2yx+Ko+IgRk+/6j3G2dTVxn9aLe02kloa6Ir++8X+I p4gb0uL2dqRAlzZccECoChTRAr9zqmJhEv537VDx20mvJ9olC/zwGpOEJxV12YIRqPL5+d0EZ/HD UUITMadEv1S2sQNpUkdmgFN2Gmyvx1aHUY0Mx0byouJhsMDhH2X5zipec5CUOG0UykxKA/xW/0sK Z4nyaCF3oCMbbUcLPKX9dl1aSWHVqgZlzeR+VW1jgXOvFhYPuTJroDjRl9AO/tS/h3jO00ndBMHp tATpV7i+TxZ4SlePhVkp0dQfPbaCFrbSHRcW+AGtsaUon+cG4pGNMKYPlbXAb686NwtZxk/sHruk heWznxZ4UuULelrKietTgiiq7+qbXw9xrZ8Vmre/Vb+RVc6SFpOvX/1+iMM/PT8tmPjTEnOXF4fl /9bXR/i5ZasYKfuCbOtHXXZ+EQv81vqpbSUW4HBXX/Ez8MiQymSBJ7UVrXhcjJ4fD+IfKUraMVjg 2m3Hq/baxUKUBv/iu2VTuzSY4DQcauWoNiUSWNAlILG+fTkbHBIcmrxSO3WpSNQSNakxNZMFTuV8 aYtJ2HmRT3wQj/Djf5/i9K+HqFXR+YRX/ZY8n0NfGwv80LYGqUD88BdwPS1rt6ww8jLBb68gkRkj WUxzoEZ+0jv7YoPDNjwpxZkN4dw7naVVu/oyC/zccC64Fc6PFlPUn+b+D683WeAHPWse2CzrR2L3 OVukEaG1wM+VmpCVj8zdsEhESe02Rng0wXUakaaIPw199u+9cv0akw1+CDlF23rhss/8R7MhJ21u xy1wFxp1Q4H6f3taTCU6Lu9nvvsUT1otsQB6fklnckgsbyHNd77yFOf8ejyjy/qNF1j5TXDon370 6xnOdeb5wZl0kFDr2LJ7V+rITHDtCXR+oAMJOI2d6XPRm7avvj/E8/xbsmaUy4YmwXVtd4bv+o/x 9WMu9J8nbxdeOittaTFpp0YjnJ4J2aas9V5dno4oVvVigxWu/824dDgK/5yMm4yr7rsxwdVfa7eH cte0gBVEhCUXT5ngxL/3NK/YCh1e6hStysOteBUW+O+vv/ifxf8BlpcmPNaY8Q4AAAAASUVORK5C YII= --Multipart_Thu_Jan_10_09:47:52_2013-1 Content-Type: text/plain; charset=US-ASCII --Multipart_Thu_Jan_10_09:47:52_2013-1-- From warren@kumari.net Wed Jan 9 18:46:17 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D300221F8561 for ; Wed, 9 Jan 2013 18:46:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vgSn+DfKiHi for ; Wed, 9 Jan 2013 18:46:17 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA11921F851E for ; Wed, 9 Jan 2013 18:46:16 -0800 (PST) Received: from [192.168.0.187] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 3A8251B402D4; Wed, 9 Jan 2013 21:46:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 9 Jan 2013 21:46:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8115C5A4-8BF4-492E-BB97-D63F3D24AF0E@kumari.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1499) Cc: sidr wg list Subject: Re: [sidr] GB records X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 02:46:18 -0000 On Jan 9, 2013, at 7:47 PM, Randy Bush wrote: >> Has anyone done any work deploying ghostbusters records yet? >=20 > yes >=20 >> If there are any opportune examples >=20 > > _ Cute. W > ______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --=20 "Does Emacs have the Buddha nature? Why not? It has bloody well = everything else..." From eosterweil@verisign.com Thu Jan 10 07:08:16 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0510D21F8566 for ; Thu, 10 Jan 2013 07:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YojyzBZk-FNd for ; Thu, 10 Jan 2013 07:08:15 -0800 (PST) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id DE38321F8528 for ; Thu, 10 Jan 2013 07:08:14 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUO7ZXeWb88TuPkl6PV79WgFa19nExgV6@postini.com; Thu, 10 Jan 2013 07:08:14 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r0AF8CdD009436; Thu, 10 Jan 2013 10:08:12 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jan 2013 10:08:12 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 10 Jan 2013 10:08:12 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1E3ECC23-089D-4EB0-AE51-A9A450AC621B@verisign.com> References: To: Randy Bush X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 10 Jan 2013 15:08:12.0312 (UTC) FILETIME=[4ED6B180:01CDEF44] Cc: sidr wg list Subject: Re: [sidr] GB records X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 15:08:16 -0000 On Jan 9, 2013, at 7:47 PM, Randy Bush wrote: >> Has anyone done any work deploying ghostbusters records yet? > > yes > >> If there are any opportune examples > > > :) From alexey.melnikov@isode.com Thu Jan 10 09:05:35 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218D821F89CB for ; Thu, 10 Jan 2013 09:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUXKtclZ+r4V for ; Thu, 10 Jan 2013 09:05:34 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 208FB21F8945 for ; Thu, 10 Jan 2013 09:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1357837530; d=isode.com; s=selector; i=@isode.com; bh=GsPMkuj/HvRFuRBBnRVX/1Echp2W6epGS6yfDSfZeeU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vxZawFUkCVAoJSLmq+QvCPboXSJHq7YtCMrFjZYtnR/a2jLInyMvQH56A44W3SzusuXM6f WffOB42Dm0SK6+UXzGXRZnQtBnbcBeSEzeYocoqH6omtlGW9ZcGzKzKbAH7VouQOTsHkUX pqrpk+bW6gX42k09CU7wPYut2lnmIEs=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 Jan 2013 17:05:30 +0000 Message-ID: <50EEF4F6.4070903@isode.com> Date: Thu, 10 Jan 2013 17:05:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: sidr wg References: <50C8E17D.3090507@isode.com> In-Reply-To: <50C8E17D.3090507@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] Poll: WG acceptance of draft-ymbk-rpki-grandparenting-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 17:05:35 -0000 On 12/12/2012 19:56, Alexey Melnikov wrote: > Dear WG participants, > > I would like to initiate 2+ weeks poll (ending on December 31st 2012) Although the poll has ended last year, there was a suggestion to extend it. If you want to express your opinion, but haven't done so yet, can you please do that by the end of Sunday, January 13th. Or at least email me directly if you think you need more time. Thanks, Alexey > regarding acceptance of draft-ymbk-rpki-grandparenting-02.txt. Please > reply to questions listed below. Send your replies to the mailing list > or directly to WG chairs . I would like to > avoid extended discussions of technical issues at this time, as I > think people already made up their minds. However including pointers > to earlier discussions is fine. > > Alexey, > on behald of SIDR chairs. > > ---------------- > > 1) Is the problem described/solved by > draft-ymbk-rpki-grandparenting-02 actually a problem that the WG needs > to address? (Answer: yes or no. Additional information is welcomed, > but I don't want people to repeat the whole discussion.) > > 2) If you answered "yes" to the question #1, please also answer the > following question: > > Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to > become a WG document? Please choose one of the following: > > > a) Ready for Adoption (whether or not you have some specific issues > with it. Also, this answer is unrelated to whether this should be a > separate draft or a part of an existing draft). > > b) Needs more work BEFORE Adoption > > c) Should not be adopted. In particular this mean that you don't > believe any amount of work on the proposed draft will address your > issues. So any solution to this problem should be a new draft written > from scratch. > > d) Abstain/don't care > > > 3) If you answered "a" or "b" above, please also answer the following > question: > > Does this need to be in a standalone draft, or can it be incorporated > into another existing WG draft? When answering this question please > only base your answer on technical reasons, in particular please leave > the decision on who is going to edit the document (if it is > standalone) to WG chairs. From swmike@swm.pp.se Thu Jan 10 23:48:10 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E38E21F8A50 for ; Thu, 10 Jan 2013 23:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1w9d3d8hTR6 for ; Thu, 10 Jan 2013 23:48:09 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2A421F89E9 for ; Thu, 10 Jan 2013 23:48:09 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8AF889C; Fri, 11 Jan 2013 08:48:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8338E9A for ; Fri, 11 Jan 2013 08:48:06 +0100 (CET) Date: Fri, 11 Jan 2013 08:48:06 +0100 (CET) From: Mikael Abrahamsson To: sidr@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 07:48:10 -0000 Hello. I work for an ISP. I have historically been present at at least one presentation by Randy Bush regarding BGP advertisment verification (which I found to be very informative). I thought I'd read up on what the current state of affairs are, so I started looking through the archives of this WG, plus looking through the past few operator meeting agendas (NANOG55-56), (RIPE64-65). I found "ROVER: BGP Route Origin Verification using Reverse-DNS" at NANOG55, "RPKI Propagation" by R. Bush at RIPE65. Are there others I should read? Reading the RIPE65 it worries me that this information seems to be created by the RIRs. I have some insight in what it takes in the operations/administration of gtld and cctld registrar/registry plus global anycasted root name server infrastructure. I feel what we're talking about here is the same thing, or even more important. If secure BGP verification doesn't work, nothing will work. Root name and (cc|g)tld servers get all the attention, but root name servers can be offline for a long duration of time without seriously affecting the Internet as a whole. The RPKI infrastructure needs to be done with same reisiliancy or better it seems. So trusting SIDR-WG and others to do the protocol standardisation, what needs to be done on the operational side to get this running at a level of quality needed to be 99.999% available and correct, both from the RIR side and documents telling ISPs what they need to do internally to make this work properly? -- Mikael Abrahamsson email: swmike@swm.pp.se From bortzmeyer@nic.fr Fri Jan 11 00:19:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3E21F8A08 for ; Fri, 11 Jan 2013 00:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjqXOcBs43o9 for ; Fri, 11 Jan 2013 00:19:39 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3C38421F88D6 for ; Fri, 11 Jan 2013 00:19:39 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5C14728055D; Fri, 11 Jan 2013 09:19:07 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 57C0F280558; Fri, 11 Jan 2013 09:19:07 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id 4C856B3806D; Fri, 11 Jan 2013 09:18:37 +0100 (CET) Date: Fri, 11 Jan 2013 09:18:37 +0100 From: Stephane Bortzmeyer To: Mikael Abrahamsson Message-ID: <20130111081837.GC12321@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: sidr@ietf.org Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 08:19:40 -0000 On Fri, Jan 11, 2013 at 08:48:06AM +0100, Mikael Abrahamsson wrote a message of 37 lines which said: > If secure BGP verification doesn't work, nothing will work. [...] > The RPKI infrastructure needs to be done with same reisiliancy or > better it seems. Resiliency of the *servers* (the rsync distributors of certs and ROAs) is less important than in the DNS case, since the validating caches can work standalone, without updating the data, for a long time. (Although a document on timing issues, expiration, duration of signatures, would be a good idea.) Resiliency of the data is indeed critical. If a RIR, because of a sofwtare bug or a hijack of its servers starts to serve bogus data, we will have a problem. From sm@resistor.net Fri Jan 11 02:29:08 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CD921F87D6 for ; Fri, 11 Jan 2013 02:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jznEgIlA2S0l for ; Fri, 11 Jan 2013 02:29:07 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3721F87FE for ; Fri, 11 Jan 2013 02:29:06 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0BAT0pM024464; Fri, 11 Jan 2013 02:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357900145; bh=wqV0P44nOdQEJvNxFMGooecI7siBnPCcAAyeWVjkGCE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QL0qoZSeSY3HmN45xrkiMFiNeaVXFdbUpNnRE7n22cYyrOR8e3p/4q59/GYC1MnbB 3Rha/rdUp35hAnW4M9mNK+G/ztBEjJzQmjTpmMzQTBZ2hrRqX94kmrxNvyyIN6RvD3 RguLpKbe8QFeNufvZ8qNjLgDG5nO+ljFccrJRhHA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357900145; i=@resistor.net; bh=wqV0P44nOdQEJvNxFMGooecI7siBnPCcAAyeWVjkGCE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WcZIPGcVJ9VkEvfIkpbIS/Xb0OWASPGnAfIfCvJsC0VODZaRgXLQYddSEBDydkjxH Kd0ShQAlwd84sHDsGunU1sYdotsp2m1tRYB6aWsPw+gaJGTzuqJmCjMRDLuNF3KVKf PCXCJhniPac3WDXchS7w3VwwdbF0Q8GHe+iEibpA= Message-Id: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Jan 2013 02:27:16 -0800 To: Mikael Abrahamsson From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sidr@ietf.org Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:29:08 -0000 Hi Mikael, At 23:48 10-01-2013, Mikael Abrahamsson wrote: >So trusting SIDR-WG and others to do the protocol standardisation, >what needs to be done on the operational side to get this running at >a level of quality needed to be 99.999% available and correct, both >from the RIR side and documents telling ISPs what they need to do >internally to make this work properly? draft-ietf-sidr-bgpsec-threats-03 discusses about the threat model. It could be used as a starting point to identify the points of failures. Regards, -sm From rogaglia@cisco.com Fri Jan 11 03:12:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F8A21F877B for ; Fri, 11 Jan 2013 03:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.099 X-Spam-Level: X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otbvMZ4TaZ-H for ; Fri, 11 Jan 2013 03:12:39 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EAC3021F873E for ; Fri, 11 Jan 2013 03:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=978; q=dns/txt; s=iport; t=1357902758; x=1359112358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t7hmCOcx0lZ+KfCqdpGJ5K7/wzz84/zZU71QUD7EZ38=; b=SnkKcaePpINgOvdGVjEtlCqWJBq8wHra1E9T1VdLO79g+eCYAmyLKANx ZvOuU+Iu6zCfUW70PBjEyDLhj5bRAQ/dZkO7BeFn7RnxpTKjPabVzuawv DwBMTnBcD2zeuYra6lRfzzz3cNGrPORNDPuL0icWk8sOVf39at3WpOrc0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAKby71CtJXHB/2dsb2JhbAA6CoVyuAcWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCIgLBgy1JIxtg1FhA5cmjy2CdYIk X-IronPort-AV: E=Sophos;i="4.84,451,1355097600"; d="scan'208";a="161312199" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jan 2013 11:12:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0BBCbqB030544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jan 2013 11:12:37 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.7]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 05:12:37 -0600 From: "Roque Gagliano (rogaglia)" To: SM Thread-Topic: [sidr] current state of BGP origin verification Thread-Index: AQHN7+yPU/HPKqhyK0S2aTWXzlGTHQ== Date: Fri, 11 Jan 2013 11:12:36 +0000 Message-ID: References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> In-Reply-To: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.40] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C1A2730F862D245857BC9EF8FD0A305@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 11:12:40 -0000 Wrong Reference. Mikael, have you looked at: http://tools.ietf.org/html/draft-ietf-sidr-orig= in-ops-19 That could be a starting point to look for missing pieces from an OPS persp= ective. Roque On Jan 11, 2013, at 11:27 AM, SM wrote: > Hi Mikael, > At 23:48 10-01-2013, Mikael Abrahamsson wrote: >> So trusting SIDR-WG and others to do the protocol standardisation, what = needs to be done on the operational side to get this running at a level of = quality needed to be 99.999% available and correct, both from the RIR side = and documents telling ISPs what they need to do internally to make this wor= k properly? >=20 > draft-ietf-sidr-bgpsec-threats-03 discusses about the threat model. It c= ould be used as a starting point to identify the points of failures. >=20 > Regards, > -sm=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From swmike@swm.pp.se Fri Jan 11 03:12:51 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593B421F873E for ; Fri, 11 Jan 2013 03:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jvmSKKT4dl8 for ; Fri, 11 Jan 2013 03:12:50 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 81CA621F8809 for ; Fri, 11 Jan 2013 03:12:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 976329C; Fri, 11 Jan 2013 12:12:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8EF379A for ; Fri, 11 Jan 2013 12:12:47 +0100 (CET) Date: Fri, 11 Jan 2013 12:12:47 +0100 (CET) From: Mikael Abrahamsson To: sidr@ietf.org In-Reply-To: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> Message-ID: References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 11:12:51 -0000 On Fri, 11 Jan 2013, SM wrote: > draft-ietf-sidr-bgpsec-threats-03 discusses about the threat model. It > could be used as a starting point to identify the points of failures. Some of the failure scenarios I have heard from the dns TLD world: Zone file was truncated due to lack of disk space. Insufficient checks was in place to notice the truncated zone file before it was replicated out to the public-facing DNS infrastructure, thus causing outage. DNSSEC failure (don't remember the exact details), ie not everything was correctly signed, thus causing failure. DNSSEC is an example of a protocol which is quite brittle operationally. You make one mistake, and your entire domain is toast. So when implementing RPKI at the RIR level, there should be operational advice how everything should be done. Preferrably even at the protocol level, there should be a disaster "off" button which the publisher can use to just switch off all validation for all records they handle, and this should be propagated very quickly. Frankly, I'm scared when I read the documentation for this (=SIDR) thing. I feel it fails the "KISS" test with all the CA, signing, propagation infrastructure needed. It's also quite different from anything else that the normal network engineer is exposed to historically in their day to day work life. It's my opinion that a lot of careful though put into how this is actually implemented in real life, making sure there are operational tools (I still have not signed my private domain with DNSSEC because the operational tools are too hard to use) in place to aid deployment. The re-signing needed over time to keep DNSSEC (and SSL certificates) up to date is something I see people fail routinely still. This needs to be automated. Is it too early in the protocol development process to start looking into the operational aspects? -- Mikael Abrahamsson email: swmike@swm.pp.se From arturo.servin@gmail.com Fri Jan 11 07:38:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476F321F886B for ; Fri, 11 Jan 2013 07:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POWYFKNKj4dd for ; Fri, 11 Jan 2013 07:38:27 -0800 (PST) Received: from mail-ye0-f176.google.com (mail-ye0-f176.google.com [209.85.213.176]) by ietfa.amsl.com (Postfix) with ESMTP id 72AE421F872C for ; Fri, 11 Jan 2013 07:38:27 -0800 (PST) Received: by mail-ye0-f176.google.com with SMTP id m1so341213yen.21 for ; Fri, 11 Jan 2013 07:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZA8e6BxscYLsDKuI0MI5RNCRfzyrLsSPrhqdC7fxcVg=; b=bb4qDQjgd3aARxP+YblaVO81upB8Jz+S+eFWDgrCY0mcUUAiEfnwiDZE1BaslP/Adp 9qa8H5EEyb02UmfOV2lRAMrzE2zIKLW1AY1GQKYwSNUKZ51tZiARO1/3z/PYf+f9EsZ6 Bw8wvvdTk0DtuKPnGFzCx8H1AZoPdq1VEo1V3atn7sY/JBpy199S7mrIszAUR9wDKrYV 3b2f6XGy5TMfl2xScynzkHMO0nMd+th/ogjzIsxdaNgO/hX0n/GjDrTNrt05rUsxSmYm 9sbyQsOiqms26k5lJkDp5dTj5ibgHO/CBygRVSYmWKG0V2uhYBkLC05goK04TtNZyR3g qorA== X-Received: by 10.236.91.228 with SMTP id h64mr85450566yhf.51.1357918706884; Fri, 11 Jan 2013 07:38:26 -0800 (PST) Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:a4a3:1474:13c7:b7a0]) by mx.google.com with ESMTPS id y9sm4044398anh.20.2013.01.11.07.38.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Jan 2013 07:38:26 -0800 (PST) Message-ID: <50F031EE.2080606@gmail.com> Date: Fri, 11 Jan 2013 13:38:22 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sidr@ietf.org References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:38:28 -0000 Mikael, Do you think that http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 covers your concerns? If not, do you recommend to add text to this draft or to focus in a new document describing the operation of a CA? Regards, as On 11/01/2013 09:12, Mikael Abrahamsson wrote: > On Fri, 11 Jan 2013, SM wrote: > >> draft-ietf-sidr-bgpsec-threats-03 discusses about the threat model. >> It could be used as a starting point to identify the points of failures. > > Some of the failure scenarios I have heard from the dns TLD world: > > Zone file was truncated due to lack of disk space. Insufficient checks > was in place to notice the truncated zone file before it was replicated > out to the public-facing DNS infrastructure, thus causing outage. > > DNSSEC failure (don't remember the exact details), ie not everything was > correctly signed, thus causing failure. DNSSEC is an example of a > protocol which is quite brittle operationally. You make one mistake, and > your entire domain is toast. > > So when implementing RPKI at the RIR level, there should be operational > advice how everything should be done. Preferrably even at the protocol > level, there should be a disaster "off" button which the publisher can > use to just switch off all validation for all records they handle, and > this should be propagated very quickly. > > Frankly, I'm scared when I read the documentation for this (=SIDR) > thing. I feel it fails the "KISS" test with all the CA, signing, > propagation infrastructure needed. It's also quite different from > anything else that the normal network engineer is exposed to > historically in their day to day work life. It's my opinion that a lot > of careful though put into how this is actually implemented in real > life, making sure there are operational tools (I still have not signed > my private domain with DNSSEC because the operational tools are too hard > to use) in place to aid deployment. > > The re-signing needed over time to keep DNSSEC (and SSL certificates) up > to date is something I see people fail routinely still. This needs to be > automated. > > Is it too early in the protocol development process to start looking > into the operational aspects? > From christopher.morrow@gmail.com Fri Jan 11 08:03:25 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8035321F875C for ; Fri, 11 Jan 2013 08:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XucF+xd-1ZG for ; Fri, 11 Jan 2013 08:03:23 -0800 (PST) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 519A021F873D for ; Fri, 11 Jan 2013 08:03:23 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id a14so378880eaa.9 for ; Fri, 11 Jan 2013 08:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ybbIyetC3tvNXsPGmDYZNy1I6Q84g8alGI0CCciOP3g=; b=hX0UZyISP6bSBpYr7P8z3Xq/EJPGRTpj5VyZNz7MSmcQvU2NEQVjHMSmb0AZC/SjA0 7f2mMAJcd05IpGhojkeDyz3onzOl8E7V2dtmNu/pt0CjC3vIZJJn5dgg0HyNOLcJCeea w2hManJYrGVZVnk9VHoMfvyCK5FeqDkHBDQmjze3UUtSBx9UbOwUz9UANFGL+gBxnrcK pV5qxepAFXO0ssUmVCay44g67VIRidP1+L3PNqnw9tU8KA53qndE3iZ9Pcd9USW1yTma 6GbDmQNohK39hfL3g2SV/nwfn8Zi6yDtwpZpPTv2MS/swCWDEsaWtZWlSohRAOT6J+DM 30vw== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr202687431eef.25.1357920202342; Fri, 11 Jan 2013 08:03:22 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Fri, 11 Jan 2013 08:03:22 -0800 (PST) In-Reply-To: <20120710160824.31991.99366.idtracker@ietfa.amsl.com> References: <20120710160824.31991.99366.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 11:03:22 -0500 X-Google-Sender-Auth: PdCXdIBnEQ0G1lR8hne90HIDrv4 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sidr] I-D ACTION:draft-ietf-sidr-cps-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:03:25 -0000 Hey there SIDR folk, This draft seemed to expire, yesterday, oops! I think we need a CPS describing document, so I bet the authors will refresh this in time. That said: 1) does the current version need work still? Was the combination of the previous 2 documents: http://tools.ietf.org/html/draft-ietf-sidr-cps-irs http://tools.ietf.org/html/draft-ietf-sidr-cps-isp a good thing to do? (it seems to remove some page flipping and combine what was mostly the same content anyway into one reference) 2) if this is 'ok' as is, should we send out a wglc now/soon for this document? -chris (co-chair 1 of 3) On Tue, Jul 10, 2012 at 12:08 PM, wrote: > 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 a Certification Practice Statement (CPS) for the Resource PKI (RPKI) > Author(s) : S. Kent, et al > Filename : draft-ietf-sidr-cps > Pages : 42 > Date : July 10, 2012 > > This document contains a template to be used for creating a > Certification Practice Statement (CPS) for an Organization that is > part of the Resource Public Key Infrastructure (RPKI), e.g., a > resource allocation registry or an ISP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kseo@bbn.com Fri Jan 11 08:46:51 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC9021F8A4E for ; Fri, 11 Jan 2013 08:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjZMnLVqr5Ov for ; Fri, 11 Jan 2013 08:46:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 27FDB21F89AA for ; Fri, 11 Jan 2013 08:46:50 -0800 (PST) Received: from dhcp89-089-095.bbn.com ([128.89.89.95]:49176) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tthkn-0004U0-71; Fri, 11 Jan 2013 11:46:49 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120710160824.31991.99366.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 11:46:46 -0500 To: Christopher Morrow From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] I-D ACTION:draft-ietf-sidr-cps-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 16:46:51 -0000 Chris, Yes, we'll submit a new version. We have not received any feedback since presenting this at the July IETF (6 months ago) so WGLC seems appropriate (to me at least :-)). Thank you, Karen >Hey there SIDR folk, > This draft seemed to expire, yesterday, oops! I think we need a CPS >describing document, so I bet the authors will refresh this in time. >That said: > 1) does the current version need work still? Was the combination of >the previous 2 documents: > http://tools.ietf.org/html/draft-ietf-sidr-cps-irs > http://tools.ietf.org/html/draft-ietf-sidr-cps-isp > a good thing to do? (it seems to remove some page flipping and >combine what was mostly the same content anyway into one reference) > 2) if this is 'ok' as is, should we send out a wglc now/soon for >this document? > >-chris >(co-chair 1 of 3) > >On Tue, Jul 10, 2012 at 12:08 PM, wrote: >> 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 a Certification Practice >>Statement (CPS) for the Resource PKI (RPKI) >> Author(s) : S. Kent, et al >> Filename : draft-ietf-sidr-cps >> Pages : 42 >> Date : July 10, 2012 >> >> This document contains a template to be used for creating a >> Certification Practice Statement (CPS) for an Organization that is >> part of the Resource Public Key Infrastructure (RPKI), e.g., a >> resource allocation registry or an ISP. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> 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 swmike@swm.pp.se Fri Jan 11 09:57:56 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4DD21F8881 for ; Fri, 11 Jan 2013 09:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv8fOqgp2Th3 for ; Fri, 11 Jan 2013 09:57:55 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29021F88D8 for ; Fri, 11 Jan 2013 09:57:54 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B6C0F9F; Fri, 11 Jan 2013 18:57:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 603749E; Fri, 11 Jan 2013 18:57:53 +0100 (CET) Date: Fri, 11 Jan 2013 18:57:53 +0100 (CET) From: Mikael Abrahamsson To: Arturo Servin In-Reply-To: <50F031EE.2080606@gmail.com> Message-ID: References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> <50F031EE.2080606@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: sidr@ietf.org Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 17:57:56 -0000 On Fri, 11 Jan 2013, Arturo Servin wrote: > Mikael, > > Do you think that > http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 covers your > concerns? I don't understand enough, but this document isn't even close when it comes to giving hands-on operational advice. What I am talking about is: https://www.ripe.net/lir-services/training/courses/rr but for people actually maintaining the operational infrastructure. Perhaps advice should be to just purchase complete solution from vendor instead of trying to run all the components oneself. At least there should be overview of the framework, flow diagrams etc, to make people more easily understand what's going on. > If not, do you recommend to add text to this draft or to focus in > a new document describing the operation of a CA? I think a new document would be good. I also feel that there needs to be advice for a few different deployment scenarios, where one is minimal (you give information to RIR, they handle most of that end, the only thing you focus on is the route validation for receiving BGP prefixes, how can this be achieved with least amount of effort) to those who want to automate everything and sign themselves (running a CA). So basically a HOWTO... -- Mikael Abrahamsson email: swmike@swm.pp.se From aservin@lacnic.net Fri Jan 11 10:10:04 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D6421F894E for ; Fri, 11 Jan 2013 10:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mswJ7--mJQ+J for ; Fri, 11 Jan 2013 10:10:02 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB6521F892A for ; Fri, 11 Jan 2013 10:10:02 -0800 (PST) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:a4a3:1474:13c7:b7a0]) by mail.lacnic.net.uy (Postfix) with ESMTP id 6EDB9308445 for ; Fri, 11 Jan 2013 16:09:44 -0200 (UYST) Message-ID: <50F0556A.3020605@lacnic.net> Date: Fri, 11 Jan 2013 16:09:46 -0200 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: sidr@ietf.org References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> <50F031EE.2080606@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 18:10:04 -0000 Mikael, I have thinking about a how-to document, however, would be the IETF a place to publish something like that? *NOGs document seems more appropiate to me. Regards, as On 11/01/2013 15:57, Mikael Abrahamsson wrote: > On Fri, 11 Jan 2013, Arturo Servin wrote: > >> Mikael, >> >> Do you think that >> http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19 covers your >> concerns? > > I don't understand enough, but this document isn't even close when it > comes to giving hands-on operational advice. > > What I am talking about is: > > https://www.ripe.net/lir-services/training/courses/rr > > but for people actually maintaining the operational infrastructure. > Perhaps advice should be to just purchase complete solution from vendor > instead of trying to run all the components oneself. At least there > should be overview of the framework, flow diagrams etc, to make people > more easily understand what's going on. > >> If not, do you recommend to add text to this draft or to focus in >> a new document describing the operation of a CA? > > I think a new document would be good. I also feel that there needs to be > advice for a few different deployment scenarios, where one is minimal > (you give information to RIR, they handle most of that end, the only > thing you focus on is the route validation for receiving BGP prefixes, > how can this be achieved with least amount of effort) to those who want > to automate everything and sign themselves (running a CA). > > So basically a HOWTO... > From sm@resistor.net Fri Jan 11 11:26:39 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092E621F8A6F for ; Fri, 11 Jan 2013 11:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXbohiH1tczi for ; Fri, 11 Jan 2013 11:26:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 154A021F87E1 for ; Fri, 11 Jan 2013 11:26:37 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0BJQTUZ027525; Fri, 11 Jan 2013 11:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357932394; bh=kuEhum++xfMSA/KPSHMYMqpbygmvazJVU8l+a0tRNBg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xdBFo1GjOQKx34PfejmCx5VM9pbh28AcAKtv60mQlv7BkT2gjCR55wOgY/z9PO87J KoJSvnF2unTnADmkt4j961wccyY0AF9UOTJP+HAvmxLMwfT/akRkvclO9oa2FhjU3B fCe1HECzEo/OrW30T5wwW9CxGrof22wJTzz2xrsA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357932394; i=@resistor.net; bh=kuEhum++xfMSA/KPSHMYMqpbygmvazJVU8l+a0tRNBg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kkVjvTlBoPyypRHkkzCsaHLUf384JiKEs/XlOl06nKtAlAtcZ4XybzjKrQHl2rGjv xukyslqX+QtytAd53oS0E8G9TGOW6c6vj6mlkBFEzUWnS/JZclEiSB2DbnIkMDIglK 53UA8KEGchO8wialJPaxPsOnzDbeFqFl5xLbh0bM= Message-Id: <6.2.5.6.2.20130111073649.0aa0bb08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Jan 2013 08:58:59 -0800 To: Mikael Abrahamsson From: SM In-Reply-To: References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sidr@ietf.org Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 19:26:39 -0000 Hi Mikael, At 03:12 11-01-2013, Mikael Abrahamsson wrote: >Some of the failure scenarios I have heard from the dns TLD world: > >Zone file was truncated due to lack of disk space. Insufficient >checks was in place to notice the truncated zone file before it was >replicated out to the public-facing DNS infrastructure, thus causing outage. I heard of that. It's overlooked as it is a detail that's only important when things go wrong. >DNSSEC failure (don't remember the exact details), ie not everything >was correctly signed, thus causing failure. DNSSEC is an example of >a protocol which is quite brittle operationally. You make one >mistake, and your entire domain is toast. Yes. >So when implementing RPKI at the RIR level, there should be >operational advice how everything should be done. Preferrably even >at the protocol level, there should be a disaster "off" button which >the publisher can use to just switch off all validation for all >records they handle, and this should be propagated very quickly. There was a thread on this mailing list about propagation. There is a level of operational advice which a document does not get into as it cannot cover everything. You seem to be asking about failures by entities outside your control and an "off" switch to avoid it from affecting your organization. draft-ietf-sidr-bgpsec-threats-03 doesn't get into that. >Frankly, I'm scared when I read the documentation for this (=SIDR) >thing. I feel it fails the "KISS" test with all the CA, signing, >propagation infrastructure needed. It's also quite different from >anything else that the normal network engineer is exposed to >historically in their day to day work life. It's my opinion that a >lot of careful though put into how this is actually implemented in >real life, making sure there are operational tools (I still have not >signed my private domain with DNSSEC because the operational tools >are too hard to use) in place to aid deployment. There's a steep learning curve. Taken as a whole the documentation fails the "KISS" test. I agree that it is necessary to give a lot of careful thought about how this is actually implemented. >Is it too early in the protocol development process to start looking >into the operational aspects? I don't have an opinion about this. Regards, -sm From swmike@swm.pp.se Fri Jan 11 12:35:53 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1A21F8A08 for ; Fri, 11 Jan 2013 12:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIbg-A3jO8uN for ; Fri, 11 Jan 2013 12:35:53 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 490CD21F89FD for ; Fri, 11 Jan 2013 12:35:52 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 406549C; Fri, 11 Jan 2013 21:35:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3906D9A; Fri, 11 Jan 2013 21:35:51 +0100 (CET) Date: Fri, 11 Jan 2013 21:35:51 +0100 (CET) From: Mikael Abrahamsson To: SM In-Reply-To: <6.2.5.6.2.20130111073649.0aa0bb08@resistor.net> Message-ID: References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> <6.2.5.6.2.20130111073649.0aa0bb08@resistor.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: sidr@ietf.org Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:35:54 -0000 On Fri, 11 Jan 2013, SM wrote: > You seem to be asking about failures by entities outside your control > and an "off" switch to avoid it from affecting your organization. > draft-ietf-sidr-bgpsec-threats-03 doesn't get into that. Well, both for me and for the other organisation. If they find out their information is corrupt and they don't know exactly how to fix it quickly, they should be able to send out something that recursively just turns off all filtering based on their entire information set. What's important to realise is that the current state of affairs is that major outages are caused very rarely by fat-fingering or intentional disrupting the global BGP system. Getting origin verification is an extreme complication of this system that potentially can cause a lot more outages than the ones caused by not having it. I still think origin verification is important and I want to have it, but it needs to be robust (as a complete system). A lot can be fixed by operational procedures (=money and time), but I really hope extra care is put into the design of it as well, to make it operationally more robust and easier to use. Also recommendations on what needs to be done over time to keep it running would be good. Then I agree that actual operational procedures are probably best produced on the NOG and RIR level, but input from the designers would probably help here. -- Mikael Abrahamsson email: swmike@swm.pp.se From sm@resistor.net Fri Jan 11 14:44:48 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABB721F8933 for ; Fri, 11 Jan 2013 14:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-FNqP15Lsvf for ; Fri, 11 Jan 2013 14:44:48 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D4021F8460 for ; Fri, 11 Jan 2013 14:44:47 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r0BMibES004367; Fri, 11 Jan 2013 14:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357944282; bh=gzIAhWDusFWnOktk7yq95wdvnmuW9EDlVivdYqmuikU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xS44Vre06s6qrp6iKRhrLDdQwfWZU+2dgN3OgfiToo7cfipXIGpROqtkwoYXwr3Fg SbMb/LMhQIxu6RLjoCC3crcd+VamQ0HZoLJr/kqZ5W01rYpejP0Hk9Dmg1+RZbvCv/ 6OoGhTVyk+h9xvhsNNb5ud30CI1qwYxnZnK1fCvk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357944282; i=@resistor.net; bh=gzIAhWDusFWnOktk7yq95wdvnmuW9EDlVivdYqmuikU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WK8G9v8xERkMnfX1W1zxC/wXaHZNgIe1Z0bAjfnmUbyuo8G0Izv+/ixemRDNufD2M c3S6Rpw3JAfWtsuQvKW8Trk1ZQxtJe/GYfDKIQzxEXnmYqtNgiwBAzdJN9NmFrk2zm whVHj+sDsTPxyf9BRzqhE9NuNbWtZmfEh2lX4oxU= Message-Id: <6.2.5.6.2.20130111142418.0ab753a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 11 Jan 2013 14:39:45 -0800 To: Arturo Servin From: SM In-Reply-To: <50F0556A.3020605@lacnic.net> References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> <50F031EE.2080606@gmail.com> <50F0556A.3020605@lacnic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sidr@ietf.org Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 22:44:48 -0000 Hi Arturo, At 10:09 11-01-2013, Arturo Servin wrote: > I have thinking about a how-to document, however, would be the IETF a >place to publish something like that? I don't think that the IETF publishes how-to documents as RFCs. Regards, -sm From joelja@bogus.com Fri Jan 11 15:15:56 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722F121F8A54 for ; Fri, 11 Jan 2013 15:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oLyKtrC5mkA for ; Fri, 11 Jan 2013 15:15:55 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB2D21F88FB for ; Fri, 11 Jan 2013 15:15:55 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-24-5-127-59.hsd1.ca.comcast.net [24.5.127.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r0BNFrYa001607 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 11 Jan 2013 23:15:53 GMT (envelope-from joelja@bogus.com) Message-ID: <50F09D23.3070304@bogus.com> Date: Fri, 11 Jan 2013 15:15:47 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20130111020335.0a9d86a0@resistor.net> <50F031EE.2080606@gmail.com> <50F0556A.3020605@lacnic.net> <6.2.5.6.2.20130111142418.0ab753a8@resistor.net> In-Reply-To: <6.2.5.6.2.20130111142418.0ab753a8@resistor.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 11 Jan 2013 23:15:54 +0000 (UTC) Cc: sidr@ietf.org Subject: Re: [sidr] current state of BGP origin verification X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 23:15:56 -0000 On 1/11/13 14:39 , SM wrote: > Hi Arturo, > At 10:09 11-01-2013, Arturo Servin wrote: >> I have thinking about a how-to document, however, would be the >> IETF a >> place to publish something like that? > > I don't think that the IETF publishes how-to documents as RFCs. if you're thinking something alough the lines of rfc-5635 then certainly they do. Origin validation for dummies would be published by IDG however. > Regards, > -sm > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Mon Jan 14 11:35:10 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91A321F8B4A; Mon, 14 Jan 2013 11:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrSy776U5SiR; Mon, 14 Jan 2013 11:35:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124BC21F8835; Mon, 14 Jan 2013 11:35:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114193509.1471.50956.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 11:35:09 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-usecases-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:35:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Use Cases and Interpretation of RPKI Objects for Issuers= and Relying Parties Author(s) : Terry Manderson Kotikalapudi Sriram Russ White Filename : draft-ietf-sidr-usecases-06.txt Pages : 32 Date : 2013-01-14 Abstract: This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI)object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-usecases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-usecases-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-usecases-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kotikalapudi.sriram@nist.gov Mon Jan 14 12:34:13 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65AC21F8B6C for ; Mon, 14 Jan 2013 12:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3xW5UHbCdvd for ; Mon, 14 Jan 2013 12:34:13 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2193821F8B64 for ; Mon, 14 Jan 2013 12:34:13 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 14 Jan 2013 15:33:56 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 14 Jan 2013 15:34:05 -0500 From: "Sriram, Kotikalapudi" To: "sidr wg list (sidr@ietf.org)" Date: Mon, 14 Jan 2013 15:22:41 -0500 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-06.txt Thread-Index: Ac3yjkeweF5fbME2TA+YYyyGNyxX2gABAgdA Message-ID: References: <20130114193509.1471.50956.idtracker@ietfa.amsl.com> In-Reply-To: <20130114193509.1471.50956.idtracker@ietfa.amsl.com> 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" MIME-Version: 1.0 Subject: [sidr] FW: I-D Action: draft-ietf-sidr-usecases-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:34:14 -0000 This revised version incorporates changes based on comments from IESG and Gen ART reviews. The authors wish to thank the reviewers for their careful review and very helpful comments. Sriram -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, January 14, 2013 2:35 PM To: i-d-announce@ietf.org Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-usecases-06.txt 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 : Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties Author(s) : Terry Manderson Kotikalapudi Sriram Russ White Filename : draft-ietf-sidr-usecases-06.txt Pages : 32 Date : 2013-01-14 Abstract: This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI)object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-usecases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-usecases-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-usecases-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rogaglia@cisco.com Tue Jan 15 03:53:27 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9048621F8792; Tue, 15 Jan 2013 03:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttBljIKUQxig; Tue, 15 Jan 2013 03:53:20 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0A82221F8786; Tue, 15 Jan 2013 03:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16788; q=dns/txt; s=iport; t=1358250798; x=1359460398; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=N3j4MGqJYbXFT2ruHJfxTkbsuHLpXaU3+k+B7ZNKgdc=; b=ItiZBDFvvd5IFG9VdRfQUz0zXmy0bExWaWcORiz2sh4+NYFCCXEnHMU4 6PBoxzqlw+6Sl2ZyEfcBjNnOcwgFaP0elauPoLFaqH3M1Twr5ZUCSsipu wA/CCTN4sW0qzw0MXJ+JtfF1rzDW7/IBCHN+YtmDi5RrMV1Ivh2B4DxFv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAKBC9VCtJXG9/2dsb2JhbABFujuDRxZzgh4BAQEDAQEBASQTNAQMBwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIiAsGDKgwjkwEjHUUg05hA5JZk3yCdYFmAgcXAgQY X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208";a="162534564" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jan 2013 11:53:17 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0FBrHr6015032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 11:53:17 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.7]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 05:53:17 -0600 From: "Roque Gagliano (rogaglia)" To: "gen-art@ietf.org" , "sidr@ietf.org" Thread-Topic: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 Thread-Index: AQHN7Pi5+smgNyB5VUaCZdHrAxAE8JhKuHGA Date: Tue, 15 Jan 2013 11:53:16 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <50E1E8D0.5010204@bbn.com> <8D3D17ACE214DC429325B2B98F3AE71287DB217C@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287DB29CE@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287DB2A22@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.57] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-09 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:53:27 -0000 dear WG/Gen-Art,=20 David and I discussed the new text that will improve this description to co= mplete the GenArt review.=20 Text to be added to section 4: "The following figure shows an example of the structure of signed objects i= n the repository, indicating the algorithm suites in use, and showing the r= elationships between three CAs (X, Y, and Z) that form a certification chai= n. Vertical alignment in the figure indicates objects signed by the same CA= using the same private key. The differences in horizontal indentation also= represent use of different publication points for objects signed by differ= ent CAs. The characters "|->" are used for visualization purposes for both = the signing relationship and the publication point change. For example, the= objects CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A and= CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key= corresponding to CA-X-Certificate-Algorithm- Suite-A and published at CA X= 's corresponding publication point." You will get a new version notification in your inbox. Roque On Jan 8, 2013, at 12:02 PM, Roque Gagliano (rogaglia) = wrote: > Hi David, >=20 > I got your point. >=20 > What about this text for that paragraph? >=20 > "The following figure illustrates the format used to describe signed obje= cts in the repository. It reflects the algorithm suites in use, and shows t= he relationship between three CAs (X, Y, and Z) that form a certificate cha= in. The vertical alignment in the figure distinguishes between objects sign= ed by the same CA using the same private key. The vertical alignment also r= epresents the composition of the different publication points as a componen= t of the RPKI repository. The characters "|->" are used for visualization p= urpose. As an example taken from the figure, the objects CA-Y-Certificate-A= lgorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A and CA-X-Signed-Objects-Algor= ithm-Suite-A are all signed using the private key corresponding to CA-X-Cer= tificate-Algorithm-Suite-A and published at that CA correspondent publicati= on point." >=20 > Roque >=20 > On Jan 7, 2013, at 7:53 PM, "Black, David" wrote: >=20 >> Hi Roque, >>=20 >>> "The vertical alignment in the figure distinguishes between the differe= nt >>> publication points and the characters '|->' are used for visualization >>> purpose." >>=20 >> I think there's more going on than just publication point change. >>=20 >> Here's the entire figure, plus the one existing sentence about >> the '|->' notation: >>=20 >> CA X-Certificate-Algorithm-Suite-A (Cert-XA) >> | >> |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA) >> |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA) >> |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA) >> |-> CA-Z-Signed-Objects-Algorithm-Suite-A >> |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA) >> |-> CA-Y-Signed-Objects-Algorithm-Suite-A >> |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA) >> |-> CA-X-Signed-Objects-Algorithm-Suite-A >>=20 >> Note: Cert-XA represent the certificate for CA X, that is signed >> using the algorithm suite A. >>=20 >> I believe that the private key corresponding to Cert-XA is used to sign >> Cert-YA, e.g., so that Cert-XA is involved in the path validation of >> Cert-YA. It looks like that's part of the relationship represented by >> '|->' and (if so) I would like to see a statement to that effect in >> addition to your proposed text about different publication points. >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] >>> Sent: Monday, January 07, 2013 12:52 PM >>> To: Black, David >>> Cc: Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; gen-art@ietf.= org; >>> sidr@ietf.org; Stewart Bryant (stbryant) >>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>=20 >>> Hi David, >>>=20 >>> On Jan 7, 2013, at 6:16 PM, "Black, David" wrote: >>>=20 >>>> Roque, >>>>=20 >>>> That new version looks good. Could you also take a look at this edito= rial >>>> suggestion that Steve deferred to you?: >>>>=20 >>>=20 >>> Ok, sorry about that. >>>=20 >>>> Starting near the end of section 4.3, the three characters >>>> |-> are used in figures to represent an RPKI hierarchy relationship; >>>> that relationship should be defined and/or explained before it is used= . >>>=20 >>> The idea in the different figures is that the vertical alignment >>> differentiates the different publication points. >>>=20 >>> What about adding the following text? >>>=20 >>> "The vertical alignment in the figure distinguishes between the differe= nt >>> publication points and the characters '|->' are used for visualization >>> purpose." >>>=20 >>>=20 >>>> For clarity, I'd suggest swapping the order of the two paragraphs >>>> above that figure in 4.3 and making the following change at the end >>>> of the paragraph that is moved down (addition of the word >>>> "certificate" is the important change): >>>=20 >>> All done and thanks. >>>=20 >>> Roque >>>=20 >>>> OLD >>>> and shows the relationship between three CAs (X, Y, and Z) that form >>>> a chain. >>>> NEW >>>> and shows the relationships among the three CAs (X, Y, and Z) >>>> that participate in a certificate chain. >>>>=20 >>>> Subsequent uses of |-> seemed clear to me. >>>>=20 >>>> Thanks, >>>> --David >>>>=20 >>>>> -----Original Message----- >>>>> From: Roque Gagliano (rogaglia) [mailto:rogaglia@cisco.com] >>>>> Sent: Monday, January 07, 2013 12:02 PM >>>>> To: Black, David >>>>> Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; gen-art@iet= f.org; >>>>> sidr@ietf.org; Stewart Bryant (stbryant) >>>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>>>=20 >>>>> David, >>>>>=20 >>>>> I just published version 10 of the document with all the agreed chang= es. >>>>> Thanks again for your review. >>>>>=20 >>>>> Roque >>>>>=20 >>>>>=20 >>>>> On Dec 31, 2012, at 8:57 PM, "Black, David" wro= te: >>>>>=20 >>>>>> Steve, >>>>>>=20 >>>>>> This all looks good; thanks for the quick response. >>>>>>=20 >>>>>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (= A, B >>>>>>>> and C) from prior sections. >>>>>>=20 >>>>>>> I have deleted all references to Alg Suite C throughout the doc, an= d >>>>>>> revised the text accordingly. >>>>>>=20 >>>>>> Magnificent - that'll be a significant improvement. >>>>>>=20 >>>>>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>>>>> (future tense) in the milestone and phase descriptions. All of >>>>>>>> these uses of "will be" should be reviewed to determine whether >>>>>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>>>>> this sentence in 4.3.1: >>>>>>>>=20 >>>>>>>> Additionally, the new algorithm transition timeline document will = be >>>>>>>> published with the following information: >>>>>>=20 >>>>>>> I agree that "will be" needs to be changed to "MUST be" in a few pl= aces, >>>>>>> starting on page 5 (Section 2) where the need to update the CP and = to >>>>> publish an >>>>>>> alg transition timetable are first mentioned. An examination of the= rest >>> of >>>>> the >>>>>>> doc shows that this change need be applied only when the alg transi= tion >>> doc >>>>> is >>>>>>> mentioned. >>>>>>=20 >>>>>> That sounds reasonable. >>>>>>=20 >>>>>>>> Section 3 Definitions: Is there any concern about possible >>>>>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>>>>>=20 >>>>>>> We defined what "Suite B" is in the terminology section, so I >>>>>>> think no further clarification is required here. >>>>>>=20 >>>>>> That's ok with me, but I thought it was worth asking. >>>>>>=20 >>>>>> Thanks, >>>>>> --David >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Stephen Kent [mailto:kent@bbn.com] >>>>>>> Sent: Monday, December 31, 2012 2:35 PM >>>>>>> To: Black, David >>>>>>> Cc: rogaglia@cisco.com; Sean Turner; gen-art@ietf.org; sidr@ietf.or= g; >>>>> Stewart >>>>>>> Bryant >>>>>>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>>>>>>=20 >>>>>>> David, >>>>>>>=20 >>>>>>>> The draft is generally well-written and clear, but has an unfortun= ate >>>>>>>> nomenclature change problem that is the primary open issue[*]. >>>>>>>>=20 >>>>>>>> Major issues: >>>>>>>>=20 >>>>>>>> [*] Section 4.7 changes the meaning of the algorithm suite names (= A, B >>>>>>>> and C) from prior sections. >>>>>>>=20 >>>>>>> I have deleted all references to Alg Suite C throughout the doc, an= d >>>>>>> revised the text accordingly. >>>>>>>=20 >>>>>>>> This also affects Sections 6 and 7. >>>>>>>> I have classified this as a major issue as I believe it introduces >>>>>>>> severe lack of clarity (and potential ambiguity) into the followin= g >>>>>>>> two paragraphs in Section 7: >>>>>>>>=20 >>>>>>>> During Phase 1, a CA that revokes a certificate under Suite A SHOU= LD >>>>>>>> revoke the corresponding certificate under Suite B, if that >>>>>>>> certificate exists. During Phase 4, a CA that revokes a certifica= te >>>>>>>> under Suite A SHOULD revoke the corresponding certificate under Su= ite >>>>>>>> C, if that certificate exists. >>>>>>>>=20 >>>>>>>> During Phase 1, a CA may revoke certificates under Suite B without >>>>>>>> revoking them under Suite A, since the Suite B products are for te= st >>>>>>>> purposes. During Phase 4 a CA may revoke certificates issued unde= r >>>>>>>> Suite C without revoking them under Suite A, since Suite C product= s >>>>>>>> are being deprecated. >>>>>>> fixed. >>>>>>>> Despite the use of three letters (A, B and C), there are only two >>>>>>>> algorithm suites involved, and different instances of Suite A refe= r to >>>>>>>> different algorithm suites. In each paragraph, the first instance = of >>>>>>>> "Suite A" refers to the same algorithm suite as "Suite C", and the >>>>>>>> second instance of "Suite A" refers to the same algorithm suite >>>>>>>> as "Suite B". >>>>>>>>=20 >>>>>>>> It would be much better and clearer to not change the meaning of t= he >>>>>>>> algorithm suite names until the EOL date. In addition, this change >>>>>>>> should enable removal of the Suite C concept from this draft. >>>>>>> fixed >>>>>>>> I >>>>>>>> strongly recommend removing the Suite C concept, as the C-A-B >>>>>>>> chronological order of suite introduction dates seems counter-intu= itive. >>>>>>> Done. >>>>>>>>=20 >>>>>>>> Minor issues: >>>>>>>>=20 >>>>>>>> Starting in Section 4.3.1, there are a number of uses of "will be" >>>>>>>> (future tense) in the milestone and phase descriptions. All of >>>>>>>> these uses of "will be" should be reviewed to determine whether >>>>>>>> "MUST be" is appropriate, e.g., as appears to be the case for >>>>>>>> this sentence in 4.3.1: >>>>>>>>=20 >>>>>>>> Additionally, the new algorithm transition timeline document will = be >>>>>>>> published with the following information: >>>>>>> I agree that "will be" needs to be changed to "MUST be" in a few pl= aces, >>>>>>> starting on page 5 (Section 2) where the need to update the CP and = to >>>>>>> publish an >>>>>>> alg transition timetable are first mentioned. An examination of the= rest >>>>>>> of the >>>>>>> doc shows that this change need be applied only when the alg transi= tion >>>>>>> doc is >>>>>>> mentioned. >>>>>>>> When "MUST be" is not appropriate, present tense (i.e., "is") is >>>>>>>> preferable. >>>>>>> fixed. >>>>>>>>=20 >>>>>>>> Nits/editorial: >>>>>>>>=20 >>>>>>>> Abstract: The following two sentences don't quite line up: >>>>>>>>=20 >>>>>>>> The process >>>>>>>> is expected to be completed in a time scale of months or years. >>>>>>>> Consequently, no emergency transition is specified. >>>>>>>>=20 >>>>>>>> Also, section 4.2 indicates that a multi-year transition timeframe >>>>>>>> is expected, which suggests that "months" is not appropriate in >>>>>>>> the abstract. Suggested rephrasing: >>>>>>>>=20 >>>>>>>> The time available to complete the transition process >>>>>>>> is expected to be several years. >>>>>>>> Consequently, no emergency transition process is specified. >>>>>>> fixed. >>>>>>>> Section 2. Introduction: The first sentence in the last paragraph >>>>>>>> mentions a forthcoming BCP on transition timetable. The rest of >>>>>>>> that paragraph implies that the BCP is for a single transition, as >>>>>>>> opposed to being a BCP for transitions in general. It would be >>>>>>>> helpful to clarify that at the start of the paragraph, e.g., >>>>>>>> by adding "For each algorithm transition," to the start of the >>>>>>>> paragraph. >>>>>>> fixed. >>>>>>>> Section 3 Definitions: Is there any concern about possible >>>>>>>> confusion of the use of "Suite B" in this draft with NSA Suite B? >>>>>>>> The draft is clear on what Suite B means for RPKI, but I suspect >>>>>>>> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>>>>>> We defined what "Suite B" is in the terminology section, so I >>>>>>> think no further clarification is required here. >>>>>>>> Describing Phase 0 as both the steady state of the RPKI and the fi= rst >>>>>>>> phase of transition is confusing (e.g., in 4.3). It would be clea= rer >>>>>>>> if Phase 0 began with publication of the updated RPKI algorithm >>>>>>>> document (Milestone 1) and that the activities that are unchanged >>>>>>>> from steady state were described as not changing in phase 0. >>>>>>> we need to be able to refer to steady state, separate from the >>>>>>> first milestone in the transition process, but I agree that referri= ng to >>>>>>> it as the first phase of the transition process is confusing. I hav= e >>>>>>> changed the text accordingly. >>>>>>>> Starting near the end of section 4.3, the three characters >>>>>>>> |-> are used in figures to represent an RPKI hierarchy relationshi= p; >>>>>>>> that relationship should be defined and/or explained before it is = used. >>>>>>>> For clarity, I'd suggest swapping the order of the two paragraphs >>>>>>>> above that figure in 4.3 and making the following change at the en= d >>>>>>>> of the paragraph that is moved down (addition of the word >>>>>>>> "certificate" is the important change): >>>>>>>>=20 >>>>>>>> OLD >>>>>>>> and shows the relationship between three CAs (X, Y, and Z) that fo= rm >>>>>>>> a chain. >>>>>>>> NEW >>>>>>>> and shows the relationships among the three CAs (X, Y, and Z) >>>>>>>> that participate in a certificate chain. >>>>>>>>=20 >>>>>>>> Subsequent uses of |-> seemed clear to me. >>>>>>> I'll defer to Roque here, as the repository representation is his d= esign. >>>>>>>> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at >>>>>>>> independent publication points, but does not make it clear that th= is >>>>>>>> recommendation applies beyond phase 2. I suggest adding text to >>>>>>>> make that clear - a reference to Section 9 (which is clear about >>>>>>>> this) may be useful as part of that text. >>>>>>> I have added a forward pointer to Section 9 here. >>>>>>>> In Section 6, please expand the ROA acronym on first use and consi= der >>>>>>>> whether it should be defined in Section 3. I'm also assuming that= the >>>>>>>> ASN acronym is intended to refer to ASN.1 content; if not, that >>>>>>>> acronym also needs attention. >>>>>>> ASN =3D Autonomous System Number. I expended the acronym as it appe= ars >>>>>>> only here. I added a ROA definition to Section 3. >>>>>>>> idnits 2.12.13 found a couple of minor nits: >>>>>>>>=20 >>>>>>>> ** There is 1 instance of too long lines in the document, the long= est >>>>> one >>>>>>>> being 23 characters in excess of 72. >>>>>>> I'll let Roque address this issue. >>>>>>>>=20 >>>>>>>> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 = keyword, >>>>>>> but >>>>>>>> does not include the phrase in its RFC 2119 key words list. >>>>>>> fixed. >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Tue Jan 15 03:56:09 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5821F883B; Tue, 15 Jan 2013 03:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRwgvKkYEbkv; Tue, 15 Jan 2013 03:56:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C521F87D2; Tue, 15 Jan 2013 03:56:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115115609.28871.56877.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 03:56:09 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 11:56:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-11.txt Pages : 31 Date : 2013-01-15 Abstract: This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-algorithm-agility-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.black@emc.com Wed Jan 16 21:38:42 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41C111E80A3; Wed, 16 Jan 2013 21:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImaQdUdld8VJ; Wed, 16 Jan 2013 21:38:41 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DCB9411E809B; Wed, 16 Jan 2013 21:38:40 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0H5cXUl027237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 00:38:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 17 Jan 2013 00:38:23 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0H5cMj2016679; Thu, 17 Jan 2013 00:38:22 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 17 Jan 2013 00:38:22 -0500 From: "Black, David" To: "rogaglia@cisco.com" , Stephen Kent , Sean Turner , "gen-art@ietf.org" Date: Thu, 17 Jan 2013 00:38:20 -0500 Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-11 Thread-Index: Ac3lOYUa+SMuJHJqQnWqMAKs4+qaRgPOumQw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287E873CF@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "Black, David" , "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 05:38:42 -0000 The -11 version of this draft resolves all of the concerns raised by the Gen-ART review of the -09 version. I want to thank the authors for the timely and productive manner in which the review's concerns were addressed. idnits 2.12.13 found a minor line length problem that can be left to the RFC Editor to correct. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, December 28, 2012 3:26 PM > To: rogaglia@cisco.com; Stephen Kent; Sean Turner; gen-art@ietf.org > Cc: Black, David; sidr@ietf.org; Stewart Bryant > Subject: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-sidr-algorithm-agility-09 > Reviewer: David L. Black > Review Date: December 28, 2012 > IETF LC End Date: December 14, 2012 >=20 > Summary: >=20 > This draft is on the right track but has open issues, described in the re= view. >=20 > I apologize for the tardy arrival of this review after the end of IETF La= st > Call for this draft - the last few months have been a rather busy time fo= r me. >=20 > This draft specifies the algorithm transition process for RPKI, which > entails coordinated issuance of new certificates and other signed product= s > across the collection of RPKI CAs in a fashion that ensures that at least > one set of signed products is usable at all times. >=20 > The draft is generally well-written and clear, but has an unfortunate > nomenclature change problem that is the primary open issue[*]. >=20 > Major issues: >=20 > [*] Section 4.7 changes the meaning of the algorithm suite names (A, B > and C) from prior sections. This also affects Sections 6 and 7. > I have classified this as a major issue as I believe it introduces > severe lack of clarity (and potential ambiguity) into the following > two paragraphs in Section 7: >=20 > During Phase 1, a CA that revokes a certificate under Suite A SHOULD > revoke the corresponding certificate under Suite B, if that > certificate exists. During Phase 4, a CA that revokes a certificate > under Suite A SHOULD revoke the corresponding certificate under Suite > C, if that certificate exists. >=20 > During Phase 1, a CA may revoke certificates under Suite B without > revoking them under Suite A, since the Suite B products are for test > purposes. During Phase 4 a CA may revoke certificates issued under > Suite C without revoking them under Suite A, since Suite C products > are being deprecated. >=20 > Despite the use of three letters (A, B and C), there are only two > algorithm suites involved, and different instances of Suite A refer to > different algorithm suites. In each paragraph, the first instance of > "Suite A" refers to the same algorithm suite as "Suite C", and the > second instance of "Suite A" refers to the same algorithm suite > as "Suite B". >=20 > It would be much better and clearer to not change the meaning of the > algorithm suite names until the EOL date. In addition, this change > should enable removal of the Suite C concept from this draft. I > strongly recommend removing the Suite C concept, as the C-A-B > chronological order of suite introduction dates seems counter-intuitive. >=20 > Minor issues: >=20 > Starting in Section 4.3.1, there are a number of uses of "will be" > (future tense) in the milestone and phase descriptions. All of > these uses of "will be" should be reviewed to determine whether > "MUST be" is appropriate, e.g., as appears to be the case for > this sentence in 4.3.1: >=20 > Additionally, the new algorithm transition timeline document will be > published with the following information: >=20 > When "MUST be" is not appropriate, present tense (i.e., "is") is > preferable. >=20 > Nits/editorial: >=20 > Abstract: The following two sentences don't quite line up: >=20 > The process > is expected to be completed in a time scale of months or years. > Consequently, no emergency transition is specified. >=20 > Also, section 4.2 indicates that a multi-year transition timeframe > is expected, which suggests that "months" is not appropriate in > the abstract. Suggested rephrasing: >=20 > The time available to complete the transition process > is expected to be several years. > Consequently, no emergency transition process is specified. >=20 > Section 2. Introduction: The first sentence in the last paragraph > mentions a forthcoming BCP on transition timetable. The rest of > that paragraph implies that the BCP is for a single transition, as > opposed to being a BCP for transitions in general. It would be > helpful to clarify that at the start of the paragraph, e.g., > by adding "For each algorithm transition," to the start of the > paragraph. >=20 > Section 3 Definitions: Is there any concern about possible > confusion of the use of "Suite B" in this draft with NSA Suite B? > The draft is clear on what Suite B means for RPKI, but I suspect > that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >=20 > Describing Phase 0 as both the steady state of the RPKI and the first > phase of transition is confusing (e.g., in 4.3). It would be clearer > if Phase 0 began with publication of the updated RPKI algorithm > document (Milestone 1) and that the activities that are unchanged > from steady state were described as not changing in phase 0. >=20 > Starting near the end of section 4.3, the three characters > |-> are used in figures to represent an RPKI hierarchy relationship; > that relationship should be defined and/or explained before it is used. > For clarity, I'd suggest swapping the order of the two paragraphs > above that figure in 4.3 and making the following change at the end > of the paragraph that is moved down (addition of the word > "certificate" is the important change): >=20 > OLD > and shows the relationship between three CAs (X, Y, and Z) that form > a chain. > NEW > and shows the relationships among the three CAs (X, Y, and Z) > that participate in a certificate chain. >=20 > Subsequent uses of |-> seemed clear to me. >=20 > Section 4.5 Phase 2 says that Suite B product SHOULD be stored at > independent publication points, but does not make it clear that this > recommendation applies beyond phase 2. I suggest adding text to > make that clear - a reference to Section 9 (which is clear about > this) may be useful as part of that text. >=20 > In Section 6, please expand the ROA acronym on first use and consider > whether it should be defined in Section 3. I'm also assuming that the > ASN acronym is intended to refer to ASN.1 content; if not, that > acronym also needs attention. >=20 > idnits 2.12.13 found a couple of minor nits: >=20 > ** There is 1 instance of too long lines in the document, the longest o= ne > being 23 characters in excess of 72. >=20 > =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keywo= rd, but > does not include the phrase in its RFC 2119 key words list. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From rogaglia@cisco.com Thu Jan 17 00:49:15 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7C821F88B2; Thu, 17 Jan 2013 00:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.099 X-Spam-Level: X-Spam-Status: No, score=-12.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux79EWXd8UAG; Thu, 17 Jan 2013 00:49:14 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21621F88B1; Thu, 17 Jan 2013 00:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8148; q=dns/txt; s=iport; t=1358412554; x=1359622154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zc78Sx89Fqu4gRQkYfAdlfAEtIkCU4EkTz1pr+xzyKc=; b=SiL+PMVVzjOQkVMsMjmqNZ5OYqjv1h5LoVnM3eQjrMqwEF4P5z1TPEvO UGRZrCT7Bl6h6I2xptmLWvQnEmfz8zaqIXuhCIizgMRYBe5InW3TLtnqi 6JXieMDEe6AfHAwXUpr0+sK6jG2Qt1fg0Z5eGCSXDB+yUmO2a0qjOs+lr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHm591CtJXG8/2dsb2JhbABBA74dFnOCHgEBAQMBHQpLBwUHBAIBCBEDAQEBCyQyHQgCBA4FCIgLBgy5RIx1gRWCTWEDiCyKLYRPjy2CdYFmIhw X-IronPort-AV: E=Sophos;i="4.84,484,1355097600"; d="scan'208";a="163669484" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jan 2013 08:49:13 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0H8nDrR007559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jan 2013 08:49:13 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.7]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 17 Jan 2013 02:49:13 -0600 From: "Roque Gagliano (rogaglia)" To: "Black, David" Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-11 Thread-Index: AQHN9I+FMi1VHdNSWkquHGET+qZOdw== Date: Thu, 17 Jan 2013 08:49:12 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71287E873CF@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287E873CF@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.20.168] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gen-art@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 08:49:15 -0000 Thank YOU David for been such a great reviewer. I will solve the Idnits in my working version waiting for other comments du= ring IESG review. Regards, Roque On Jan 17, 2013, at 6:38 AM, "Black, David" wrote: > The -11 version of this draft resolves all of the concerns raised by the > Gen-ART review of the -09 version. I want to thank the authors for the > timely and productive manner in which the review's concerns were addresse= d. >=20 > idnits 2.12.13 found a minor line length problem that can be left to the > RFC Editor to correct. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Black, David >> Sent: Friday, December 28, 2012 3:26 PM >> To: rogaglia@cisco.com; Stephen Kent; Sean Turner; gen-art@ietf.org >> Cc: Black, David; sidr@ietf.org; Stewart Bryant >> Subject: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 >>=20 >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> . >>=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. >>=20 >> Document: draft-ietf-sidr-algorithm-agility-09 >> Reviewer: David L. Black >> Review Date: December 28, 2012 >> IETF LC End Date: December 14, 2012 >>=20 >> Summary: >>=20 >> This draft is on the right track but has open issues, described in the r= eview. >>=20 >> I apologize for the tardy arrival of this review after the end of IETF L= ast >> Call for this draft - the last few months have been a rather busy time f= or me. >>=20 >> This draft specifies the algorithm transition process for RPKI, which >> entails coordinated issuance of new certificates and other signed produc= ts >> across the collection of RPKI CAs in a fashion that ensures that at leas= t >> one set of signed products is usable at all times. >>=20 >> The draft is generally well-written and clear, but has an unfortunate >> nomenclature change problem that is the primary open issue[*]. >>=20 >> Major issues: >>=20 >> [*] Section 4.7 changes the meaning of the algorithm suite names (A, B >> and C) from prior sections. This also affects Sections 6 and 7. >> I have classified this as a major issue as I believe it introduces >> severe lack of clarity (and potential ambiguity) into the following >> two paragraphs in Section 7: >>=20 >> During Phase 1, a CA that revokes a certificate under Suite A SHOULD >> revoke the corresponding certificate under Suite B, if that >> certificate exists. During Phase 4, a CA that revokes a certificate >> under Suite A SHOULD revoke the corresponding certificate under Suite >> C, if that certificate exists. >>=20 >> During Phase 1, a CA may revoke certificates under Suite B without >> revoking them under Suite A, since the Suite B products are for test >> purposes. During Phase 4 a CA may revoke certificates issued under >> Suite C without revoking them under Suite A, since Suite C products >> are being deprecated. >>=20 >> Despite the use of three letters (A, B and C), there are only two >> algorithm suites involved, and different instances of Suite A refer to >> different algorithm suites. In each paragraph, the first instance of >> "Suite A" refers to the same algorithm suite as "Suite C", and the >> second instance of "Suite A" refers to the same algorithm suite >> as "Suite B". >>=20 >> It would be much better and clearer to not change the meaning of the >> algorithm suite names until the EOL date. In addition, this change >> should enable removal of the Suite C concept from this draft. I >> strongly recommend removing the Suite C concept, as the C-A-B >> chronological order of suite introduction dates seems counter-intuitive. >>=20 >> Minor issues: >>=20 >> Starting in Section 4.3.1, there are a number of uses of "will be" >> (future tense) in the milestone and phase descriptions. All of >> these uses of "will be" should be reviewed to determine whether >> "MUST be" is appropriate, e.g., as appears to be the case for >> this sentence in 4.3.1: >>=20 >> Additionally, the new algorithm transition timeline document will be >> published with the following information: >>=20 >> When "MUST be" is not appropriate, present tense (i.e., "is") is >> preferable. >>=20 >> Nits/editorial: >>=20 >> Abstract: The following two sentences don't quite line up: >>=20 >> The process >> is expected to be completed in a time scale of months or years. >> Consequently, no emergency transition is specified. >>=20 >> Also, section 4.2 indicates that a multi-year transition timeframe >> is expected, which suggests that "months" is not appropriate in >> the abstract. Suggested rephrasing: >>=20 >> The time available to complete the transition process >> is expected to be several years. >> Consequently, no emergency transition process is specified. >>=20 >> Section 2. Introduction: The first sentence in the last paragraph >> mentions a forthcoming BCP on transition timetable. The rest of >> that paragraph implies that the BCP is for a single transition, as >> opposed to being a BCP for transitions in general. It would be >> helpful to clarify that at the start of the paragraph, e.g., >> by adding "For each algorithm transition," to the start of the >> paragraph. >>=20 >> Section 3 Definitions: Is there any concern about possible >> confusion of the use of "Suite B" in this draft with NSA Suite B? >> The draft is clear on what Suite B means for RPKI, but I suspect >> that RPKI Suite B and NSA Suite B are unlikely to match, if ever. >>=20 >> Describing Phase 0 as both the steady state of the RPKI and the first >> phase of transition is confusing (e.g., in 4.3). It would be clearer >> if Phase 0 began with publication of the updated RPKI algorithm >> document (Milestone 1) and that the activities that are unchanged >> from steady state were described as not changing in phase 0. >>=20 >> Starting near the end of section 4.3, the three characters >> |-> are used in figures to represent an RPKI hierarchy relationship; >> that relationship should be defined and/or explained before it is used. >> For clarity, I'd suggest swapping the order of the two paragraphs >> above that figure in 4.3 and making the following change at the end >> of the paragraph that is moved down (addition of the word >> "certificate" is the important change): >>=20 >> OLD >> and shows the relationship between three CAs (X, Y, and Z) that form >> a chain. >> NEW >> and shows the relationships among the three CAs (X, Y, and Z) >> that participate in a certificate chain. >>=20 >> Subsequent uses of |-> seemed clear to me. >>=20 >> Section 4.5 Phase 2 says that Suite B product SHOULD be stored at >> independent publication points, but does not make it clear that this >> recommendation applies beyond phase 2. I suggest adding text to >> make that clear - a reference to Section 9 (which is clear about >> this) may be useful as part of that text. >>=20 >> In Section 6, please expand the ROA acronym on first use and consider >> whether it should be defined in Section 3. I'm also assuming that the >> ASN acronym is intended to refer to ASN.1 content; if not, that >> acronym also needs attention. >>=20 >> idnits 2.12.13 found a couple of minor nits: >>=20 >> ** There is 1 instance of too long lines in the document, the longest o= ne >> being 23 characters in excess of 72. >>=20 >> =3D=3D The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keywo= rd, but >> does not include the phrase in its RFC 2119 key words list. >>=20 >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >=20 From wwwrun@rfc-editor.org Thu Jan 17 11:39:01 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756DB21F88B0; Thu, 17 Jan 2013 11:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1Xc3gG0Owy2; Thu, 17 Jan 2013 11:38:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC621F885B; Thu, 17 Jan 2013 11:38:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 816FFB1E002; Thu, 17 Jan 2013 11:28:03 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130117192803.816FFB1E002@rfc-editor.org> Date: Thu, 17 Jan 2013 11:28:03 -0800 (PST) Cc: sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] RFC 6810 on The Resource Public Key Infrastructure (RPKI) to Router Protocol X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:39:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6810 Title: The Resource Public Key Infrastructure (RPKI) to Router Protocol Author: R. Bush, R. Austein Status: Standards Track Stream: IETF Date: January 2013 Mailbox: randy@psg.com, sra@hactrn.net Pages: 27 Characters: 59714 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidr-rpki-rtr-26.txt URL: http://www.rfc-editor.org/rfc/rfc6810.txt In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK] This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Thu Jan 17 11:39:17 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472321F88E3; Thu, 17 Jan 2013 11:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.041 X-Spam-Level: X-Spam-Status: No, score=-102.041 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5JVoVxulCJx; Thu, 17 Jan 2013 11:39:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9392A21F88E2; Thu, 17 Jan 2013 11:39:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D3AFDB1E002; Thu, 17 Jan 2013 11:28:20 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130117192820.D3AFDB1E002@rfc-editor.org> Date: Thu, 17 Jan 2013 11:28:20 -0800 (PST) Cc: sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] RFC 6811 on BGP Prefix Origin Validation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:39:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6811 Title: BGP Prefix Origin Validation Author: P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein Status: Standards Track Stream: IETF Date: January 2013 Mailbox: pmohapat@cisco.com, jgs@juniper.net, dward@cisco.com, randy@psg.com, sra@hactrn.net Pages: 10 Characters: 20082 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sidr-pfx-validate-10.txt URL: http://www.rfc-editor.org/rfc/rfc6811.txt To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK] This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Thu Jan 17 13:23:36 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746BC21F88BD; Thu, 17 Jan 2013 13:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcNZe+-SbFjY; Thu, 17 Jan 2013 13:23:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D636621F88A2; Thu, 17 Jan 2013 13:23:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2013 13:23:35 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:23:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Threat Model for BGP Path Security Author(s) : Stephen Kent Andrew Chi Filename : draft-ietf-sidr-bgpsec-threats-04.txt Pages : 26 Date : 2013-01-17 Abstract: This document describes a threat model for the context in which BGP path security mechanisms will be developed. It assumes the context established by the SIDR WG charter, as of April 19, 2011. The charter established two goals for the SIDR work: o Enabling an AS to verify the authorization of an origin AS to The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-threats-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From achi@bbn.com Thu Jan 17 13:41:14 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92E721F8917 for ; Thu, 17 Jan 2013 13:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZr1NMnhpWlp for ; Thu, 17 Jan 2013 13:41:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1A08521F8900 for ; Thu, 17 Jan 2013 13:41:13 -0800 (PST) Received: from dhcp89-089-010.bbn.com ([128.89.89.10]:49525 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TvxCy-0000tM-Hx for sidr@ietf.org; Thu, 17 Jan 2013 16:41:12 -0500 Message-ID: <50F86FF4.4040606@bbn.com> Date: Thu, 17 Jan 2013 16:41:08 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sidr wg References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> In-Reply-To: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 21:41:15 -0000 On 1/17/2013 4:23 PM, internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-threats-04 This revision clarifies the wording on route leaks as a residual vulnerability, addressing a comment by Chris Morrow. From kotikalapudi.sriram@nist.gov Fri Jan 18 08:07:34 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A96821F8956 for ; Fri, 18 Jan 2013 08:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19iCnhfrKS1A for ; Fri, 18 Jan 2013 08:07:33 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id AB03221F8972 for ; Fri, 18 Jan 2013 08:07:22 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 18 Jan 2013 11:07:02 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 18 Jan 2013 11:07:10 -0500 From: "Sriram, Kotikalapudi" To: "sidr wg list (sidr@ietf.org)" Date: Fri, 18 Jan 2013 11:07:09 -0500 Thread-Topic: [sidr] the need for speed Thread-Index: Ac3mKv/MYV+peaj3Rom41XejdX5avwPZbTUA Message-ID: References: ,<50D8F410.1090202@bogus.com> <50DF9565.5010101@bogus.com> In-Reply-To: <50DF9565.5010101@bogus.com> 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" MIME-Version: 1.0 Subject: [sidr] FW: the need for speed X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:07:34 -0000 Joel Jaeggli and I had an off-list email discussion. It was a follow up to Joel's earlier post on the sidr list: http://www.ietf.org/mail-archive/web/sidr/current/msg05560.html With his permission, I am forwarding the email exchange between us here. It is mainly about setting up a BGP session quickly (under the emergency scenario) between a DoS mitigator and the victim. Joel's inputs/insights follow. Sriram -----Original Message----- From: joel jaeggli [mailto:joelja@bogus.com] Sent: Saturday, December 29, 2012 8:14 PM So, I'd say first off that I come at this as a consumer of these services (I have used them) rather than as a provider of them. On 12/28/12 6:51 AM, Sriram, Kotikalapudi wrote: > Hi Joel, > > Thanks for your comments. > >> The alternative approach assuming you've planned ahead is to originate >> a more specific with the same origin but Verisign as the transit AS... >> therefore the origin validation works fine. if you do the same with >> the covering prefix you're going to have to either make your other >> providers less desirable, or withdraw the prefix. the backhaul from >> your dos protection provider is done with a tunnel or ideally with a >> private interconnect. > > The ideas you mention above were initiated with these two posts: > > http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html > http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html > > Shane and I have since been discussing various scenarios and nuances > as you might have seen on the sidr list. > > Let me ask a question that perhaps you can offer some help with. > When you have path validation (BGPSEC) in the future, the DDoS > mitigator cannot generate a *signed update* on behalf of the victim. yeah the approach described doesn't solve the path validation problem at least without coordination. > Because in order to do so the mitigator needs the victim's private > key. But sidr wg generally seems to discourage Org A from sharing > private keys with another Org B. > And we are discussing an emergency situation where the victim and > mitigator have had no prior relationship. yeah when you're under duress things are somewhat exciting. > In this case, how easy or difficult is it to set up a BGP peering > session on the fly between from the victim's CE to mitigator's PE? so in the case of mitigation through prefix re-advertisement, typically a tunnel is required from the ddos mitigation provider back to the customers equipment - because you're announcing a prefix from the dos mitigation provider big enough to be accepted on the internet. In general the tunnel needs to be terminated using other address space, so either the block they're announcing is de-aggregated from the victim's address space or the dos provider announces the victim's whole address space and a provider assigned address is used for tunnel termination. There's a design problem here in ipv4 land about deploying your services such that they're separable in the event that you need to move one but not all of them.. > There is no prior connection between them. > Can they set up the BGP session over a TCP session that may span multiple physical hops? So yes, because you need to backhaul (good) traffic from the ddos mitigation provider to the victims servers over a tunnel or a newly established direct connection, it does not seem infeasible to me to establish a bgp session at the same time that the tunnel is brought up. In fact it probably makes sense to encapsulate the bgp session in the tunnel. Bringing up a session at that time is clearly more complex than not doing it, but if you need it to make it work then it's probably worth it. we did maintain BGP sessions with Verisign for this dos mitigation service for example so that we could among other things signal them as to which prefixes we wanted them to take. > ** How fast can this be done? ** Fundamentally, this is like turning up any other peer, joint coordination is required, if no additional infrastructure has to be provisioned then it's something that can be done rather quickly by two people that know what they're doing. > If the BGP session (BGPSEC in this case) is set up quickly, then the > victim can provide a signed announcement (with an appropriate more > specific prefix) directly to the mitigator and then the mitigator can > propagate it, and intercept the DDoS data traffic for scrubbing and re-channeling back to the victim's server. So, today when I change my published RADB policy by adding a prefix to my existing providers it can take as long as 24 hours for my upstreams to adjust their RADB generated filters. so there are other considerations that today impact the speed at which some changes can be made, that can be accelerated by calling them and nicely asking to regenerate those objects but does imply some level of planning ahead / confusion occurs when changes are made under duress. Joel From christopher.morrow@gmail.com Fri Jan 18 08:12:21 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEB321F88A8 for ; Fri, 18 Jan 2013 08:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GyikyN0p+0l for ; Fri, 18 Jan 2013 08:12:18 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 717E521F892D for ; Fri, 18 Jan 2013 08:12:18 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so1578140eaa.33 for ; Fri, 18 Jan 2013 08:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=rwvSbVnOKsWg8mWz25r1Vb3Ji5Xsb0uDolePJk9IQdA=; b=Y+DpNon/y9AZaT9f/iqktu1F0YvFdMMODgsXt5mILjt2fShO8gXajiA0zjEHmMYkPu GLHxwGNA+E2oypOAQHZXryTf5VuXJLrdqIQh4MMBmnI8X4+AmCkHL0E/M1gPPqOZqifV S4gaRGj2UANCPSBFVBGv0KS/atneHtq50groQPXphNEwwhqsSzINtKT9jaN2g5qRyYNW 3QRXq/+XtNRcYsSx8rpRSNUux3q3IzYXge+zf44FGxUEWBh4EJO+DnVQJzkYD9ZmndCz NIbtP17+/CBghzzoIP9TZGBVcLiMkz6qxZmMQEWn8vDVsMuM/MiCssRPIPh5qS5JKwjw BtbA== MIME-Version: 1.0 X-Received: by 10.14.207.195 with SMTP id n43mr27277680eeo.38.1358525537609; Fri, 18 Jan 2013 08:12:17 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Fri, 18 Jan 2013 08:12:17 -0800 (PST) In-Reply-To: <20130118144835.18337.67362.idtracker@ietfa.amsl.com> References: <20130118144835.18337.67362.idtracker@ietfa.amsl.com> Date: Fri, 18 Jan 2013 11:12:17 -0500 X-Google-Sender-Auth: x5iwHVWBY210jFFauEvkRwEo1JI Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] Fwd: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:12:21 -0000 of interest ... sounds like (from the abstract) this is more along the lines of a BCP. ---------- Forwarded message ---------- From: Date: Fri, Jan 18, 2013 at 9:48 AM Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-00.txt To: i-d-announce@ietf.org Cc: opsec@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : BGP operations and security Author(s) : Jerome Durand Ivan Pepelnjak Gert Doering Filename : draft-ietf-opsec-bgp-security-00.txt Pages : 24 Date : 2013-01-18 Abstract: BGP (Border Gateway Protocol) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it's important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself (like TTL, MD5, control plane filtering) and to better control the flow of routing information, using prefix filtering and automatization of prefix filters, max-prefix filtering, AS path filtering, route flap dampening and BGP community scrubbing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From eosterweil@verisign.com Tue Jan 22 07:07:56 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2A121F8800 for ; Tue, 22 Jan 2013 07:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrA9ZWRx0-Ez for ; Tue, 22 Jan 2013 07:07:55 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5A421F85AF for ; Tue, 22 Jan 2013 07:07:55 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUP6rR0LZ1FPWt98wPEyFWHIXTZAwPb6U@postini.com; Tue, 22 Jan 2013 07:07:55 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r0MF7muK032302; Tue, 22 Jan 2013 10:07:50 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 10:07:39 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <50F86FF4.4040606@bbn.com> Date: Tue, 22 Jan 2013 10:07:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> To: Andrew Chi X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 22 Jan 2013 15:07:39.0439 (UTC) FILETIME=[3833ABF0:01CDF8B2] Cc: sidr wg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:07:56 -0000 On Jan 17, 2013, at 4:41 PM, Andrew Chi wrote: > On 1/17/2013 4:23 PM, internet-drafts@ietf.org wrote: >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-threats-04 >=20 > This revision clarifies the wording on route leaks as a residual = vulnerability, addressing a comment by Chris Morrow. I have a few problems with this draft, and in particular, with the new = text: - The anecdote at the top of the modified paragraph on page 19 says, = ``It has been stated that...'' without a citation, however, the = paragraph then goes on to say that without an _RFC_ citation we cannot = address route leaks. I would submit that moving from anecdotal hearsay = to omission without a normative reference is an awkward transition. - While there is no definition of a route leak in an RFC, there is an = entire GROW draft dedicated to it. - I also don't understand how the text in this (a threats document) can = claim that route leaks are beyond the scope of PATHSEC in a fait = accompli manner... This is a threats document, right? This is a threat = to BGP, right? The RPKI provides semantics that ``BGP, itself does not = include semantics...'' for... I don't think applying this exclusion to = route leaks survives a sniff test. Overall, I think the threats document is still missing a badly needed = treatise on route leaks. I would suggest a good starting point for = informational reading might be the draft: = http://tools.ietf.org/html/draft-grow-simple-leak-attack-bgpsec-no-help-00= Eric= From christopher.morrow@gmail.com Tue Jan 22 08:08:58 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71AC921F899F for ; Tue, 22 Jan 2013 08:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szmmu8RZPU8J for ; Tue, 22 Jan 2013 08:08:58 -0800 (PST) Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by ietfa.amsl.com (Postfix) with ESMTP id AC82321F8992 for ; Tue, 22 Jan 2013 08:08:57 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id c1so2956592eaa.39 for ; Tue, 22 Jan 2013 08:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QBst7ZzVr3HSXrIOhJJA7WsBNvWcX+WKngowOqRgAbM=; b=uL2pwAZi7EewwrBVSQyL2nbj+rFqvVRHcZqat2O80GHqP6z0lIpNGYzWDL+1H/CfEd zq23FY4rioTC8HQlROZJKLJ9vCaOZ2oqRJVSl/4Tj94D8m2h56rC2dDoDJAZE2MvSqdN K17hhGaz71WjTAAFmA0HDjwz6l0qCsmmgyMOR+JXaPnxWvN88AELOV+gg1ZWz2FNMaYt 4o9EDbF7XszetoTFw8T56AXlbq6Q1cw0qewdyAWKcG4SqmB2Wdr/dCKirP+IP3daoElp FEvEEbREw6cXZ6cLtd35X+SgTp1dLnx8zg5HfQy4RDQBopFEwbjkuBG60M21HxOoqesd v+9A== MIME-Version: 1.0 X-Received: by 10.14.202.3 with SMTP id c3mr74306610eeo.4.1358870936640; Tue, 22 Jan 2013 08:08:56 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Tue, 22 Jan 2013 08:08:56 -0800 (PST) In-Reply-To: <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> Date: Tue, 22 Jan 2013 11:08:56 -0500 X-Google-Sender-Auth: PfrWTjtq4faNrUKA65satx0RPM0 Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:08:58 -0000 On Tue, Jan 22, 2013 at 10:07 AM, Eric Osterweil wrote: > - I also don't understand how the text in this (a threats document) can claim that route > leaks are beyond the scope of PATHSEC in a fait accompli manner... This is a > threats document, right? This is a threat to BGP, right? The RPKI provides > semantics that is the 'leak' a threat to 'BGP' or to the users of the network? >``BGP, itself does not include semantics...'' for... I don't think applying this exclusion to > route leaks survives a sniff test. the RPKI is simply a database, it's not part of the BGP protocol. The RPKI system doesn't include bgp peering data, so while you could detect and potentially mitigate a 'hijack', it's not clear to me that you'd know 'leak' vs 'new peering arrangement' just based on the RPKI data. > Overall, I think the threats document is still missing a badly needed treatise on route > leaks. is it fair to say that you would like the threats document to say, in perhaps more words than this: "BGP Path Security has no capability to influence or inform the bgp system of 'route leaks'." this, I think, does run afoul of stephen's want for a definition of 'route leak' though... but I think it's what you're aiming at? From eosterweil@verisign.com Tue Jan 22 08:16:07 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A311121F8A9B for ; Tue, 22 Jan 2013 08:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W65u7L3bR23Y for ; Tue, 22 Jan 2013 08:16:07 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id E021521F8A51 for ; Tue, 22 Jan 2013 08:16:06 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUP67Q6bexATSFulLNLtpKw9gNewIaFsn@postini.com; Tue, 22 Jan 2013 08:16:06 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r0MGG08j002241; Tue, 22 Jan 2013 11:16:02 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 11:15:50 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 22 Jan 2013 11:16:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 22 Jan 2013 16:15:50.0971 (UTC) FILETIME=[BEF1E8B0:01CDF8BB] Cc: sidr wg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:16:07 -0000 On Jan 22, 2013, at 11:08 AM, Christopher Morrow wrote: > On Tue, Jan 22, 2013 at 10:07 AM, Eric Osterweil > wrote: > >> - I also don't understand how the text in this (a threats document) = can claim that route >> leaks are beyond the scope of PATHSEC in a fait accompli manner... = This is a >> threats document, right? This is a threat to BGP, right? The RPKI = provides >> semantics that >=20 > is the 'leak' a threat to 'BGP' or to the users of the network? I think this might be a case of picket fences? I see your distinction, = but I had thought the wg's broader goal was to protect those that rely = on BGP? I didn't think we were designing a protocol that could fall in = a forrest with no one to hear it. :) >> ``BGP, itself does not include semantics...'' for... I don't think = applying this exclusion to >> route leaks survives a sniff test. >=20 > the RPKI is simply a database, it's not part of the BGP protocol. The > RPKI system doesn't include bgp peering data, so while you could > detect and potentially mitigate a 'hijack', it's not clear to me that > you'd know 'leak' vs 'new peering arrangement' just based on the RPKI > data. Indeed. My point was not to draw RPKI into the solution space, or claim = something about its goals. I was just trying to illustrate that the wg = has already invested (heavily) in systems and designs that are not = semantically part of BGP. It just seemed silly (imho) to start claiming = that if something isn't part of BGP's semantics, we should treat it as = taboo... >> Overall, I think the threats document is still missing a badly needed = treatise on route >> leaks. >=20 > is it fair to say that you would like the threats document to say, in > perhaps more words than this: > "BGP Path Security has no capability to influence or inform the bgp > system of 'route leaks'." >=20 > this, I think, does run afoul of stephen's want for a definition of > 'route leak' though... but I think it's what you're aiming at? I am not sure. I would suggest that identifying a threat should _not_ = be held up by the search for a closed form expression of that threat. = Does that make more sense? Eric= From randy@psg.com Tue Jan 22 14:18:43 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7986621F87B6 for ; Tue, 22 Jan 2013 14:18:43 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwXCZ2n2y+eo for ; Tue, 22 Jan 2013 14:18:43 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 27B0821F86C9 for ; Tue, 22 Jan 2013 14:18:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TxmAx-000L0B-Vg; Tue, 22 Jan 2013 22:18:40 +0000 Date: Wed, 23 Jan 2013 07:18:38 +0900 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 22:18:43 -0000 > I had thought the wg's broader goal was to protect those that rely on > BGP? good luck with that. start an insurance business. it is to protect the protocol from being gamed. randy From eosterweil@verisign.com Tue Jan 22 15:18:00 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1728821F8584 for ; Tue, 22 Jan 2013 15:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzDn4A7BiEXs for ; Tue, 22 Jan 2013 15:17:59 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id D66B921F857E for ; Tue, 22 Jan 2013 15:17:58 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUP8eJJmkJ3cYplaKYn7gs67Ll+RbVwur@postini.com; Tue, 22 Jan 2013 15:17:58 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r0MNHrmn031033; Tue, 22 Jan 2013 18:17:55 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 18:17:43 -0500 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 22 Jan 2013 18:17:54 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> To: Randy Bush X-Mailer: Apple Mail (2.1085) X-OriginalArrivalTime: 22 Jan 2013 23:17:43.0002 (UTC) FILETIME=[AE1753A0:01CDF8F6] Cc: sidr wg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 23:18:01 -0000 On Jan 22, 2013, at 5:18 PM, Randy Bush wrote: >> I had thought the wg's broader goal was to protect those that rely on >> BGP? > > good luck with that. start an insurance business. Good one, Randy... Eric From christopher.morrow@gmail.com Tue Jan 22 18:16:25 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C0121F8865 for ; Tue, 22 Jan 2013 18:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1gWfdhAkW5q for ; Tue, 22 Jan 2013 18:16:25 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3521F8925 for ; Tue, 22 Jan 2013 18:16:16 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so2864988eaa.32 for ; Tue, 22 Jan 2013 18:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Mo4kkeMQ+2Tdiw1epwxFEGMHjjhEbj5TFL8SQMWuxRE=; b=O9vfA8SCN8jXw87ln28/yvOPN9XhEvA6hFSBSpSK8xDFcLxkA4cY2sE4vY05u9iN7D jttUIB3JcDditthJndPoalOtXW6Q1s0rgFpeKktDt9NlwZwTtXgkfBoNum/xoeZSZ4Mh DuHQpserAIpDKjasbRF+LK2pbrDDjli9rcTTqr96xg23aU0TtOvzjFxhxlGh/agIclBP tl9hbPyh8+9YDcScxWlnnMkwtYQtE8CzLFIG1/JnVtQLlBGR0V5qX4Dc8ycAx/u7G/MG z41XBi/ZZvxDShIEDXLWtDeaB3WoFQ7sCBT6WpVTiBNOcDApC7N6EkBHhu5eAz1MTO68 LN6w== MIME-Version: 1.0 X-Received: by 10.14.207.195 with SMTP id n43mr78824059eeo.38.1358907375451; Tue, 22 Jan 2013 18:16:15 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.223.100.1 with HTTP; Tue, 22 Jan 2013 18:16:15 -0800 (PST) In-Reply-To: References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> Date: Tue, 22 Jan 2013 21:16:15 -0500 X-Google-Sender-Auth: TlgG1aq3e6KQPMQ6AdXBaCbD4x0 Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 02:16:25 -0000 On Tue, Jan 22, 2013 at 6:17 PM, Eric Osterweil wrote: > > On Jan 22, 2013, at 5:18 PM, Randy Bush wrote: > >>> I had thought the wg's broader goal was to protect those that rely on >>> BGP? I think the goal has been to protect the routing system through better protections of the protocol. I hope we can later get to a point where this means the users of the system have tools to make their routing system (and ours) better. -chris From russw@riw.us Wed Jan 23 06:40:59 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23E21F85CE for ; Wed, 23 Jan 2013 06:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5y8DqvGnVqq for ; Wed, 23 Jan 2013 06:40:58 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id A9B0221F8598 for ; Wed, 23 Jan 2013 06:40:58 -0800 (PST) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ty1VX-0002zF-7D for sidr@ietf.org; Wed, 23 Jan 2013 06:40:55 -0800 Message-ID: <50FFF680.3080400@riw.us> Date: Wed, 23 Jan 2013 09:41:04 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: sidr@ietf.org References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 14:40:59 -0000 > Indeed. My point was not to draw RPKI into the solution space, or claim something about its goals. I was just trying to illustrate that the wg has already invested (heavily) in systems and designs that are not semantically part of BGP. It just seemed silly (imho) to start claiming that if something isn't part of BGP's semantics, we should treat it as taboo... The problem is, of course, that a "route leak," is explicitly a part of BGP's semantics --on the filtering side of things. Communities, for instance, are very much a part of the semantics of BGP. They are used to filter routes and control the places where routes are advertised; therefore filtering is a part of BGP's semantics. Proving a route should not be advertised is as much a part of this problem as proving a route should be advertised --in fact, you can't really separate the two problems, though we've been trying to for years. "Securing the semantics of BGP," is just a convenient way to restrict the scope to BGP-SEC (SBGP), while being flexible enough to leave out the things BGP-SEC (SBGP) can't fix as well. We need to begin from the beginning, starting with a real requirements document with real requirements framed in a way actually designed to protect the operation of BGP from the perspective of intent, rather than operation. I'll say it again (to be ignored again): all security is about intent. Russ -- <>< riwhite@verisign.com russw@riw.us From shane@castlepoint.net Wed Jan 23 07:49:24 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793F521F85AF for ; Wed, 23 Jan 2013 07:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZrAZ7cOdh0H for ; Wed, 23 Jan 2013 07:49:24 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBA821F85A4 for ; Wed, 23 Jan 2013 07:49:23 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 892DF30007F for ; Wed, 23 Jan 2013 15:49:22 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 4807730007C; Wed, 23 Jan 2013 08:49:22 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: <50FFF680.3080400@riw.us> Date: Wed, 23 Jan 2013 08:49:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <998FA3F3-2EBE-49C6-B41F-2B5AB326FB75@castlepoint.net> References: <20130117212335.2192.18659.idtracker@ietfa.amsl.com> <50F86FF4.4040606@bbn.com> <88D477E9-141E-407F-A3B1-FEC4D5AB4DAE@verisign.com> <50FFF680.3080400@riw.us> To: Russ White X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jan 23 08:49:22 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5100068242074631383882 X-DSPAM-Factors: 27, to+#+the, 0.01000, to+#+the, 0.01000, Mime-Version*OS+X, 0.01000, not+be, 0.01000, From*Amante+shane, 0.01000, mailing+list, 0.01000, as+well, 0.01000, Mime-Version*Mail+#+1499, 0.01000, of+#+#+of, 0.01000, and+#+the, 0.01000, to+#+#+and, 0.01000, the+#+to, 0.01000, for+#+#+the, 0.01000, Mime-Version*6.2+1499, 0.01000, are+not, 0.01000, be+#+in, 0.01000, Mime-Version*OS+#+#+#+1499, 0.01000, is+#+#+that, 0.01000, the+#+#+of, 0.01000, is+#+#+of, 0.01000, a+#+#+to, 0.01000, Mime-Version*X+#+6.2, 0.01000, of+this, 0.01000, are+#+#+#+of, 0.01000, it+#+to, 0.01000, to+#+#+#+the, 0.01000, to+#+#+#+the, 0.01000 Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:49:24 -0000 On Jan 23, 2013, at 7:41 AM, Russ White wrote: >> Indeed. My point was not to draw RPKI into the solution space, or = claim something about its goals. I was just trying to illustrate that = the wg has already invested (heavily) in systems and designs that are = not semantically part of BGP. It just seemed silly (imho) to start = claiming that if something isn't part of BGP's semantics, we should = treat it as taboo... >=20 > The problem is, of course, that a "route leak," is explicitly a part = of > BGP's semantics --on the filtering side of things. Communities, for > instance, are very much a part of the semantics of BGP. They are used = to > filter routes and control the places where routes are advertised; > therefore filtering is a part of BGP's semantics. Proving a route = should > not be advertised is as much a part of this problem as proving a route > should be advertised --in fact, you can't really separate the two > problems, though we've been trying to for years. >=20 >=20 > "Securing the semantics of BGP," is just a convenient way to restrict > the scope to BGP-SEC (SBGP), while being flexible enough to leave out > the things BGP-SEC (SBGP) can't fix as well. We need to begin from the > beginning, starting with a real requirements document with real > requirements framed in a way actually designed to protect the = operation > of BGP from the perspective of intent, rather than operation. > I'll say > it again (to be ignored again): all security is about intent. I'm not ignoring it. :-) In fact, I'll +1 it. =20 -shane >=20 > Russ >=20 > --=20 > <>< > riwhite@verisign.com > russw@riw.us > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From internet-drafts@ietf.org Wed Jan 23 10:05:02 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290821F8703; Wed, 23 Jan 2013 10:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noIasAa9WWff; Wed, 23 Jan 2013 10:05:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B954021F8B5E; Wed, 23 Jan 2013 10:05:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130123180501.26076.98984.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2013 10:05:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-cps-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 18:05:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Template for a Certification Practice Statement (CPS) fo= r the Resource PKI (RPKI) Author(s) : BBN Technologies Filename : draft-ietf-sidr-cps-01.txt Pages : 42 Date : 2013-01-23 Abstract: This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-cps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-cps-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-cps-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Jan 24 10:52:47 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A65621F84D5; Thu, 24 Jan 2013 10:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmkUFox4dL9E; Thu, 24 Jan 2013 10:52:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6178421F8464; Thu, 24 Jan 2013 10:52:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130124185246.30200.56205.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2013 10:52:46 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Algorithm Agility Procedure for RPKI.) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:52:47 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Algorithm Agility Procedure for RPKI.' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-algorithm-agility/ballot/ No IPR declarations have been submitted directly on this I-D. This draft was previously last called with an intended status of Proposed Standard. The purpose of this last call is to determine if there is IETF consensus to publish this draft as a BCP. From internet-drafts@ietf.org Mon Jan 28 08:04:54 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE221F870E; Mon, 28 Jan 2013 08:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUD8IcHMZ87c; Mon, 28 Jan 2013 08:04:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE4021F8738; Mon, 28 Jan 2013 08:04:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130128160453.8364.39571.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2013 08:04:53 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-impl-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:04:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : RPKI Router Implementation Report Author(s) : Randy Bush Rob Austein Keyur Patel Hannes Gredler Matthias Waehlisch Filename : draft-ietf-sidr-rpki-rtr-impl-02.txt Pages : 9 Date : 2013-01-28 Abstract: This document is an implementation report for the RPKI Router protocol as defined in [RFC6810]. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-impl-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/