From nobody Mon Mar 3 07:10:06 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C731A0132 for ; Mon, 3 Mar 2014 07:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN90kqZjmqWB for ; Mon, 3 Mar 2014 07:10:01 -0800 (PST) Received: from txdal11mx02.parsons.com (txdal11mx02.parsons.com [206.219.199.110]) by ietfa.amsl.com (Postfix) with ESMTP id 42FAA1A0127 for ; Mon, 3 Mar 2014 07:10:01 -0800 (PST) Received: from pps.filterd (txdal11mx02 [127.0.0.1]) by txdal11mx02.parsons.com (8.14.5/8.14.5) with SMTP id s23F5Ne5013496 for ; Mon, 3 Mar 2014 09:09:58 -0600 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx02.parsons.com with ESMTP id 1jcshgs2kd-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 03 Mar 2014 09:09:57 -0600 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id s23F9Ve3004969 for ; Mon, 3 Mar 2014 09:09:31 -0600 Received: from HSV-CAS004.huntsville.ads.sparta.com ([10.62.8.148]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id s23F9QpM026696 for ; Mon, 3 Mar 2014 09:09:26 -0600 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS004.huntsville.ads.sparta.com ([fe80::d00f:c039:2622:2252%11]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 09:09:26 -0600 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: jabber scribe; minutes taker; slides from presenters Thread-Index: Ac8zS9OBK2AN0fOiThSf0Ru4Y6WuLAABZMBUAOg7vEo= Date: Mon, 3 Mar 2014 15:09:25 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD35A@HSV-MB002.huntsville.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-03_02:2014-03-03,2014-03-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=230.336 compositescore=0.0475211685653588 urlsuspect_oldscore=0.475211685653588 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0475211685653588 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-1403030061 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QKGIMI_MzNNLcnjuTrZLnTGPjY8 Subject: Re: [sidr] jabber scribe; minutes taker; slides from presenters X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:10:04 -0000 No one has yet volunteered to be either jabber scribe or minutes taker.=0A= =0A= The meeting can't proceed without those.=0A= =0A= Please do consider. The etherpad collaborative tool can make the minutes t= aking less painful but still needs one/two/many collaborators.=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: Murphy, Sandra=0A= Sent: Wednesday, February 26, 2014 7:18 PM=0A= To: sidr@ietf.org=0A= Subject: RE: jabber scribe; minutes taker; slides from presenters=0A= =0A= And number your slides, too. Please.=0A= =0A= --Sandy, speaking as wg co-chair=0A= ________________________________________=0A= From: Murphy, Sandra=0A= Sent: Wednesday, February 26, 2014 6:39 PM=0A= To: sidr@ietf.org=0A= Subject: jabber scribe; minutes taker; slides from presenters=0A= =0A= It would be most helpful to have the roles of jabber scribe and minutes tak= er set before the meeting. If you are willing, please do speak up.=0A= =0A= We can't proceed with the discussions and presentations without a the jabbe= r scribe and minutes taker identified. So if you want the meeting to proce= ed, speak up or urge someone to speak up.=0A= =0A= We are meeting first thing Tuesday morning. Anyone presenting slides shoul= d get their slides to the chairs by end of the session time on Monday. It = would be very much appreciated by those who are participating remotely.=0A= =0A= (Anyone hoping to be first has already lost - David got his in already.)=0A= =0A= --Sandy, speaking as co-chair=0A= From nobody Mon Mar 3 08:09:45 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDC91A0113 for ; Mon, 3 Mar 2014 08:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06xccj4L4bQe for ; Mon, 3 Mar 2014 08:09:35 -0800 (PST) Received: from ux-2s11.inf.fh-bonn-rhein-sieg.de (ux-2s11.inf.fh-bonn-rhein-sieg.de [194.95.66.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7161A00AB for ; Mon, 3 Mar 2014 08:08:20 -0800 (PST) Received: from [192.168.1.32] (p5DDD61FA.dip0.t-ipconnect.de [93.221.97.250]) (authenticated bits=0) by ux-2s11.inf.fh-bonn-rhein-sieg.de (8.14.4/8.14.4/Debian-4ska2) with ESMTP id s23G8FOr031873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 3 Mar 2014 17:08:16 +0100 Message-ID: <5314A8ED.3090105@smail.inf.h-brs.de> Date: Mon, 03 Mar 2014 17:08:13 +0100 From: Demian Rosenkranz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD35A@HSV-MB002.huntsville.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth: by SMTP AUTH @ ux-2s11 X-MIMEDefang-Info-ge: Gescannt in Inf@FH-BRS, Regeln s. MiniFAQ E-Mail/Mailscanner X-Scanned-By: MIMEDefang 2.73 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/qQi_y2jvVh05csT-ADqq53t9rrs Subject: [sidr] Man-in-the-middle attack X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:09:42 -0000 Hello, I have a question regarding the possibility of using mitm attacks to change repository contents/the validity of signed objects and router certificates. Every CA instance has a corresponding CRL and Manifest. The CRL contains certificates which are revoked and the Manifest contains just Signed Objects. Because of the rsync protocol, a mitm attack between RP and repository is possible. If the attacker withholds ... ... a signed object, the rp software would recognize it by checking the manifest. ... a EE certificate, the rp software would recognize it, because the corresponding signed object can't be validated. ... a manifest/crl, the rp sofware would recognize it, because every CA instance has to have a manifest and a crl. ... a CA certificate and all files underneath that certificate, the rp software WOULDN'T recognize anything. So the whole structure underneath that certificate would be invalid. ... a Router certificate, the RP WOULDN'T recognize it, because it isn't listet in any other file. Regonize means recognizing the missing file, not necessarily the attack. It could also be a mistake/bug/etc. Are the described cases right or did I miss something? Would be great to get feedback. Kind regards Demian Rosenkranz From nobody Mon Mar 3 08:44:46 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42001A0238 for ; Mon, 3 Mar 2014 08:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H2rrmenKkFZ for ; Mon, 3 Mar 2014 08:44:43 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id E671C1A0149 for ; Mon, 3 Mar 2014 08:44:42 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so3776687vcb.5 for ; Mon, 03 Mar 2014 08:44:39 -0800 (PST) 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=GdeOcZ4SxYk+V/MFIZ30COtMtMasuxQTjB8NDXgjIPo=; b=X1WJpt9F6o//biTa67vovWGKQnGxt32aVT+3QopSHMgycjoxOZimYhCblgLmTxfjBj jhK1oOY9QHXYsuqD5kBExi3rDsqVHQOEDL7qIb/SNs3s2tegex1qJzYqpgk5/HC27mg0 fC9R/Hqm/EX+CeTRRuddk51zv7Ik+lNmNGrq27/xKlkYMylO3W7N47HWD4/tXJw3J6rY 4vPzrNkvamJZAt2JdXv6KZ2H1AY0hBCYRCrykr5Oj9NaASKzTZ5jDajV+s+pWPspjn2o V+n4eUJeL4Fe7kaei20b3VWbpNIQ/fe8SN3zbrqS5ZcJmUjCOVc3CEe+ZEicNO1q3BmJ xSRQ== X-Gm-Message-State: ALoCoQlvNcjeiyvy36t6UKG0E3sM1l/ewE6j22P9vhVEf8EKiwxtxu6pjPNQMmzrD7a9oRRZ3rRK MIME-Version: 1.0 X-Received: by 10.52.250.4 with SMTP id yy4mr321386vdc.56.1393865079692; Mon, 03 Mar 2014 08:44:39 -0800 (PST) Received: by 10.52.96.202 with HTTP; Mon, 3 Mar 2014 08:44:39 -0800 (PST) In-Reply-To: <5314A8ED.3090105@smail.inf.h-brs.de> References: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD35A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com> <5314A8ED.3090105@smail.inf.h-brs.de> Date: Mon, 3 Mar 2014 11:44:39 -0500 Message-ID: From: Andrew Chi To: Demian Rosenkranz Content-Type: multipart/alternative; boundary=001a1136794cf3bb4704f3b6808a Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/kkiTxtYz3fo8L4x7HWEzd0eIcDY Cc: sidr@ietf.org Subject: Re: [sidr] Man-in-the-middle attack X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:44:44 -0000 --001a1136794cf3bb4704f3b6808a Content-Type: text/plain; charset=UTF-8 All of these are detectable. On Mon, Mar 3, 2014 at 11:08 AM, Demian Rosenkranz < drosen2s@smail.inf.h-brs.de> wrote: > > > ... a CA certificate and all files underneath that certificate, the rp > software WOULDN'T recognize anything. So the whole structure underneath > that certificate would be invalid. > CA certs are listed by the manifest that sits in the same publication point (directory). In addition, the cert's SIA contains a URI for all of the "children." If the CA cert were present but "all files underneath" were missing, the RP software would at the very least log a failure to fetch the child directory. > > ... a Router certificate, the RP WOULDN'T recognize it, because it isn't > listet in any other file. > A manifest will cover anything in the directory (except itself), so that should include router certs. --001a1136794cf3bb4704f3b6808a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All = of these are detectable.

On Mon, Mar 3, 2014 at 11:08 AM, Demian Rosenkranz <drosen2s@smail.inf.h-brs.de> wrote:

... a CA certificate and all files underneath that certificate, the rp soft= ware WOULDN'T recognize anything. So the whole structure underneath tha= t certificate would be invalid.

CA cert= s are listed by the manifest that sits in the same publication point (direc= tory). =C2=A0In addition, the cert's SIA contains a URI for all of the = "children." =C2=A0If the CA cert were present but "all files= underneath" were missing, the RP software would at the very least log= a failure to fetch the child directory.
=C2=A0

... a Router certificate, the RP WOULDN'T recognize it, because it isn&= #39;t listet in any other file.

A manif= est will cover anything in the directory (except itself), so that should in= clude router certs.

--001a1136794cf3bb4704f3b6808a-- From nobody Mon Mar 3 09:42:00 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2131A02EE for ; Mon, 3 Mar 2014 09:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXJNJyuXYWg3 for ; Mon, 3 Mar 2014 09:41:57 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CBB181A0256 for ; Mon, 3 Mar 2014 09:41:56 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id x12so1128147wgg.30 for ; Mon, 03 Mar 2014 09:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tnYASYJ2WCgwjl1Ac5vwmZuGdQmRe6Uzw7VdVfCVznE=; b=IRHzPBrP0yeIheC2XPcOYqYyJGX3Gzt9wxgctMQ7Y5DXZbdd0tvS4Ie9g9AuVIns8T gZkkKsJu+K8tDxasOQq8izeGs9m3YBVt9j8cAqh8uUSSmTWBAjD53tePjkt2vAFiMOk6 +1xHvMAoHnBxCcDXeH+ne3L4Ogpe+P2gU8IndVciJROd1BcBdj580IDNy+4ChFsks3oa lBuZAYUXUd6/QGviNkxFow/CCx1lZ3ZLgfQcC6sPQO3rWV0yPL8z8iim0ZCGYfbDr7JX 1RGoigyeHUTGZZELBUk2g5DWP0MA4JK6CVQopIml9IEK3fkMYxQzH4EKfDUJENkSZoZV zGFQ== MIME-Version: 1.0 X-Received: by 10.195.13.234 with SMTP id fb10mr11634152wjd.50.1393868509400; Mon, 03 Mar 2014 09:41:49 -0800 (PST) Received: by 10.217.120.194 with HTTP; Mon, 3 Mar 2014 09:41:49 -0800 (PST) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD35A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com> Date: Mon, 3 Mar 2014 12:41:49 -0500 Message-ID: From: Matthew Lepinski To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=047d7bb03afc5dd4f104f3b74d9f Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/1dk9A0pUKCPRUfjTTIgafVI3WgY Cc: "sidr@ietf.org" Subject: Re: [sidr] jabber scribe; minutes taker; slides from presenters X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:41:59 -0000 --047d7bb03afc5dd4f104f3b74d9f Content-Type: text/plain; charset=ISO-8859-1 I can take notes to help produce the minutes for the SIDR meeting on Tuesday On Mon, Mar 3, 2014 at 10:09 AM, Murphy, Sandra wrote: > No one has yet volunteered to be either jabber scribe or minutes taker. > > The meeting can't proceed without those. > > Please do consider. The etherpad collaborative tool can make the minutes > taking less painful but still needs one/two/many collaborators. > > --Sandy > > ________________________________________ > From: Murphy, Sandra > Sent: Wednesday, February 26, 2014 7:18 PM > To: sidr@ietf.org > Subject: RE: jabber scribe; minutes taker; slides from presenters > > And number your slides, too. Please. > > --Sandy, speaking as wg co-chair > ________________________________________ > From: Murphy, Sandra > Sent: Wednesday, February 26, 2014 6:39 PM > To: sidr@ietf.org > Subject: jabber scribe; minutes taker; slides from presenters > > It would be most helpful to have the roles of jabber scribe and minutes > taker set before the meeting. If you are willing, please do speak up. > > We can't proceed with the discussions and presentations without a the > jabber scribe and minutes taker identified. So if you want the meeting to > proceed, speak up or urge someone to speak up. > > We are meeting first thing Tuesday morning. Anyone presenting slides > should get their slides to the chairs by end of the session time on Monday. > It would be very much appreciated by those who are participating remotely. > > (Anyone hoping to be first has already lost - David got his in already.) > > --Sandy, speaking as co-chair > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --047d7bb03afc5dd4f104f3b74d9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I can take notes to help produce the minutes for the SIDR = meeting on Tuesday


On Mon, Mar 3, 2014 at 10:09 AM, Murphy, Sandra <Sandra= .Murphy@parsons.com> wrote:
No one has yet volunteered to be either jabb= er scribe or minutes taker.

The meeting can't proceed without those.

Please do consider. =A0The etherpad collaborative tool can make the minutes= taking less painful but still needs one/two/many collaborators.

--Sandy

________________________________________
From: Murphy, Sandra
Sent: Wednesday, February 26, 2014 7:18 PM
To: sidr@ietf.org
Subject: RE: jabber scribe; minutes taker; slides from presenters

And number your slides, too. =A0Please.

--Sandy, speaking as wg co-chair
________________________________________
From: Murphy, Sandra
Sent: Wednesday, February 26, 2014 6:39 PM
To: sidr@ietf.org
Subject: jabber scribe; minutes taker; slides from presenters

It would be most helpful to have the roles of jabber scribe and minutes tak= er set before the meeting. =A0If you are willing, please do speak up.

We can't proceed with the discussions and presentations without a the j= abber scribe and minutes taker identified. =A0So if you want the meeting to= proceed, speak up or urge someone to speak up.

We are meeting first thing Tuesday morning. =A0Anyone presenting slides sho= uld get their slides to the chairs by end of the session time on Monday. = =A0It would be very much appreciated by those who are participating remotel= y.

(Anyone hoping to be first has already lost - David got his in already.)
--Sandy, speaking as co-chair

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

--047d7bb03afc5dd4f104f3b74d9f-- From nobody Mon Mar 3 09:50:47 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7883E1A0259 for ; Mon, 3 Mar 2014 09:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epVubmTpo7bf for ; Mon, 3 Mar 2014 09:50:43 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 92CA01A00E4 for ; Mon, 3 Mar 2014 09:50:43 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s23HoFNo023662; Mon, 3 Mar 2014 11:50:39 -0600 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jcv56rwdt-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 03 Mar 2014 11:50:39 -0600 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s23HobZo026179; Mon, 3 Mar 2014 12:50:37 -0500 Received: from HSV-CAS004.huntsville.ads.sparta.com ([10.62.8.148]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s23HoaQW015523; Mon, 3 Mar 2014 12:50:37 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS004.huntsville.ads.sparta.com ([fe80::d00f:c039:2622:2252%11]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 11:50:36 -0600 From: "Murphy, Sandra" To: Demian Rosenkranz , "sidr@ietf.org" Thread-Topic: [sidr] Man-in-the-middle attack Thread-Index: AQHPNvsLWyOdY0zlsEi8t3LjF8EklprPmikp Date: Mon, 3 Mar 2014 17:50:35 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A01965@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD35A@HSV-MB002.huntsville.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com>, <5314A8ED.3090105@smail.inf.h-brs.de> In-Reply-To: <5314A8ED.3090105@smail.inf.h-brs.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-03_02:2014-03-03,2014-03-03,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.0999750412669593 urlsuspect_oldscore=0.999608685244017 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.0999750412669593 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403030089 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/RYkcEDankHd2bzajc_3Uuohp3jE Subject: Re: [sidr] Man-in-the-middle attack X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:50:45 -0000 I think maybe the problem might be the following statement:=0A= =0A= >Every CA instance has a corresponding CRL and Manifest. The CRL contains= =0A= >certificates which are revoked and the Manifest contains just Signed=0A= >Objects.=0A= =0A= The manifest contains every signed object (except itself) that the CS prod= uces. That includes subsidiary certs, CRLS, ROAs and any other signed obje= ct. So the certs a CA issues are also the set of "signed objects" the mani= fest lists.=0A= =0A= You are probably confused by RFC6486:=0A= =0A= fileList:=0A= This field is a sequence of FileAndHash objects. There is one=0A= FileAndHash entry for each currently valid signed object that has=0A= been published by the authority (at this publication point).=0A= =0A= And the fact that there's an RFC called "Signed Object Template =85" (RFC 6= 488) which is currently used to define manifests and ROAs.=0A= =0A= In RFC6486, "signed objects" means objects that have signatures related to = the CA and are published by the CA, That includes certs and CRLs.=0A= =0A= But in RFC 6488, "signed objects" means a subset of those objects, those th= at are not subsidiary CA certificates or CRLs..=0A= =0A= --Sandy=0A= ________________________________________=0A= From: sidr [sidr-bounces@ietf.org] on behalf of Demian Rosenkranz [drosen2s= @smail.inf.h-brs.de]=0A= Sent: Monday, March 03, 2014 11:08 AM=0A= To: sidr@ietf.org=0A= Subject: [sidr] Man-in-the-middle attack=0A= =0A= Hello,=0A= =0A= I have a question regarding the possibility of using mitm attacks to=0A= change repository contents/the validity of signed objects and router=0A= certificates.=0A= =0A= Every CA instance has a corresponding CRL and Manifest. The CRL contains=0A= certificates which are revoked and the Manifest contains just Signed=0A= Objects.=0A= =0A= Because of the rsync protocol, a mitm attack between RP and repository=0A= is possible. If the attacker withholds ...=0A= =0A= ... a signed object, the rp software would recognize it by checking the=0A= manifest.=0A= =0A= ... a EE certificate, the rp software would recognize it, because the=0A= corresponding signed object can't be validated.=0A= =0A= ... a manifest/crl, the rp sofware would recognize it, because every CA=0A= instance has to have a manifest and a crl.=0A= =0A= ... a CA certificate and all files underneath that certificate, the rp=0A= software WOULDN'T recognize anything. So the whole structure underneath=0A= that certificate would be invalid.=0A= =0A= ... a Router certificate, the RP WOULDN'T recognize it, because it isn't=0A= listet in any other file.=0A= =0A= Regonize means recognizing the missing file, not necessarily the attack.=0A= It could also be a mistake/bug/etc.=0A= =0A= Are the described cases right or did I miss something? Would be great to=0A= get feedback.=0A= =0A= Kind regards=0A= =0A= Demian Rosenkranz=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From nobody Mon Mar 3 10:13:26 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7C51A01F2 for ; Mon, 3 Mar 2014 10:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hniKT_Wc9O98 for ; Mon, 3 Mar 2014 10:13:07 -0800 (PST) Received: from ux-2s11.inf.fh-bonn-rhein-sieg.de (ux-2s11.inf.fh-bonn-rhein-sieg.de [194.95.66.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6971A01D1 for ; Mon, 3 Mar 2014 10:11:31 -0800 (PST) Received: from [192.168.1.32] (p5DDD61FA.dip0.t-ipconnect.de [93.221.97.250]) (authenticated bits=0) by ux-2s11.inf.fh-bonn-rhein-sieg.de (8.14.4/8.14.4/Debian-4ska2) with ESMTP id s23IBQP6014219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 3 Mar 2014 19:11:27 +0100 Message-ID: <5314C5CD.7080602@smail.inf.h-brs.de> Date: Mon, 03 Mar 2014 19:11:25 +0100 From: Demian Rosenkranz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD35A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com> <5314A8ED.3090105@smail.inf.h-brs.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Auth: by SMTP AUTH @ ux-2s11 X-MIMEDefang-Info-ge: Gescannt in Inf@FH-BRS, Regeln s. MiniFAQ E-Mail/Mailscanner X-Scanned-By: MIMEDefang 2.73 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/L3NyKwXVy8GC-QrZx3SrJQJ_Tg4 Subject: Re: [sidr] Man-in-the-middle attack X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:13:11 -0000 Ok, so I misunderstood the RFC6486: "A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an authority responsible for publishing at that publication point." RFC6488: "Other information assertions about resources are expressed via digitally signed, non-X.509 data structures that are referred to as "signed objects" in the RPKI context." So, in the first sentence, "signed object" means all files which were signed by the CA instance and not a RPKI signed object as in the second one?! Thank you for your answers. Kind regards Demian Am 03.03.2014 17:44, schrieb Andrew Chi: > All of these are detectable. > > On Mon, Mar 3, 2014 at 11:08 AM, Demian Rosenkranz > > wrote: > > > ... a CA certificate and all files underneath that certificate, the > rp software WOULDN'T recognize anything. So the whole structure > underneath that certificate would be invalid. > > > CA certs are listed by the manifest that sits in the same publication > point (directory). In addition, the cert's SIA contains a URI for all > of the "children." If the CA cert were present but "all files > underneath" were missing, the RP software would at the very least log a > failure to fetch the child directory. > > > ... a Router certificate, the RP WOULDN'T recognize it, because it > isn't listet in any other file. > > > A manifest will cover anything in the directory (except itself), so that > should include router certs. > From nobody Mon Mar 3 10:57:50 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE731A036C for ; Mon, 3 Mar 2014 10:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhFDIazVe45t for ; Mon, 3 Mar 2014 10:57:46 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id CB82C1A0367 for ; Mon, 3 Mar 2014 10:57:46 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s23ItBxL020373 for ; Mon, 3 Mar 2014 12:57:43 -0600 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jcy7h8316-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 03 Mar 2014 12:57:42 -0600 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s23Ivf92026862 for ; Mon, 3 Mar 2014 13:57:41 -0500 Received: from HSV-CAS004.huntsville.ads.sparta.com ([10.62.8.148]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s23IvgHI016164 for ; Mon, 3 Mar 2014 13:57:42 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS004.huntsville.ads.sparta.com ([fe80::d00f:c039:2622:2252%11]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 12:57:41 -0600 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: slides Thread-Index: AQHPNxI4XCdOpDmExUW9Wb+i20BFcg== Date: Mon, 3 Mar 2014 18:57:41 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A019FC@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-03_03:2014-03-03,2014-03-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.0999750412669593 urlsuspect_oldscore=0.999750412669593 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.0999750412669593 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403030101 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/TxJhPer2a1eHiDsveQhbMUFib-U Subject: [sidr] slides X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:57:48 -0000 Slides that have been received have been uploaded.=0A= =0A= (Notify chairs immediately if you think you've provided slides and the slid= es have not appeared on the meeting materials site.) =0A= =0A= Many of the presenters have not yet provided slides. IF YOU HAVE SLIDES, G= ET THEM IN SOON!! Presentations not uploaded sufficiently before the meeti= ng time will not be presented. And do allow for the possibility of transmi= ssion failure.=0A= =0A= Send slides to the sidr-chairs@ietf.org list -- both chairs.=0A= =0A= =0A= --Sandy=0A= From nobody Mon Mar 3 11:30:15 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410701A0311 for ; Mon, 3 Mar 2014 11:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn4k_UzaquaM for ; Mon, 3 Mar 2014 11:30:09 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAAF1A030D for ; Mon, 3 Mar 2014 11:30:09 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s23JPmhF017439; Mon, 3 Mar 2014 13:30:05 -0600 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jcy7h88t5-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 03 Mar 2014 13:30:04 -0600 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s23JU33B027113; Mon, 3 Mar 2014 14:30:03 -0500 Received: from HSV-CAS004.huntsville.ads.sparta.com ([10.62.8.148]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s23JU4aR016403; Mon, 3 Mar 2014 14:30:04 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS004.huntsville.ads.sparta.com ([fe80::d00f:c039:2622:2252%11]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 13:30:03 -0600 From: "Murphy, Sandra" To: Matthew Lepinski Thread-Topic: [sidr] jabber scribe; minutes taker; slides from presenters Thread-Index: Ac8zS9OBK2AN0fOiThSf0Ru4Y6WuLAABZMBUAOg7vEoAEfP1gP//uSwJ Date: Mon, 3 Mar 2014 19:30:03 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A01A9A@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6949DD35A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949DD60A@HSV-MB002.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949FF7E5@HSV-MB001.huntsville.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F694A01A9AHSVMB001huntsvi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-03_03:2014-03-03,2014-03-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=1380.44443978307 compositescore=0.0686300997361417 urlsuspect_oldscore=0.686300997361417 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=1034100 rbsscore=0.0686300997361417 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403030105 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/g7JLYuyu-roN7InJiPOY81pHv54 Cc: "sidr@ietf.org" Subject: Re: [sidr] jabber scribe; minutes taker; slides from presenters X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:30:12 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F694A01A9AHSVMB001huntsvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you very much Matt. The rest of you are not off the hook. We still need a jabber scribe. And = it would be really really good to have another minutes taker to provide cov= erage. --Sandy ________________________________ From: Matthew Lepinski [mlepinski.ietf@gmail.com] Sent: Monday, March 03, 2014 12:41 PM To: Murphy, Sandra Cc: sidr@ietf.org Subject: Re: [sidr] jabber scribe; minutes taker; slides from presenters I can take notes to help produce the minutes for the SIDR meeting on Tuesda= y On Mon, Mar 3, 2014 at 10:09 AM, Murphy, Sandra > wrote: No one has yet volunteered to be either jabber scribe or minutes taker. The meeting can't proceed without those. Please do consider. The etherpad collaborative tool can make the minutes t= aking less painful but still needs one/two/many collaborators. --Sandy ________________________________________ From: Murphy, Sandra Sent: Wednesday, February 26, 2014 7:18 PM To: sidr@ietf.org Subject: RE: jabber scribe; minutes taker; slides from presenters And number your slides, too. Please. --Sandy, speaking as wg co-chair ________________________________________ From: Murphy, Sandra Sent: Wednesday, February 26, 2014 6:39 PM To: sidr@ietf.org Subject: jabber scribe; minutes taker; slides from presenters It would be most helpful to have the roles of jabber scribe and minutes tak= er set before the meeting. If you are willing, please do speak up. We can't proceed with the discussions and presentations without a the jabbe= r scribe and minutes taker identified. So if you want the meeting to proce= ed, speak up or urge someone to speak up. We are meeting first thing Tuesday morning. Anyone presenting slides shoul= d get their slides to the chairs by end of the session time on Monday. It = would be very much appreciated by those who are participating remotely. (Anyone hoping to be first has already lost - David got his in already.) --Sandy, speaking as co-chair _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --_000_24B20D14B2CD29478C8D5D6E9CBB29F694A01A9AHSVMB001huntsvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you very much Matt.

The rest of you are not off the hook.  We still need a jabber scr= ibe.  And it would be really really good to have another minutes taker= to provide coverage.

--Sandy

From: Matthew Lepinski [mlepinski.ietf@gm= ail.com]
Sent: Monday, March 03, 2014 12:41 PM
To: Murphy, Sandra
Cc: sidr@ietf.org
Subject: Re: [sidr] jabber scribe; minutes taker; slides from presen= ters

I can take notes to help produce the minutes for the SIDR = meeting on Tuesday


On Mon, Mar 3, 2014 at 10:09 AM, Murphy, Sandra = <Sandra.M= urphy@parsons.com> wrote:
No one has yet volunteered to be either jabber scribe or minutes taker.

The meeting can't proceed without those.

Please do consider.  The etherpad collaborative tool can make the minu= tes taking less painful but still needs one/two/many collaborators.

--Sandy

________________________________________
From: Murphy, Sandra
Sent: Wednesday, February 26, 2014 7:18 PM
To: sidr@ietf.org Subject: RE: jabber scribe; minutes taker; slides from presenters

And number your slides, too.  Please.

--Sandy, speaking as wg co-chair
________________________________________
From: Murphy, Sandra
Sent: Wednesday, February 26, 2014 6:39 PM
To: sidr@ietf.org Subject: jabber scribe; minutes taker; slides from presenters

It would be most helpful to have the roles of jabber scribe and minutes tak= er set before the meeting.  If you are willing, please do speak up.
We can't proceed with the discussions and presentations without a the jabbe= r scribe and minutes taker identified.  So if you want the meeting to = proceed, speak up or urge someone to speak up.

We are meeting first thing Tuesday morning.  Anyone presenting slides = should get their slides to the chairs by end of the session time on Monday.=  It would be very much appreciated by those who are participating rem= otely.

(Anyone hoping to be first has already lost - David got his in already.)
--Sandy, speaking as co-chair

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mai= lman/listinfo/sidr

--_000_24B20D14B2CD29478C8D5D6E9CBB29F694A01A9AHSVMB001huntsvi_-- From nobody Mon Mar 3 13:25:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701FE1A014A for ; Mon, 3 Mar 2014 13:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGZWm2mZYGK3 for ; Mon, 3 Mar 2014 13:25:03 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8E71A0102 for ; Mon, 3 Mar 2014 13:25:02 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s23LG6Np024750 for ; Mon, 3 Mar 2014 15:24:59 -0600 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jd1ge81bt-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 03 Mar 2014 15:24:59 -0600 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s23LOwZD028015 for ; Mon, 3 Mar 2014 16:24:58 -0500 Received: from HSV-CAS003.huntsville.ads.sparta.com ([10.62.8.138]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s23LOx2Q017212 for ; Mon, 3 Mar 2014 16:24:59 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS003.huntsville.ads.sparta.com ([fe80::a415:ede2:34ef:d13f%11]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 15:24:58 -0600 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: updated agenda Thread-Index: Ac83JvggmCAydoQZQ7ezMOWnSo3CYg== Date: Mon, 3 Mar 2014 21:24:58 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A01D86@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-03_03:2014-03-03,2014-03-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.0999750412669593 urlsuspect_oldscore=0.999750412669593 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.0999750412669593 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403030122 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/qv-TMhzw4Z5SbInbnpYO-sbyG1c Subject: [sidr] updated agenda X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 21:25:04 -0000 There's an updated agenda with an additional topic and a reduction of one t= opic's time slot size from twice what everyone else got to the same as ever= yone else (especially given that the request had been for "a few minutes" = :-) ).=0A= =0A= The agenda is full. Those presenters/speakers/ombudsgeeks whose topics are= pretty cut-and-dried should feel free to take less than the time allotted = so we have more time for discussion of less cut-and-dried topics.=0A= =0A= --Sandy, speaking as one of the co-chairs=0A= =0A= =0A= From nobody Tue Mar 4 01:36:36 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF381A0473 for ; Tue, 4 Mar 2014 01:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtGkFc7u-gbK for ; Tue, 4 Mar 2014 01:36:31 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 662421A044B for ; Tue, 4 Mar 2014 01:36:31 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id b13so2850440wgh.32 for ; Tue, 04 Mar 2014 01:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NJEPK7U0A+jEXB1rwRcen/uD0XhC0k+uYo3TnVeI09o=; b=j+Uz6KWShiqco4Sff2yULJz65tuJ/x8dQmGJ/19kvUFTr0JjhxfZP+uom1YYedE9xq jnFnqgAzO2USwEU1PbFfptuxqeDrWouzx26Hc8q5IMTk+T2DyBJLmIyMI65EbjX6yTSy 44GM2/dAPHGxt+aFPRrTA2MxYJXYHOoz/bqo0sazooehXzVoZ9qKaFtHlETripxw/aen XsFx+RmDfkbBHn4iXAo6rsxNOg+MFBgG2XK18t0t91gYaJgCSHIvZUgVBr7JEehsPEX2 tpKF1x7VAYYapMdmyifhBLJ8nIc7yp9nMDwarMTbLGzMyzstWvK5Gl+HSfMsigP/6hP8 jKAA== X-Received: by 10.194.134.132 with SMTP id pk4mr13523201wjb.82.1393925787831; Tue, 04 Mar 2014 01:36:27 -0800 (PST) Received: from dhcp-b461.meeting.ietf.org (dhcp-b461.meeting.ietf.org. [31.133.180.97]) by mx.google.com with ESMTPSA id ju6sm49143104wjc.1.2014.03.04.01.36.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 01:36:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6949DBD45@HSV-MB002.huntsville.ads.sparta.com> Date: Tue, 4 Mar 2014 20:36:24 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F6940A90C5@HSV-MB001.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6949DBD45@HSV-MB002.huntsville.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/y-3PX0i4uGmt01bJfASVIeBNyP0 Cc: "sidr@ietf.org" Subject: Re: [sidr] working group adoption poll for draft-huston-sidr-rfc6490-bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:36:35 -0000 submitted - with blank line added as per WG discussion today On 27 Feb 2014, at 4:16 am, Murphy, Sandra = wrote: > There was sufficient support and no objections raised (as well as some = energetic activity) to judge the working group as having consensus to = adopt this work as a working group work item. >=20 > The authors should submit a new draft with a working group file name = as soon as as possible. >=20 > --Sandy, speaking as one of the co-chairs >=20 > ________________________________________ > From: sidr [sidr-bounces@ietf.org] on behalf of Murphy, Sandra = [Sandra.Murphy@parsons.com] > Sent: Friday, February 07, 2014 2:47 PM > To: sidr@ietf.org > Subject: [sidr] working group adoption poll for = draft-huston-sidr-rfc6490-bis >=20 > The authors of "draft-ietf-sidr-multiple-publication-points" proposed = a new direction for that draft that included: >=20 >=20 > - A "6490-bis" document that obsoletes RFC 6490 with the addition of = multiple operators in section 3 of the current document. >=20 >=20 > The wg having consented to that approach, the authors of RFC6490 = produced a new draft draft-huston-sidr-rfc6490-bis that would serve as = the 6490-bis. >=20 > The authors of draft-huston-sidr-rfc6490-bis have requested that the = wg adopt this draft as a working group work item. >=20 > See http://tools.ietf.org/html/draft-huston-sidr-rfc6490-bis-00, = "Resource Certificate PKI (RPKI) Trust Anchor Locator". >=20 > Please do respond to the list as to whether you support the wg = adopting this as a work item. Note that you do not need to comment on = the content of this draft at this time. You are asked to indicate if = you think that this is work that the wg should be doing and whether this = draft is an acceptable starting point. Adding whether you can/will = review or not is useful. >=20 > This adoption poll will end on Friday, 21 February, 2014. >=20 > --Sandy, speaking as wg co-chair >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Mar 4 07:19:51 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C584E1A014D for ; Tue, 4 Mar 2014 07:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEJ4UkbHqXX3 for ; Tue, 4 Mar 2014 07:19:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D86661A01C5 for ; Tue, 4 Mar 2014 07:19:36 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:37147 helo=dhcp-a575.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WKr85-000IFQ-Cn; Tue, 04 Mar 2014 10:19:37 -0500 Message-ID: <5315EF02.3080206@bbn.com> Date: Tue, 04 Mar 2014 10:19:30 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Randy Bush , sidr Content-Type: multipart/alternative; boundary="------------070304030506050008020400" Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/teprT5swNGokWGSppIhwR5fXnfg Subject: [sidr] suggested text to replace Section 4 in the use cases doc X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:19:41 -0000 This is a multi-part message in MIME format. --------------070304030506050008020400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Randy, here is my suggestion for text that is not so folksy and is clearer (at least to me). Steve 4.Example Uses Case 1: ISP C find that its CA certificate has been be revoked (or modified to removed resources) by the RIR (or ISP) that issued it. ISP C believes that this revocation was either an error by RIR staff, or that the RIR has been compelled to revoke the certificate by a law enforcement agency in the jurisdiction where the RIR operates. ISP C would like other ISPs to be able to ignore the certificate revocation (or modification), at their discretion. Case 1 also encompasses a larger case, e.g., when all of the ISPs with a country require protection for an RIR action of this sort, coordinated at a national level. We cannot assume that the country operates an NIR. Case 2: ISP B makes use of private address space (RFC 1918) or makes use of address space allocated to some other party , but which is not announced globally). ISP B makes use of the RPKI internally, as well as for global routing. ISP B would like its use of private address space to work internally with routers that make use of RPKI data. Case 3: An organization, A, is authorized to control routing of traffic from a set of ISPs to the rest of the Internet. (For example, A may want traffic to selected addresses to be redirected to other addresses, or be dropped.)Because these ISPs want to use the RPKI, A needs a way to coordinate their use of the RPKI (insupport of A's traffic management goal). --------------070304030506050008020400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Randy,


here is my suggestion for text that is not so folksy and is clearer (at least to me).


Steve


4.  Example Uses

 

Case 1:

ISP C find that its CA certificate has been be revoked (or modified to removed resources) by the RIR (or ISP) that issued it. ISP C believes that this revocation was either an error by RIR staff, or that the RIR has been compelled to revoke the certificate by a law enforcement agency in the jurisdiction where the RIR operates. ISP C would like other ISPs to be able to ignore the certificate revocation (or modification), at their discretion.

 

Case 1 also encompasses a larger case, e.g., when all of the ISPs with a country require protection for an RIR action of this sort, coordinated at a national level. We cannot assume that the country operates an NIR.

 

Case 2:

ISP B makes use of private address space (RFC 1918) or makes use of address space allocated to some other party , but which is not announced globally). ISP B makes use of the RPKI internally, as well as for global routing. ISP B would like its use of private address space to work internally with routers that make use of RPKI data.

 

Case 3:

An organization, A, is authorized to control routing of traffic from a set of ISPs to the rest of the Internet. (For example, A may want traffic to selected addresses to be redirected to other addresses, or be dropped.)  Because these ISPs want to use the RPKI, A needs a way to coordinate their use of the RPKI (in  support of A’s traffic management goal).

--------------070304030506050008020400-- From nobody Tue Mar 4 07:21:06 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC21A007C for ; Tue, 4 Mar 2014 07:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_La_sGtv3Vm for ; Tue, 4 Mar 2014 07:21:01 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 90B5B1A0032 for ; Tue, 4 Mar 2014 07:21:01 -0800 (PST) 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 1WKr9M-00038u-UP; Tue, 04 Mar 2014 15:20:57 +0000 Date: Tue, 04 Mar 2014 15:20:55 +0000 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: <5315EF02.3080206@bbn.com> References: <5315EF02.3080206@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/3CYwmgm4qR6_BbW8Hyz_H24laDQ Cc: sidr Subject: Re: [sidr] suggested text to replace Section 4 in the use cases doc X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:21:04 -0000 wow! text. i will incorporate after a pause for list denizens to comment. thanks! randy From nobody Tue Mar 4 07:55:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FFE1A027B for ; Tue, 4 Mar 2014 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.25 X-Spam-Level: *** X-Spam-Status: No, score=3.25 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_CHARSET_FARAWAY=2.45] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vZezrn8fx2c for ; Tue, 4 Mar 2014 07:54:56 -0800 (PST) Received: from mail.zdns.cn (smtp.knet.cn [202.173.10.124]) by ietfa.amsl.com (Postfix) with SMTP id A6CAF1A027F for ; Tue, 4 Mar 2014 07:54:55 -0800 (PST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Di Ma In-Reply-To: <5315EF02.3080206@bbn.com> Date: Tue, 4 Mar 2014 15:54:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6AE30413-6C70-4AB1-A939-E5148F28466C@zdns.cn> References: <5315EF02.3080206@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/cjonXw8ris9BRabtx342YrXfxp4 Cc: sidr Subject: Re: [sidr] suggested text to replace Section 4 in the use cases doc X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:55:02 -0000 Steve, It=A1=AFs more explicit and better to understand.=20 But I suggest eliminating the expression concerning NIR that is = =A1=B0Case 1 also encompasses a larger case, e.g., when all of the ISPs = with a country require protection for an RIR action of this sort, = coordinated at a national level. We cannot assume that the country = operates an NIR." INR management in a country with NIR could be very complicated, = with different operation models. If necessay , a separate operation doc = might be presented, getting NIR stuff involved. =20 Di Ma Internet Domain Name System Beijing Engineering Research Centre (ZDNS) KNET Technologies =D4=DA 2014=C4=EA3=D4=C24=C8=D5=A3=AC=CF=C2=CE=E73:19=A3=ACStephen Kent = =D0=B4=B5=C0=A3=BA > Randy, >=20 > here is my suggestion for text that is not so folksy and is clearer = (at least to me). >=20 > Steve >=20 > 4. Example Uses > =20 > Case 1: > ISP C find that its CA certificate has been be revoked (or modified to = removed resources) by the RIR (or ISP) that issued it. ISP C believes = that this revocation was either an error by RIR staff, or that the RIR = has been compelled to revoke the certificate by a law enforcement agency = in the jurisdiction where the RIR operates. ISP C would like other ISPs = to be able to ignore the certificate revocation (or modification), at = their discretion. > =20 > Case 1 also encompasses a larger case, e.g., when all of the ISPs with = a country require protection for an RIR action of this sort, coordinated = at a national level. We cannot assume that the country operates an NIR. > =20 > Case 2: > ISP B makes use of private address space (RFC 1918) or makes use of = address space allocated to some other party , but which is not announced = globally). ISP B makes use of the RPKI internally, as well as for global = routing. ISP B would like its use of private address space to work = internally with routers that make use of RPKI data. > =20 > Case 3: > An organization, A, is authorized to control routing of traffic from a = set of ISPs to the rest of the Internet. (For example, A may want = traffic to selected addresses to be redirected to other addresses, or be = dropped.) Because these ISPs want to use the RPKI, A needs a way to = coordinate their use of the RPKI (in support of A=A1=AFs traffic = management goal). > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Mar 5 05:04:47 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBB41A0121 for ; Wed, 5 Mar 2014 05:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuYUh1LgAnl0 for ; Wed, 5 Mar 2014 05:04:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3791A03A6 for ; Wed, 5 Mar 2014 05:04:39 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:49576 helo=dhcp-a70b.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLBUo-0005cV-Qi; Wed, 05 Mar 2014 08:04:26 -0500 Message-ID: <531720DA.8020300@bbn.com> Date: Wed, 05 Mar 2014 08:04:26 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Di Ma References: <5315EF02.3080206@bbn.com> <6AE30413-6C70-4AB1-A939-E5148F28466C@zdns.cn> In-Reply-To: <6AE30413-6C70-4AB1-A939-E5148F28466C@zdns.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/aUsBmxdzoyaEOfbqlRKjbovAzF4 Cc: sidr Subject: Re: [sidr] suggested text to replace Section 4 in the use cases doc X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:04:45 -0000 > Steve, > It¡¯s more explicit and better to understand. > > But I suggest eliminating the expression concerning NIR that is ¡°Case 1 also encompasses a larger case, e.g., when all of the ISPs with a country require protection for an RIR action of this sort, coordinated at a national level. We cannot assume that the country operates an NIR." > > INR management in a country with NIR could be very complicated, with different operation models. If necessay , a separate operation doc might be presented, getting NIR stuff involved. > > > Di Ma > Internet Domain Name System Beijing Engineering Research Centre (ZDNS) > KNET Technologies Thanks for the feedback. My point, in case 1, is that we cannot assume that a solution to this use case can rely on the existence of an NIR. That is compatible with your observation that an NIR might need to develop its own operations document. Steve From nobody Wed Mar 5 07:50:08 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB891A00DA; Wed, 5 Mar 2014 07:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8nvmO7wgZyT; Wed, 5 Mar 2014 07:50:04 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 49CAE1A074F; Wed, 5 Mar 2014 07:50:03 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id e16so820572lan.2 for ; Wed, 05 Mar 2014 07:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nxNbcS7XK7lOvA/0BPd3AfPwlcvCDafO50uWJYrJeXo=; b=Vt4hDv38hszcEoYXoi/MtYghGjQRr8SNiS4N0LTomxeu67dQn7rRj1pWByP5CpdTcm btzhBZXjSirAjWZOTKH5SnDOsEe9IICXSJi8REFVBslPm3jnM2x0dS9IakyO+TQ+9C3/ 9DjbR+1ABdPnvcUXtDkdaLhtEeUthFj+n1ojbluabIgzZhkZciYy+mrqMx515t/OeUfe mrEpeLwb5S/dbBR+nADlWUrbS0al9GZ+mWVxBJBb3nKCuHHd6vT8qqhoTb+t32LoJNaK YyU6/oYgs3pSqiiOdg0li6yUWIQDyjBHd0ZPlYRCSNxYx7tgzbYbtMzaYfdvByyLnqP2 pkTw== MIME-Version: 1.0 X-Received: by 10.112.55.99 with SMTP id r3mr1718518lbp.54.1394034599870; Wed, 05 Mar 2014 07:49:59 -0800 (PST) Received: by 10.152.45.196 with HTTP; Wed, 5 Mar 2014 07:49:59 -0800 (PST) Date: Wed, 5 Mar 2014 10:49:59 -0500 Message-ID: From: Christopher Morrow To: "sidr-chairs@ietf.org" , "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/7BavhPybXnBwSjTIOUXHozNtg9U Subject: [sidr] BGPSEC Algorithms document missing a clear reference? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:50:07 -0000 It was pointed out in passing (hallway/table conversation) that in: draft-ietf-sidr-bgpsec-algs-05 (at least 05) there's this text in section 2: "NOTE: The exception to the above hashing algorithm is the use of SHA-1 [SHS] when CAs generate authority and subject key identifiers [ID.bgpsec-pki-profiles]." The reference to bgpsec-pki-profiles, is PROBABLY really: draft-sidr-bgpsec-pki-profiles There doesn't seem to be a reference to sha1 here for making an SKI. It looks like you'd have to inherit and inherit from 3779 -> 5280 and text in section 4.2.1.2: " For CA certificates, subject key identifiers SHOULD be derived from the public key or a method that generates unique values. Two common methods for generating key identifiers from the public key are: (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). Cooper, et al. Standards Track [Page 28] RFC 5280 PKIX Certificate and CRL Profile May 2008 (2) The keyIdentifier is composed of a four-bit type field with the value 0100 followed by the least significant 60 bits of the SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). " Is this the intention? that spelunking in rfcs is required to figure out that sha1 would be used? or could/should the reference be more clear? -chris (care of mystery caller #7) From nobody Wed Mar 5 13:07:40 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBA51A073E for ; Wed, 5 Mar 2014 13:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.449 X-Spam-Level: ** X-Spam-Status: No, score=2.449 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_CHARSET_FARAWAY=2.45] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci5OPA1kGzFc for ; Wed, 5 Mar 2014 13:07:37 -0800 (PST) Received: from mail.zdns.cn (smtp.knet.cn [202.173.10.124]) by ietfa.amsl.com (Postfix) with SMTP id 839D31A0716 for ; Wed, 5 Mar 2014 13:07:35 -0800 (PST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Di Ma In-Reply-To: <531720DA.8020300@bbn.com> Date: Wed, 5 Mar 2014 21:07:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9CE5AA6F-AF48-4805-A4AE-FFE4CA4DB83B@zdns.cn> References: <5315EF02.3080206@bbn.com> <6AE30413-6C70-4AB1-A939-E5148F28466C@zdns.cn> <531720DA.8020300@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/EqTnkJW9f2xKSAEEShymQAoFNyc Cc: Di Ma , sidr Subject: Re: [sidr] suggested text to replace Section 4 in the use cases doc X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 21:07:40 -0000 Agreed:)=20 =D4=DA 2014=C4=EA3=D4=C25=C8=D5=A3=AC=CF=C2=CE=E71:04=A3=ACStephen Kent = =D0=B4=B5=C0=A3=BA >=20 >> Steve, >> It=A1=AFs more explicit and better to understand.=20 >>=20 >> But I suggest eliminating the expression concerning NIR that is = =A1=B0Case 1 also encompasses a larger case, e.g., when all of the ISPs = with a country require protection for an RIR action of this sort, = coordinated at a national level. We cannot assume that the country = operates an NIR." >>=20 >> INR management in a country with NIR could be very complicated, = with different operation models. If necessay , a separate operation doc = might be presented, getting NIR stuff involved. >>=20 >>=20 >> Di Ma >> Internet Domain Name System Beijing Engineering Research Centre = (ZDNS) >> KNET Technologies >=20 > Thanks for the feedback. >=20 > My point, in case 1, is that we cannot assume that a solution to this > use case can rely on the > existence of an NIR. >=20 > That is compatible with your observation that an NIR might need to > develop its own operations document. >=20 > Steve >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Mar 6 03:03:25 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9901A02BF for ; Thu, 6 Mar 2014 03:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoG-sVGsXafJ for ; Thu, 6 Mar 2014 03:03:22 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id E0CAE1A02BC for ; Thu, 6 Mar 2014 03:03:21 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-a117.meeting.ietf.org [31.133.161.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 079BB398A2 for ; Thu, 6 Mar 2014 11:03:18 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 2AF1BAFDF22 for ; Thu, 6 Mar 2014 11:03:17 +0000 (GMT) Date: Thu, 06 Mar 2014 11:03:17 +0000 From: Rob Austein To: sidr@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140306110317.2AF1BAFDF22@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Mrj98o9iUlkQ__Q_MhKPEEC5rNA Subject: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:03:23 -0000 I just posted draft-austein-sidr-rpki-rtr-rfc6810bis-00, which is intended as an update to the RPKI-Router protocol (RFC 6810). An HTMLized rfcdiff against RFC 6810 is available at: http://subvert-ietf.hactrn.net/sidr-rpki-rtr-bis/draft-austein-sidr-rpki-rtr-rfc6810bis-00-from-rfc6810.diff.html Summary of changes to date from RFC 6810: 1) New Router Certificate PDU, to support BGPSEC. Those who remember the earlier (and now expired) draft-ymbk-rpki-rtr-keys may notice that the format of this PDU has changed slightly: per discussion at this week's face-to-face meeting in London, we need to support binding a single router key to multiple ASNs, so we changed the PDU format slightly to allow this. 2) We added a few timing parameters to the End Of Data PDU. These, like the Serial Number mechanism, are lifted almost verbatim from the DNS zone transfer protocol. We left them out of RFC 6810, but subsequent exploration of some of the corner cases of the RPKI Router protocol convinced us that leaving these timing parameters out of the protocol had been a mistake. This draft bumps the protocol version number from 0 to 1. Immediately after posting this I-D we received a gentle reminder that we need to specify what a client and server are meant to do when they support different versions of the protocol, so we'll say something about that in the next revision. We'd like to ask the WG to adopt this as a WG draft. We hope this will be a non-contentious request, as the WG is chartered to work on BGPSEC and we're pretty sure that we need the Router Key PDU to support this, but of course this is up to the chairs and the WG. From nobody Thu Mar 6 08:35:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D081A023D for ; Thu, 6 Mar 2014 08:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UYg9T1UZ51f for ; Thu, 6 Mar 2014 08:35:06 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E49131A00F4 for ; Thu, 6 Mar 2014 08:35:05 -0800 (PST) Received: from smp.bbn.com ([192.1.122.26]:37519) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLbGF-000GI6-Vv for sidr@ietf.org; Thu, 06 Mar 2014 11:35:08 -0500 Received: from [130.129.19.230] (port=50900) by smp.bbn.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WLbG9-0009sP-M5 for sidr@ietf.org; Thu, 06 Mar 2014 11:35:01 -0500 Message-ID: <5318A3B4.2070304@bbn.com> Date: Thu, 06 Mar 2014 16:35:00 +0000 From: David Mandelberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: dmandelb Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/XbYaVYRgaLkFp93M7Uz8LRkufN8 Subject: Re: [sidr] Man-in-the-middle attack X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:35:07 -0000 On 2014-03-03 16:08, Demian Rosenkranz wrote: > ... a EE certificate, the rp software would recognize it, because the > corresponding signed object can't be validated. An EE certificate used for a CMS signed object (e.g., a ROAs) is embedded in the CMS signed object itself. I.e., the EE certificate is not a separate file that a MITM could omit or delete. An rsync MITM could modify the CMS to not include an EE certificate, but we'd reject that as an invalid CMS object. Also, the hash of the CMS object would no longer match its corresponding hash in the manifest. From nobody Thu Mar 6 08:36:28 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0111A0074 for ; Thu, 6 Mar 2014 08:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9LDNbJDoTky for ; Thu, 6 Mar 2014 08:36:26 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A9A651A00E8 for ; Thu, 6 Mar 2014 08:36:25 -0800 (PST) Received: from smp.bbn.com ([192.1.122.26]:39637) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLbHX-000GIf-N8 for sidr@ietf.org; Thu, 06 Mar 2014 11:36:27 -0500 Received: from [130.129.19.230] (port=50940) by smp.bbn.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WLbHR-0009sm-DY for sidr@ietf.org; Thu, 06 Mar 2014 11:36:21 -0500 Message-ID: <5318A404.7010701@bbn.com> Date: Thu, 06 Mar 2014 16:36:20 +0000 From: David Mandelberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: dmandelb Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QujiIIjzLe4UPMa3F8B2Hz8TU4E Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:36:27 -0000 I support adoption, and I have a few comments/questions about the draft: In section 5.8, you mention an "Update Query PDU". Did you mean Reset Query? In section 5.10, could you move the SKI to before the AS numbers so all the fixed-length fields are at the beginning? (nit) In section 10, s/pointer of presence/point of presence/ From nobody Thu Mar 6 09:07:21 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909A21A0083 for ; Thu, 6 Mar 2014 09:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cmv6E4Icuco for ; Thu, 6 Mar 2014 09:07:15 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) by ietfa.amsl.com (Postfix) with ESMTP id 026571A01F2 for ; Thu, 6 Mar 2014 09:07:14 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-a117.meeting.ietf.org [31.133.161.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 22E62398D9 for ; Thu, 6 Mar 2014 17:07:10 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 04789AFEE06 for ; Thu, 6 Mar 2014 17:07:08 +0000 (GMT) Date: Thu, 06 Mar 2014 17:07:08 +0000 From: Rob Austein To: sidr@ietf.org In-Reply-To: <5318A404.7010701@bbn.com> References: <5318A404.7010701@bbn.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140306170709.04789AFEE06@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/z9o0UITVR05V2JF3vTAGo99lzks Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:07:17 -0000 At Thu, 06 Mar 2014 16:36:20 +0000, David Mandelberg wrote: > > I support adoption, and I have a few comments/questions about the draft: > > In section 5.8, you mention an "Update Query PDU". Did you mean Reset Query? Yep. > In section 5.10, could you move the SKI to before the AS numbers so all > the fixed-length fields are at the beginning? Seems reasonable. > (nit) In section 10, s/pointer of presence/point of presence/ Oops. Thanks. All of these changes will be in the next revision. From nobody Thu Mar 6 09:16:48 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C341A01FD for ; Thu, 6 Mar 2014 09:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwFzZ-6d3zJN for ; Thu, 6 Mar 2014 09:16:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDA71A01D6 for ; Thu, 6 Mar 2014 09:16:44 -0800 (PST) Received: from smp.bbn.com ([192.1.122.36]:46235) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLbuS-0003H8-0i for sidr@ietf.org; Thu, 06 Mar 2014 12:16:40 -0500 Received: from dhcp-a632.meeting.ietf.org ([31.133.166.50]:48844) by smp.bbn.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1WLgaa-0004iZ-Bw for sidr@ietf.org; Thu, 06 Mar 2014 17:16:28 -0500 Message-ID: <5318AD76.6060204@bbn.com> Date: Thu, 06 Mar 2014 17:16:38 +0000 From: David Mandelberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: dmandelb Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/rmE_NJ4UpfHi5U1ZTydSKmjqvB4 Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:16:45 -0000 Sorry, one more question on this draft: Does it make sense to mandate an order for the AS Numbers field of the Router Key PDU? Otherwise, what happens if the cache announces a router key with one ordering, and withdraws that router key with the same AS numbers in a different order? From nobody Thu Mar 6 09:31:42 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1D01A02BB for ; Thu, 6 Mar 2014 09:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wF2vv6TCqw7 for ; Thu, 6 Mar 2014 09:31:38 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 6091D1A014D for ; Thu, 6 Mar 2014 09:31:38 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-a117.meeting.ietf.org [31.133.161.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 7DEA0398D9 for ; Thu, 6 Mar 2014 17:31:34 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 8F64AAFEE87 for ; Thu, 6 Mar 2014 17:31:33 +0000 (GMT) Date: Thu, 06 Mar 2014 17:31:33 +0000 From: Rob Austein To: sidr@ietf.org In-Reply-To: <5318AD76.6060204@bbn.com> References: <5318AD76.6060204@bbn.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/DSTo56DZ3zXuBoVhwt5pU3ycwlg Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:31:40 -0000 At Thu, 06 Mar 2014 17:16:38 +0000, David Mandelberg wrote: > > Sorry, one more question on this draft: Does it make sense to mandate an > order for the AS Numbers field of the Router Key PDU? Otherwise, what > happens if the cache announces a router key with one ordering, and > withdraws that router key with the same AS numbers in a different order? Seems plausible. Not sure it's necessary, but almost certainly harmless, and might help. Other opinions welcome. From nobody Thu Mar 6 10:12:52 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AF51A004C for ; Thu, 6 Mar 2014 10:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0VtwFii5G92 for ; Thu, 6 Mar 2014 10:12:49 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 72AA71A0040 for ; Thu, 6 Mar 2014 10:12:49 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s26IAT8D017358; Thu, 6 Mar 2014 12:12:43 -0600 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1jewrx04uf-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 06 Mar 2014 12:12:42 -0600 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id s26IC1NV032076; Thu, 6 Mar 2014 12:12:01 -0600 Received: from HSV-CAS003.huntsville.ads.sparta.com (HSV-CAS003.huntsville.sparta.com [10.62.8.138]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id s26IC1HC021751; Thu, 6 Mar 2014 12:12:01 -0600 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS003.huntsville.ads.sparta.com ([fe80::a415:ede2:34ef:d13f%11]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 12:12:00 -0600 From: "Murphy, Sandra" To: Rob Austein Thread-Topic: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) Thread-Index: AQHPOV/V5Crks2I3o0ehVyh5N92J/JrUtauA//+g8Nc= Date: Thu, 6 Mar 2014 18:12:00 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A07731@HSV-MB001.huntsville.ads.sparta.com> References: <5318AD76.6060204@bbn.com>, <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> In-Reply-To: <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-06_06:2014-03-05,2014-03-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=48.445471141256 compositescore=0.0148378968684884 urlsuspect_oldscore=0.195307920112602 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=38 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0148378968684884 spamscore=0 recipient_to_sender_domain_totalscore=47 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403060093 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/x3GCla8q_74zwTkGi9ETc2uS2Mg Cc: "sidr@ietf.org" Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:12:51 -0000 So the draft does two things - adds a new PDU and makes some changes to the= overall protocol function.=0A= =0A= I would expect that adding a new PDU would be a new document, not a revisio= n to the protocol document. Would you agree?=0A= =0A= Since you are changing the protocol function anyway, I can see the efficien= cy in making the changes together. Of course, if there's agreement about o= ne part and not about the other, there's some fate sharing. Comment?=0A= =0A= The new PDU assumes the wg agrees to the revision of the router cert draft.= Correct? So this is tied to progress of a revised router cert draft? Is= somebody already on board to provide that new draft?=0A= =0A= --Sandy=0A= =0A= From nobody Thu Mar 6 10:37:35 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0B1A01CC for ; Thu, 6 Mar 2014 10:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zL-hRFteHyC for ; Thu, 6 Mar 2014 10:37:32 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC81A0192 for ; Thu, 6 Mar 2014 10:37:32 -0800 (PST) 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 1WLdAb-0004Mu-W6; Thu, 06 Mar 2014 18:37:26 +0000 Date: Thu, 06 Mar 2014 18:37:25 +0000 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F694A07731@HSV-MB001.huntsville.ads.sparta.com> References: <5318AD76.6060204@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/4KAW8QAYT9gvIRoZnZ4kG7TDw0k Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:37:33 -0000 > I would expect that adding a new PDU would be a new document, not a > revision to the protocol document. Would you agree? the version numbers all change > The new PDU assumes the wg agrees to the revision of the router cert > draft. Correct? So this is tied to progress of a revised router cert > draft? Is somebody already on board to provide that new draft? maybe you missed draft-ymbk-rpki-rtr-keys-01.txt how much bureaucracy can we create here? randy From nobody Thu Mar 6 11:30:53 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1449C1A00F2 for ; Thu, 6 Mar 2014 11:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3LHyB7aCjH3 for ; Thu, 6 Mar 2014 11:30:49 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0391A0084 for ; Thu, 6 Mar 2014 11:30:49 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s26JUWFq030307; Thu, 6 Mar 2014 13:30:43 -0600 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1jexqur61x-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 06 Mar 2014 13:30:42 -0600 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id s26JUetX000407; Thu, 6 Mar 2014 13:30:40 -0600 Received: from HSV-CAS003.huntsville.ads.sparta.com (HSV-CAS003.huntsville.sparta.com [10.62.8.138]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id s26JUYhJ025481; Thu, 6 Mar 2014 13:30:34 -0600 Received: from KRAVEN.huntsville.ads.sparta.com (10.62.8.137) by HSV-CAS003.huntsville.ads.sparta.com (10.62.8.138) with Microsoft SMTP Server (TLS) id 14.2.347.0; Thu, 6 Mar 2014 13:30:33 -0600 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by kraven.huntsville.ads.sparta.com ([::1]) with mapi id 14.02.0342.003; Thu, 6 Mar 2014 13:30:33 -0600 From: "Murphy, Sandra" To: Randy Bush Thread-Topic: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) Thread-Index: AQHPOV/V5Crks2I3o0ehVyh5N92J/JrUtauA//+g8NeAAHF3gP//na1C Date: Thu, 6 Mar 2014 19:30:33 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A077C5@HSV-MB001.huntsville.ads.sparta.com> References: <5318AD76.6060204@bbn.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-06_06:2014-03-05,2014-03-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=48.445471141256 compositescore=0.0148378968684884 urlsuspect_oldscore=0.195307920112602 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=38 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0148378968684884 spamscore=0 recipient_to_sender_domain_totalscore=47 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403060107 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/_Ka12Yg2N-4U3UfrLiiJxYLQK9Y Cc: Rob Austein , "sidr@ietf.org" Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:30:51 -0000 >> The new PDU assumes the wg agrees to the revision of the router cert=0A= >> draft. Correct? So this is tied to progress of a revised router cert= =0A= >> draft? Is somebody already on board to provide that new draft?>=0A= >=0A= >maybe you missed draft-ymbk-rpki-rtr-keys-01.txt=0A= =0A= Rob's message said that the new PDU would "support binding a single router = key to multiple ASNs".=0A= =0A= I presumed that this came from the change to the router cert that Rob spoke= about in the sidr meeting this week. I presumed he was speaking about a c= hange to draft-ietf-sidr-bgpsec-pki-profiles-06, in this part =0A= =0A= Each BGPSEC Router Certificate MUST include the AS Resource=0A= Identifier Delegation extension, as specified in section 4.8.11 of=0A= [RFC6487]. The AS Resource Identifier Delegation extension MUST=0A= include exactly one AS number, and the "inherit" element MUST NOT be=0A= specified.=0A= =0A= The 6810 change Rob suggests (and draft-ymbk-rpki-rtr-keys-01.txt, too) def= ine a new PDU carrying the router cert's AS info to the router. But draft-= ietf-sidr-bgpsec-pki-profiles-06 needs to change, too, if multiple ASNs are= going to be there to carry.=0A= =0A= >how much bureaucracy can we create here?=0A= =0A= This isn't a big job - a change from "exactly one" to "at least one" might = be sufficient. I think that's substantive, not bureaucratic.=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: Randy Bush [randy@psg.com]=0A= Sent: Thursday, March 06, 2014 1:37 PM=0A= To: Murphy, Sandra=0A= Cc: Rob Austein; sidr@ietf.org=0A= Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)=0A= =0A= > I would expect that adding a new PDU would be a new document, not a=0A= > revision to the protocol document. Would you agree?=0A= =0A= the version numbers all change=0A= =0A= > The new PDU assumes the wg agrees to the revision of the router cert=0A= > draft. Correct? So this is tied to progress of a revised router cert=0A= > draft? Is somebody already on board to provide that new draft?=0A= =0A= maybe you missed draft-ymbk-rpki-rtr-keys-01.txt=0A= =0A= how much bureaucracy can we create here?=0A= =0A= randy=0A= From nobody Thu Mar 6 11:35:37 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166791A012C for ; Thu, 6 Mar 2014 11:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fvSbfQt3swY for ; Thu, 6 Mar 2014 11:35:27 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAA91A0068 for ; Thu, 6 Mar 2014 11:35:27 -0800 (PST) Envelope-to: sidr@ietf.org Received: from dhcp-a5f3.meeting.ietf.org ([31.133.165.243] helo=mw-PC.meeting.ietf.org) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLe4g-000Cxz-DC; Thu, 06 Mar 2014 20:35:22 +0100 Date: Thu, 6 Mar 2014 19:35:16 +0000 From: Matthias Waehlisch To: Rob Austein In-Reply-To: <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> Message-ID: References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/OfSo8YIHI4KrKX3ISM_QDH98Jks Cc: sidr@ietf.org Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:35:29 -0000 On Thu, 6 Mar 2014, Rob Austein wrote: > > Sorry, one more question on this draft: Does it make sense to > > mandate an order for the AS Numbers field of the Router Key PDU? > > Otherwise, what happens if the cache announces a router key with one > > ordering, and withdraws that router key with the same AS numbers in > > a different order? > > Seems plausible. Not sure it's necessary, but almost certainly > harmless, and might help. Other opinions welcome. > maybe David can a little bit more elaborate on the advantages? I suspect that the routers needs to inspect the AS Numbers field per entry anyway. What is the meaning of the order? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From nobody Thu Mar 6 19:07:50 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8771A005F for ; Thu, 6 Mar 2014 19:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V0JYvL9iyth for ; Thu, 6 Mar 2014 19:07:43 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 930121A01B6 for ; Thu, 6 Mar 2014 19:07:43 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s2735xGG018390 for ; Thu, 6 Mar 2014 21:07:39 -0600 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jf28wrujm-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 06 Mar 2014 21:07:39 -0600 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s2737cfJ021060 for ; Thu, 6 Mar 2014 22:07:38 -0500 Received: from HSV-CAS003.huntsville.ads.sparta.com ([10.62.8.138]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s2737cUv008925 for ; Thu, 6 Mar 2014 22:07:38 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS003.huntsville.ads.sparta.com ([fe80::a415:ede2:34ef:d13f%11]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 21:07:37 -0600 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: a new working group draft Thread-Index: Ac85qYvLaz12iFNTROGb0eGuyq+kOA== Date: Fri, 7 Mar 2014 03:07:37 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A07932@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.24] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-07_01:2014-03-05,2014-03-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=230.336 compositescore=0.0999698076309413 urlsuspect_oldscore=0.999698076309413 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=3.26690420359155e-05 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0999698076309413 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403060174 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/_TKK-dEXxNdsRlh0WkI4peSUvbI Subject: [sidr] a new working group draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 03:07:45 -0000 George explained in the meeting on Tuesday (and Rob and Matt had noted on t= he list long ago) that RFC6485 (*) and the CMS spec are not in sync wrt the= mandatory signing algorithm. He also noted that all implementations follo= w the CMS spec.=0A= =0A= The chairs have decided that this is something that needs to be fixed.=0A= =0A= The chairs appoint George Michaelson and Geoff Huston as editors to submit = a draft draft-ietf-sidr-rfc6485-bis-00.txt to revise RFC6485.=0A= =0A= The plan is to push this through to publication with all due speed.=0A= =0A= --Sandy, speaking as one of the co-chairs=0A= =0A= (*) The Profile for Algorithms and Key Sizes for Use in the Resource Publi= c Key Infrastructure (RPKI)= From nobody Fri Mar 7 02:40:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5281A012B for ; Fri, 7 Mar 2014 02:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WgmGWo1-XER for ; Fri, 7 Mar 2014 02:40:03 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 896B11A006F for ; Fri, 7 Mar 2014 02:40:03 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-a117.meeting.ietf.org [31.133.161.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 4E4F339843 for ; Fri, 7 Mar 2014 10:39:59 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 5FA6AAFFE52 for ; Fri, 7 Mar 2014 10:39:58 +0000 (GMT) Date: Fri, 07 Mar 2014 10:39:58 +0000 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/JNAQesH0_rPRzxSR7o1LxIakb14 Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 10:40:05 -0000 At Thu, 6 Mar 2014 19:35:16 +0000, Matthias Waehlisch wrote: > > > > Does it make sense to mandate an order for the AS Numbers field > > > of the Router Key PDU? Otherwise, what happens if the cache > > > announces a router key with one ordering, and withdraws that > > > router key with the same AS numbers in a different order? > > maybe David can a little bit more elaborate on the advantages? I > suspect that the routers needs to inspect the AS Numbers field per entry > anyway. > > What is the meaning of the order? David can speak for himself, but speaking on my own behalf as a implementer: if we define a canonical order, comparing two PDUs is a simple binary string comparison. If we don't define a canonical order, comparison is more complicated, hence more error-prone. Given that the rpki-rtr protocol requires duplicate elimination, we do need to perform such comparisons, so making them as simple as possible seems advisable. FWIW, I think David's suggestion is a good one, and I'm likely to implement it that way in my server whether required to do so or not. From nobody Fri Mar 7 03:47:51 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64B81A018F for ; Fri, 7 Mar 2014 03:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_kRdCiXM0WD for ; Fri, 7 Mar 2014 03:47:47 -0800 (PST) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id F1C021A01C4 for ; Fri, 7 Mar 2014 03:47:46 -0800 (PST) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s27Ber3q006650; Fri, 7 Mar 2014 05:47:41 -0600 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1jf28wt6u1-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 07 Mar 2014 05:47:41 -0600 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id s27Bldve004815; Fri, 7 Mar 2014 05:47:40 -0600 Received: from HSV-CAS003.huntsville.ads.sparta.com (HSV-CAS003.huntsville.sparta.com [10.62.8.138]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id s27BldCc011542; Fri, 7 Mar 2014 05:47:39 -0600 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS003.huntsville.ads.sparta.com ([fe80::a415:ede2:34ef:d13f%11]) with mapi id 14.02.0387.000; Fri, 7 Mar 2014 05:47:39 -0600 From: "Murphy, Sandra" To: Rob Austein Thread-Topic: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) Thread-Index: AQHPOV/V5Crks2I3o0ehVyh5N92J/JrUtauA//+g8NeAASu2ug== Date: Fri, 7 Mar 2014 11:47:37 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A07A96@HSV-MB001.huntsville.ads.sparta.com> References: <5318AD76.6060204@bbn.com>, <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net>, <24B20D14B2CD29478C8D5D6E9CBB29F694A07731@HSV-MB001.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F694A07731@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.23] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-07_03:2014-03-07,2014-03-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=48.445471141256 compositescore=0.0148378968684884 urlsuspect_oldscore=0.195307920112602 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=38 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0148378968684884 spamscore=0 recipient_to_sender_domain_totalscore=47 urlsuspectscore=0.1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403070022 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QC47GEJtQGCd9DM3LzS7KAOMgi8 Cc: "sidr@ietf.org" Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:47:50 -0000 >From conversation with authors, answers below=0A= =0A= >I would expect that adding a new PDU would be a new document, not a revisi= on to the=0A= >protocol document. Would you agree?=0A= =0A= Answer: depends on the PDU=0A= =0A= =0A= >Is somebody already on board to provide that new draft?=0A= =0A= I missed the import of the following captured in the minutes:=0A= =0A= Steve Kent: As an author, we can fix this=0A= =0A= Answer: "yes".=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: Murphy, Sandra=0A= Sent: Thursday, March 06, 2014 1:12 PM=0A= To: Rob Austein=0A= Cc: sidr@ietf.org; Randy Bush=0A= Subject: RE: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)=0A= =0A= So the draft does two things - adds a new PDU and makes some changes to the= overall protocol function.=0A= =0A= I would expect that adding a new PDU would be a new document, not a revisio= n to the protocol document. Would you agree?=0A= =0A= Since you are changing the protocol function anyway, I can see the efficien= cy in making the changes together. Of course, if there's agreement about o= ne part and not about the other, there's some fate sharing. Comment?=0A= =0A= The new PDU assumes the wg agrees to the revision of the router cert draft.= Correct? So this is tied to progress of a revised router cert draft? Is= somebody already on board to provide that new draft?=0A= =0A= --Sandy=0A= =0A= From nobody Fri Mar 7 04:23:37 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8658E1A0218 for ; Fri, 7 Mar 2014 04:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjcOp6dyX2HS for ; Fri, 7 Mar 2014 04:23:32 -0800 (PST) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7002F1A01EC for ; Fri, 7 Mar 2014 04:23:32 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-a117.meeting.ietf.org [31.133.161.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 40B4839837 for ; Fri, 7 Mar 2014 12:23:28 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 1137EB00966 for ; Fri, 7 Mar 2014 12:23:27 +0000 (GMT) Date: Fri, 07 Mar 2014 12:23:26 +0000 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140307122327.1137EB00966@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/juznl3nim4EZjeMuy2fU6_HI7fE Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 12:23:34 -0000 Updated (-01) draft posted, incorporating David's suggestions and the promised text regarding interoperability between versions 0 and 1 of the protocol. Diff of changes against the RFC: http://subvert-ietf.hactrn.net/sidr-rpki-rtr-bis/draft-austein-sidr-rpki-rtr-rfc6810bis-01-from-rfc6810.diff.html From nobody Fri Mar 7 04:37:35 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBC81A0274 for ; Fri, 7 Mar 2014 04:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tfnWYpPuUvs for ; Fri, 7 Mar 2014 04:37:32 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 46E411A0271 for ; Fri, 7 Mar 2014 04:37:30 -0800 (PST) Envelope-to: sidr@ietf.org Received: from dhcp-b550.meeting.ietf.org ([31.133.181.80] helo=mw-PC.meeting.ietf.org) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WLu1k-0006b3-Vt; Fri, 07 Mar 2014 13:37:25 +0100 Date: Fri, 7 Mar 2014 12:37:19 +0000 From: Matthias Waehlisch To: Rob Austein In-Reply-To: <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> Message-ID: References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Ptn5-AyAcrN7cS1CJMb4tbt71aE Cc: sidr@ietf.org Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 12:37:33 -0000 On Fri, 7 Mar 2014, Rob Austein wrote: > > > > Does it make sense to mandate an order for the AS Numbers field > > > > of the Router Key PDU? Otherwise, what happens if the cache > > > > announces a router key with one ordering, and withdraws that > > > > router key with the same AS numbers in a different order? > > > > maybe David can a little bit more elaborate on the advantages? I > > suspect that the routers needs to inspect the AS Numbers field per entry > > anyway. > > > > What is the meaning of the order? > > David can speak for himself, > do you have any other scenario in mind, David? > but speaking on my own behalf as a implementer: if we define a > canonical order, comparing two PDUs is a simple binary string > comparison. If we don't define a canonical order, comparison is more > complicated, hence more error-prone. > It's probably a shift of the "complexity" ... but I agree that it simplifies the router part. What happens if the ASNs are not in order (for some strange bug reason)? It wouldn't harm the router? > Given that the rpki-rtr protocol requires duplicate elimination, we do > need to perform such comparisons, so making them as simple as possible > seems advisable. > I suppose this requires an update of the duplicate description (similar text of Section 5.6 in Section 5.10, and update Section 11, no 11). Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From nobody Fri Mar 7 12:49:25 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF001A020D; Fri, 7 Mar 2014 12:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loFsQXE9eEbR; Fri, 7 Mar 2014 12:49:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E84841A0084; Fri, 7 Mar 2014 12:49:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140307204918.31610.82129.idtracker@ietfa.amsl.com> Date: Fri, 07 Mar 2014 12:49:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/rNvnMl2I3ylJlr4eJHoiLbxQMuM Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:49:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Authors : Geoff Huston George Michaelson Filename : draft-ietf-sidr-rfc6485bis-00.txt Pages : 7 Date : 2014-03-07 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format for the Resource Public Key Infrastructure subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the Relying Parties (RPs) that verify these digital signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 9 03:18:25 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F801A0240 for ; Sun, 9 Mar 2014 03:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz8GHrOmJWlo for ; Sun, 9 Mar 2014 03:18:22 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 074C61A023D for ; Sun, 9 Mar 2014 03:18:22 -0700 (PDT) Received: from minas-ithil.hactrn.net (unknown [93.158.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id EF31939825 for ; Sun, 9 Mar 2014 10:18:10 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id B5A23B02C27 for ; Sun, 9 Mar 2014 11:18:09 +0100 (CET) Date: Sun, 09 Mar 2014 11:18:09 +0100 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140309101809.B5A23B02C27@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/k0tpLSvGtAWicNevoaMJC6VU3FY Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 10:18:23 -0000 At Fri, 7 Mar 2014 12:37:19 +0000, Matthias Waehlisch wrote: > On Fri, 7 Mar 2014, Rob Austein wrote: > > > but speaking on my own behalf as a implementer: if we define a > > canonical order, comparing two PDUs is a simple binary string > > comparison. If we don't define a canonical order, comparison is more > > complicated, hence more error-prone. > > > It's probably a shift of the "complexity" ... but I agree that it > simplifies the router part. Not really more complicated for the cache. I'm holding this router certificate with an RFC 3779 ASIdentifiers extension and need to convert that certificate into a Router Key PDU. Turns out the ASIdentifiers extension already lists the ASNs in the canonical order, so I don't even have to sort it, in fact I'd have to work harder to put the ASNs in any other order. Sorting simplifies things in the cache too: stripping out all the PKI glorp can result in apparent duplicates in the stripped data, which my server is required to remove when constructing the feed my server gives to the router. At least in my implementation, having a single canonical form for the PDU simplifies this process, which is why I'm likely to implement it this way whether required to do so or not. > What happens if the ASNs are not in order (for some strange bug > reason)? It wouldn't harm the router? Point. So maybe caches MUST generate the canonical format but routers MAY skip checking to see whether the cache goofed this up? > > Given that the rpki-rtr protocol requires duplicate elimination, we do > > need to perform such comparisons, so making them as simple as possible > > seems advisable. > > > I suppose this requires an update of the duplicate description > (similar text of Section 5.6 in Section 5.10, and update Section 11, no > 11). Or consolidate the discussion of duplicate PDUs somewhere else in the document, but yes, we need to nail that down. From nobody Mon Mar 10 10:22:58 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF491A06A9 for ; Mon, 10 Mar 2014 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHYo5qnDaaQ9 for ; Mon, 10 Mar 2014 10:22:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D907F1A066C for ; Mon, 10 Mar 2014 10:22:54 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36057 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WN3ub-0002fW-2i for sidr@ietf.org; Mon, 10 Mar 2014 13:22:49 -0400 Message-ID: <531DF4E8.2070301@bbn.com> Date: Mon, 10 Mar 2014 13:22:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sidr@ietf.org References: <5318AD76.6060204@bbn.com>, <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net>, <24B20D14B2CD29478C8D5D6E9CBB29F694A07731@HSV-MB001.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F694A07A96@HSV-MB001.huntsville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F694A07A96@HSV-MB001.huntsville.ads.sparta.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/CTb1DWWJm__d5O-V6M9Pw1vkYw8 Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:22:56 -0000 Sandy, > >From conversation with authors, answers below > >> I would expect that adding a new PDU would be a new document, not a revision to the >> protocol document. Would you agree? > Answer: depends on the PDU > > >> Is somebody already on board to provide that new draft? > I missed the import of the following captured in the minutes: > > Steve Kent: As an author, we can fix this > > Answer: "yes". I think the minutes associated my comment from above with the wrong discussion. I think I made that comment in response to a suggested change to the router cert I-D, to allow more than one AS to appear in a router cert. Steve From nobody Tue Mar 11 02:56:08 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0BF1A066C for ; Tue, 11 Mar 2014 02:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Xum74T3ch65 for ; Tue, 11 Mar 2014 02:56:05 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF0E1A064F for ; Tue, 11 Mar 2014 02:56:05 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s2B9eaWL016808; Tue, 11 Mar 2014 04:55:53 -0500 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jhw300kbg-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2014 04:55:53 -0500 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s2B9tqbW009588; Tue, 11 Mar 2014 05:55:52 -0400 Received: from HSV-CAS003.huntsville.ads.sparta.com ([10.62.8.138]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s2B9tqv7028744; Tue, 11 Mar 2014 05:55:52 -0400 Received: from KRAVEN.huntsville.ads.sparta.com (10.62.8.137) by HSV-CAS003.huntsville.ads.sparta.com (10.62.8.138) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 11 Mar 2014 04:55:52 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by kraven.huntsville.ads.sparta.com ([::1]) with mapi id 14.02.0342.003; Tue, 11 Mar 2014 04:55:51 -0500 From: "Murphy, Sandra" To: Stephen Kent , "sidr@ietf.org" Thread-Topic: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) Thread-Index: AQHPOV/V5Crks2I3o0ehVyh5N92J/JrUtauA//+g8NeAASu2uoAFaXcAgADBeD0= Date: Tue, 11 Mar 2014 09:55:50 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A094EB@HSV-MB001.huntsville.ads.sparta.com> References: <5318AD76.6060204@bbn.com>, <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net>, <24B20D14B2CD29478C8D5D6E9CBB29F694A07731@HSV-MB001.huntsville.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F694A07A96@HSV-MB001.huntsville.ads.sparta.com>, <531DF4E8.2070301@bbn.com> In-Reply-To: <531DF4E8.2070301@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.24] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-11_03:2014-03-10,2014-03-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=59.2324062654895 compositescore=0.0701202090889211 urlsuspect_oldscore=0.999698076309413 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=14 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0701202090889211 spamscore=0 recipient_to_sender_domain_totalscore=14 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403110022 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/2zL44y2nX9UMWHobZwa1Bx3b9w4 Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 09:56:07 -0000 The comment from me about "to provide that new draft" was a comment about a= new version of the router certs draft (draft-ietf-sidr-bgpsec-pki-profiles= ), so your comment applies. =A0=0A= =0A= =0A= The minutes note your comment during the discussion with Rob suggesting the= need for more than one AS in the router certificates. =A0The minutes do no= t note the draft name, and maybe should be amended to do so to be clear.=0A= =0A= =0A= --Sandy=A0=0A= =0A= ________________________________________=0A= From: sidr [sidr-bounces@ietf.org] on behalf of Stephen Kent [kent@bbn.com]= =0A= Sent: Monday, March 10, 2014 1:22 PM=0A= To: sidr@ietf.org=0A= Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)=0A= =0A= Sandy,=0A= =0A= > >From conversation with authors, answers below=0A= >=0A= >> I would expect that adding a new PDU would be a new document, not a revi= sion to the=0A= >> protocol document. Would you agree?=0A= > Answer: depends on the PDU=0A= >=0A= >=0A= >> Is somebody already on board to provide that new draft?=0A= > I missed the import of the following captured in the minutes:=0A= >=0A= > Steve Kent: As an author, we can fix this=0A= >=0A= > Answer: "yes".=0A= I think the minutes associated my comment from above with the wrong=0A= discussion.=0A= I think I made that comment in response to a suggested change to the=0A= router cert=0A= I-D, to allow more than one AS to appear in a router cert.=0A= =0A= Steve=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From nobody Tue Mar 11 07:31:39 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCD41A046F for ; Tue, 11 Mar 2014 07:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlmTHYwAvdEv for ; Tue, 11 Mar 2014 07:31:35 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id B1E4F1A0735 for ; Tue, 11 Mar 2014 07:31:35 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s2BEU26W028761 for ; Tue, 11 Mar 2014 09:31:13 -0500 Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1jj3ja8a8t-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Mar 2014 09:31:13 -0500 Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id s2BEVCJ1028001 for ; Tue, 11 Mar 2014 09:31:12 -0500 Received: from HSV-CAS003.huntsville.ads.sparta.com (HSV-CAS003.huntsville.sparta.com [10.62.8.138]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id s2BEVCVR015555 for ; Tue, 11 Mar 2014 09:31:12 -0500 Received: from KRAVEN.huntsville.ads.sparta.com (10.62.8.137) by HSV-CAS003.huntsville.ads.sparta.com (10.62.8.138) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 11 Mar 2014 09:31:11 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by kraven.huntsville.ads.sparta.com ([::1]) with mapi id 14.02.0342.003; Tue, 11 Mar 2014 09:31:11 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: a new working group draft for RFC6810-bis Thread-Index: Ac89Nov828ahrEa1TpWBZvDPkDBaeg== Date: Tue, 11 Mar 2014 14:31:10 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A0956D@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.24] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-11_04:2014-03-11,2014-03-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=230.336 compositescore=0.0475211685653588 urlsuspect_oldscore=0.475211685653588 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0475211685653588 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-1403110071 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Tzu3ehOXBN5vqv8N-GL6-6tntuA Subject: [sidr] a new working group draft for RFC6810-bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:31:37 -0000 =0A= The router needs the router - AS mappings for the bgpsec path validation to= work, so the rpki-rtr protocol needs to provide that info to the routers. = That means a new rpki-rtr PDU needs to be provided. The chairs have decid= ed this need is clear and a new version of RFC6810 is needed with the new P= DU.=0A= =0A= The chairs appoint Rob Austein and Randy Bush as co-editors of a draft draf= t-ietf-sidr-rfc6810-bis-00.txt to revise RFC6810, which they should submit = at their earliest convenience.=0A= =0A= --Sandy, speaking as one of the wg co-chairs= From nobody Tue Mar 11 07:35:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10D01A0735 for ; Tue, 11 Mar 2014 07:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY_yXXECKRHP for ; Tue, 11 Mar 2014 07:35:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B09BF1A046F for ; Tue, 11 Mar 2014 07:35:02 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:50018) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WNNlm-0002xe-UJ for sidr@ietf.org; Tue, 11 Mar 2014 10:35:03 -0400 Message-ID: <531F1F0F.5090803@bbn.com> Date: Tue, 11 Mar 2014 10:34:55 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/C1cWt4lVDOv44xW2cKWTR2GsZbc Subject: Re: [sidr] BGPSEC Algorithms document missing a clear reference? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:35:05 -0000 Chris, > It was pointed out in passing (hallway/table conversation) that in: > draft-ietf-sidr-bgpsec-algs-05 (at least 05) > > there's this text in section 2: > > "NOTE: The exception to the above hashing algorithm is the use of > > SHA-1 [SHS] when CAs generate authority and subject key > identifiers [ID.bgpsec-pki-profiles]." > > The reference to bgpsec-pki-profiles, is PROBABLY really: > draft-sidr-bgpsec-pki-profiles > not sure why the angle bracket reference to the bgpsec protocol appears above, after the intended reference. But, as you note below, draft-sidr-bgpsec-pki-profiles does not refer to SKI's.It says that it inherits all of the RPKI cert profile (RFC 6487) except as noted in Section 3 of the I-D. RFC 6487 mandates inclusion of the SKI and AKI extensions, and specifies use of SHA-1 to compute SKI and AKI values. So, the text above should be changed to refer RFC 6487. (There is no need to go back to 5280, since 6487 cites it and narrows the SKI/AKI generation options from that RFC.) Steve From nobody Tue Mar 11 08:57:02 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBBD1A0457 for ; Tue, 11 Mar 2014 08:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fPxSaZVN8WN for ; Tue, 11 Mar 2014 08:56:58 -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 F2C531A01AD for ; Tue, 11 Mar 2014 08:56:57 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id y1so5886713lam.9 for ; Tue, 11 Mar 2014 08:56:51 -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=SJfh9FB31VV5JOjjjFyLGUywgT3mfgHdRESAFnmvLd0=; b=QsNCQXfKSh6l1E8ufLENUZzBK9UW9DKSibjEbOa3wPoteAVffdZ5IbBLV/xfNXrtVQ KK3AA8Czvgs06M4adCLQd+96LNvyMD0V5PuuPeu7lTmi2DMWmCJEerj/etoFtk+YX8gI Mcv8JnXF9xzvdgwT1DwyzKBtik5OOBggqpn2/nd/+XBL5rBCruFGZ7jO4Tofyz3QZL6g vgXG276xsJ2Cw5tyDVHBpblRz8JiFmI5RZQKCtATtKjFfv3Jg26/D5RIxjWLXht0QYwu 0nscvK7qBgmbbbKGVqpUEVotYzEouahLbIbmiFZZv5t3o2PxAXve/BQ8ctrzsVXTxET1 lUjQ== MIME-Version: 1.0 X-Received: by 10.152.26.66 with SMTP id j2mr17705128lag.25.1394553411599; Tue, 11 Mar 2014 08:56:51 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.45.196 with HTTP; Tue, 11 Mar 2014 08:56:51 -0700 (PDT) In-Reply-To: <531F1F0F.5090803@bbn.com> References: <531F1F0F.5090803@bbn.com> Date: Tue, 11 Mar 2014 11:56:51 -0400 X-Google-Sender-Auth: 7BqCP8dClrzIKag5rNK6Z8Lke4o Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/r6BML4IFkNbAjTnBvOC1GUvaTws Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSEC Algorithms document missing a clear reference? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:57:01 -0000 On Tue, Mar 11, 2014 at 10:34 AM, Stephen Kent wrote: > Chris, > > >> It was pointed out in passing (hallway/table conversation) that in: >> draft-ietf-sidr-bgpsec-algs-05 (at least 05) >> >> there's this text in section 2: >> >> "NOTE: The exception to the above hashing algorithm is the use of >> >> SHA-1 [SHS] when CAs generate authority and subject key >> identifiers [ID.bgpsec-pki-profiles]." >> >> The reference to bgpsec-pki-profiles, is PROBABLY really: >> draft-sidr-bgpsec-pki-profiles >> > > not sure why the angle bracket reference to the bgpsec protocol appears > above, angle brackets because of old-skool email-client/URL interpolation habits :( wrong reference because ... #fail. The right one: apologies for the confusion. > after the intended reference. But, as you note below, > draft-sidr-bgpsec-pki-profiles > does not refer to SKI's.It says that it inherits all of the RPKI cert > profile > (RFC 6487) except as noted in Section 3 of the I-D. RFC 6487 mandates > inclusion > of the SKI and AKI extensions, and specifies use of SHA-1 to compute SKI and > AKI values. > So, the text above should be changed to refer RFC 6487. (There is no need to > go back to > 5280, since 6487 cites it and narrows the SKI/AKI generation options from > that RFC.) awesome! the OP was correct in pointing out the missing linkages, sweet :) > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Mar 11 10:30:20 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC41A0752 for ; Tue, 11 Mar 2014 10:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDf-J4HdVxLk for ; Tue, 11 Mar 2014 10:30:18 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) by ietfa.amsl.com (Postfix) with ESMTP id 751BF1A0763 for ; Tue, 11 Mar 2014 10:30:15 -0700 (PDT) Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 11 Mar 2014 17:30:08 +0000 Message-ID: <030d01cf3d4e$cb933780$4001a8c0@gateway.2wire.net> From: t.petch To: "Murphy, Sandra" , References: <24B20D14B2CD29478C8D5D6E9CBB29F694A07932@HSV-MB001.huntsville.ads.sparta.com> Date: Tue, 11 Mar 2014 17:09:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AM3PR07CA004.eurprd07.prod.outlook.com (10.242.16.44) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Forefront-PRVS: 0147E151B5 X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(189002)?= =?iso-8859-1?Q?(199002)(377454003)(33646001)(77156001)(81342001)(76796001?= =?iso-8859-1?Q?)(47446002)(85306002)(83072002)(19580395003)(19580405001)(?= =?iso-8859-1?Q?54316002)(77982001)(59766001)(69226001)(93136001)(77096001?= =?iso-8859-1?Q?)(76786001)(56776001)(80976001)(83322001)(85852003)(949460?= =?iso-8859-1?Q?01)(89996001)(92566001)(90146001)(84392001)(4396001)(95416?= =?iso-8859-1?Q?001)(81542001)(23756003)(92726001)(56816005)(62966002)(935?= =?iso-8859-1?Q?16002)(61296002)(74662001)(94316002)(14496001)(93916002)(9?= =?iso-8859-1?Q?5666003)(51856001)(97186001)(47976001)(65816001)(50986001)?= =?iso-8859-1?Q?(53806001)(46102001)(20776003)(47776003)(63696002)(8726600?= =?iso-8859-1?Q?1)(87286001)(42186004)(66066001)(76482001)(47736001)(62236?= =?iso-8859-1?Q?002)(88136002)(74366001)(79102001)(44716002)(50466002)(747?= =?iso-8859-1?Q?06001)(74502001)(87976001)(31966008)(97336001)(50226001)(8?= =?iso-8859-1?Q?0022001)(74876001)(44736004)(49866001)(86362001)(74416001)?= =?iso-8859-1?Q?(7726001)(2101003);DIR:OUT;SFP:1101;SCL:1;SRVR:AMXPR07MB05?= =?iso-8859-1?Q?3;H:AMXPRD0111HT001.eurprd01.prod.exchangelabs.com;FPR:BB3?= =?iso-8859-1?Q?2D8F0.2FAF90D6.CBD79DCF.68E5ADF8.200D7;PTR:InfoNoRecords;M?= =?iso-8859-1?Q?X:1;A:0;LANG:en;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/qLkeJlUYDp5PEFfXgjbif0at_J8 Subject: [sidr] IETF89 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 17:30:20 -0000 Sandy In the meeting materials for IETF89 for SIDR, 'Rsync considered harmful' appears twice - probably about right! - but other presentations are lacking. Can you fix, please? Tom Petch ----- Original Message ----- From: "Murphy, Sandra" To: Sent: Friday, March 07, 2014 3:07 AM /listinfo/sidr From nobody Tue Mar 11 15:27:54 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A181A087A for ; Tue, 11 Mar 2014 15:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nLgqnfPtyWh for ; Tue, 11 Mar 2014 15:27:46 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE4A1A085E for ; Tue, 11 Mar 2014 15:27:46 -0700 (PDT) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB022.namprd09.prod.outlook.com (10.255.211.142) with Microsoft SMTP Server (TLS) id 15.0.893.10; Tue, 11 Mar 2014 22:27:38 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.70]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.70]) with mapi id 15.00.0893.001; Tue, 11 Mar 2014 22:27:37 +0000 From: "Sriram, Kotikalapudi" To: Geoff Huston Thread-Topic: Questions about draft-huston-rpki-validation-01 Thread-Index: Ac89eRhd+ibZbQZWQW6u2RB/Km153Q== Date: Tue, 11 Mar 2014 22:27:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(77096001)(54316002)(56776001)(74316001)(74706001)(76176001)(81342001)(94946001)(74366001)(56816005)(47736001)(87936001)(90146001)(76576001)(76796001)(76786001)(2656002)(33646001)(81542001)(74876001)(95416001)(94316002)(69226001)(87266001)(86362001)(63696002)(54356001)(47976001)(93516002)(95666003)(59766001)(4396001)(53806001)(97186001)(92566001)(97336001)(85852003)(83072002)(47446002)(74502001)(31966008)(74662001)(50986001)(81686001)(80976001)(77982001)(85306002)(46102001)(49866001)(80022001)(66066001)(83322001)(65816001)(79102001)(81816001)(51856001)(76482001)(93136001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB022; H:BLUPR09MB053.namprd09.prod.outlook.com; CLIP:129.6.140.100; FPR:BFA8C715.AE92D712.4AF3BFA7.74E3D148.201EF; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/x3Q4DCd2c5l6xwmIg3jpk3vSk6Y Cc: George Michaelson , sidr wg list Subject: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 22:27:50 -0000 SSB3ZW50IHRocm91Z2ggeW91ciAtMDEgZHJhZnQgYW5kIHRoZSBTSURSIHByZXNlbnRhdGlvbiBz bGlkZXMgZnJvbSBsYXN0IHdlZWsgb25jZSBhZ2FpbiwgDQphbmQgaGF2ZSB0aGUgZm9sbG93aW5n IHF1ZXN0aW9uczogDQoNCigxKSBBbiB1cGRhdGUgd2l0aCBwcmVmaXgtb3JpZ2luIHBhaXIgezUu MC4wLjAvMjQsIEFTNjQ1MTF9IGlzIHJlY2VpdmVkLiANClRoZXJlIGlzIGEgUk9BOiB7NS4wLjAu MC8yMiwgbWF4TGVuZ3RoID0gMjQ7IEFTNjQ1MTF9IGluIHRoZSBSUEtJLiANCkhvd2V2ZXIsIGl0 IGlzIHNpZ25lZCB1c2luZyBhIGNlcnRpZmljYXRlIHRoYXQgaXMg4oCcdmFsaWTigJ0gb25seSBm b3IgcmVzb3VyY2UgezUuMC4wLjAvMjR9LiAgDQpJbiB0aGlzIGNhc2UsIGlzIGl0IHRoZSBpbnRl bnQgb2YgeW91ciBhbHRlcm5hdGUgdmFsaWRhdGlvbiBtb2RlbCB0byBhc2NlcnRhaW4gdGhhdCAN CnRoZSBhYm92ZSBST0EgaXMgcGFydGlhbGx5IHZhbGlkLCBhbmQgYWNjb3JkaW5nbHkgcHJlZml4 LW9yaWdpbiBwYWlyIHs1LjAuMC4wLzI0LCBBUzY0NTExfSBpcyDigJxWYWxpZOKAnT8NCg0KKDIp IExldCB1cyBzYXksIHRoZXJlIGlzIGEgUk9BOiB7MS4wLjAuMC8yNCwgMi4wLjAuMC8yMiwgMy4w LjAuMC8yMDsgQVM2NDUwMH0gaW4gdGhlIFJQS0kuIA0KQnV0IHRoaXMgUk9BIGlzIHNpZ25lZCB1 c2luZyBhIGNlcnRpZmljYXRlIHRoYXQgaXMg4oCcdmFsaWTigJ0gb25seSBmb3IgcmVzb3VyY2Vz IHsxLjAuMC4wLzI0LCAzLjAuMC4wLzIwfQ0KdGhhdCBpcyBhIHN1YnNldCBvZiB0aGUgcHJlZml4 ZXMgbGlzdGVkIGluIHRoZSBST0EuICANCkluIHRoaXMgY2FzZSwgaXMgaXQgdGhlIGludGVudCBv ZiB5b3VyIGFsdGVybmF0ZSB2YWxpZGF0aW9uIG1vZGVsIHRvIGFzY2VydGFpbiB0aGF0IA0KdGhl IGFib3ZlIFJPQSBpcyBwYXJ0aWFsbHkgdmFsaWQsIGFuZCBhY2NvcmRpbmdseSBwcmVmaXgtb3Jp Z2luIHBhaXJzIA0KezEuMC4wLjAvMjQsIEFTNjQ1MDB9IGFuZCB7My4wLjAuMC8yMCwgQVM2NDUw MH0gYXJlIOKAnFZhbGlk4oCdPyANCg0KKDMpIE9uIHNsaWRlICMxOCwgZG8geW91IG5lZWQgdG8g cmVxdWlyZSDigJxDZXJ0aWZpY2F0ZXMgMSB0aHJvdWdoIG4tMSBhcmUgYWxzbyDigJx2YWxpZOKA nSANCmFjY29yZGluZyB0byB0aGlzIHNhbWUgY3JpdGVyaW9u4oCdPyAgWW91IGFyZSBub3QgdmFs aWRhdGluZyB0aGVtIGF0IHRoaXMgcG9pbnQuIA0KWW91IGFyZSBvbmx5IHZhbGlkYXRpbmcgQ2Vy dGlmaWNhdGUg4oCYbuKAmSBmb3IgKmEgZ2l2ZW4gSU5SKi4gDQpJcyBpdCBub3QgZW5vdWdoIHRv IHJlcXVpcmUgdGhhdCDigJx0aGUgcmVzb3VyY2VzIGluIHRoZSBJTlIgZXh0ZW5zaW9uIG9mIA0K Q2VydGlmaWNhdGUgeCBtdXN0IHN1YnN1bWUgdGhlIGdpdmVuIElOUuKAnSBmb3IgZWFjaCB4IChp bmRpdmlkdWFsbHkpOyB4PTEsIDIsIDMsIOKApiwgbj8gDQoNClRoYW5rcy4NClNyaXJhbQ0K4oCD DQoNCg0KDQo= From nobody Tue Mar 11 23:14:02 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872961A0574 for ; Tue, 11 Mar 2014 23:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9v3VzECvRf9 for ; Tue, 11 Mar 2014 23:13:57 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 261BE1A08E2 for ; Tue, 11 Mar 2014 23:13:56 -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=zwzGooe03e9qmMlxAePTcpHG3OlkJ/EfHEFiA/lw4dI=; b=eseku+ICPEIm8Q7LtXBvVvoVp855QScMbopjp3ZrJSBD4cL5WqXfIh6u1lvFhm2IIzC6+FtmjDlX6 kZzG3LLtBQkP8Q875QVDpv2yrOWYbcgc1PUT2eUYW4h07pZuf20N7MUwY8x6OQvfkSd7kOuOCNFbXc FH6u4jeSIKDOniXE= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 12 Mar 2014 16:12:21 +1000 (EST) Received: from [10.207.196.3] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 12 Mar 2014 16:13:47 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: Date: Wed, 12 Mar 2014 17:13:37 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/pV6GsjnBa07RiO1s-gEQvFCMW4M Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 06:14:00 -0000 Hi Srinam, Thanks for your questions - let me try and answer them as best I can... > I went through your -01 draft and the SIDR presentation slides from = last week once again,=20 > and have the following questions:=20 >=20 > (1) An update with prefix-origin pair {5.0.0.0/24, AS64511} is = received.=20 > There is a ROA: {5.0.0.0/22, maxLength =3D 24; AS64511} in the RPKI.=20= > However, it is signed using a certificate that is =93valid=94 only for = resource {5.0.0.0/24}. =20 > In this case, is it the intent of your alternate validation model to = ascertain that=20 > the above ROA is partially valid, and accordingly prefix-origin pair = {5.0.0.0/24, AS64511} is =93Valid=94? If I understand your question, you are painting the picture where: The ROA says that AS64511 can announce 5.0.0.0/22 or any subset up to a = /24 The EE cert that signed it has a resource extension of 5.0.0.0/24 (i.e. = the ROA is overclaiming) And the CA that signed it has a resource extension set that encompasses = 5.0.0.0/24 And the CA "above" it has a resources extension that encompasses = 5.0.0.0/24 etc to the trust anchor So if we said "is the UPDATE 5.0.0.0/24 valid" then given that = 5.0.0.0/24 is contained in the ROA, and the same prefix is contained in all the certs from the = EE cert to a TA in an otherwise valid validation path, then the answer would be YES Although I note that the draft did NOT explicitly talk about the = relationship between a ROA and the EE cert that signed it. It only talked about the = treatment of the resource extensions in the pair-wise comparison of certificates in the = validation path. In your question you've extended that same approach to the relationship = between the EE cert that signed the ROA and the ROA. I think that is a consistent = extension, but=20 its a matter that should be further considered. >=20 > (2) Let us say, there is a ROA: {1.0.0.0/24, 2.0.0.0/22, 3.0.0.0/20; = AS64500} in the RPKI.=20 > But this ROA is signed using a certificate that is =93valid=94 only = for resources {1.0.0.0/24, 3.0.0.0/20} > that is a subset of the prefixes listed in the ROA. =20 > In this case, is it the intent of your alternate validation model to = ascertain that=20 > the above ROA is partially valid, and accordingly prefix-origin pairs=20= > {1.0.0.0/24, AS64500} and {3.0.0.0/20, AS64500} are =93Valid=94?=20 In this example you are again painting a picture of a ROA that = "overclaims" as compared to the resources listed in the EE certificate that signed it. Assuming that there are validation paths for 1.0.0.0/24 and 3.0.0.0/24 = between a TA and the EE cert then yes, by the same reasoning as the answer to the previous question I would say = that a consistent answer is that these two updates would be accepted as "valid" (with the same caveat that this is an extension to the described = approach to certificate validation, but an extension that I personally am comfortable with) >=20 > (3) On slide #18, do you need to require =93Certificates 1 through n-1 = are also =93valid=94=20 > according to this same criterion=94? You are not validating them at = this point.=20 > You are only validating Certificate =91n=92 for *a given INR*.=20 > Is it not enough to require that =93the resources in the INR extension = of=20 > Certificate x must subsume the given INR=94 for each x (individually); = x=3D1, 2, 3, =85, n?=20 I was taking the text of RFC3779 that defined the certificate validity = (slide 3) and was illustrating the difference in that text were we to use this approach. I think your = formulation of the text has the same semantic intent as the text on slide 18, but your text highlights the difference = from RFC3779, while I was=20 trying to illustrate what would need to change from the original = validation definition. Either that or I have not understood your question! If so, could you = explain this a bit more? regards, Geoff From nobody Wed Mar 12 03:40:40 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DDC1A094E for ; Wed, 12 Mar 2014 03:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEoey97xzkbw for ; Wed, 12 Mar 2014 03:40:38 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id B0D821A0948 for ; Wed, 12 Mar 2014 03:40:38 -0700 (PDT) Received: from minas-ithil.hactrn.net (unknown [217.41.234.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 5EF7A3995D for ; Wed, 12 Mar 2014 10:40:31 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id D9159B0811A for ; Wed, 12 Mar 2014 11:40:31 +0100 (CET) Date: Wed, 12 Mar 2014 11:40:31 +0100 From: Rob Austein To: sidr@ietf.org In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F694A0956D@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F694A0956D@HSV-MB001.huntsville.ads.sparta.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140312104031.D9159B0811A@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/PriVZIYvhecBIccQzj0-VSpSIVw Subject: Re: [sidr] a new working group draft for RFC6810-bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 10:40:40 -0000 At Tue, 11 Mar 2014 14:31:10 +0000, Murphy, Sandra wrote: > > The chairs appoint Rob Austein and Randy Bush as co-editors of a > draft draft-ietf-sidr-rfc6810-bis-00.txt to revise RFC6810, which > they should submit at their earliest convenience. Uploaded. Posting to drafts repository currently blocked waiting for a WG chair to click button approving this as a WG -00. No changes other than name from draft-austein-rpki-rtr-rfc6810bis-01 (ie, I have not yet addressed the points Matthias raised on Friday). From nobody Wed Mar 12 11:07:47 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E9E1A0757; Wed, 12 Mar 2014 11:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fLQMAgiG_3D; Wed, 12 Mar 2014 11:07:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F30EC1A058E; Wed, 12 Mar 2014 11:07:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140312180741.19241.12099.idtracker@ietfa.amsl.com> Date: Wed, 12 Mar 2014 11:07:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/55zuOLXgxyOefdj0iNZoeInRsVs Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 18:07:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol Authors : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-rfc6810-bis-00.txt Pages : 30 Date : 2014-03-11 Abstract: In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 12 12:07:37 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCAF1A0758 for ; Wed, 12 Mar 2014 12:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06drh-nIAAmp for ; Wed, 12 Mar 2014 12:07:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id D89C21A0365 for ; Wed, 12 Mar 2014 12:07:32 -0700 (PDT) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB008.namprd09.prod.outlook.com (10.255.211.151) with Microsoft SMTP Server (TLS) id 15.0.893.10; Wed, 12 Mar 2014 19:07:19 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.70]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.70]) with mapi id 15.00.0893.001; Wed, 12 Mar 2014 19:07:19 +0000 From: "Sriram, Kotikalapudi" To: Geoff Huston Thread-Topic: Questions about draft-huston-rpki-validation-01 Thread-Index: Ac89eRhd+ibZbQZWQW6u2RB/Km153QAQRwSAABqu5AA= Date: Wed, 12 Mar 2014 19:07:18 +0000 Message-ID: <29aaf7410c27484fa790408f93db4d74@BLUPR09MB053.namprd09.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 01480965DA x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(51914003)(189002)(199002)(13464003)(51444003)(377454003)(33646001)(50986001)(47976001)(74366001)(77096001)(97336001)(74316001)(85852003)(95666003)(56816005)(76576001)(83072002)(49866001)(47446002)(80022001)(87936001)(31966008)(74662001)(74502001)(76786001)(76796001)(97186001)(2656002)(63696002)(94946001)(90146001)(74706001)(87266001)(47736001)(66066001)(4396001)(92566001)(53806001)(65816001)(81342001)(81686001)(46102001)(51856001)(54356001)(80976001)(81816001)(19580395003)(76482001)(19580405001)(81542001)(83322001)(56776001)(69226001)(54316002)(95416001)(93516002)(86362001)(85306002)(59766001)(74876001)(94316002)(79102001)(93136001)(77982001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB008; H:BLUPR09MB053.namprd09.prod.outlook.com; CLIP:129.6.140.100; FPR:9E28DD97.AE029312.32F3EDB7.54E7E958.2047F; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/phr2rgzJAR3Hwb8MaNTa5vcZS3Y Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 19:07:35 -0000 Geoff, Thanks for the reply. Quoting from your responses, > I think that is a >consistent extension, but its a matter that should be further considered. >(with the same caveat that this is an extension to the described approach = to >certificate >validation, but an extension that I personally am comfortable with) Yes, that is right. I think we are in sync on my questions (1) and (2),=20 except that as you've said all this needs further consideration by the WG. For my question (3), we need to delve deeper. Please see my next email. Sriram=20 >-----Original Message----- >From: Geoff Huston [mailto:gih@apnic.net] >Sent: Wednesday, March 12, 2014 2:14 AM >To: Sriram, Kotikalapudi >Cc: George Michaelson; sidr wg list >Subject: Re: Questions about draft-huston-rpki-validation-01 > >Hi Srinam, > >Thanks for your questions - let me try and answer them as best I can... > > >> I went through your -01 draft and the SIDR presentation slides from >> last week once again, and have the following questions: >> >> (1) An update with prefix-origin pair {5.0.0.0/24, AS64511} is received. >> There is a ROA: {5.0.0.0/22, maxLength =3D 24; AS64511} in the RPKI. >> However, it is signed using a certificate that is "valid" only for resou= rce >{5.0.0.0/24}. >> In this case, is it the intent of your alternate validation model to >> ascertain that the above ROA is partially valid, and accordingly prefix-= origin >pair {5.0.0.0/24, AS64511} is "Valid"? > >If I understand your question, you are painting the picture where: > >The ROA says that AS64511 can announce 5.0.0.0/22 or any subset up to a /= 24 > >The EE cert that signed it has a resource extension of 5.0.0.0/24 (i.e. th= e ROA is >overclaiming) > >And the CA that signed it has a resource extension set that encompasses >5.0.0.0/24 > >And the CA "above" it has a resources extension that encompasses 5.0.0.0/2= 4 > >etc to the trust anchor > >So if we said "is the UPDATE 5.0.0.0/24 valid" then given that 5.0.0.0/24 = is >contained in the ROA, and the same prefix is contained in all the certs fr= om the >EE cert to a TA in an otherwise valid validation path, then the answer wou= ld be >YES > >Although I note that the draft did NOT explicitly talk about the relations= hip >between a ROA and the EE cert that signed it. It only talked about the tre= atment >of the resource extensions in the pair-wise comparison of certificates in = the >validation path. >In your question you've extended that same approach to the relationship >between the EE cert that signed the ROA and the ROA. I think that is a >consistent extension, but its a matter that should be further considered. > > >> >> (2) Let us say, there is a ROA: {1.0.0.0/24, 2.0.0.0/22, 3.0.0.0/20; AS6= 4500} in >the RPKI. >> But this ROA is signed using a certificate that is "valid" only for reso= urces >{1.0.0.0/24, 3.0.0.0/20} >> that is a subset of the prefixes listed in the ROA. >> In this case, is it the intent of your alternate validation model to asc= ertain that >> the above ROA is partially valid, and accordingly prefix-origin pairs >> {1.0.0.0/24, AS64500} and {3.0.0.0/20, AS64500} are "Valid"? > > >In this example you are again painting a picture of a ROA that "overclaims= " as >compared to the resources >listed in the EE certificate that signed it. > >Assuming that there are validation paths for 1.0.0.0/24 and 3.0.0.0/24 bet= ween >a TA and the EE cert then yes, >by the same reasoning as the answer to the previous question I would say t= hat a >consistent answer >is that these two updates would be accepted as "valid" > >(with the same caveat that this is an extension to the described approach = to >certificate >validation, but an extension that I personally am comfortable with) > > > > >> >> (3) On slide #18, do you need to require "Certificates 1 through n-1 are= also >"valid" >> according to this same criterion"? You are not validating them at this = point. >> You are only validating Certificate 'n' for *a given INR*. >> Is it not enough to require that "the resources in the INR extension of >> Certificate x must subsume the given INR" for each x (individually); x= =3D1, 2, 3, >..., n? > > >I was taking the text of RFC3779 that defined the certificate validity (sl= ide 3) and >was illustrating >the difference in that text were we to use this approach. I think your for= mulation >of the text has the same semantic >intent as the text on slide 18, but your text highlights the difference fr= om >RFC3779, while I was >trying to illustrate what would need to change from the original validatio= n >definition. > >Either that or I have not understood your question! If so, could you expla= in this a >bit more? > >regards, > > Geoff From nobody Wed Mar 12 13:17:34 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B081A0496 for ; Wed, 12 Mar 2014 13:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI_CT2T7r4mL for ; Wed, 12 Mar 2014 13:17:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn14138.inbound.protection.outlook.com [207.46.163.138]) by ietfa.amsl.com (Postfix) with ESMTP id 9035B1A068F for ; Wed, 12 Mar 2014 13:17:20 -0700 (PDT) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB006.namprd09.prod.outlook.com (10.255.211.149) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 12 Mar 2014 20:17:13 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.70]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.70]) with mapi id 15.00.0893.001; Wed, 12 Mar 2014 20:17:12 +0000 From: "Sriram, Kotikalapudi" To: Geoff Huston Thread-Topic: Questions about draft-huston-rpki-validation-01 Thread-Index: Ac89eRhd+ibZbQZWQW6u2RB/Km153QAQRwSAABsPsLA= Date: Wed, 12 Mar 2014 20:17:11 +0000 Message-ID: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 01480965DA x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(76576001)(77982001)(77096001)(66066001)(46102001)(59766001)(74876001)(76796001)(76786001)(69226001)(79102001)(561944002)(74706001)(20776003)(65816001)(63696002)(80022001)(54316002)(51856001)(87266001)(2656002)(53806001)(54356001)(56776001)(49866001)(47976001)(50986001)(74316001)(47736001)(33646001)(95416001)(4396001)(76482001)(94316002)(90146001)(85852003)(87936001)(92566001)(86362001)(93516002)(93136001)(83072002)(94946001)(56816005)(74502001)(74662001)(81816001)(85306002)(97186001)(95666003)(97336001)(31966008)(47446002)(81542001)(81342001)(80976001)(74366001)(83322001)(81686001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB006; H:BLUPR09MB053.namprd09.prod.outlook.com; FPR:7F05B15E.9DF617ED.B2CF7F47.8AEA914E.2037B; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/3iHQn11go8nsP3EBA8F8iSoH6ns Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 20:17:27 -0000 Geoff, About my Question (3), let us discuss this a bit more carefully with an exa= mple. There is this ROA: {10.0.0.0/24, AS64499} that we wish to validate. It is signed with Certificate 3, which has the following certificate path t= o the TA:=20 Certificate 1: It lists {10.0.0.0/12, AS64501, AS64505, AS64509} (TA certi= ficate) Certificate 2: It lists {10.0.0.0/22, AS64501, AS64505, AS64511} Certificate 3: It lists {10.0.0.0/20, AS64501, AS64505} Note: Certificate 1 is the TA certificate. It is clear that following the current (RFC 3779) method,=20 Certificates 2 and 3 are invalid, and it follows that the ROA is invalid. Now, there are two methods that we may enumerate for a modified (or alterna= te)=20 validation proposal: Method A (more conservative but less robust relative to Method B below):=20 Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3= . =20 Step 2: Do the resources in Certificate 3 subsume the prefix in the ROA? A= nswer: YES,=20 because "the INR of interest" 10.0.0.0/24 in the ROA is subsumed by=20 an INR 10.0.0.0/20 in Certificate 3. OK, now proceed to validate Certificat= e 3.=20 Note that "the INR of interest" in Certificate 3 is 10.0.0.0/20. =20 Step 3: Ask if the resources in Certificate 2 subsume "the INR of interest"= in Certificate 3?=20 Answer: NO, because "the INR of interest" 10.0.0.0/20 in Certificate 3 is N= OT subsumed=20 by an INR in the parent Certificate 2. =20 (Note: The parent Certificate 2 has a more specific prefix 10.0.0.0/22.) Step 4: Since the certificate chain "validation" failed at Step 3, declare = the ROA=20 being considered as "Invalid" for the prefix-origin pair {10.0.0.0/24, AS64= 499} . Method B (less conservative but more robust relative to Method A above): Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3= . =20 Step 2: Set "the given INR" as 10.0.0.0/24. That is the INR in the ROA for = which=20 validation is being sought.=20 [Note: "The given INR" remains a constant in the steps that follow. =20 We just *stay focused on this given INR* for the rest of the validation pro= cess below.=20 This is the main difference compared to method A.] =20 Step 3: Do the resources in Certificate 3 subsume the "the given INR" 10.0.= 0.0/24?=20 Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.0.= 0/20 in Certificate 3.=20 Step 4: Do the resources in Certificate 2 subsume the "the given INR" 10.0.= 0.0/24?=20 Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.0.= 0/22 in Certificate 2. Step 5: Do the resources in Certificate 1 subsume the "the given INR" 10.0.= 0.0/24?=20 Answer: YES, because the given INR 10.0.0.0/24 is subsumed by an INR 10.0.0= .0/12 in Certificate 1. Step 6: Since the certificate chain "validation" passed at each step above= =20 for "the given INR" 10.0.0.0/24, declare the ROA being considered=20 as "Valid" for the prefix-origin pair {10.0.0.0/24, AS64499} . =20 So Method A produces an "Invalid" result for the ROA,=20 whereas Method B yields a "Valid" result. I hope the difference between Methods A and B is clear.=20 In Method A, "the INR of interest" at level x must be subsumed by an INR at= level x+1.=20 But in Method B, only "the given INR" (e.g., a prefix in a ROA or an ASN in= a router certificate)=20 is the steady focus, and what is required is that "the given INR" must be s= ubsumed=20 by resources listed in the certificate at each level (1, 2, 3, ..., n). The description on your Slide #18 falls short of describing precisely=20 either Method A or Method B. From your Slide #14, it seems evident that you= are=20 proposing Method B; am I right?=20 (In terms of language and clarity, the notion of calling a certificate "val= id"=20 is misleading when in fact all that is being checked is merely=20 whether a given INR is subsumed in it.) =20 Sriram From nobody Wed Mar 12 14:35:21 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961511A0764 for ; Wed, 12 Mar 2014 14:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUtaU59acrA4 for ; Wed, 12 Mar 2014 14:35:18 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id CFB521A0761 for ; Wed, 12 Mar 2014 14:35: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 s2CLURQB019679; Wed, 12 Mar 2014 16:35:11 -0500 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jjxvk07g5-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 12 Mar 2014 16:35:06 -0500 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s2CLYqIh021753; Wed, 12 Mar 2014 17:34:52 -0400 Received: from HSV-CAS003.huntsville.ads.sparta.com ([10.62.8.138]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s2CLYg6q007553; Wed, 12 Mar 2014 17:34:53 -0400 Received: from KRAVEN.huntsville.ads.sparta.com (10.62.8.137) by HSV-CAS003.huntsville.ads.sparta.com (10.62.8.138) with Microsoft SMTP Server (TLS) id 14.2.347.0; Wed, 12 Mar 2014 13:10:01 -0500 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by kraven.huntsville.ads.sparta.com ([::1]) with mapi id 14.02.0342.003; Wed, 12 Mar 2014 13:10:02 -0500 From: "Murphy, Sandra" To: Rob Austein , "sidr@ietf.org" Thread-Topic: [sidr] a new working group draft for RFC6810-bis Thread-Index: Ac89Nov828ahrEa1TpWBZvDPkDBaegA0tpiAAAUn+oU= Date: Wed, 12 Mar 2014 18:10:02 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A09B29@HSV-MB001.huntsville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F694A0956D@HSV-MB001.huntsville.ads.sparta.com>, <20140312104031.D9159B0811A@minas-ithil.hactrn.net> In-Reply-To: <20140312104031.D9159B0811A@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.33] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-12_07:2014-03-12,2014-03-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=53.6324152728553 compositescore=0.0810740488552347 urlsuspect_oldscore=0.998747677773289 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=12 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0810740488552347 spamscore=0 recipient_to_sender_domain_totalscore=14 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403120129 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/qLJSlPt2KakZD4xxjSsPH5Xzy_g Subject: Re: [sidr] a new working group draft for RFC6810-bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 21:35:20 -0000 Chair approval done.=0A= =0A= (Delay was due to lack of Internet during travel.)=0A= =0A= --Sandy=0A= =0A= =0A= ________________________________________=0A= From: sidr [sidr-bounces@ietf.org] on behalf of Rob Austein [sra@hactrn.net= ]=0A= Sent: Wednesday, March 12, 2014 6:40 AM=0A= To: sidr@ietf.org=0A= Subject: Re: [sidr] a new working group draft for RFC6810-bis=0A= =0A= At Tue, 11 Mar 2014 14:31:10 +0000, Murphy, Sandra wrote:=0A= >=0A= > The chairs appoint Rob Austein and Randy Bush as co-editors of a=0A= > draft draft-ietf-sidr-rfc6810-bis-00.txt to revise RFC6810, which=0A= > they should submit at their earliest convenience.=0A= =0A= Uploaded. Posting to drafts repository currently blocked waiting for=0A= a WG chair to click button approving this as a WG -00.=0A= =0A= No changes other than name from draft-austein-rpki-rtr-rfc6810bis-01=0A= (ie, I have not yet addressed the points Matthias raised on Friday).=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From nobody Thu Mar 13 10:24:05 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695361A0A39 for ; Thu, 13 Mar 2014 10:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip84gzpCpXds for ; Thu, 13 Mar 2014 10:24:02 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 624681A0A36 for ; Thu, 13 Mar 2014 10:24:02 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s2DHMsvd005534 for ; Thu, 13 Mar 2014 12:23:55 -0500 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jkfm3gk5x-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Mar 2014 12:23:52 -0500 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s2DHNndc027848 for ; Thu, 13 Mar 2014 13:23:49 -0400 Received: from HSV-CAS004.huntsville.ads.sparta.com ([10.62.8.148]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s2DHNna3013210 for ; Thu, 13 Mar 2014 13:23:49 -0400 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS004.huntsville.ads.sparta.com ([fe80::d00f:c039:2622:2252%11]) with mapi id 14.02.0387.000; Thu, 13 Mar 2014 12:23:46 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes for IETF89 Thread-Index: Ac8+4OLebFu2GEkVQbW8G5fDhfEmcw== Date: Thu, 13 Mar 2014 17:23:46 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A09D2B@HSV-MB001.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.33] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-13_07:2014-03-13,2014-03-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=230.336 compositescore=0.0999698076309413 urlsuspect_oldscore=0.999698076309413 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=4.30879226475112e-05 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0999698076309413 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403130092 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/-_OD1yUFMrVmj5la_ia_6WKfGX8 Subject: [sidr] minutes for IETF89 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:24:04 -0000 Matt Lepinski took minutes for the SIDR session in the IETF etherpad.=0A= =0A= I've uploaded a copy to the meeting materials site. http://www.ietf.org/pr= oceedings/89/minutes/minutes-89-sidr=0A= =0A= The etherpad site (temporary) is http://etherpad.tools.ietf.org:9000/p/note= s-ietf-89-sidr?useMonospaceFont=3Dtrue=0A= =0A= Below is the text of those minutes. =0A= =0A= Please review and send any corrections or additions to the list.=0A= =0A= --Sandy, speaking as one of the wg co-chairs=0A= =0A= =0A= SIDR Meeting at IETF 89=0A= March 4, 2014=0A= 9:00am UTC=0A= =0A= Chair Slides: http://www.ietf.org/proceedings/89/slides/slides-89-sidr-7.pd= f=0A= =0A= Chris Marrow (Chair) will work with the authors on the mailing list to reso= lve the one outstanding issue in the requirments document.=0A= draft-ietf-sidr-bgpsec-reqs-09 =0A= =0A= -------------- =0A= RFC 6490bis - Geoff Huston : http://www.ietf.org/proceedings/89/slides/slid= es-89-sidr-2.pdf=0A= =0A= Rob Austein: It would be nice if there was an easy way to find the delimite= r between the URIs and the Public Key=0A= Also, it would be nice to keep this simple. I would like not to hav= e to include a JSON library just to parse the TAL file=0A= =0A= Geoff Huston: Will look into whether carriage return characters can appear = in the public key=0A= If there can be a carriage return in the public key, Geoff will put= in the blank line delimiter=0A= =0A= Sandy: Are we just dealing with the one issue (multiple publication) or whe= n we re-opened this document, was the working group's intention that =0A= =0A= Rob A: If we are going to change the document, let's make the smallest chan= ge possible to address the issue (multiple publication) =0A= =0A= Tim B: It is not important to me that we use JSON. I think JSON is a good i= dea and it is well-defined, but I don't want to hold anything up=0A= =0A= Randy: Isn't Klingon as well-defined as JSON?=0A= Wes: No, but it is easier to understand=0A= =0A= Sandy: The Working Group Chairs see a high bar for accepting any changes ot= her than the muliple URI change =0A= =0A= ----------------=0A= George Michaelson - OID issue in RF6485 : http://www.ietf.org/proceedings/8= 9/slides/slides-89-sidr-5.pdf=0A= =0A= This errata is actually a change to base document=0A= =0A= Stewert AD: We are not allowed to make any technical change through the Err= ata process=0A= ... spin a new RFC if there is any doubt=0A= ... please include a note to be removed by the RFC Editor=0A= Make it clear what the change is and why this change is being made= =0A= =0A= =0A= --------------=0A= Rob Austein - No Slides=0A= =0A= The current draft for BGPSEC router certificates requires there be only one= AS in the Router Certificate=0A= =0A= Steve Kent: As an author, we can fix this=0A= =0A= Matt L: It may be helpful to have cautionary text in bgpsec-ops telling peo= ple not to use multiple keys for a router that happens to be in multiple AS= es.=0A= Fixing the router certificate draft is important, but even with the = change bad/dangerous behaivor would be permissible.=0A= =0A= Jeff H: Wes and Sandy's document on AS Migration might be relevant here. We= want to make sure whatever we recommend for router certificates is consist= ent with AS migration scenarios=0A= =0A= ------------=0A= Randy Bush : Use Cases - No Slides=0A= =0A= Randy Bush: I know Steve Kent has issues with the prose. Does anyone have i= ssues with the semantics=0A= =0A= Steve Kent: I will provide suggested text to improve the prose. =0A= =0A= Randy Bush: Note: If you swallow this pill then proposals to change the wor= ld will need to address these three use-cases=0A= =0A= ------------=0A= Geoff Huston : RPKI Validation - http://www.ietf.org/proceedings/89/slides/= slides-89-sidr-3.pdf=0A= draft-huston-rpki-validation=0A= =0A= Randy: This doesn't have an Internet draft? =0A= Geoff: There is now an Internet draft=0A= =0A= Randy and Geoff talk past each other regarding whether this proposal is top= -down and bottom-up=0A= =0A= Rob Austein: I am not concerned about the responsibility that RIRs have to = do the job that they are paid to do=0A= I am concerned about caching/timing issues. I am somewhat =0A= If we go forward, we need a new OID for a new certificate extensio= n that is not RFC 3779 but is like 3779=0A= We would not want to implement this in the core of OpenSSL=0A= However, I think that joins in the tree are not as easy as you mak= e them out to be.=0A= Getting the issuer names to match is probably doable with X.509 = games, but it isn't easy=0A= =0A= Doug Montegomery made a point that was missed by the minute taker = =0A= Claim: If we go down this path we won't be able to understand the RP= KI by looking at=0A= Geoff: We didn't have this to begin with in the PKI model because every= thing we have in a PKI is relative to the Trust Anchors that you happen to = trust=0A= =0A= David Mandelberg: On Slide 15, Geoff doesn't mean "Local Trust Anchor" in t= he LTA sense of other SIDR documents.=0A= =0A= David is concerned that adding joins makes things a lot more co= mplicated (at least for the people doing the validation)=0A= =0A= Steve Bellovin: I am concerned that I don't understand the formal semantics= of this evaluation you are proposing=0A= When we move from a tree to a graph, I am concerned that the co= nsistency proof isn't obvious=0A= =0A= Geoff: The semantics are equivalent to if we had a separate tree for each a= ddress and for each AS number=0A= =0A= Rob Astein: "Twitch ... Joins ... Twitch"=0A= =0A= Tim B: It might be useful to consider the two cases separately -- where you= have no joins, and where you do have joins=0A= I think the former issue need not be that hard to implement (although a= s Rob said maybe we need a new OID)=0A= I like that the tree structure allows me to validate in paralell withou= t one branch affecting another =0A= =0A= Geoff: The paralellization isn't a major issue. I can give you pseudo-code = =0A= =0A= Steve Kent: There are a lot of problems with the joins.=0A= Key roll-over won't work smoothly in the event of a join=0A= What you propose is a MAJOR change to validation=0A= I am sympathetic to the issues you raise=0A= But I think the joins are a foundamentally flawed idea and then = we can discuss whether there is a way to address the other issues you raise= =0A= =0A= Warren Kumari: Doesn't it make sense for the guy at the bottom to just clai= m 0/0 and all AS number?=0A= Geoff: An issuer should never issue for 0/0=0A= =0A= Carlos Martinez (Lacnic): I think (like Tim) that there are two use-cases t= hat should be addressed separately=0A= When I explain the technology to new people, new people imagine that th= ings currently work with the relaxed rules that Geoff is proposing [1st use= -case]=0A= =0A= ------------=0A= David Mandelberg : SLURM - http://www.ietf.org/proceedings/89/slides/slides= -89-sidr-0.pdf=0A= =0A= Tim B: We have a web interface for ignoring particular resources=0A= It would be great to have a standard way of doing/configuring this=0A= =0A= Rob A: This misses some shared central configuration=0A= In this you need to distribute SLURM files, you can't just point your= validator at someone you trust=0A= This isn't bad=0A= =0A= Randy: This doesn't solve Alice and carol's case=0A= We should think about about how to solve the whole problem (all three= use-cases)=0A= =0A= Discussion with Jeff and Chris about whether the draft needs both del and a= dd statements. Would there ever be a del without an add?=0A= =0A= Wes George: Why are we coming up with new and interesting ways to poke hole= s and not trust the system?=0A= Won't people just use this do to kinky things? If we insert this = work-around for the system, at what point do we just decide that implementi= ng RPKI isn't worth the overhead=0A= =0A= ----------=0A= David Mandelberg: TAO - http://www.ietf.org/proceedings/89/slides/slides-89= -sidr-1.pdf=0A= =0A= Rob A: What if Eve doesn't exist?=0A= =0A= Randy: We are missing (from the 2007 discussion) the agreement that the ext= ernalities have been met=0A= Requiring that the externalities have been met requries Eve existing= and getting the resources=0A= Reference to "torn Euro" protocol=0A= =0A= Steve K: This is an automation of the update of the RPKI data for a transfe= r=0A= It is not a replacement for existing procedures/contractual arrang= ements=0A= Carol can issue a trivial resource to Eve to put her into the syst= em =0A= (e.g., give Eve a /32 and take it back after this is all done)=0A= =0A= Byron [Jabber]: SKI is not identity=0A= ... this needs clarification, will take to the list=0A= =0A= Tim B: I think these are valid goals. =0A= But this seems to add complexity to provisioning=0A= Maybe this can just be solved informally and doesn't require a new st= andard=0A= But I need to read this draft fully=0A= =0A= ----------=0A= George Michaelson : Rsync Harmful - http://www.ietf.org/proceedings/89/slid= es/slides-89-sidr-8.pdf=0A= =0A= Note: Much of this presentation was given in a different context on Sunday = at IEPG=0A= =0A= Note: When George's slides refer to East Coast and West Coast he is referri= ng to North America. (As opposed to, say, the East and West Coast of Japan = or Australia)=0A= =0A= Rob A: I have been viewing Rsync as phase 1=0A= I imagine at some point we will need to do something else=0A= I like this presentation, but it doesn't change my opinion=0A= I really don't recommend running as root. (Our software does not make= it easy to run Rsync as root)=0A= =0A= Tim B: I think it is an important design decision to have validators sepera= te from routers=0A= I don't think sending the RPKI data in BGP is a good idea=0A= I have some other ideas for replacing Rsync, which I will bring up a= gain if appropriate.=0A= =0A= Randy: Thanks for doing this work=0A= However, for the time being, Please follow RFC 7115. (Recommendation= with regard to directory system) =0A= =0A= -----------=0A= Fabian Mejia : RPKI Experience in Ecudor - http://www.ietf.org/proceedings/= 89/slides/slides-89-sidr-4.pdf=0A= =0A= Volk: Is there use in actual routing in Ecudor?=0A= =0A= Ans: On March 15, invalid routes will be dropped at the IXP=0A= (Currently just monitored)=0A= From nobody Sun Mar 16 16:40:45 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1E61A023A for ; Sun, 16 Mar 2014 16:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.815 X-Spam-Level: * X-Spam-Status: No, score=1.815 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEA3gSxZZfNa for ; Sun, 16 Mar 2014 16:40:42 -0700 (PDT) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id F3A5C1A01F1 for ; Sun, 16 Mar 2014 16:40:41 -0700 (PDT) Envelope-to: sidr@ietf.org Received: from g231108200.adsl.alicedsl.de ([92.231.108.200] helo=mw-PC.fritz.box) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WPKfQ-000DjF-L8; Mon, 17 Mar 2014 00:40:32 +0100 Date: Mon, 17 Mar 2014 00:40:30 +0100 From: Matthias Waehlisch To: Rob Austein In-Reply-To: <20140309101809.B5A23B02C27@minas-ithil.hactrn.net> Message-ID: References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> <20140309101809.B5A23B02C27@minas-ithil.hactrn.net> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/e-oAmrpUGmchiQIwaYQGrpnAaRw Cc: sidr@ietf.org Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 23:40:44 -0000 Sorry for the late reply ... On Sun, 9 Mar 2014, Rob Austein wrote: > > What happens if the ASNs are not in order (for some strange bug > > reason)? It wouldn't harm the router? > > Point. So maybe caches MUST generate the canonical format but routers > MAY skip checking to see whether the cache goofed this up? > Sounds good. > > > Given that the rpki-rtr protocol requires duplicate elimination, we do > > > need to perform such comparisons, so making them as simple as possible > > > seems advisable. > > > > > I suppose this requires an update of the duplicate description > > (similar text of Section 5.6 in Section 5.10, and update Section 11, no > > 11). > > Or consolidate the discussion of duplicate PDUs somewhere else in the > document, but yes, we need to nail that down. > I'm more in favor of consolidating. Just to double check, because the term "duplicate" is not very clear in this context - at least to me. In contrast to RFC 6810, in RFC 6810-bis a Router Key PDU contains a list of ASNs. The received PDU may differ even though parts of the content are duplicates. RFC 6810 says "identical to one it already has active", which means that we are checking pieces of content. For example, the router receives Router Key PDU with ASNs {10,20,30} and later the 'same' PDU but with ASNs {10,20}. I would consider this as a duplicate. However, in this case the ordering doesn't help to apply binary string comparison. Thanks matthias From nobody Sun Mar 16 18:15:21 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6D61A0340 for ; Sun, 16 Mar 2014 18:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z64kz-55jAWD for ; Sun, 16 Mar 2014 18:15:15 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 657191A033C for ; Sun, 16 Mar 2014 18:15:15 -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=n+8xGszjokIFk3TijGHaB4rB6fbgkr0lOYliD+Fi61Q=; b=hBIom3qXW+yrMDrtc9WeNC4vt80QNPu68PtlAy3fzQri57yB5F/I50PbA+/8oN9C/oWMNKT4Zu5vf t70vXxMmNpgAEh+Eo8r0cgt3I3lIRo907P4KeGiFIp7i5a3OKmix+pGVyfZNQKOktP8g6pPZckPG0B DXitsEOnTshszam4= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Mon, 17 Mar 2014 20:24:58 +1000 (EST) Received: from robewin.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; Mon, 17 Mar 2014 11:15:04 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> Date: Mon, 17 Mar 2014 12:15:03 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/obSnxy4Jhvk5wUHMSsPjqqjqRfY Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:15:19 -0000 Hi Sriram, I am espousing method B in your terminology. Perhaps if I rephrase the validation question a little, it may be a = little clearer. The validation question is: Given a certificate X and a TA certificate, = for what resources is this certificate "valid"? You point out > (In terms of language and clarity, the notion of calling a certificate = "valid"=20 > is misleading when in fact all that is being checked is merely=20 > whether a given INR is subsumed in it.) =20 Maybe there is a way of tightening this up. How about: A resource = contained in the resource extension of a certificate is defined as = "valid" if this resource is listed in the resource extension field of = all certificates that are contained in a certification path, where the = construction of this certification path is defined in section 6 of = RFC5280. Back you your example...So the question posted by the ROA, which is = signed by certificate 3, is "Is certificate 3 valid for 10.0.0.0/24?" As you've described here the certification path is Cert 1, Cert 2, and = Cert 3, and as 10.0.0.0/24 is contained in the resource extension of all = of these certificates then it can be concluded that the question posed = by the ROA, namely whether certificate 3 is valid for 10.0.0.0/24, can = be answered in the affirmative. (In the WG I also considered a slightly expanded question: Given a = certificate X and a set of TA certificates, for what resources is this = certificate "valid"?, but that proved to be a little more controversial = for many!) regards, Geoff On 13 Mar 2014, at 7:17 am, Sriram, Kotikalapudi = wrote: > Geoff, >=20 > About my Question (3), let us discuss this a bit more carefully with = an example. >=20 > There is this ROA: {10.0.0.0/24, AS64499} that we wish to validate. > It is signed with Certificate 3, which has the following certificate = path to the TA:=20 > Certificate 1: It lists {10.0.0.0/12, AS64501, AS64505, AS64509} (TA = certificate) > Certificate 2: It lists {10.0.0.0/22, AS64501, AS64505, AS64511} > Certificate 3: It lists {10.0.0.0/20, AS64501, AS64505} > Note: Certificate 1 is the TA certificate. >=20 > It is clear that following the current (RFC 3779) method,=20 > Certificates 2 and 3 are invalid, and it follows that the ROA is = invalid. >=20 > Now, there are two methods that we may enumerate for a modified (or = alternate)=20 > validation proposal: >=20 > Method A (more conservative but less robust relative to Method B = below):=20 >=20 > Step 1: Ask what certificate is used to sign the RAO? Answer: = Certificate 3. >=20 > Step 2: Do the resources in Certificate 3 subsume the prefix in the = ROA? Answer: YES,=20 > because "the INR of interest" 10.0.0.0/24 in the ROA is subsumed by=20 > an INR 10.0.0.0/20 in Certificate 3. OK, now proceed to validate = Certificate 3.=20 > Note that "the INR of interest" in Certificate 3 is 10.0.0.0/20. >=20 > Step 3: Ask if the resources in Certificate 2 subsume "the INR of = interest" in Certificate 3?=20 > Answer: NO, because "the INR of interest" 10.0.0.0/20 in Certificate 3 = is NOT subsumed=20 > by an INR in the parent Certificate 2. =20 > (Note: The parent Certificate 2 has a more specific prefix = 10.0.0.0/22.) >=20 > Step 4: Since the certificate chain "validation" failed at Step 3, = declare the ROA=20 > being considered as "Invalid" for the prefix-origin pair {10.0.0.0/24, = AS64499} . >=20 > Method B (less conservative but more robust relative to Method A = above): >=20 > Step 1: Ask what certificate is used to sign the RAO? Answer: = Certificate 3. >=20 > Step 2: Set "the given INR" as 10.0.0.0/24. That is the INR in the ROA = for which=20 > validation is being sought.=20 > [Note: "The given INR" remains a constant in the steps that follow. =20= > We just *stay focused on this given INR* for the rest of the = validation process below.=20 > This is the main difference compared to method A.] >=20 > Step 3: Do the resources in Certificate 3 subsume the "the given INR" = 10.0.0.0/24?=20 > Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR = 10.0.0.0/20 in Certificate 3.=20 >=20 > Step 4: Do the resources in Certificate 2 subsume the "the given INR" = 10.0.0.0/24?=20 > Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR = 10.0.0.0/22 in Certificate 2. >=20 > Step 5: Do the resources in Certificate 1 subsume the "the given INR" = 10.0.0.0/24?=20 > Answer: YES, because the given INR 10.0.0.0/24 is subsumed by an INR = 10.0.0.0/12 in Certificate 1. >=20 > Step 6: Since the certificate chain "validation" passed at each step = above=20 > for "the given INR" 10.0.0.0/24, declare the ROA being considered=20 > as "Valid" for the prefix-origin pair {10.0.0.0/24, AS64499} . =20 >=20 > So Method A produces an "Invalid" result for the ROA,=20 > whereas Method B yields a "Valid" result. > I hope the difference between Methods A and B is clear.=20 > In Method A, "the INR of interest" at level x must be subsumed by an = INR at level x+1.=20 > But in Method B, only "the given INR" (e.g., a prefix in a ROA or an = ASN in a router certificate)=20 > is the steady focus, and what is required is that "the given INR" must = be subsumed=20 > by resources listed in the certificate at each level (1, 2, 3, ..., = n). >=20 > The description on your Slide #18 falls short of describing precisely=20= > either Method A or Method B. =46rom your Slide #14, it seems evident = that you are=20 > proposing Method B; am I right?=20 > (In terms of language and clarity, the notion of calling a certificate = "valid"=20 > is misleading when in fact all that is being checked is merely=20 > whether a given INR is subsumed in it.) =20 >=20 > Sriram >=20 >=20 From nobody Mon Mar 17 08:51:23 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8467E1A01BE for ; Mon, 17 Mar 2014 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9Hlhqg-wDz7 for ; Mon, 17 Mar 2014 08:51:11 -0700 (PDT) Received: from nm2-vm2.access.bullet.mail.gq1.yahoo.com (nm2-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.30]) by ietfa.amsl.com (Postfix) with ESMTP id CF1101A042F for ; Mon, 17 Mar 2014 08:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1395071462; bh=F2TGnBoOHeSoyX0VCijV1GWZFiXYSjn+yiijYLu73TM=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Received:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To:Subject:In-Reply-To:References:Message-ID:X-Sender:User-Agent; b=SKK8cG4oyFRqJJTFw23VQP/Qb+rBUA3u6qzcbIfpcqtbAM0ngjPyawXWwUoARSFWyvPwkj1D1bDhg9rb7/YZ68vTxf/7lJfm00Gky6sRb+vPbTwQoJ0My38lSmXmmP4Y3udScZPkYWBxLkWfG1iOkVBU+qtNZY1GyDEoFc2EHys= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=R/4qamXQY5weWZclLE9WjVlm5QxHgqd8mieo/mDYq47H/LMGsm8q2wB3TWz6mRG6+RzAm19atcWGA2a+t6BDC6L4o+Xs3H1ZyfsMuARkneK2LkhdvHgVftvQO/x6EYX/+iiwHoI2i4jqibwGRCEfNpXQTzPiQDz0x/XbPj9rltI=; Received: from [216.39.60.168] by nm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Mar 2014 15:51:02 -0000 Received: from [98.138.226.244] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 17 Mar 2014 15:51:02 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 17 Mar 2014 15:51:01 -0000 X-Yahoo-Newman-Id: 936686.50011.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: TJme6TIVM1mA78U5Wb32eLxgRFmfDCmDfemy1xph4DYn2Db 93iIxqgffdvT4Mopem0AEYb.6UUYzMqoksVVrMgyL09HYHbs8Qm6jpM0k6Hd Ul0elKs4INoKwwUL0tYQ1qRYpb5Eq1M2okqS.ckG96UWhzMro2sEj2vU75Iz 9pgO1j40.Q31wwJvi5S_H.jNIpe1iJStk3bTqsxxc2zpd4ZdPg6Q1I5yCVzj vC8knx6GJdvWdaeciPn8FzHFAzwfn3Kl.kg0mmLg0PBraMoGIkFQrNPmVrw8 Tpo2E9Rgs3swNyCklq2jOkCsQipaNjjd6ZaFm.KC6VTxAjDq2QMs6wRp.ZBs ZDdFakqrytrfbz8KZHYcXlsIa_X0tSLH4_igkm8L68RISR5zTjPS8a6MFYSc 8ZgrKwO_NEXsKULSRbZH8_.A4ffB7B7sKezCVSPffeXFtEKd5Es4cE_io4PK VCtp0_N1shw5ILorykz3hEbiO3HRANOGAGhNyCeug8KJOpvrr2cFmdOrodsb RSDn_TJCb9nhhE2FocR3vGsimqJgjUgoseSZqElcaWoyvx9pQZQ9MeS2n4rm oDdB0RehsKhV_Hw2hLq0bymYH.ExJ3jGG_2DmeO5qWbDU_Wrj8N4HLUBXyJl uZRoavxMTiuxn71gVkuxXimsr X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- X-Rocket-Received: from uriel.mandelberg.org (david@67.189.168.202 with plain [98.138.84.52]) by smtp115.sbc.mail.ne1.yahoo.com with SMTP; 17 Mar 2014 15:51:01 +0000 UTC Received: from secure.mandelberg.org (unknown [10.1.2.3]) by uriel.mandelberg.org (Postfix) with ESMTP id 44AC71C6051 for ; Mon, 17 Mar 2014 11:51:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2014 11:51:00 -0400 From: David Mandelberg To: In-Reply-To: <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/FTdgy0FqvE2U9kK7RfrvRsKNUEE Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 15:51:15 -0000 On 2014-03-07 06:39, Rob Austein wrote: > David can speak for himself, but speaking on my own behalf as a > implementer: if we define a canonical order, comparing two PDUs is a > simple binary string comparison. If we don't define a canonical > order, comparison is more complicated, hence more error-prone. Given > that the rpki-rtr protocol requires duplicate elimination, we do need > to perform such comparisons, so making them as simple as possible > seems advisable. I fully agree with the above. > FWIW, I think David's suggestion is a good one, and I'm likely to > implement it that way in my server whether required to do so or not. I'll probably also implement it that way. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Mon Mar 17 16:21:46 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360421A01E3 for ; Mon, 17 Mar 2014 16:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaUy4Wt55TPJ for ; Mon, 17 Mar 2014 16:21:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0B51A044B for ; Mon, 17 Mar 2014 16:21:41 -0700 (PDT) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 17 Mar 2014 23:21:31 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.12]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.43]) with mapi id 15.00.0898.005; Mon, 17 Mar 2014 23:21:31 +0000 From: "Sriram, Kotikalapudi" To: Geoff Huston Thread-Topic: Questions about draft-huston-rpki-validation-01 Thread-Index: Ac89eRhd+ibZbQZWQW6u2RB/Km153QAQRwSAABsPsLAA1ffwgAAtxyld Date: Mon, 17 Mar 2014 23:21:30 +0000 Message-ID: <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com>, <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> In-Reply-To: <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.222.35] x-forefront-prvs: 0153A8321A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(24454002)(377454003)(189002)(199002)(76482001)(54316002)(20776003)(94316002)(56776001)(74706001)(83072002)(66066001)(86362001)(65816001)(33646001)(95666003)(51856001)(79102001)(74316001)(81542001)(4396001)(63696002)(81816001)(69226001)(74662001)(81686001)(80022001)(47446002)(85852003)(31966008)(93136001)(49866001)(93516002)(47736001)(59766001)(77982001)(56816005)(92566001)(90146001)(74502001)(74876001)(94946001)(19580395003)(19580405001)(83322001)(76576001)(80976001)(46102001)(2656002)(47976001)(87266001)(87936001)(81342001)(95416001)(53806001)(54356001)(97336001)(76786001)(74366001)(97186001)(76796001)(77096001)(561944002)(85306002)(50986001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB053; H:BLUPR09MB053.namprd09.prod.outlook.com; FPR:6FC1F2DF.9EF297ED.B2CF5C47.9AE6A17E.20548; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ilYmz5n_isIuVXATJ9I-BD2TXAw Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 23:21:44 -0000 Geoff,=0A= =0A= Thanks. Comments inline.=0A= =0A= >Hi Sriram,=0A= =0A= >I am espousing method B in your terminology.=0A= =0A= Yes, I thought so. I also think method B should be preferable over method A= , =0A= if we do go down this path. =0A= =0A= >Perhaps if I rephrase the validation question a little, =0A= >it may be a little clearer.=0A= =0A= >The validation question is: Given a certificate X and a TA certificate, = =0A= >for what resources is this certificate "valid"?=0A= =0A= Suggestion:=0A= s/Given a certificate X and a TA certificate/Given a certificate X and =0A= its certification path (per Section 6 of RFC5280)/ =0A= =0A= >You point out=0A= >> (In terms of language and clarity, the notion of calling a certificate "= valid" =0A= >> is misleading when in fact all that is being checked is merely =0A= >> whether a given INR is subsumed in it.) =0A= =0A= >Maybe there is a way of tightening this up. =0A= >How about: A resource contained in the resource extension =0A= >of a certificate is defined as "valid" if this resource =0A= >is listed in the resource extension field of all certificates =0A= >that are contained in a certification path, where the =0A= >construction of this certification path is defined in section 6 of RFC5280= .=0A= =0A= Suggestion:=0A= s/is listed in the resource extension field of all certificates/=0A= /is subsumed in the resource extension field of each of the certificates/= =0A= =0A= (Note: A prefix may not be listed but may be subsumed in a less specific th= at is listed.)=0A= =0A= Do you need somewhat different wording for the case of ROA validation?=0A= (Is a ROA also technically a "certificate"?)=0A= When you say "resource contained in the resource extension",=0A= is that well defined for a ROA as well?=0A= =0A= >(In the WG I also considered a slightly expanded question: =0A= >Given a certificate X and a set of TA certificates, =0A= >for what resources is this certificate "valid"?, =0A= >but that proved to be a little more controversial for many!)=0A= =0A= Yes, I also feel that the =93join=94 idea is far more complicated and the b= enefits are not clear.=0A= =0A= Thanks.=0A= Sriram=0A= =0A= ________________________________________=0A= From: Geoff Huston =0A= Sent: Sunday, March 16, 2014 9:15 PM=0A= To: Sriram, Kotikalapudi=0A= Cc: George Michaelson; sidr wg list=0A= Subject: Re: Questions about draft-huston-rpki-validation-01=0A= =0A= Hi Sriram,=0A= =0A= I am espousing method B in your terminology.=0A= =0A= Perhaps if I rephrase the validation question a little, it may be a little = clearer.=0A= =0A= The validation question is: Given a certificate X and a TA certificate, for= what resources is this certificate "valid"?=0A= =0A= You point out=0A= > (In terms of language and clarity, the notion of calling a certificate "v= alid"=0A= > is misleading when in fact all that is being checked is merely=0A= > whether a given INR is subsumed in it.)=0A= =0A= Maybe there is a way of tightening this up. How about: A resource contained= in the resource extension of a certificate is defined as "valid" if this r= esource is listed in the resource extension field of all certificates that = are contained in a certification path, where the construction of this certi= fication path is defined in section 6 of RFC5280.=0A= =0A= Back you your example...So the question posted by the ROA, which is signed = by certificate 3, is "Is certificate 3 valid for 10.0.0.0/24?"=0A= =0A= As you've described here the certification path is Cert 1, Cert 2, and Cert= 3, and as 10.0.0.0/24 is contained in the resource extension of all of the= se certificates then it can be concluded that the question posed by the ROA= , namely whether certificate 3 is valid for 10.0.0.0/24, can be answered in= the affirmative.=0A= =0A= (In the WG I also considered a slightly expanded question: Given a certific= ate X and a set of TA certificates, for what resources is this certificate = "valid"?, but that proved to be a little more controversial for many!)=0A= =0A= =0A= regards,=0A= =0A= Geoff=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= On 13 Mar 2014, at 7:17 am, Sriram, Kotikalapudi wrote:=0A= =0A= > Geoff,=0A= >=0A= > About my Question (3), let us discuss this a bit more carefully with an e= xample.=0A= >=0A= > There is this ROA: {10.0.0.0/24, AS64499} that we wish to validate.=0A= > It is signed with Certificate 3, which has the following certificate path= to the TA:=0A= > Certificate 1: It lists {10.0.0.0/12, AS64501, AS64505, AS64509} (TA cer= tificate)=0A= > Certificate 2: It lists {10.0.0.0/22, AS64501, AS64505, AS64511}=0A= > Certificate 3: It lists {10.0.0.0/20, AS64501, AS64505}=0A= > Note: Certificate 1 is the TA certificate.=0A= >=0A= > It is clear that following the current (RFC 3779) method,=0A= > Certificates 2 and 3 are invalid, and it follows that the ROA is invalid.= =0A= >=0A= > Now, there are two methods that we may enumerate for a modified (or alter= nate)=0A= > validation proposal:=0A= >=0A= > Method A (more conservative but less robust relative to Method B below):= =0A= >=0A= > Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate= 3.=0A= >=0A= > Step 2: Do the resources in Certificate 3 subsume the prefix in the ROA? = Answer: YES,=0A= > because "the INR of interest" 10.0.0.0/24 in the ROA is subsumed by=0A= > an INR 10.0.0.0/20 in Certificate 3. OK, now proceed to validate Certific= ate 3.=0A= > Note that "the INR of interest" in Certificate 3 is 10.0.0.0/20.=0A= >=0A= > Step 3: Ask if the resources in Certificate 2 subsume "the INR of interes= t" in Certificate 3?=0A= > Answer: NO, because "the INR of interest" 10.0.0.0/20 in Certificate 3 is= NOT subsumed=0A= > by an INR in the parent Certificate 2.=0A= > (Note: The parent Certificate 2 has a more specific prefix 10.0.0.0/22.)= =0A= >=0A= > Step 4: Since the certificate chain "validation" failed at Step 3, declar= e the ROA=0A= > being considered as "Invalid" for the prefix-origin pair {10.0.0.0/24, AS= 64499} .=0A= >=0A= > Method B (less conservative but more robust relative to Method A above):= =0A= >=0A= > Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate= 3.=0A= >=0A= > Step 2: Set "the given INR" as 10.0.0.0/24. That is the INR in the ROA fo= r which=0A= > validation is being sought.=0A= > [Note: "The given INR" remains a constant in the steps that follow.=0A= > We just *stay focused on this given INR* for the rest of the validation p= rocess below.=0A= > This is the main difference compared to method A.]=0A= >=0A= > Step 3: Do the resources in Certificate 3 subsume the "the given INR" 10.= 0.0.0/24?=0A= > Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.= 0.0/20 in Certificate 3.=0A= >=0A= > Step 4: Do the resources in Certificate 2 subsume the "the given INR" 10.= 0.0.0/24?=0A= > Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.= 0.0/22 in Certificate 2.=0A= >=0A= > Step 5: Do the resources in Certificate 1 subsume the "the given INR" 10.= 0.0.0/24?=0A= > Answer: YES, because the given INR 10.0.0.0/24 is subsumed by an INR 10.0= .0.0/12 in Certificate 1.=0A= >=0A= > Step 6: Since the certificate chain "validation" passed at each step abov= e=0A= > for "the given INR" 10.0.0.0/24, declare the ROA being considered=0A= > as "Valid" for the prefix-origin pair {10.0.0.0/24, AS64499} .=0A= >=0A= > So Method A produces an "Invalid" result for the ROA,=0A= > whereas Method B yields a "Valid" result.=0A= > I hope the difference between Methods A and B is clear.=0A= > In Method A, "the INR of interest" at level x must be subsumed by an INR = at level x+1.=0A= > But in Method B, only "the given INR" (e.g., a prefix in a ROA or an ASN = in a router certificate)=0A= > is the steady focus, and what is required is that "the given INR" must be= subsumed=0A= > by resources listed in the certificate at each level (1, 2, 3, ..., n).= =0A= >=0A= > The description on your Slide #18 falls short of describing precisely=0A= > either Method A or Method B. From your Slide #14, it seems evident that y= ou are=0A= > proposing Method B; am I right?=0A= > (In terms of language and clarity, the notion of calling a certificate "v= alid"=0A= > is misleading when in fact all that is being checked is merely=0A= > whether a given INR is subsumed in it.)=0A= >=0A= > Sriram=0A= >=0A= >=0A= =0A= From nobody Mon Mar 17 16:47:11 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8E81A01FB for ; Mon, 17 Mar 2014 16:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHNk-0siwaXn for ; Mon, 17 Mar 2014 16:47:03 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id C6F581A01E1 for ; Mon, 17 Mar 2014 16:47:02 -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=PnFRF45IQmviZ6tclHtmE/NzPblEVLINdQeLpN/tOA8=; b=q7znlPkQ+WaK38SpzWO6/EEOZ3mCqLSC8ojMxCJJ2PKPRAI4/HKmPt3F29+eGevRexMyCygHB0Mgn kJMGbibkqjVSGzaYWLn30T7eDtJg0+HBN7UwogLtj+bik8BHo4mrzk8g7RBSu69Pdbok6n/iNcfOWC pQ799jPbE2PFSbgI= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 18 Mar 2014 18:56:41 +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; Tue, 18 Mar 2014 09:46:51 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> Date: Tue, 18 Mar 2014 10:46:49 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com>, <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/JKV8ZJacfIvTfwg5EQgF3xHpJt0 Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 23:47:05 -0000 >=20 Hi Sriram, >> Perhaps if I rephrase the validation question a little,=20 >> it may be a little clearer. >=20 >> The validation question is: Given a certificate X and a TA = certificate,=20 >> for what resources is this certificate "valid"? >=20 > Suggestion: > s/Given a certificate X and a TA certificate/Given a certificate X and=20= > its certification path (per Section 6 of RFC5280)/=20 >=20 agreed, this is a little cleared >> You point out >>> (In terms of language and clarity, the notion of calling a = certificate "valid"=20 >>> is misleading when in fact all that is being checked is merely=20 >>> whether a given INR is subsumed in it.) =20 >=20 >> Maybe there is a way of tightening this up.=20 >> How about: A resource contained in the resource extension=20 >> of a certificate is defined as "valid" if this resource=20 >> is listed in the resource extension field of all certificates=20 >> that are contained in a certification path, where the=20 >> construction of this certification path is defined in section 6 of = RFC5280. >=20 > Suggestion: > s/is listed in the resource extension field of all certificates/ > /is subsumed in the resource extension field of each of the = certificates/ >=20 > (Note: A prefix may not be listed but may be subsumed in a less = specific that is listed.) >=20 agreed > Do you need somewhat different wording for the case of ROA validation? > (Is a ROA also technically a "certificate"?) > When you say "resource contained in the resource extension", > is that well defined for a ROA as well? RFC6482 need not be altered at all. Section 4 of RFC64582 states: The IP address delegation extension [RFC3779 is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. which still holds in this slightly altered certificated validation = framework. >=20 >> (In the WG I also considered a slightly expanded question:=20 >> Given a certificate X and a set of TA certificates,=20 >> for what resources is this certificate "valid"?,=20 >> but that proved to be a little more controversial for many!) >=20 > Yes, I also feel that the =93join=94 idea is far more complicated and = the benefits are not clear. >=20 I am working on clarity here in terms of explaining the benefits of this = approach. thanks, Geoff From nobody Tue Mar 18 05:22:43 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53F21A0123 for ; Tue, 18 Mar 2014 05:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcO3ngpqLCjM for ; Tue, 18 Mar 2014 05:22:38 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 37FBF1A0333 for ; Tue, 18 Mar 2014 05:22:37 -0700 (PDT) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB056.namprd09.prod.outlook.com (10.255.211.156) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 12:22:28 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.12]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.174]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 12:22:28 +0000 From: "Sriram, Kotikalapudi" To: Geoff Huston Thread-Topic: Questions about draft-huston-rpki-validation-01 Thread-Index: Ac89eRhd+ibZbQZWQW6u2RB/Km153QAQRwSAABsPsLAA1ffwgAAtxyldAAFuk4AAGUQnAg== Date: Tue, 18 Mar 2014 12:22:27 +0000 Message-ID: References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com>, <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com>, <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> In-Reply-To: <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.163.254.208] x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(92566001)(93136001)(77096001)(69226001)(80976001)(80022001)(65816001)(66066001)(95666003)(74662001)(86362001)(47446002)(93516002)(74502001)(83072002)(85852003)(94946001)(94316002)(31966008)(47736001)(47976001)(49866001)(81342001)(81542001)(4396001)(76576001)(76796001)(76786001)(50986001)(87936001)(2656002)(95416001)(74366001)(74316001)(56776001)(87266001)(81816001)(33646001)(90146001)(74876001)(56816005)(85306002)(76482001)(54316002)(83322001)(81686001)(59766001)(63696002)(77982001)(97336001)(79102001)(20776003)(51856001)(46102001)(54356001)(53806001)(97186001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB056; H:BLUPR09MB053.namprd09.prod.outlook.com; FPR:6CC8FAB5.AD98D620.7FF763BB.6E0FE99.201C1; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/8p2PdZ2xFq8WI1PFGnyPvCtVa7Q Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 12:22:41 -0000 Geoff,=0A= =0A= >> Do you need somewhat different wording for the case of ROA validation?= =0A= >> (Is a ROA also technically a "certificate"?)=0A= >> When you say "resource contained in the resource extension",=0A= >> is that well defined for a ROA as well?=0A= =0A= >RFC6482 need not be altered at all.=0A= >Section 4 of RFC64582 states:=0A= > The IP address delegation extension [RFC3779 is present in the=0A= > end-entity (EE) certificate (contained within the ROA), and each=0A= > IP address prefix(es) in the ROA is contained within the set of IP= =0A= > addresses specified by the EE certificate's IP address delegation=0A= > extension.=0A= =0A= >which still holds in this slightly altered certificated validation framewo= rk.=0A= =0A= That is good. But what I meant was (in your I-D under discussion) does =0A= the alternate validation algorithm for a ROA need slightly different wordin= g =0A= (as compared to that for certificates)? =0A= Such as:=0A= A ROA is "valid" for a given IP address prefix specified in the ROA, =0A= if the given IP address prefix is subsumed in the resource extension field = =0A= of the end-entity (EE) certificate (contained within the ROA),=0A= and also subsumed in the resource extension field of all other certificates= =0A= that are contained in a certification path, where the =0A= construction of this certification path is defined in Section 6 of RFC5280.= =0A= =0A= Sriram=0A= =0A= =0A= =0A= =0A= =0A= From nobody Tue Mar 18 11:21:31 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036A01A0452; Tue, 18 Mar 2014 11:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g37WCEqyx_ez; Tue, 18 Mar 2014 11:21:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB21A0454; Tue, 18 Mar 2014 11:20:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140318182033.1157.48788.idtracker@ietfa.amsl.com> Date: Tue, 18 Mar 2014 11:20:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/_k_tOADfO-N3l2n6K7Q3dwvRB8E Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 18:21:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Resource Certificate PKI (RPKI) Trust Anchor Locator Authors : Geoff Huston Samuel Weiler George Michaelson Stephen Kent Filename : draft-ietf-sidr-rfc6490-bis-00.txt Pages : 9 Date : 2014-03-04 Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 18 12:10:42 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D922D1A0494 for ; Tue, 18 Mar 2014 12:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCsP0I7uXCVL for ; Tue, 18 Mar 2014 12:10:34 -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 B83641A044C for ; Tue, 18 Mar 2014 12:10:33 -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=g00i+y+c8zLWE+4A7mHdRITUpwaJU+8v7/TbqxCYd/A=; b=X4MDg7r1JyTDPk+l/QFCrOQeh3y09W4EZcLjRcLm06wqJQ6827A9PvVXirA7NRV1a2ETyYm6Qk+0O tMxkK+cOAUigWhiosKIBrQ4s/ZLWvsU1NHxjkIC0GIZ5Cw654QKepzYs/7zPDnebHb7JH+zIPl8rcF ZTNsrnx6R57fw1kE= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 19 Mar 2014 05:10:23 +1000 (EST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 19 Mar 2014 05:10:22 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: Date: Wed, 19 Mar 2014 06:10:20 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com>, <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com>, <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/YxhZEd02NmFU8L4z6-uoZVlUg8I Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:10:40 -0000 >=20 > That is good. But what I meant was (in your I-D under discussion) does=20= > the alternate validation algorithm for a ROA need slightly different = wording=20 > (as compared to that for certificates)?=20 I think not. RFC6482 did not define how the EE certificate is to be = validated. It simply states that the IP addresses listed in the ROA must also be found in the resource extensions of the signing EE cert. This still = holds. i.e. no change is required there. regards, Geoff From nobody Tue Mar 18 13:09:39 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A591A0296 for ; Tue, 18 Mar 2014 13:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkpibludFHjv for ; Tue, 18 Mar 2014 13:09:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4359C1A01A5 for ; Tue, 18 Mar 2014 13:09:36 -0700 (PDT) Received: from BLUPR09MB053.namprd09.prod.outlook.com (10.255.211.146) by BLUPR09MB056.namprd09.prod.outlook.com (10.255.211.156) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 20:09:27 +0000 Received: from BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.12]) by BLUPR09MB053.namprd09.prod.outlook.com ([169.254.14.174]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 20:09:26 +0000 From: "Sriram, Kotikalapudi" To: Geoff Huston Thread-Topic: Questions about draft-huston-rpki-validation-01 Thread-Index: Ac89eRhd+ibZbQZWQW6u2RB/Km153QAQRwSAABsPsLAA1ffwgAAtxyldAAFuk4AAGUQnAgAPXn8AAACzPPA= Date: Tue, 18 Mar 2014 20:09:26 +0000 Message-ID: References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com>, <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com>, <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> In-Reply-To: <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 0154C61618 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(199002)(189002)(81816001)(33646001)(85306002)(90146001)(74706001)(56816005)(74876001)(2656002)(95416001)(87936001)(87266001)(74366001)(56776001)(76482001)(77982001)(79102001)(20776003)(97336001)(59766001)(63696002)(51856001)(97186001)(53806001)(54356001)(46102001)(83322001)(54316002)(81686001)(65816001)(66066001)(95666003)(80022001)(80976001)(92566001)(77096001)(93136001)(69226001)(81542001)(49866001)(81342001)(4396001)(47736001)(76576001)(76796001)(76786001)(50986001)(47976001)(74502001)(93516002)(47446002)(74662001)(86362001)(94946001)(94316002)(31966008)(83072002)(85852003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB056; H:BLUPR09MB053.namprd09.prod.outlook.com; FPR:7DF6FAF4.AD92D710.41F30F5B.44E41149.201E6; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/cdfLnJK3NQANXnIwYeEOIq93bv0 Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 20:09:38 -0000 >> >> That is good. But what I meant was (in your I-D under discussion) does >> the alternate validation algorithm for a ROA need slightly different >> wording (as compared to that for certificates)? > >I think not. RFC6482 did not define how the EE certificate is to be valid= ated. >It simply states that the IP addresses listed in the ROA must also be foun= d in the >resource extensions of the signing EE cert. This still holds. > >i.e. no change is required there. > I think you are saying that a ROA is "valid" for all prefixes listed in it,= if the signing EE cert is=20 "valid" for each of those prefixes (in accordance with the alternate valida= tion method). I.e., there is no such thing as 'the ROA is (partially) valid for some of t= he listed prefixes'. Does not harm to include some statement this effect in your I-D. We discussed the possibility of ROA over-claiming earlier.=20 The above is not accommodative of that. And I think that is also OK for now= . We can revisit if robustness to ROA over-claiming is something=20 that interests anyone else on this list. Thanks. Sriram =20 =20 From nobody Tue Mar 18 13:29:14 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7A1A02FB; Tue, 18 Mar 2014 13:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PusukAp4_wbe; Tue, 18 Mar 2014 13:29:10 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id D99601A01A5; Tue, 18 Mar 2014 13:29:09 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s2IKPHm3030700; Tue, 18 Mar 2014 15:29:01 -0500 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1jpt09174g-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 18 Mar 2014 15:29:00 -0500 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s2IKT0cr024263; Tue, 18 Mar 2014 16:29:00 -0400 Received: from HSV-CAS004.huntsville.ads.sparta.com ([10.62.8.148]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s2IKT0Ts007963; Tue, 18 Mar 2014 16:29:00 -0400 Received: from HSV-MB001.huntsville.ads.sparta.com ([fe80::292e:cdb7:1aa6:ce74]) by HSV-CAS004.huntsville.ads.sparta.com ([fe80::d00f:c039:2622:2252%11]) with mapi id 14.02.0387.000; Tue, 18 Mar 2014 15:28:59 -0500 From: "Murphy, Sandra" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-00.txt Thread-Index: AQHPQtbnMOHi2dMs1kSsYeP1L7lq3ZrnSumT Date: Tue, 18 Mar 2014 20:29:00 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694A0BA32@HSV-MB001.huntsville.ads.sparta.com> References: <20140318182033.1157.48788.idtracker@ietfa.amsl.com> In-Reply-To: <20140318182033.1157.48788.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.33] 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.11.87, 1.0.14, 0.0.0000 definitions=2014-03-18_07:2014-03-18,2014-03-18,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.09996243435396 urlsuspect_oldscore=0.999624343539601 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.09996243435396 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403180106 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/t2B6Ulr2H9RCDyaquVfivQl4LKo Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 20:29:12 -0000 Apologies to the authors. This was submitted during IETF week. Being a -0= 0 draft, a request for approval was sent to the chairs, who missed it.=0A= =0A= --Sandy, speaking as a wg co-chair=0A= ________________________________________=0A= From: sidr [sidr-bounces@ietf.org] on behalf of internet-drafts@ietf.org [i= nternet-drafts@ietf.org]=0A= Sent: Tuesday, March 18, 2014 2:20 PM=0A= To: i-d-announce@ietf.org=0A= Cc: sidr@ietf.org=0A= Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-00.txt=0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the Secure Inter-Domain Routing Working Group= of the IETF.=0A= =0A= Title : Resource Certificate PKI (RPKI) Trust Anchor Loca= tor=0A= Authors : Geoff Huston=0A= Samuel Weiler=0A= George Michaelson=0A= Stephen Kent=0A= Filename : draft-ietf-sidr-rfc6490-bis-00.txt=0A= Pages : 9=0A= Date : 2014-03-04=0A= =0A= Abstract:=0A= This document defines a Trust Anchor Locator (TAL) for the Resource=0A= Certificate Public Key Infrastructure (RPKI).=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/=0A= =0A= There's also a htmlized version available at:=0A= http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-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= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From nobody Fri Mar 21 09:23:21 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7133A1A047B for ; Fri, 21 Mar 2014 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXIeGDHBqNaO for ; Fri, 21 Mar 2014 09:23:17 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE391A0764 for ; Fri, 21 Mar 2014 09:23:17 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WR2Do-00084w-8Y; Fri, 21 Mar 2014 17:23:05 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-7.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WR2Do-0007vu-3g; Fri, 21 Mar 2014 17:23:04 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <20140306110317.2AF1BAFDF22@minas-ithil.hactrn.net> Date: Fri, 21 Mar 2014 17:23:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A4252C9-9B98-4E60-9E8B-C39834BB95D0@ripe.net> References: <20140306110317.2AF1BAFDF22@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1510) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_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: 784d7acfe6559f2a0b602ec6519a0719c4d7f5bb4754cfb2d173624fdbc898ba Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/rZ138aWS5o10RzmdGaVp24hfAgI Cc: sidr@ietf.org Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:23:19 -0000 Hi Rob, wg, Sorry for the late reply. For the record: I support adopting this work. I will reply to issues raised and discussed in this thread where = appropriate. Here I just wanted to comment on this: > 2) We added a few timing parameters to the End Of Data PDU. These, > like the Serial Number mechanism, are lifted almost verbatim from > the DNS zone transfer protocol. We left them out of RFC 6810, but > subsequent exploration of some of the corner cases of the RPKI > Router protocol convinced us that leaving these timing parameters > out of the protocol had been a mistake. Can you elaborate a bit on why this had been a mistake? With regards to the minimum allowed value for the refresh. Why is it 120 = seconds? That seems rather long to me. I understand that currently = updates do not happen that often and propagate that quickly, but that = may change. And if it does, and the RP tool sees more regular changes = and it is confident that it can deal with load, then I think it would be = better if it could use a lower number without having to revisit this = text. With regards to the retry and expire intervals: I am not sure what I (as = cache) should tell the router, so I would probably just go for the = defaults. Reading them they look to me more like responsibilities of the = client. But please let me know if I am missing something below.. Did you intend for the expire interval to be something that an operator = can configure in the cache, and have it automatically propagated to the = client routers? I think I would prefer to configure it on the routers. With regards to the retry interval, I am not sure if there should be any = limit. Why can't the router decide, and what it is the synergy with = having multiple cache configured in a router described in section 10? I = think I may prefer to not limit the router's retries at all, and = recommend operators to monitor their cache. Do we need a standard query = type for the latter? At least to get the cache's own opinion on its = health that could be integrated with monitoring? Tim From nobody Fri Mar 21 09:25:09 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970281A0470 for ; Fri, 21 Mar 2014 09:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47ofdJWD6DmD for ; Fri, 21 Mar 2014 09:24:57 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id A9FB11A03FA for ; Fri, 21 Mar 2014 09:24:57 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WR2FJ-0005B4-Nc; Fri, 21 Mar 2014 17:24:48 +0100 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-7.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WR2FJ-00081E-Iy; Fri, 21 Mar 2014 17:24:37 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Fri, 21 Mar 2014 17:24:38 +0100 Content-Transfer-Encoding: 7bit Message-Id: <9D934E53-8CE6-4C43-9E4E-536EEA025153@ripe.net> References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> To: David Mandelberg X-Mailer: Apple Mail (2.1510) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_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: 784d7acfe6559f2a0b602ec6519a0719443b0aeb1f519e2ea4e4e19104573d20 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/BWztoQZjmM5t1UI-SAc8aYgT7bE Cc: sidr@ietf.org Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:24:59 -0000 On Mar 17, 2014, at 4:51 PM, David Mandelberg wrote: > On 2014-03-07 06:39, Rob Austein wrote: >> David can speak for himself, but speaking on my own behalf as a >> implementer: if we define a canonical order, comparing two PDUs is a >> simple binary string comparison. If we don't define a canonical >> order, comparison is more complicated, hence more error-prone. Given >> that the rpki-rtr protocol requires duplicate elimination, we do need >> to perform such comparisons, so making them as simple as possible >> seems advisable. > > I fully agree with the above. +1 > > >> FWIW, I think David's suggestion is a good one, and I'm likely to >> implement it that way in my server whether required to do so or not. > > I'll probably also implement it that way. +1 > > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Mar 27 07:23:54 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82F41A0705 for ; Thu, 27 Mar 2014 07:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb7dQEL6FAAD for ; Thu, 27 Mar 2014 07:23:50 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.55.4]) by ietfa.amsl.com (Postfix) with ESMTP id BFB8D1A072C for ; Thu, 27 Mar 2014 07:23:46 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 500) id EE62A5C596CB0; Thu, 27 Mar 2014 08:23:44 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway11.websitewelcome.com (Postfix) with ESMTP id CC5445C596C4D for ; Thu, 27 Mar 2014 08:23:44 -0600 (CST) Received: from [96.231.225.192] (port=50261 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WTBDc-00060d-05; Thu, 27 Mar 2014 09:23:44 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: Date: Thu, 27 Mar 2014 10:23:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6EB6BF26-E261-449D-85DF-124EE7914424@ieca.com> References: <531F1F0F.5090803@bbn.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:50261 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xryUBGLq9BkJjN-NEcBNzs0QxBI Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSEC Algorithms document missing a clear reference? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:23:52 -0000 New version should be posted soon addressing this and some other = reference updaets. spt On Mar 11, 2014, at 11:56, Christopher Morrow = wrote: > On Tue, Mar 11, 2014 at 10:34 AM, Stephen Kent wrote: >> Chris, >>=20 >>=20 >>> It was pointed out in passing (hallway/table conversation) that in: >>> draft-ietf-sidr-bgpsec-algs-05 (at least 05) >>>=20 >>> there's this text in section 2: >>>=20 >>> "NOTE: The exception to the above hashing algorithm is the use of >>>=20 >>> SHA-1 [SHS] when CAs generate authority and subject key >>> identifiers [ID.bgpsec-pki-profiles]." >>>=20 >>> The reference to bgpsec-pki-profiles, is PROBABLY really: >>> draft-sidr-bgpsec-pki-profiles >>> >>=20 >> not sure why the angle bracket reference to the bgpsec protocol = appears >> above, >=20 > angle brackets because of old-skool email-client/URL interpolation = habits :( > wrong reference because ... #fail. The right one: > >=20 > apologies for the confusion. >=20 >> after the intended reference. But, as you note below, >> draft-sidr-bgpsec-pki-profiles >> does not refer to SKI's.It says that it inherits all of the RPKI cert >> profile >> (RFC 6487) except as noted in Section 3 of the I-D. RFC 6487 mandates >> inclusion >> of the SKI and AKI extensions, and specifies use of SHA-1 to compute = SKI and >> AKI values. >> So, the text above should be changed to refer RFC 6487. (There is no = need to >> go back to >> 5280, since 6487 cites it and narrows the SKI/AKI generation options = from >> that RFC.) >=20 > awesome! the OP was correct in pointing out the missing linkages, = sweet :) >=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Mar 27 07:26:22 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EB81A072C; Thu, 27 Mar 2014 07:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOb4H9GEUsxe; Thu, 27 Mar 2014 07:26:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B34F1A0731; Thu, 27 Mar 2014 07:26:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140327142616.8634.4770.idtracker@ietfa.amsl.com> Date: Thu, 27 Mar 2014 07:26:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/OHnGXdQe9f6oHJR2G14D87H_OJI Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:26:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : BGP Algorithms, Key Formats, & Signature Formats Author : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-06.txt Pages : 7 Date : 2014-03-27 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-algs-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 27 08:42:22 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5032B1A0670; Thu, 27 Mar 2014 08:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_U9fSAPS9Az; Thu, 27 Mar 2014 08:42:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C67451A0322; Thu, 27 Mar 2014 08:42:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140327154215.24135.70663.idtracker@ietfa.amsl.com> Date: Thu, 27 Mar 2014 08:42:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/dPvWm68fhjVhCRDzDvbt4bnADwA Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:42:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests Authors : Mark Reynolds Sean Turner Steve Kent Filename : draft-ietf-sidr-bgpsec-pki-profiles-07.txt Pages : 12 Date : 2014-03-27 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) or ASes. 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(es). 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-pki-profiles-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 27 09:29:39 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EA91A0178 for ; Thu, 27 Mar 2014 09:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuMrkVqamnbL for ; Thu, 27 Mar 2014 09:29:36 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.71.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADA61A016A for ; Thu, 27 Mar 2014 09:29:36 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 9FDAF9BB8EA5; Thu, 27 Mar 2014 11:29:34 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 864D59BB8E40 for ; Thu, 27 Mar 2014 11:29:34 -0500 (CDT) Received: from [96.231.225.192] (port=51062 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WTDBM-00017G-VJ for sidr@ietf.org; Thu, 27 Mar 2014 11:29:33 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: <20140307204918.31610.82129.idtracker@ietfa.amsl.com> Date: Thu, 27 Mar 2014 12:29:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62DD1873-6D92-41B7-B0D4-F227CE9AAAB7@ieca.com> References: <20140307204918.31610.82129.idtracker@ietfa.amsl.com> To: sidr@ietf.org X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.4]) [96.231.225.192]:51062 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/gpQPrO_VuHzBU8l3NF45Af74wXM Subject: [sidr] comments: draft-ietf-sidr-rfc6485bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:29:38 -0000 I think this one is ready for wglc ;) nits that can be fixed whenever: s6: r/and [RFC6487] a apply to certificate and CRLs /and [RFC6487] apply to certificates and CRLs s8: Maybe consider just renaming s8 to =93Changes since RFC 6485=94 and = striking: [Remove before publication. Dear IESG, This is a slight technical change to RFC6485, and the advice to the WG from a Routing AD was that this is outside the limited scope of an erratum. and the final ]. In recent history, the IESG liked to have a section in update drafts = that remains after publication listing the changes. spt On Mar 07, 2014, at 15:49, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : The Profile for Algorithms and Key Sizes for = use in the Resource Public Key Infrastructure > Authors : Geoff Huston > George Michaelson > Filename : draft-ietf-sidr-rfc6485bis-00.txt > Pages : 7 > Date : 2014-03-07 >=20 > Abstract: > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format for > the Resource Public Key Infrastructure subscribers that generate > digital signatures on certificates, Certificate Revocation Lists, = and > signed objects as well as for the Relying Parties (RPs) that verify > these digital signatures. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Mar 27 11:33:17 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA081A0182 for ; Thu, 27 Mar 2014 11:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmiSqTmg3md4 for ; Thu, 27 Mar 2014 11:33:14 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id DB57A1A0352 for ; Thu, 27 Mar 2014 11:33:12 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [10.0.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 7DD2673051 for ; Thu, 27 Mar 2014 18:33:08 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3372417135 for ; Thu, 27 Mar 2014 14:33:08 -0400 (EDT) Date: Thu, 27 Mar 2014 14:33:08 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <5318AD76.6060204@bbn.com> <20140306173133.8F64AAFEE87@minas-ithil.hactrn.net> <20140307103958.5FA6AAFFE52@minas-ithil.hactrn.net> <20140309101809.B5A23B02C27@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140327183308.3372417135@thrintun.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ZY8w1ktwHxJRp6AR-lfpI1VH6tQ Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 18:33:16 -0000 At Mon, 17 Mar 2014 00:40:30 +0100, Matthias Waehlisch wrote: > > Sorry for the late reply ... Mine is even later, as I was mostly offline for more than a week. > Just to double check, because the term "duplicate" is not very clear > in this context - at least to me. In contrast to RFC 6810, in RFC > 6810-bis a Router Key PDU contains a list of ASNs. The received PDU may > differ even though parts of the content are duplicates. > > RFC 6810 says "identical to one it already has active", which means > that we are checking pieces of content. For example, the router receives > Router Key PDU with ASNs {10,20,30} and later the 'same' PDU but with > ASNs {10,20}. I would consider this as a duplicate. However, in this > case the ordering doesn't help to apply binary string comparison. This is a can of worms. Thank you for being polite about it. :) At this point I think the simplest solution would be to change the format of the proposed Router Key PDU so that it contains exactly one ASN. In the rare cases (router operators, sanity check this, please) where there is a need for multiple ASNs to share the same key, the cache would just issue multiple Router Key PDUs, one for each ASN. This approach is a bit verbose in the multi-ASN case, but has trivially simple protocol semantics. An alternative would be to require the cache to withdraw then announce ; in this case, "duplicate" would be defined solely by the key. My preference for the first approach is based on the assumption that this is a rare case, therefore not worth optimizing at the expense of additional protocol complexity. In particular, I would really prefer to avoid adding code paths that will almost never be executed into a security protocol. From nobody Thu Mar 27 12:19:37 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3701A073B for ; Thu, 27 Mar 2014 12:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g17IECJyOurn for ; Thu, 27 Mar 2014 12:19:32 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id AC5B01A0720 for ; Thu, 27 Mar 2014 12:19:30 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 0DE3373051 for ; Thu, 27 Mar 2014 19:19:27 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id A82A617135 for ; Thu, 27 Mar 2014 15:19:26 -0400 (EDT) Date: Thu, 27 Mar 2014 15:19:26 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <0A4252C9-9B98-4E60-9E8B-C39834BB95D0@ripe.net> References: <20140306110317.2AF1BAFDF22@minas-ithil.hactrn.net> <0A4252C9-9B98-4E60-9E8B-C39834BB95D0@ripe.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140327191926.A82A617135@thrintun.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/1EnN7ZGnG80Cqunn2uiBe5cV-qQ Subject: Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 19:19:34 -0000 At Fri, 21 Mar 2014 17:23:05 +0100, Tim Bruijnzeels wrote: > > Sorry for the late reply. Likewise :) > > 2) We added a few timing parameters to the End Of Data PDU. These, > > like the Serial Number mechanism, are lifted almost verbatim from > > the DNS zone transfer protocol. We left them out of RFC 6810, but > > subsequent exploration of some of the corner cases of the RPKI > > Router protocol convinced us that leaving these timing parameters > > out of the protocol had been a mistake. > > Can you elaborate a bit on why this had been a mistake? Back around Halloween, Randy and I received an off-list message asking about the end of RFC 6810 section 8. Our correspondent is welcome to jump in here and speak for himself, but he's not one of the usual IETF suspects and may not be on list, so I'll attempt to channel him for the moment. He pointed out that RFC 6810 is inconsistent in its advice about what the router should do if it loses connectivity to the cache for more than two hours: in one place we say that the router SHOULD delete the data it got from the cache, in another place we say that the router should retain the data. Furthermore, RFC 6810 is unclear on how long the router should retain the data (if it does), and, if so, what the expiration period should be. The DNS zone transfer protocol, on which the rpki-rtr protocol is based, conveys explicit answers to all of these questions to the router, in the form of the timing parameters included in the SOA record. Upon reading this question, I concluded that leaving the rest of these out of the rpki-rtr protocol had been a mistake. Granted, this just pushes some of the decisions back from the router to the cache, but the cache is (probably) in a better position to know the right answers, or, at least, plausible harmless answers. That said: the proposed defaults in the current draft, while not quite picked out of thin air, were not the result of years of detailed analysis, so I'm open to suggestions for better values. > With regards to the minimum allowed value for the refresh. Why is it > 120 seconds? That seems rather long to me. I understand that > currently updates do not happen that often and propagate that > quickly, but that may change. And if it does, and the RP tool sees > more regular changes and it is confident that it can deal with load, > then I think it would be better if it could use a lower number > without having to revisit this text. Part of the point of the REFRESH and RETRY parameters is to allow the cache to specify how much beating it is willing to accept from the router(s). In that context, telling the router to check for updates every minute seems a bit excessive. Keep in mind that the current recommendation is to poll hourly, and that the real mechanism for pushing updates out quickly is the Notify PDU (which we also lifted almost verbatim from DNS, no surprise). There may be a better way to phrase the text in the draft, but the REFRESH parameter is intended to control how often the router polls in the absence of a Notify PDU. Assuming that the cache generates Notify PDus, this kind of polling is almost unnecessary; we included it because Notify PDUs are just a hint to the router that now would be a good time to poll, which the router is free to ignore. The REFRESH value tells the router that it really should consider polling at that interval if it hasn't been responding to Notify PDUs. As a demented counterexample, I guess one could build a router which refuses to process Notify PDUs at all but which wants to be kept up to date so badly that it wants to poll every five seconds. I will confess to not having a lot of sympathy with such a design. All that said, if you have a proposal for a better minimum, holler. > With regards to the retry and expire intervals: I am not sure what I > (as cache) should tell the router, so I would probably just go for > the defaults. That's fine, if you have no better idea, although you might consider making them configurable by the cache operator. > Reading them they look to me more like responsibilities of the > client. But please let me know if I am missing something below.. The thing you may be missing is that these are likely to be tied to things like loading on your cache (eg, how many routers is this poor little cache serving, and are you running the cache on a TRS-80), how often your cache fetches data from the RPKI, and what kinds of certificate expiration times people are using to populate the RPKI. Granted, the cache may not be much smarter about some of this than the router is, but, pretty much by definition, the cache can't possibly be dumber about these issues than the router is. > Did you intend for the expire interval to be something that an > operator can configure in the cache, and have it automatically > propagated to the client routers? I think I would prefer to > configure it on the routers. Says the author of a cache implementation :) What I got from the original query that started me down this path is that the router guys don't really know either. Nothing you say can require them to hold data longer than they want to do so, but you, as the cache, ought to be able to tell them that it's a really bad idea to hold data longer than X. You, as the cache, have some idea of what your own update frequency is and can, if you choose, measure what kind of churn rate you're seeing, from which you can determine (at least as well as the router can) how long it is before N percent of the data have changed. Granted, you might not bother to do that; you might instead choose to hardwire an advertised expiration time measured in years. But since the cache is stripping off all the certificate expiration timestamps, the cache by definition knows more about this than the router does, so it seems advisable to have some way for the cache to tell the router when old data should go away. > With regards to the retry interval, I am not sure if there should be > any limit. Why can't the router decide, and what it is the synergy > with having multiple cache configured in a router described in > section 10? RETRY is one cache telling the routers that use it how often it's willing to be beaten up when there's a problem refreshing data. Different cache, (potentially) different RETRY. > I think I may prefer to not limit the router's retries at all, and > recommend operators to monitor their cache. Do we need a standard > query type for the latter? At least to get the cache's own opinion > on its health that could be integrated with monitoring? I don't understand how this would work well enough to have an informed opinion, but it sounds more complicated than DNS-like RETRY. Where's the gain? Also, "recommend operators to monitor their cache" sounds like you're talking about human beings. Certainly there are some in the NOC, but do we really need to drag them in whenever a router fails to sync with its cache(s)? Keep in mind that, for all of these parameters, the cache's responsibility is probably just to pass along settings that were configured by the human who installed the cache software (which may in turn just be passing along the default values from the spec). The point of the exercise here is to make these things explicit, visible, and configurable by the operator, rather than leaving them in the realm of things which the router implementor may or may not have made configurable in some implementation-specific way. From nobody Thu Mar 27 17:41:36 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1381A075F; Thu, 27 Mar 2014 17:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGrXPnJ2Rirm; Thu, 27 Mar 2014 17:41:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D511A075C; Thu, 27 Mar 2014 17:41:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140328004126.13483.25956.idtracker@ietfa.amsl.com> Date: Thu, 27 Mar 2014 17:41:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ABmK1YCRHuzGs37f2xIoXePAdi0 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 00:41:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure Authors : Geoff Huston George Michaelson Filename : draft-ietf-sidr-rfc6485bis-01.txt Pages : 7 Date : 2014-03-27 Abstract: This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format for the Resource Public Key Infrastructure subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the Relying Parties (RPs) that verify these digital signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6485bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 27 17:41:45 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB751A078D for ; Thu, 27 Mar 2014 17:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0BIuzr2d2We for ; Thu, 27 Mar 2014 17:41:38 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id CF1F61A0766 for ; Thu, 27 Mar 2014 17:41:37 -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=qdtWoJ70pMMOQIkWBv5PjduqxDFW4YZaC4TsNXpQJvk=; b=qkPiTNWaLRC5SKkjXdcYgqIuJrn4dYzZv48d0Ann08ArTUzpTiIc8TUqB7ZVOb7flQWJ4NGILNhwi RS08X84slDuco3L/LElmA3RNGPhZoUPBhUT5D6nSp5YQSF7/Qq+cmQFTnbSZ54bbWQ7Q9fJrw01aLK 7T0QR0Y/yzfYXQUc= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 28 Mar 2014 19:50:43 +1000 (EST) Received: from [203.119.77.29] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 28 Mar 2014 10:41:32 +1000 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <62DD1873-6D92-41B7-B0D4-F227CE9AAAB7@ieca.com> Date: Fri, 28 Mar 2014 11:41:31 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140307204918.31610.82129.idtracker@ietfa.amsl.com> <62DD1873-6D92-41B7-B0D4-F227CE9AAAB7@ieca.com> To: sidr wg list X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xHY__9tQGwk7cVViOr2F3UmGW3Y Cc: sidr-chairs@ietf.org Subject: Re: [sidr] comments: draft-ietf-sidr-rfc6485bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 00:41:40 -0000 Thanks Sean. I've submitted a -01 version with these changes applied Chairs: this is a pretty minor change and I think we are done - can I = request a WGLC on this version (-01) of the document? thanks, Geiff On 28 Mar 2014, at 3:29 am, Sean Turner wrote: > I think this one is ready for wglc ;) >=20 > nits that can be fixed whenever: >=20 > s6: >=20 > r/and [RFC6487] a apply to certificate and CRLs > /and [RFC6487] apply to certificates and CRLs >=20 > s8: Maybe consider just renaming s8 to =93Changes since RFC 6485=94 = and striking: >=20 > [Remove before publication. >=20 > Dear IESG, This is a slight technical change to RFC6485, and the > advice to the WG from a Routing AD was that this is outside the > limited scope of an erratum. >=20 > and the final ]. >=20 > In recent history, the IESG liked to have a section in update drafts = that remains after publication listing the changes. >=20 > spt >=20 > On Mar 07, 2014, at 15:49, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >>=20 >> Title : The Profile for Algorithms and Key Sizes for = use in the Resource Public Key Infrastructure >> Authors : Geoff Huston >> George Michaelson >> Filename : draft-ietf-sidr-rfc6485bis-00.txt >> Pages : 7 >> Date : 2014-03-07 >>=20 >> Abstract: >> This document specifies the algorithms, algorithms' parameters, >> asymmetric key formats, asymmetric key size and signature format for >> the Resource Public Key Infrastructure subscribers that generate >> digital signatures on certificates, Certificate Revocation Lists, = and >> signed objects as well as for the Relying Parties (RPs) that verify >> these digital signatures. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Mar 28 12:55:41 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F11A0785 for ; Fri, 28 Mar 2014 12:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrsLd3hFjiqS for ; Fri, 28 Mar 2014 12:55:34 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1531A076A for ; Fri, 28 Mar 2014 12:55:33 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 631B428B003A; Fri, 28 Mar 2014 15:55:31 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 4BA371F8035; Fri, 28 Mar 2014 15:55:31 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <030d01cf3d4e$cb933780$4001a8c0@gateway.2wire.net> Date: Fri, 28 Mar 2014 15:55:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F694A07932@HSV-MB001.huntsville.ads.sparta.com> <030d01cf3d4e$cb933780$4001a8c0@gateway.2wire.net> To: sidr@ietf.org X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ma3zGeMXEPorhAF-_sUuRA27ebI Subject: Re: [sidr] IETF89 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 19:55:35 -0000 There were indeed two copies of the "Rsync considered harmful" slides, = which was corrected easily. But I noticed no lacking presentations and I've not heard back from Tom. = So unless someone can point to what is lacking, I'll consider this = closed. --Sandy On Mar 11, 2014, at 1:09 PM, t.petch wrote: > Sandy >=20 > In the meeting materials for IETF89 for SIDR, 'Rsync considered = harmful' > appears twice - probably about right! - but other presentations are > lacking. Can you fix, please? >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Murphy, Sandra" > To: > Sent: Friday, March 07, 2014 3:07 AM > /listinfo/sidr >=20