From nobody Sun May 4 17:21:28 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EBF1A01DD for ; Sun, 4 May 2014 17:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.258 X-Spam-Level: X-Spam-Status: No, score=0.258 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rray4iQ8Sgwc for ; Sun, 4 May 2014 17:21:25 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 137101A01DA for ; Sun, 4 May 2014 17:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:date:from:to:subject:message-id:mail-followup-to: references:mime-version:content-type:content-disposition:in-reply-to: user-agent:return-path; bh=sqEezOARRwu/Cqqw80EdwXwjxtNlyHrKQ4AYesFVfqs=; b=Xn/4atAJFJLfKBbxhiNwEz4aGkuasUPTxL2iT2b2GDkSAae8JttGnmpuDHu7eCCLh83btIV6AlO/A IUlCz76GI+glKZW+l8quw1FLGexCeY0fg61sTyJ3WJsH+Lj/EnFD4XNiA+tVzLopbdBNOtQJx0aZ2w We5xxXfnomXK/EUg= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Mon, 5 May 2014 10:20:56 +1000 (EST) Received: from main (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 5 May 2014 10:21:19 +1000 Received: from tomh by main with local (Exim 4.82) (envelope-from ) id 1Wh6ek-000AcE-MU for sidr@ietf.org; Mon, 05 May 2014 10:21:18 +1000 Date: Mon, 5 May 2014 10:21:18 +1000 From: Tom Harrison To: Message-ID: <20140505002118.GA40364@main> Mail-Followup-To: sidr@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/pZFj2x0NfwsvHogC8aPo65ZuWV0 Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:21:27 -0000 On Fri, Apr 25, 2014 at 12:05:14PM -0400, Sandra Murphy wrote: > The authors of draft-huston-rpki-validation-01.txt, RPKI Validation > Reconsidered, have requested wg adoption. > > See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > > Please do respond to the list as to whether you support the wg > adopting this as a work item. You do not need to comment on the > content of this draft at this time. You are asked to indicate if > you think that this is work that the wg should be doing and whether > this draft is an acceptable starting point. Adding whether you > can/will review or not is useful. > > Note that active support is required for adoption. Silence is a > vote against adoption. > > This adoption call will end on 9 May 2014. I support adoption. -Tom From nobody Mon May 5 09:06:06 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4342E1A016C for ; Mon, 5 May 2014 09:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdgGw6KxROIj for ; Mon, 5 May 2014 09:06:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 262CE1A0298 for ; Mon, 5 May 2014 09:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5602; q=dns/txt; s=iport; t=1399305959; x=1400515559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fqfH4dxRavBbq0goI+ItwW2LhkiM12rMjjTNaYIOl7w=; b=ac+DSQmCFTOcR9N3gfGvSNuxziHE/mAseOzQpkl+2DDDqFvOuoh8I1Ad X1uQJqLaIZjVWg38aPL6PPNzYPEnDzXm2fkSV3FvpO5WtibEPL0VqDIRP QUTAcKe038KUW20CMjg60NkmFFBlqEpiRc9cq0t7gsisv2mpVh/UgCUJU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0HAM61Z1OtJA2G/2dsb2JhbABZgwZPWKowAQIFAZJRAYc6gRgWdIImAQEEAQEBawsQAgEIBDsHJwsUEQIEDgUJCwiIJQ3LWheFVoh8BgGDKoEVBJk0knSDNG2BAiQc X-IronPort-AV: E=Sophos;i="4.97,989,1389744000"; d="scan'208,217";a="322444933" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 05 May 2014 16:05:58 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s45G5wNK000516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 16:05:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 5 May 2014 11:05:58 -0500 From: "Roque Gagliano (rogaglia)" To: Randy Bush Thread-Topic: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 Thread-Index: AQHPaHvmvZsbW7hhNkeRxV8NMyn81w== Date: Mon, 5 May 2014 16:05:57 +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.155.144.166] Content-Type: multipart/alternative; boundary="_000_E233B3DD0DDC4AFFBC4BAE669BF811BFciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/R-i3L9Bla_0uHYQow_T-NowPRP0 Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:06:04 -0000 --_000_E233B3DD0DDC4AFFBC4BAE669BF811BFciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Randy, because the goal of this draft can already be reached simply through use of existing means, i do not support publication. i am not strongly opposed. it's just one more bit of ietf work that is not obviously needed. Here are the three reasons that may refresh our mind on why after 4 years t= his draft is still important to move forward to the IESG: 1) Scope beyond BGP communities: This document creates an IANA registry fo= r the "BGP origin validation state". This makes the document the standard f= or the encoding of this state (valid/invalid/not found). We are already use= d it as reference for the IPFIX Information Element 294 (for which we went = through all the process with the IPFIX policy to get it registered here: h= ttp://www.iana.org/assignments/ipfix/ipfix.xhtml). There are other use case= s that I can think of where this registry will be required (MRT exports as = one top of my mind) 2) Documenting change on BGP decision process changes: Section 3. Basically= the origin validation happens before any other policy applied. This goes b= eyond the iBGP community but even for stand-alone routers. In this sense, y= ou can implement RPKI in a device without modifying any existing policy des= cription. 3) Documentation of non-standard BGP communities: Over the years, we have s= een a number of attempts to document and standardise providers communities = with less than great results. One particularly use case (that I suffered) i= s when you have to merge two networks due to an acquisition, standardised c= ommunities are very helpful. And lets not forget: Running Code: Last but not least=85the draft has been = delayed more than what it should and several implementations (including two= from Cisco) has running code + documentation + training. As we are pushing= to improve adoption of RPKI, I rather spend time adding the missing pieces= that removing what is not broken=85although the need may not be obvious fo= r everyone. Roque randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_E233B3DD0DDC4AFFBC4BAE669BF811BFciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Randy,

because the goal of this draft can already be rea= ched simply through use
of existing means, i do not support publication.  i am not strongly opposed.  it's just one more bit of ietf work that is not obviously needed.

Here are the three reasons that may refresh our mind on why after 4 ye= ars this draft is still important to move forward to the IESG:

1) Scope beyond BGP communities:  This document creat= es an IANA registry for the "BGP origin validation state". This m= akes the document the standard for the encoding of this state (valid/invali= d/not found). We are already used it as reference for the IPFIX Information Element 294 (for which we went through all the proce= ss with the IPFIX policy to get it registered here:  http://www.iana.org/assig= nments/ipfix/ipfix.xhtml). There are other use cases that I can think of where this registry will be required (MRT ex= ports as one top of my mind)

2) Documenting change on BGP decision process changes: Section 3. Basically the origin validation happens before any other policy applied.= This goes beyond the iBGP community but even for stand-alone routers. In t= his sense, you can implement RPKI in a device without modifying any existing policy description.

3) Documentation of non-standard BGP communities: O= ver the years, we have seen a number of attempts to document and standardis= e providers communities with less than great results. One particularly= use case (that I suffered) is when you have to merge two networks due to an acquisition, standardised communities are = very helpful. 

And lets not forget: Running Code: Last but not = least=85the draft has been delayed more than what it should and several imp= lementations (including two from Cisco) has running code + documentatio= n + training. As we are pushing to improve adoption of RPKI, I rather spend time adding the missing pieces that removing what is = not broken=85although the need may not be obvious for everyone.

Roque

randy

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

--_000_E233B3DD0DDC4AFFBC4BAE669BF811BFciscocom_-- From nobody Mon May 5 09:10:13 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6091A016C for ; Mon, 5 May 2014 09:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcxNZSGiWi5H for ; Mon, 5 May 2014 09:10:07 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4891A037A for ; Mon, 5 May 2014 09:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3981; q=dns/txt; s=iport; t=1399306204; x=1400515804; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oVfEbf0HJU8B6okTREXd3uQG71DZmVomlntVwXGKukU=; b=QKnHmJ/qXx6XosA3GvnJFu/po2Wp01byFZJ4aqjInFrhuX8w9SN1nXEp AZfsAi4OrfLic+XO96xkpJFSMFKIKqhBi1naa8HR4Qv3Ib/wK8UPLyenh DF++nwNFDB5ngGN3bETsSfwmVepMyKby2+a7mgW5kIMcgXll7kk8N+JvD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIHAGm3Z1OtJA2E/2dsb2JhbABZgwZPWKowAQIFAZEPgUIBhzqBGBZ0giYBAQQBAQFrCxACAQgECjEHJwsUEQIEDgUUiC0Ny1oXhVaIfAeDKoEVBJk0gTyROIM0gW8kHA X-IronPort-AV: E=Sophos; i="4.97,989,1389744000"; d="scan'208,217"; a="41135416" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 05 May 2014 16:10:03 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s45GA3P1013251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 16:10:04 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 5 May 2014 11:10:03 -0500 From: "Roque Gagliano (rogaglia)" To: Sandra Murphy Thread-Topic: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 Thread-Index: AQHPaHx4vZsbW7hhNkeRxV8NMyn81w== Date: Mon, 5 May 2014 16:10:03 +0000 Message-ID: <9487C4DF-EEAF-40FE-A9CE-768D38C91DA7@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.144.166] Content-Type: multipart/alternative; boundary="_000_9487C4DFEEAF40FEA9CE768D38C91DA7ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/9-sn31wfDbxACkpX0B9R6FQfD3Q Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:10:10 -0000 --_000_9487C4DFEEAF40FEA9CE768D38C91DA7ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sandra, I support this document moving forward to the IESG. I read the document as part of the WGLC process and I believe the text is r= eady for publication. My only question is a formality from Section 3 that says: " If a BGP router supports prefix origin validation and is configure for th= e extensions defined in this document, the validation step SHOULD be perfor= med prior to any of the steps defined in the decision process of [RFC4271]." (Roque) Should this document specifically be labeled as an update to RFC427= 1? Regards, Roque On Apr 26, 2014, at 1:53 AM, Sandra Murphy > wrote: The authors of BGP Prefix Origin Validation State Extended Community, draft= -ietf-sidr-origin-validation-signaling-04 have requested a WGLC. This message begins a two week WGLC, to end on 9 May 2014. The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-origin= -validation-signaling. Please do send comments to the list, indicating whether you do or do not be= lieve that the draft is ready for publication. --Sandy, speaking as wg co-chair _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_9487C4DFEEAF40FEA9CE768D38C91DA7ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Sandra,

I support this document moving forward to the IESG.

I read the document as part of the WGLC process and I believe the text= is ready for publication.

My only question is a formality from Section 3 that says: 

"= If a BGP router supports prefix origin validation and is configure fo= r the extensions defined in this document, the validation step SHOULD = be performed prior to any of the steps defined in the decision process of [RFC4271]."= ;

(Roque) Should this document specifically be labeled as an update to R= FC4271?

Regards,
Roque

On Apr 26, 2014, at 1:53 AM, Sandra Murphy <sandy@tislabs.com> wrote:

The authors of BGP Prefix Origin Validation State= Extended Community, draft-ietf-sidr-origin-validation-signaling-04 have re= quested a WGLC.

This message begins a two week WGLC, to end on 9 May 2014.  

The draft is available at http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling.=

Please do send comments to the list, indicating whether you do or do not be= lieve that the draft is ready for publication.

--Sandy, speaking as wg co-chair
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

--_000_9487C4DFEEAF40FEA9CE768D38C91DA7ciscocom_-- From nobody Mon May 5 09:19:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF701A03A6 for ; Mon, 5 May 2014 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axbT7k6nvSkl for ; Mon, 5 May 2014 09:19:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 099301A0382 for ; Mon, 5 May 2014 09:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1303; q=dns/txt; s=iport; t=1399306739; x=1400516339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JtrLNTV2FSMbZCHYKnqcaeNMhpr8LxhqXxxd0ENUHSs=; b=ER4gUXMxDzB2hTtqn8Ssvi6x4dkES4+/Tiq/CM9MMlbd+kuDcuAKnmOs ko96YnT5j3IHHfCex1SxSG32FM+hAM8cta/UZvvbJB1bHPZwVvMme1MYq v/YVBdzVCudw/xnET6gtmKz9g53KC4Jky0rF+i0Y20d8IsyjIzUFvHz0X I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsHAIy5Z1OtJV2Z/2dsb2JhbABZgwZPWKowAQIFAZJRhzuBGBZ0giUBAQEDAQEBATc0CwULAgEINhAnCyUCBA4FiDkIDctZEwSFVohJMweDKoEVBJk0knSDNIIv X-IronPort-AV: E=Sophos;i="4.97,989,1389744000"; d="scan'208";a="322289382" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 05 May 2014 16:18:58 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s45GIwRf003728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 16:18:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 5 May 2014 11:18:58 -0500 From: "Roque Gagliano (rogaglia)" To: Randy Bush Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: AQHPaH23g+Y1On9pTU2gzdMektI5tA== Date: Mon, 5 May 2014 16:18:57 +0000 Message-ID: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.144.166] Content-Type: text/plain; charset="us-ascii" Content-ID: <14981CEC1BDAA64AA1F3F9515F40D952@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/esR6z2ujZ0vN13p0WCs4PMRlYxk Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:19:05 -0000 Randy, > while checking the docco, i found >>>=20 >>> 3.14 While the trust level of a route should be determined by the >>> BGPsec protocol, local routing preference and policy MUST then >>> be applied to best path and other routing decisions. Such >>> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. >>> ... >>> 3.17 If a BGPsec design makes use of a security infrastructure, that >>> infrastructure SHOULD enable each network operator to select >>> the entities it will trust when authenticating data in the >>> security infrastructure. See, for example, >>> [I-D.ietf-sidr-ltamgmt]. What about adding that "the connection to this security infrastructure MUST= be through a secure channel"? >>>=20 >>> those references would seem to be obe. dunno what to do with the first= , >>> drop it? the second might ref lta-use-cases. >>=20 >> losing the last sentence in the first seems ok. and the second moving >> to use-cases seems ok to me... >=20 > anyone else have input on this one, well, these two? Proposed changes sounds good. r. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon May 5 09:25:28 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904BF1A02E9 for ; Mon, 5 May 2014 09:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pitzBnzURxWu for ; Mon, 5 May 2014 09:25:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id B65E91A00C6 for ; Mon, 5 May 2014 09:25:22 -0700 (PDT) Received: from BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) by BLUPR09MB038.namprd09.prod.outlook.com (10.255.211.144) with Microsoft SMTP Server (TLS) id 15.0.934.12; Mon, 5 May 2014 16:25:12 +0000 Received: from BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.59]) by BLUPR09MB038.namprd09.prod.outlook.com ([169.254.11.59]) with mapi id 15.00.0934.000; Mon, 5 May 2014 16:25:12 +0000 From: "Montgomery, Douglas" To: "sidr@ietf.org" Thread-Topic: A note about a few tools that maybe of interest: Thread-Index: AQHPaH6WQNIwDauF0ESUBR3NybX37g== Date: Mon, 5 May 2014 16:25:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [129.6.140.29] x-forefront-prvs: 0202D21D2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(31966008)(16601075003)(74662001)(81342001)(74502001)(15202345003)(81542001)(87936001)(36756003)(54356999)(50986999)(83072002)(92566001)(79102001)(66066001)(86362001)(83506001)(575784001)(80022001)(83322001)(19580395003)(99396002)(4396001)(21056001)(20776003)(101416001)(77982001)(92726001)(85852003)(99286001)(64706001)(2656002)(76482001)(15975445006)(46102001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB038; H:BLUPR09MB038.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; Content-Type: text/plain; charset="Windows-1252" Content-ID: <9E8BA0BC9F5133429B74A724CCB9BD1C@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/SdvjRXUuFt_OOS30s98jHLG8iSs Subject: [sidr] A note about a few tools that maybe of interest: X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:25:25 -0000 We run a RPKI monitor that examines various statistics of the emerging RPKI and its relationship to global BGP trace data. Aspects of the RPKI-BGP=20 component are similar to some of the other monitors, the RPKI analysis component=20 offers some new data and visualizations of emerging RPKI structure and usage. =20 Both views offer global and per-region statistics and the ability to compare=20 statistics across regions. We continue to add new analysis modules to the monitor. =20 For details see:=20 http://rpki-monitor.antd.nist.gov There is a new release of our BGP-SrX (quagga) origin validation prototype (v 0.3.1) that now contains full support for signaling validation state with community attributes (draft-ietf-sidr-origin-validation-signaling-04) along with some bug fixes. Source and binary installs available below: http://bgpsrx.antd.nist.gov/ At the same site, there is also a stub, pre-release of a BGPSEC prototype. Mainly offered as an early interoperability tester for BGPSEC session negotiation and BGPSEC_Path attribute generation and validation. Router keys are self-signed and stored in a local file (i.e., no rpki-to-router support for router keys yet). For now, there is just a binary release and instruction file to operate prototype as an interop test tool. Router Diagnostic commands have been extended to display BGPSEC information, e.g.: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D bgpd# show ip bgp 10.40.0.0/16 BGP routing table entry for 10.40.0.0/16 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 2030 40 SRx Information: Update ID: 0.09A2630D Validation: prefix-origin: valid path: valid bgpsec: valid (combination of prefix-origin and path validation) PathType: BGPSEC-Path ( 1 signature blocks, each with 2 path segments) signature block #1: algorithm suite id 1 path segment 1: as=3D2030; pcount=3D1 signature segment [1]: block 1, ski=3D97E8EEC56E7C8AE22866D218B0E4D40416EC4EFA path segment 2: as=3D40; pcount=3D1 signature segment [1]: block 1, ski=3DA509AE9ED377CC31AED01E820670DF9CC781DA9F 10.0.1.2 from 10.0.1.2 (10.0.1.2) Origin IGP, localpref 100, valid, external, best Last Update: Mon May 5 08:42:37 2014 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Once we add new rpki-to-router (draft-austein-sidr-rpki-rtr-rfc6810bis-01) support and do further robustness testing, we will release full source for this functionality too. =8B=20 Doug Montgomery, Mgr Internet & Scalable Systems Research @ NIST / ITL / ANTD From nobody Mon May 5 09:41:38 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71671A03DF for ; Mon, 5 May 2014 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seRAKcfLH2p4 for ; Mon, 5 May 2014 09:41:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id 171041A03D4 for ; Mon, 5 May 2014 09:41:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WhLxH-0003Sg-Py; Mon, 05 May 2014 16:41:28 +0000 Date: Mon, 05 May 2014 18:41:28 +0200 Message-ID: From: Randy Bush To: Roque Gagliano In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/MlSmj_ZNZhZT5U0YfZRoK-jbh6I Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:41:35 -0000 >>>> 3.14 While the trust level of a route should be determined by the >>>> BGPsec protocol, local routing preference and policy MUST then >>>> be applied to best path and other routing decisions. Such >>>> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. >>>> ... >>>> 3.17 If a BGPsec design makes use of a security infrastructure, that >>>> infrastructure SHOULD enable each network operator to select >>>> the entities it will trust when authenticating data in the >>>> security infrastructure. See, for example, >>>> [I-D.ietf-sidr-ltamgmt]. > > What about adding that "the connection to this security infrastructure > MUST be through a secure channel"? connection from what? mains power? :) this is about routers speaking bgpsec. imiho, it would be ill-adviised to start down the rat-hole of operational practices of router management for which there is no proof of termination. randy From nobody Mon May 5 09:51:52 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B684A1A017E for ; Mon, 5 May 2014 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PefjSXMd79wQ for ; Mon, 5 May 2014 09:51:45 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C1ECE1A01B1 for ; Mon, 5 May 2014 09:51:44 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id mc6so979802lab.23 for ; Mon, 05 May 2014 09:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sJaVtc4mqFsoXklHpMqoDyFUjoqmEUghZBEW4G4lhxU=; b=k/xdGJNG19h8ZgQ+INsp0KMcpqyC7UJVbkO1XpO52blkxcZnjlv4M0F5sprUhXtUYQ Xe0Vt4cXHsV6p/3Uj4zm2vQwNUq7HXjrcafG3fEbK9Ce39Ex0zJ5AQ0Wpx3YN+m1g1gk 9FIC00jjlutCTSuHpV+dmC0mTDasFvVvEO1HLSS2Mb09b5rBQLmfl/C3DMe69vZOhT4G syn5iHNfNx+gQp5N8O+cliZ3BnnGX9uS3iJqCsyH4ZB453Qu/pgxpeQDKEvBm28SEsxf Nyrpo6Xk9oNKUElvjR4+LPdf/C9Ibosxth5rpLaHz7z4Ewv/zsXTs6GWt+ApGyT/mY6L FEJg== MIME-Version: 1.0 X-Received: by 10.112.100.231 with SMTP id fb7mr2062159lbb.56.1399308700724; Mon, 05 May 2014 09:51:40 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.114.95.74 with HTTP; Mon, 5 May 2014 09:51:40 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Mon, 5 May 2014 12:51:40 -0400 X-Google-Sender-Auth: 7hL6TVIcAENFhzI8DbyaITzbLHo Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ifPWP2l59EofnJb6NOT27lZ2xPU Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:51:49 -0000 On Mon, May 5, 2014 at 12:41 PM, Randy Bush wrote: >>>>> 3.14 While the trust level of a route should be determined by the >>>>> BGPsec protocol, local routing preference and policy MUST then >>>>> be applied to best path and other routing decisions. Such >>>>> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. >>>>> ... >>>>> 3.17 If a BGPsec design makes use of a security infrastructure, that >>>>> infrastructure SHOULD enable each network operator to select >>>>> the entities it will trust when authenticating data in the >>>>> security infrastructure. See, for example, >>>>> [I-D.ietf-sidr-ltamgmt]. >> >> What about adding that "the connection to this security infrastructure >> MUST be through a secure channel"? it's done via rcynic and/or rpki-to-rtr, right? depending on where in the process you are... presuming the process looks like: publication-point - gatherer - cache - router (rcynic) (rcynic) (rpki-rtr) and above/before 'publication-point' is 'RIR tomfoolery' > connection from what? mains power? :) i think roque was referring to the above process...which I think already includes 'security bits'. (rcynic == CMS, rpki-rtr == AO || ssh) > this is about routers speaking bgpsec. imiho, it would be ill-adviised > to start down the rat-hole of operational practices of router management > for which there is no proof of termination. let's avoid that for now, especially since I think the request is already taken care of. If this is all satisfactory, let's get to a WGLC in the next 2 days, and then see where that leads us? -chris From nobody Mon May 5 10:03:54 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DA81A03E8 for ; Mon, 5 May 2014 10:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbfytAVI7pqh for ; Mon, 5 May 2014 10:03:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id 40F851A03E5 for ; Mon, 5 May 2014 10:03:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WhMIs-0003XR-2Q; Mon, 05 May 2014 17:03:46 +0000 Date: Mon, 05 May 2014 19:03:46 +0200 Message-ID: From: Randy Bush To: Roque Gagliano 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/alU5SFQMWupuPleJU_QCJzZ3llQ Cc: sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:03:52 -0000 > This document creates an IANA registry for the "BGP origin validation > state". which is highly inappropriate, as the three and only three states are cast in stone. this should be removed if we're going to progress the document. > 2) Documenting change on BGP decision process changes: Section 3. > Basically the origin validation happens before any other policy > applied. This goes beyond the iBGP community but even for stand-alone > routers. In this sense, you can implement RPKI in a device without > modifying any existing policy description. and this was codified in rfc 6811. now you get to compare the two, because any inconsistency would be bad. > 3) Documentation of non-standard BGP communities: Over the years, we > have seen a number of attempts to document and standardise providers > communities with less than great results. One particularly use case > (that I suffered) is when you have to merge two networks due to an > acquisition, standardised communities are very helpful. last para of rfc 7115 sec 5 Validity state signaling SHOULD NOT be accepted from a neighbor AS. The validity state of a received announcement has only local scope due to issues such as scope of trust, RPKI synchrony, and management of local trust anchors [LTA-USE]. > And lets not forget: Running Code: Last but not least=E2=80=A6the draft h= as > been delayed more than what it should and several implementations > (including two from Cisco) has running code + documentation + > training. As we are pushing to improve adoption of RPKI, I rather > spend time adding the missing pieces that removing what is not > broken=E2=80=A6although the need may not be obvious for everyone. actually, code removal is not an evil, quite the opposite. but, as i said > i do not support publication. i am not strongly opposed. it's just > one more bit of ietf work that is not obviously needed. randy From nobody Mon May 5 10:12:42 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552521A0177 for ; Mon, 5 May 2014 10:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J84xZ08nOTf7 for ; Mon, 5 May 2014 10:12:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) by ietfa.amsl.com (Postfix) with ESMTP id AF99B1A00D7 for ; Mon, 5 May 2014 10:12:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WhMRN-0003YF-5r; Mon, 05 May 2014 17:12:33 +0000 Date: Mon, 05 May 2014 19:12:34 +0200 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/q7xL43Bb1c26cnu9p8f75tpKSlg Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:12:40 -0000 >>>>> 3.14 While the trust level of a route should be determined by the >>>>> BGPsec protocol, local routing preference and policy MUST then >>>>> be applied to best path and other routing decisions. Such >>>>> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. >>>>> ... >>>>> 3.17 If a BGPsec design makes use of a security infrastructure, that >>>>> infrastructure SHOULD enable each network operator to select >>>>> the entities it will trust when authenticating data in the >>>>> security infrastructure. See, for example, >>>>> [I-D.ietf-sidr-ltamgmt]. >>> >>> What about adding that "the connection to this security infrastructure >>> MUST be through a secure channel"? > > it's done via rcynic and/or rpki-to-rtr, right? depending on where in > the process you are... presuming the process looks like: > publication-point - gatherer - cache - router > (rcynic) (rcynic) (rpki-rtr) apologies to roque. some external data were indeed what was meant (an rpki-like thing is an example), and was inteneded by "security infrastructure." the authenticity of those data is an issue. we might say so in sec cons. randy From nobody Mon May 5 10:14:48 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234C51A02E1 for ; Mon, 5 May 2014 10:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVWk8w3pDXJb for ; Mon, 5 May 2014 10:14:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 411481A00D7 for ; Mon, 5 May 2014 10:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1216; q=dns/txt; s=iport; t=1399310082; x=1400519682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=++6PDVpuj+irm3x/s0Gfu+dL3JqknS8pg0IT4yTqUUk=; b=LW2QFQp3FEDVKh5ldcX22qS3XhYEIEkEvEDisZnnmJIb/JdQJ+71OC0n bPNKCtaw4RZ6cQSz7IjY0bQGb0ReR5ht193qfQb5jI7w95N/ubvtSOKWn V84DyElOS+UvUHPKxoPbNlweVzhCmloybaMU09/2CgWhpSqgB3j65jdgl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgHAO/FZ1OtJV2d/2dsb2JhbABZgwaBJ6oxAQIFAZoMgRgWdIIlAQEBAwE6PwULAgEINhAyJQIEDgWIOQjLbheFVoNbhFMbMweDKoEVBJk0knSDNIIv X-IronPort-AV: E=Sophos;i="4.97,989,1389744000"; d="scan'208";a="322580719" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 05 May 2014 17:14:41 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s45HEf3Z015117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 17:14:41 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 5 May 2014 12:14:41 -0500 From: "Roque Gagliano (rogaglia)" To: Randy Bush Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: AQHPaH23g+Y1On9pTU2gzdMektI5tA== Date: Mon, 5 May 2014 17:14:41 +0000 Message-ID: <24A5BD7D-7206-4801-8450-B4C28E5ABF47@cisco.com> References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.144.166] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Hpkn3SRafIS8HizYBF2SvI6iL84 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 17:14:47 -0000 On May 5, 2014, at 9:41 AM, Randy Bush wrote: >>>>> 3.14 While the trust level of a route should be determined by the >>>>> BGPsec protocol, local routing preference and policy MUST then >>>>> be applied to best path and other routing decisions. Such >>>>> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. >>>>> ... >>>>> 3.17 If a BGPsec design makes use of a security infrastructure, tha= t >>>>> infrastructure SHOULD enable each network operator to select >>>>> the entities it will trust when authenticating data in the >>>>> security infrastructure. See, for example, >>>>> [I-D.ietf-sidr-ltamgmt]. >>=20 >> What about adding that "the connection to this security infrastructure >> MUST be through a secure channel"? >=20 > connection from what? mains power? :) > this is about routers speaking bgpsec. imiho, it would be ill-adviised > to start down the rat-hole of operational practices of router management > for which there is no proof of termination. I was thinking on the issues we had on origin with adding security for RTR = and to better document this requirement early on. Roque > randy From nobody Mon May 5 11:58:03 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DF31A0478 for ; Mon, 5 May 2014 11:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDJxZqkRe2_x for ; Mon, 5 May 2014 11:57:54 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id F099E1A045B for ; Mon, 5 May 2014 11:57:53 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id AF6C35934; Mon, 5 May 2014 18:57:50 +0000 (UTC) Date: Mon, 5 May 2014 18:57:50 +0000 From: heasley To: Randy Bush Message-ID: <20140505185750.GA43515@shrubbery.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Puw4gWemh8yQ4OH8NgDV4rGwf_Q Cc: sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:58:00 -0000 Mon, May 05, 2014 at 07:03:46PM +0200, Randy Bush: > > And lets not forget: Running Code: Last but not least???the draft has > > been delayed more than what it should and several implementations > > (including two from Cisco) has running code + documentation + > > training. As we are pushing to improve adoption of RPKI, I rather > > spend time adding the missing pieces that removing what is not > > broken???although the need may not be obvious for everyone. > > actually, code removal is not an evil, quite the opposite. esp. when 1 company has 2 (two, zwei, dos!) implementations. From nobody Wed May 7 08:35:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8B91A0311 for ; Wed, 7 May 2014 08:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1O1qjWie5CW for ; Wed, 7 May 2014 08:35:02 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id B77D81A02EA for ; Wed, 7 May 2014 08:35:02 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8F58628B004A for ; Wed, 7 May 2014 11:34:58 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 8A0C81F8055; Wed, 7 May 2014 11:34:58 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 May 2014 11:34:58 -0400 Message-Id: <0BCE0C50-1CDC-491D-8590-983229C39817@tislabs.com> To: sidr wg list Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/oY3hJg2-dWBEx1xH-YViwx9XqOA Cc: Sandra Murphy Subject: [sidr] ENDING FRIDAY: WGLC and working group adoption call X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:35:07 -0000 This is friendly reminder that we have two decisions underway at this time: An adoption call for draft-huston-rpki-validation-01.txt: http://www.ietf.org/mail-archive/web/sidr/current/msg06530.html A working group last call (WGLC) for http://www.ietf.org/mail-archive/web/sidr/current/msg06532.html Read up, speak up. --Sandy, speaking as one of the wg co-chairs From nobody Fri May 9 11:23:11 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A47B1A0316; Fri, 9 May 2014 11:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI3Q26QEq4VL; Fri, 9 May 2014 11:23:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D91531A00D7; Fri, 9 May 2014 11:23:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140509182306.12241.57263.idtracker@ietfa.amsl.com> Date: Fri, 09 May 2014 11:23:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/3JGzU6CZQcm3fFL7YGUZbV6Izcw Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-as-migration-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 18:23:08 -0000 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 : BGPSec Considerations for AS Migration Authors : Wesley George Sandy Murphy Filename : draft-ietf-sidr-as-migration-01.txt Pages : 14 Date : 2014-05-09 Abstract: This draft discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-as-migration-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 9 16:13:23 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A611A00D4 for ; Fri, 9 May 2014 16:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZP9zV7imwCD for ; Fri, 9 May 2014 16:13:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0FC1A008A for ; Fri, 9 May 2014 16:13:19 -0700 (PDT) Received: from dhcp89-089-042.bbn.com ([128.89.89.42]:58353) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Wityb-0009KM-Jo for sidr@ietf.org; Fri, 09 May 2014 19:13:13 -0400 Message-ID: <536D6109.6090504@bbn.com> Date: Fri, 09 May 2014 19:13:13 -0400 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/BPsZvaEc20MzjmdLEK8WLs2-OfE Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 23:13:21 -0000 I'm not yet convinced that the operational costs justify the potential weakening of security. So I do not support adoption of the document as is. I would like to see it split into 2 drafts -- one describing the problem(s) (perhaps including the aspects Rob has mentioned) with an analysis of their likely frequency/impact/cost; and then if the WG agrees one is needed, a separate draft for a solution that would include an assessment of any reduction in security that results from using this solution. Perhaps there are solutions that don't require modifying the RPKI validation. I'm willing to review the resulting drafts. On 4/25/14 12:05 PM, Sandra Murphy wrote: > The authors of draft-huston-rpki-validation-01.txt, RPKI Validation Reconsidered, have requested wg adoption. > > See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > > Please do respond to the list as to whether you support the wg adopting this as a work item. You do not need to comment on the content of this draft at this time. You are asked to indicate if you think that this is work that the wg should be doing and whether this draft is an acceptable starting point. Adding whether you can/will review or not is useful. > > Note that active support is required for adoption. Silence is a vote against adoption. > > This adoption call will end on 9 May 2014. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Fri May 9 20:08:49 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5B51A0135 for ; Fri, 9 May 2014 20:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NexyFerOM8k for ; Fri, 9 May 2014 20:08:35 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 308821A011A for ; Fri, 9 May 2014 20:08:35 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so4776037wes.32 for ; Fri, 09 May 2014 20:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=taCL6vBmrTZA2zioU2AsspD5d22Ri5WbHbaX4s2NAMo=; b=c/tnP04PnoqpKiX+uGwF3l7EylIRF6WxbMAoM0gJU42EDDVNnvCzggrnlQ05hWyLn4 Rf6dxBOwHabbKXbMSEiVHl357E5NDdcbw47gB6sniiEdxKx22+T+ZIx3QQHehya9PWHq ZfJXtDSC4/YipHGjYfOzHkF+iNyJxyXJ6i7fBXhqUdM5JcSeDAXyhiBUMQ96xMQ+c5Ha F5p+XIFsG3Kxl+E+4E/S8wU34yLVEeeSUZtNeEHB3UqQPFtquZ0hJc0eiio4t3JZstDp lqwQFZP/JWzra44+E8WTS3K0vvk7EfyvXs3v+vEmux/8bXLxKn+Aeaa77LSyaqL5px6G 4oYA== MIME-Version: 1.0 X-Received: by 10.180.93.163 with SMTP id cv3mr5848783wib.3.1399691309665; Fri, 09 May 2014 20:08:29 -0700 (PDT) Received: by 10.216.100.197 with HTTP; Fri, 9 May 2014 20:08:29 -0700 (PDT) In-Reply-To: <20140429220119.47384C6B182@minas-ithil.hactrn.net> References: <20140429220119.47384C6B182@minas-ithil.hactrn.net> Date: Fri, 9 May 2014 23:08:29 -0400 Message-ID: From: Matthew Lepinski To: Rob Austein Content-Type: multipart/alternative; boundary=f46d043895394ed40604f90307f1 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/17qy_GPHDUv6BwWMpK2mYM9J80M Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 03:08:41 -0000 --f46d043895394ed40604f90307f1 Content-Type: text/plain; charset=UTF-8 I think that Rob makes an excellent point. I have no problem with making this draft the focal point of discussions about changing RPKI path validation. Indeed, I greatly appreciate the effort that Geoff and George have put into articulating the operational concern with RFCs 3779 and 6487. There is clearly a CA operational concern here and I think it is good for the working group to take these types of concerns seriously. However, I am not yet sold that the solution outlined in this draft is necessary (or is the best way of addressing the problem). I think it is possible that the cost [in complexity, risk, changes to deployed code] of the proposed solution is not worth the benefit. At this point in time, I think it is important to prematurely commit to a solution. (Indeed, based on discussions on the list, I think there was - even quite recently -- some confusion about the problem that needs to be solved.) Personally, I don't think it is especially important whether or not we adopt the draft, as long as adopting the draft isn't interpreted as consensus that the particular solution specified in the draft is definitely the best way forward. That is, Adoption is generally a commitment by the working group to spend time working on a particular topic and a transfer of change control to the working group. Both of these I am comfortable with. - Matt Lepinski On Tue, Apr 29, 2014 at 6:01 PM, Rob Austein wrote: > Unfortunately, the binary adopt-or-not question is insufficiently > nuanced for a case like this. > > I think the WG needs a work item to explore the issue of decoupling > RFC-3779-style[*] path validation from certificate validation. It may > be that at the end of that process we will decide not to change the > base specification, but in addition to whatever sympathy the WG might > feel for CA operators near the root of the tree, I think there may be > some real issues lurking here with respect to out-of-order validation > problems and we need to explore them further. > > I really do not know at this point whether the result of the work we > need to do on this will be a publishable document or not. > > I do not support the addition of joins in the RPKI tree, full stop. > > The WG chairs asked a couple of specific questions: > > > You are asked to indicate if you think that this is work that the wg > > should be doing > > Yes, with the proviso that the end result may be a decision to leave > well enough alone, in which case the only thing we might publish would > be a history of our decision not to change anything. > > > and whether this draft is an acceptable starting point. > > As a problem statement, yes. With no intent to give offense, it's > nowhere near being suitable as an amended specification, but such a > document would be premature at this stage in any case. > > Starting with a problem statement seems appropriate, so long as we > retain the option of keeping the current specification. Yes, this > might end up meaning that, after years of work, the WG concludes that > we should not change the specification. Sometimes you have to work on > something for a while before you know whether you should be doing it. > > [*] "RFC-3779-style" because, if we change it, it won't be RFC 3779 > anymore. It might well reuse all of RFC 3779's syntax and most of > RFC 3779's semantics, but since there is deployed code that thinks > it knows how to validate with the current semantics, at minimum I > would want the hypothetical new thing to use different extnID OID > values to flag the change. So, strictly speaking, this would be a > new set of X.509v3 extensions that just happen to look exactly > like the ones from RFC 3779. > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --f46d043895394ed40604f90307f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that Rob makes an excellent point.

I have no problem with making this draft the focal point of discussions abo= ut changing RPKI path validation. Indeed, I greatly appreciate the effort t= hat Geoff and George have put into articulating the operational concern wit= h RFCs 3779 and 6487. There is clearly a CA operational concern here and I = think it is good for the working group to take these types of concerns seri= ously.=C2=A0

However, I am not yet sold that the solution outlined in th= is draft is necessary (or is the best way of addressing the problem). =C2= =A0I think it is possible that the cost [in complexity, risk, changes to de= ployed code] of the proposed solution is not worth the benefit.=C2=A0
=
At this point in time, I think it is important to prematurely com= mit to a solution. (Indeed, based on discussions on the list, I think there= was - even quite recently -- some confusion about the problem that needs t= o be solved.)=C2=A0
=
Personally, I don't think it is especially important whether or not= we adopt the draft, as long as adopting the draft isn't interpreted as= consensus that the particular solution specified in the draft is definitel= y the best way forward. That is, Adoption is generally a commitment by the = working group to spend time working on a particular topic and a transfer of= change control to the working group. Both of these I am comfortable with.<= /div>
=
- Matt Lepinski


On Tue, Apr 29, 2014 at= 6:01 PM, Rob Austein <sra@hactrn.net> wrote:
Unfortunately, the binary adopt-or-not quest= ion is insufficiently
nuanced for a case like this.

I think the WG needs a work item to explore the issue of decoupling
RFC-3779-style[*] path validation from certificate validation. =C2=A0It may=
be that at the end of that process we will decide not to change the
base specification, but in addition to whatever sympathy the WG might
feel for CA operators near the root of the tree, I think there may be
some real issues lurking here with respect to out-of-order validation
problems and we need to explore them further.

I really do not know at this point whether the result of the work we
need to do on this will be a publishable document or not.

I do not support the addition of joins in the RPKI tree, full stop.

The WG chairs asked a couple of specific questions:

> You are asked to indicate if you think that this is work that the wg > should be doing

Yes, with the proviso that the end result may be a decision to leave<= br> well enough alone, in which case the only thing we might publish would
be a history of our decision not to change anything.

> and whether this draft is an acceptable starting point.

As a problem statement, yes. =C2=A0With no intent to give offense, it= 's
nowhere near being suitable as an amended specification, but such a
document would be premature at this stage in any case.

Starting with a problem statement seems appropriate, so long as we
retain the option of keeping the current specification. =C2=A0Yes, this
might end up meaning that, after years of work, the WG concludes that
we should not change the specification. =C2=A0Sometimes you have to work on=
something for a while before you know whether you should be doing it.

[*] "RFC-3779-style" because, if we change it, it won't be RF= C 3779
=C2=A0 =C2=A0 anymore. =C2=A0It might well reuse all of RFC 3779's synt= ax and most of
=C2=A0 =C2=A0 RFC 3779's semantics, but since there is deployed code th= at thinks
=C2=A0 =C2=A0 it knows how to validate with the current semantics, at minim= um I
=C2=A0 =C2=A0 would want the hypothetical new thing to use different extnID= OID
=C2=A0 =C2=A0 values to flag the change. =C2=A0So, strictly speaking, this = would be a
=C2=A0 =C2=A0 new set of X.509v3 extensions that just happen to look exactl= y
=C2=A0 =C2=A0 like the ones from RFC 3779.

_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--f46d043895394ed40604f90307f1-- From nobody Mon May 12 11:35:01 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE111A0785 for ; Mon, 12 May 2014 11:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2AeRVfcauLI for ; Mon, 12 May 2014 11:34:59 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.106.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9401A0783 for ; Mon, 12 May 2014 11:34:59 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 53CF6188147F1; Mon, 12 May 2014 13:34:49 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 0FF7218813597 for ; Mon, 12 May 2014 13:34:49 -0500 (CDT) Received: from [96.231.225.192] (port=49526 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wjv3o-0002zO-51 for sidr@ietf.org; Mon, 12 May 2014 13:34:48 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: Date: Mon, 12 May 2014 14:34:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> <20140404171253.E2CF21721C@thrintun.hactrn.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1Wjv3o-0002zO-51 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:49526 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/iRgORf0MO4mvlXf7NpWmuy-RwyM Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:35:00 -0000 On Apr 04, 2014, at 15:47, Geoff Huston wrote: >>=20 >> The authors of RFC 6487 can speak for themselves, but I think their >> intent was to avoid requests for "vanity names" (CN=3D"Joe's Pizza" >> instead of CN=3D"4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which = could >> be construed as eroding claims that the RPKI attests only to things >> like addresses and autonomous system numbers. >=20 > As I recall the discussion at the time was based around a desire to > avoid any implication that the CA was attesting as to the identity of = the > subject. i.e. the CA was explicitly not saying that the holder of the = public > key was the individual described int subject field (section 4.5 of = RFC6487). >=20 > There was also some convenience in using a subject name that was = linked > to the subject's public key, in so far as when the subject rolled keys > then the subject would request a new certificate and the issuer would > use a different subject name (section 4.5 once more). >=20 > Geoff Ah this last part I had glossed over. Would it make sense to have the = name that goes in the router certificate then be something like = =93ROUTER-#-32_bit_BGP_Identifier=94 where the # gets incremented = everytime there=92s a new key? For those that love hard coded lengths = this might be an issue if the # grows, but is that the only drawback? spt= From nobody Mon May 12 11:43:06 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA5A1A0745 for ; Mon, 12 May 2014 11:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7bYiMxYplOr for ; Mon, 12 May 2014 11:43:04 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 24A171A0728 for ; Mon, 12 May 2014 11:43:03 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gf5so2277346lab.10 for ; Mon, 12 May 2014 11:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tYdz+J99njFGTI+tWDzRy7wwoILejYjWvUWhhe1d0hE=; b=lqrAypO48sHx80bqCcWqXB3O8zhQa+Vy97pSGSBwDl6F7OueK6gTKX6kV6NXBFpaTo Y9UEMpyFjeemh3LViwGOj1E5WIhTcSBhBRFZ7FKP5IiAgKd8WNN4MsIA7pBfREkZKw1i Ocvt0tUpfUvY1hv/miA21HpiDw0mz1uUz7MOY07Q9+spjJuehW6qdz13fUHVvR8TnqUY mv/GzpmpAuXzHJ7zu2O8PANcvCXTdLp4hR83pq+nL5r6dYdOWjXnSOfquXxNyHdYUHMG w/dgfABw71enmp/E/q3EVZDoKoRobOg5B6nPXg215KrW0ByVR2gXoMEuuCcZJvtWzqs3 xOjw== MIME-Version: 1.0 X-Received: by 10.152.5.202 with SMTP id u10mr2961237lau.42.1399920177400; Mon, 12 May 2014 11:42:57 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.114.95.74 with HTTP; Mon, 12 May 2014 11:42:57 -0700 (PDT) In-Reply-To: <9487C4DF-EEAF-40FE-A9CE-768D38C91DA7@cisco.com> References: <9487C4DF-EEAF-40FE-A9CE-768D38C91DA7@cisco.com> Date: Mon, 12 May 2014 14:42:57 -0400 X-Google-Sender-Auth: oByNy2YEdY7DiKahP_W4dTvjit4 Message-ID: From: Christopher Morrow To: "Roque Gagliano (rogaglia)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/O-s6SlGv0cgKj_RERf2UECCjBhQ Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 18:43:06 -0000 On Mon, May 5, 2014 at 12:10 PM, Roque Gagliano (rogaglia) wrote: > Sandra, > > I support this document moving forward to the IESG. > > I read the document as part of the WGLC process and I believe the text is > ready for publication. > > My only question is a formality from Section 3 that says: > > " If a BGP router supports prefix origin validation and is configure for the > extensions defined in this document, the validation step SHOULD be performed > prior to any of the steps defined in the decision process of [RFC4271]." > > (Roque) Should this document specifically be labeled as an update to > RFC4271? doesn't a prefix-list (or other route-filter) happen prior to the decision process as well though? > > Regards, > Roque > > On Apr 26, 2014, at 1:53 AM, Sandra Murphy wrote: > > The authors of BGP Prefix Origin Validation State Extended Community, > draft-ietf-sidr-origin-validation-signaling-04 have requested a WGLC. > > This message begins a two week WGLC, to end on 9 May 2014. > > The draft is available at > http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling. > > Please do send comments to the list, indicating whether you do or do not > believe that the draft is ready for publication. > > --Sandy, speaking as wg co-chair > _______________________________________________ > 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 nobody Mon May 12 13:03:59 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C161A0741 for ; Mon, 12 May 2014 13:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz6EaunXdIZE for ; Mon, 12 May 2014 13:03:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id B09921A0727 for ; Mon, 12 May 2014 13:03:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WjwRv-0006TF-PQ; Mon, 12 May 2014 20:03:48 +0000 Date: Mon, 12 May 2014 22:03:42 +0200 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> <20140404171253.E2CF21721C@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/pWCWfQS-kIplMXxGU3ei4DReeSk Cc: sidr@ietf.org Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 20:03:56 -0000 > Would it make sense to have the name that goes in the router > certificate then be something like =E2=80=9CROUTER-#-32_bit_BGP_Identifie= r=E2=80=9D > where the # gets incremented everytime there=E2=80=99s a new key? For th= ose > that love hard coded lengths this might be an issue if the # grows, > but is that the only drawback? if you have to go down that path, and i am unsure of it, then use a fixed length router# and wrap. and keep in mind that bgp_id is unique only within an AS. randy From nobody Mon May 12 15:54:16 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280A51A07A7 for ; Mon, 12 May 2014 15:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OSbhvNBvyKn for ; Mon, 12 May 2014 15:54:13 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [64.5.50.5]) by ietfa.amsl.com (Postfix) with ESMTP id B62BE1A078C for ; Mon, 12 May 2014 15:54:13 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 7149B47E90576; Mon, 12 May 2014 17:54:07 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway04.websitewelcome.com (Postfix) with ESMTP id DB76047E90274 for ; Mon, 12 May 2014 17:54:06 -0500 (CDT) Received: from [96.231.225.192] (port=50638 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wjz6k-00041Q-5M; Mon, 12 May 2014 17:54:06 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: Date: Mon, 12 May 2014 18:54:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0E43F204-1FD6-4D92-AE6A-F0B6EDA93FFC@ieca.com> References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> <20140404171253.E2CF21721C@thrintun.hactrn.net> To: Randy Bush X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1Wjz6k-00041Q-5M X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:50638 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/116Mz6ughLNp8fEnO0gJ1rmw9Pk Cc: sidr@ietf.org Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 22:54:15 -0000 On May 12, 2014, at 16:03, Randy Bush wrote: >> Would it make sense to have the name that goes in the router >> certificate then be something like =93ROUTER-#-32_bit_BGP_Identifier=94= >> where the # gets incremented everytime there=92s a new key? For = those >> that love hard coded lengths this might be an issue if the # grows, >> but is that the only drawback? >=20 > if you have to go down that path, and i am unsure of it, then use a > fixed length router# and wrap. I could live with that make it like 000 an wrap 999. If you have to = rekey that often =85. > and keep in mind that bgp_id is unique only within an AS. yep that=92s true. spt= From nobody Mon May 12 18:50:20 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991001A07DD for ; Mon, 12 May 2014 18:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tKZktEz_aNT for ; Mon, 12 May 2014 18:50:15 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.93.164.12]) by ietfa.amsl.com (Postfix) with ESMTP id 20B601A03AB for ; Mon, 12 May 2014 18:50:15 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 500) id D941B4033D45F; Mon, 12 May 2014 20:50:08 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway11.websitewelcome.com (Postfix) with ESMTP id B94E44033D437 for ; Mon, 12 May 2014 20:50:08 -0500 (CDT) Received: from [96.231.225.192] (port=51469 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wk1r5-00008E-Nk; Mon, 12 May 2014 20:50:07 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: Date: Mon, 12 May 2014 21:50:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25567F3D-6C59-48D2-B99F-A88F402D3058@ieca.com> References: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> To: "George, Wes" X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1Wk1r5-00008E-Nk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:51469 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/z84WIxIKx5V2hN0pWEEPbGLmyCk Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 01:50:16 -0000 Wes, Randy and I bashed some text around; would this work: When it is decided that an active router key is to be revoked, the process of requesting the CA to revoke, the process of the CA actually revoking the router=92s certificate, and then the process of rekeying/renewing the router=92s certificate, (possibly distributing a new key and certificate to the router), and distributing the status takes time during which the operator must decide how they wish to maintain continuity of operations, with or without the compromised private key, or whether they wish to to bring the router offline to address the compromise. =20 Keeping the router operational and BGPsec-speaking is the ideal goal, but if operational practices do not allow this then reconfiguring the router to disabling BGPsec is likely preferred to bringing the router offline. Routers which support more than one private key, where one is operational and the other(s) are soon-to-be-opertional, facilitate revocation events because the operator can configure the router to make a soon-to-be-operational key operational, request revocation of the compromised key, and then make a new soon-to-be-operational key, all hopefully without needing to take offline or reboot the router. For routers which support only one operational key, the operators should create or install the new private key, and then request revocation of the compromised private key. spt On Apr 30, 2014, at 16:26, George, Wes = wrote: > This update address my comments on the document, and I think it=92s in = good > shape now. The new section 4 is really good. The one thing I might > recommend adding for completeness is a few additional words around > revocation process at the end of section 4, specifically if there is = any > difference or recommendation in process for make before break = (provision > new key, then revoke old) or when that may not be a good idea compared > with the risk of outage caused by revoking and then rekeying. It may = be as > simple as saying something similar to the above about whether a router > supports multiple private keys or not, but I=92m not sure if there are > additional considerations that need to be discussed. >=20 > Thanks, >=20 > Wes >=20 >=20 >=20 > On 4/29/14, 10:14 AM, "Sean Turner" wrote: >=20 >> Hi, >>=20 >> This version includes a new section 4 that addresses key management >> (i.e., keep a timer to make sure your cert doesn=92t expire). = There=92s also >> some editorial/readability corrections. Please review as the authors >> think this version pretty much wraps up what we wanted to say. >>=20 >> spt >>=20 >> On Apr 29, 2014, at 10:10, internet-drafts@ietf.org wrote: >>=20 >>>=20 >>> 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. >>>=20 >>> Title : Router Keying for BGPsec >>> Authors : Sean Turner >>> Keyur Patel >>> Randy Bush >>> Filename : draft-ietf-sidr-rtr-keying-05.txt >>> Pages : 10 >>> Date : 2014-04-29 >>>=20 >>> Abstract: >>> BGPsec-speaking routers are provisioned with private keys to sign = BGP >>> messages; the corresponding public keys are published in the global >>> RPKI (Resource Public Key Infrastructure) thereby enabling >>> verification of BGPsec messages. This document describes two ways = of >>> provisioning the public-private key-pairs: router-driven and >>> operator-driven. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-05 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-05 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From nobody Tue May 13 09:16:32 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECEA1A0115 for ; Tue, 13 May 2014 09:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpjh3qbVgncC for ; Tue, 13 May 2014 09:16:28 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 525A51A0102 for ; Tue, 13 May 2014 09:16:28 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,1044,1389762000"; d="scan'208";a="301681438" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 May 2014 12:16:02 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 13 May 2014 12:16:21 -0400 From: "George, Wes" To: Sean Turner Date: Tue, 13 May 2014 12:16:27 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt Thread-Index: Ac9uxq2Y+/S6dKIgQYm2V9MdJFaa9g== Message-ID: References: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> <25567F3D-6C59-48D2-B99F-A88F402D3058@ieca.com> In-Reply-To: <25567F3D-6C59-48D2-B99F-A88F402D3058@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/md_cdUx-68jrVsz0MVBbRcgughg Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:16:30 -0000 V29ya3MgZm9yIG1lLg0KDQpUaG91Z2ggSeKAmW0gbm90IHN1cmUgdGhhdCB0aGVyZSBpcyBhIGh1 Z2UgZGlzdGluY3Rpb24gYmV0d2VlbiBkaXNhYmxpbmcNCkJHUFNlYyBhbmQgdGFraW5nIHRoZSBy b3V0ZXIgb2ZmbGluZSBzaW5jZSBkaXNhYmxpbmcgQkdQU2VjIHdvdWxkIHRyaWdnZXINCm5laWdo Ym9yIHNlc3Npb24gcmVzZXRzIGZvciBjYXBhYmlsaXR5IHJlbmVnb3RpYXRpb24gdW5sZXNzIHdl 4oCZdmUNCnNwZWNpZmllZCBvdGhlcndpc2UgaW4gdGhlIHByb3RvY29sIGRvY3MgKGRvZXNu4oCZ dCBsb29rIGxpa2UgaXQgaW4gbXkgcXVpY2sNCnNraW0pLCBhbmQgbW9zdCBsaWtlbHkgZm9yY2Ug YW4gZW50aXJlbHkgdW5ncmFjZWZ1bCBzZXQgb2YgdXBkYXRlcyBhcyB0aGUNCm5laWdoYm9ycyBy ZS1zZW5kIHRoZWlyIGFubm91bmNlbWVudHMgd2l0aCBBU19QQVRIIGluc3RlYWQgb2YgQkdQU0VD X1BBVEguDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KDQpPbiA1LzEyLzE0LCA5OjUwIFBNLCAiU2Vh biBUdXJuZXIiIDxUdXJuZXJTQGllY2EuY29tPiB3cm90ZToNCg0KPldlcywNCj4NCj5SYW5keSBh bmQgSSBiYXNoZWQgc29tZSB0ZXh0IGFyb3VuZDsgd291bGQgdGhpcyB3b3JrOg0KPg0KPldoZW4g aXQgaXMgZGVjaWRlZCB0aGF0IGFuIGFjdGl2ZSByb3V0ZXIga2V5IGlzIHRvIGJlIHJldm9rZWQs IHRoZQ0KPnByb2Nlc3Mgb2YgcmVxdWVzdGluZyB0aGUgQ0EgdG8gcmV2b2tlLCB0aGUgcHJvY2Vz cyBvZiB0aGUgQ0ENCj5hY3R1YWxseSByZXZva2luZyB0aGUgcm91dGVy4oCZcyBjZXJ0aWZpY2F0 ZSwgYW5kIHRoZW4gdGhlIHByb2Nlc3Mgb2YNCj5yZWtleWluZy9yZW5ld2luZyB0aGUgcm91dGVy 4oCZcyBjZXJ0aWZpY2F0ZSwgKHBvc3NpYmx5IGRpc3RyaWJ1dGluZyBhDQo+bmV3IGtleSBhbmQg Y2VydGlmaWNhdGUgdG8gdGhlIHJvdXRlciksIGFuZCBkaXN0cmlidXRpbmcgdGhlIHN0YXR1cw0K PnRha2VzIHRpbWUgZHVyaW5nIHdoaWNoIHRoZSBvcGVyYXRvciBtdXN0IGRlY2lkZSBob3cgdGhl eSB3aXNoDQo+dG8gbWFpbnRhaW4gY29udGludWl0eSBvZiBvcGVyYXRpb25zLCB3aXRoIG9yIHdp dGhvdXQgdGhlIGNvbXByb21pc2VkDQo+cHJpdmF0ZSBrZXksIG9yIHdoZXRoZXIgdGhleSB3aXNo IHRvIHRvIGJyaW5nIHRoZSByb3V0ZXIgb2ZmbGluZSB0bw0KPmFkZHJlc3MgdGhlIGNvbXByb21p c2UuDQo+DQo+S2VlcGluZyB0aGUgcm91dGVyIG9wZXJhdGlvbmFsIGFuZCBCR1BzZWMtc3BlYWtp bmcgaXMgdGhlIGlkZWFsIGdvYWwsDQo+YnV0IGlmIG9wZXJhdGlvbmFsIHByYWN0aWNlcyBkbyBu b3QgYWxsb3cgdGhpcyB0aGVuIHJlY29uZmlndXJpbmcgdGhlDQo+cm91dGVyIHRvIGRpc2FibGlu ZyBCR1BzZWMgaXMgbGlrZWx5IHByZWZlcnJlZCB0byBicmluZ2luZyB0aGUgcm91dGVyDQo+b2Zm bGluZS4NCj4NCj5Sb3V0ZXJzIHdoaWNoIHN1cHBvcnQgbW9yZSB0aGFuIG9uZSBwcml2YXRlIGtl eSwgd2hlcmUgb25lIGlzDQo+b3BlcmF0aW9uYWwgYW5kIHRoZSBvdGhlcihzKSBhcmUgc29vbi10 by1iZS1vcGVydGlvbmFsLCBmYWNpbGl0YXRlDQo+cmV2b2NhdGlvbiBldmVudHMgYmVjYXVzZSB0 aGUgb3BlcmF0b3IgY2FuIGNvbmZpZ3VyZSB0aGUgcm91dGVyIHRvIG1ha2UNCj5hIHNvb24tdG8t YmUtb3BlcmF0aW9uYWwga2V5IG9wZXJhdGlvbmFsLCByZXF1ZXN0IHJldm9jYXRpb24gb2YgdGhl DQo+Y29tcHJvbWlzZWQga2V5LCBhbmQgdGhlbiBtYWtlIGEgbmV3IHNvb24tdG8tYmUtb3BlcmF0 aW9uYWwga2V5LCBhbGwNCj5ob3BlZnVsbHkgd2l0aG91dCBuZWVkaW5nIHRvIHRha2Ugb2ZmbGlu ZSBvciByZWJvb3QgdGhlIHJvdXRlci4gIEZvcg0KPnJvdXRlcnMgd2hpY2ggc3VwcG9ydCBvbmx5 IG9uZSBvcGVyYXRpb25hbCBrZXksIHRoZSBvcGVyYXRvcnMgc2hvdWxkDQo+Y3JlYXRlIG9yIGlu c3RhbGwgdGhlIG5ldyBwcml2YXRlIGtleSwgYW5kIHRoZW4gcmVxdWVzdCByZXZvY2F0aW9uIG9m DQo+dGhlIGNvbXByb21pc2VkIHByaXZhdGUga2V5Lg0KPg0KPnNwdA0KPg0KPk9uIEFwciAzMCwg MjAxNCwgYXQgMTY6MjYsIEdlb3JnZSwgV2VzIDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPiB3 cm90ZToNCj4NCj4+IFRoaXMgdXBkYXRlIGFkZHJlc3MgbXkgY29tbWVudHMgb24gdGhlIGRvY3Vt ZW50LCBhbmQgSSB0aGluayBpdOKAmXMgaW4NCj4+Z29vZA0KPj4gc2hhcGUgbm93LiBUaGUgbmV3 IHNlY3Rpb24gNCBpcyByZWFsbHkgZ29vZC4gVGhlIG9uZSB0aGluZyBJIG1pZ2h0DQo+PiByZWNv bW1lbmQgYWRkaW5nIGZvciBjb21wbGV0ZW5lc3MgaXMgYSBmZXcgYWRkaXRpb25hbCB3b3JkcyBh cm91bmQNCj4+IHJldm9jYXRpb24gcHJvY2VzcyBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gNCwgc3Bl Y2lmaWNhbGx5IGlmIHRoZXJlIGlzIGFueQ0KPj4gZGlmZmVyZW5jZSBvciByZWNvbW1lbmRhdGlv biBpbiBwcm9jZXNzIGZvciBtYWtlIGJlZm9yZSBicmVhayAocHJvdmlzaW9uDQo+PiBuZXcga2V5 LCB0aGVuIHJldm9rZSBvbGQpIG9yIHdoZW4gdGhhdCBtYXkgbm90IGJlIGEgZ29vZCBpZGVhIGNv bXBhcmVkDQo+PiB3aXRoIHRoZSByaXNrIG9mIG91dGFnZSBjYXVzZWQgYnkgcmV2b2tpbmcgYW5k IHRoZW4gcmVrZXlpbmcuIEl0IG1heSBiZQ0KPj5hcw0KPj4gc2ltcGxlIGFzIHNheWluZyBzb21l dGhpbmcgc2ltaWxhciB0byB0aGUgYWJvdmUgYWJvdXQgd2hldGhlciBhIHJvdXRlcg0KPj4gc3Vw cG9ydHMgbXVsdGlwbGUgcHJpdmF0ZSBrZXlzIG9yIG5vdCwgYnV0IEnigJltIG5vdCBzdXJlIGlm IHRoZXJlIGFyZQ0KPj4gYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyB0aGF0IG5lZWQgdG8gYmUg ZGlzY3Vzc2VkLg0KPj4NCj4+IFRoYW5rcywNCj4+DQo+PiBXZXMNCj4+DQo+Pg0KPj4NCj4+IE9u IDQvMjkvMTQsIDEwOjE0IEFNLCAiU2VhbiBUdXJuZXIiIDxUdXJuZXJTQGllY2EuY29tPiB3cm90 ZToNCj4+DQo+Pj4gSGksDQo+Pj4NCj4+PiBUaGlzIHZlcnNpb24gaW5jbHVkZXMgYSBuZXcgc2Vj dGlvbiA0IHRoYXQgYWRkcmVzc2VzIGtleSBtYW5hZ2VtZW50DQo+Pj4gKGkuZS4sIGtlZXAgYSB0 aW1lciB0byBtYWtlIHN1cmUgeW91ciBjZXJ0IGRvZXNu4oCZdCBleHBpcmUpLiAgVGhlcmXigJlz DQo+Pj5hbHNvDQo+Pj4gc29tZSBlZGl0b3JpYWwvcmVhZGFiaWxpdHkgY29ycmVjdGlvbnMuICBQ bGVhc2UgcmV2aWV3IGFzIHRoZSBhdXRob3JzDQo+Pj4gdGhpbmsgdGhpcyB2ZXJzaW9uIHByZXR0 eSBtdWNoIHdyYXBzIHVwIHdoYXQgd2Ugd2FudGVkIHRvIHNheS4NCj4+Pg0KPj4+IHNwdA0KPj4+ DQo+Pj4gT24gQXByIDI5LCAyMDE0LCBhdCAxMDoxMCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IHdyb3RlOg0KPj4+DQo+Pj4+DQo+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+PiBkaXJlY3Rvcmllcy4NCj4+ Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2VjdXJlIEludGVyLURvbWFpbiBS b3V0aW5nIFdvcmtpbmcNCj4+Pj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+DQo+Pj4+ICAgICAg IFRpdGxlICAgICAgICAgICA6IFJvdXRlciBLZXlpbmcgZm9yIEJHUHNlYw0KPj4+PiAgICAgICBB dXRob3JzICAgICAgICAgOiBTZWFuIFR1cm5lcg0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICBLZXl1ciBQYXRlbA0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBSYW5keSBCdXNoDQo+ Pj4+ICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNpZHItcnRyLWtleWluZy0wNS50 eHQNCj4+Pj4gICAgIFBhZ2VzICAgICAgICAgICA6IDEwDQo+Pj4+ICAgICBEYXRlICAgICAgICAg ICAgOiAyMDE0LTA0LTI5DQo+Pj4+DQo+Pj4+IEFic3RyYWN0Og0KPj4+PiAgQkdQc2VjLXNwZWFr aW5nIHJvdXRlcnMgYXJlIHByb3Zpc2lvbmVkIHdpdGggcHJpdmF0ZSBrZXlzIHRvIHNpZ24gQkdQ DQo+Pj4+ICBtZXNzYWdlczsgdGhlIGNvcnJlc3BvbmRpbmcgcHVibGljIGtleXMgYXJlIHB1Ymxp c2hlZCBpbiB0aGUgZ2xvYmFsDQo+Pj4+ICBSUEtJIChSZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJh c3RydWN0dXJlKSB0aGVyZWJ5IGVuYWJsaW5nDQo+Pj4+ICB2ZXJpZmljYXRpb24gb2YgQkdQc2Vj IG1lc3NhZ2VzLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdHdvIHdheXMgb2YNCj4+Pj4gIHBy b3Zpc2lvbmluZyB0aGUgcHVibGljLXByaXZhdGUga2V5LXBhaXJzOiByb3V0ZXItZHJpdmVuIGFu ZA0KPj4+PiAgb3BlcmF0b3ItZHJpdmVuLg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyLXJ0ci1rZXlpbmcvDQo+Pj4+DQo+ Pj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4+PiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpZHItcnRyLWtleWluZy0wNQ0K Pj4+Pg0KPj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6DQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2lk ci1ydHIta2V5aW5nLTA1DQo+Pj4+DQo+Pj4+DQo+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj4+IHN1Ym1pc3Np b24NCj4+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pj4NCj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+Pj4+ IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3Rvcmllczog aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPj4+PiBvciBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzaWRyIG1haWxpbmcgbGlzdA0KPj4+IHNp ZHJAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np ZHINCj4+DQo+Pg0KPj4gVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUNCj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdA0KPj50byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZA0KPj5zb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo aWNoIGl0IGlzIGFkZHJlc3NlZC4NCj4+SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkNCj4+bm90aWZpZWQgdGhhdCBhbnkg ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4NCj4+ aW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUt bWFpbCBpcw0KPj5zdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMNCj4+RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5DQo+PmRlbGV0ZSB0aGUgb3JpZ2lu YWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo+DQoNCg0K VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBX YXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQs IGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUg V2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBj b3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFu ZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRl bGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJp bnRvdXQuDQo= From nobody Tue May 13 09:23:19 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924BF1A0124 for ; Tue, 13 May 2014 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2zDBcJ2BZ6q for ; Tue, 13 May 2014 09:23:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1D81A0117 for ; Tue, 13 May 2014 09:23:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WkFTw-0000dX-5P; Tue, 13 May 2014 16:23:08 +0000 Date: Tue, 13 May 2014 18:23:07 +0200 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> <25567F3D-6C59-48D2-B99F-A88F402D3058@ieca.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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/LwZ7N4SsBx-_fOuoi9z1d-6UerM Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:23:17 -0000 > Though I=E2=80=99m not sure that there is a huge distinction between disa= bling > BGPSec and taking the router offline since disabling BGPSec would trigger > neighbor session resets for capability renegotiation unless we=E2=80=99ve > specified otherwise in the protocol docs (doesn=E2=80=99t look like it in= my quick > skim), and most likely force an entirely ungraceful set of updates as the > neighbors re-send their announcements with AS_PATH instead of BGPSEC_PATH. likely significantly shorter than whatever time it takes to revoke, get new cert, install, and then go through the bgp reset. though you will eventually do that anyway. randy From nobody Mon May 19 11:38:54 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB61A1A0104 for ; Mon, 19 May 2014 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkBCR6FVa8Af for ; Mon, 19 May 2014 11:38:51 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CAA1A00D7 for ; Mon, 19 May 2014 11:38:50 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id pv20so4461397lab.13 for ; Mon, 19 May 2014 11:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+qbBza/AkYcbyHuduV68YnoSe0t3dqjpTRLS3U4Sdfo=; b=JEfLfAAAX2z1i0AhozdcPWBRUMk98OygTwngBlRyUxrALgkAl4NEEjiv1gpfWhYaD4 Pv4VupFBbzz/jiN+h4uTArqHQERUa90fEVJOlzIgo9o7KF/gsdOeHnmLeg+FzUTIqJX0 Zd3jNZKnS3TjaSw61aqETunLeznVHivWsRK8RQTIBpJqLlBtfGf6eiXa0ZJUf1JI8Akv 2WE6pTuEf+06uo9D+nqXKfeC1+iA/0dquMNrt5vk5+KzBc2BVXAdOlBVK2Q9y3YEi8qx lojhEpCSVHoRVzi6zCrCSaQwdBVmUKGApRPjjs8rgzRTu+PwMugrAe+ftnecvNBKnhx+ oqTA== MIME-Version: 1.0 X-Received: by 10.152.42.194 with SMTP id q2mr27867657lal.39.1400524728871; Mon, 19 May 2014 11:38:48 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Mon, 19 May 2014 11:38:48 -0700 (PDT) In-Reply-To: References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> Date: Mon, 19 May 2014 14:38:48 -0400 X-Google-Sender-Auth: Q5UhVEq6X4Ya_R86nN917VEqUz0 Message-ID: From: Christopher Morrow To: Tim Bruijnzeels Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/d5bKsJM77Ey01u2JmtTtxlBJA0s Cc: "Sriram, Kotikalapudi" , George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 18:38:52 -0000 On Thu, Apr 17, 2014 at 11:35 AM, Tim Bruijnzeels wrote: > Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509} (TA certificate) > Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511} > Certificate 3: {10.0.0.0/20, AS64501, AS64509} It's unclear to me what would happen if you split this into a prefix/asn per cert and just carried more certs in your purse. Why would I not just add more certs to my purse? is there a particular reason to conglomerate these under the minimal number of certs? are we trying to minimize space in my purse? if so the purse is large, and the certs very small... I could 10x or 100x the number of certs here and be ok still. -chris From nobody Tue May 20 05:10:10 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3E1A0346 for ; Tue, 20 May 2014 05:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j-NlBDUq9w7 for ; Tue, 20 May 2014 05:10:06 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838241A033D for ; Tue, 20 May 2014 05:10:06 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id e53so479592eek.25 for ; Tue, 20 May 2014 05:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=omEO389kNiLdNBXmsd85zevxpJvugS8DDP06MSkVsxU=; b=0LPulnoOwZgTK+BQAyWZrUjEenpPe//QNd8Rus2WIOGKyVEvsHArut49Ca2JafNwBY nOVYAxor1uYWBZnnR21G+HFjmtdPdUIK1UqJ+17In9VYWjZd6KI/zSjLNedHuAlFUB2P 6Fn489jetaOSno8UenYPZJOWSUUCGr8GFwiLd0Uu2Npixkd/J7211lAApsNpSoBfuItq oTXg5FaBxiqi6s3ojhdiKzfqu6ZAUb8CPXYVsf6049Si9uDZAheOborsnze1ZZdQokOv gAQKcSMdtLmz1+E+w7ZXvvmyJGzDkPqtYmgYPBrTw49wbp+NRfbue8RR4/9Lbn6bXigC aNJw== X-Received: by 10.14.208.195 with SMTP id q43mr3536877eeo.42.1400587804837; Tue, 20 May 2014 05:10:04 -0700 (PDT) Received: from ?IPv6:2001:67c:2e8:13:204e:9ac5:dbfc:780f? ([2001:67c:2e8:13:204e:9ac5:dbfc:780f]) by mx.google.com with ESMTPSA id w48sm3420067eel.9.2014.05.20.05.10.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 May 2014 05:10:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Geoff Huston In-Reply-To: Date: Tue, 20 May 2014 22:10:03 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Dat65sZ5Xx6y-Qd8XsS7tVLLFmQ Cc: sidr wg list , "Sriram, Kotikalapudi" , George Michaelson Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 12:10:07 -0000 On 20 May 2014, at 4:38 am, Christopher Morrow = wrote: > On Thu, Apr 17, 2014 at 11:35 AM, Tim Bruijnzeels = wrote: >> Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509} (TA = certificate) >> Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511} >> Certificate 3: {10.0.0.0/20, AS64501, AS64509} >=20 > It's unclear to me what would happen if you split this into a > prefix/asn per cert and just carried more certs in your purse. Why > would I not just add more certs to my purse? is there a particular > reason to conglomerate these under the minimal number of certs? are we > trying to minimize space in my purse? if so the purse is large, and > the certs very small... I could 10x or 100x the number of certs here > and be ok still. For AS numbers thats an interesting approach, if you carry a single ASN = per cert then yes, there would be a whole lot more certs around (-ve), = but any discrepancy in AS registry records between parent and child = would be limited to just those ASns where there are such discrepancies = (+ve) However I'm unsure how you could or would apply this principle to IPv4 = addresses. And I'm even more unclear about IPv6.=20 However, in principle, the validation algorithm proposed in this draft = performs a validation function which is semantically equivalent to = breaking down each certificate into a collection of certificates, each = describing one element of the original number set, but this approach = does not require one to define the minimal unit of addresses in IPv6, = nor try to generate an enumeration of individual /128s (or even /64s!) = in IPv6, which I guess is a Good Thing. Geoff From nobody Tue May 20 06:41:30 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652171A0449 for ; Tue, 20 May 2014 06:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc7g0yJcW379 for ; Tue, 20 May 2014 06:41:27 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.56.148.14]) by ietfa.amsl.com (Postfix) with ESMTP id AC7801A0336 for ; Tue, 20 May 2014 06:41:27 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id E6C6A6E6E310B; Tue, 20 May 2014 08:41:26 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id B56A06E6E1B3B for ; Tue, 20 May 2014 08:41:20 -0500 (CDT) Received: from [198.180.150.142] (port=49465 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WmkIC-0004hj-4y for sidr@ietf.org; Tue, 20 May 2014 08:41:20 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sean Turner In-Reply-To: Date: Tue, 20 May 2014 09:41:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> <25567F3D-6C59-48D2-B99F-A88F402D3058@ieca.com> To: "sidr@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Exim-ID: 1WmkIC-0004hj-4y X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:49465 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/H2WMvYCBbvBLl9_pWrSu4VGFiSI Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 13:41:28 -0000 On May 13, 2014, at 12:23, Randy Bush wrote: >> Though I=92m not sure that there is a huge distinction between = disabling >> BGPSec and taking the router offline since disabling BGPSec would = trigger >> neighbor session resets for capability renegotiation unless we=92ve >> specified otherwise in the protocol docs (doesn=92t look like it in = my quick >> skim), and most likely force an entirely ungraceful set of updates as = the >> neighbors re-send their announcements with AS_PATH instead of = BGPSEC_PATH. >=20 > likely significantly shorter than whatever time it takes to revoke, = get > new cert, install, and then go through the bgp reset. though you will > eventually do that anyway. >=20 > randy I=92m going to throw in a new version and ask for WGLC. spt From nobody Tue May 20 06:49:34 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B621A0460 for ; Tue, 20 May 2014 06:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZm9BijfOzry for ; Tue, 20 May 2014 06:49:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C311A06F9 for ; Tue, 20 May 2014 06:49:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WmkQ4-00070V-Ka; Tue, 20 May 2014 13:49:29 +0000 Date: Tue, 20 May 2014 16:49:27 +0300 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: References: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> <25567F3D-6C59-48D2-B99F-A88F402D3058@ieca.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=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/O2FJ73wKTZjBdNbnUJNzgLps4-8 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 13:49:32 -0000 >>> Though I=E2=80=99m not sure that there is a huge distinction between di= sabling >>> BGPSec and taking the router offline since disabling BGPSec would trigg= er >>> neighbor session resets for capability renegotiation unless we=E2=80=99= ve >>> specified otherwise in the protocol docs (doesn=E2=80=99t look like it = in my quick >>> skim), and most likely force an entirely ungraceful set of updates as t= he >>> neighbors re-send their announcements with AS_PATH instead of BGPSEC_PA= TH. >>=20 >> likely significantly shorter than whatever time it takes to revoke, get >> new cert, install, and then go through the bgp reset. though you will >> eventually do that anyway. >>=20 > I=E2=80=99m going to throw in a new version and ask for WGLC. wfm randy From nobody Tue May 20 06:52:42 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0291A0336 for ; Tue, 20 May 2014 06:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTFmaACgUcfO for ; Tue, 20 May 2014 06:52:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532181A033D for ; Tue, 20 May 2014 06:52:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WmkT7-00071A-Gz; Tue, 20 May 2014 13:52:38 +0000 Date: Tue, 20 May 2014 16:52:36 +0300 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/jn5WeWp7g9-4R1tszASEoBNYGB4 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 13:52:40 -0000 funny. datatracker does not show wglc for this document randy, trying to time that small fix for roque From nobody Tue May 20 07:06:01 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7BF1A06FC; Tue, 20 May 2014 07:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sbg7jkkQU7e; Tue, 20 May 2014 07:05:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B731A06F1; Tue, 20 May 2014 07:05:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140520140554.6523.38223.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 07:05:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/lCVBKW8YJ3fPwchDbdi7aTwMnaI Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:05:57 -0000 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 : Router Keying for BGPsec Authors : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-06.txt Pages : 11 Date : 2014-05-20 Abstract: BGPsec-speaking routers are provisioned with private keys to sign BGP messages; the corresponding public keys are published in the global RPKI (Resource Public Key Infrastructure) thereby enabling verification of BGPsec messages. This document describes two ways of provisioning the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 20 07:26:35 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BF41A06F4 for ; Tue, 20 May 2014 07:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGma8PeaiUQp for ; Tue, 20 May 2014 07:26:31 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.247.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0E1A0439 for ; Tue, 20 May 2014 07:26:30 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id BA54C5B5266E0; Tue, 20 May 2014 09:26:29 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 4E4C85B521AF6 for ; Tue, 20 May 2014 09:26:14 -0500 (CDT) Received: from [198.180.150.142] (port=49568 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wmkzd-0003kK-LY; Tue, 20 May 2014 09:26:13 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sean Turner In-Reply-To: <20140520140554.6523.38223.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 10:26:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F75C5BC-EDC2-4448-BC29-572D369D7E69@ieca.com> References: <20140520140554.6523.38223.idtracker@ietfa.amsl.com> To: sidr-chairs@tools.ietf.org X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Exim-ID: 1Wmkzd-0003kK-LY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:49568 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/b4XwJe5Q8UZsMAqHrXlN12iQm_k Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:26:32 -0000 SIDR Chairs, This version address all known outstanding comments. At this point, I=92d= like to request a WGLC but realize that this draft probably needs to = progress with the other BGPsec drafts. spt On May 20, 2014, at 10:05, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Router Keying for BGPsec > Authors : Sean Turner > Keyur Patel > Randy Bush > Filename : draft-ietf-sidr-rtr-keying-06.txt > Pages : 11 > Date : 2014-05-20 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys to sign = BGP > messages; the corresponding public keys are published in the global > RPKI (Resource Public Key Infrastructure) thereby enabling > verification of BGPsec messages. This document describes two ways = of > provisioning the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue May 20 07:29:10 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7B1A0439 for ; Tue, 20 May 2014 07:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGoM5bWN66vX for ; Tue, 20 May 2014 07:29:07 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C641A06F4 for ; Tue, 20 May 2014 07:29:06 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id gl10so469989lab.39 for ; Tue, 20 May 2014 07:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eexhW/pXa/whCgEYd9JxRC/NPcXfP3aCLA/VSp2Ih50=; b=fnVli9JzWEibBbsK6oUaQy1VWfFw5k3HQsWWfrfWMbSTijUFC8117fqeN5YJ6xcisE enArKRg1cXt4X58O79ppx5/OWoOzBBpF+Q1nD8l1jRs9qfALcQsPcpR7709mukfKY/5x eWrDXApNf2/kx9dTAwdqhdY6FRSU/fvNDcLuiqlNTqGL5wlvtdJ6IQcOo1e7NKC/5emo BKaeE0TDZY3RsDOgnD4uZGGvwEzNktsIDfaTxwA4z4C9sGHtHmOeMXViBM5GzuWdtbjY NKTC8+ripyeMIeBNQGkUTEwMbUyxOX73Ce+neOEIz7RH+kGDvC9NdA2T1tnXCqiBc9mo ChXg== MIME-Version: 1.0 X-Received: by 10.112.186.7 with SMTP id fg7mr14120272lbc.42.1400596144822; Tue, 20 May 2014 07:29:04 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Tue, 20 May 2014 07:29:04 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Tue, 20 May 2014 10:29:04 -0400 X-Google-Sender-Auth: 5EwSqq3ZbxCkQABq2xrA9D6tmrU Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QL9fY22uOuU4bG3wzLT5ngNuB8I Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:29:08 -0000 i didn't update the tracker... (i hadn't ever in the past). Did we circle down on an answer for the leak/persay language that everyone's happy with? If so I'd like to push out a pub request today. On Tue, May 20, 2014 at 9:52 AM, Randy Bush wrote: > funny. datatracker does not show wglc for this document > > randy, trying to time that small fix for roque From nobody Tue May 20 07:38:34 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADF81A0468 for ; Tue, 20 May 2014 07:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW0p0oIWVfJU for ; Tue, 20 May 2014 07:38:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C9F1A034A for ; Tue, 20 May 2014 07:38:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WmlBT-00079g-P9; Tue, 20 May 2014 14:38:28 +0000 Date: Tue, 20 May 2014 17:38:26 +0300 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/8HKJcsrBRtZRiNmXOMLSz7my8Qc Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 14:38:32 -0000 > i didn't update the tracker... (i hadn't ever in the past). uh, that is between you and the datawhacker > Did we circle down on an answer for the leak/persay language that > everyone's happy with? If so I'd like to push out a pub request today. as far as i am aware, there is no issue with leak language. we got past folk looking up 'per se' in their dictionaries. the one open issue is >>>>> 3.14 While the trust level of a route should be determined by the >>>>> BGPsec protocol, local routing preference and policy MUST then >>>>> be applied to best path and other routing decisions. Such >>>>> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. >>>>> ... >>>>> 3.17 If a BGPsec design makes use of a security infrastructure, that >>>>> infrastructure SHOULD enable each network operator to select >>>>> the entities it will trust when authenticating data in the >>>>> security infrastructure. See, for example, >>>>> [I-D.ietf-sidr-ltamgmt]. >>> >>> What about adding that "the connection to this security infrastructure >>> MUST be through a secure channel"? > > it's done via rcynic and/or rpki-to-rtr, right? depending on where in > the process you are... presuming the process looks like: > publication-point - gatherer - cache - router > (rcynic) (rcynic) (rpki-rtr) apologies to roque. some external data were indeed what was meant (an rpki-like thing is an example), and was inteneded by "security infrastructure." the authenticity of those data is an issue. we might say so in sec cons. and i am waiting for wglc to close so i can make the hack once. randy From nobody Tue May 20 08:46:11 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA141A06FA for ; Tue, 20 May 2014 08:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y0qHOZYDX1P for ; Tue, 20 May 2014 08:46:06 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A13B1A0183 for ; Tue, 20 May 2014 08:46:06 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id q8so561047lbi.12 for ; Tue, 20 May 2014 08:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1JcQRgisZ4tJWTjE4LsW877MReqlMrR2hGQjmowhij0=; b=EOA3/abs39Qu6AUFlNb/FHPCq50ziusTgwqPf7ohsmwciVhAhGGjjkn9F76syusRXQ VkzwAk+Sm7u3RmEcwGH547K5QCh1NOmePQ8U0FTOPbmyqOvGZ/JGHzf6W5Gxa4rNmZs8 VeX9aNKO9a1+TPKBwPSpVl8Ubn2EbwXpsLXjMkMsNYk3xZ5EYkzpk+SFUjn4/WOZ8qPJ mMcr2ePyCYjiyO/YK/h3+EjHrXFitHbz/hX6MfaTCASe4P0d9fSma+BtY4uXN0m0Z1xs zyhJTwg8QpQ4xT4oN00XU9RJrJSzsC5LqWb9A1r/hPVRAiRiXRCr4AASU3psber58K7a NcBQ== MIME-Version: 1.0 X-Received: by 10.152.20.40 with SMTP id k8mr2603174lae.62.1400600764532; Tue, 20 May 2014 08:46:04 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Tue, 20 May 2014 08:46:04 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Tue, 20 May 2014 11:46:04 -0400 X-Google-Sender-Auth: iOKlImBqBaVkyOf7q1nW21NsK2M Message-ID: From: Christopher Morrow To: Randy Bush , Roque Gagliano Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/q_nd8VdCMFb2-lHxvdEF9myK4Lg Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 15:46:09 -0000 On Tue, May 20, 2014 at 10:38 AM, Randy Bush wrote: >> i didn't update the tracker... (i hadn't ever in the past). > > uh, that is between you and the datawhacker > >> Did we circle down on an answer for the leak/persay language that >> everyone's happy with? If so I'd like to push out a pub request today. > > as far as i am aware, there is no issue with leak language. we got past > folk looking up 'per se' in their dictionaries. the one open issue is > > >>>>> 3.14 While the trust level of a route should be determined by the > >>>>> BGPsec protocol, local routing preference and policy MUST then > >>>>> be applied to best path and other routing decisions. Such > >>>>> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. > >>>>> ... > >>>>> 3.17 If a BGPsec design makes use of a security infrastructure, that > >>>>> infrastructure SHOULD enable each network operator to select > >>>>> the entities it will trust when authenticating data in the > >>>>> security infrastructure. See, for example, > >>>>> [I-D.ietf-sidr-ltamgmt]. > >>> > >>> What about adding that "the connection to this security infrastructure > >>> MUST be through a secure channel"? > > > > it's done via rcynic and/or rpki-to-rtr, right? depending on where in > > the process you are... presuming the process looks like: > > publication-point - gatherer - cache - router > > (rcynic) (rcynic) (rpki-rtr) > > apologies to roque. some external data were indeed what was meant (an > rpki-like thing is an example), and was inteneded by "security > infrastructure." > > the authenticity of those data is an issue. we might say so in sec > cons. > > and i am waiting for wglc to close so i can make the hack once. Roque, is the change/text ok? or ? From nobody Tue May 20 10:49:55 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B55A1A0102 for ; Tue, 20 May 2014 10:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4vSnPpz93DU for ; Tue, 20 May 2014 10:49:53 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8641A0259 for ; Tue, 20 May 2014 10:49:53 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id A253A28B0017 for ; Tue, 20 May 2014 13:49:52 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 6BD8E1F8032; Tue, 20 May 2014 13:49:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <5C076C44-9200-4A07-A1BE-3888DCC9BC36@apnic.net> Date: Tue, 20 May 2014 13:49:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5C076C44-9200-4A07-A1BE-3888DCC9BC36@apnic.net> To: sidr wg list X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/H1gOjMwp0PbxbW08Fy6GL331XjA Cc: Sandra Murphy Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 17:49:55 -0000 Speaking as regular ol' member. On Apr 21, 2014, at 11:55 PM, Geoff Huston wrote: ====================== >>Except that the signed object signature algorithm OID will be >>rsaEncryption which I think is still PKCS#1v1.5, but is not in section >>5 of rfc4055. > > >I am unsure what you mean here. Perhaps if you send what you think the >text should say it would be helpful. The comment is about the correctness of the reference. But that should not have an impact on implementation, so I withdraw the comment. ================= >what about: > >"The locations where algorithm object identifiers appear are:" Works for me. ====================== >I think this was a failing in RFC6485 itself. >RFC6487 has forward pointers to RFC6485 in the algorithm section for >PKCS , but the text in RFC64845 refers to "certificates, CRLs and >signed objects". > >Do you have alternative text to suggest here? > Defending RFC6485: RFC6485 only had one OID to talk about, so any reference to an OID could be assumed to be that one OID. So the choice for cert requests might not have been direct in RFC6485, but there was no ambiguity. But, yes, with the added mention of new OIDs, the text retained from RFC6485 is no longer clear about implementation of cert requests. I suggest the following alternative text would make the choice clear. The changes add cert requests where the choice for certs and CRLs is mentioned. From: * The signature algorithm used in certificates, CRLs, and signed objects is RSA Public-Key Cryptography Standards (PKCS) #1 Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from Section 5 of [RFC4055]. To: * The signature algorithm used in certificates, CRLs, signed objects, and certification requests is RSA Public-Key Cryptography Standards (PKCS) #1 Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from Section 5 of [RFC4055]. From: * The hashing algorithm used in certificates, CRLs, and signed objects is SHA-256 [SHS] (see note below). Hashing algorithms are not identified individually in certificates and CRLs, as the identity of the hashing algorithm is combined with the identity of the digital signature algorithm. To: * The hashing algorithm used in certificates, CRLs, signed objects, and certification requests is SHA-256 [SHS] (see note below). Hashing algorithms are not identified individually in certificates, CRLs, and certificate requests as the identity of the hashing algorithm is combined with the identity of the digital signature algorithm. From: For generating and verifying certificates, and CRLs the hashing and digital signature algorithms are referred to together, i.e., "RSA PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST be used in this case. To: For generating and verifying certificates, CRLs, and certification requests, the hashing and digital signature algorithms are referred to together, i.e., "RSA PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256". The Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST be used in this case. ======================== A couple of typos in the new section 8 explaining the changes: From: Section 2 of [RFC6485] specified a single signature algorithm (SHA- 256) To: Section 2 of [RFC6485] specified a single signature algorithm (RSA PKCS#1 v1.5) (I'm guessing here what you mean, but I'm pretty sure the text did not mean SHA-256 is a signature algorithm. It could also be that the text meant: To: Section 2 of [RFC6485] specified a single signature algorithm (RSA and a single hash algorithm (SHA-256) or ... something else?) This section is an explanation of the change, so it is intended for the IESG, and is not crucial to implementation. I think it would be better to change to say what you mean, but I can accept it. There's also this typo: From: This document changes Section 2 of [RFC4055]. To: This document changes Section 2 of [RFC6485]. That also is not crucial to implementation, but it might confuse the secretariat to have this text claim that the draft updates 4055. If anyone notices. ========================== >> I presume accepting sha256WithRSAEncryption is backward compatibiilty ... > >I am already hopelessly confused by this situation, and I'm in no >position to answer this. No one else has expressed any concern over the backward compatibility, so I withdraw the comment. ============================== Then there's this new bit, which I noticed in the midst of checking what was needed for the certificate requests. In Section 2, the text says In a certification request, the OID appears in the PKCS #10 signatureAlgorithm field [RFC2986], or in the Certificate Request Message Format (CRMF) POPOSigningKey signature field [RFC4211]. RFC4211 says that the POPOSigningKey is: POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING } I'm pretty sure the text should say the OID goes in the POPOSigningKey algorithmIdentifier field, not the POPOSigningKey signature field. [[While this looks clear to me, the comment could use some review by someone comfortable with ASN.1 overloaded and inconsistent field names.]] That text is in the original RFC6485 and it has no relationship with the problem with the OID choice in CMS, the reason for this bis. However, if true, this has implementation impact, so I think this should be considered at some point. *IF* people agree that this is wrong, do the authors have any problem with changing the text in this bis? FROM: Message Format (CRMF) POPOSigningKey signature field [RFC4211]. TO: Message Format (CRMF) POPOSigningKey algorithmIdentifier field [RFC4211]. --Sandy, speaking as regular ol' member From nobody Tue May 20 14:35:30 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EDF1A0407 for ; Tue, 20 May 2014 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAgI_tQIzziu for ; Tue, 20 May 2014 14:35:26 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E0E1A03E5 for ; Tue, 20 May 2014 14:35:25 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr17so925481lab.31 for ; Tue, 20 May 2014 14:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=s5wuhopY5hhz0rfNVpS0uRHYk2GbCvhGQXTNEepCuT0=; b=ln6+PJRMqRDEi/XaGPGBe7H+CFORhGQNf/hZjcc0iNBsbRo2mDQHYbtuIu2A+eRJAE G4T8tc8VBAvkt5iVxw6alxk9gb8BIKIxRwsDbVGtNNT9ISqfMWfePvp7JTFqcd053pTy bZFWmciBe+ep/s/g+BuEGbaBkTY0Ijk52szMo1YkMcd11Uokc+qMMcDptH1edbpVSOt8 57wd4Kfr+UwEAxaKO4p7Qpef83sRLT7NrwxSqIgoeUiY7C5T1d+SX7BXRbWZs3MSlCkX Li0kAoqi4h4FiKDUlgRbouVO3R/WHnhURVRcJDckG3ZnUqlM+0htVWfnwl6W6FgVQAvK Lc7g== MIME-Version: 1.0 X-Received: by 10.152.29.168 with SMTP id l8mr34410594lah.35.1400621724046; Tue, 20 May 2014 14:35:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Tue, 20 May 2014 14:35:23 -0700 (PDT) In-Reply-To: References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> Date: Tue, 20 May 2014 17:35:23 -0400 X-Google-Sender-Auth: b38z_EVIMsdjobrZ1J47wv3bgE4 Message-ID: From: Christopher Morrow To: Geoff Huston Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/nDfIsRPDBSJmVzgGCi-g6cSHLt8 Cc: sidr wg list , "Sriram, Kotikalapudi" , George Michaelson Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 21:35:28 -0000 On Tue, May 20, 2014 at 8:10 AM, Geoff Huston wrote: > > On 20 May 2014, at 4:38 am, Christopher Morrow = wrote: >> It's unclear to me what would happen if you split this into a >> prefix/asn per cert and just carried more certs in your purse. Why >> would I not just add more certs to my purse? is there a particular >> reason to conglomerate these under the minimal number of certs? are we >> trying to minimize space in my purse? if so the purse is large, and >> the certs very small... I could 10x or 100x the number of certs here >> and be ok still. > > For AS numbers thats an interesting approach, if you carry a single ASN p= er cert then yes, there would be a whole lot more certs around (-ve), but a= ny discrepancy in AS registry records between parent and child would be lim= ited to just those ASns where there are such discrepancies (+ve) > ok, in tim's/your(someone's) original note: --------------------- snip ------------------------ Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509} (TA certificate) Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511} Certificate 3: {10.0.0.0/20, AS64501, AS64509} Currently we reject certificate 2 and everything under it.. --------------------- end snip ------------------------ it looks to me like making this 8 ROA instead of 3 would make sense. The 'isp'/resource-owner (I think - AS64501) would be able to announce the /12, /22 and /20. The customer/other prefix-users: 64505 - /12 and /22 64509 - /12 and /20 64511 - /22 which seems to catch the intent of the 3 certs at least. This way if you were to break out a new /X from the /12 for AS65534 no one is broken and no shuffling has to happen (yet). If the RIR would break the /12 up into 2x /13, for instance, and transfer the top/higher /13 off to RIR#2, only the /12 needs to change and you could do make-before-break over some period of time acceptable to the 3+ parties involved. Additionally, if the RIR has an oopsy on the /12 the other prefixes by the users are ok... hopefully. It's not clear to me that 'oopsy' will happen on only a single prefix either? if it can happen to 1, it can happen to 20000. (maybe that's a chat for another day in the thread though). > However I'm unsure how you could or would apply this principle to IPv4 ad= dresses. And I'm even more unclear about IPv6. > to /32's? or something else? I suppose TODAY we only really care about 'minimum size prefix (max length) which is globally accepted'. We also should have data on how quickly the RPKI system converges across it's whole (perhaps to some level of 'converge') given number of objects in the global system. (this metric discussion came up several times over the last M meetings... sriram and tim have some data, but it's not clear how applicable any of the study work has been) > However, in principle, the validation algorithm proposed in this draft pe= rforms a validation function which is semantically equivalent to breaking d= own each certificate into a collection of certificates, each describing one= element of the original number set, but this approach does not require one= to define the minimal unit of addresses in IPv6, nor try to generate an en= umeration of individual /128s (or even /64s!) in IPv6, which I guess is a G= ood Thing. sure, but I don't know that we need to go to host-level data do we? you can't get a host-route routed in the internet today, at least not beyond your local ISP (save leaks/mistakes), and I think the ROA format allows you to specify: 128.2.0.0/16-32 AS5050 right? so in v6: 2001:4860::/32-128 AS15169 Any case of splitting a prefix (2001:4860::/32 becomes 2001:4860::/33 && 2001:4860:8000::/33) for the purposes of transfer/change-in-Origin is going to require /make before break. I don't think that's changed by the validation algorithm is it? I do think that being explicit with the roa content and not cute by chunking as much as possible into the bag is a good thing. It seems, to me, like it makes the decision process for each ROA less complex, and thus any further actions on that ROA (splits, joins, deletion, etc) simpler. -chris From nobody Wed May 21 11:06:55 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28C1A0116 for ; Wed, 21 May 2014 11:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1WIuX-8bYJ9 for ; Wed, 21 May 2014 11:06:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057CA1A0107 for ; Wed, 21 May 2014 11:06:49 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:55688) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WnAuo-0003sh-Qu for sidr@ietf.org; Wed, 21 May 2014 14:06:58 -0400 Message-ID: <537CEB37.506@bbn.com> Date: Wed, 21 May 2014 14:06:47 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sidr@ietf.org References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/qNoReBFDQ1BzgwhelsvJgWFSzYI Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 18:06:54 -0000 Folks, I realize I am very late in commenting on this doc, but I was on vacation for a month, and upon return I am working through 2300+ new messages, so ... I have three concerns with the document: 1- the doc presumes that the solution to the principle problem cited is to change the validation alg. That may be the right outcome, but I think it might be more appropriate to focus on the primary, cited concern, i.e., that a error in the 3779 extension(s) of cert for a CA with many children might cause problems for many of the children. Geoff specifically raised this issue for RIRs, and because they are acting as TAs, they have the ability to issue a new self-signed cert that adversely impacts many of their children. NIRs and very large ISPs don't acts as TAs, so errors by them affect certs issued by them to individual children. One could begin by describing what we believe to be best practices for RPKI CAs with regard to 3779 extension checks. For example, for a CA that is also a TA, it makes sense to run RP validation for every cert issued by the CA prior to publishing a new self-signed cert. That simple process would detect any child certs that would be rendered invalid by an error if the sort cited by Geoff. This RP check can be automated trivially, since the CA/TA has direct access to all of the currently- valid certs that it has issued. For a CA that is not a TA, the impact of a 3779 change is limited to the subtree for the affected cert. Here too, it makes sense for the CA to run an RP check whenever it is reducing the scope of the 3779 extensions. So, the automated check to run here would entail two parts: first see if a cert that is being re-issued represents a reduction in scope for the 3779 extension(s); second, fetch the certs issued by the CA whose cert is being reissued, and see if any of them will be invalidated by the change. If those with experience operating RPKI CAs have other suggestions for good practice wrt avoiding the problem Geoff cited, they too should be part of a doc addressing this issue. (I'd also like to verify that the RIRs are, or are not, performing the first set of checks today, for their ss-certs.) Geoff has argued that other benefits accrue from relaxing the 3779 part of the path validation procedure. There is not agreement on his other examples. For example, we have an I-D describing how to automate more of the resource transfer process (draft-barnes-sidr-tao-00). The mechanism described there would benefit a little from a relaxed 3779 validation check, but only in very limited circumstances. So, that use case does not seem especially compelling. 2- A separate concern is that the candidate doc contains two separable cases: one relaxes path validation by not mandating that every subordinate cert contain only a subset of the resources in the parent cert. The other case introduces the notion of a join into the RPKI tree structure. This latter case was extensively criticized during the SIDR WG meeting, by a number of folks. I suggest that case not be part of a new WG doc at this time. 3- My final concern/observation, is that the text in the doc that describes how to relax the 3779 aspects of path validation is not, as stated, viable. Specifically, it appears to assume that path validation is performed only for EE certs. In the RPKI, we effect path discovery top down, based on our model for discovering CAs and their children. (In PKIs in general, path discovery may be top down or bottom up, or both toward the middle, but the RPKI is not a generic PKI.) Because of the top- down approach, it makes sense for RP software to validate each newly discovered CA. This is not only an efficiency issue, but also an anti-DOS feature. Thus the description of how to modify the current 3779 path validation alg is not adequate. I believe it can be fixed, and I have indicated how it might be fixed in (private) message excahnges with Geoff. Thus this concern is not a reason to reject work on this topic, but it does suggest that a viable algorithmic description might be a prerequisite for adopting a version of this doc. Steve From nobody Wed May 21 12:05:11 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA38D1A06C8 for ; Wed, 21 May 2014 12:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX7kD9W5Ny14 for ; Wed, 21 May 2014 12:05:08 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) by ietfa.amsl.com (Postfix) with SMTP id 54D371A0694 for ; Wed, 21 May 2014 12:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=SJaCIFyI4+k0ZivCiT3nc+6jJJnjtnCYqJtIJAVKkmE=; b=U7/WfDwkLt5RVVcLiDqpdNSJia85aGmt7f8S6rYjGRUR166NVyXtQyiwzsjhAaxX9A3RxhWArkDr9 jrp8OCW7se189SJHS2uTYKS+uCC0uiB8iC4OI2q66vf9j3TjUPuREk5MOkw8VHY8g6Q6q7/19ksLgx keCZeHMs6yPHlank= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 22 May 2014 05:05:58 +1000 (EST) Received: from [10.121.124.61] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 22 May 2014 05:05:04 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Geoff Huston In-Reply-To: <537CEB37.506@bbn.com> Date: Thu, 22 May 2014 05:04:55 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <02E084F0-C222-4753-ACCF-C239D6B6B29B@apnic.net> References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> <537CEB37.506@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Y75XCftXEFsJYjgxxBgxyF0OvbA Cc: sidr@ietf.org Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:05:11 -0000 Hi Steve, I appreciate the backlog of mail you are working from, as you note in = your mail, but I always think it useful to have carefully read a document before = performing a critique. I'm sure you would agree with that sentiment. I was therefore quite surprised to = find you had said the following: > 2- A separate concern is that the candidate doc contains two separable = cases: one relaxes > path validation by not mandating that every subordinate cert contain = only a subset > of the resources in the parent cert. The other case introduces the = notion of a join > into the RPKI tree structure. This latter case was extensively = criticized during the > SIDR WG meeting, by a number of folks. I suggest that case not be part = of a new WG > doc at this time. I would be grateful for the precise reference in the "candidate doc" you = talk about to the concept of a "join". I looked though = draft-huston-rpki-validation-01.txt, and=20 maybe I missed something incredibly obtuse and well buried in the = whitespace, but I couldn't find any such reference in this document. Are you perhaps = performing a critique of some other draft in this rather lengthy message and not in fact = referring to=20 draft-huston-rpki-validation-01.txt at all? The description of the first case is also inappropriately informal - the = alternative view described in the draft is that a relying party can consider a = certificate to be valid with respect to only those resources that are contained in all = certificates that form the validation path. Perhaps the subtle difference in your description = might be the cause of your evident discomfort with what you believe is contained in = this document. I think a careful read of section 2 of this draft adequately addresses = why your proposal for=20 additional operational procedures in point 1 of your note seems to be = well wide of addressing the issues described in the draft.=20 The assertion in point 3 that this is "not viable" I interpret as one = opinion, most likely one held by yourself. Obviously there are other opinions and perspectives on this = matter, and this draft describes such a different perspective and also includes the motivation = behind it. I would recommend that perhaps this conversation would benefit from such a careful reading = of the draft in question. regards, Geoff From nobody Wed May 21 12:18:48 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955FF1A0732 for ; Wed, 21 May 2014 12:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHlWkXRxT4RN for ; Wed, 21 May 2014 12:18:45 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3C51A052E for ; Wed, 21 May 2014 12:18:45 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.98,881,1392181200"; d="scan'208";a="325126205" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 May 2014 15:17:49 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 21 May 2014 15:18:33 -0400 From: "George, Wes" To: Randy Bush , Christopher Morrow Date: Wed, 21 May 2014 15:18:32 -0400 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: Ac91KXSPSdjqNMTHSG2ThAqAihDlnw== Message-ID: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Gns_1zP5ZE6ansZ-mFEouZtm3F0 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:18:46 -0000 DQpPbiA1LzIwLzE0LCAxMDozOCBBTSwgIlJhbmR5IEJ1c2giIDxyYW5keUBwc2cuY29tPiB3cm90 ZToNCg0KPj4gIHdlIGdvdCBwYXN0DQo+Zm9sayBsb29raW5nIHVwICdwZXIgc2UnIGluIHRoZWly IGRpY3Rpb25hcmllcy4NCg0KV2VsbCBub3QgZXhhY3RseSwgc2luY2UgdGhhdCB3YXMgbmV2ZXIg dGhlIGluaXRpYWwgcHJvYmxlbS4gSSBqdXN0IGRlY2lkZWQNCm5vdCB0byBtYWtlIGFuIGlzc3Vl IG91dCBvZiBpdCBhbnkgZnVydGhlciBzaW5jZSBJIHNlZW1lZCB0byBiZSB0aGUgb25seQ0Kb25l IGV4cHJlc3NpbmcgdGhlIGNvbmNlcm4uDQoNCldlcw0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkg b2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0 YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1 YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBF LW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRh a2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhp cyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFu ZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Wed May 21 12:49:12 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8C01A0850 for ; Wed, 21 May 2014 12:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rlc2KP4DhkuH for ; Wed, 21 May 2014 12:49:09 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0891A0830 for ; Wed, 21 May 2014 12:49:08 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id ec20so392822lab.33 for ; Wed, 21 May 2014 12:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8otTjm/Zgfg59dIihhGyQ0yffQCro/L+xvhWXi71eGs=; b=KcvTFz7JiGCQeyxuJUmsNQZCIrsw59/L32r/vdGo29WnQb8ouKupTp4LYD63Mnc5B3 VTyWcIaCmj7NEJWbUj/0pM3sCnMTEcOdKqH+Tkl5reputug6yGNq3pLzXjXUnMcWpgRN 2ev3kWE37vVuPUB5oHS3KNDOuc4Rzdy6ZD9a0QfXYgefKsI8nJuDj+EyZxrR+ypIjL3+ ny152w5EYuAL5LMDpUyPJ9aqXW3B193M8BFOswPN0axsm/dseW9f7Tq0tyclbQr6RnEU sWMRs9mF2D9SmTZed58mmEVFPthCDH5gt9R8JpZquDTABktsdGYZvUQDeTr3QySbM/A3 m64Q== MIME-Version: 1.0 X-Received: by 10.152.242.164 with SMTP id wr4mr39488218lac.38.1400701746484; Wed, 21 May 2014 12:49:06 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Wed, 21 May 2014 12:49:06 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Wed, 21 May 2014 15:49:06 -0400 X-Google-Sender-Auth: yi9VzZsxa010hKCvcf04m36-p3s Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ywy3xdbJ_Cd09NjaPXnb9ff-JKU Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:49:10 -0000 On Wed, May 21, 2014 at 3:18 PM, George, Wes wrote: > > On 5/20/14, 10:38 AM, "Randy Bush" wrote: > >>> we got past >>folk looking up 'per se' in their dictionaries. > > Well not exactly, since that was never the initial problem. I just decided > not to make an issue out of it any further since I seemed to be the only > one expressing the concern. ok, so we're just holding on roque then? From nobody Wed May 21 12:53:19 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE6F1A0830 for ; Wed, 21 May 2014 12:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_kXns4-_XAI for ; Wed, 21 May 2014 12:53:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF82F1A082A for ; Wed, 21 May 2014 12:53:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WnCZe-0002i6-J7; Wed, 21 May 2014 19:53:15 +0000 Date: Wed, 21 May 2014 22:53:13 +0300 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Opkx7IpBILMkn88otpsy5gsWyZI Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:53:18 -0000 > ok, so we're just holding on roque then? no. i know how to deal with that one. but i do not want to make multiple updates. so waiting for wglc to finish (actually, i think it timed out already), so i can issue one hack. randy From nobody Wed May 21 12:59:18 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56821A0882 for ; Wed, 21 May 2014 12:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGmph4PW8Be2 for ; Wed, 21 May 2014 12:59:16 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B1D1A0881 for ; Wed, 21 May 2014 12:59:15 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so1952571lbg.4 for ; Wed, 21 May 2014 12:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VhQDEKB1XzwkXrGdJOq09kHZ9ylz2nz62IxMcF+Gggs=; b=E81LPbfBLhWSVTlvRB7y2Olv4QEPFg2VredPzTE16/z/+/Ir8pzRCpFQjzO+cSiXjV TOLmaX7f6R2P9PWglJ03aKY3V20qu4GLEPtt0xcwO6ukj0QVQ2fjxtJ7/wZBjAu1WAvH eZ7v+s+LDGbcpJn5p8UMx9wFXBYgOFwdh0Y4/pkahpBnDQx+5P/X8mwlbyaSnc7N+jWd zHfnSCAfpIVDpE7urcqS2nq0CBilgQ3Cp8EHbiRFPwVTY/XKK2CHGD63zHKTlRl6dVzP 3gIyRol4BR/BEdK1E9BWdHeFI7P7GcISukeGqOGmzSZNpSnsvWHYqiqxHPcGJmJYSCv2 khuw== MIME-Version: 1.0 X-Received: by 10.152.242.164 with SMTP id wr4mr39523582lac.38.1400702353674; Wed, 21 May 2014 12:59:13 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Wed, 21 May 2014 12:59:13 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Wed, 21 May 2014 15:59:13 -0400 X-Google-Sender-Auth: qJYVvhUYYOzhmZBDR93Bl5Q0YrI Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/lZ6op5kbbADJpTPhXQbSjAsmGPM Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 19:59:18 -0000 On Wed, May 21, 2014 at 3:53 PM, Randy Bush wrote: >> ok, so we're just holding on roque then? > > no. i know how to deal with that one. but i do not want to make > multiple updates. so waiting for wglc to finish (actually, i think > it timed out already), so i can issue one hack. yes, it dragged out waiting on some wording fixes... From nobody Thu May 22 06:02:04 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29591A00EF for ; Thu, 22 May 2014 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4tHlEZ585gg for ; Thu, 22 May 2014 06:02:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BFD1A001A for ; Thu, 22 May 2014 06:01:54 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so2567041lbi.5 for ; Thu, 22 May 2014 06:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JSa2j/MlGHAeaxhSnHhObEIpvkj0hmdUqsqaQUjc6KM=; b=FZGyrt+QvhrxqOLXE6wvcPApSoKJg5xCXbRjsPeeGS+JM/lsQckxK5sV2rqmKL5Muw 6ARfyuJJ5qWir9rbpQp1auI8/zcqdsoK++Sj0tQKyrujY+yU2r3lGH6MXljbxwJE5c4/ TGUc/uzUfg/ajCEx9iQ/vfSH6SjeKrj+wOIUiGT2XCSZ9OOHoHb3O4NCPyMgdDcAwCIG FgOw4Zf2yQY8XAgx9BnZcAu1gP1mN8jdBx2IWvUHX1HRNLZ1thuKDNl3KlanY1c71yVV HTJ6dVd4dUMgbK9shXs+TGTz5dz/LxP1uawuVfJvy/EOktjeGwMc3teuENQxg1GC425h NSQA== MIME-Version: 1.0 X-Received: by 10.112.150.103 with SMTP id uh7mr39956520lbb.30.1400763712153; Thu, 22 May 2014 06:01:52 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Thu, 22 May 2014 06:01:52 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Thu, 22 May 2014 09:01:52 -0400 X-Google-Sender-Auth: zbsu29Fiq0UdbzoUZI6UZbCXi8U Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/vuLMcV95B6GKyn0PLraAE5A2FVE Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:02:03 -0000 Ok, with an offline (off email?) conversation with one of the authors I think it's time to call an end to this very long WGLC. It seems, to me, that all of the comments and questions were dealt with, and that overall the document is ready to move along to the next step in the ponderous (though probably shorter than this step) process. Thanks for bearing with the process so far... -chris co-chair-person On Wed, May 21, 2014 at 3:59 PM, Christopher Morrow wrote: > On Wed, May 21, 2014 at 3:53 PM, Randy Bush wrote: >>> ok, so we're just holding on roque then? >> >> no. i know how to deal with that one. but i do not want to make >> multiple updates. so waiting for wglc to finish (actually, i think >> it timed out already), so i can issue one hack. > > yes, it dragged out waiting on some wording fixes... From nobody Thu May 22 06:59:13 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C4B1A013B for ; Thu, 22 May 2014 06:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4vMt29TLago for ; Thu, 22 May 2014 06:59:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC86A1A0176 for ; Thu, 22 May 2014 06:59:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WnTWT-0004pf-I9; Thu, 22 May 2014 13:59:06 +0000 Date: Thu, 22 May 2014 16:59:07 +0300 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/h8QwAPh2JHG168fW10N70CeKCtc Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 13:59:10 -0000 ok. i will recover a bit from jet-lag and then hack in a sec cons on the good issue roque raised. randy From nobody Thu May 22 07:14:53 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5861A01A7 for ; Thu, 22 May 2014 07:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eITl1E9r6W61 for ; Thu, 22 May 2014 07:14:51 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85F01A0176 for ; Thu, 22 May 2014 07:14:50 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so2684244lbd.0 for ; Thu, 22 May 2014 07:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c9yO7zNl9SeQOnJObXXBByucP2Bk0RF/jK+GO3nDxQs=; b=y1tVFshIt3ehLl/vVN76CT+9dE6n+cmqKVnobiKp3tCOdX3STWcrSMwbPVno0KYKDs jGWUQB9V1rgzNIxyF+lVN6w82wSTDlFWY4cgm1gPbKE18OMBjZlSKljEYh2loh4VZE1U CDGrPkwUshwSi/B42ShKB+9GW68b5lDJ7Qv9N5D+wVbDK8/dEW4+OASQwjroGhLrE6gY kDrJWOr04bjrEvVq6iEeQbk3oOAi0YtekNsvxrprpKNZaIHO0gpXFWFyAyy90nZzbLG4 plWTGa5FuKmfAQvlgOLr8bV6vyIwGLiJbbBTy36AZjWqVhQahiesCby0O1wCyC3GDQ4V mHLA== MIME-Version: 1.0 X-Received: by 10.152.4.137 with SMTP id k9mr33140560lak.46.1400768088359; Thu, 22 May 2014 07:14:48 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.153.5.161 with HTTP; Thu, 22 May 2014 07:14:48 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Thu, 22 May 2014 10:14:48 -0400 X-Google-Sender-Auth: 3JCLk_iXxmghn_uUIZkeMOMxQSQ Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xho0dPO0j83ia234pSvfxg6qAQs Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 14:14:52 -0000 On Thu, May 22, 2014 at 9:59 AM, Randy Bush wrote: > ok. i will recover a bit from jet-lag and then hack in a sec cons on > the good issue roque raised. fair enough. When the next rev pops up through the process I'll send a pub-request to the iesg sausage factory. From nobody Thu May 22 09:07:45 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB5A1A016D for ; Thu, 22 May 2014 09:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJJTlRD7V4vG for ; Thu, 22 May 2014 09:07:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA021A0049 for ; Thu, 22 May 2014 09:07:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WnVWp-00058e-NA; Thu, 22 May 2014 16:07:36 +0000 Date: Fri, 23 May 2014 01:07:34 +0900 Message-ID: From: Randy Bush To: Roque Gagliano In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.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 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/uZpa0UU6WUZ3x2pNwz3zYhQIX-4 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 16:07:43 -0000 roque, how about 6. Security Considerations If an external "security infrastructure" is used, as mentioned in Paragraph 9 and Paragraph 17, it is critical that the authenticity and integrity of data of such an infrastructure is assured and that it its integrity is assured when it is used by BGPsec. i may tune the grammar in the morning randy From nobody Thu May 22 11:39:45 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7C71A02C9 for ; Thu, 22 May 2014 11:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGMLDEJcq9pM for ; Thu, 22 May 2014 11:39:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8901A02CC for ; Thu, 22 May 2014 11:39:22 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57833) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WnXtr-000BoO-Bj; Thu, 22 May 2014 14:39:31 -0400 Message-ID: <537E4456.9050009@bbn.com> Date: Thu, 22 May 2014 14:39:18 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Geoff Huston References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> <537CEB37.506@bbn.com> <02E084F0-C222-4753-ACCF-C239D6B6B29B@apnic.net> In-Reply-To: <02E084F0-C222-4753-ACCF-C239D6B6B29B@apnic.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/9_u5WohYMV6VwjfswpUlGt1r09Q Cc: sidr@ietf.org Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 18:39:35 -0000 Geoff, > Hi Steve, > > I appreciate the backlog of mail you are working from, as you note in your mail, but > I always think it useful to have carefully read a document before performing a critique. I'm sure > you would agree with that sentiment. I was therefore quite surprised to find you had said the > following: > >> 2- A separate concern is that the candidate doc contains two separable cases: one relaxes >> path validation by not mandating that every subordinate cert contain only a subset >> of the resources in the parent cert. The other case introduces the notion of a join >> into the RPKI tree structure. This latter case was extensively criticized during the >> SIDR WG meeting, by a number of folks. I suggest that case not be part of a new WG >> doc at this time. I did read the doc carefully, and we exchanged a few very detailed messages in mid-February, prior to the SIDR meeting in London. But, that was a few months ago, and I conflated your briefing at that meeting (specifically slide 15) with the text of the document. My bad. > I would be grateful for the precise reference in the "candidate doc" you talk about > to the concept of a "join". I looked though draft-huston-rpki-validation-01.txt, and > maybe I missed something incredibly obtuse and well buried in the whitespace, but I > couldn't find any such reference in this document. Are you perhaps performing a critique > of some other draft in this rather lengthy message and not in fact referring to > draft-huston-rpki-validation-01.txt at all? you're right; As noted above, I was referring to slide 15 in your briefing at the SIDR meeting (a briefing on the doc in question, hence my confusion). > The description of the first case is also inappropriately informal - the alternative view > described in the draft is that a relying party can consider a certificate to be valid > with respect to only those resources that are contained in all certificates that form > the validation path. Perhaps the subtle difference in your description might be the > cause of your evident discomfort with what you believe is contained in this document. The "algorithm" in the I-D, Section 3.2, describes validity in terms of a "specific resource". The definition of the phrase specific resource is vague, at best. It made sense if one assumed that the specific resource was contained in an EE or CA) since that would avoid declaring a superior CA cert as invalid if an RP did not try to evaluate such a cert. But, for the incremental, top down CA cert eval process, there is no indication of how one should determine a specific resource. Your slides were better ion this point, suggesting that one construct the set of valid resources as part of the cert path evaluation process. But, you noted that my criticism of the "join" aspect of you design was inaccurate, because it is not in the doc in question, so, equivalently, the improved description of the proposed path validation alg in youyr slides ought not be in scope either :-). > I think a careful read of section 2 of this draft adequately addresses why your proposal for > additional operational procedures in point 1 of your note seems to be well wide of addressing the issues > described in the draft. I agree that my suggested CA practices represent a deviation from the mechanism you are tryign to describe. But, if the WG is to consider revising path validation based on the concerns you cite, then it makes sense to ask whether RIR CAs, in particular, are doing what could already be done to avoid the problems in question. If not, then it seems somewhat premature to impose significant changes on all RPs when CAs are not doing what they could to address this potential problem. I'm not saying that we ought not consider your proposal, but let's try to avoid the problem with easy, prudent behavior by CAs, first. > The assertion in point 3 that this is "not viable" I interpret as one opinion, most likely one held > by yourself. Obviously there are other opinions and perspectives on this matter, and this draft > describes such a different perspective and also includes the motivation behind it. I would recommend > that perhaps this conversation would benefit from such a careful reading of the draft in question. As I noted, and as you well know, I read the draft carefully and sent a couple of long messages to you, cc'd to the WG chairs, on 2/13 and 14. The perspective of the I-D is not the issue; the issue is that it is imprecise on a number of important points. It is not a rigorous description of a proposal. Of course there are other opinions; there always are in the IETF. Steve From nobody Thu May 22 22:33:19 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718971A03AA; Thu, 22 May 2014 22:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okJKiEtf8cNq; Thu, 22 May 2014 22:33:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2545A1A03A4; Thu, 22 May 2014 22:33:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140523053316.7519.8995.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 22:33:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ijxxxnYhkpzM6Nh5zCwse0yLUyI Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-11.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 05:33:18 -0000 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 : Security Requirements for BGP Path Validation Authors : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-11.txt Pages : 9 Date : 2014-05-22 Abstract: This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-reqs-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 23 14:48:42 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70521A00C9; Fri, 23 May 2014 14:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyV1fZnkjNZY; Fri, 23 May 2014 14:48:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 379E11A008F; Fri, 23 May 2014 14:48:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140523214834.1202.3087.idtracker@ietfa.amsl.com> Date: Fri, 23 May 2014 14:48:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/GUEJuxFpCrdvj8maXAhwojWAHiU Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 21:48:35 -0000 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 : Router Keying for BGPsec Authors : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-07.txt Pages : 11 Date : 2014-05-23 Abstract: BGPsec-speaking routers are provisioned with private keys to sign BGP messages; the corresponding public keys are published in the global RPKI (Resource Public Key Infrastructure) thereby enabling verification of BGPsec messages. This document describes two ways of provisioning the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 23 14:55:14 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616A81A00BE for ; Fri, 23 May 2014 14:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK6iL6Lou-j8 for ; Fri, 23 May 2014 14:55:11 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.154.24]) by ietfa.amsl.com (Postfix) with ESMTP id 518131A00C9 for ; Fri, 23 May 2014 14:55:11 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 4912D30782078; Fri, 23 May 2014 16:55:09 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 4087730781DFD for ; Fri, 23 May 2014 16:55:08 -0500 (CDT) Received: from [96.231.225.192] (port=57853 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WnxQh-0000SC-Ng for sidr@ietf.org; Fri, 23 May 2014 16:55:07 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sean Turner In-Reply-To: <20140523214834.1202.3087.idtracker@ietfa.amsl.com> Date: Fri, 23 May 2014 17:55:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140523214834.1202.3087.idtracker@ietfa.amsl.com> To: sidr@ietf.org X-Mailer: Apple Mail (2.1878.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WnxQh-0000SC-Ng X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:57853 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/JfNdX_uSXY3FmWMOfK3ASkukPVg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 21:55:12 -0000 Addresses some editorial issues I got off-list. spt On May 23, 2014, at 17:48, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Router Keying for BGPsec > Authors : Sean Turner > Keyur Patel > Randy Bush > Filename : draft-ietf-sidr-rtr-keying-07.txt > Pages : 11 > Date : 2014-05-23 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys to sign = BGP > messages; the corresponding public keys are published in the global > RPKI (Resource Public Key Infrastructure) thereby enabling > verification of BGPsec messages. This document describes two ways = of > provisioning the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=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