From carlosm3011@gmail.com Mon Sep 2 22:22:19 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFAD11E8171 for ; Mon, 2 Sep 2013 22:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcz2mBETgWAH for ; Mon, 2 Sep 2013 22:22:18 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0050911E8166 for ; Mon, 2 Sep 2013 22:22:17 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eo20so4202343lab.34 for ; Mon, 02 Sep 2013 22:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uCqqE6rD/wYlBI0I9j27jjPaXYGCeluU8PDSi8CEDJk=; b=f16bVL32yqh4TgkWrx7GV/hKNR5mHpYtamHLsnIZUWMU1abyrKr5QpGTpCoe2k7wF1 YezIrHSttfb/r1C+koyqhslQjJqu1NbHLhlIB4GoiQq0TrPhphsfppnPBFacmp8kRfC6 L83yYxmsCndN1Vc5HpLkgpChS5hysEdkoXkAPPlfB1DkqQ4XYtFwSCdBtrBPtjxZzEex +hMg4kIiQ+W6jv/ZR/vo18rK83eF7ROVLdMl2et/bBdIg6VYTHFNEFQIIU6/Yf+bN+Dw NV3XIPQtjbYFXGmRYlnzIp5FeZKfQgyQnWjrOkBO0fC3Kv3ARDzQnWDbxJ3YtAXe/NIl iElw== MIME-Version: 1.0 X-Received: by 10.152.22.198 with SMTP id g6mr24611095laf.5.1378185736885; Mon, 02 Sep 2013 22:22:16 -0700 (PDT) Received: by 10.112.167.170 with HTTP; Mon, 2 Sep 2013 22:22:16 -0700 (PDT) In-Reply-To: <52173924.2030102@NLnetLabs.nl> References: <24B20D14B2CD29478C8D5D6E9CBB29F6749DEA4E@CVA-MB001.centreville.ads.sparta.com> <52173924.2030102@NLnetLabs.nl> Date: Tue, 3 Sep 2013 02:22:16 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: Benno Overeinder Content-Type: multipart/alternative; boundary=089e0160bab0481c8804e573df8a Cc: "sidr@ietf.org" Subject: Re: [sidr] call for indication of interest: draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 05:22:19 -0000 --089e0160bab0481c8804e573df8a Content-Type: text/plain; charset=ISO-8859-1 Agreed, I think the draft is useful (although I'm with George here, my RPSL is rusty at best) On Fri, Aug 23, 2013 at 7:27 AM, Benno Overeinder wrote: > I am also in favour of pursuing this draft. I do see a benefit in > signing RPSL objects. > > I understand the argument of Randy: with the keys in the RPKI one can > sign anything such as bank transactions, and indeed that doesn't mean we > have to do so. But RPSL objects are close to the practice of routing, > just like RPKI. And although technically they are different > infrastructures, operationally both technologies are used for > overlapping goals. I also see advantages for deployment and transition > strategies. And there are situations in which ISPs will keep using RPSL > and the added authoritative information from RPKI would be a great plus. > > If the WG thinks this work should proceed, I am available as an > additional author/editor of the draft (given the current authors agree > with suggestion of chairs). > > -- Benno > > On 08/23/2013 12:48 AM, George Michaelson wrote: > > I believe this work is important and should continue, and be adopted by > > the WG as a deliverable. RPKI has the capability to provide PKI > > assurance over information which lies outside of BGP, as well as > > informing BGP, and I think constructing the appropriate formalisms over > > signing of RPSL objects will materially enhance trust in the statements > > made in RPSL, relating to internet number resources. > > > > I have no competency to work on this draft. I would encourage others to > > get involved. > > > > -George > > > > > > On Fri, Aug 23, 2013 at 6:07 AM, Murphy, Sandra > > > wrote: > > > > The authors of the draft-ietf-sidr-rpsl-sig have both indicated that > > they see a need for this draft and are still interested in pursuing > > the work. > > > > But they both have been appointed to positions that put strong > > demands on their time. > > > > Therefore, they would like some indication from the wg that the wg > > also is interested in pursuing the work. > > > > And the co-chairs think it would be helpful to have an additional > > author/editor on this draft. > > > > So. > > > > Please do state whether you believe the wg should continue work in > > this area. Responses by 5 Sep, please. > > > > If you would be interested in serving as an additional author on > > this draft, please do say so. > > > > --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 > > > > -- > Benno J. Overeinder > NLnet Labs > http://www.nlnetlabs.nl/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= --089e0160bab0481c8804e573df8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agreed, I think the draft is useful (although I'm with= George here, my RPSL is rusty at best)

On Fri, Aug 23, 2013 at 7:27 AM, Benno Over= einder <benno@nlnetlabs.nl> wrote:
I am also in favour of pursuing this draft. = =A0I do see a benefit in
signing RPSL objects.

I understand the argument of Randy: with the keys in the RPKI one can
sign anything such as bank transactions, and indeed that doesn't mean w= e
have to do so. =A0But RPSL objects are close to the practice of routing, just like RPKI. =A0And although technically they are different
infrastructures, operationally both technologies are used for
overlapping goals. =A0I also see advantages for deployment and transition strategies. =A0And there are situations in which ISPs will keep using RPSL<= br> and the added authoritative information from RPKI would be a great plus.
If the WG thinks this work should proceed, I am available as an
additional author/editor of the draft (given the current authors agree
with suggestion of chairs).

-- Benno

On 08/23/2013 12:48 AM, George Michaelson wrote:
> I believe this work is important and should continue, and be adopted b= y
> the WG as a deliverable. RPKI has the capability to provide PKI
> assurance over information which lies outside of BGP, as well as
> informing BGP, and I think constructing the appropriate formalisms ove= r
> signing of RPSL objects will materially enhance trust in the statement= s
> made in RPSL, relating to internet number resources.
>
> I have no competency to work on this draft. I would encourage others t= o
> get involved.
>
> -George
>
>
> On Fri, Aug 23, 2013 at 6:07 AM, Murphy, Sandra
> <Sandra.Murphy@parsons.com <mailto:Sandra.Murphy@parsons.com>> wrote:
>
> =A0 =A0 The authors of the draft-ietf-sidr-rpsl-sig have both indicate= d that
> =A0 =A0 they see a need for this draft and are still interested in pur= suing
> =A0 =A0 the work.
>
> =A0 =A0 But they both have been appointed to positions that put strong=
> =A0 =A0 demands on their time.
>
> =A0 =A0 Therefore, they would like some indication from the wg that th= e wg
> =A0 =A0 also is interested in pursuing the work.
>
> =A0 =A0 And the co-chairs think it would be helpful to have an additio= nal
> =A0 =A0 author/editor on this draft.
>
> =A0 =A0 So.
>
> =A0 =A0 Please do state whether you believe the wg should continue wor= k in
> =A0 =A0 this area. =A0Responses by 5 Sep, please.
>
> =A0 =A0 If you would be interested in serving as an additional author = on
> =A0 =A0 this draft, please do say so.
>
> =A0 =A0 --Sandy, speaking as wg co-chair
> =A0 =A0 _______________________________________________
> =A0 =A0 sidr mailing list
> =A0 =A0 sidr@ietf.org <m= ailto:sidr@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/sidr
>
>
>
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

--
Benno J. Overeinder
NLnet Labs
http://www.nlnetlabs= .nl/

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



--
=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--089e0160bab0481c8804e573df8a-- From prvs=2958acfa01=sandra.murphy@parsons.com Tue Sep 3 06:46:12 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D47811E81ED for ; Tue, 3 Sep 2013 06:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVJulKMJakqU for ; Tue, 3 Sep 2013 06:46:00 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24E11E81E9 for ; Tue, 3 Sep 2013 06:45:56 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r83DjbZp017120 for ; Tue, 3 Sep 2013 08:45:48 -0500 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1enffd8gjp-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 03 Sep 2013 08:45:47 -0500 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r83Djjh2019117 for ; Tue, 3 Sep 2013 06:45:46 -0700 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r83DjhVh017401 for ; Tue, 3 Sep 2013 06:45:45 -0700 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Tue, 3 Sep 2013 09:45:42 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: Mailman service interruption Thursday 29 Aug Thread-Index: AQHOqKtTlSplyj0lhk+Y4BUsBq0bMQ== Date: Tue, 3 Sep 2013 13:45:42 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749EACD7@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-03_06:2013-09-03, 2013-09-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=110.568 compositescore=0.0600554693842911 urlsuspect_oldscore=0.600554693842911 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0600554693842911 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309030036 Subject: [sidr] Mailman service interruption Thursday 29 Aug X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 13:46:12 -0000 Last Thursday, the routing ADs notified the routing wgs that there had been= a problem with IETF mail. The problem caused some mail messages to ietf l= ists to be dropped. It was said that all senders whose messages had been d= ropped were notified individually.=0A= =0A= A general alert to the wgs was thought to be unnecessary. However, the cla= rification below is not quite as definite that the discovery of the lost me= ssages and notification of the senders was "foolproof".=0A= =0A= So anyone who thinks that they sent mail last Thursday should look at the m= ailing list archive. Anyone who sent mail to ANY mailing list served by th= e IETF mailman server should look at the appropriate archive.=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: wgchairs-bounces@ietf.org [wgchairs-bounces@ietf.org] on behalf of Gl= en [glen@amsl.com]=0A= Sent: Thursday, August 29, 2013 7:39 PM=0A= To: Glen Barney=0A= Subject: Mailman service interruption yesterday=0A= =0A= Greetings:=0A= =0A= Yesterday the IETF experienced a 5.5-hour service outage on its=0A= Mailman list processor.=0A= =0A= In this failure, Mailman started dropping messages, rather than=0A= bouncing them, as it should have done. This was problematic, because=0A= there was not an immediate indication that something was wrong, nor=0A= was there any automated or manual way that this outage could have been=0A= detected quickly. Fortunately, Pete Resnick, noted that several of=0A= his emails were not being delivered, and notified the emergency alert=0A= server at that time.=0A= =0A= Following Pete's alert, Steve Young, the IETF system administrator,=0A= logged in to the system, and was able to analyze the problem and=0A= effect resolution. He was able to restore service to Mailman and=0A= verify that mail was now flowing directly.=0A= =0A= Steve reported that the cause of the outage seems to have been a=0A= permissions setting on a directory that was incorrect. We are still=0A= investigating whether the broken setting was due to software changes,=0A= or a filesystem problem, and will continue to take steps to ensure=0A= that the current system remains healthy and operational.=0A= =0A= Because of the nature of this outage, Steve was not, unfortunately,=0A= able to recover the lost email messages themselves. But he did spend=0A= several hours processing the mail logs during the outage period, and=0A= sent notifications to all the senders that he was able to locate in=0A= the log during the outage period, asking those individuals to resend=0A= their email messages. While not a foolproof response, this was a good=0A= course of action to take in an attempt to recover the lost messages.=0A= =0A= Service has been up and running continuously since 2100PDT yesterday,=0A= and no further outages have been observed. No other services were=0A= impacted or interrupted during this time.=0A= =0A= Although not specifically mentioned in the release notes, we attribute=0A= this to the older version of Mailman currently in use. We note that=0A= we are deploying new IETF servers with the latest versions of Linux=0A= and Mailman (and other support software) to our colocation facilities=0A= next week, and hope to migrate the IETF to those servers soon. This=0A= should increase reliability and - we hope! - resolve whatever bug may=0A= have caused Mailman to drop these emails.=0A= =0A= In addition it has come to my attention that no notification was sent=0A= out generally following this outage. I was out sick today, at a=0A= string of medical appointments, but I failed to make clear to AMS that=0A= someone else would need to send a notification in my absence. I=0A= apologize for the delay, therefore, in getting this notification sent=0A= out.=0A= =0A= Thank you for your patience. As always, if there are any questions,=0A= please let me know.=0A= =0A= Glen Barney=0A= IT Director=0A= AMS (IETF Secretariat)=0A= From brian@innovationslab.net Tue Sep 3 12:12:39 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2071D11E8101 for ; Tue, 3 Sep 2013 12:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiaHbrRKdSaq for ; Tue, 3 Sep 2013 12:12:33 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45821F9C78 for ; Tue, 3 Sep 2013 12:12:32 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3BF758811D for ; Tue, 3 Sep 2013 12:12:32 -0700 (PDT) Received: from 10252815.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0E651130003 for ; Tue, 3 Sep 2013 12:12:31 -0700 (PDT) Message-ID: <522634A9.4080809@innovationslab.net> Date: Tue, 03 Sep 2013 15:12:41 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F6749DEA4E@CVA-MB001.centreville.ads.sparta.com> <52173924.2030102@NLnetLabs.nl> In-Reply-To: <52173924.2030102@NLnetLabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] call for indication of interest: draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:12:39 -0000 On 8/23/13 6:27 AM, Benno Overeinder wrote: > I am also in favour of pursuing this draft. I do see a benefit in > signing RPSL objects. > > I understand the argument of Randy: with the keys in the RPKI one can > sign anything such as bank transactions, and indeed that doesn't mean we > have to do so. But RPSL objects are close to the practice of routing, > just like RPKI. And although technically they are different > infrastructures, operationally both technologies are used for > overlapping goals. I also see advantages for deployment and transition > strategies. And there are situations in which ISPs will keep using RPSL > and the added authoritative information from RPKI would be a great plus. > > If the WG thinks this work should proceed, I am available as an > additional author/editor of the draft (given the current authors agree > with suggestion of chairs). > I have not talked to Robert about this, but I would be fine with letting Benno help update the draft to take into account the WGLC comments. Regards, Brian From prvs=2958acfa01=sandra.murphy@parsons.com Tue Sep 3 14:56:06 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596F011E8145 for ; Tue, 3 Sep 2013 14:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8wDlHcOoSuX for ; Tue, 3 Sep 2013 14:55:59 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0023011E8142 for ; Tue, 3 Sep 2013 14:55:58 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r83LtTGD032365; Tue, 3 Sep 2013 16:55:47 -0500 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1ennud0q7f-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 03 Sep 2013 16:55:47 -0500 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r83LtjFT023967; Tue, 3 Sep 2013 14:55:46 -0700 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r83Ltii7004002; Tue, 3 Sep 2013 14:55:44 -0700 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Tue, 3 Sep 2013 17:55:43 -0400 From: "Murphy, Sandra" To: "carlos@lacnic.net" , "sidr@ietf.org" Thread-Topic: [sidr] Requesting comments on multiple publication points Thread-Index: AQHOjxGHNibKCQ3mxkS83JNje5PNeZm0wcMR Date: Tue, 3 Sep 2013 21:55:44 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749EAE74@CVA-MB002.centreville.ads.sparta.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.62.8.137] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F6749EAE74CVAMB002centrev_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-03_06:2013-09-03, 2013-09-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=18.6703529693469 compositescore=0.0599164254646292 urlsuspect_oldscore=0.599164254646292 suspectscore=0 recipient_domain_to_sender_totalscore=1542 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=3 recipient_domain_to_sender_domain_totalscore=7979 rbsscore=0.0599164254646292 spamscore=0 recipient_to_sender_domain_totalscore=3 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309030074 Subject: Re: [sidr] Requesting comments on multiple publication points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 21:56:06 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F6749EAE74CVAMB002centrev_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There was a brief flurry of messages in response to this that lasted a week= (if you include the messages specifically taking about TAL change). The minutes note several comments during the meeting about the problem of m= aintaining consistency. This is an important topic. Now that we're back from August vacations, thi= s is a reminder to take this discussion up again. --Sandy ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Carlos Mar= tinez-Cagnazzo [carlosm3011@gmail.com] Sent: Thursday, August 01, 2013 11:50 AM To: sidr@ietf.org Subject: [sidr] Requesting comments on multiple publication points Hello all, thanks for all your input on this draft. I encourage all to send their comm= ents and discuss the draft on the list. cheers! ~Carlos --_000_24B20D14B2CD29478C8D5D6E9CBB29F6749EAE74CVAMB002centrev_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There was a brief flurry of messages in response to this that lasted = a week (if you include the messages specifically taking about TAL change).

The minutes note several comments during the meeting about the problem= of maintaining consistency.

This is an important topic.  Now that we're back from August vaca= tions, this is a reminder to take this discussion up again.

--Sandy

From: sidr-bounces@ietf.org [sidr-bounces= @ietf.org] on behalf of Carlos Martinez-Cagnazzo [carlosm3011@gmail.com] Sent: Thursday, August 01, 2013 11:50 AM
To: sidr@ietf.org
Subject: [sidr] Requesting comments on multiple publication points
Hello all,

thanks for all your input on this draft. I encourage all to send their= comments and discuss the draft on the list.

cheers!

~Carlos


--_000_24B20D14B2CD29478C8D5D6E9CBB29F6749EAE74CVAMB002centrev_-- From internet-drafts@ietf.org Thu Sep 5 08:50:18 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EFA21E8118; Thu, 5 Sep 2013 08:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVnYG+sRyg4b; Thu, 5 Sep 2013 08:50:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE0721E80C3; Thu, 5 Sep 2013 08:50:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130905155016.9835.90149.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 08:50:16 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-21.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 15:50:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-21.txt Pages : 11 Date : 2013-09-05 Abstract: Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present those which are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-origin-ops-21 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 internet-drafts@ietf.org Thu Sep 5 15:36:02 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087DB21E8183; Thu, 5 Sep 2013 15:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znbPVMf5-NPH; Thu, 5 Sep 2013 15:36:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7467C21E8127; Thu, 5 Sep 2013 15:36:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 15:36:01 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:36:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Threat Model for BGP Path Security Author(s) : Stephen Kent Andrew Chi Filename : draft-ietf-sidr-bgpsec-threats-06.txt Pages : 19 Date : 2013-09-05 Abstract: This document describes a threat model for the context in which (E)BGP path security mechanisms will be developed. The threat model includes an analysis of the RPKI, and focuses on the ability of an AS to verify the authenticity of the AS path info received in a BGP update. We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP [RFC4271], consistent with the inter-AS security focus of the RPKI [RFC6480]. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in [RFC4271]. It concludes with brief discussion of residual vulnerabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-threats-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 dave@twitter.com Thu Sep 5 16:06:51 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4921021E817C for ; Thu, 5 Sep 2013 16:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVh0f8vtyu13 for ; Thu, 5 Sep 2013 16:06:51 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 36BA221E8190 for ; Thu, 5 Sep 2013 16:06:50 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id f4so5423672iea.9 for ; Thu, 05 Sep 2013 16:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5F95xDzxlnN14Vlb3SyzPzQRQOpfGIsm6krcIRKhP9c=; b=qjp4kz7EG3USo9aOOfeoOWWiflPkLn/pkODiybNiUw4R+BjR6BLroUoFV2JNZDN0Nr zUCN5jX0itwql7wel9fPUDl1G06S/kpASef83YfxgbrLgL4cnzd8JRs0U5PoCkFZLzGQ TUi/LrWB5frkeiUL8rlswOWLHZCPWYwqd/I2M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5F95xDzxlnN14Vlb3SyzPzQRQOpfGIsm6krcIRKhP9c=; b=CgEi1eZAPiz16hpgMWHV/tfgYDa7Z6gZzMxUPf0CFYtIqh7Mc7OW+3Y/fcqiuloAqH L0AjTUS+7m+NWMw/yjRL8deX7UImOlTzD92aRVshL8HANGfmQrfbtS8ycUQKSJKtVW4c 22qS5284FxfPRCcz1Codrkdc8o2BoiKEvvrJ7BOYIQ1rCiZgLC9+dj+9xvGLMtie9Vew vFK84ypiO3WL4wNOlopzgDr9E4NqR0u4nPyj3Fwmc8gSKKBSAJi9nxA4wUeZpS+pMDs2 W8ZJi7w05oiTmxcV7IA0U+EfVQlAGivMMiT49AEZ/7z6/FoqYuTtESt/rlVkrauGB//4 CYTw== X-Gm-Message-State: ALoCoQlB/93x/cSqUKnVZfMQrQhWt6ayZxz3jFmphPNIUHLGgk93aaRJSMA+TV8KN84hYsVrIoMU X-Received: by 10.50.20.99 with SMTP id m3mr7801394ige.54.1378422408609; Thu, 05 Sep 2013 16:06:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.252.41 with HTTP; Thu, 5 Sep 2013 16:06:28 -0700 (PDT) In-Reply-To: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> From: Dave Mitchell Date: Thu, 5 Sep 2013 16:06:28 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=047d7bd6b2b4042fe804e5aafa2f Cc: grow@ietf.org, sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 23:06:51 -0000 --047d7bd6b2b4042fe804e5aafa2f Content-Type: text/plain; charset=ISO-8859-1 Seems related to our draft on MITM attacks with BGPSEC lacking path validation, but expands on other attack vectors. https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpsec-no-help/ Thanks. -d On Thu, Sep 5, 2013 at 3:36 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working > Group of the IETF. > > Title : Threat Model for BGP Path Security > Author(s) : Stephen Kent > Andrew Chi > Filename : draft-ietf-sidr-bgpsec-threats-06.txt > Pages : 19 > Date : 2013-09-05 > > Abstract: > This document describes a threat model for the context in which > (E)BGP path security mechanisms will be developed. The threat model > includes an analysis of the RPKI, and focuses on the ability of an AS > to verify the authenticity of the AS path info received in a BGP > update. We use the term PATHSEC to refer to any BGP path security > technology that makes use of the RPKI. PATHSEC will secure BGP > [RFC4271], consistent with the inter-AS security focus of the RPKI > [RFC6480]. > > The document characterizes classes of potential adversaries that are > considered to be threats, and examines classes of attacks that might > be launched against PATHSEC. It does not revisit attacks against > unprotected BGP, as that topic has already been addressed in > [RFC4271]. It concludes with brief discussion of residual > vulnerabilities. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-threats-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/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --047d7bd6b2b4042fe804e5aafa2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Seems related to our draft on MITM attacks with BGPSE= C lacking path validation, but expands on other attack vectors.

https://datatracker.ietf.org/doc/draft-ietf-grow-simple-le= ak-attack-bgpsec-no-help/

Thanks.

-d


On Thu, Sep 5, 2013 at 3:36 P= M, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Secure Inter-Domain Routing Working Gro= up of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Threat Model for BGP Path Secur= ity
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Stephen Kent
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Andrew Chi
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-bgpsec-threats-06= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-09-05

Abstract:
=A0 =A0This document describes a threat model for the context in which
=A0 =A0(E)BGP path security mechanisms will be developed. =A0The threat mod= el
=A0 =A0includes an analysis of the RPKI, and focuses on the ability of an A= S
=A0 =A0to verify the authenticity of the AS path info received in a BGP
=A0 =A0update. =A0We use the term PATHSEC to refer to any BGP path security=
=A0 =A0technology that makes use of the RPKI. =A0PATHSEC will secure BGP =A0 =A0[RFC4271], consistent with the inter-AS security focus of the RPKI =A0 =A0[RFC6480].

=A0 =A0The document characterizes classes of potential adversaries that are=
=A0 =A0considered to be threats, and examines classes of attacks that might=
=A0 =A0be launched against PATHSEC. =A0It does not revisit attacks against<= br> =A0 =A0unprotected BGP, as that topic has already been addressed in
=A0 =A0[RFC4271]. =A0It concludes with brief discussion of residual
=A0 =A0vulnerabilities.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-= threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-0= 6

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-= bgpsec-threats-06


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--047d7bd6b2b4042fe804e5aafa2f-- From kent@bbn.com Fri Sep 6 11:14:44 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001EE21E80D4; Fri, 6 Sep 2013 11:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNrnsEXu17a3; Fri, 6 Sep 2013 11:14:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0DE11E80F9; Fri, 6 Sep 2013 11:14:38 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57966 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VI0YG-000FI4-78; Fri, 06 Sep 2013 14:14:36 -0400 Message-ID: <522A1B8B.70409@bbn.com> Date: Fri, 06 Sep 2013 14:14:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dave Mitchell References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: grow@ietf.org, internet-drafts@ietf.org, sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 18:14:44 -0000 Dave, This is just a cleanup pass on this doc, to address IESG comments. The doc dates back to June, 2011. So, perhaps you mean to say that your doc is related to his one :-). Steve > Seems related to our draft on MITM attacks with BGPSEC lacking path > validation, but expands on other attack vectors. > > https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpsec-no-help/ > > Thanks. > > -d From dave@twitter.com Fri Sep 6 11:25:50 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C43B11E81B8 for ; Fri, 6 Sep 2013 11:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnNZ9-PEKa8I for ; Fri, 6 Sep 2013 11:25:50 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B9EDD11E81B5 for ; Fri, 6 Sep 2013 11:25:49 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so3677009pad.32 for ; Fri, 06 Sep 2013 11:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=U+ysYSe20DKMpxwxa3cuockAVX8dCagt4Kd/63sw82U=; b=H5fm+6/Mj1/5crnr/NOIvcHItGTXmIr9pU44rrqgYgX7V+IF0S9+AePfUMEvrnH31O GSg+txyfQE19m3H1uRpGcrBEuuLYHxlS0zYfz2vfKIsnaBru2OOqCpga4Nza0Cl6WXNF Yb4n85yYOV2LCOXfAMsuNs4rI5uxMIVTyhtVg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=U+ysYSe20DKMpxwxa3cuockAVX8dCagt4Kd/63sw82U=; b=HTmBVXUTnk3blQ7WN8gRfj6kmjzWtaGNPeMS3yH3LTcVV2kEXW05PdbIi6j6LeeDEp NKve+hJ7EXuQv+Wvci7Mzszu2wC+rM9ZflkZpg+37z1rvOWwwHObTs3jqOCpE+gvpg6A i4ZzCJ6VX7VldW/CZ1LhTMPkEP7INhAd8yRAw8BHpY+y4YwTUwRiZv+LGQgwcQYYJOgU i+PoMjAc1Df5uQzQLw/qmMCBypaMWM9tO1RIkYaKMWNVDrOOx+LlymjtjObafBsq13uG +exYnli6tU5+BzbETRHxEhDa1DxpcZy8O8EJ6khq+khjfF3Uk7I9HOlUhPHOlDZtydNY UIog== X-Gm-Message-State: ALoCoQk+oebApY1L2QoDuPky8gBQFFl/7KJ14SCdubdkwHMrocdIgQA8LDA/kqNuAhsFY3WjH0uN X-Received: by 10.68.216.33 with SMTP id on1mr4441159pbc.107.1378491949330; Fri, 06 Sep 2013 11:25:49 -0700 (PDT) Received: from ?IPv6:2002:1805:bb8::5598:ad61:ca0b:c5dc? ([2002:1805:bb8:0:5598:ad61:ca0b:c5dc]) by mx.google.com with ESMTPSA id w6sm5322893pbt.32.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 11:25:48 -0700 (PDT) References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> <522A1B8B.70409@bbn.com> Mime-Version: 1.0 (1.0) In-Reply-To: <522A1B8B.70409@bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0E9ACE46-3658-407F-8BEF-CEEFD8F027EB@twitter.com> X-Mailer: iPhone Mail (10B350) From: Dave Mitchell Date: Fri, 6 Sep 2013 11:25:46 -0700 To: Stephen Kent Cc: "grow@ietf.org" , "internet-drafts@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 18:25:51 -0000 That's exactly what I meant to say. :) Apologies. Been a long, long week.=20= Being new to the IETF process, but not the industry, I have some confusion a= bout GROW I-D's as they can sometimes be very similar or partially overlappi= ng with IDR and SIDR drafts. Just trying to understand which WG's are respon= sible for what, how overlap is handled and where combining efforts makes the= most sense.=20 Thanks in advance. Have a great weekend!=20 -d On Sep 6, 2013, at 11:14 AM, Stephen Kent wrote: > Dave, >=20 > This is just a cleanup pass on this doc, to address IESG comments. The doc= dates back to June, 2011. >=20 > So, perhaps you mean to say that your doc is related to his one :-). >=20 > Steve >> Seems related to our draft on MITM attacks with BGPSEC lacking path valid= ation, but expands on other attack vectors. >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpse= c-no-help/ >>=20 >> Thanks. >>=20 >> -d From kent@bbn.com Fri Sep 6 13:38:32 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712E421F9E88; Fri, 6 Sep 2013 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lML7NTJT4sOq; Fri, 6 Sep 2013 13:38:25 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A3C6411E8198; Fri, 6 Sep 2013 13:38:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58157 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VI2nO-000Hdp-RG; Fri, 06 Sep 2013 16:38:22 -0400 Message-ID: <522A3D3E.7070709@bbn.com> Date: Fri, 06 Sep 2013 16:38:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dave Mitchell , sidr , grow@ietf.org References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> <522A1B8B.70409@bbn.com> <0E9ACE46-3658-407F-8BEF-CEEFD8F027EB@twitter.com> In-Reply-To: <0E9ACE46-3658-407F-8BEF-CEEFD8F027EB@twitter.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 20:38:32 -0000 Dave, Fair questions for a somewhat complex environment. SIDR develops security standards for inter-domain routing, working within the context of BGP standards developed by IDR. GROW has more of an operations focus, and is intended to provide input to IDR. So, your doc on route leaks, if approved in GROW, could inform IDR about changes needed to BGP to counter this problem (which is not contrary to current BGP semantics). In turn, IDR could elect to revise BGP to address this problem, and then IDR could ask SIDR to develop security mechanisms to enable ASes to enforce the revised BGP specs, for example. Steve From christopher.morrow@gmail.com Fri Sep 6 19:54:29 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCD021F8C20; Fri, 6 Sep 2013 19:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9vxTRTq1eTf; Fri, 6 Sep 2013 19:54:29 -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 F2E7321F9CA1; Fri, 6 Sep 2013 19:54:24 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id es20so3327978lab.23 for ; Fri, 06 Sep 2013 19:54: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; bh=Sly2kuBqi8+bEWyLrQhG3BQOIB/fLrzb70S1Yp0NjGQ=; b=axhpKCxSYW8GZKD9LLlVP5djy8cBiGHm7/QQbWvlhK0HQkHv/tdLB3+fK+SUWmpfa8 NE+9jNdnBLNHedwNrZke/GylXagUo20gviMYn3KXbsOooZREtpmV4YR6Ng6i68GuDQrK iOpuRmxous3zJG1A5bVAXwtl7/SCjI5UQvlUowkwIdyQIRxRD14ORuUOzsq7STqpIvYF 3ptluw2aOjMPw/MiLyqVdC+h7yt+qDwQKF/1ZAuiSbLbG8LPuH8HeJb2FQu8MozOMCd4 pAZB0mvcmKHkDkJ9yqjEQXaJ+hoIrG7AQOBDzbCF3akeudDp0dBEjQEmMQA5MUDl/JLE XiLg== MIME-Version: 1.0 X-Received: by 10.152.26.72 with SMTP id j8mr4969484lag.19.1378522463918; Fri, 06 Sep 2013 19:54:23 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.6.3 with HTTP; Fri, 6 Sep 2013 19:54:23 -0700 (PDT) In-Reply-To: <522A3D3E.7070709@bbn.com> References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> <522A1B8B.70409@bbn.com> <0E9ACE46-3658-407F-8BEF-CEEFD8F027EB@twitter.com> <522A3D3E.7070709@bbn.com> Date: Fri, 6 Sep 2013 22:54:23 -0400 X-Google-Sender-Auth: m8VCfYSTZOO8Bcrd0GECK7n6hug Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "grow@ietf.org grow@ietf.org" , sidr Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 02:54:29 -0000 On Fri, Sep 6, 2013 at 4:38 PM, Stephen Kent wrote: > Dave, > > Fair questions for a somewhat complex environment. > > SIDR develops security standards for inter-domain routing, working within > the context of > BGP standards developed by IDR. > > GROW has more of an operations focus, and is intended to provide input to > IDR. > > So, your doc on route leaks, if approved in GROW, could inform IDR about > changes > needed to BGP to counter this problem (which is not contrary to current BGP > semantics). In turn, IDR could elect to revise BGP to address this problem, > and > then IDR could ask SIDR to develop security mechanisms to enable ASes to > enforce the > revised BGP specs, for example. this does sound like the agreed upon plan ... yes. From shares@ndzh.com Mon Sep 9 10:00:25 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E456D21F999D; Mon, 9 Sep 2013 10:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.631 X-Spam-Level: X-Spam-Status: No, score=0.631 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V53jnm7O934G; Mon, 9 Sep 2013 09:59:53 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A313E11E811B; Mon, 9 Sep 2013 09:59:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Christopher Morrow'" , "'Stephen Kent'" References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> <522A1B8B.70409@bbn.com> <0E9ACE46-3658-407F-8BEF-CEEFD8F027EB@twitter.com> <522A3D3E.7070709@bbn.com> In-Reply-To: Date: Mon, 9 Sep 2013 12:59:48 -0400 Message-ID: <00ef01cead7d$fe49f4e0$fadddea0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQEYA0Sz2QbxesBuC5usyJ8aH8rAGAHPYQMHArZPU1ACb5pS5gGgA2nqApRYs4ma0afecA== X-Authenticated-User: skh@ndzh.com Cc: grow@ietf.org, 'sidr' Subject: Re: [sidr] [GROW] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:00:26 -0000 Chris: Yes, this is the correct process. You are welcome to discuss mechanism on the IDR list. Summarize the route leak context for people not reading both lists. Sue -----Original Message----- From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of Christopher Morrow Sent: Friday, September 06, 2013 10:54 PM To: Stephen Kent Cc: grow@ietf.org grow@ietf.org; sidr Subject: Re: [GROW] [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt On Fri, Sep 6, 2013 at 4:38 PM, Stephen Kent wrote: > Dave, > > Fair questions for a somewhat complex environment. > > SIDR develops security standards for inter-domain routing, working > within the context of BGP standards developed by IDR. > > GROW has more of an operations focus, and is intended to provide input > to IDR. > > So, your doc on route leaks, if approved in GROW, could inform IDR > about changes needed to BGP to counter this problem (which is not > contrary to current BGP semantics). In turn, IDR could elect to revise > BGP to address this problem, and then IDR could ask SIDR to develop > security mechanisms to enable ASes to enforce the revised BGP specs, > for example. this does sound like the agreed upon plan ... yes. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow From prvs=29644fe0aa=sandra.murphy@parsons.com Mon Sep 9 10:31:35 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3B811E8115; Mon, 9 Sep 2013 10:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCMFDPx2m486; Mon, 9 Sep 2013 10:31:30 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB621F9D96; Mon, 9 Sep 2013 10:31:30 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r89HKXlG020338; Mon, 9 Sep 2013 12:31:27 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1esey5hf7y-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 09 Sep 2013 12:31:27 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r89HVPhf021715; Mon, 9 Sep 2013 12:31:25 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r89HVOFq019196; Mon, 9 Sep 2013 12:31:24 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Mon, 9 Sep 2013 13:31:28 -0400 From: "Murphy, Sandra" To: Christopher Morrow , Stephen Kent Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt Thread-Index: AQHOq0ESr99VFbd8Wk604zbM+Nii7Jm516iAgAPVZk0= Date: Mon, 9 Sep 2013 17:31:27 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749EB956@CVA-MB002.centreville.ads.sparta.com> References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> <522A1B8B.70409@bbn.com> <0E9ACE46-3658-407F-8BEF-CEEFD8F027EB@twitter.com> <522A3D3E.7070709@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.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-09_06:2013-09-09, 2013-09-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=143.583041074578 compositescore=0.000259131885333344 urlsuspect_oldscore=0.00259131885333344 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=5 recipient_domain_to_sender_domain_totalscore=809548 rbsscore=0.000259131885333344 spamscore=0 recipient_to_sender_domain_totalscore=5 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309090091 Cc: "grow@ietf.org grow@ietf.org" , sidr Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:31:35 -0000 There's even a chair consensus statement on route leaks and forward plan:= =0A= =0A= http://www.ietf.org/mail-archive/web/sidr/current/msg06014.html=0A= =0A= --Sandy, speaking as wg co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Christophe= r Morrow [morrowc.lists@gmail.com]=0A= Sent: Friday, September 06, 2013 10:54 PM=0A= To: Stephen Kent=0A= Cc: grow@ietf.org grow@ietf.org; sidr=0A= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt=0A= =0A= On Fri, Sep 6, 2013 at 4:38 PM, Stephen Kent wrote:=0A= > Dave,=0A= >=0A= > Fair questions for a somewhat complex environment.=0A= >=0A= > SIDR develops security standards for inter-domain routing, working within= =0A= > the context of=0A= > BGP standards developed by IDR.=0A= >=0A= > GROW has more of an operations focus, and is intended to provide input to= =0A= > IDR.=0A= >=0A= > So, your doc on route leaks, if approved in GROW, could inform IDR about= =0A= > changes=0A= > needed to BGP to counter this problem (which is not contrary to current B= GP=0A= > semantics). In turn, IDR could elect to revise BGP to address this proble= m,=0A= > and=0A= > then IDR could ask SIDR to develop security mechanisms to enable ASes to= =0A= > enforce the=0A= > revised BGP specs, for example.=0A= =0A= this does sound like the agreed upon plan ... yes.=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From dave@twitter.com Mon Sep 9 14:41:29 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD9721E80A8 for ; Mon, 9 Sep 2013 14:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX84Rw9wtAoq for ; Mon, 9 Sep 2013 14:41:29 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id D116E11E8158 for ; Mon, 9 Sep 2013 14:41:28 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id qd12so4410403ieb.22 for ; Mon, 09 Sep 2013 14:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tR1hB4r6wde0iKjyreNp0/3XQRAnvW3iyRLEsx6+pYk=; b=m85qwL+DzJzl4YoT/mSqnTdZtcEQAUryX4NtA8nSMaGcm1QadbRp0lZozY7H9gL3eU lAZ+QFUVFuE/TKMW5CPxxsX2pyTRfETvRjbfTHqfdbNPWbnc2x58aQJ6egWK2KfUZmY2 EfJeYcn9eFhgc9Ebxl/BZR9+O4cAQfhLGS7fc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tR1hB4r6wde0iKjyreNp0/3XQRAnvW3iyRLEsx6+pYk=; b=jZZcXAnW/mdEMlyEY/PnlmiFdGAz+FZ4wDEM7W1OptKzdl3CZ9DsguniMgXoQkzY7+ TTyAs0SmD++ejFBD41BHWFf0YZ4cgFum4hDn+/uOkNjFfXUVg9zcv7hSdxHkYBk08ai3 /5kZIyU/79nq4MSxkZk3WfXhC+vk49iLy1LMgDDIhjST5da+9GRsp+F2V03fi3ClGTnQ 0ANJw7e6R2NdCuF+qwSYlQk/Zqwi6HVq+9ME0IbUxIYiyMBOvr1Wh5AzC8mOStAsl2AL NpC6IKgINtbs1EGPLzy7KEyhuuCeqmvSwU0mtmb8rJChGK4wouw1XUNCRQQLDAsEcbkW Fq8Q== X-Gm-Message-State: ALoCoQnHhhL1m5Rly4KtkLsu/dbmjj33imyBHa6sditgkOM1aWMG7Mmmbh2HsCct3hkaUTpBStu+ X-Received: by 10.43.117.194 with SMTP id fn2mr1625142icc.65.1378762888332; Mon, 09 Sep 2013 14:41:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.252.41 with HTTP; Mon, 9 Sep 2013 14:41:08 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6749EB956@CVA-MB002.centreville.ads.sparta.com> References: <20130905223601.21300.98910.idtracker@ietfa.amsl.com> <522A1B8B.70409@bbn.com> <0E9ACE46-3658-407F-8BEF-CEEFD8F027EB@twitter.com> <522A3D3E.7070709@bbn.com> <24B20D14B2CD29478C8D5D6E9CBB29F6749EB956@CVA-MB002.centreville.ads.sparta.com> From: Dave Mitchell Date: Mon, 9 Sep 2013 14:41:08 -0700 Message-ID: To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=bcaec5186cbe30611d04e5fa4050 Cc: "grow@ietf.org grow@ietf.org" , sidr Subject: Re: [sidr] [GROW] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:41:29 -0000 --bcaec5186cbe30611d04e5fa4050 Content-Type: text/plain; charset=ISO-8859-1 Great, thanks all. Appreciate the clarification! Lots of docs and history to wade through as a process n00b and I apologize for any wasted cycles. -dave On Mon, Sep 9, 2013 at 10:31 AM, Murphy, Sandra wrote: > There's even a chair consensus statement on route leaks and forward plan: > > http://www.ietf.org/mail-archive/web/sidr/current/msg06014.html > > --Sandy, speaking as wg co-chair > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of > Christopher Morrow [morrowc.lists@gmail.com] > Sent: Friday, September 06, 2013 10:54 PM > To: Stephen Kent > Cc: grow@ietf.org grow@ietf.org; sidr > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt > > On Fri, Sep 6, 2013 at 4:38 PM, Stephen Kent wrote: > > Dave, > > > > Fair questions for a somewhat complex environment. > > > > SIDR develops security standards for inter-domain routing, working within > > the context of > > BGP standards developed by IDR. > > > > GROW has more of an operations focus, and is intended to provide input to > > IDR. > > > > So, your doc on route leaks, if approved in GROW, could inform IDR about > > changes > > needed to BGP to counter this problem (which is not contrary to current > BGP > > semantics). In turn, IDR could elect to revise BGP to address this > problem, > > and > > then IDR could ask SIDR to develop security mechanisms to enable ASes to > > enforce the > > revised BGP specs, for example. > > this does sound like the agreed upon plan ... yes. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > --bcaec5186cbe30611d04e5fa4050 Content-Type: text/html; charset=ISO-8859-1
Great, thanks all. Appreciate the clarification!

Lots of docs and history to wade through as a process n00b and I apologize for any wasted cycles.

</thread>

-dave


On Mon, Sep 9, 2013 at 10:31 AM, Murphy, Sandra <Sandra.Murphy@parsons.com> wrote:
There's even a chair consensus statement on route leaks and forward plan:

http://www.ietf.org/mail-archive/web/sidr/current/msg06014.html

--Sandy, speaking as wg co-chair
________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Christopher Morrow [morrowc.lists@gmail.com]
Sent: Friday, September 06, 2013 10:54 PM
To: Stephen Kent
Cc: grow@ietf.org grow@ietf.org; sidr
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt

On Fri, Sep 6, 2013 at 4:38 PM, Stephen Kent <kent@bbn.com> wrote:
> Dave,
>
> Fair questions for a somewhat complex environment.
>
> SIDR develops security standards for inter-domain routing, working within
> the context of
> BGP standards developed by IDR.
>
> GROW has more of an operations focus, and is intended to provide input to
> IDR.
>
> So, your doc on route leaks, if approved in GROW, could inform IDR about
> changes
> needed to BGP to counter this problem (which is not contrary to current BGP
> semantics). In turn, IDR could elect to revise BGP to address this problem,
> and
> then IDR could ask SIDR to develop security mechanisms to enable ASes to
> enforce the
> revised BGP specs, for example.

this does sound like the agreed upon plan ... yes.
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

--bcaec5186cbe30611d04e5fa4050-- From iesg-secretary@ietf.org Mon Sep 9 15:26:07 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE0C21E8097; Mon, 9 Sep 2013 15:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8DiXiaOWrhL; Mon, 9 Sep 2013 15:26:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEEA21F9FA7; Mon, 9 Sep 2013 15:26:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130909222606.3593.32383.idtracker@ietfa.amsl.com> Date: Mon, 09 Sep 2013 15:26:06 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (Threat Model for BGP Path Security) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 22:26:08 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Threat Model for BGP Path Security' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a threat model for the context in which (E)BGP path security mechanisms will be developed. The threat model includes an analysis of the RPKI, and focuses on the ability of an AS to verify the authenticity of the AS path info received in a BGP update. We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP [RFC4271], consistent with the inter-AS security focus of the RPKI [RFC6480]. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in [RFC4271]. It concludes with brief discussion of residual vulnerabilities. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. From kent@bbn.com Tue Sep 10 04:21:12 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A45E21E80C5 for ; Tue, 10 Sep 2013 04:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1GRZVv2t6dN for ; Tue, 10 Sep 2013 04:21:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id ECACD21F8497 for ; Tue, 10 Sep 2013 04:21:05 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39818 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VJM0G-0001XG-BX for sidr@ietf.org; Tue, 10 Sep 2013 07:21:04 -0400 Message-ID: <522F009F.50107@bbn.com> Date: Tue, 10 Sep 2013 07:21:03 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Suspenders X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:21:12 -0000 As requested by Chris, we have posted an I-D that details the data structures and procedures for which I provided a very high level overview at the SIDR meeting. Steve From kent@bbn.com Tue Sep 10 04:23:33 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C74121E80F7 for ; Tue, 10 Sep 2013 04:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASKIyEC2bQUr for ; Tue, 10 Sep 2013 04:23:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA0521E80CF for ; Tue, 10 Sep 2013 04:23:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39824 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VJM2Z-0001ZD-UI for sidr@ietf.org; Tue, 10 Sep 2013 07:23:28 -0400 Message-ID: <522F012F.6060703@bbn.com> Date: Tue, 10 Sep 2013 07:23:27 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Suspenders, redux X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 11:23:33 -0000 Whoops. I forgot to include the URL for Suspenders: http://www.ietf.org/id/draft-kent-sidr-suspenders-00.txt From christopher.morrow@gmail.com Tue Sep 10 08:57:47 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581411E81E3 for ; Tue, 10 Sep 2013 08:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aGNdRFpDM7f for ; Tue, 10 Sep 2013 08:57:41 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4A21E8143 for ; Tue, 10 Sep 2013 08:56:12 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id x18so6528091lbi.10 for ; Tue, 10 Sep 2013 08:56:11 -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=rmYZi6Wi9jC6T+V32nfP0cGiHkIkkV4qVw/UNClwrMY=; b=uLKuesBZA24AIKMO4FnLsqNbZAiH7OlfNJYoFevQ3qa0diLP7i/N/t572CNpVLx0GN f5cGMEx4ptqY9ZcCPoLZjvurNNlY8O7ZBynrmQwNCNz1FpSTOMWT3TzwC/OO04qi1wZV ngrgCee1MxyO1Dcd79vBljAEXGlgbqwT4MLGoPJCLZZk7qOivvGOp65sPo70c4m6IKP4 17Z+jDCtSoQotiCTDbE4zD5eXkglhNYtLdqfgsLUOUkK3w6mfPM931j678n2zbkqzu9u WZFyK7HU9vkjTkIRuA3wWScGTm0+g0HySmMsCqbK9tQPuuL70dmRDEQu189UdgfYXwcC koIg== MIME-Version: 1.0 X-Received: by 10.112.0.173 with SMTP id 13mr21218158lbf.8.1378828571043; Tue, 10 Sep 2013 08:56:11 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.6.3 with HTTP; Tue, 10 Sep 2013 08:56:10 -0700 (PDT) In-Reply-To: <522F012F.6060703@bbn.com> References: <522F012F.6060703@bbn.com> Date: Tue, 10 Sep 2013 11:56:10 -0400 X-Google-Sender-Auth: eOTOPDJ2QW5RyC-_14iEmUUHLzY Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr Subject: Re: [sidr] Suspenders, redux X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:57:47 -0000 great, thanks! I hope we can all have a read through prior to vancouver and plan to discuss this there. On Tue, Sep 10, 2013 at 7:23 AM, Stephen Kent wrote: > Whoops. I forgot to include the URL for Suspenders: > > http://www.ietf.org/id/draft-kent-sidr-suspenders-00.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From prvs=2967863564=sandra.murphy@parsons.com Thu Sep 12 12:02:04 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6174211E80F4 for ; Thu, 12 Sep 2013 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFqD2cp3CkkD for ; Thu, 12 Sep 2013 12:01:30 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2511A11E8249 for ; Thu, 12 Sep 2013 12:00:46 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8CJ0iKZ016409 for ; Thu, 12 Sep 2013 14:00:45 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1euk47g378-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Sep 2013 14:00:44 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8CJ0gpa011358 for ; Thu, 12 Sep 2013 14:00:42 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8CJ0g6q000586 for ; Thu, 12 Sep 2013 14:00:42 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Thu, 12 Sep 2013 15:00:41 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: meeting minutes uploaded Thread-Index: Ac6iY92cRCeV5eSuRMmKKn2HFrWllwNhmoBQ Date: Thu, 12 Sep 2013 19:00:41 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749EC35D@CVA-MB002.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6749E7CB3@CVA-MB002.centreville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6749E7CB3@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-12_07:2013-09-12, 2013-09-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=110.568 compositescore=0.0527339388916443 urlsuspect_oldscore=0.527339388916442 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0527339388916443 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309120101 Subject: Re: [sidr] meeting minutes uploaded X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:02:20 -0000 The deadline for corrections to the meeting minutes is next Wednesday, so p= lease take a look at what was uploaded and note any corrections to the list= .=0A= =0A= --Sandy, speaking as co-chair=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@parsons.com]=0A= Sent: Monday, August 26, 2013 10:32 AM=0A= To: sidr@ietf.org=0A= Subject: [sidr] meeting minutes uploaded=0A= =0A= The meeting minutes have been uploaded and should be available at the proce= edings page http://www.ietf.org/proceedings/87/minutes/minutes-87-sidr.=0A= =0A= Please do review the minutes and send any corrections or additions to the l= ist.=0A= =0A= Many thanks to Andrew Chi for serving as minutes taker. You might enjoy hi= s tagging of some remarks in the minutes.=0A= =0A= Thanks also to Dan York and Warren Kumari for serving as jabber scribes on = 31 July and Matt Lepinski on 2 Aug. For a candid, in-the-moment view, the = jabber log is archived at http://www.ietf.org/jabber/logs/sidr/2013-07-31.h= tml and http://www.ietf.org/jabber/logs/sidr/2013-08-02.html and the audio = log is http://www.ietf.org/audio/ietf87. (We were ietf87-potsdam1-20130731-= 1510-pm2.mp3 on 31 July and ietf87-charlottenburg2-3-20130802-1120-am2.mp3 = and ietf87-charlottenburg2-3-20130802-1230-pm1.mp3 on 2 Aug.)=0A= =0A= Minutes corrections deadline:=0A= =0A= 2013-09-18 (Wednesday): Proceedings submission corrections cutoff da= te by UTC 24:00=0A= =0A= --Sandy=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From randy@psg.com Thu Sep 12 12:09:17 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62F121E80C1 for ; Thu, 12 Sep 2013 12:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LClwEB5MHM-d for ; Thu, 12 Sep 2013 12:09:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 59EE221E8090 for ; Thu, 12 Sep 2013 12:09:17 -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 1VKCGQ-0008NC-V7; Thu, 12 Sep 2013 19:09:15 +0000 Date: Thu, 12 Sep 2013 09:09:13 -1000 Message-ID: From: Randy Bush To: Geoff Huston , George Michaelson User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: [sidr] draft-huston-rpki-validation-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:09:18 -0000 geoff and george, i am trying to understand $subject, and need some help. it seems the key motivation is that, in a transfer, If the original registry's certification actions are simply to issue a new certificate for the current holder with a reduced resource set, and to revoke the original certificate, then there is a distinct possibility of encountering the situation illustrated by the example in the previous section. This is a result of an operational process for certificate issuance by the parent CA being de-coupled from the certificate operations of child CA. i.e. the operational problem you fear is that a parent CA shrinking a child's certificate will not cause the child's CA to shrink subordinate certificates it has issued, and so on down the tree. but would this not be a spec violation and hence a bug? is it worth whacking validation so heavily to whitewash this corner case when good code and ops practice should prevent it? this would be a *really big* change to validation, so had best be really worthwhile. otoh, at breakfast a few weeks ago, i thought you, gih, said that this hack might make alternate views, aka LTA, much easier. if so, i might be much more tempted. if i did not mis-hear, could you expand? thanks. randy From wesley.george@twcable.com Thu Sep 12 12:31:49 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DEF11E80D7; Thu, 12 Sep 2013 12:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee7AP0BuHuvU; Thu, 12 Sep 2013 12:31:45 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D911E80D2; Thu, 12 Sep 2013 12:31:44 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,892,1371096000"; d="scan'208";a="135144170" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Sep 2013 15:27:50 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 12 Sep 2013 15:29:48 -0400 From: "George, Wes" To: "ietf@ietf.org" Date: Thu, 12 Sep 2013 15:29:47 -0400 Thread-Topic: [sidr] Last Call: (Threat Model for BGP Path Security) to Informational RFC Thread-Index: Ac6v7m3Fmqs44D6/QaitrpgmUbSsHg== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A6896A3@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Last Call: (Threat Model for BGP Path Security) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:31:49 -0000 I've reviewed this document and have some comments. First, an apology, because although I'm an active participant in the SIDR W= G, I'm pretty sure I missed the WGLC on this, so these comments shouldn't n= ecessarily be construed as me taking my argument to ietf@ietf because I fel= t that SIDR ignored my concerns. Now, my actual comments: Maybe I'm hypersensitive to such in light of recent accusations of national= actors subverting supposedly secure infrastructure to behave badly, but I = find it odd that this threats document doesn't discuss the interaction betw= een a national actor and the machinery provided by draft-ietf-sidr-ltamgmt.= i.e. a national actor imposes upon SPs that operate inside their borders t= o use their own Local (and compromised) Trust Anchor to subvert the protect= ions provided by RPKI. While this is primarily a concern for origin validat= ion, I view it as distinct from the existing discussion of attacks on a CA = covered in 4.5, and there is no equivalent Origin Validation threats docume= nt. It may be that the right path is to augment the discussion of this issu= e in the LTA management draft, and simply reference it from this draft, but= I don't think that this is discussed suitably in the security consideratio= ns of either draft. Section 4.2 is missing any discussion regarding manipulation of other route= attributes that may be used to affect a BGP route's selection, such as MED= , Local Pref. It's covered in section 5, but since this occurred to me whil= st reading section 4.2, perhaps some mention in 4.2 would be useful, I don'= t know. That said, I also think that the discussion of this topic at the end of ses= sion 5 is inadequate for a document in IETF LC. The SIDR WG made a consciou= s decision to secure *only* the AS_Path attribute, and leave other attribut= es insecure, but there is no summary of the underlying rationale supporting= this choice. Pointing to a WG charter as the sole explanation, and noting = that this document should be changed if the charter is updated is unaccepta= ble, as it provides no context to a reader that was not privy to the discus= sion leading to that charter/scope decision. It also makes reference to som= ething fairly ephemeral (a WG and charter) in a permanent document. Fine fo= r a draft in WG discussion to have that sort of placeholder, but not anymor= e. There is a brief (and IMO incomplete) discussion of this matter to be fo= und in section 2.3 of draft-sriram-bgpsec-design-choices that could be refe= renced, but since that document's future is unclear, some standalone discus= sion within this document might be more appropriate. At a minimum, a threat= s document should discuss why these threats are not considered high enough = risk to justify the added complexity of securing them using the RPKI. Thanks, Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > The IESG > Sent: Monday, September 09, 2013 6:26 PM > To: IETF-Announce > Cc: sidr@ietf.org > Subject: [sidr] Last Call: > (Threat Model for BGP Path Security) to Informational RFC > > > The IESG has received a request from the Secure Inter-Domain Routing WG > (sidr) to consider the following document: > - 'Threat Model for BGP Path Security' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes a threat model for the context in which > (E)BGP path security mechanisms will be developed. The threat model > includes an analysis of the RPKI, and focuses on the ability of an AS > to verify the authenticity of the AS path info received in a BGP > update. We use the term PATHSEC to refer to any BGP path security > technology that makes use of the RPKI. PATHSEC will secure BGP > [RFC4271], consistent with the inter-AS security focus of the RPKI > [RFC6480]. > > The document characterizes classes of potential adversaries that are > considered to be threats, and examines classes of attacks that might > be launched against PATHSEC. It does not revisit attacks against > unprotected BGP, as that topic has already been addressed in > [RFC4271]. It concludes with brief discussion of residual > vulnerabilities. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ballot/ > > > No IPR declarations have been submitted directly on this I-D. Anything below this line has been added by my company's mail server, I have= no control over it. ----------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From prvs=2967863564=sandra.murphy@parsons.com Thu Sep 12 14:41:24 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45F621E820E for ; Thu, 12 Sep 2013 14:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv6dmnKNpf7r for ; Thu, 12 Sep 2013 14:41:18 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id C557021E80B9 for ; Thu, 12 Sep 2013 14:41:18 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8CLed5E028616; Thu, 12 Sep 2013 16:40:55 -0500 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1euk47gv17-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 12 Sep 2013 16:40:54 -0500 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r8CLeafH026392; Thu, 12 Sep 2013 14:40:37 -0700 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r8CLeZV7000554; Thu, 12 Sep 2013 14:40:35 -0700 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Thu, 12 Sep 2013 17:40:34 -0400 From: "Murphy, Sandra" To: Randy Bush , Geoff Huston , "George Michaelson" Thread-Topic: [sidr] draft-huston-rpki-validation-00.txt Thread-Index: AQHOr+ug8v5hAlaBEk6Q1jJIfPBW4pnCoVJ5 Date: Thu, 12 Sep 2013 21:40:33 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749EC3F0@CVA-MB002.centreville.ads.sparta.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.62.8.137] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-12_07:2013-09-12, 2013-09-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=7.88562963511659 compositescore=0.0195919489280896 urlsuspect_oldscore=0.246483884955027 suspectscore=0 recipient_domain_to_sender_totalscore=1816 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=25 recipient_domain_to_sender_domain_totalscore=7979 rbsscore=0.0195919489280896 spamscore=0 recipient_to_sender_domain_totalscore=27 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309120128 Cc: sidr wg list Subject: Re: [sidr] draft-huston-rpki-validation-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 21:41:24 -0000 Speaking as regular ol' member=0A= =0A= >i am trying to understand $subject, and need some help. =A0it seems the=0A= =0A= I also don't fully grasp the problem or the solution, and so of course I do= n't quite grasp how the solution solves the problem.=0A= =0A= So I would also like some help in understanding.=0A= =0A= >i.e. the operational problem you fear is that a parent CA shrinking a=0A= >child's certificate will not cause the child's CA to shrink subordinate=0A= >certificates it has issued, and so on down the tree.=0A= =0A= I don't quite follow this statement. =A0I didn't think causality was the pr= oblem, but lack of synchronization, lack of concurrence in time.=0A= =0A= In the case of transfer, the child CA is an aware and willing participant. = Yes? =A0So child CA could take the action to request the parent split its C= A cert into two CA certs and avoid the problem that way. =A0No? =A0But like= I said, I don't quite grasp the problem.=0A= =0A= --Sandy, speaking as regular ol' member=0A= ________________________________________=0A= From internet-drafts@ietf.org Thu Sep 12 16:08:12 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC8321E811B; Thu, 12 Sep 2013 16:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQDwPtBOgOP1; Thu, 12 Sep 2013 16:08:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4AA21E80E7; Thu, 12 Sep 2013 16:08:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130912230812.12802.67027.idtracker@ietfa.amsl.com> Date: Thu, 12 Sep 2013 16:08:12 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 23:08:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Router Keying for BGPsec Author(s) : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-02.txt Pages : 9 Date : 2013-09-12 Abstract: BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global RPKI (Resource Public Key Infrastructure). This document describes two ways of provisioning public/private keys, 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-02 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 turners@ieca.com Thu Sep 12 16:10:53 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A1621F9E01 for ; Thu, 12 Sep 2013 16:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.341 X-Spam-Level: X-Spam-Status: No, score=-102.341 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxBUYtHBghV0 for ; Thu, 12 Sep 2013 16:10:48 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.179.5]) by ietfa.amsl.com (Postfix) with ESMTP id 54E2321F9DCF for ; Thu, 12 Sep 2013 16:10:48 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 756193975714A; Thu, 12 Sep 2013 18:10:26 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 4AEA939757118 for ; Thu, 12 Sep 2013 18:10:26 -0500 (CDT) Received: from [96.231.225.44] (port=63038 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VKG2A-0003TL-00 for sidr@ietf.org; Thu, 12 Sep 2013 18:10:46 -0500 Message-ID: <523249F5.10602@ieca.com> Date: Thu, 12 Sep 2013 19:10:45 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr@ietf.org References: <20130912230812.12802.67027.idtracker@ietfa.amsl.com> In-Reply-To: <20130912230812.12802.67027.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:63038 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 23:10:53 -0000 Better late than never? I believe this version addresses Wes' comments (if he can remember them :) spt On 9/12/13 7:08 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : Router Keying for BGPsec > Author(s) : Sean Turner > Keyur Patel > Randy Bush > Filename : draft-ietf-sidr-rtr-keying-02.txt > Pages : 9 > Date : 2013-09-12 > > Abstract: > BGPsec-speaking routers must be provisioned with private keys and the > corresponding public key must be published in the global RPKI > (Resource Public Key Infrastructure). This document describes two > ways of provisioning public/private keys, 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-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-02 > > > 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/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From gih@apnic.net Thu Sep 12 17:08:27 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6DC21F9E88 for ; Thu, 12 Sep 2013 17:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.443 X-Spam-Level: X-Spam-Status: No, score=-99.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpCumX+-1Ekt for ; Thu, 12 Sep 2013 17:08:23 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id CD94F21F9E73 for ; Thu, 12 Sep 2013 17:08:17 -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=+sN1TbOIv9nYwBHDQ27QjL+MQJ1wKMZhNwNT5nritEc=; b=qXtJjEK3KfW6SKBd4OFe/8cQiCa+oL/+nxtE4XM0gVDJ5hNA/7T8yiEXyCluNGXRInOCp8m5Av4jF uRCDMF3mrutdYxdz4M53Aa3gUbf3rADZ7h6iTupyJOvaA5ckUeETbkw3L7zIJ3Zv8tDhHzE7FVRnu6 U4RoxPFYiOAb1lWk= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 13 Sep 2013 10:07:52 +1000 (EST) Received: from aarnet-kab-ws1.canberra.aarnet.edu.au (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 13 Sep 2013 10:08:14 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Geoff Huston In-Reply-To: Date: Fri, 13 Sep 2013 10:08:15 +1000 Content-Transfer-Encoding: 7bit Message-ID: <4A0CE699-8DB6-4391-B612-B359283B55D9@apnic.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1508) Cc: George Michaelson , sidr wg list Subject: Re: [sidr] draft-huston-rpki-validation-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 00:08:27 -0000 On 13/09/2013, at 5:09 AM, Randy Bush wrote: > geoff and george, > > i am trying to understand $subject, and need some help. it seems the > key motivation is that, in a transfer, > > If the original registry's certification actions are simply to issue > a new certificate for the current holder with a reduced resource set, > and to revoke the original certificate, then there is a distinct > possibility of encountering the situation illustrated by the example > in the previous section. This is a result of an operational process > for certificate issuance by the parent CA being de-coupled from the > certificate operations of child CA. > > i.e. the operational problem you fear is that a parent CA shrinking a > child's certificate will not cause the child's CA to shrink subordinate > certificates it has issued, and so on down the tree. > > but would this not be a spec violation and hence a bug? is it worth > whacking validation so heavily to whitewash this corner case when good > code and ops practice should prevent it? > > this would be a *really big* change to validation, so had best be really > worthwhile. > > otoh, at breakfast a few weeks ago, i thought you, gih, said that this > hack might make alternate views, aka LTA, much easier. if so, i might > be much more tempted. if i did not mis-hear, could you expand? > The problem is that when a CA is compelled to remove a resource from a certificate (be it a court order, pressure from some agency, or fat fingers, or any other reason), the all the subordinate certificates that include the removed resource are henceforth invalid. And thats not just invalid for the resource that was removed - thats ALL resources in these subordinate certificate that include the removed resource. Trying to create workarounds that allow relying parties to patch up this are messy, and are reliant on these relying parties being aware of the problem and ready and willing to go to some considerable lengths to generate local material that would validate these otherwise invalid certificates. The alternate approach is to alter the validity consideration as per the draft. In this case when the CA issues its shrunken resource set all the subordinate certificates from this CA remain valid in the context of all resources other than the removed resource. Which means that subordinate CAs are not compelled to re-issue certificates in order to protect the validity of their signed products. This is a big win imho. Secondly, the workaround by relying parties need only be concerned with the production of local trust material for the resource that has been removed. Nothing more. This makes the workaround process a lot easier, as a relying party can generate a local TA that references just the disputed resource and acts as a TA for the certificate that would otherwise be considered invalid _for this disputed resource_. Obviously I could expand more, but I hope that is a decent explanation of what I was saying at the time regards, Geoff From wesley.george@twcable.com Mon Sep 16 11:20:51 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004E811E813F for ; Mon, 16 Sep 2013 11:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKYbgEt71Uj0 for ; Mon, 16 Sep 2013 11:20:46 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE811E82E7 for ; Mon, 16 Sep 2013 11:20:45 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,917,1371096000"; d="scan'208";a="136513691" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Sep 2013 14:20:43 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 16 Sep 2013 14:20:44 -0400 From: "George, Wes" To: Sean Turner , "sidr@ietf.org" Date: Mon, 16 Sep 2013 14:20:44 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt Thread-Index: Ac6wDVbS8LjhfO0LTfGh5wmuHf3KegC+KdKw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A84B36E@PRVPEXVS15.corp.twcable.com> References: <20130912230812.12802.67027.idtracker@ietfa.amsl.com> <523249F5.10602@ieca.com> In-Reply-To: <523249F5.10602@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:20:51 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Sean Turner > > Better late than never? > > I believe this version addresses Wes' comments (if he can remember them > :) > [WEG] I had to go find the email, but yes, this addresses my comments, with= one exception - we'd talked about sneakernet key transfers (copy to USB or= CF and move the card, copy back to restore) in the hardware swap case. I d= on't know if you want to explicitly mention that in section 5 or not. I'd s= ort of prefer that to hoping that router vendors understand that etc. =3D s= neakernet. :-) Did another review, found a few more mostly minor things: Section 3.1 "...can be directly transferred to the RPKI CA over the Etherne= t port..." I'd be less specific here and say something like "over the netwo= rk" since "the Ethernet port" is both ambiguous and overly specific. Also y= ou probably need to say something like "assuming that the router has direct= connectivity to the CA at this point in the provisioning process" -- for t= hat matter, it might be useful for both 3.1 and 3.2 if you were explicit ab= out what the router needs to be able to talk to both inside and outside of = the provider network at this stage of the provisioning process to make sure= that none of these validation and key exchange steps fail on account of no= t being able to talk to the right server. In other words, which of these va= lidations are local and which require communicating with an external TA, CA= , etc.? The draft currently skips from section 3 to section 5. I might suggest that= section 4 should cover key rolls (if, for example, the private key is comp= romised somehow, or if you simply wish to do this periodically), since you'= ve covered provisioning a new router, and then go to scenarios where you wa= nt to swap hardware and keep the same keys. I don't think there's a lot tha= t is different between initial provisioning and doing a key roll, but if th= ere is anything different, it's worth highlighting, especially if there are= gotchas around making sure that you don't accidentally break validation wh= en you swap router keys (overlapping expiry, etc), and if there isn't, it's= worth mentioning that the process is the same. A few grammar nits as well, but I expect the RFC editor can handle those. := -) > > Title : Router Keying for BGPsec > > Author(s) : Sean Turner > > Keyur Patel > > Randy Bush > > Filename : draft-ietf-sidr-rtr-keying-02.txt > > Pages : 9 > > Date : 2013-09-12 > > [WEG] Nice job in making this more accessible for those of us less familiar= with PKI wrangling, this is a really helpful draft. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From iesg-secretary@ietf.org Tue Sep 17 07:52:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DCD11E8477; Tue, 17 Sep 2013 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm9CtJEkj-g3; Tue, 17 Sep 2013 07:52:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D44011E8256; Tue, 17 Sep 2013 07:52:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 07:52:23 -0700 Cc: sidr@ietf.org Subject: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 14:52:28 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI-Based Origin Validation Operation' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-10-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present those which are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Tue Sep 17 14:15:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7051D11E8592; Tue, 17 Sep 2013 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1MYID86F1jy; Tue, 17 Sep 2013 14:15:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1CC11E8205; Tue, 17 Sep 2013 14:15:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917211539.13206.87012.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 14:15:39 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:15:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : Router Keying for BGPsec Author(s) : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-03.txt Pages : 8 Date : 2013-09-17 Abstract: BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global RPKI (Resource Public Key Infrastructure). This document describes two ways of provisioning public/private keys, 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-03 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 internet-drafts@ietf.org Tue Sep 17 14:22:43 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64BE11E82F1; Tue, 17 Sep 2013 14:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3PS20QS-71s; Tue, 17 Sep 2013 14:22:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9711E8145; Tue, 17 Sep 2013 14:22:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917212238.11108.89380.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 14:22:38 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:22:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : A Profile for BGPSEC Router Certificates, Certificate Re= vocation Lists, and Certification Requests Author(s) : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-06.txt Pages : 11 Date : 2013-09-17 Abstract: This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-pki-profiles-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 turners@ieca.com Tue Sep 17 14:24:25 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04B311E8197 for ; Tue, 17 Sep 2013 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOMZuAulFccF for ; Tue, 17 Sep 2013 14:24:19 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [67.18.65.19]) by ietfa.amsl.com (Postfix) with ESMTP id 86BC511E8139 for ; Tue, 17 Sep 2013 14:24:18 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id DF0D930ECBFC; Tue, 17 Sep 2013 16:24:17 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id ADAE830ECB78 for ; Tue, 17 Sep 2013 16:24:17 -0500 (CDT) Received: from [96.231.225.44] (port=55729 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VM2kr-0006zb-0A for sidr@ietf.org; Tue, 17 Sep 2013 16:24:17 -0500 Message-ID: <5238C880.2060401@ieca.com> Date: Tue, 17 Sep 2013 17:24:16 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr@ietf.org References: <20130917212238.11108.89380.idtracker@ietfa.amsl.com> In-Reply-To: <20130917212238.11108.89380.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:55729 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:24:25 -0000 This is just a keep alive version. spt On 9/17/13 5:22 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests > Author(s) : Mark Reynolds > Sean Turner > Steve Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-06.txt > Pages : 11 > Date : 2013-09-17 > > Abstract: > This document defines a standard profile for X.509 certificates for > the purposes of supporting validation of Autonomous System (AS) paths > in the Border Gateway Protocol (BGP), as part of an extension to that > protocol known as BGPSEC. BGP is a critical component for the proper > operation of the Internet as a whole. The BGPSEC protocol is under > development as a component to address the requirement to provide > security for the BGP protocol. The goal of BGPSEC is to design a > protocol for full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates specified > by this profile are issued under Resource Public Key Infrastructure > (RPKI) Certification Authority (CA) certificates, containing the AS > Identifier Delegation extension, to routers within the Autonomous > System (AS). The certificate asserts that the router(s) holding the > private key are authorized to send out secure route advertisements on > behalf of the specified AS. This document also profiles the > Certificate Revocation List (CRL), profiles the format of > certification requests, and specifies Relying Party certificate path > validation procedures. The document extends the RPKI; therefore, > this documents updates the RPKI Resource Certificates Profile (RFC > 6487). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-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/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From internet-drafts@ietf.org Tue Sep 17 14:24:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EDE11E830C; Tue, 17 Sep 2013 14:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5CjC13AZyhG; Tue, 17 Sep 2013 14:24:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FB411E81BE; Tue, 17 Sep 2013 14:24:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917212426.26282.91682.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 14:24:27 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:24:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF. Title : BGP Algorithms, Key Formats, & Signature Formats Author(s) : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-05.txt Pages : 7 Date : 2013-09-17 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-bgpsec-algs-05 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 turners@ieca.com Tue Sep 17 14:25:04 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC0511E830C for ; Tue, 17 Sep 2013 14:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O71lxl+tZMNd for ; Tue, 17 Sep 2013 14:24:59 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.52.14]) by ietfa.amsl.com (Postfix) with ESMTP id 87A6B11E8139 for ; Tue, 17 Sep 2013 14:24:59 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 172B2617CF55C; Tue, 17 Sep 2013 16:24:59 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 001C6617CF51A for ; Tue, 17 Sep 2013 16:24:59 -0500 (CDT) Received: from [96.231.225.44] (port=55734 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VM2lW-00081U-KP for sidr@ietf.org; Tue, 17 Sep 2013 16:24:58 -0500 Message-ID: <5238C8A9.7050506@ieca.com> Date: Tue, 17 Sep 2013 17:24:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sidr@ietf.org References: <20130917212426.26282.91682.idtracker@ietfa.amsl.com> In-Reply-To: <20130917212426.26282.91682.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:55734 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:25:04 -0000 This is just a keep alive version. spt On 9/17/13 5:24 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : BGP Algorithms, Key Formats, & Signature Formats > Author(s) : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-05.txt > Pages : 7 > Date : 2013-09-17 > > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format used > in BGPSEC (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (RFC 6485). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-algs > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-algs-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-05 > > > 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/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From turners@ieca.com Tue Sep 17 14:26:03 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184EA11E85B2 for ; Tue, 17 Sep 2013 14:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gjqWgc0OnNN for ; Tue, 17 Sep 2013 14:25:40 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.22.80]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4511E80D9 for ; Tue, 17 Sep 2013 14:25:34 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id D5A3B423673C3; Tue, 17 Sep 2013 16:25:11 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 831E242367343 for ; Tue, 17 Sep 2013 16:25:11 -0500 (CDT) Received: from [96.231.225.44] (port=55736 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VM2m3-0000bh-G2; Tue, 17 Sep 2013 16:25:31 -0500 Message-ID: <5238C8CA.9070909@ieca.com> Date: Tue, 17 Sep 2013 17:25:30 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "George, Wes" References: <20130912230812.12802.67027.idtracker@ietfa.amsl.com> <523249F5.10602@ieca.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A84B36E@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043A84B36E@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:55736 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:26:03 -0000 On 9/16/13 2:20 PM, George, Wes wrote: >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >> Sean Turner >> >> Better late than never? >> >> I believe this version addresses Wes' comments (if he can remember them >> :) >> > [WEG] I had to go find the email, but yes, this addresses my comments, with one exception - we'd talked about sneakernet key transfers (copy to USB or CF and move the card, copy back to restore) in the hardware swap case. I don't know if you want to explicitly mention that in section 5 or not. I'd sort of prefer that to hoping that router vendors understand that etc. = sneakernet. :-) Luckily we all have email archives ;) How about: OLD: Note that cut/copy and paste operations for keys over a certain sizes is error-prone. NEW: Note that cut/copy and paste operations over a SSH-proected CLI session for keys over a certain sizes is error-prone; a less error process is to use a USB or CF device to copy the key to and then insert the device in to the router. > Did another review, found a few more mostly minor things: > > Section 3.1 "...can be directly transferred to the RPKI CA over the Ethernet port..." I'd be less specific here and say something like "over the network" since "the Ethernet port" is both ambiguous and overly specific. Also you probably need to say something like "assuming that the router has direct connectivity to the CA at this point in the provisioning process" -- for that matter, it might be useful for both 3.1 and 3.2 if you were explicit about what the router needs to be able to talk to both inside and outside of the provider network at this stage of the provisioning process to make sure that none of these validation and key exchange steps fail on account of not being able to talk to the right server. In other words, which of these validations are local and which require communicating with an external TA, CA, etc.? Replacing Ethernet with network no problem. And, you're right the draft needs to say something about network connectivity with the entity that requests the certificate and the CA. I made the following changes: s3.1: OLD: The PKCS#10 request, which includes the public key the router wants certified, can be directly transferred to the RPKI CA over the network if the router supports protocols such as FTP and HTTP [RFC2585] using the application/pkcs10 media type [RFC5967] or EST (Enrollment over Secure Transport) [I-D.ietf-pkix-est]. NEW: The PKCS#10 request, which includes the public key the router wants certified, can be directly transferred to the RPKI CA over the network if the router supports protocols such as FTP and HTTP [RFC2585] using the application/pkcs10 media type [RFC5967] or EST (Enrollment over Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that the router has direct connectivity to the CA. OLD: The operator off-loads the PKCS#10 and uploads the request to their RPKI software management tools. NEW: The operator off-loads the PKCS#10 and uploads the request to their RPKI software management tools; external network connectivity is not required if the operator acts as CA. BTW - you'd still need external connectivity if the operator acts as the CA to publish the certificate in the RPKI. I put some words in to that affect. > The draft currently skips from section 3 to section 5. I might suggest that section 4 should cover key rolls (if, for example, the private key is compromised somehow, or if you simply wish to do this periodically), since you've covered provisioning a new router, and then go to scenarios where you want to swap hardware and keep the same keys. I don't think there's a lot that is different between initial provisioning and doing a key roll, but if there is anything different, it's worth highlighting, especially if there are gotchas around making sure that you don't accidentally break validation when you swap router keys (overlapping expiry, etc), and if there isn't, it's worth mentioning that the process is the same. I'll have to give some thought to what other requirements there are for key rollovers. I'll go ahead and publish a new version with a blank section 4 to make sure we knock out the other issues. Thanks again for the review! spt > A few grammar nits as well, but I expect the RFC editor can handle those. :-) > >>> Title : Router Keying for BGPsec >>> Author(s) : Sean Turner >>> Keyur Patel >>> Randy Bush >>> Filename : draft-ietf-sidr-rtr-keying-02.txt >>> Pages : 9 >>> Date : 2013-09-12 >>> > > [WEG] Nice job in making this more accessible for those of us less familiar with PKI wrangling, this is a really helpful draft. > > Wes > > 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 prvs=2972babdd9=sandra.murphy@parsons.com Tue Sep 17 15:22:29 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2659B11E81B4 for ; Tue, 17 Sep 2013 15:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F578efZhRTBg for ; Tue, 17 Sep 2013 15:22:23 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4911E8113 for ; Tue, 17 Sep 2013 15:22:23 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8HMMIj4016332 for ; Tue, 17 Sep 2013 17:22:22 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1exw0js0ft-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Sep 2013 17:22:22 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8HMMLir006602 for ; Tue, 17 Sep 2013 17:22:21 -0500 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8HMML9I000822 for ; Tue, 17 Sep 2013 17:22:21 -0500 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Tue, 17 Sep 2013 18:22:17 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: meeting request for IETF 88 Thread-Index: Ac6z9F/QPNR4qCtPQYuSlK3zoFoHIA== Date: Tue, 17 Sep 2013 22:22:20 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C684@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_07:2013-09-18, 2013-09-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=121.944 compositescore=0.0520922603175645 urlsuspect_oldscore=0.520922603175645 suspectscore=0 recipient_domain_to_sender_totalscore=1816 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7979 rbsscore=0.0520922603175645 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309170115 Subject: [sidr] meeting request for IETF 88 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:22:29 -0000 I requested one session for the IETF 88 meeting. I adjusted the conflicts = list as Alexey had added several.=0A= =0A= Just to be sure I've covered the important ones, please take a look at the = list:=0A= =0A= Conflicts to Avoid: =0A= First Priority: pkix opsec idr grow saag rtgwg dane rtgarea isis=0A= Second Priority: dnsop tls jose=0A= =0A= Also - it is possible to request a Meetecho or Webex session. If that woul= d be helpful to you, particularly if you already know you will be presentin= g remotely, please send the chairs or list a request.=0A= =0A= --Sandy=0A= From prvs=2972babdd9=sandra.murphy@parsons.com Tue Sep 17 15:24:46 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F2C21F9D62 for ; Tue, 17 Sep 2013 15:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zybwtYkl3nv for ; Tue, 17 Sep 2013 15:24:41 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7221F9D23 for ; Tue, 17 Sep 2013 15:24:41 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8HMN31D016763 for ; Tue, 17 Sep 2013 17:24:40 -0500 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1exw0js0sr-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Sep 2013 17:24:40 -0500 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r8HMOcwS009072 for ; Tue, 17 Sep 2013 15:24:38 -0700 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r8HMOciJ023164 for ; Tue, 17 Sep 2013 15:24:38 -0700 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Tue, 17 Sep 2013 18:24:35 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: IETF 88 pre-meeting important dates Thread-Index: Ac6z9LGAjI+nS9BBREKxpJm2TiObHw== Date: Tue, 17 Sep 2013 22:24:37 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C695@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_07:2013-09-18, 2013-09-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=121.944 compositescore=0.0594337672718611 urlsuspect_oldscore=0.594337672718611 suspectscore=0 recipient_domain_to_sender_totalscore=1816 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7979 rbsscore=0.0594337672718611 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309170115 Subject: [sidr] IETF 88 pre-meeting important dates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:24:47 -0000 Dates to remember in preparing for the upcoming meeting=0A= =0A= =0A= - 2013-09-23 (Monday): Cutoff date for requests to schedule Working Group m= eetings at UTC 24:00. To request a Working Group session, use the IETF Meet= ing Session Request Tool.=0A= - 2013-09-23 (Monday): Cutoff date for BOF proposal requests to Area Direct= ors at UTC 24:00. To request a BOF, please see instructions on Requesting a= BOF.=0A= - 2013-09-26 (Thursday): Cutoff date for Area Directors to approve BOFs at = UTC 24:00.=0A= - 2013-10-03 (Thursday): Preliminary agenda published for comment.=0A= - 2013-10-07 (Monday): Cutoff date for requests to reschedule Working Group= and BOF meetings UTC 24:00.=0A= - 2013-10-11 (Friday): Final agenda to be published.=0A= - 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC 24:00, upl= oad using IETF Meeting Materials Management Tool.=0A= - 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, uplo= ad using IETF Meeting Materials Management Tool.=0A= =0A= =0A= --Sandy=0A= From randy@psg.com Tue Sep 17 17:18:01 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A26011E815E for ; Tue, 17 Sep 2013 17:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sojvegiFmITE for ; Tue, 17 Sep 2013 17:18:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A08B11E8153 for ; Tue, 17 Sep 2013 17:17:56 -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 1VM5Ss-0007h9-1J; Wed, 18 Sep 2013 00:17:54 +0000 Date: Tue, 17 Sep 2013 14:17:53 -1000 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: <5238C8CA.9070909@ieca.com> References: <20130912230812.12802.67027.idtracker@ietfa.amsl.com> <523249F5.10602@ieca.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A84B36E@PRVPEXVS15.corp.twcable.com> <5238C8CA.9070909@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=US-ASCII Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 00:18:01 -0000 > Note that cut/copy and paste operations over a SSH-proected CLI session > for keys over a certain sizes is error-prone; a less error process is to ^-prone > use a USB or CF device to copy the key to and then insert the device in > to the router. way too detailed. you noted that pure text copy/paste is error prone. that's enough. do you really want to get into the 42 other ways of doing it? how about copy/paste of a checksummed package containing the credential? or xmodem? and don't forget paper tape! :) > The PKCS#10 request, which includes the public key the router wants > certified, can be directly transferred to the RPKI CA over the network > if the router supports protocols such as FTP and HTTP [RFC2585] using > the application/pkcs10 media type [RFC5967] or EST (Enrollment over > Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that the > router has direct connectivity to the CA. what's "direct?" are you trying to say in the same pop? on the same lan segment? or do you merely mean e2e over the intertubes? > The operator off-loads the PKCS#10 and uploads the request to their RPKI > software management tools; external network connectivity is not required > if the operator acts as CA. external to what? s/external/global/? randy From randy@psg.com Tue Sep 17 17:22:48 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2EC11E81D0 for ; Tue, 17 Sep 2013 17:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3qxeOA5RSvP for ; Tue, 17 Sep 2013 17:22:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 088BB11E812F for ; Tue, 17 Sep 2013 17:22:48 -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 1VM5Xa-0007l7-KW; Wed, 18 Sep 2013 00:22:47 +0000 Date: Tue, 17 Sep 2013 14:22:45 -1000 Message-ID: From: Randy Bush To: Sandy Murphy In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C684@CVA-MB001.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C684@CVA-MB001.centreville.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] meeting request for IETF 88 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 00:22:48 -0000 > Conflicts to Avoid: > First Priority: pkix opsec idr grow saag rtgwg dane rtgarea isis > Second Priority: dnsop tls jose i would add karp to the first tier i do not see direct relevance of the second tier items. i suspect they are just folk's personal conflicts, not conflicts of serious technical substance. if so, i might move dane and [sic] isis to second priority. randy From tim@ripe.net Wed Sep 18 01:00:14 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FA411E81BE for ; Wed, 18 Sep 2013 01:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r77cZD5GS0Qq for ; Wed, 18 Sep 2013 01:00:09 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id BDA7811E80DE for ; Wed, 18 Sep 2013 01:00:09 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VMCg9-0004jq-7t; Wed, 18 Sep 2013 10:00:07 +0200 Received: from puppy.ripe.net ([193.0.1.230] helo=[IPv6:::1]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VMCg9-0008TK-3Q; Wed, 18 Sep 2013 10:00:05 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Bruijnzeels In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C684@CVA-MB001.centreville.ads.sparta.com> Date: Wed, 18 Sep 2013 10:00:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C684@CVA-MB001.centreville.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1508) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130918 clean X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719aa195572bc3ac7b3823bac8825a7c072 Cc: "sidr@ietf.org" Subject: Re: [sidr] meeting request for IETF 88 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 08:00:14 -0000 On Sep 18, 2013, at 12:22 AM, "Murphy, Sandra" = wrote: > I requested one session for the IETF 88 meeting. I adjusted the = conflicts list as Alexey had added several. >=20 > Just to be sure I've covered the important ones, please take a look at = the list: >=20 > Conflicts to Avoid:=20 > First Priority: pkix opsec idr grow saag rtgwg dane rtgarea isis > Second Priority: dnsop tls jose >=20 Many RIR folk are interested in both sidr and weirds. > Also - it is possible to request a Meetecho or Webex session. If that = would be helpful to you, particularly if you already know you will be = presenting remotely, please send the chairs or list a request. >=20 > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From wesley.george@twcable.com Wed Sep 18 06:36:15 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD4E11E82D0 for ; Wed, 18 Sep 2013 06:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hdpo345av9nO for ; Wed, 18 Sep 2013 06:36:10 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 94ED911E82D4 for ; Wed, 18 Sep 2013 06:36:07 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,929,1371096000"; d="scan'208";a="45672130" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 18 Sep 2013 09:36:03 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 18 Sep 2013 09:36:06 -0400 From: "George, Wes" To: Randy Bush , Sean Turner Date: Wed, 18 Sep 2013 09:36:05 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt Thread-Index: Ac60BIv/ctgl3hn4RNS2qtL4vHZN6gAbbaRA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A8F5110@PRVPEXVS15.corp.twcable.com> References: <20130912230812.12802.67027.idtracker@ietfa.amsl.com> <523249F5.10602@ieca.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A84B36E@PRVPEXVS15.corp.twcable.com> <5238C8CA.9070909@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 13:36:15 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Randy Bush > > > Note that cut/copy and paste operations over a SSH-proected CLI > session > > for keys over a certain sizes is error-prone; a less error process is > to > ^-prone > > use a USB or CF device to copy the key to and then insert the device > in > > to the router. > > way too detailed. you noted that pure text copy/paste is error prone. > that's enough. do you really want to get into the 42 other ways of > doing it? how about copy/paste of a checksummed package containing the > credential? or xmodem? and don't forget paper tape! :) > [WEG] Agree with Randy. Was more thinking about this in terms of the hardwa= re swap scenario (section 5), rather than initial key provisioning. You say= that vendors SHOULD allow the key to be offloaded and then provide example= s of offload methods, but sneakernet isn't one of them. I don't think we ha= ve to tell implementers to support importing a key from a filesystem (in wh= atever form) but being explicit about the ability to EXPORT it to a filesys= tem is a different matter. Thanks Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From prvs=2973a7c5e4=sandra.murphy@parsons.com Wed Sep 18 12:16:42 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B4B11E8135 for ; Wed, 18 Sep 2013 12:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI+nQ6vRcapD for ; Wed, 18 Sep 2013 12:16:33 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id E8E8C11E8132 for ; Wed, 18 Sep 2013 12:16:32 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8IJFnWM008721; Wed, 18 Sep 2013 14:16:13 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1eye9y9rye-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 18 Sep 2013 14:16:12 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8IJGAhb012038; Wed, 18 Sep 2013 14:16:10 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8IJG8oP027482; Wed, 18 Sep 2013 14:16:08 -0500 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 15:16:02 -0400 From: "Murphy, Sandra" To: "Roque Gagliano (rogaglia)" , Geoff Huston Thread-Topic: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00 Thread-Index: Ac5/P7KlsWW9gua6S/mEz+yRY2Jx6ACSJbqA///q8YCAAUv7gIAADzOAgDv5C7SAAIyLAIAD0JYAgCSPl7M= Date: Wed, 18 Sep 2013 19:16:00 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C8EC@CVA-MB001.centreville.ads.sparta.com> References: , <24B20D14B2CD29478C8D5D6E9CBB29F6749E7607@CVA-MB002.centreville.ads.sparta.com> <973B0890-766F-4023-8F35-876936E470C6@apnic.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_08:2013-09-18, 2013-09-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=14.3246112728525 compositescore=0.00820105449233881 urlsuspect_oldscore=0.23431234912671 suspectscore=0 recipient_domain_to_sender_totalscore=1933 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=4 recipient_domain_to_sender_domain_totalscore=8785 rbsscore=0.00820105449233881 spamscore=0 recipient_to_sender_domain_totalscore=4 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309180099 Cc: "sidr@ietf.org list" Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 19:16:42 -0000 Looks like this is the final word.=0A= =0A= Consensus of the wglc is that the document is good to go, with revisions.= =0A= =0A= Draft authors, could you please submit a new version with the wording sugge= sted below?=0A= =0A= As an update to RFC6487, this document broadens the class of certificates t= hat conform to the RPKI profile by explicitly including within the profile = those certificates that contain a policy qualifier as described here. A rel= ying party that performs a strict validation based on RFC6487 and fails to = support the updates described in this document, would incorrectly invalidat= e RPKI objects that implement the changes in Section 2.=0A= =0A= Note this includes one nit change of "implements" to "implement".=0A= =0A= Please also consider the nits mentioned in the message:=0A= http://www.ietf.org/mail-archive/web/sidr/current/msg06124.html=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= ________________________________________=0A= From: Roque Gagliano (rogaglia) [rogaglia@cisco.com]=0A= Sent: Monday, August 26, 2013 4:18 AM=0A= To: Geoff Huston; Murphy, Sandra=0A= Cc: Andy Newton; sidr@ietf.org list=0A= Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00=0A= =0A= Hi Geoff/Sandy,=0A= =0A= Agree that we can void the mention on the current status of the known RP. A= s the due-diligence was done, I am fine.=0A= =0A= I think your proposed text from Geoff goes well with the intention of the = original text (at least with the first sentence).It is just a matter of how= explicit we want to be in the consequences of not implementing the changes= on this document for RP parties. We and go with only his sentence or addin= g the two sentences:=0A= =0A= "As an update to RFC6487, this document broadens the class of certificates = that conform to the RPKI profile by explicitly including within the profile= those certificates that contain a policy qualifier as described here. A re= lying party that performs a strict validation based on RFC6487 and fails to= support the updates described in this document, would incorrectly invalida= te RPKI objects that implements the changes in Section 2."=0A= =0A= Roque=0A= =0A= =0A= =0A= On Aug 24, 2013, at 12:03 AM, Geoff Huston wrote:=0A= =0A= > Wouldn't it be better to note that: As an update to RFC6487, this documen= t broadens the class of certificates that conform to the RPKI profile by ex= plicitly including within the profile those certificates that contain a pol= icy qualifier as described here.=0A= >=0A= > Geoff=0A= >=0A= >=0A= >=0A= > On 24/08/2013, at 4:09 AM, "Murphy, Sandra" w= rote:=0A= >=0A= >> Speaking as working group chair:=0A= >>=0A= >> I can't be certain that this indicates a promise to modify the draft or = not. Roque, Andy, could you comment?=0A= >>=0A= >> If so, a new version is needed and I'll say so on the list.=0A= >> If not, I'll have to ask for resolution on list.=0A= >>=0A= >> Speaking as regular ol' member (and a bit as wg chair, as I'm not clear = about the intent of the new text):=0A= >>=0A= >> I don't think this text hurts anything, but I am puzzled about the inten= t. If "all known" implementations comply, why mention the problem? OTOH, = it might serve to forestall AD/IESG questions.=0A= >>=0A= >> So I agree with Andy's observation, though I'd say a heading "Backward C= ompatibility Considerations" rather than "Interoperability Considerations" = suits the situation better.=0A= >>=0A= >> (Apologies - searching for the thread, I found these comments stuck in m= y draft folder from 17 July.)=0A= >>=0A= >> --Sandy=0A= >>=0A= >> P.S.=0A= >>=0A= >> "strick"->"strict"=0A= >> "RPKI signed objects" -> "RPKI objects" =0A= >> "implements"->"include" or "contain" or...=0A= >> "RP"-> relying party (or you'll have to define the acronym somewhere)=0A= >> Not sure what ""as in IDR" means.=0A= >>=0A= >> ________________________________________=0A= >> From: Andy Newton [andy@arin.net]=0A= >> Sent: Tuesday, July 16, 2013 9:49 AM=0A= >> To: Roque Gagliano (rogaglia)=0A= >> Cc: Murphy, Sandra; sidr@ietf.org=0A= >> Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00=0A= >>=0A= >> This sounds fine to me, though it is really an interoperability=0A= >> considerations section thingy. The IETF does those now, right? :)=0A= >>=0A= >> -andy=0A= >>=0A= >> On 7/16/13 4:55 AM, "Roque Gagliano (rogaglia)" wro= te:=0A= >>=0A= >>> Thanks Andy.=0A= >>>=0A= >>> Do you think we need to add something in the security section about the= =0A= >>> transition?=0A= >>>=0A= >>> Something like:=0A= >>>=0A= >>> "A RP that performs a strick validation based on RFC6487 and fails to= =0A= >>> support the updates described in this document, would incorrectly=0A= >>> invalidate RPKI signed objects that implements the changes in Section 2= .=0A= >>> At the time of this writing, all known RP software suites (you can=0A= >>> mention them as in IDR) were tested and supported the updates on this= =0A= >>> document"=0A= >>>=0A= >>> Roque=0A= >>>=0A= >>> On Jul 15, 2013, at 7:07 PM, Andy Newton wrote:=0A= >>>=0A= >>>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" = =0A= >>>> wrote:=0A= >>>>=0A= >>>>> Before sending my support to advance to the IESG, I wanted to ask the= =0A= >>>>> author if they have tested the effects of this change on existing RP= =0A= >>>>> tools. Do they really set the certificate as invalid?=0A= >>>>=0A= >>>> Yes, we have tested against the three RP suites. One did not require a= =0A= >>>> change while the other two required simple one line changes. Current= =0A= >>>> releases of all three now accommodate it.=0A= >>>>=0A= >>>> -andy=0A= >>>>=0A= >>>=0A= >>>=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> sidr mailing list=0A= >> sidr@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sidr=0A= >=0A= =0A= From prvs=2973a7c5e4=sandra.murphy@parsons.com Wed Sep 18 12:40:52 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4121411E825A for ; Wed, 18 Sep 2013 12:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz0AFTeLIdRW for ; Wed, 18 Sep 2013 12:40:46 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id D398811E8140 for ; Wed, 18 Sep 2013 12:40:45 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8IJUeZL024439 for ; Wed, 18 Sep 2013 14:40:45 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1eye9y9wmy-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 18 Sep 2013 14:40:44 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8IJegmU012221 for ; Wed, 18 Sep 2013 14:40:42 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8IJefvB028390 for ; Wed, 18 Sep 2013 14:40:41 -0500 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 15:40:39 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: some comments on draft-ietf-sidr-cps-02 Thread-Index: AQHOozI8Ji55SGp/+0KdqEnf/YiUBJnMAaHZ Date: Wed, 18 Sep 2013 19:40:38 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C902@CVA-MB001.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6749E8EEB@CVA-MB002.centreville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6749E8EEB@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_08:2013-09-18, 2013-09-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=132.136 compositescore=0.0518105524237806 urlsuspect_oldscore=0.518105524237806 suspectscore=0 recipient_domain_to_sender_totalscore=1933 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=8785 rbsscore=0.0518105524237806 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309180101 Subject: [sidr] some comments on draft-ietf-sidr-cps-02 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 19:40:53 -0000 Some things came up as I reviewed the comments received during wglc. Most = of these are nits, but a few are substantive.=0A= =0A= The most substantial of the things that came up are about 2119 language and= the preface's suggestions for eliminating references.=0A= =0A= A long message with a lot of detail, sorry.=0A= =0A= These have been previously shared with the authors.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= Terry asked why 5.7 (key rollover and disaster recovery) was "[OMITTED]". = Steve suggested a small paragraph.=0A= =0A= David noted that sections 5.7 and 5.8 don't match 6484. Steve said that 64= 84 was in error. If I understand correctly, 6484 was supposed to omit sect= ion 5.7, and the section numbering was supposed to be maintained from 3647,= so 6484's 5.7 should be numbered 5.8.=0A= =0A= Q: The CPS is an instantiation of 3647, not a re-instantiation of 6484's in= stantiation of 3647, so it is OK if the CPS has sections from 3647 that are= not present in 6484. Correct?=0A= =0A= I agree with Steve that the change to 6484 should just be an errata (sectio= n numbering typo, not a substantive change) rather than an update.=0A= =0A= I found a couple other things, while I was trying to figure that out.=0A= =0A= Sections 9.1.2 and 9.1.3 match the section titles of 3647's 9.1.4 and 9.1.5= . I presume the CPS intended to omit 9.1.2 and 9.1.3 from 3647 and the seq= uential numbering in the draft is incorrect.=0A= =0A= I am not clear why sections 5.4.6, 5.4.7, and 5.5, which are present in 364= 7 but omitted in 6484, are present here. They are tagged as OMITTED and ha= ve no text. Why not just leave them out as you did for other sections? No= t a biggie, but I'm curious.=0A= =0A= RFC3647 is mentioned but not referenced.=0A= =0A= There are some "should" uses that might be supposed to be "SHOULD". In par= ticular I note that the text about policy qualifiers ("It should be the sam= e URI") looks like it is supposed to be 2119 language. And is that a SHOUL= D not a MUST? Out of curiosity: any concerns if a CA publishes a CPS somew= here other than in the URI of the policy qualifier and the two CPSs are dif= ferent? Confusion to the user is the only drawback I can see.=0A= =0A= I am not sure why the preface's suggestions for editing of the draft text t= o produce a CPS document includes deleting the normative references. The = CPS text that would be retained includes references to 6484, 6485 and 6487,= and there is use of 2119 language. Those are all in the normative referen= ces section and would be deleted.=0A= =0A= Another of those suggested edits is to delete the Disclaimer of Validity se= ction. But there is no section by that name. It also suggests deleting th= e section Intellectual Property Statement. There is no section of that exa= ct name, but there is a section titled "9.5. Intellectual property rights" = but I do not believe that you mean for the user to delete that section.=0A= =0A= 2.1 says=0A= at .=0A= The "SIDR" part is not a permanent reference, so likely to produce comment.= "IETF-designated"??=0A= =0A= I noticed that section 4.4.3 was added between -01 and -02. I figure that'= s (partly) because it is a MUST in 6484. That got me to looking at the MUS= Ts/SHOULDs of 6484.=0A= =0A= =0A= =0A= 2.3 says=0A= you still need to provide this information for relying parties. This=0A= should include the period of time within which a certificate will be=0A= published after the CA issues the certificate, and the period of time=0A= within which a CA will publish a CRL with an entry for a revoked=0A= certificate, after the CA revokes that certificate.>=0A= 2.3 of 6484 says the CA "MUST" specify these timeframes in the CPS.=0A= =0A= 3.1.2 of 6484 says that the CA SHOULD NOT use meaningful names, which leave= s the CA some leeway. 3.1.2 in the CPS draft says "The name of the subscri= ber will not be "meaningful" ", which is not flexible. OK, so this is a te= mplate that the CAs can modify, and that language is helpful to the desired= outcome that the subject names are meaningless. 3.1.3 says "Although Subj= ect names in certificates issued by this Organization need not be meaningfu= l," which is inconsistent with 3.1.2. And 3.1.5 says "Because the Subject = names are not intended to be meaningful". So is it "will not be meaningful= " or "need not be (not intended to be) meaningful"?=0A= =0A= 4.7.1 of 6484 says=0A= Note that if a certificate is revoked to replace the RFC 3779=0A= extensions, the replacement certificate MUST incorporate the same=0A= public key rather than a new key.=0A= 4.7.1 of the CPS draft add's a "unless" clause:=0A= If a certificate is revoked to replace the RFC 3779 extensions, the=0A= replacement certificate will incorporate the same public key, not a=0A= new key, unless the subscriber requests a re-key at the same time.=0A= Does the "unless" clause make the CPS in violation of 6484?=0A= =0A= 6.3.2 of 6484 says=0A= case, the validity period for certificates MUST be chosen by the=0A= issuing CA and described in its CPS.=0A= 6.3.2 of the CPS draft says=0A= The CA's key pair will have a validity=0A= interval of . =0A= which sounds like it does not describe the validity period of the certs it = issues, but rather the validity period of its own cert (which according to = 6484 is under the control of the CA's parent)=0A= =0A= 9 of the CPS drafts says=0A= X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DAC21F91B7 for ; Thu, 19 Sep 2013 06:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJOIXnSxYAim for ; Thu, 19 Sep 2013 06:40:28 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1975C21F8F9A for ; Thu, 19 Sep 2013 06:40:26 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so7801232lbj.41 for ; Thu, 19 Sep 2013 06:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UOHZEdZxIvQvmIFv8OpAvE0TelCVMVLLaIA4k13H78c=; b=Muaj856NdC/n+byhWfTrYZ75DyBjB9tEUcCc3yE8xNE5yDlCMWdoih6PU+9OmQtHsW 5PuhTjmdsXAIuCZDjJ0QADSkKamxa+IJwYlY98+ooCCqeDR7HUyHREoQDbY87UMtJvOx jYLnq5l2OHuJTj3pmaV+0fhq7Qev56XVX9HvBRKnyBymA2E1dHNW6kC6kqQfipmB8YfR JdWf30ISuI6myHWBiGHKiboMd2xGzM2sVE5O8x75g4gbwvV6lpZSQlc/CisVND3dA9lY 0K4YN/+k9XF9cMAurMNu2G3OhpNWpvSA4lzYxJgXalMMJCDXit1GATZ9NXQYU64JjX+/ SbwA== MIME-Version: 1.0 X-Received: by 10.152.88.20 with SMTP id bc20mr1284661lab.37.1379598009791; Thu, 19 Sep 2013 06:40:09 -0700 (PDT) Received: by 10.112.210.136 with HTTP; Thu, 19 Sep 2013 06:40:09 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C684@CVA-MB001.centreville.ads.sparta.com> Date: Thu, 19 Sep 2013 10:40:09 -0300 Message-ID: From: Carlos Martinez-Cagnazzo To: Tim Bruijnzeels Content-Type: multipart/alternative; boundary=001a11c32e884e788204e6bcb1bf Cc: "sidr@ietf.org" Subject: Re: [sidr] meeting request for IETF 88 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 13:40:34 -0000 --001a11c32e884e788204e6bcb1bf Content-Type: text/plain; charset=ISO-8859-1 +1 Plus, I won't be attending so if webex / meetecho can be requested, that'd be a plus. regards ~Carlos On Wed, Sep 18, 2013 at 5:00 AM, Tim Bruijnzeels wrote: > > On Sep 18, 2013, at 12:22 AM, "Murphy, Sandra" > wrote: > > > I requested one session for the IETF 88 meeting. I adjusted the > conflicts list as Alexey had added several. > > > > Just to be sure I've covered the important ones, please take a look at > the list: > > > > Conflicts to Avoid: > > First Priority: pkix opsec idr grow saag rtgwg dane rtgarea isis > > Second Priority: dnsop tls jose > > > > Many RIR folk are interested in both sidr and weirds. > > > > Also - it is possible to request a Meetecho or Webex session. If that > would be helpful to you, particularly if you already know you will be > presenting remotely, please send the chairs or list a request. > > > > --Sandy > > _______________________________________________ > > 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 > -- -- ========================= Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me ========================= --001a11c32e884e788204e6bcb1bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

Plus, I won't be attending so if= webex / meetecho can be requested, that'd be a plus.

regards

~Carlos


On Wed, Sep 18, 2013 at 5:00 AM, Tim Bru= ijnzeels <tim@ripe.net> wrote:

On Sep 18, 2013, at 12:22 AM, "Murphy, Sandra" <Sandra.Murphy@parsons.com> wrote:

> I requested one session for the IETF 88 meeting. =A0I adjusted the con= flicts list as Alexey had added several.
>
> Just to be sure I've covered the important ones, please take a loo= k at the list:
>
> Conflicts to Avoid:
> First Priority: pkix opsec idr grow saag rtgwg dane rtgarea isis
> Second Priority: dnsop tls jose
>

Many RIR folk are interested in both sidr and weirds.


> Also - it is possible to request a Meetecho or Webex session. =A0If th= at would be helpful to you, particularly if you already know you will be pr= esenting remotely, please send the chairs or list a request.
>
> --Sandy
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

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



--
=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--001a11c32e884e788204e6bcb1bf-- From wesley.george@twcable.com Thu Sep 19 13:48:49 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5AF21F847C for ; Thu, 19 Sep 2013 13:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 290Fe8GtfDue for ; Thu, 19 Sep 2013 13:48:45 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 61DFD21F846E for ; Thu, 19 Sep 2013 13:48:45 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,939,1371096000"; d="scan'208";a="46025478" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 19 Sep 2013 16:48:34 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 19 Sep 2013 16:48:40 -0400 From: "George, Wes" To: "sidr@ietf.org" Date: Thu, 19 Sep 2013 16:48:40 -0400 Thread-Topic: draft-ietf-sidr-as-migration-00 Thread-Index: Ac61eZ7ayB45MYBdRXKWiUq0zgjGmQ== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A9B5487@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] draft-ietf-sidr-as-migration-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:48:50 -0000 Haven't really gotten any comments on this since I made the changes to addr= ess the comments identified at WG adoption. Could I get another review pass= so that we can maybe put this one to bed? Thanks, Wes > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, July 10, 2013 1:57 PM > To: i-d-announce@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-as-migration-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing Working > Group of the IETF. > > Title : BGPSec Considerations for AS Migration > Author(s) : Wesley George > Sandy Murphy > Filename : draft-ietf-sidr-as-migration-00.txt > Pages : 14 > Date : 2013-07-10 > > 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-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From danny@tcb.net Thu Sep 19 14:23:18 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4E621F8948 for ; Thu, 19 Sep 2013 14:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZDdur6VEnmm for ; Thu, 19 Sep 2013 14:23:12 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17521F88FB for ; Thu, 19 Sep 2013 14:22:51 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 22F5C300079 for ; Thu, 19 Sep 2013 21:22:51 +0000 (UTC) Received: from dul1dmcphers-m1.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 306D4300050; Thu, 19 Sep 2013 15:22:50 -0600 (MDT) Content-Type: multipart/signed; boundary="Apple-Mail=_43F58132-CBDC-44C1-B854-339276B3FCEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Danny McPherson In-Reply-To: <20130909222606.3593.32383.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 17:22:46 -0400 Message-Id: References: <20130909222606.3593.32383.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1508) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Sep 19 15:22:51 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 523b6b2b42071471017274 X-DSPAM-Factors: 27, received+a, 0.40000, 2013+at, 0.40000, file+#+#+#+via, 0.40000, Subject*Call+draft-ietf-sidr-bgpsec-threats-06.txt, 0.40000, update+#+#+the, 0.40000, As+#+#+#+some, 0.40000, document+#+#+#+BGP, 0.40000, brief+#+of, 0.40000, developed+The, 0.40000, focuses+#+#+ability, 0.40000, Subject*Re+Last, 0.40000, participate+#+#+#+something, 0.40000, residual+#+The, 0.40000, technology+#+makes, 0.40000, may+#+sent, 0.40000, The+#+#+to, 0.40000, technology+that, 0.40000, No+#+#+#+been, 0.40000, an+#+#+the, 0.40000, that+are, 0.40000, avail+#+#+the, 0.40000, WG+#+to, 0.40000, WG+#+to, 0.40000, Subject*Model+for, 0.40000, The+#+#+#+make, 0.40000, to+#+the, 0.40000, to+#+the, 0.40000 Cc: IETF-Announce , sidr@ietf.org Subject: Re: [sidr] Last Call: (Threat Model for BGP Path Security) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 21:23:18 -0000 --Apple-Mail=_43F58132-CBDC-44C1-B854-339276B3FCEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I read this draft and tried to participate in shaping into something I = as an operator believe useful in SIDR WG, but to no avail -- IMO because = the protocol work, and then the requirements work, were largely = completed already. I believe this approach will cause more harm than = good and result in more instability than security, and it leaves some = considerable holes with which I am actually concerned about related to = inter-domain routing security (and autonomy) on the Internet. As such, = myself and some other operators published this document, which has since = been accepted and evolved as a WG document within the Global Routing = Operations WG (GROW): = http://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no-he= lp-02 =20 I've given up on SIDR, I wish them well=85. -danny On Sep 9, 2013, at 6:26 PM, The IESG wrote: >=20 > The IESG has received a request from the Secure Inter-Domain Routing = WG > (sidr) to consider the following document: > - 'Threat Model for BGP Path Security' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document describes a threat model for the context in which > (E)BGP path security mechanisms will be developed. The threat model > includes an analysis of the RPKI, and focuses on the ability of an = AS > to verify the authenticity of the AS path info received in a BGP > update. We use the term PATHSEC to refer to any BGP path security > technology that makes use of the RPKI. PATHSEC will secure BGP > [RFC4271], consistent with the inter-AS security focus of the RPKI > [RFC6480]. >=20 > The document characterizes classes of potential adversaries that are > considered to be threats, and examines classes of attacks that might > be launched against PATHSEC. It does not revisit attacks against > unprotected BGP, as that topic has already been addressed in > [RFC4271]. It concludes with brief discussion of residual > vulnerabilities. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 --Apple-Mail=_43F58132-CBDC-44C1-B854-339276B3FCEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlI7aykACgkQVbIg27AGOxqprwCfUbZLOba+0f8dMjbDrvNntvwK 2GcAn16A+2/xTtiOgZ3ztZKHqD+AUqf6 =hsMr -----END PGP SIGNATURE----- --Apple-Mail=_43F58132-CBDC-44C1-B854-339276B3FCEC-- From russw@riw.us Thu Sep 19 15:28:21 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AA921F89FF; Thu, 19 Sep 2013 15:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UIages2oIHo; Thu, 19 Sep 2013 15:28:17 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB321F89EB; Thu, 19 Sep 2013 15:28:16 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95]:64586 helo=USCSWHITER10L1C) by server.riw.us with esmtpa (Exim 4.80.1) (envelope-from ) id 1VMmhj-0005Xr-Ch; Thu, 19 Sep 2013 22:28:07 +0000 From: "Russ White" To: "'Danny McPherson'" , References: <20130909222606.3593.32383.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 19 Sep 2013 18:28:34 -0400 Message-ID: <256a01ceb587$94b69850$be23c8f0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFlnXcuBrz1DtOhODORWEqU7lVikgJG7HWVmo2cwBA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: 'IETF-Announce' , sidr@ietf.org Subject: Re: [sidr] Last Call: (Threat Model for BGP Path Security) to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 22:28:21 -0000 > I read this draft and tried to participate in shaping into something I as an > operator believe useful in SIDR WG, but to no avail -- IMO because the > protocol work, and then the requirements work, were largely completed > already. I believe this approach will cause more harm than good and result in > more instability than security, and it leaves some considerable holes with > which I am actually concerned about related to inter-domain routing security > (and autonomy) on the Internet. As such, myself and some other operators > published this document, which has since been accepted and evolved as a > WG document within the Global Routing Operations WG (GROW): > > http://tools.ietf.org/html/draft-ietf-grow-simple-leak-attack-bgpsec-no- > help-02 > > I've given up on SIDR, I wish them well.. +1 Russ From prvs=29750037bf=sandra.murphy@parsons.com Fri Sep 20 08:49:18 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6085B21F8EDF for ; Fri, 20 Sep 2013 08:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGrLneZJPhb0 for ; Fri, 20 Sep 2013 08:49:12 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id DD4F221F8F07 for ; Fri, 20 Sep 2013 08:49:10 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8KFeBxP021916 for ; Fri, 20 Sep 2013 10:49:10 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1f0cdwbb41-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 20 Sep 2013 10:49:09 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8KFn89A023879 for ; Fri, 20 Sep 2013 10:49:08 -0500 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8KFn8bB020144 for ; Fri, 20 Sep 2013 10:49:08 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::20bf:20a8:2ee8:f749%11]) with mapi id 14.02.0342.003; Fri, 20 Sep 2013 11:49:08 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: sidr - Update to a Meeting Session Request for IETF 88 Thread-Index: AQHOthgP/sgl+ftllE+XQreYg8XKfpnOxT8i Date: Fri, 20 Sep 2013 15:49:07 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CE926C@CVA-MB002.centreville.ads.sparta.com> References: <20130920154231.20975.12804.idtracker@ietfa.amsl.com> In-Reply-To: <20130920154231.20975.12804.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-20_07:2013-09-20, 2013-09-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=132.136 compositescore=0.0518105524237806 urlsuspect_oldscore=0.518105524237806 suspectscore=0 recipient_domain_to_sender_totalscore=1933 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=8785 rbsscore=0.0518105524237806 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309200065 Subject: [sidr] FW: sidr - Update to a Meeting Session Request for IETF 88 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:49:19 -0000 Here are the adjustments to our meeting request. Hopefully I caught all th= e comments.=0A= =0A= The deadline is Monday, so do let the chairs know if there are any final ad= justments.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: "IETF Meeting Session Request Tool" [session_request_developers@ietf.= org]=0A= Sent: Friday, September 20, 2013 11:42 AM=0A= To: session-request@ietf.org=0A= Cc: sidr-ads@tools.ietf.org; morrowc@ops-netman.net; Murphy, Sandra; murphy= @tis.com=0A= Subject: sidr - Update to a Meeting Session Request for IETF 88=0A= =0A= An update to a meeting session request has just been submitted by Sandra Mu= rphy, a Chair of the sidr working group.=0A= =0A= =0A= ---------------------------------------------------------=0A= Working Group Name: Secure Inter-Domain Routing=0A= Area Name: Routing Area=0A= Session Requester: Sandra Murphy=0A= =0A= Number of Sessions: 1=0A= Length of Session(s): 2.5 Hours=0A= Number of Attendees: 100=0A= Conflicts to Avoid:=0A= First Priority: isis rtgarea rtgwg saag grow idr opsec pkix weirds karp=0A= Second Priority: dnsop dane=0A= Third Priority: tls jose lisp=0A= =0A= =0A= Special Requests:=0A= meetecho session desired, some active draft authors are unable to attend = in person=0A= ---------------------------------------------------------=0A= =0A= From wesley.george@twcable.com Mon Sep 23 05:58:04 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EB221F9EC4; Mon, 23 Sep 2013 05:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngWdnVFc-Tf2; Mon, 23 Sep 2013 05:58:00 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E815121F9E1A; Mon, 23 Sep 2013 05:57:59 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,962,1371096000"; d="scan'208";a="139511610" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 23 Sep 2013 08:57:28 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 23 Sep 2013 08:57:59 -0400 From: "George, Wes" To: "ietf@ietf.org" Date: Mon, 23 Sep 2013 08:58:01 -0400 Thread-Topic: Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice Thread-Index: Ac6ztbPlACJMwTnFSrmLB+h0XUneyQEpbBVA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> In-Reply-To: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:58:04 -0000 I've reviewed multiple iterations of this draft, and I believe it is mostly= ready to go. However, the concerns I raised during WGLC in http://www.ietf.org/mail-arch= ive/web/sidr/current/msg05010.html regarding the ambiguity of some of the g= uidance regarding location of RPKI caches ("close") in section 3 still have= not been addressed. IMO if it is important enough to discuss proximity, it= is important enough to devote some words to explaining the rationale for t= hat recommendation so that operators can make an informed design decision. Thanks, Wes George > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: Tuesday, September 17, 2013 10:52 AM > To: IETF-Announce > Cc: sidr@ietf.org > Subject: Last Call: (RPKI-Based > Origin Validation Operation) to Best Current Practice > > > The IESG has received a request from the Secure Inter-Domain Routing WG > (sidr) to consider the following document: > - 'RPKI-Based Origin Validation Operation' > as Best Current Practice > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-10-01. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Deployment of RPKI-based BGP origin validation has many operational > considerations. This document attempts to collect and present those > which are most critical. It is expected to evolve as RPKI-based > origin validation continues to be deployed and the dynamics are > better understood. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Mon Sep 23 11:52:05 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8274D21F9D55; Mon, 23 Sep 2013 11:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2aoOoCRO-VL; Mon, 23 Sep 2013 11:52:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id C14EA21F8CB4; Mon, 23 Sep 2013 11:52:01 -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 1VOBEm-0000ew-4j; Mon, 23 Sep 2013 18:52:00 +0000 Date: Mon, 23 Sep 2013 08:51:59 -1000 Message-ID: From: Randy Bush To: Wesley George In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:52:05 -0000 > However, the concerns I raised during WGLC in > http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html > regarding the ambiguity of some of the guidance regarding location of > RPKI caches ("close") in section 3 still have not been addressed. IMO > if it is important enough to discuss proximity, it is important enough > to devote some words to explaining the rationale for that > recommendation so that operators can make an informed design decision. hey, thanks for caring and reviewing i think the two paragraphs you would like to see improved are As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. 'Close' is, of course, complex. One should consider trust boundaries, routing bootstrap reachability, latency, etc. If insecure transports are used between an operator's cache and their router(s), the Transport Security recommendations in [RFC6810] SHOULD be followed. In particular, operators MUST NOT use insecure transports between their routers and RPKI caches located in other Autonomous Systems. i am not against further explanation, send text. but short text. :) experiments have shown that latency between cache and router, and between caches in a cache dag, is not an appreciable issue. as the reports of these experiments are not peer reviewed, it is not clear that they are good to reference. one has been accepted at conext, but page count limit prevented the latency issue from being included :( i thought bootstrap reachability would be fairly obvious to an operator. but if simple routing and no dns dependency were not obvious to you, then a few words are indeed needed. or am i missing your point here? as the rpki-rtr protocol is beyond the border of object-based security, the operator only has transport security between the cache(s) and the router. it would probably be good to add this as it motivates the "close" and "trust boundary" cautions. what is missing from the second paragraph? section 7 of rfc6810, as referenced, was very heavily reviewed and pretty much bludgeons this one to death. of course if you have specific ideas for improvement, that'd be great. > "ok, we're going to stick it in a VM on our two national data center > compute infrastructures like the rest of our servers, we can spin up > more instances if you need to scale it" > "but RFC mumble mumble says that we shouldn't do that..." > "ok, why? And where do you want to put it?" > "ummm... 'close' to the routers? Because...reasons" i am not sure it would be useful to go into the general issue of why caches should be proximal to the consumer as it is a rather well- explored area, from akamia and limelight to dns. but if you have a sentence or two that communicates this, send it over. randy From randy@psg.com Mon Sep 23 13:46:58 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83B221F9654; Mon, 23 Sep 2013 13:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpAKSm+hLAMX; Mon, 23 Sep 2013 13:46:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 70A9E21F958A; Mon, 23 Sep 2013 13:46:58 -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 1VOD1z-0000ve-Nl; Mon, 23 Sep 2013 20:46:56 +0000 Date: Mon, 23 Sep 2013 10:46:54 -1000 Message-ID: From: Randy Bush To: Wesley George In-Reply-To: References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:46:59 -0000 take two paragraphs and call back in the morning if you are still in pain :) randy In order that routers need not perform certificate validation, cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], does not provide object-based security to the router. I.e. the router may not validate the data cryptographically from well-known trust anchor. The router trusts the cache to provide correct data and relies on transport based security for the data received from the cache. Therefore the authenticity and integrity of the data from the cache should be well protected, see Section 7 of [RFC6810]. As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. 'Close' is, of course, complex. One should consider trust boundaries, routing bootstrap reachability, latency, etc. E.g. as the router can not validate the received data using a trust anchor, it should only accept data from caches it strongly trusts to provide valid data. And a router should bootstrap from a chache which is reachable without relying on other infrastructure such as DNS or routing protocols. From prvs=2979a36a3f=sandra.murphy@parsons.com Mon Sep 23 17:01:16 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAE111E80F4 for ; Mon, 23 Sep 2013 17:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKdbIgMW2Lgs for ; Mon, 23 Sep 2013 17:01:11 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67F11E80F3 for ; Mon, 23 Sep 2013 17:01:11 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8NNtK5e026097 for ; Mon, 23 Sep 2013 19:00:56 -0500 Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1f2qyvk1wh-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Sep 2013 19:00:56 -0500 Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r8O00lxb002724 for ; Mon, 23 Sep 2013 17:00:48 -0700 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r8O00kUn032723 for ; Mon, 23 Sep 2013 17:00:46 -0700 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::20bf:20a8:2ee8:f749%11]) with mapi id 14.02.0342.003; Mon, 23 Sep 2013 20:00:45 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: IETF 88 pre-meeting important dates Thread-Index: Ac6z9LGAjI+nS9BBREKxpJm2TiObHwEw5ABD Date: Tue, 24 Sep 2013 00:00:45 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CEAC4C@CVA-MB002.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C695@CVA-MB001.centreville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C695@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-23_05:2013-09-22, 2013-09-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=132.136 compositescore=0.0591598543478303 urlsuspect_oldscore=0.591598543478303 suspectscore=0 recipient_domain_to_sender_totalscore=1933 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=8785 rbsscore=0.0591598543478303 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309230146 Subject: Re: [sidr] IETF 88 pre-meeting important dates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 00:01:16 -0000 The list I sent last week was copied form the Secretariat reminder to chair= s, so it focused on the chair actions.=0A= =0A= Here's a list from the meeting important dates site, so this includes draft= deadlines and registration deadlines.=0A= =0A= Notice that there is only one deadline for draft submissions, -00 included.= It is still necessary for wg chairs to approve any submission of a -00 wg= draft (one that is named draft-ietf-sidr-xxxx-00).=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88=0A= =0A= =0A= =0A= 2013-09-23 (Monday): Cutoff date for requests to schedule Working Group mee= tings at UTC 24:00. To request a Working Group session, use the IETF Meetin= g Session Request Tool.=0A= 2013-09-23 (Monday): Cutoff date for BOF proposal requests to Area Director= s at UTC 24:00. To request a BOF, please see instructions on Requesting a B= OF.=0A= 2013-09-26 (Thursday): Cutoff date for Area Directors to approve BOFs at UT= C 24:00.=0A= 2013-10-03 (Thursday): Preliminary agenda published for comment.=0A= 2013-10-07 (Monday): Cutoff date for requests to reschedule Working Group a= nd BOF meetings UTC 24:00.=0A= 2013-10-07 (Monday): Working Group Chair approval for initial document (Ver= sion -00) submissions appreciated by UTC 24:00.=0A= 2013-10-11 (Friday): Final agenda to be published.=0A= 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 24:00, upload using IETF ID Submission Tool.=0A= 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC 24:00, uploa= d using IETF Meeting Materials Management Tool.=0A= 2013-10-25 (Friday): Early Bird registration and payment cut-off at UTC 24:= 00.=0A= 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, upload= using IETF Meeting Materials Management Tool.=0A= 2013-10-28 (Monday): Registration cancellation cut-off at UTC 24:00.=0A= 2013-11-01 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:0= 0 local meeting time.= From david.black@emc.com Mon Sep 23 17:25:29 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FBA21F90AC; Mon, 23 Sep 2013 17:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MWu-7lNaYkL; Mon, 23 Sep 2013 17:25:25 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 36EB811E80FA; Mon, 23 Sep 2013 17:25:24 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8O0PI6W000928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 20:25:20 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com r8O0PI6W000928 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1379982320; bh=OiAhaeU72NmjliP/IuyfucKu194=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bVDriBQ1CJkq/4IjDl4YHaYV5SnbvH/wfIpRJEjIYf8+RdpknGTtlGwa6Zmmoxsxd fLMl7E35GFmtDwfgX8Z8WtJWFAFS/pUMf/3OeNFeH0n6g9DSkNaewXi8wynXgDQHgP 06/45iTutuKMkvF8cnvFHpbs+c2tIpPreaI4Sjqs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com r8O0PI6W000928 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 23 Sep 2013 17:25:04 -0700 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8O0P3dS020919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 20:25:03 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Mon, 23 Sep 2013 20:25:03 -0400 From: "Black, David" To: "kent@bbn.com" , "achi@cs.unc.edu" , "General Area Review Team (gen-art@ietf.org)" Date: Mon, 23 Sep 2013 20:25:02 -0400 Thread-Topic: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 Thread-Index: Ac64vH6VzaO+WomZQWGShOqAdRnxDw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DBB6FDA@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-EMM-GWVC: 1 X-RSA-Classifications: public X-EMM-McAfeeVC: 1 Cc: "Black, David" , "sidr@ietf.org" , "ietf@ietf.org" Subject: [sidr] Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 00:25:29 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-bgpsec-threats-06 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is on the right track, but has open issues described in the review. This draft describes the threat model for BGP Path Security. The draft generally reads well, but does contain quite a bit of serious security analysis of an important routing protocol and hence requires both security and routing expertise to fully understand. Major issue: This draft contains more than just a threat model. It also contains a high level security analysis of the security architecture/approach that applies the RPKI to secure use of BGP. That analysis appears to be good, but it's somehow disconnected from the rest of the sidr WG's work, by what I hope is simply a terminology problem: - This draft refers to the security architecture/approach for BGP as PATHSEC. - Many of the other sidr WG draft refer to that security as BGPsec In effect, the PATHSEC security architecture/approach appears to be implicit in this draft. Something's missing - if those two terms were meant to be the same, BGPsec should probably be used in this draft, otherwise, the relationship should be described. I've tagged this as a major issue, as it makes text like the following in Section 4.2 rather unclear: Stale Path Announcement: If PATHSEC-secured announcements can expire, such an announcement may be propagated with PATHSEC data that is "expired". This behavior would violate the PATHSEC goals and is considered a type of replay attack. What is "PATHSEC data"? What are "the PATHSEC goals"? The statement in the abstract that " We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI" doesn't seem to answer these questions. Minor Issue: Section 4.4 seems somewhat loose on caching by RPs, considering the importance of that caching in countering a number of the attacks described in that section - in multiple cases, RP detection of an attack relies upon the RP noticing that something has changed at the publication point wrt the RP's cached copy in a fashion that should not have happened. Statements such as "the RPKI calls for RPs to cache" and "RPs are expected to make use of local caches" strike me as a weak foundation for the level of security dependence on that caching. A pointer to a SHOULD or MUST requirement for caching by RPKI RPs in another document would alleviate this concern; surely that language exists somewhere. Nits/editorial comments: Also in Section 4.4: (The RP would be very unhappy if there is no CRL for the CA instance anyway.) Please rewrite to describe how the RP reacts to failure to find a CRL - the RP surely does something in addition to becoming "very unhappy" ;-). Some of that may already be in the sentence immediately following the "very unhappy" text. idnits 2.12.17 complains about a missing reference: =3D=3D Missing Reference: 'TCPMD5' is mentioned on line 114, but not defi= ned That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] should be informatively referenced here - it was RFC 2385, which has been obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 is obsolete will generate a different idnits warning, which is ok to ignore= . Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From wesley.george@twcable.com Tue Sep 24 09:26:45 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6CB21F9D1B; Tue, 24 Sep 2013 09:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXBfIUmcjgZ4; Tue, 24 Sep 2013 09:26:40 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 5176621F9A43; Tue, 24 Sep 2013 09:26:40 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,971,1371096000"; d="scan'208";a="46954452" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Sep 2013 12:26:23 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 24 Sep 2013 12:26:39 -0400 From: "George, Wes" To: Randy Bush Date: Tue, 24 Sep 2013 12:26:38 -0400 Thread-Topic: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice Thread-Index: Ac64jgB+HSqwJbVgSDymS4xbc+zqTQAstq4Q Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 16:26:45 -0000 > From: Randy Bush [mailto:randy@psg.com] > i think the two paragraphs you would like to see improved are [snip] > i am not against further explanation, send text. but short text. :) [WEG] just the first paragraph really, and as I'll note below - I'd love to= send text, but I don't understand one of the recommendations > > experiments have shown that latency between cache and router, and > between caches in a cache dag, is not an appreciable issue. [WEG] ok, so why is "close" important then? > i thought bootstrap reachability would be fairly obvious to an operator. > but if simple routing and no dns dependency were not obvious to you, > then a few words are indeed needed. or am i missing your point here? [WEG] yes, completely obvious. Though the last two sentences of your sugges= ted text in the other email is a useful addition > > > what is missing from the second paragraph? [WEG] I'm actually happy with second para > > > i am not sure it would be useful to go into the general issue of why > caches should be proximal to the consumer as it is a rather well- > explored area, from akamia and limelight to dns. but if you have a > sentence or two that communicates this, send it over. [WEG] Generally, I understand why closer is better for content caches (Akam= ai/llnw) and DNS, but not for RPKI caches. You're making a link between the= two that I'm not following. Both of the former benefit from proximity beca= use it reduces latency and reduces unnecessary backhaul and potentially all= ows for a geographically customized service, resulting in improved user exp= erience. If latency isn't a factor (at least in the average-sized propagati= on domain), and RPKI caches aren't particularly bandwidth intensive, why do= es proximity matter? Is this just an extension of the trust domain and limi= ted dependence on routing protocols? If so, I'd dispense with recommending = "close" because it confuses the issue and just keep the discussion about se= condary dependencies and trust domains. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Tue Sep 24 11:53:21 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6390F21F9B92; Tue, 24 Sep 2013 11:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL4-2Bd0tM+j; Tue, 24 Sep 2013 11:53:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 915E011E8160; Tue, 24 Sep 2013 11:53:17 -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 1VOXjW-0007g2-Eg; Tue, 24 Sep 2013 18:53:14 +0000 Date: Tue, 24 Sep 2013 08:53:13 -1000 Message-ID: From: Randy Bush To: Wesley George In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:53:21 -0000 hi wes, > why does proximity matter? Is this just an extension of the trust > domain and limited dependence on routing protocols? If so, I'd > dispense with recommending "close" because it confuses the issue and > just keep the discussion about secondary dependencies and trust > domains. are you really saying that i should be comfortable configuring a seattle router to use a cache in tokyo even though both are in my network and there is a pretty direct hop? 1 r0.sea.rg.net (147.28.0.4) 0.189 ms 0.306 ms 0.230 ms 2 r1.sea.rg.net (147.28.0.5) 0.307 ms 0.259 ms 0.221 ms 3 sea001bf00.iij.net (206.81.80.237) 0.336 ms 0.383 ms 0.348 ms 4 tky008bf00.IIJ.net (206.132.169.110) 88.723 ms 94.377 ms 124.044 ms 5 tky001bb10.IIJ.Net (58.138.80.18) 83.639 ms 83.701 ms 89.133 ms i am willing to hack the text. but i am just not sure that proximity is not a good attribute. the longer the wire the greater the likelihood of it being cut. randy From ttauber@1-4-5.net Tue Sep 24 12:14:19 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797E611E8177 for ; Tue, 24 Sep 2013 12:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WHRDyHQ7Ewy for ; Tue, 24 Sep 2013 12:14:14 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6D211E8169 for ; Tue, 24 Sep 2013 12:14:11 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id hj3so4325179wib.13 for ; Tue, 24 Sep 2013 12:14:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+ldUJDDvrKjAglSg9m78S8nRboXcBe6tVHWvlGIR3UI=; b=O3WuEOpt90kR69dNXzZ88lyYhmK48QVUe2C3Bc9NcIwkpvalfWwjzutLOf9hxGr8Go nGq4rpuoMTTULtPIujpm8Vrj7Q5G+hvjHmgUzxBO14+5lSsvbtKrT60UoY2H9OSMsfhV rsfQdwK2rLBU1Faq+beO1X1nRBCScwpmBvPQPdBrU7Qe8o0IsiffdUN2fc9VncBRKVMg cUYMpufSjjVab9ymrL02IlWn5kxZ6tOAQ6Di4c1neRtl+fPCCj2/G/SZmK3CfqYkGYmw DBQ7Kdon4gKDOnav0w5qJ3z1d+Owa7Z1X9MBwSyVJ6BSZnie1xY3ilUl5oVaM+lrUzii 1OdA== X-Gm-Message-State: ALoCoQnaxWuXQErQNWlEMa1pl0cU/1au9VnDPfAmNaamHItggnRcquer7YY2PDCSqGftPQ6P8rXj MIME-Version: 1.0 X-Received: by 10.180.74.209 with SMTP id w17mr19306311wiv.7.1380050049103; Tue, 24 Sep 2013 12:14:09 -0700 (PDT) Received: by 10.194.249.2 with HTTP; Tue, 24 Sep 2013 12:14:09 -0700 (PDT) X-Originating-IP: [24.104.152.66] In-Reply-To: References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> Date: Tue, 24 Sep 2013 15:14:09 -0400 Message-ID: From: Tony Tauber To: Randy Bush Content-Type: multipart/alternative; boundary=f46d043749f9f30c3404e725f03c Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 19:14:19 -0000 --f46d043749f9f30c3404e725f03c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 24, 2013 at 2:53 PM, Randy Bush wrote: > hi wes, > > > why does proximity matter? Is this just an extension of the trust > > domain and limited dependence on routing protocols? If so, I'd > > dispense with recommending "close" because it confuses the issue and > > just keep the discussion about secondary dependencies and trust > > domains. > > are you really saying that i should be comfortable configuring a seattle > router to use a cache in tokyo even though both are in my network and > there is a pretty direct hop? > Why shouldn't it just be "in the cloud" and you not care about where? Oh, because RPKI-RTR isn't an application, it's infrastructure! > 1 r0.sea.rg.net (147.28.0.4) 0.189 ms 0.306 ms 0.230 ms > 2 r1.sea.rg.net (147.28.0.5) 0.307 ms 0.259 ms 0.221 ms > 3 sea001bf00.iij.net (206.81.80.237) 0.336 ms 0.383 ms 0.348 ms > 4 tky008bf00.IIJ.net (206.132.169.110) 88.723 ms 94.377 ms 124.044 ms > 5 tky001bb10.IIJ.Net (58.138.80.18) 83.639 ms 83.701 ms 89.133 ms > > i am willing to hack the text. but i am just not sure that proximity is > not a good attribute. the longer the wire the greater the likelihood of > it being cut. > Following this line of reasoning (which is not unreasonable); if the router requires the cache to arrive at correctness, maybe the cache should be _inside_ the router. I'm not trying to be snarky, I know all the bootstrapping concerns have been hashed and re-hashed. To me, this funkiness seems like a holdover from that. Tony --f46d043749f9f30c3404e725f03c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 24, 2013 at 2:53 PM, Randy Bush <randy@psg.com> wrote:
hi wes,

> why does proximity matter? Is this just an extension of the trust
> domain and limited dependence on routing protocols? If so, I'd
> dispense with recommending "close" because it confuses the i= ssue and
> just keep the discussion about secondary dependencies and trust
> domains.

are you really saying that i should be comfortable configuring a seat= tle
router to use a cache in tokyo even though both are in my network and
there is a pretty direct hop?

Why shoul= dn't it just be "in the cloud" and you not care about where?<= br>
Oh, because RPKI-RTR isn't an application, it's infra= structure!
=A0
=A01 =A0r0.sea.rg.net (147.28.0.4) =A00.189 ms =A00.306 ms =A00.230 ms
=A02 =A0r1.sea.rg.net (147.28.0.5) =A00.307 ms =A00.259 ms =A00.221 ms
=A03 =A0sea001bf00.= iij.net (206.81= .80.237) =A00.336 ms =A00.383 ms =A00.348 ms
=A04 =A0tky008bf00.= IIJ.net (206.132.169.110) =A088.723 ms =A094.377 ms =A0124.044 ms
=A05 =A0tky001bb10.= IIJ.Net (58.138.80.18) =A083.639 ms =A083.701 ms =A089.133 ms

i am willing to hack the text. =A0but i am just not sure that proximity is<= br> not a good attribute. =A0the longer the wire the greater the likelihood of<= br> it being cut.

Following this line of reasoning (which= is not unreasonable); if the router requires the cache to arrive at correc= tness, maybe the cache should be _inside_ the router.

I'm not trying to be snarky, I know all the bootstrappin= g concerns have been hashed and re-hashed.
To me, this funkin= ess seems like a holdover from that.

Tony
=A0

--f46d043749f9f30c3404e725f03c-- From randy@psg.com Tue Sep 24 12:29:09 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2721F9703; Tue, 24 Sep 2013 12:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8SOvsf6HgVb; Tue, 24 Sep 2013 12:29:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id DDC4C11E80ED; Tue, 24 Sep 2013 12:29: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 1VOYIC-0007mS-9o; Tue, 24 Sep 2013 19:29:04 +0000 Date: Tue, 24 Sep 2013 09:29:03 -1000 Message-ID: From: Randy Bush To: Tony Tauber In-Reply-To: References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 19:29:09 -0000 > Following this line of reasoning (which is not unreasonable); if the > router requires the cache to arrive at correctness, maybe the cache > should be _inside_ the router. yep. but no chance of it fitting in existing routers, and routers today don't have the crypto oomph to validate (frequently). hence rpki-rtr protocol, rfc6810. randy From christopher.morrow@gmail.com Tue Sep 24 17:38:59 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E757111E8197; Tue, 24 Sep 2013 17:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2psLGIRUoyxG; Tue, 24 Sep 2013 17:38:59 -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 18DB911E80F1; Tue, 24 Sep 2013 17:38:57 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id es20so4258019lab.24 for ; Tue, 24 Sep 2013 17:38: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:content-transfer-encoding; bh=J8HUYS/c1WpiW9HyuuQXDgEAGIDz8N9jJGmsWkPR6XM=; b=B4eE82mqCfSAc2cNct0caHQdZmLFPz3Rx+2OTVtVGfSPPT5tW4bqLwp6PV5tzSkdwb 6ldFzy4lboqUoMpQ63tonjDRI69IYfn+DEViXoQi106PSIgzeeeSbB2JSc02md6/OTRJ uo7ADROqiDQz9W0e9km/qepyURePkmAlcxDEV1aDyUvXC+71AqcE4v6yqBCqcwsp95h3 4NHedNHVXI97QI8grNHqDVCcVCyfxzyzNp9i6vvIGVB9CoX7/fX4w/EYK8JViVHTC7H/ JWJBMvChkjZJ9ruAdIoH4zZREvHihuvW8GOAW4mYSdVila8UIQfPovgUFfhk487gAnYU piRA== MIME-Version: 1.0 X-Received: by 10.112.159.166 with SMTP id xd6mr26766549lbb.22.1380069536927; Tue, 24 Sep 2013 17:38:56 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.6.3 with HTTP; Tue, 24 Sep 2013 17:38:56 -0700 (PDT) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> Date: Tue, 24 Sep 2013 20:38:56 -0400 X-Google-Sender-Auth: o1xgeTPw6MIm4Hnf2IRhVUrRtuk Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 00:39:00 -0000 On Tue, Sep 24, 2013 at 12:26 PM, George, Wes w= rote: >> From: Randy Bush [mailto:randy@psg.com] >> i think the two paragraphs you would like to see improved are > [snip] >> i am not against further explanation, send text. but short text. :) > [WEG] just the first paragraph really, and as I'll note below - I'd love = to send text, but I don't understand one of the recommendations >> >> experiments have shown that latency between cache and router, and >> between caches in a cache dag, is not an appreciable issue. > [WEG] ok, so why is "close" important then? > >> i thought bootstrap reachability would be fairly obvious to an operator. >> but if simple routing and no dns dependency were not obvious to you, >> then a few words are indeed needed. or am i missing your point here? > [WEG] yes, completely obvious. Though the last two sentences of your sugg= ested text in the other email is a useful addition >> >> >> what is missing from the second paragraph? > [WEG] I'm actually happy with second para >> >> >> i am not sure it would be useful to go into the general issue of why >> caches should be proximal to the consumer as it is a rather well- >> explored area, from akamia and limelight to dns. but if you have a >> sentence or two that communicates this, send it over. > [WEG] Generally, I understand why closer is better for content caches (Ak= amai/llnw) and DNS, but not for RPKI caches. You're making a link between t= he two that I'm not following. Both of the [CLM] this is about the consumer of the data, right? (and convenience to the operator that hosts the cache). In the akamai/cdn example 'consumer' is 'cable/dsl/etc' user. "Close" is convenient-to-the-operator close to the 'cable/dsl/etc' user. Perhaps 'metro' is close enough for CDNs, balancing latency and backhaul requirements. In the RPKIcache example, 'consumer' is 'routers in your network'. 'Close' is 'close enough that bootstrapping isn't a problem', balanced with 'gosh, maybe I don't want to put one on top of each router! plus associated management headaches to deal with these new systems/appliances'. former benefit from proximity because it reduces latency and reduces unnecessary backhaul and potentially allows for a geographically customized service, resulting in improved user experience. If latency isn't a factor (at least in the average-sized propagation domain), and RPKI caches aren't particularly bandwidth intensive, why does proximity matter? Is this just an extension of the trust domain and limited dependence on routing protocols? If so, I'd dispense with recommending "close" because it confuses the issue and just keep the discussion about secondary dependencies and trust domains. [CLM] I guess one way is to say: "People should understand the dependencies and engineer appropriately" ... which you kind of asked to not say in the original comment. (or is the issue that the dependencies aren't clear?) > > Thanks > Wes George > > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight 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 t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From prvs=2980eabcac=sandra.murphy@parsons.com Wed Sep 25 08:42:58 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65C421F9EE1 for ; Wed, 25 Sep 2013 08:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOccy9tZI3x4 for ; Wed, 25 Sep 2013 08:42:54 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 07CBE21F9EE9 for ; Wed, 25 Sep 2013 08:42:53 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8PFeIkV018826 for ; Wed, 25 Sep 2013 10:42:53 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1f40qb9069-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Sep 2013 10:42:52 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8PFgpQF017318 for ; Wed, 25 Sep 2013 10:42:51 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8PFgpSD018495 for ; Wed, 25 Sep 2013 10:42:51 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Wed, 25 Sep 2013 11:42:51 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: I-D Action: draft-ymbk-lta-use-cases-00.txt Thread-Index: AQHOudRR1QnhkhqppUG/huwsfel1YJnWlu/a Date: Wed, 25 Sep 2013 15:42:50 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CEAF9B@CVA-MB002.centreville.ads.sparta.com> References: <20130925094722.29986.14516.idtracker@ietfa.amsl.com> In-Reply-To: <20130925094722.29986.14516.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-25_07:2013-09-25, 2013-09-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=141.992 compositescore=0.0511753745092519 urlsuspect_oldscore=0.511753745092519 suspectscore=0 recipient_domain_to_sender_totalscore=2241 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=8785 rbsscore=0.0511753745092519 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309250078 Subject: [sidr] FW: I-D Action: draft-ymbk-lta-use-cases-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:42:58 -0000 I just saw this announcement. Looks interesting.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= ________________________________________=0A= From: i-d-announce-bounces@ietf.org [i-d-announce-bounces@ietf.org] on beha= lf of internet-drafts@ietf.org [internet-drafts@ietf.org]=0A= Sent: Wednesday, September 25, 2013 5:47 AM=0A= To: i-d-announce@ietf.org=0A= Subject: I-D Action: draft-ymbk-lta-use-cases-00.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= =0A= =0A= Title : RPKI Local Trust Anchor Use Cases=0A= Author(s) : Randy Bush=0A= Filename : draft-ymbk-lta-use-cases-00.txt=0A= Pages : 5=0A= Date : 2013-09-25=0A= =0A= Abstract:=0A= There are a number of critical circumstances where a localized=0A= routing domain needs to augment or modify the Global RPKI. This=0A= document attempts to outline a few of them.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ymbk-lta-use-cases=0A= =0A= There's also a htmlized version available at:=0A= http://tools.ietf.org/html/draft-ymbk-lta-use-cases-00=0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= _______________________________________________=0A= I-D-Announce mailing list=0A= I-D-Announce@ietf.org=0A= https://www.ietf.org/mailman/listinfo/i-d-announce=0A= Internet-Draft directories: http://www.ietf.org/shadow.html=0A= or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A= From wesley.george@twcable.com Wed Sep 25 09:35:51 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F77F11E8114; Wed, 25 Sep 2013 09:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.276 X-Spam-Level: X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ5sLUlZhZTx; Wed, 25 Sep 2013 09:35:46 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 151BA21F9A45; Wed, 25 Sep 2013 09:35:41 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,978,1371096000"; d="scan'208";a="47220169" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Sep 2013 12:35:22 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 25 Sep 2013 12:35:40 -0400 From: "George, Wes" To: Randy Bush Date: Wed, 25 Sep 2013 12:35:39 -0400 Thread-Topic: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice Thread-Index: Ac65V1igrUR2Wr2URwaoVIacQcfnPQAnU1Yw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC4D@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:35:51 -0000 > From: Randy Bush [mailto:randy@psg.com] > > are you really saying that i should be comfortable configuring a seattle > router to use a cache in tokyo even though both are in my network and > there is a pretty direct hop? [WEG] not necessarily. But I'm also not saying that there would *never* be = a scenario where that makes sense. > > i am willing to hack the text. but i am just not sure that proximity is > not a good attribute. the longer the wire the greater the likelihood of > it being cut. [WEG] Proximity is generally a good attribute, but it's not free, so help t= he reader understand the tradeoffs so that they can justify spending money = to get better proximity. The draft hasn't provided a good explanation of ho= w proximity improves RPKI (or what problems a lack of it creates), nor how = to determine whether the level of proximity in a given design is "good enou= gh" to provide the perceived benefit. Your statement about long wires being cut is an argument for redundancy and= geographic diversity, not proximity. Of course an operator needs to take i= nto account the topology of their network when considering geographic diver= sity, but that's not necessarily going to translate to a need for proximity= . The draft says one should consider latency, but never explains how increase= d latency impacts RPKI, nor gives any guidance on how much might be too muc= h, especially when one considers that RPKI is an asymmetric system that cha= nges on mostly human time-scales (order of hours or days). Most places wher= e latency matters, it's a function of what RTT does to throughput or the pe= rception of speed for interaction (how long it takes between when I click a= nd when something happens). This isn't an interactive system. What is laten= cy-sensitive in this system on the subsecond scale such that it can be affe= cted by moving the cache closer? Even on systems configured for very freque= nt synchronization, are we expecting anything to change on that timescale? See my other response to CMorrow for questions around bootstrapping. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Wed Sep 25 09:38:53 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46F511E8121; Wed, 25 Sep 2013 09:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLwWukXrRz+D; Wed, 25 Sep 2013 09:38:48 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5721F997D; Wed, 25 Sep 2013 09:38:48 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,978,1371096000"; d="scan'208";a="140818927" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 25 Sep 2013 12:38:06 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 25 Sep 2013 12:38:46 -0400 From: "George, Wes" To: Christopher Morrow Date: Wed, 25 Sep 2013 12:38:45 -0400 Thread-Topic: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice Thread-Index: Ac65h5/CzWC7JQ5zQxOxogvcpo+5hAAbVixw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 16:38:53 -0000 > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] > > [CLM] > In the RPKIcache example, 'consumer' is 'routers in your network'. > 'Close' is 'close enough that bootstrapping isn't a problem', balanced > with 'gosh, maybe I don't want to put one on top of each router! plus > associated management headaches to deal with these new > systems/appliances'. [WEG] that's part of my issue - the only way that you get "close enough tha= t bootstrapping isn't a problem" is when the cache and router are directly = connected. Otherwise there *is* going to be some amount of time while the r= outer is coming up that it can't talk to its configured caches e.g. while i= t learns the route(s) to the cache(s). I think that supports a recommendati= on to put the caches in your IGP instead of BGP, so that you get faster con= vergence of those routes and therefore have access to the cache when BGP co= mes up and starts converging, rather than once BGP is partially converged. = But the draft doesn't say that. The question is, does the propagation/convergence delay for an IGP in an av= erage network (let's call it somewhere between subsecond and 5 seconds) mak= e a non-trival difference in RPKI's bootstrap behavior, especially since BG= P convergence is also dependent on IGP convergence? Can we make a clearer r= ecommendation of the performance envelope we're shooting for so that people= can design accordingly? I'm not sure I buy a general "faster(or closer) is= always better" recommendation - at some point, we hit diminishing returns,= given that this is mostly a human time-scale system. The document doesn't = provide clear guidance on how to balance that tradeoff. > > > [CLM] > I guess one way is to say: "People should understand the dependencies > and engineer appropriately" ... which you kind of asked to not say in > the original comment. (or is the issue that the dependencies aren't > clear?) [WEG] The issue is that the dependencies aren't clear. I'm not expecting th= e text to be too prescriptive here, because all networks are different, but= I need enough technical discussion to properly "understand the dependencie= s and engineer accordingly". This is an operational considerations document= , so it needs to tell operators what breaks if they don't do it as recommen= ded. If this is about bootstrapping, then we need to be clearer about the r= elationship between bootstrapping and network convergence (since recommendi= ng that the cache is directly connected to the router is impractical) and h= ow it impacts RPKI cache-router communication and performance. If it's abou= t reducing latency via proximity, then we need to explain how much latency = is too much latency and why. If it's about proper geographic diversity with= in a network's topology, then we need to say that. If we don't actually kno= w if it makes a difference, and so are defaulting to recommendations that m= ost folks agree are generally a good idea, we should say that. But right no= w we're assuming too much, IMO. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Wed Sep 25 19:22:58 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAF021F90E5; Wed, 25 Sep 2013 19:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls7BxE2xg6B9; Wed, 25 Sep 2013 19:22:58 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4C29C21F8426; Wed, 25 Sep 2013 19:22:57 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eo20so413600lab.17 for ; Wed, 25 Sep 2013 19:22:54 -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=sVgEtb67suRab6lUEln1au67A9ihlNHziG+fvJ1XpA0=; b=DUua6VtA+5KkYU7iHZlv9762j0AwnAtKA9kT+y3rq8PTin7K3DrwUvKzC6FyVrj9LS 0MmU9YcpZJdf555LJSqWNY5t5dVGXYVQOZNpT7i1cTAAPOwL3KrWVoKIthmNrwE8GFls d+9ec5VJas8UmkGktKkWwbE9eynC+YpO6txHmdfYRdqut4wgzpUN9WNYXS7BT0sAYa2D tWQSiUDhWF2yWiWjO/dqJYNqmbJ2qhMqrdYYp0G/lD8kNdx1pQvU3mCVKegElq6tVxi8 0zI9Bnd4AV6PvmCakbHO8joPRervtA89KMwCsUWkVxlnXQ92dAb6yZuR1j7zCLCXokI6 THgw== MIME-Version: 1.0 X-Received: by 10.152.116.7 with SMTP id js7mr32507116lab.11.1380162172948; Wed, 25 Sep 2013 19:22:52 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.6.3 with HTTP; Wed, 25 Sep 2013 19:22:52 -0700 (PDT) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> Date: Wed, 25 Sep 2013 22:22:52 -0400 X-Google-Sender-Auth: uvM4cFJaWFjY8FlWXi8FNQ1mNO0 Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 02:22:58 -0000 On Wed, Sep 25, 2013 at 12:38 PM, George, Wes wrote: >> From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] >> >> [CLM] >> In the RPKIcache example, 'consumer' is 'routers in your network'. >> 'Close' is 'close enough that bootstrapping isn't a problem', balanced >> with 'gosh, maybe I don't want to put one on top of each router! plus >> associated management headaches to deal with these new >> systems/appliances'. > > [WEG] that's part of my issue - the only way that you get "close enough that > bootstrapping isn't a problem" is when the cache and router are directly there's some baseline that's acceptable, you intimate that IGP comes up before EGP below. that makes some sense, and thus maybe the target is 'in your igp, close enough that fiber failures won't be a problem' then? > connected. Otherwise there *is* going to be some amount of time while > the router is coming up that it can't talk to its configured caches e.g. while but the data in the cache only REALLY matters for bgp validation... so your IGP clue below isn't unreasonable. > it learns the route(s) to the cache(s). I think that supports a recommendation > to put the caches in your IGP instead of BGP, so that you get faster I actually didn't note a [ie]GP recommendation in the doc. > convergence of those routes and therefore have access to the cache > when BGP comes up and starts converging, rather than once BGP is > partially converged. But the draft doesn't say that. ok > The question is, does the propagation/convergence delay for an IGP in an > average network (let's call it somewhere between subsecond and 5 seconds) > make a non-trival difference in RPKI's bootstrap behavior, especially since > BGP convergence is also dependent on IGP convergence? Can we make a > clearer recommendation of the performance envelope we're shooting for so > that people can design accordingly? I'm not sure I buy a general "faster(or > closer) is always better" recommendation - at some point, we hit diminishing > returns, given that this is mostly a human time-scale system. The document > doesn't provide clear guidance on how to balance that tradeoff. i think a bunch of this really also depends on the operator deploying though... 'its hard to get server people to do X for me' or 'gosh, these appliances can be managed by network-operations! and they are cheap-ish' or 'gosh, we don't have 1gbps ports anymore in general, crap...' I do think the original intent was to not dictate: "Must be 5ms from the router, or else!!" and rely upon the operator to do the tradeoff you just made above. Each network is different in it's expectations from the infra, and each has different igp/egp designs as well as fiber plant restrictions. I think it's going to be rough going making a recommendation much more than: 1) make sure the cache is available before BGP starts to converge for a device and I actually can't come up with something else that's super helpful :( even the above might be 'too much advice', if your plan is to accept all routes and simply de-pref until validation might happen then re-evaluate as you can. >> [CLM] >> I guess one way is to say: "People should understand the dependencies >> and engineer appropriately" ... which you kind of asked to not say in >> the original comment. (or is the issue that the dependencies aren't >> clear?) > > [WEG] The issue is that the dependencies aren't clear. I'm not expecting the > text to be too prescriptive here, because all networks are different, but I need > enough technical discussion to properly "understand the dependencies and > engineer accordingly". This is an operational considerations document, so it > needs to tell operators what breaks if they don't do it as recommended. If this ok... > is about bootstrapping, then we need to be clearer about the relationship > between bootstrapping and network convergence (since recommending > that the cache is directly connected to the router is impractical) and how > it impacts RPKI cache-router communication and performance. If it's about > reducing latency via proximity, then we need to explain how much latency is > too much latency and why. If it's about proper geographic diversity within a > network's topology, then we need to say that. If we don't actually know if it > makes a difference, and so are defaulting to recommendations that most folks > agree are generally a good idea, we should say that. But right now we're > assuming too much, IMO. ok, the current text is: " As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. 'Close' is, of course, complex. One should consider trust boundaries, routing bootstrap reachability, latency, etc" Maybe something like: " As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close enough to routers that require these data and services such that failures in local device routing domain do not impact cache availability. One should consider trust boundaries, routing bootstrap reachability, latency, etc" -chris (content warning removed.. since it didn't come from TWC, and my words are not as restricted) From randy@psg.com Wed Sep 25 19:45:48 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2464A11E8136; Wed, 25 Sep 2013 19:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtgKfhwXnUgC; Wed, 25 Sep 2013 19:45:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 6368611E8132; Wed, 25 Sep 2013 19:45:37 -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 1VP1Zu-0007W2-H8; Thu, 26 Sep 2013 02:45:18 +0000 Date: Wed, 25 Sep 2013 16:45:17 -1000 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 02:45:53 -0000 >> [WEG] that's part of my issue - the only way that you get "close >> enough that bootstrapping isn't a problem" is when the cache and >> router are directly > there's some baseline that's acceptable, you intimate that IGP comes > up before EGP below. that makes some sense, and thus maybe the target > is 'in your igp, close enough that fiber failures won't be a problem' > then? but do we want to go to that level of detail? it's just nit-pick fodder >> connected. Otherwise there *is* going to be some amount of time while >> the router is coming up that it can't talk to its configured caches >> e.g. while > but the data in the cache only REALLY matters for bgp validation... so > your IGP clue below isn't unreasonable. and the folk who smoked the "use ibgp for your igp" dope at&t handed out to customers? i really don't think we want to get into the nitty gritty of how folk should configure their networks. way to many styles, variables, corner cases, ... explain the underlying physics and what's prudent and let the network's engineers design their network. but yes, 'close' may be a bit so loose, and seems to be major nit-picking fodder. >> it learns the route(s) to the cache(s). I think that supports a >> recommendation to put the caches in your IGP instead of BGP, so that >> you get faster > I actually didn't note a [ie]GP recommendation in the doc. not because i ran out of ink (credit to nw) >> convergence of those routes and therefore have access to the cache >> when BGP comes up and starts converging, rather than once BGP is >> partially converged. But the draft doesn't say that. > ok "but i only have that one router. and if bgp does not come up, then the cache can not load up." do you *really* want to go down these myriad twisty passages? > i think a bunch of this really also depends on the operator deploying > though... 'its hard to get server people to do X for me' or 'gosh, > these appliances can be managed by network-operations! and they are > cheap-ish' or 'gosh, we don't have 1gbps ports anymore in general, > crap...' yes, makes one want to go back to running a small network. > I do think the original intent was to not dictate: "Must be 5ms from > the router, or else!!" and rely upon the operator to do the tradeoff > you just made above. Each network is different in it's expectations > from the infra, and each has different igp/egp designs as well as > fiber plant restrictions. I think it's going to be rough going making > a recommendation much more than: i agree up to here > 1) make sure the cache is available before BGP starts to converge > for a device you can't. cache may need routing to fill its little tummy. > and I actually can't come up with something else that's super helpful which is why i stopped where i did. though i think one could amplify a bit on 'close'. your paragraph is not bad > "As RPKI-based origin validation relies on the availability of RPKI > data, operators SHOULD locate caches close enough to routers that > require these data and services such that failures in local device > routing domain do not impact cache availability. One should consider > trust boundaries, routing bootstrap reachability, latency, etc" i would modify slightly (e.g. s/do not impact/are unlikely to impact/) but can stitch it in. and latency may be a red herring. but i eat herring, so wth. randy From randy@psg.com Wed Sep 25 20:29:39 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0764011E80FF; Wed, 25 Sep 2013 20:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE--xy3vp9nh; Wed, 25 Sep 2013 20:29:38 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4878911E80FA; Wed, 25 Sep 2013 20:29: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 1VP2Gk-0007cI-C9; Thu, 26 Sep 2013 03:29:34 +0000 Date: Wed, 25 Sep 2013 17:29:33 -1000 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 03:29:39 -0000 how about To relieve routers of the load of performing certificate validation, cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], does not provide object-based security to the router. I.e. the router may not validate the data cryptographically from a well-known trust anchor. The router trusts the cache to provide correct data and relies on transport based security for the data received from the cache. Therefore the authenticity and integrity of the data from the cache should be well protected, see Section 7 of [RFC6810]. As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate RPKI caches close to routers that require these data and services in order to minimize the impact of likely failures in local routing, intermediate devices, long circuits, etc. One also should consider trust boundaries, routing bootstrap reachability, etc. E.g. a router should bootstrap from a chache which is reachable with minimal reliance on other infrastructure such as DNS or routing protocols. randy From wesley.george@twcable.com Thu Sep 26 06:43:41 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53F821F9EB0; Thu, 26 Sep 2013 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JerHTQSeZUCo; Thu, 26 Sep 2013 06:43:36 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD521F9E54; Thu, 26 Sep 2013 06:43:35 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,985,1371096000"; d="scan'208";a="141258661" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 26 Sep 2013 09:42:49 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 26 Sep 2013 09:43:33 -0400 From: "George, Wes" To: Randy Bush , Christopher Morrow Date: Thu, 26 Sep 2013 09:43:31 -0400 Thread-Topic: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice Thread-Index: Ac66aLeNkcAI8H3yR6KuuLA6za1L+AATngOg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043AC5C439@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 13:43:41 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Randy Bush > > how about > > To relieve routers of the load of performing certificate validation, > cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], > does not provide object-based security to the router. I.e. the > router may not validate the data cryptographically from a well-known > trust anchor. The router trusts the cache to provide correct data > and relies on transport based security for the data received from the > cache. Therefore the authenticity and integrity of the data from the > cache should be well protected, see Section 7 of [RFC6810]. [WEG] fine, though it's unclear if "may" in the above is intended to be nor= mative. I think it's not, but just pointing it out. > > As RPKI-based origin validation relies on the availability of RPKI > data, operators SHOULD locate RPKI caches close to routers that > require these data and services in order to minimize the impact of > likely failures in local routing, intermediate devices, long > circuits, etc. One also should consider trust boundaries, routing > bootstrap reachability, etc. E.g. a router should bootstrap from a > chache which is reachable with minimal reliance on other > infrastructure such as DNS or routing protocols. [WEG] this is better, but I still maintain that in the first sentence, "clo= se" isn't actually the goal we're trying for. How about: ...operators SHOULD consider the relationship between the routers that requ= ire these data and services and the location of the RPKI caches in the netw= ork's topology. Caches SHOULD be located so that they can take advantage of= geographic redundancy and minimize the impact of likely failures in local = routing, .... And add this at the end to explain why reliance on routing protocols @ boot= strap is risky: ...or routing protocols. Reliance on routing protocol convergence to reach = a cache at bootstrap time can result in significant increases in total conv= ergence time as the router converges partially, synchronizes with the RPKI = cache, and then must re-converge based on the data from the cache. Thanks Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Thu Sep 26 11:29:19 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379F921F8FF8; Thu, 26 Sep 2013 11:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7k2Z0bxVJRw; Thu, 26 Sep 2013 11:29:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id B731021F8616; Thu, 26 Sep 2013 11:29:04 -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 1VPGIs-0002ve-9f; Thu, 26 Sep 2013 18:28:42 +0000 Date: Thu, 26 Sep 2013 08:28:40 -1000 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043AC5C439@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5C439@PRVPEXVS15.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 18:29:19 -0000 >> To relieve routers of the load of performing certificate validation, >> cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], >> does not provide object-based security to the router. I.e. the >> router may not validate the data cryptographically from a well-known >> trust anchor. The router trusts the cache to provide correct data >> and relies on transport based security for the data received from the >> cache. Therefore the authenticity and integrity of the data from the >> cache should be well protected, see Section 7 of [RFC6810]. > [WEG] fine, though it's unclear if "may" in the above is intended to > be normative. I think it's not, but just pointing it out. actually, it was a grammar error which i caught right after posting. in my edit buffer, it is 'can' as in ablility not 'may' as in permission. >> As RPKI-based origin validation relies on the availability of RPKI >> data, operators SHOULD locate RPKI caches close to routers that >> require these data and services in order to minimize the impact of >> likely failures in local routing, intermediate devices, long >> circuits, etc. One also should consider trust boundaries, routing >> bootstrap reachability, etc. E.g. a router should bootstrap from a >> chache which is reachable with minimal reliance on other >> infrastructure such as DNS or routing protocols. > [WEG] this is better, but I still maintain that in the first sentence, > "close" isn't actually the goal we're trying for. for some definitions of 'we' :) > How about: > ...operators SHOULD consider the relationship between the routers that > require these data and services and the location of the RPKI caches in > the network's topology. Caches SHOULD be located so that they can take > advantage of geographic redundancy and minimize the impact of likely > failures in local routing, .... i don't even know what geographic redundancy is, alternate earths? if you mean redundant network topology, i think it is more than that. i really think physical line length matters. as i said, the longer the circuit the more likely a boat anchor will whack it. hence close. > And add this at the end to explain why reliance on routing protocols @ > bootstrap is risky: > > ...or routing protocols. Reliance on routing protocol convergence to > reach a cache at bootstrap time can result in significant increases in > total convergence time as the router converges partially, synchronizes > with the RPKI cache, and then must re-converge based on the data from > the cache. i think i understand what you want made more explicit. today's try To relieve routers of the load of performing certificate validation, cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], does not provide object-based security to the router. I.e. the router can not validate the data cryptographically from a well-known trust anchor. The router trusts the cache to provide correct data and relies on transport based security for the data received from the cache. Therefore the authenticity and integrity of the data from the cache should be well protected, see Section 7 of [RFC6810]. As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate RPKI caches close to routers that require these data and services in order to minimize the impact of likely failures in local routing, intermediate devices, long circuits, etc. One should also consider trust boundaries, routing bootstrap reachability, etc. E.g. a router should bootstrap from a chache which is reachable with minimal reliance on other infrastructure such as DNS or routing protocols. For example, if a router needs its BGP and/or IGP to converge for the router to reach a cache, once a cache is reachable, the router will then have to reevaluate prefixes already learned via BGP. Such configurations should be avoided if possible. randy From sidr-secretary@samweiler.com Thu Sep 26 14:11:53 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C931121E80B5 for ; Thu, 26 Sep 2013 14:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNCEiuO3yd3C for ; Thu, 26 Sep 2013 14:11:48 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id D01FF21F9F7F for ; Thu, 26 Sep 2013 14:11:45 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 05D2046B2D for ; Thu, 26 Sep 2013 17:11:45 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.7/8.14.7) with ESMTP id r8QLBiiS002158 for ; Thu, 26 Sep 2013 17:11:44 -0400 (EDT) (envelope-from sidr-secretary@samweiler.com) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.7/8.14.7/Submit) with ESMTP id r8QLBiEV002155 for ; Thu, 26 Sep 2013 17:11:44 -0400 (EDT) (envelope-from sidr-secretary@samweiler.com) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 26 Sep 2013 17:11:44 -0400 (EDT) From: SIDR Secretary X-X-Sender: weiler@fledge.watson.org To: sidr@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 26 Sep 2013 17:11:44 -0400 (EDT) Subject: [sidr] Draft status page on wiki X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIDR Secretary List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 21:11:53 -0000 As WG secretary, I'm trying to maintain a todo list for the WG (or, perhaps more correctly, for its chairs). As part of that effort, I have added to the wiki a list of current document status, as I see things. http://trac.tools.ietf.org/wg/sidr/trac/wiki/ChairActions Recognizing that many of the "next steps" are "WG discussion needed", I have suggested that the chairs prioritize those discussions, which is loosely reflected in the parenthetical comments of "first priority", "lower priority" and the like. That's not to say that discussions of other docs would be unwelcome; it's just a reminder to the chairs of which discussions they may want to try to prod along first. 1) Please review the list for accuracy. If you think a doc is missing or should show a different state, please email sidr-secretary@samweiler.com rather than editing the wiki. 2) This is a wiki, anyone with a tools login can edit it, and I welcome you to make clean-up and formatting changes. I would prefer that you email me substantive changes rather than making them yourselves. 3) If you have suggestions for how to better format this data (tables that one can sort by various columns?), I welcome those suggestions. Feel free to demonstrate your suggestions by changing the wiki or adding a new page with the new formatting. -- Sam From wesley.george@twcable.com Thu Sep 26 14:19:55 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79C521F8F4A; Thu, 26 Sep 2013 14:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijhvJPvUQGkr; Thu, 26 Sep 2013 14:19:43 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id D63E421F8CCB; Thu, 26 Sep 2013 14:19:42 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.90,988,1371096000"; d="scan'208";a="40675862" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 26 Sep 2013 17:19:00 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 26 Sep 2013 17:19:41 -0400 From: "George, Wes" To: Randy Bush Date: Thu, 26 Sep 2013 17:19:39 -0400 Thread-Topic: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice Thread-Index: Ac665pubwGCMokKLTCyGSsKB9kFqxwAENXRg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043AD0D70E@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5C439@PRVPEXVS15.corp.twcable.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 21:19:56 -0000 > From: Randy Bush [mailto:randy@psg.com] > > i don't even know what geographic redundancy is, alternate earths? [WEG] nah, the latency is too high until we sort out IP over Quantum Entang= lement. ;-) Geographic redundancy in the context of things that live on ser= vers is that it exists on servers in more than one physical location (e.g. = Datacenter East and Datacenter West) so that there isn't a single point of = failure. In this case, that'd probably be in the form of two caches backing= each other up (router configured to use both). if > you mean redundant network topology, i think it is more than that. i > really think physical line length matters. as i said, the longer the > circuit the more likely a boat anchor will whack it. hence close. [WEG] yes, but ultimately that's dependent on your network topology. If "cl= ose" is the only way to mitigate that (vs having a truly redundant backup t= hat doesn't share any topology in its path), then sure, that's what you do.= But I don't think it directly translates to "should be close". We clearly = disagree, but I'm not going to belabor the point any further. > > > i think i understand what you want made more explicit. today's try > > To relieve routers of the load of performing certificate validation, > cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], > does not provide object-based security to the router. I.e. the > router can not validate the data cryptographically from a well-known > trust anchor. The router trusts the cache to provide correct data > and relies on transport based security for the data received from the > cache. Therefore the authenticity and integrity of the data from the > cache should be well protected, see Section 7 of [RFC6810]. > > As RPKI-based origin validation relies on the availability of RPKI > data, operators SHOULD locate RPKI caches close to routers that > require these data and services in order to minimize the impact of > likely failures in local routing, intermediate devices, long > circuits, etc. One should also consider trust boundaries, routing > bootstrap reachability, etc. E.g. a router should bootstrap from a > chache which is reachable with minimal reliance on other > infrastructure such as DNS or routing protocols. > > For example, if a router needs its BGP and/or IGP to converge for the > router to reach a cache, once a cache is reachable, the router will > then have to reevaluate prefixes already learned via BGP. Such > configurations should be avoided if possible. [WEG] close enough, ship it. Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se 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 dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Fri Sep 27 06:16:42 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F29511E80D3; Fri, 27 Sep 2013 06:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSCCzpZoMSyB; Fri, 27 Sep 2013 06:16:42 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8182721F9B8D; Fri, 27 Sep 2013 06:16:41 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z5so2188524lbh.23 for ; Fri, 27 Sep 2013 06:16: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=oudJ/eSRWDlpVIWsweqrXQwvNK0+AcunUib3GbIFJFM=; b=pzY+HFArrpQmdR/IehpzFY1N/UkWLSEO8fDhiWXPt96W7XegF76qqASUZVT8kj1xfX bBaRNqdrfcWiBYENARczw1z+lmkXpOc9y2c2d6U10ep0ZsN7X0XlGpa98dWJcsLOrsEb XLLYBd/m8P5qhNSurXeUEitCYkdF02F4ONRdiFLPl2G9UXiIEGf4Hxa9Xa0lkVqL6Jg4 mmHMEzxRT9NrSl6UAQfUYA2SJY9SQB4H+2dYoyCnUH2S8GmVSjFrFTx9ZXAN4FCu/sSX Y1fjn3oK9sDvtg0kXD9eX0oDqidgbCUuwgfrtZW3Zw0mnyAVbNo+XZwLP/sewaPC9kca zH1w== MIME-Version: 1.0 X-Received: by 10.112.159.166 with SMTP id xd6mr8701765lbb.22.1380287800458; Fri, 27 Sep 2013 06:16:40 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.6.3 with HTTP; Fri, 27 Sep 2013 06:16:40 -0700 (PDT) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043AD0D70E@PRVPEXVS15.corp.twcable.com> References: <20130917145223.16906.84693.idtracker@ietfa.amsl.com> <2671C6CDFBB59E47B64C10B3E0BD5923043A9B61A6@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AB69649@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5BC5F@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AC5C439@PRVPEXVS15.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD5923043AD0D70E@PRVPEXVS15.corp.twcable.com> Date: Fri, 27 Sep 2013 09:16:40 -0400 X-Google-Sender-Auth: J5Xyi58cATjPfbc35ZWRcGWdXSU Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Disgust , sidr wg list Subject: Re: [sidr] Last Call: (RPKI-Based Origin Validation Operation) to Best Current Practice X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:16:42 -0000 On Thu, Sep 26, 2013 at 5:19 PM, George, Wes wrote: > > [WEG] close enough, ship it. hurray! :) (I'm also ok with the last edit buffer fun) thank wes and randy for a fun discussion. -chris From prvs=2982ee7a37=sandra.murphy@parsons.com Fri Sep 27 12:36:28 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695EF21F9F19 for ; Fri, 27 Sep 2013 12:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8w7dEGMk0GL for ; Fri, 27 Sep 2013 12:36:16 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id C146A21F9FD5 for ; Fri, 27 Sep 2013 12:36:10 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8RJZPbs009577; Fri, 27 Sep 2013 14:36:03 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1f5cp69m0c-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 27 Sep 2013 14:36:03 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8RJa1hr000709; Fri, 27 Sep 2013 14:36:01 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8RJZsBR000684; Fri, 27 Sep 2013 14:35:59 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Fri, 27 Sep 2013 15:35:54 -0400 From: "Murphy, Sandra" To: "draft-ietf-sidr-multiple-publication-points@tools.ietf.org" Thread-Topic: possible interim meeting for draft-ietf-sidr-multiple-publication-points Thread-Index: Ac67uMeASnh6Mvp5TAeOyyM1se3xkg== Date: Fri, 27 Sep 2013 19:35:53 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB6AB@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-27_07:2013-09-27, 2013-09-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.0395041412045292 urlsuspect_oldscore=0.0395041412045292 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0395041412045292 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309270115 Cc: "sidr-secretary@samweiler.com" , "sidr@ietf.org" Subject: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:36:29 -0000 Various pokes to the list to discuss this haven't been working.=0A= =0A= Chris and I are considering holding a virtual meeting - telecon only - for = a short 1-2 hour duration - for discussion of this draft only.=0A= =0A= Is that acceptable to you? This requires a two week advance announcement -= are there any times about two week from now that you would or would not be= available? Is a particular time of the day good for you?=0A= =0A= Just thinking here, so comment.=0A= =0A= --Sandy= From christopher.morrow@gmail.com Fri Sep 27 12:44:41 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9D521F9A31 for ; Fri, 27 Sep 2013 12:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yysibR103qrC for ; Fri, 27 Sep 2013 12:44:38 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id EA76B21F9048 for ; Fri, 27 Sep 2013 12:44:37 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so4893598ieb.23 for ; Fri, 27 Sep 2013 12:44:37 -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=RMkuTdoTKebDCxywCopSRA9HXpxHzEc+8z5IiONrBrQ=; b=Iy3FwAHVqhBoQY4gaJaUNmYob+G3ZxleQ4d1q6bX3ptEISg0FE81cDJ/6zdqKPprSu q40V6v0FQp6biLpidMGf0FOhW1/IXYxpkP3u5OLgWq55VbCxG/t0KFOkxb3DQ1RZsKps kf7FyxQic+vQKWiDxVUX2Vddb5K+s4sKPPEHCTIc9yAz6kPsL/5x//HVJJ4xpNI/SzcX Ni65t8IZ62lf1AyJlqtRoDOMKEKcOzdOy9r1tyvBT5uRAweQu08jJSdWnJMWS4mwteVR sRZ6TIKOSZ2BpFamAT8NWVFCo6HeNDnraZuz73CM79e/ThYGVAMg2nXxIQuvKCxHuNSv 97Zg== MIME-Version: 1.0 X-Received: by 10.50.141.133 with SMTP id ro5mr3732470igb.35.1380311077429; Fri, 27 Sep 2013 12:44:37 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.64.245.173 with HTTP; Fri, 27 Sep 2013 12:44:37 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F674A5C8EC@CVA-MB001.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6749E7607@CVA-MB002.centreville.ads.sparta.com> <973B0890-766F-4023-8F35-876936E470C6@apnic.net> <24B20D14B2CD29478C8D5D6E9CBB29F674A5C8EC@CVA-MB001.centreville.ads.sparta.com> Date: Fri, 27 Sep 2013 15:44:37 -0400 X-Google-Sender-Auth: dn6_zUTOeTqoSpG5BoG4m9m76Jc Message-ID: From: Christopher Morrow To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:44:41 -0000 On Wed, Sep 18, 2013 at 3:16 PM, Murphy, Sandra wrote: > Looks like this is the final word. > > Consensus of the wglc is that the document is good to go, with revisions. > > Draft authors, could you please submit a new version with the wording sug= gested below? > draft-authors: "Y U NO SEND DRAFT UPDATE?" :) > As an update to RFC6487, this document broadens the class of certificates= that conform to the RPKI profile by explicitly including within the profil= e those certificates that contain a policy qualifier as described here. A r= elying party that performs a strict validation based on RFC6487 and fails t= o support the updates described in this document, would incorrectly invalid= ate RPKI objects that implement the changes in Section 2. > > Note this includes one nit change of "implements" to "implement". > > Please also consider the nits mentioned in the message: > http://www.ietf.org/mail-archive/web/sidr/current/msg06124.html > > --Sandy, speaking as wg co-chair > > > ________________________________________ > From: Roque Gagliano (rogaglia) [rogaglia@cisco.com] > Sent: Monday, August 26, 2013 4:18 AM > To: Geoff Huston; Murphy, Sandra > Cc: Andy Newton; sidr@ietf.org list > Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00 > > Hi Geoff/Sandy, > > Agree that we can void the mention on the current status of the known RP.= As the due-diligence was done, I am fine. > > I think your proposed text from Geoff goes well with the intention of th= e original text (at least with the first sentence).It is just a matter of h= ow explicit we want to be in the consequences of not implementing the chang= es on this document for RP parties. We and go with only his sentence or add= ing the two sentences: > > "As an update to RFC6487, this document broadens the class of certificate= s that conform to the RPKI profile by explicitly including within the profi= le those certificates that contain a policy qualifier as described here. A = relying party that performs a strict validation based on RFC6487 and fails = to support the updates described in this document, would incorrectly invali= date RPKI objects that implements the changes in Section 2." > > Roque > > > > On Aug 24, 2013, at 12:03 AM, Geoff Huston wrote: > >> Wouldn't it be better to note that: As an update to RFC6487, this docume= nt broadens the class of certificates that conform to the RPKI profile by e= xplicitly including within the profile those certificates that contain a po= licy qualifier as described here. >> >> Geoff >> >> >> >> On 24/08/2013, at 4:09 AM, "Murphy, Sandra" = wrote: >> >>> Speaking as working group chair: >>> >>> I can't be certain that this indicates a promise to modify the draft or= not. Roque, Andy, could you comment? >>> >>> If so, a new version is needed and I'll say so on the list. >>> If not, I'll have to ask for resolution on list. >>> >>> Speaking as regular ol' member (and a bit as wg chair, as I'm not clear= about the intent of the new text): >>> >>> I don't think this text hurts anything, but I am puzzled about the inte= nt. If "all known" implementations comply, why mention the problem? OTOH,= it might serve to forestall AD/IESG questions. >>> >>> So I agree with Andy's observation, though I'd say a heading "Backward = Compatibility Considerations" rather than "Interoperability Considerations"= suits the situation better. >>> >>> (Apologies - searching for the thread, I found these comments stuck in = my draft folder from 17 July.) >>> >>> --Sandy >>> >>> P.S. >>> >>> "strick"->"strict" >>> "RPKI signed objects" -> "RPKI objects" >>> "implements"->"include" or "contain" or... >>> "RP"-> relying party (or you'll have to define the acronym somewhere) >>> Not sure what ""as in IDR" means. >>> >>> ________________________________________ >>> From: Andy Newton [andy@arin.net] >>> Sent: Tuesday, July 16, 2013 9:49 AM >>> To: Roque Gagliano (rogaglia) >>> Cc: Murphy, Sandra; sidr@ietf.org >>> Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00 >>> >>> This sounds fine to me, though it is really an interoperability >>> considerations section thingy. The IETF does those now, right? :) >>> >>> -andy >>> >>> On 7/16/13 4:55 AM, "Roque Gagliano (rogaglia)" wr= ote: >>> >>>> Thanks Andy. >>>> >>>> Do you think we need to add something in the security section about th= e >>>> transition? >>>> >>>> Something like: >>>> >>>> "A RP that performs a strick validation based on RFC6487 and fails to >>>> support the updates described in this document, would incorrectly >>>> invalidate RPKI signed objects that implements the changes in Section = 2. >>>> At the time of this writing, all known RP software suites (you can >>>> mention them as in IDR) were tested and supported the updates on this >>>> document" >>>> >>>> Roque >>>> >>>> On Jul 15, 2013, at 7:07 PM, Andy Newton wrote: >>>> >>>>> On 7/15/13 10:22 AM, "Roque Gagliano (rogaglia)" >>>>> wrote: >>>>> >>>>>> Before sending my support to advance to the IESG, I wanted to ask th= e >>>>>> author if they have tested the effects of this change on existing RP >>>>>> tools. Do they really set the certificate as invalid? >>>>> >>>>> Yes, we have tested against the three RP suites. One did not require = a >>>>> change while the other two required simple one line changes. Current >>>>> releases of all three now accommodate it. >>>>> >>>>> -andy >>>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 randy@psg.com Fri Sep 27 13:02:15 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAAE11E8162 for ; Fri, 27 Sep 2013 13:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p26D3Yxk9rdP for ; Fri, 27 Sep 2013 13:02:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 1346811E814D for ; Fri, 27 Sep 2013 13:02:13 -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 1VPeEu-0001Gp-1m; Fri, 27 Sep 2013 20:02:12 +0000 Date: Fri, 27 Sep 2013 10:02:11 -1000 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB6AB@CVA-MB002.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB6AB@CVA-MB002.centreville.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:02:15 -0000 imiho, mailing list discussion has raised issues that are not really going to benefit from a voice call or f2f. the authors need to think a bit and propose something which addresses some non-trivial issues with the current draft. randy From rogaglia@cisco.com Fri Sep 27 13:26:52 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0C311E80E8 for ; Fri, 27 Sep 2013 13:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT-W0Zz4H5-c for ; Fri, 27 Sep 2013 13:26:47 -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 6A29221F92B2 for ; Fri, 27 Sep 2013 13:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7173; q=dns/txt; s=iport; t=1380313607; x=1381523207; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=riINzpYgebX+u9MeSEhT2HfuZt/8tE+QmIV6yEaKXl8=; b=kcyPvp+Ji0hG5KScOkdz6cAHKf7odMKlr9zsb+FDXmmHmYqY6PyrGlib taFPKMhoJG29FBas21SR/dMUk6jW1t/Y6qkinD3veMAK/7CK95so7gtTy hDViSo6QpFNud1zRsPcRbRst1h5frlRcgDU8W0QXE5fgVTG39f020gHo7 Y=; X-Files: smime.p7s : 4459 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKvpRVKtJV2c/2dsb2JhbABbgwc4UsBOgSEWdIIlAQEBAwEBAQFrCwULAgEIIiQCJQslAgQOBQgGh3IGDLoLBI8gMQeDH4EBA5AngTCYIIFmgT6CKg X-IronPort-AV: E=Sophos;i="4.90,995,1371081600"; d="p7s'?scan'208";a="265279963" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 27 Sep 2013 20:26:43 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8RKQh8u024593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 20:26:43 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.92]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 15:26:42 -0500 From: "Roque Gagliano (rogaglia)" To: Sandra Murphy Thread-Topic: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points Thread-Index: AQHOu7/g2Dlg0uuK3E2Y7pxDlMAmxQ== Date: Fri, 27 Sep 2013 20:26:41 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB6AB@CVA-MB002.centreville.ads.sparta.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.147] Content-Type: multipart/signed; boundary="Apple-Mail=_085E6F09-15AB-4523-9894-75710703C19D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:26:52 -0000 --Apple-Mail=_085E6F09-15AB-4523-9894-75710703C19D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sandy, I agree with Randy that (we) the authors are in fault here. I will work with my co-authors to bring a proposal to the group on how = to move forward with the document.=20 Roque On Sep 27, 2013, at 10:02 PM, Randy Bush wrote: > imiho, mailing list discussion has raised issues that are not really > going to benefit from a voice call or f2f. the authors need to think > a bit and propose something which addresses some non-trivial issues > with the current draft. >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_085E6F09-15AB-4523-9894-75710703C19D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINSTCCBkIw ggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIxMDgzMTIzNTk1OVowgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQD Ey5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn/R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEi VzAhJZCao/SsKsaIF4ZhchN2LuwDyyebjyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+Dey xtmSSq5937hEH5u6P4wG/tgjT0hRI2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/ xhR7DtryBeTTgwKmxWlwtKnkVunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28 ODC7iCbDZ2ZmtLR3+cChxw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQAB o4ICRDCCAkAwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBS MCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpo dHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAY BgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXECl4aATCB 8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZl cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWdu IENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItb dVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaPwdqbiPKzbE0fWC+6AVFddMFG6MO4 e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKMYJsrnGVJlMSiOCRIpVylUEto6WIip5Po mSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBiTe/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP9 5WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26tlcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4 OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXi dE0HbYQwggb/MIIF56ADAgECAhAYf+/XztcT+E2kExj0ut5oMA0GCSqGSIb3DQEBBQUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UE AxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzA1 MTQwMDAwMDBaFw0xNDA1MTUyMzU5NTlaMIHEMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQgLSAxMzY4NTI0MDEwMDczMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20xDzAN BgNVBAsMBlMvTUlNRTEeMBwGA1UECwwVUGVyc29uYSBOb3QgVmFsaWRhdGVkMR8wHQYDVQQLDBZT eW1hbnRlYyBUcnVzdCBOZXR3b3JrMR0wGwYDVQQKDBRTeW1hbnRlYyBDb3Jwb3JhdGlvbjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/aDENz/1kQVeEyPK5cHw3n9c4ErU13WONPXjL7 fHYj0Yr/DSGbdyiWZ001bkIMPxvJbxv4r5EaTq72gHxhTF/frLoM5+sEKAErBPuOqpAAYlxo4uyK U1pQzPy+3rtlVRStNUAJZHVN4kYtHRghGoBCkqh2JoSBMCgc41Mr1UvS3dI4kp5lKEqutKjoDtdc /O4Kee/CLzEy0D8QNOF7OSjrPmed1jsAxxqsv9EHMJvG9z/CIXF2Q/kYf24ozeujCPZVaOTjWVsd BsZSNUaD9LyeGQBtGCXq7e0rUEFPZfsdxUoBoVeTYRYIcloFuiG4QQsvjr6rlFZDbXEhOWOJnRsC AwEAAaOCAwcwggMDMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMCAGA1UdJQEB/wQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU+K3xGZv+qs21HN5cJGWwMOyfwHcwHQYDVR0R BBYwFIEScm9nYWdsaWFAY2lzY28uY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoB MIIBKwYIKwYBBQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3Rvcnku dmVyaXNpZ24uY29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFs JTIwU3Vic2NyaWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90 JTIwVmFsaWRhdGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUy QyUyME8lMjAlM0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NB Q2VydGlmaWNhdGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1 dGguY29tL2NhXzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmww bAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1 dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGGx85vFgUxMDkyMjA5BgpghkgBhvhFARAFBCsw KQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUA A4IBAQA9KvHI6pN0/W4MJl3cATuTU0cdkjZBvfztljunVmn72rij+hJKzSg8lGawguiccFWVqqEl sMIAinuB1zqFe1ILchliltXEj5vPI+HyGxn5akhQuzk7/hmAfs00CC1hbC1HB8r+b7R2s/bkJ7YY fpE0lMd7exB62MccwKh5yFCgxIvxG/irFLjNicpW/C6ixzmuPoKQO9Rs5H9oBnYVxtGpORPt6H5+ DINZOpsbDcnNgi3mIpSK0lapSzVUueOWBJwS5sfjOLe5pBbpvarrZp0zs0gADupX5u1bH0DpSwj1 zN5wP/p5f2h0L2i4rpaU05LLgBzh0JTy+zidLpU8NgAhMYID5DCCA+ACAQEwgbswgaYxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAYf+/XztcT+E2k Exj0ut5oMAkGBSsOAwIaBQCgggH9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDkyNzIwMjY0MVowIwYJKoZIhvcNAQkEMRYEFOLF2IXg7lFpjfO6RUi6aWf/EiQL MIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVy c29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0AhAYf+/XztcT+E2kExj0ut5oMIHOBgsqhkiG9w0BCRACCzGBvqCB uzCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQL ExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQC EBh/79fO1xP4TaQTGPS63mgwDQYJKoZIhvcNAQEBBQAEggEAnI2csVga836kR1RAtWsaXDgVThEd GIgUQ8pv5Wrr/ez/wVb+DwIbdezw608uLEnTg2b41oGI3VtBPA2DohbmUkr4bXQhe0N3fzvzj45n 3+bQGVjfW01HTCHCyXYtpf4QaTSHCmNX+2YgzN1z1QBLZqirX/SBebe4os2+iYR9aSz//1FMDKO8 BxSjc9qzHoKCnWbBrS2ThXaxjV0UD42AZqgLABIguYZT7JEDCj9k4gD2Oa/hB+Bmdha0eKIE26IX 1STcPiHjDiFFE31uyBkmm55dAhT6Aqu7JnQ1rKXf5vMSQLjDG/2zqk6hY8CZsRzs+TmpqFThnXnr uws99xrzBQAAAAAAAA== --Apple-Mail=_085E6F09-15AB-4523-9894-75710703C19D-- From randy@psg.com Fri Sep 27 13:31:34 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C171521F9EAD for ; Fri, 27 Sep 2013 13:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LxUkb4gzNAp for ; Fri, 27 Sep 2013 13:31:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7D421F9F96 for ; Fri, 27 Sep 2013 13:31:33 -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 1VPehG-0001Ke-Fd; Fri, 27 Sep 2013 20:31:30 +0000 Date: Fri, 27 Sep 2013 10:31:29 -1000 Message-ID: From: Randy Bush To: "Roque Gagliano (rogaglia)" In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB6AB@CVA-MB002.centreville.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] possible interim meeting for draft-ietf-sidr-multiple-publication-points X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 20:31:34 -0000 > I agree with Randy that (we) the authors are in fault here. not fault. just work in queue for busy people randy From prvs=2982ee7a37=sandra.murphy@parsons.com Fri Sep 27 14:26:06 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9968911E80DE for ; Fri, 27 Sep 2013 14:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-JNkGBlBuZn for ; Fri, 27 Sep 2013 14:26:02 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id DC67711E8168 for ; Fri, 27 Sep 2013 14:26:01 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8RLPBsd015938; Fri, 27 Sep 2013 16:26:00 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1f5cp6a6uc-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 27 Sep 2013 16:25:59 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8RLPwNZ001360; Fri, 27 Sep 2013 16:25:58 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8RLPwhw004089; Fri, 27 Sep 2013 16:25:58 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Fri, 27 Sep 2013 17:25:58 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: call for indication of interest: draft-ietf-sidr-rpsl-sig Thread-Index: AQHOn1BOL8dSVe3s0kSIt9a0dY5T+ZnaUANa Date: Fri, 27 Sep 2013 21:25:57 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB74F@CVA-MB002.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6749DEA4E@CVA-MB001.centreville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6749DEA4E@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-27_08:2013-09-27, 2013-09-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=11.3641288271473 compositescore=0.0229752679104391 urlsuspect_oldscore=0.0501409747817734 suspectscore=0 recipient_domain_to_sender_totalscore=1469 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=1 recipient_domain_to_sender_domain_totalscore=7945 rbsscore=0.0229752679104391 spamscore=0 recipient_to_sender_domain_totalscore=2 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309270132 Subject: Re: [sidr] call for indication of interest: draft-ietf-sidr-rpsl-sig X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:26:06 -0000 There were sufficient indications of continued interest in this draft, so t= he draft will continue to be an active draft.=0A= =0A= There was more than one volunteer to help with the draft. Benno is a part = of the RIPE community that has used RPSL for a long time, and the chairs ha= ve accepted his offer to be a co-author.=0A= =0A= Thank you, Benno.=0A= =0A= The current authors should work with Benno to divide the draft duties.=0A= =0A= --Sandy, speaking as one of the co-chairs=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@parsons.com]=0A= Sent: Thursday, August 22, 2013 4:07 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] call for indication of interest: draft-ietf-sidr-rpsl-sig= =0A= =0A= The authors of the draft-ietf-sidr-rpsl-sig have both indicated that they s= ee a need for this draft and are still interested in pursuing the work.=0A= =0A= But they both have been appointed to positions that put strong demands on t= heir time.=0A= =0A= Therefore, they would like some indication from the wg that the wg also is = interested in pursuing the work.=0A= =0A= And the co-chairs think it would be helpful to have an additional author/ed= itor on this draft.=0A= =0A= So.=0A= =0A= Please do state whether you believe the wg should continue work in this are= a. Responses by 5 Sep, please.=0A= =0A= If you would be interested in serving as an additional author on this draft= , please do say so.=0A= =0A= --Sandy, speaking as wg co-chair=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From prvs=2982ee7a37=sandra.murphy@parsons.com Fri Sep 27 14:31:40 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD4B21F9048 for ; Fri, 27 Sep 2013 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiLNSWB-OZEO for ; Fri, 27 Sep 2013 14:31:35 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1221F9808 for ; Fri, 27 Sep 2013 14:30:13 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8RLThJa020253 for ; Fri, 27 Sep 2013 16:30:13 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1f5cp6a7hs-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 27 Sep 2013 16:30:12 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r8RLUBA3001400 for ; Fri, 27 Sep 2013 16:30:11 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r8RLUBJY004200 for ; Fri, 27 Sep 2013 16:30:11 -0500 Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Fri, 27 Sep 2013 17:30:11 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: draft-ietf-sidr-bogons is dead Thread-Index: Ac67yL42jAAySFITT4+/s7gffSizDA== Date: Fri, 27 Sep 2013 21:30:09 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CEB75D@CVA-MB002.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-27_08:2013-09-27, 2013-09-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=121.944 compositescore=0.0520922603175645 urlsuspect_oldscore=0.520922603175645 suspectscore=0 recipient_domain_to_sender_totalscore=1816 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=7979 rbsscore=0.0520922603175645 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309270133 Subject: [sidr] draft-ietf-sidr-bogons is dead X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 21:31:40 -0000 The draft draft-ietf-sidr-bogons has not seen progress since 2009 and the a= uthors have not indicated interest in pursuing this.=0A= =0A= This draft is now marked as dead in the datatracker.=0A= =0A= --Sandy, speaking as one of the co-chairs= From kent@bbn.com Mon Sep 30 11:08:58 2013 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B09721F9C37; Mon, 30 Sep 2013 11:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOoDkUl3SGcT; Mon, 30 Sep 2013 11:08:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80021F9D30; Mon, 30 Sep 2013 11:08:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37342 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VQhta-000G48-3A; Mon, 30 Sep 2013 14:08:34 -0400 Message-ID: <5249BE21.4060702@bbn.com> Date: Mon, 30 Sep 2013 14:08:33 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Black, David" References: <8D3D17ACE214DC429325B2B98F3AE712025DBB6FDA@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712025DBB6FDA@MX15A.corp.emc.com> Content-Type: multipart/alternative; boundary="------------060700050800060803080107" Cc: "sidr@ietf.org" , "ietf@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 18:08:58 -0000 This is a multi-part message in MIME format. --------------060700050800060803080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, > Major issue: > > This draft contains more than just a threat model. agreed. > It also contains > a high level security analysis of the security architecture/approach > that applies the RPKI to secure use of BGP. yes. we didn't create a threat model doc for the RPKI, and this seemed like a good time to address that omission, since the SIDR charter mandates use of the RPKI as a basis for the path security design. > That analysis appears to > be good, but it's somehow disconnected from the rest of the sidr WG's > work, by what I hope is simply a terminology problem: > - This draft refers to the security architecture/approach for > BGP as PATHSEC. > - Many of the other sidr WG draft refer to that security as > BGPsec > In effect, the PATHSEC security architecture/approach appears to be > implicit in this draft. The term PATHSEC is used to refer to a generic path security solution approach, consistent with the WG charter, rather than to the specific solution approach, BGPsec, that has been developed. The rationale for using the different term is that this threat doc should precede the requirements doc, which should precede the solution design. In reality, the requirements doc was generated before the threat analysis, and the BGPSEC design was well along before this doc was finalized. Earlier versions of the doc did refer to BGPsec, but the term was changed for the reasons cited above. This doc does embed assumptions about what a general path security architecture would entail, e.g., based on prior work on such architectures, e.g, S-BGP. > Something's missing - if those two terms were meant to be the same, > BGPsec should probably be used in this draft, otherwise, the relationship > should be described. I've tagged this as a major issue, as it makes > text like the following in Section 4.2 rather unclear: I hope my explanation above explains why the terminology was adopted. > Stale Path Announcement: If PATHSEC-secured announcements can > expire, such an announcement may be propagated with PATHSEC data > that is "expired". This behavior would violate the PATHSEC goals > and is considered a type of replay attack. > > What is "PATHSEC data"? What are "the PATHSEC goals"? The statement > in the abstract that " We use the term PATHSEC to refer to any BGP > path security technology that makes use of the RPKI" doesn't seem to > answer these questions. PATHSEC data is whatever data is sent via a path security design to enable an AS to verify that the UPDATE has traversed the indicated set of ASes. The goals for PATHSEC are the ones stated in the SIDR WG charter . (The relevant charter text used to appear up front, but was removed at the request of the WG chairs and the cognizant AD. The relevant text appears in this version on page 16, as part of the residual vulnerabilities discussion.) > Minor Issue: > > Section 4.4 seems somewhat loose on caching by RPs, considering the > importance of that caching in countering a number of the attacks described > in that section - in multiple cases, RP detection of an attack relies > upon the RP noticing that something has changed at the publication point > wrt the RP's cached copy in a fashion that should not have happened. > Statements such as "the RPKI calls for RPs to cache" and "RPs are > expected to make use of local caches" strike me as a weak foundation > for the level of security dependence on that caching. A pointer to a > SHOULD or MUST requirement for caching by RPKI RPs in another document > would alleviate this concern; surely that language exists somewhere. The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the RPKI as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it was necessary to repeat that here. But we can include a cite: Note first that the RPKI calls for RPs to cache the data they acquire and verify from the repository system *[RFC6480, RFC6481]*. > Nits/editorial comments: > > Also in Section 4.4: > > (The RP would be very unhappy if > there is no CRL for the CA instance anyway.) > > Please rewrite to describe how the RP reacts to failure to find a CRL > - the RP surely does something in addition to becoming "very unhappy" ;-). > Some of that may already be in the sentence immediately following the > "very unhappy" text. I'll remove the flippant parenthetical. You're right that it isn't useful. > idnits 2.12.17 complains about a missing reference: > > == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined > > That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] > should be informatively referenced here - it was RFC 2385, which has been > obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 > is obsolete will generate a different idnits warning, which is ok to ignore. I disagree, and I discussed this with Stewart previously. The reference appears in a quote and was appropriate at the time the quoted text was generated. --------------060700050800060803080107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David,

Major issue:

This draft contains more than just a threat model.
agreed.
 It also contains
a high level security analysis of the security architecture/approach
that applies the RPKI to secure use of BGP.
yes. we didn't create a threat model doc for the RPKI, and this seemed
like a good time to address that omission, since the SIDR charter mandates
use of the RPKI as a basis for the path security design.
That analysis appears to
be good, but it's somehow disconnected from the rest of the sidr WG's
work, by what I hope is simply a terminology problem:
	- This draft refers to the security architecture/approach for
		BGP as PATHSEC.
	- Many of the other sidr WG draft refer to that security as
		BGPsec
In effect, the PATHSEC security architecture/approach appears to be
implicit in this draft.
The term PATHSEC is used to refer to a generic path security solution
approach, consistent with the WG charter, rather than to the specific
solution approach, BGPsec, that has been developed. The rationale for
using the different term is that this threat doc should precede the
requirements doc, which should precede the solution design. In reality,
the requirements doc was generated before the threat analysis, and the
BGPSEC design was well along before this doc was finalized. Earlier versions
of the doc did refer to BGPsec, but the term was changed for the reasons
cited above. This doc does embed assumptions about what a general path security architecture would entail, e.g., based on prior work on such architectures, e.g, S-BGP.
Something's missing - if those two terms were meant to be the same,
BGPsec should probably be used in this draft, otherwise, the relationship
should be described.  I've tagged this as a major issue, as it makes
text like the following in Section 4.2 rather unclear:
I hope my explanation above explains why the terminology was adopted.
      Stale Path Announcement: If PATHSEC-secured announcements can
      expire, such an announcement may be propagated with PATHSEC data
      that is "expired".  This behavior would violate the PATHSEC goals
      and is considered a type of replay attack.

What is "PATHSEC data"?  What are "the PATHSEC goals"?  The statement
in the abstract that " We use the term PATHSEC to refer to any BGP
path security technology that makes use of the RPKI" doesn't seem to
answer these questions.
PATHSEC data is whatever data is sent via a path security design to enable
an AS to verify that the UPDATE has traversed the indicated set of ASes. The
goals for PATHSEC are the ones stated in the SIDR WG charter . (The relevant
charter text used to appear up front, but was removed at the request of the
WG chairs and the cognizant AD. The relevant text appears in this version on
page 16, as part of the residual vulnerabilities discussion.)
Minor Issue:

Section 4.4 seems somewhat loose on caching by RPs, considering the
importance of that caching in countering a number of the attacks described
in that section - in multiple cases, RP detection of an attack relies
upon the RP noticing that something has changed at the publication point
wrt the RP's cached copy in a fashion that should not have happened.
Statements such as "the RPKI calls for RPs to cache" and "RPs are
expected to make use of local caches" strike me as a weak foundation
for the level of security dependence on that caching.  A pointer to a
SHOULD or MUST requirement for caching by RPKI RPs in another document
would alleviate this concern; surely that language exists somewhere.
The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the RPKI
as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it was
necessary to repeat that here. But we can include a cite:

   Note first that the RPKI calls for RPs to cache the data they acquire
   and verify from the repository system [RFC6480, RFC6481].
Nits/editorial comments:

Also in Section 4.4:

   (The RP would be very unhappy if
   there is no CRL for the CA instance anyway.)

Please rewrite to describe how the RP reacts to failure to find a CRL
- the RP surely does something in addition to becoming "very unhappy" ;-).
Some of that may already be in the sentence immediately following the
"very unhappy" text.
I'll remove the flippant parenthetical. You're right that it isn't useful.
idnits 2.12.17 complains about a missing reference:

  == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined

That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5]
should be informatively referenced here - it was RFC 2385, which has been
obsoleted by RFC 5925, which is referenced here.  The fact that RFC 2385
is obsolete will generate a different idnits warning, which is ok to ignore.
I disagree, and I discussed this with Stewart previously. The reference appears in a
quote and was appropriate at the time the quoted text was generated.

    

    

  


--------------060700050800060803080107--

From rjsparks@nostrum.com  Mon Sep 30 14:16:06 2013
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D041C21F9E83; Mon, 30 Sep 2013 14:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.491
X-Spam-Level: 
X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEcoh+4BBkHE; Mon, 30 Sep 2013 14:16:05 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 280D321F9E80; Mon, 30 Sep 2013 14:16:04 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-125-188.dllstx.fios.verizon.net [71.170.125.188]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8ULG4c9008498 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 16:16:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <5249EA19.20705@nostrum.com>
Date: Mon, 30 Sep 2013 16:16:09 -0500
From: Robert Sparks 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: General Area Review Team , sidr@ietf.org, draft-ietf-sidr-origin-ops@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 71.170.125.188 is authenticated by a trusted mechanism)
Subject: [sidr] Gen-art LC review: draft-ietf-sidr-origin-ops-27
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 21:16:07 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sidr-origin-ops
Reviewer: Robert Sparks
Review Date: 30 September 2013
IETF LC End Date: 1 October 2013
IESG Telechat date: not yet scheduled for a telechat

Summary: Basically ready for publication as a BCP (but there are some LC discussions that should be reflected before approval)



From david.black@emc.com  Mon Sep 30 16:02:43 2013
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51CF21F99E9; Mon, 30 Sep 2013 16:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LabRlwO-hmnz; Mon, 30 Sep 2013 16:02:37 -0700 (PDT)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0FB21F9AA1; Mon, 30 Sep 2013 16:02:33 -0700 (PDT)
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8UN2S1j006653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Sep 2013 19:02:28 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r8UN2S1j006653
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1380582148; bh=dDgd9THgV6eZli+a6imdS828dvM=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=r7Ts7EmUFw7W6fkr26nDV7qCxl3WJjlutYFvipXW33+/3R3q6+egT0oG0GrYZ8i+r hLHpdNTC7jsJ16z2+RJWdsPvQR6/04T3Fv44t1SEmBsINRMaMWPfRjFarcruXKhid9 +sJxokHsLcY8anqNGRCE2DSJhgjril9IxfBk8RLw=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r8UN2S1j006653
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 30 Sep 2013 16:02:12 -0700
Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8UN2B2R008180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Sep 2013 19:02:11 -0400
Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Mon, 30 Sep 2013 19:02:11 -0400
From: "Black, David" 
To: Stephen Kent 
Date: Mon, 30 Sep 2013 19:02:09 -0400
Thread-Topic: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
Thread-Index: Ac6+CBbVhSmDE70mQoK256XQLmYrMwAJU83Q
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DBB7B41@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE712025DBB6FDA@MX15A.corp.emc.com> <5249BE21.4060702@bbn.com>
In-Reply-To: <5249BE21.4060702@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712025DBB7B41MX15Acorpemcc_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-EMM-GWVC: 1
X-RSA-Classifications: DLM_1, public
X-EMM-McAfeeVC: 1
Cc: "ietf@ietf.org" , "Black, David" , "sidr@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" 
Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 23:02:43 -0000

--_000_8D3D17ACE214DC429325B2B98F3AE712025DBB7B41MX15Acorpemcc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

[1] Terminology:

> The term PATHSEC is used to refer to a generic path security solution
> approach, consistent with the WG charter, rather than to the specific
> solution approach, BGPsec, that has been developed. The rationale for
> using the different term is that this threat doc should precede the
> requirements doc, which should precede the solution design. In reality,
> the requirements doc was generated before the threat analysis, and the
> BGPSEC design was well along before this doc was finalized. Earlier versi=
ons
> of the doc did refer to BGPsec, but the term was changed for the reasons
> cited above. This doc does embed assumptions about what a general path
> security architecture would entail, e.g., based on prior work on such
> architectures, e.g, S-BGP.

That change in terminology is fine - what's missing (IMHO) is an explanatio=
n
of how the new terminology relates to terminology used in related drafts.  =
As
the term "PATHSEC" appears to be unique to this draft, I think this draft
should explain how that term relates to the BGPsec terminology used elsewhe=
re
for a specific instance of the PATHSEC concept.  Discussion of related prio=
r
work that also falls under the heading of PATHSEC would be good to add
(e.g., a sentence or two on S-BGP in addition to BGPsec would make it clear
that PATHSEC is the more general term), but I don't view that as essential.

That should address most of my concerns around text that I found hard to
interpret, e.g., the excerpt from section 4.2 in the original review:

>>      Stale Path Announcement: If PATHSEC-secured announcements can
>>      expire, such an announcement may be propagated with PATHSEC data
>>      that is "expired".  This behavior would violate the PATHSEC goals
>>      and is considered a type of replay attack.
>>
>> What is "PATHSEC data"?  What are "the PATHSEC goals"?
>
> PATHSEC data is whatever data is sent via a path security design to enabl=
e
> an AS to verify that the UPDATE has traversed the indicated set of ASes. =
The
> goals for PATHSEC are the ones stated in the SIDR WG charter . (The relev=
ant
> charter text used to appear up front, but was removed at the request of t=
he
> WG chairs and the cognizant AD. The relevant text appears in this version=
 on
> page 16, as part of the residual vulnerabilities discussion.)

I think the terminology clarification will clear up what "PATHSEC data" is,=
 but
the notion of describing the goals of an architecture ("PATHSEC goals") as
"residual vulnerabilities" strikes me as both peculiar and unclear.

[2] Caching

> The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the =
RPKI
> as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it =
was
> necessary to repeat that here. But we can include a cite:
>
>   Note first that the RPKI calls for RPs to cache the data they acquire
>   and verify from the repository system [RFC6480, RFC6481].

That addition would definitely help.  I'd suggest: "calls for" -> "requires=
 that"

I would also observe that it's not a good assumption that the RFC that resu=
lts
from this draft will be read in tandem with the SIDR charter (not much of a
problem here, but a more serious problem in [1] above).  If that really is
intended, then an informative reference to the SIDR charter should be added=
,
although I don't think it's a good idea for an RFC to reference a WG charte=
r
- the relevant WG charter portions should be reproduced in the RFC.

[3] TCPMD5 reference


> idnits 2.12.17 complains about a missing reference:

>

>  =3D=3D Missing Reference: 'TCPMD5' is mentioned on line 114, but not def=
ined

>

> That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5]

> should be informatively referenced here - it was RFC 2385, which has been

> obsoleted by RFC 5925, which is referenced here.  The fact that RFC 2385

> is obsolete will generate a different idnits warning, which is ok to igno=
re.

>

> I disagree, and I discussed this with Stewart previously. The reference a=
ppears

> in a quote and was appropriate at the time the quoted text was generated.



Ok - I was suggesting adding an informative reference to RFC 2385, but this

is a nit, and so if the responsible AD is happy with omitting that referenc=
e

entirely, I don't have a problem.

Thanks,
--David

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, September 30, 2013 2:09 PM
To: Black, David
Cc: achi@cs.unc.edu; General Area Review Team (gen-art@ietf.org); stbryant@=
cisco.com; ietf@ietf.org; sidr@ietf.org
Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06

David,



Major issue:



This draft contains more than just a threat model.
agreed.


 It also contains

a high level security analysis of the security architecture/approach

that applies the RPKI to secure use of BGP.
yes. we didn't create a threat model doc for the RPKI, and this seemed
like a good time to address that omission, since the SIDR charter mandates
use of the RPKI as a basis for the path security design.


That analysis appears to

be good, but it's somehow disconnected from the rest of the sidr WG's

work, by what I hope is simply a terminology problem:

       - This draft refers to the security architecture/approach for

              BGP as PATHSEC.

       - Many of the other sidr WG draft refer to that security as

              BGPsec

In effect, the PATHSEC security architecture/approach appears to be

implicit in this draft.
The term PATHSEC is used to refer to a generic path security solution
approach, consistent with the WG charter, rather than to the specific
solution approach, BGPsec, that has been developed. The rationale for
using the different term is that this threat doc should precede the
requirements doc, which should precede the solution design. In reality,
the requirements doc was generated before the threat analysis, and the
BGPSEC design was well along before this doc was finalized. Earlier version=
s
of the doc did refer to BGPsec, but the term was changed for the reasons
cited above. This doc does embed assumptions about what a general path secu=
rity architecture would entail, e.g., based on prior work on such architect=
ures, e.g, S-BGP.


Something's missing - if those two terms were meant to be the same,

BGPsec should probably be used in this draft, otherwise, the relationship

should be described.  I've tagged this as a major issue, as it makes

text like the following in Section 4.2 rather unclear:
I hope my explanation above explains why the terminology was adopted.


      Stale Path Announcement: If PATHSEC-secured announcements can

      expire, such an announcement may be propagated with PATHSEC data

      that is "expired".  This behavior would violate the PATHSEC goals

      and is considered a type of replay attack.



What is "PATHSEC data"?  What are "the PATHSEC goals"?  The statement

in the abstract that " We use the term PATHSEC to refer to any BGP

path security technology that makes use of the RPKI" doesn't seem to

answer these questions.
PATHSEC data is whatever data is sent via a path security design to enable
an AS to verify that the UPDATE has traversed the indicated set of ASes. Th=
e
goals for PATHSEC are the ones stated in the SIDR WG charter . (The relevan=
t
charter text used to appear up front, but was removed at the request of the
WG chairs and the cognizant AD. The relevant text appears in this version o=
n
page 16, as part of the residual vulnerabilities discussion.)


Minor Issue:



Section 4.4 seems somewhat loose on caching by RPs, considering the

importance of that caching in countering a number of the attacks described

in that section - in multiple cases, RP detection of an attack relies

upon the RP noticing that something has changed at the publication point

wrt the RP's cached copy in a fashion that should not have happened.

Statements such as "the RPKI calls for RPs to cache" and "RPs are

expected to make use of local caches" strike me as a weak foundation

for the level of security dependence on that caching.  A pointer to a

SHOULD or MUST requirement for caching by RPKI RPs in another document

would alleviate this concern; surely that language exists somewhere.
The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the RP=
KI
as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it wa=
s
necessary to repeat that here. But we can include a cite:

   Note first that the RPKI calls for RPs to cache the data they acquire
   and verify from the repository system [RFC6480, RFC6481].


Nits/editorial comments:



Also in Section 4.4:



   (The RP would be very unhappy if

   there is no CRL for the CA instance anyway.)



Please rewrite to describe how the RP reacts to failure to find a CRL

- the RP surely does something in addition to becoming "very unhappy" ;-).

Some of that may already be in the sentence immediately following the

"very unhappy" text.
I'll remove the flippant parenthetical. You're right that it isn't useful.


idnits 2.12.17 complains about a missing reference:



  =3D=3D Missing Reference: 'TCPMD5' is mentioned on line 114, but not defi=
ned



That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5]

should be informatively referenced here - it was RFC 2385, which has been

obsoleted by RFC 5925, which is referenced here.  The fact that RFC 2385

is obsolete will generate a different idnits warning, which is ok to ignore=
.
I disagree, and I discussed this with Stewart previously. The reference app=
ears in a
quote and was appropriate at the time the quoted text was generated.





--_000_8D3D17ACE214DC429325B2B98F3AE712025DBB7B41MX15Acorpemcc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Steve,
 
[1] Terminology:
 
> The term PATHSEC is=
 used to refer to a generic path security solution
> solution approach, BGPsec, that has been d=
eveloped. The rationale for 
> using the diffe=
rent term is that this threat doc should precede the
<=
p class=3DMsoNormal>> requirements doc, which should precede the solution design. In rea=
lity,
> the requirements doc was generated bef=
ore the threat analysis, and the
=
> BGPSEC desi=
gn was well along before this doc was finalized. Earlier versions
> of the doc did refer to BGPsec, but the term was chan=
ged for the reasons
> cited above. This doc =
does embed assumptions about what a general path
=
> security architecture would entail, e.g., based on prior work on such<=
o:p>
> architectures, e.g, S-BGP.=

 
That change in terminology is fin=
e – what’s missing (IMHO) is an explanation
of how the new terminology relates to terminology used in related dr=
afts.  As
the term “PATHSEC” app=
ears to be unique to this draft, I think this draft
for a specific instance of the PATHSEC conc=
ept.  Discussion of related prior
work that =
also falls under the heading of PATHSEC would be good to add
(e.g., a se=
ntence or two on S-BGP in addition to BGPsec would make it clear=

that PATHSEC is the more general term), but I don’t v=
iew that as essential.
 
That should address most of my concerns around text that I found har=
d to
interpret, e.g., the excerpt from section 4.=
2 in the original review:
 
>>      Stale Path Announcement: I=
f PATHSEC-secured announcements can
>> &nbs=
p;    expire, such an announcement may be propagated wi=
th PATHSEC data
>>    &=
nbsp; that is "expired".  This behavior would violate the PA=
THSEC goals
>>     =
; and is considered a type of replay attack.
>=
;> 
>> What is "PATHSEC data&q=
uot;?  What are "the PATHSEC goals"?
> PATHSEC data is whatever data is se=
nt via a path security design to enable
> an A=
S to verify that the UPDATE has traversed the indicated set of ASes. The
> goals for PATHSEC are the ones stated in the S=
IDR WG charter . (The relevant
> charter text =
used to appear up front, but was removed at the request of the
> WG chairs and the cognizant AD. The relevant text appear=
s in this version on
> page 16, as part of th=
e residual vulnerabilities discussion.)
&nbs=
p;
I think the terminology clarification will clear up=
 what “PATHSEC data” is, but
the noti=
on of describing the goals of an architecture (“PATHSEC goals”)=
 as
“residual vulnerabilities” strike=
s me as both peculiar and unclear.
 
[2] Caching
 <=
/span>
> The RPKI mandates caching (see RFCs 6480 and 6481), and=
 since use of the RPKI 
> as a basis for PATHS=
EC is mandated by the SIDR charter, I didn't feel it was =

> necessary to repeat that here. But we can include a cite:
> 
>   Not=
e first that the RPKI calls for RPs to cache the data they acquire
>   and verify from the repository system [R=
FC6480, RFC6481].
 
 
I would also observe that it’s not a g=
ood assumption that the RFC that results
from thi=
s draft will be read in tandem with the SIDR charter (not much of a
problem here, but a more serious problem in [1] above).&=
nbsp; If that really is
intended, then an informa=
tive reference to the SIDR charter should be added,
– the relevant WG charter =
portions should be reproduced in the RFC.
&n=
bsp;
[3] TCPMD5 reference
 
> idnits 2.12.17 complains about a missin=
g reference:
> 
> =
; =3D=3D Missing Reference: 'TCPMD5' is mentioned on line 114, but not defi=
ned
> 
> That citation is e=
mbedded in a quote from RFC 4272, nonetheless, [TCPMD5]
> should be informatively referenced here - it was RFC 2385, which has=
 been
> obsoleted by RFC 5925, which is referenced =
here.  The fact that RFC 2385
> is obsolete wi=
ll generate a different idnits warning, which is ok to ignore.
> 
> I disagree, and I discussed t=
his with Stewart previously. The reference appears
>=
; in a quote and was appropriate at the time the quoted text was generated.=

 
Ok – I was suggesti=
ng adding an informative reference to RFC 2385, but this
is a nit, and so if the responsible AD is happy with omitting that refer=
ence
entirely, I don’t have a problem.
 
Thanks,
--David=

 
From: Stephen Kent [=
mailto:kent@bbn.com] 
Sent: Monday, September 30, 2013 2:09 PMTo: Black, David
Cc: achi@cs.unc.edu; General Area Review=
 Team (gen-art@ietf.org); stbryant@cisco.com; ietf@ietf.org; sidr@ietf.org<=
br>Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06<=
o:p>
 
=

David,


Major issue:
 
This draft contains more than=
 just a threat model. 
agreed.

=

 It also contains
a high level sec=
urity analysis of the security architecture/approach
t=
hat applies the RPKI to secure use of BGP.  
yes. we didn't create a threat model doc for the RPKI, and thi=
s seemed
like a good time to address that omission, since the SIDR chart=
er mandates
use of the RPKI as a basis for the path security design.
=

That analysis appears to
be go=
od, but it's somehow disconnected from the rest of the sidr WG's=

work, by what I hope is simply a terminology problem:=

       - This draft refers to the =
security architecture/approach for
   &=
nbsp;          BGP as PATHSEC.=

       - Many of the ot=
her sidr WG draft refer to that security as
 &nbs=
p;            BGPsec=

In effect, the PATHSEC security architecture/approach=
 appears to be
implicit in this draft.
The term PATHSEC is used to refer to a generic path s=
ecurity solution
approach, consistent with the WG charter, rather than t=
o the specific
solution approach, BGPsec, that has been developed. The r=
ationale for 
using the different term is that this threat doc should pr=
ecede the
requirements doc, which should precede the solution design. In=
 reality,
the requirements doc was generated before the threat analysis,=
 and the
BGPSEC design was well along before this doc was finalized. Ear=
lier versions
of the doc did refer to BGPsec, but the term was changed f=
or the reasons
cited above. This doc does embed assumptions about what a=
 general path security architecture would entail, e.g., based on prior work=
 on such architectures, e.g, S-BGP.

Something's =
missing - if those two terms were meant to be the same,
BGPsec should probably be used in this draft, otherwise, the relationship=

should be described.  I've tagged this as a majo=
r issue, as it makes
text like the following in Sectio=
n 4.2 rather unclear:
I hope my explan=
ation above explains why the terminology was adopted.

      Stale Path Announcement: If PATHSEC-se=
cured announcements can
     =
 expire, such an announcement may be propagated with PATHSEC data
      that is "expired".&nbs=
p; This behavior would violate the PATHSEC goals
 =
;     and is considered a type of replay attack.
 
What is "PATHSEC data"=
?  What are "the PATHSEC goals"?  The statement
in the abstract that " We use the term PATHSEC to refer =
to any BGP
path security technology that makes use of =
the RPKI" doesn't seem to
answer these questions.=

PATHSEC data is whatever data is sent=
 via a path security design to enable
an AS to verify that the UPDATE ha=
s traversed the indicated set of ASes. The
goals for PATHSEC are the one=
s stated in the SIDR WG charter . (The relevant
charter text used to app=
ear up front, but was removed at the request of the
WG chairs and the co=
gnizant AD. The relevant text appears in this version on
page 16, as par=
t of the residual vulnerabilities discussion.)

M=
inor Issue:
 
Section 4.4 se=
ems somewhat loose on caching by RPs, considering the
=
importance of that caching in countering a number of the attacks described<=
o:p>
in that section - in multiple cases, RP detection of a=
n attack relies
upon the RP noticing that something ha=
s changed at the publication point
wrt the RP's cached=
 copy in a fashion that should not have happened.
Statements such as &=
quot;the RPKI calls for RPs to cache" and "RPs are
expected to make use of local caches" strike me as a weak found=
ation
for the level of security dependence on that cac=
hing.  A pointer to a
SHOULD or MUST requirement =
for caching by RPKI RPs in another document
would alle=
viate this concern; surely that language exists somewhere.
=

The RPKI mandates caching (see RFCs 6480 =
and 6481), and since use of the RPKI 
as a basis for PATHSEC is mandated=
 by the SIDR charter, I didn't feel it was 
necessary to repeat that her=
e. But we can include a cite:

   Note first that the RPKI =
calls for RPs to cache the data they acquire
   and verify fro=
m the repository system [RFC6480, RFC6481].

Nits/editorial comments:
 
Also in Section 4.4:
 
&nb=
sp;  (The RP would be very unhappy if
  =
; there is no CRL for the CA instance anyway.)
&n=
bsp;
Please rewrite to describe how the RP reacts to failur=
e to find a CRL
- the RP surely does something in addi=
tion to becoming "very unhappy" ;-).
Some of=
 that may already be in the sentence immediately following the
"very unhappy" text.
I'll remove the flippant parenthetical. You're right that it isn't useful=
.

idnits 2.12.17 complains about a missing refer=
ence:
 
  =3D=3D Missin=
g Reference: 'TCPMD5' is mentioned on line 114, but not defined<=
/pre>
 
That citation is embedded in a quote =
from RFC 4272, nonetheless, [TCPMD5]
should be informa=
tively referenced here - it was RFC 2385, which has been
obsoleted by RFC 5925, which is referenced here.  The fact that RFC=
 2385
is obsolete will generate a different idnits war=
ning, which is ok to ignore.
I disagre=
e, and I discussed this with Stewart previously. The reference appears in a=

quote and was appropriate at the time the quoted text was generated.
 
&=
nbsp;
=

--_000_8D3D17ACE214DC429325B2B98F3AE712025DBB7B41MX15Acorpemcc_--