From nobody Wed Feb 6 01:20:13 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E903312426E; Wed, 6 Feb 2019 01:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 dBJPnRRrdaiF; Wed, 6 Feb 2019 01:20:09 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB5E128D09; Wed, 6 Feb 2019 01:20:09 -0800 (PST) Received: from [IPv6:2a04:b900::1:1447:c7c5:626d:2660] (unknown [IPv6:2a04:b900:0:1:1447:c7c5:626d:2660]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id BEB932CBE2; Wed, 6 Feb 2019 10:20:06 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1549444806; bh=k5oJFZlL061+/y7woVR+hicuFSQfl7VEjef45qwBn98=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=uu7u8xr3TsaqVHlDMWJlh0mOLMXrjX4IMDsFpQTIFY9pZg+U15vkG7dvNQXgKmd+k r48h+HaFlJQmXvXgnKpWIG2nAPJG4vhRD/gEzYDdqeQt0APSOy8VNnYZdp7JxLslC4 E8fg3v7ypY7N6pp/zg9GTKv000YkRj22Rq4X1osA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: <4350CE4E-5E77-4101-932E-E164652F4425@nlnetlabs.nl> Date: Wed, 6 Feb 2019 10:20:06 +0100 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <0502BBB4-06E0-49B5-8A16-82FADABB7F35@nlnetlabs.nl> References: <154823467586.7485.17416366729552218933@ietfa.amsl.com> <4350CE4E-5E77-4101-932E-E164652F4425@nlnetlabs.nl> To: sidrops-chairs@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 09:20:12 -0000 Dear co-chairs, I have waited a while but saw no further comments. Can you please initiate a last-call for this version? Kind regards Tim Bruijnzeels > On 23 Jan 2019, at 10:16, Tim Bruijnzeels wrote: >=20 > Dear WG, >=20 > This version address the comments made after the unclosed last call = for -05. >=20 > * There is now no blank line between the comments and the URIs. > * Relying Parties MUST now do TLS verification (from SHOULD) and text = that was there arguing that unsafe transport is not a huge issue when = there is object security has been removed. > * Job Snijders is acknowledged for suggesting the comments section. >=20 > Please have a look and speak up if you see any remaining issues. This = should have been a simple change, but we're talking about this for = almost a year now. If I get no comments by the end of next week, then I = will try asking for last call once again, but I hope to avoid having to = make a version -07. >=20 > Thanks > Tim >=20 >=20 >> On 23 Jan 2019, at 10:11, 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 SIDR Operations WG of the IETF. >>=20 >> Title : Resource Public Key Infrastructure (RPKI) = Trust Anchor Locator >> Authors : Geoff Huston >> Samuel Weiler >> George Michaelson >> Stephen Kent >> Tim Bruijnzeels >> Filename : draft-ietf-sidrops-https-tal-06.txt >> Pages : 10 >> Date : 2019-01-23 >>=20 >> Abstract: >> This document defines a Trust Anchor Locator (TAL) for the Resource >> Public Key Infrastructure (RPKI). TALs allow Relying Parties in the >> RPKI to download the current Trust Anchor (TA) CA certificate from >> one or more locations, and verify that the key of this self-signed >> certificate matches the key on the TAL. Thus, Relying Parties can = be >> configured with TA keys, but allow these TAs to change the content = of >> their CA certificate. In particular it allows TAs to change the set >> of Internet Number Resources included in the RFC3779 extension of >> their certificate. >>=20 >> This document obsoletes the previous definition of Trust Anchor >> Locators in RFC 7730 by adding support for HTTPS URIs. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-https-tal-06 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Mon Feb 11 08:34:49 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FEA131074 for ; Mon, 11 Feb 2019 08:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vQZRNXzEpTBC for ; Mon, 11 Feb 2019 08:34:45 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E51B12008A for ; Mon, 11 Feb 2019 08:34:42 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 5939B28B0041 for ; Mon, 11 Feb 2019 11:34:41 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3E0111F804E; Mon, 11 Feb 2019 11:34:41 -0500 (EST) From: Sandra Murphy Content-Type: multipart/alternative; boundary="Apple-Mail=_0C941098-0436-42A6-9C63-3E30035C2F2D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 11 Feb 2019 11:34:44 -0500 References: <23649.35961.352370.101277@oz.mt.att.com> Cc: Sandra Murphy To: sidrops@ietf.org Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Sidrops] Fwd: AT&T/as7018 now drops invalid prefixes from peers X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:34:47 -0000 --Apple-Mail=_0C941098-0436-42A6-9C63-3E30035C2F2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Great news for RPKI deployment. One response asked for AT&T to share more about the experience. Between this and the Cloudflare announcement some months back, someday = the world might get to the point that there could be a current practice = document for deployment, initial or steady state. =E2=80=94Sandy > Begin forwarded message: >=20 > From: Jay Borkenhagen > Subject: AT&T/as7018 now drops invalid prefixes from peers > Date: February 11, 2019 at 9:53:45 AM EST > To: nanog@nanog.org > Reply-To: Jay Borkenhagen >=20 >=20 > FYI: >=20 > The AT&T/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. =20 >=20 > We continue to accept invalid route announcements from our customers, > at least for now. We are communicating with our customers whose > invalid announcements we are propagating, informing them that these > routes will be accepted by fewer and fewer networks over time. >=20 > Thanks to those of you who are publishing ROAs in the RPKI. We would > also like to encourage other networks to join us in taking this step > to improve the quality of routing information in the Internet. >=20 > Thanks! >=20 > Jay B. >=20 >=20 --Apple-Mail=_0C941098-0436-42A6-9C63-3E30035C2F2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Great news for RPKI deployment.

One response asked for AT&T to = share more about the experience.

Between this and the Cloudflare = announcement some months back, someday the world might get to the point = that there could be a current practice document for deployment, initial = or steady state.

=E2=80=94Sandy


Begin = forwarded message:

From: = Jay Borkenhagen <jayb@braeburn.org>
Subject: = AT&T/as7018 = now drops invalid prefixes from peers
Date: = February 11, 2019 at 9:53:45 AM = EST
To: = nanog@nanog.org
Reply-To: = Jay Borkenhagen <jayb@braeburn.org>

FYI:

The AT&T/as7018 = network is now dropping all RPKI-invalid route
announcements= that we receive from our peers.  

We = continue to accept invalid route announcements from our customers,
at least for now.  We are communicating with our = customers whose
invalid announcements we are propagating, = informing them that these
routes will be accepted by fewer = and fewer networks over time.

Thanks to = those of you who are publishing ROAs in the RPKI.  We would
also like to encourage other networks to join us in taking = this step
to improve the quality of routing information in = the Internet.

Thanks!

= = = = = = Jay B.



= --Apple-Mail=_0C941098-0436-42A6-9C63-3E30035C2F2D-- From nobody Mon Feb 11 08:47:13 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C4F130EBB for ; Mon, 11 Feb 2019 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 DGqMLunV38YM for ; Mon, 11 Feb 2019 08:47:07 -0800 (PST) Received: from smtpbguseast3.qq.com (smtpbguseast3.qq.com [54.243.244.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7904A131058 for ; Mon, 11 Feb 2019 08:47:05 -0800 (PST) X-QQ-mid: bizesmtp12t1549903619t04l7d0r Received: from [192.168.3.18] (unknown [118.247.10.155]) by esmtp6.qq.com (ESMTP) with id ; Tue, 12 Feb 2019 00:46:56 +0800 (CST) X-QQ-SSF: 00400000002000M0ZI70B00A0000000 X-QQ-FEAT: +IkrLX7ElIJQftKf0YEMjUhR4K3VKY0/L+7lKt05qAG0DFsKYRGsLj6q/GyiO MfpHaAnYaCuWZWsytWC5euKtB5ZKa3QRxFKr0T8HurnNCPJflcJnYM6Sw5DX0r2eObYZxDM 1Ia9HVJKPwIh12D/r/dJYhLYdZhx/9idw2qF4sQck7b8tImpCBNbyhwQEFUziYf6LRXUypZ m6KTAyYzxHZi+ffeuH9BKWdZit9x+p/8VYRazN+d65V04dG6L4Fny55KIgKo2kPJWvwKgLF RJ353eMejeA1ZKCo9o5KkgZHATIZPrCE4L9t4VmQG3iUmf X-QQ-GoodBg: 1 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Di Ma In-Reply-To: Date: Tue, 12 Feb 2019 00:46:55 +0800 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19FC2A7A-574C-467D-A0B7-079CAEF595FC@zdns.cn> References: <23649.35961.352370.101277@oz.mt.att.com> To: Sandra Murphy X-Mailer: Apple Mail (2.3445.102.3) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign2 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] Fwd: AT&T/as7018 now drops invalid prefixes from peers X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:47:12 -0000 Sandy, Thanks for sharing.=20 Glad to know another ISP to let the RPKI take effect. Is there an official statement from AT&T on this for reference?=20 Di > =E5=9C=A8 2019=E5=B9=B42=E6=9C=8812=E6=97=A5=EF=BC=8C00:34=EF=BC=8CSandr= a Murphy =E5=86=99=E9=81=93=EF=BC=9A >=20 > Great news for RPKI deployment. >=20 > One response asked for AT&T to share more about the experience. >=20 > Between this and the Cloudflare announcement some months back, someday = the world might get to the point that there could be a current practice = document for deployment, initial or steady state. >=20 > =E2=80=94Sandy >=20 >=20 >> Begin forwarded message: >>=20 >> From: Jay Borkenhagen >> Subject: AT&T/as7018 now drops invalid prefixes from peers >> Date: February 11, 2019 at 9:53:45 AM EST >> To: nanog@nanog.org >> Reply-To: Jay Borkenhagen >>=20 >>=20 >> FYI: >>=20 >> The AT&T/as7018 network is now dropping all RPKI-invalid route >> announcements that we receive from our peers. =20 >>=20 >> We continue to accept invalid route announcements from our customers, >> at least for now. We are communicating with our customers whose >> invalid announcements we are propagating, informing them that these >> routes will be accepted by fewer and fewer networks over time. >>=20 >> Thanks to those of you who are publishing ROAs in the RPKI. We would >> also like to encourage other networks to join us in taking this step >> to improve the quality of routing information in the Internet. >>=20 >> Thanks! >>=20 >> Jay B. >>=20 >>=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Feb 11 10:50:55 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CDC13111F for ; Mon, 11 Feb 2019 10:50:53 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 yCK2k3I6C0dL for ; Mon, 11 Feb 2019 10:50:52 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B08413111D for ; Mon, 11 Feb 2019 10:50:52 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 530F428B0041; Mon, 11 Feb 2019 13:50:51 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 330AC1F804E; Mon, 11 Feb 2019 13:50:51 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sandra Murphy In-Reply-To: <19FC2A7A-574C-467D-A0B7-079CAEF595FC@zdns.cn> Date: Mon, 11 Feb 2019 13:50:51 -0500 Cc: Sandra Murphy , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <67E36A7E-7778-4D43-9EF2-D5EF00A7337A@tislabs.com> References: <23649.35961.352370.101277@oz.mt.att.com> <19FC2A7A-574C-467D-A0B7-079CAEF595FC@zdns.cn> To: Di Ma X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Sidrops] Fwd: AT&T/as7018 now drops invalid prefixes from peers X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 18:50:54 -0000 Hm. Well, Jay is a/the top engineer at AT&T and a very long time visible = AT&T presence at NANOG, so when he says "is now dropping=E2=80=9D I tend = to accept that as truth. I gather you are looking for some corporate press release, from maybe a = CIO/CTO/CEO/C-something? Something suitable for convincing some other = CIO/CTO/CEO/C-something of the corporate stance behind the statement? I = don=E2=80=99t know, I have not looked for one. =E2=80=94Sandy > On Feb 11, 2019, at 11:46 AM, Di Ma wrote: >=20 > Sandy, >=20 > Thanks for sharing.=20 >=20 > Glad to know another ISP to let the RPKI take effect. >=20 > Is there an official statement from AT&T on this for reference?=20 >=20 > Di >=20 >> =E5=9C=A8 2019=E5=B9=B42=E6=9C=8812=E6=97=A5=EF=BC=8C00:34=EF=BC=8CSand= ra Murphy =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> Great news for RPKI deployment. >>=20 >> One response asked for AT&T to share more about the experience. >>=20 >> Between this and the Cloudflare announcement some months back, = someday the world might get to the point that there could be a current = practice document for deployment, initial or steady state. >>=20 >> =E2=80=94Sandy >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: Jay Borkenhagen >>> Subject: AT&T/as7018 now drops invalid prefixes from peers >>> Date: February 11, 2019 at 9:53:45 AM EST >>> To: nanog@nanog.org >>> Reply-To: Jay Borkenhagen >>>=20 >>>=20 >>> FYI: >>>=20 >>> The AT&T/as7018 network is now dropping all RPKI-invalid route >>> announcements that we receive from our peers. =20 >>>=20 >>> We continue to accept invalid route announcements from our = customers, >>> at least for now. We are communicating with our customers whose >>> invalid announcements we are propagating, informing them that these >>> routes will be accepted by fewer and fewer networks over time. >>>=20 >>> Thanks to those of you who are publishing ROAs in the RPKI. We = would >>> also like to encourage other networks to join us in taking this step >>> to improve the quality of routing information in the Internet. >>>=20 >>> Thanks! >>>=20 >>> Jay B. >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 >=20 From nobody Mon Feb 11 11:03:10 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84102131166 for ; Mon, 11 Feb 2019 11:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lhGnheT1s8zp for ; Mon, 11 Feb 2019 11:02:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E12A131154 for ; Mon, 11 Feb 2019 11:02:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gtGqx-0006hA-Db; Mon, 11 Feb 2019 19:02:51 +0000 Date: Mon, 11 Feb 2019 11:02:50 -0800 Message-ID: From: Randy Bush To: Sandra Murphy Cc: Di Ma , sidrops@ietf.org In-Reply-To: <67E36A7E-7778-4D43-9EF2-D5EF00A7337A@tislabs.com> References: <23649.35961.352370.101277@oz.mt.att.com> <19FC2A7A-574C-467D-A0B7-079CAEF595FC@zdns.cn> <67E36A7E-7778-4D43-9EF2-D5EF00A7337A@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Fwd: AT&T/as7018 now drops invalid prefixes from peers X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 19:03:08 -0000 > I gather you are looking for some corporate press release jay could not make the nanog announcement without corporate approval randy From nobody Mon Feb 11 18:31:23 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7F9129619 for ; Mon, 11 Feb 2019 18:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 oI23XMkjHET2 for ; Mon, 11 Feb 2019 18:31:16 -0800 (PST) Received: from smtpproxy21.qq.com (smtpbg297.qq.com [184.105.67.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35F7127AC2 for ; Mon, 11 Feb 2019 18:31:15 -0800 (PST) X-QQ-mid: bizesmtp22t1549938669te9ymmb4 Received: from [192.168.3.18] (unknown [118.247.10.155]) by esmtp6.qq.com (ESMTP) with id ; Tue, 12 Feb 2019 10:31:07 +0800 (CST) X-QQ-SSF: 00400000000000M0ZI70B00A0000000 X-QQ-FEAT: jLTfbrzLdoNJ46PrrgWafhTmMgk8yxYZzmtz7WmLAo/ck3z8WeuEMt93Df4OK shHDEYb+mdtwvJrpeODIZui6TTp2eh2lVwuai+Z1Fc5u4uj0NJAI8BN5+bjl30nV60kTnc9 iZPW3ElcvnlV55Zx+OB8uhheyLvVHOQsSQRq11T/h/4I1keBaUzqfTBYzVa2gGwlhJFZA51 lOwgYDG1teVxVbH34PRDRCK1NSL3ETbHGCIhYnVf4CZxA3Xus2yVEegHwZJCrbrawK8CBcx f5bTahJqgT4Ev1Co6g0RAbFYih/xCYkKTWS4kQSbk5j265cSoGSUJWUUA= X-QQ-GoodBg: 1 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Di Ma In-Reply-To: <67E36A7E-7778-4D43-9EF2-D5EF00A7337A@tislabs.com> Date: Tue, 12 Feb 2019 10:31:06 +0800 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <23649.35961.352370.101277@oz.mt.att.com> <19FC2A7A-574C-467D-A0B7-079CAEF595FC@zdns.cn> <67E36A7E-7778-4D43-9EF2-D5EF00A7337A@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.3445.102.3) X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign1 X-QQ-Bgrelay: 1 Archived-At: Subject: Re: [Sidrops] AT&T/as7018 now drops invalid prefixes from peers X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 02:31:22 -0000 Sandy, > =E5=9C=A8 2019=E5=B9=B42=E6=9C=8812=E6=97=A5=EF=BC=8C02:50=EF=BC=8CSandr= a Murphy =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hm. >=20 > Well, Jay is a/the top engineer at AT&T and a very long time visible = AT&T presence at NANOG, so when he says "is now dropping=E2=80=9D I tend = to accept that as truth. >=20 > I gather you are looking for some corporate press release, from maybe = a CIO/CTO/CEO/C-something? Something suitable for convincing some other = CIO/CTO/CEO/C-something of the corporate stance behind the statement? I = don=E2=80=99t know, I have not looked for one. >=20 Yes. It would be lovely that I can reference some corporate press = release to share with China Internet Community, to let them know = RPKI-based OV is making progress worldwide especially in big ISPs such = as AT&T.=20 Di > =E2=80=94Sandy >=20 >=20 >=20 >> On Feb 11, 2019, at 11:46 AM, Di Ma wrote: >>=20 >> Sandy, >>=20 >> Thanks for sharing.=20 >>=20 >> Glad to know another ISP to let the RPKI take effect. >>=20 >> Is there an official statement from AT&T on this for reference?=20 >>=20 >> Di >>=20 >>> =E5=9C=A8 2019=E5=B9=B42=E6=9C=8812=E6=97=A5=EF=BC=8C00:34=EF=BC=8CSan= dra Murphy =E5=86=99=E9=81=93=EF=BC=9A >>>=20 >>> Great news for RPKI deployment. >>>=20 >>> One response asked for AT&T to share more about the experience. >>>=20 >>> Between this and the Cloudflare announcement some months back, = someday the world might get to the point that there could be a current = practice document for deployment, initial or steady state. >>>=20 >>> =E2=80=94Sandy >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: Jay Borkenhagen >>>> Subject: AT&T/as7018 now drops invalid prefixes from peers >>>> Date: February 11, 2019 at 9:53:45 AM EST >>>> To: nanog@nanog.org >>>> Reply-To: Jay Borkenhagen >>>>=20 >>>>=20 >>>> FYI: >>>>=20 >>>> The AT&T/as7018 network is now dropping all RPKI-invalid route >>>> announcements that we receive from our peers. =20 >>>>=20 >>>> We continue to accept invalid route announcements from our = customers, >>>> at least for now. We are communicating with our customers whose >>>> invalid announcements we are propagating, informing them that these >>>> routes will be accepted by fewer and fewer networks over time. >>>>=20 >>>> Thanks to those of you who are publishing ROAs in the RPKI. We = would >>>> also like to encourage other networks to join us in taking this = step >>>> to improve the quality of routing information in the Internet. >>>>=20 >>>> Thanks! >>>>=20 >>>> Jay B. >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >>=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Feb 12 18:25:12 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49C4130EE7 for ; Tue, 12 Feb 2019 18:25:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 ewCwJvL8M7Hn for ; Tue, 12 Feb 2019 18:25:06 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E557C12958B for ; Tue, 12 Feb 2019 18:25:05 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id o125so502008qkf.3 for ; Tue, 12 Feb 2019 18:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5oB6RUNVz6fwtGBJQdW/Ky/l5EAvQwj3X5akLI62Hys=; b=gWBk2ptHxlnRQuk5OwyuN6VXwgc9Lo00A7nQbKPfKFyqK9yLvo3sGnqDKyIMli84EF ZRG5TevCYxyj1W75cnxOaapR/Tiq+GOYv1jbIY5yGWopnIimMI5xVM2DVvvw6iIxDAOU 1DIpDUy5qhTS8+3pNqE9/evTiqmWq9FIJO720= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5oB6RUNVz6fwtGBJQdW/Ky/l5EAvQwj3X5akLI62Hys=; b=UaWdAvqM8oKaBnSWW/BlKZMXuQCADbQ6vSF/+ChNOdmwW32Y4c0JqScTTvgzHBZ8dW O4j4yI35/3JueR2GGCr0HGCd0zo53cl3TH0dxokWtXLKeZe0JUIKY49ZobijjWOGJxO/ aG2E5JQdWxSL8Z1P/eeh8C+fkQ4brw3DuoWC0Ic2BIuCR3lBAlcpgQ+xh9ep0FkMiul5 k1ayKwfK5SGCW81Az/OJ1YTYEQovC7jzCnA+xrlQoh+0LE9KS5nYOZfJu+s8sDOcIBXW DMxeXqcs7Fgnqba9/gkW4ooKDGOjuoLTUISXZ/P9+BDU0N2oHWQ+ZwS03yIZ+S1WPZDp DEuw== X-Gm-Message-State: AHQUAubeBrRDMHFTL4RL+xblHZqFKKk1U8uMPSr80RDuWieo56pgFeMi Tjl8XfFCakPWYe4liBUjBCLr/w== X-Google-Smtp-Source: AHgI3IYKWAL28Pu19ZQ3DOVReJfHh/3gTYpQy7/QKWViDTWn/ZvSsDFrimMzGJz4rX/ORE7Xz+LnxQ== X-Received: by 2002:a37:98d:: with SMTP id 135mr3913146qkj.333.1550024704664; Tue, 12 Feb 2019 18:25:04 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.25.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:25:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154830586386.7517.12515642346949342885.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:25:01 -0500 Cc: The IESG , SIDROps Chairs , Chris Morrow , SIDR Operations WG , draft-ietf-sidrops-rtr-keying@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <587443F2-D022-4109-AFF7-E6C06091E151@sn3rd.com> References: <154830586386.7517.12515642346949342885.idtracker@ietfa.amsl.com> To: Eric Rescorla , Alissa Cooper X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Eric Rescorla's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:25:10 -0000 > On Jan 23, 2019, at 23:57, Eric Rescorla wrote: >=20 > Eric Rescorla has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D13996 >=20 >=20 >=20 > DETAIL > S 2. >>=20 >> Operators are free to use either the router-driven or = operator-driven >> method as supported by the platform. Regardless of the method >> chosen, operators first establish a protected channel between the >> management system and the router. How this protected channel is >> established is router-specific and is beyond scope of this = document. >=20 > This seems rather under-specified. Given that we know that people are > not careful about this, I think you need to specify some sort of > minimum requirements for this channel. That need not be a particular > protocol, but it needs to specify the security properties it provides. > I see you have some SHOULD-level language later, but I think you need > MUST level, and as noted below, I think the guidance is wrong. Alissa had a comment in the same vein so I hope to address both here. In the future, routers may come with key material burned into them that = the router can then use to securely communicate with the operator (e.g., = brewski or something akin to what=E2=80=99s in s8), but the reality is = that the routers arrive with nada on them. So, s2 is about how the = operator gets keying material into the router that it can then later use = to secure communications with the operator. There=E2=80=99s two ways to = get this done and there=E2=80=99s an initial leap of faith that has to = happen (i.e., there=E2=80=99s -no- security on first connect): - the operator connects directly through the =E2=80=9Ccraft=E2=80=9D = port and =E2=80=9Csquirts=E2=80=9D the keying material in and configures = the router to use SSH (or whatever) for future connections. It=E2=80=99s = also going to set up it=E2=80=99s AS number and whatever else goes in = the config file to make the protocol run. - the operator connects over a network port and squirts the keying = material in and configures the router to use SSH (or whatever) for = future connections. But, chances are very high that the operator = connects to the router via SSH, and probably with some generic lame pwd. So while I agree we want to better specify what kind of protections this = channel should provide I am unsure what to write if the router has no = keying material whatsoever when the operator gets first it. > S 5.2. >> the BGP Identifier when it sends the CSR to the CA. >>=20 >> Even if the operator cannot extract the private key from the = router, >> this signature still provides a linkage between a private key and = a >> router. That is, the operator can verify the proof of possession >> (POP), as required by [RFC6484]. >=20 > It's not clear to me what is being claimed in terms of PoP here. As I > understand it, the certificate is a binding between the AS number/BGP > identifier pair and the public key, but if neither of those is in the > PKCS#10 request, then they're not signed over by the private key, and > so PoP isn't really operative. The relevant question is whether if I > obtain the PKCS#10 request I can obtain a certificate for an identity > other than the intended one. 1st baed on somebody else=E2=80=99s comment we=E2=80=99re moving that = paragraph to s5.1. It=E2=80=99s out of place in s5.2 because If the = operator can generate the key well they certainly have access to it. The POP we=E2=80=99re getting is that the router has the key. If = there=E2=80=99s nothing in the CSR but the operator is the middle-man = then the operator can tell the CA this CSR goes with this name though = some other means. > S 5.2.1. >> ensure the returned private key did in fact come from the = operator, >> but this requires that the operator also provision via the CLI or >> include in the SignedData the RPKI CA certificate and relevant >> operator's EE certificate(s). The router should inform the = operator >> whether or not the signature validates to a trust anchor; this >> notification mechanism is out of scope. >=20 > I don't understand what security this is intended to provide. As I > understand it, the way this works is that the operator signs the > PKCS#8 package and then sends it to the router, which verifies the > signature. This verification is performed based on a key configured by > the operator, right? But in that case, if someone obtains operator > access to the router, they can just configure their own key, thus > bypassing the signature check. You are right on the first part. =20 The thing that is probably not well explained in s4 is that physical = attacks are thwarted by initial operator configurations, e.g., setting = pwd, require SSH cert auth, configuring the AS number, etc. Granted = this configuration is not going to is not going to stop nation state = attackers, but we=E2=80=99re not trying to address that. So, I am = hoping that some additional words in s4 about additional configurations = will address this, but I wanted to check with you before proposing a = bunch of words that would miss the mark you=E2=80=99re aiming at. > Secondarily, I don't understand how this works if the RPKI CA > certificate is included in the SignedData, because then how do I > validate it against a trust anchor. The TA is installed as part of the set-up procedure in s4. > Finally, how does the router know > which of the large number of EEs signed by the RPKI CA it should > accept signed PKCS#8 messages from. Again, this goes back to the operator configurations. Once, the router = has been configured with its ASN it will be able to check that the = certificate used to sign the key includes that ASN. > S 6. >> private key it holds corresponds to the returned public key. If = the >> operator saved the PKCS#10 it can check this correspondence by >> comparing the public key in the CSR to the public key in the = returned >> certificate. If the operator has not saved the PKCS#10, it can = check >> this correspondence by generating a signature on any data and = then >> verifying the signature using the returned certificate. >=20 > It is not clear to me that this is correct. You seem to be assuming > that it given a key pair (K_priv, K_pub), it is not possible to > generate a new key K_pub' that will validate signatures made with > K_priv. This isn't ordinarily an assumption we make of digital > signature systems. This is just a consistency check and you are right what you would do is = either check that the public sent in the CSR matches the one in the = returned certificate if you saved the CSR or regenerate the public from = the private and then check that it matches the one returned in the = certificate if you did not save the CSR. OLD: If the operator has not saved the PKCS#10, it can check this correspondence by generating a signature on any data and then verifying the signature using the returned certificate. NEW: If the operator has not saved the PKCS#10, it can check this correspondence by regenerating the public key from the private and then verifying the regenerate public key matches the public key returned in the certificate. > S 8. >> the CA prior to operator initiating the router's CSR. CAs = use >> authentication material to determine whether the router is >> eligible to receive a certificate. Authentication material at = a >> minimum includes the router's AS number and BGP Identifier as >> well as the router's key material, but can also include >> additional information. Authentication material can be >=20 > Surely it also includes some information that allows the router to > prove it is entitled to a key with that AS and BGP identifier, but I'm > not seeing this here. I guess maybe I am confused because I thought that=E2=80=99s what the = entire bullet was about. The operator is priming the CA with = information that will allow the router to begin contacting the CA = without the operator in the middle. > S 12.1. >> CSR you sent; the certificate will include the subject name, = serial >> number, public key, and other fields as well as being signed by = the >> CA. After the CA issues the certificate, the CA returns the >> certificate, and posts the certificate to the RPKI repository. = Check >> that the certificate corresponds to the private key by verifying = the >> signature on the CSR sent to the CA; this is just a check to make >=20 > This is not the right check. The CSR contains the public key. If you > want to check, make sure it is identical to the one in the cert. Changed to: Check that the certificate corresponds to the public key contained in the CSR sent to the CA; ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > S 1. >> These two methods differ in where the keys are generated: on the >> router in the router-driven method, and elsewhere in the >> operator-driven method. Routers are required to support at least = one >> of the methods in order to work in various deployment = environments. >> Some routers may not allow the private key to be off-loaded while >> others may. While off-loading private keys would ease swapping = of >=20 > Nit: "off-load" has multiple meanings. I would suggest =E2=80=9Cexported= " ack > S 1. >> operator-driven method. Routers are required to support at least = one >> of the methods in order to work in various deployment = environments. >> Some routers may not allow the private key to be off-loaded while >> others may. While off-loading private keys would ease swapping = of >> routing engines, exposure of private keys is a well known = security >> risk. >=20 > This is a somewhat shallow treatment of this. Specifically: >=20 > 1. There are multiple ways in which a device might allow a key not to > be exported. For instance, there might not be a command, but it might > be in unencrypted NVRAM. Or, it might be in an HSM. These have very > different security properties. >=20 > 2. There are designs which allow a key to be moved from device to > device without exposure, e.g.,, a hardware token. I agree it=E2=80=99s a little/lot shallow, but I am not sure what = digging deeper is going to accomplish here especially in the intro. > S 1. >> In the router-driven method, the router generates its own >> public/private key-pair. >>=20 >> The router-driven method mirrors the model used by traditional = PKI >> subscribers; the private key never leaves trusted storage (e.g., >> Hardware Security Module). This is by design and supports = classic >=20 > This seems overly concrete. The router may or may not have an HSM, but > there are benefits even if it does not. Yeah I know, but honestly I am not sure how to fix this other than = laying out all of the deployment options. And, like I just do not have = the energy for that. > S 1. >> ensure that no one can impersonate the subscriber. For = non-humans, >> this method does not always work. For example, when an operator >> wants to support hot-swappable routers, the same private key = needs to >> be installed in the soon-to-be online router that was used by the = the >> soon-to-be offline router. This motivated the operator-driven >> method. >=20 > I'm not following this explanation, as it's routine for Internet > servers to have keys in software and be able to transfer them from > device to device. This is, after all, what PEM files do I tweaked this based on BenK=E2=80=99s comment. While it is true that = some keep them in software not all do. There was concern that if = you=E2=80=99re running with a HSM that you couldn=E2=80=99t get the key = out to put it in another router=E2=80=99s HSM. And, yeah this is all = kind of odd because you might be able to just move the HSM over or use a = networked HSM. But, that was the concern: that there would be a = one-to-one relationship of key to router and if the router goes down = you=E2=80=99re SOL.=20 > S 1. >> acting as the intermediary. Section 8 describes another method = that >> requires more capable routers. >>=20 >> Useful References: [RFC8205] describes gritty details, [RFC8209] >> specifies the format for the PKCS#10 certification request, and >> [RFC8208] specifies the algorithms used to generate the PKCS#10's >=20 > Nit "The PKCS#10's signature" is not grammatical I will drop the ' > S 2. >> method as supported by the platform. Regardless of the method >> chosen, operators first establish a protected channel between the >> management system and the router. How this protected channel is >> established is router-specific and is beyond scope of this = document. >> Though other configuration mechanisms might be used, e.g. = NetConf >> (see [RFC6470]), the protected the protected channel between the >=20 > "the protected the protected=E2=80=9D Couple of people noticed this. Fixed. > S 3. >> bis] to return the issued certificate, >>=20 >> - Using FTP or HTTP per [RFC2585], and >>=20 >> - Using Enrollment over Secure Transport (EST) protocol per >> [RFC7030]. >=20 > I'm surprised you don't list ACME. This way predates ACME. > S 5. >> is sometimes referred to as a Certificate Signing Request (CSR), = may >> be generated by the router or by the operator. >>=20 >> The PKCS#10 request SHOULD be saved to enable verifying that the >> returned public key in the certificate corresponds to the private >> used to generate the signature on the CSR. >=20 > This is generally not necessary. In most systems, the private key > syntax either includes the public key or the public key can be > generated from the private key. Agreed, but somebody was adamant about including one way you could do = this so I just left it in. > S 5.1. >>=20 >> NOTE: If a router were to communicate directly with a CA to have = the >> CA certify the PKCS#10 certification request, there would be no = way >> for the CA to authenticate the router. As the operator knows the >> authenticity of the router, the operator mediates the = communication >> with the CA. >=20 > This doesn't seem like it's necessarily true. For instance, with ACME > the operator could provide the router with a credential sufficient to > authenticate the request. Ben had a similar comment so I tweaked it. > S 5.2.1. >>=20 >> 5.2.1. Using PKCS#8 to Transfer Private Key >>=20 >> A private key can be encapsulated in a PKCS#8 Asymmetric Key = Package >>=20 >> [RFC5958] and should be further encapsulated in Cryptographic = Message >=20 > SHOULD? Yes I think that was the intention. > S 10. >> Private key protection in transit: Mistakes here are, for all, >> practical purposes catastrophic because disclosure of the = private >> key allows another entity to masquerade as (i.e., impersonate) = the >> signer; transport security is therefore strongly RECOMMENDED. = The >> level of security provided by the transport layer's security >> mechanism SHOULD be commensurate with the strength of the = BGPsec >=20 > I'm not sure "commensurate" is what's needed here. For instance, the > transport channel might be much more secure than the router key (e.g., > P-521 and AES-256 with a RSA-2048 router key). >=20 > More generally, it's not clear to me that these are really connected > at all, as the threat environments are totally different. As noted > above, I believe you should just specify a minimal level. Commensurate is probably the wrong word, I was shooting for "at least as = good as." > S 12.1. >> and integrity and replay protection. >>=20 >> Appendix B. The n00b Guide to BGPsec Key Management >>=20 >> This appendix is informative. It attempts to explain all of the = PKI >> technobabble in plainer language. >=20 > All fields have jargon, but generally deriding another field's > language as "technobabble" doesn't seem that helpful. Honestly, I was kind of poking fun at myself, but I get your point. I = changed it to: explain some of the PKI lingo in plainer language > S 12.1. >> BGPsec speakers send signed BGPsec updates that are verified by = other >> BGPsec speakers. In PKI parlance, the senders are referred to as >> signers and the receivers are referred to as relying parties. = The >> signers with which we are concerned here are routers signing = BGPsec >> updates. Signers use private keys to sign and relying parties = use >> the corresponding public keys, in the form of X.509 public key >=20 > They're not in the form of public key certificates, they are carried > in certificates. ack > S 12.1. >> that will generate the key pair for the algorithms referenced in = the >> main body of this document; consult your router's documentation = for >> the specific commands. The key generation process will yield >> multiple files: the private key and the public key; the file = format >> varies depending on the arcane command you issued, but generally = the >> files are DER or PEM-encoded. >=20 > Actually, it may or may not generate multiple files. That's > implementation specific. Fair point. I will replace with: r/multiple files: the private key and the public key /one or more files for the private key and the public key spt= From nobody Tue Feb 12 18:25:30 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA511295EC for ; Tue, 12 Feb 2019 18:25:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 w_kPtIEeL6Tu for ; Tue, 12 Feb 2019 18:25:15 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D942130EF2 for ; Tue, 12 Feb 2019 18:25:11 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id x6so486972qki.6 for ; Tue, 12 Feb 2019 18:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BFJZvWS/NvHwRoGyPQCwHn3GFk9alp9DRh5NMWvHW0M=; b=ab/hCLJYnjSIKNKuuUYikh5gDr4SyaoKfkRwqPQCphBJDEMKTu57REhCVnSyhqOcBG AaFC3vOBCkHvFq4wXjqw+t7mllGBiuoO23IDkBBr4kigcg0JO+EED9cwVDM+ivfnz+6u mPf6phVYF/ZR7WoMJe0OTxhgRKC/kyLI75aS8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BFJZvWS/NvHwRoGyPQCwHn3GFk9alp9DRh5NMWvHW0M=; b=PULEK64NyKX3Yv42xNArzki4lKh8KzrKX+rCY71W4u0DKh3Y/eqbxc1/wQAAmTuG17 udbLrhMDEYvnky4717yWd6bAz+Cl/jVhUJPxBGxz6Zt1d0Wvk/r1kW2w3p9E2gLaSvxB F35M9QLUgiF1skLXdSvxYoIJtKrLgq4uAYenUolBdboQFHVVRDtzO9c6vlqFENteBA46 G8TRTFJnFkRlav9+BC74Zxzwa/x44I8Pz4sxO1fl9kEX4eVuKCVZMCGgcBN7cR3lbGAT n80pSy9cvCyVei+qhfHy136n9jM1e5HS1b2zTUQcRmRVR9IMoWP1OYxQT/TaRRtCB4M7 Y9Tg== X-Gm-Message-State: AHQUAubkFGiYTRDSISK+SO2fp/+uGFo872ANbpJAIku6V0mPa4nufoxu OYFxqzgnUj7aLzkPScK27wDeNg== X-Google-Smtp-Source: AHgI3IaIxfpMVsQRNQRTqc54pdOvWM1QwXLGLUAQxuZxzG2ViHbUnkJBptfEt8YmfVEity0DgleIEg== X-Received: by 2002:a37:b482:: with SMTP id d124mr5057485qkf.168.1550024710192; Tue, 12 Feb 2019 18:25:10 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.25.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:25:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154807116197.8204.4725884576566449203.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:25:08 -0500 Cc: The IESG , draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154807116197.8204.4725884576566449203.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-sidrops-rtr-keying-03=3A_=28with_COMMENT=29?= X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:25:17 -0000 > On Jan 21, 2019, at 06:46, Mirja K=C3=BChlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I would recommend to remove the normative language from Appendix A = ("SHOULD" in > the first sentence) as this is, I think, covered in the security = considerations > section. If not, it might be worth moving Appendix A to the main body = of the > document. You are right it is addressed in the SecCon so I will do the swap. spt From nobody Tue Feb 12 18:25:46 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996C51295EC for ; Tue, 12 Feb 2019 18:25:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 SXM1con0Vzo5 for ; Tue, 12 Feb 2019 18:25:37 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA299130EE1 for ; Tue, 12 Feb 2019 18:25:33 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id w4so975623qtc.1 for ; Tue, 12 Feb 2019 18:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BDL7xo2VpmHqJiQXi1yy4mHQ/uieowJXQgVkPQ4glQA=; b=MuTXfsYxf+kgOtbnLj5eQ+T5TjRkroqcnPRIzFgX4lALwCkSdtmXZw/lAUNdQDu42P 4g26vBaqcEpsRrcl2roXoVHQLDwzKhUsDOwFDTWtKKkBTAg82pvejPAh4Pa7ALr4K8Jn ZvNkFhEThrh3IKCu6L07NphTRfY/pnDrln1g4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BDL7xo2VpmHqJiQXi1yy4mHQ/uieowJXQgVkPQ4glQA=; b=ahXAWfsip2Gdjl6yiioJtN3NJES+qHfAzvvtgC42m70/jDF5ZIk2AnlK8pfHH6L5J/ 05bacFK6kOd9KbovrdTLSKqtRBc0VZkiOeJ/BQRDPNEKbaONIBWz8nvzvDVkNFnDk6bg 1PpOGGG7k7JcOVXV9nopOxdk3qRPnFCNKtG1RXU2/cLQIDx57/zSeke8U2OeWoEw2YqC zv7idZodzO3PYGMgmmbDP9WnW2VVz1/fixwhqzMOUYmznKNn5U48H3KOpPyHn7wRupM/ D5fO1+zabJDG/vIVAtpJocoT7gXw7gNc1IBNABMfu5fR/62fkJknLjaQAsP3BZkSyYZC bKbw== X-Gm-Message-State: AHQUAubLrSmoZcUs+UYS6QP7RgpnsBe1KSQlCLMl2MG4ElhHRCWif3Bl 0FL2c2Fcw5t472cO5Hwr6z2mdQ== X-Google-Smtp-Source: AHgI3Iattq7+GbLdkgvBDmZ1067ikNwvtMsH1wjEHTQ23eaFO5Rl6sdy04e9rtfV0EzqyrEGnrMTMw== X-Received: by 2002:ac8:1c5d:: with SMTP id j29mr5224590qtk.113.1550024733024; Tue, 12 Feb 2019 18:25:33 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.25.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:25:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154826560230.7563.12584828485918011085.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:25:31 -0500 Cc: The IESG , draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , SIDROps Chairs , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <6A4B0CAF-004F-4FB8-8A0A-A2F155308DF0@sn3rd.com> References: <154826560230.7563.12584828485918011085.idtracker@ietfa.amsl.com> To: Alvaro Retana X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:25:40 -0000 > On Jan 23, 2019, at 12:46, Alvaro Retana = wrote: >=20 > Alvaro Retana has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > (1) I don't really have a strong objection for this document being a = BCP.=20 > However, while documenting two different methods, there is no clear = indication > of "what is believed to be the best" [rfc2026], or even better, which = method > should be used in what situations. I understand that operators have = different > preferences/needs and that prescribing one method as the default in = not the > right thing to do. >=20 > I would really like to see some text (maybe a "Deployment = Considerations" > section) that talks about when one or the other might be = preferred/considered. Right so I am hoping that Randy=E2=80=99s answer helped here. The only = thing I will add is that it really depends on what gear you buy so in = some sense I am kind of wobbly on whether we should pick one. > (2) =C2=A74: s/BGP Identifier [RFC4271]/BGP Identifier [RFC6286] Good catch! > (3) =C2=A74: "In the case where the operator has chosen not to use = unique per-router > certificates, a BGP Identifier of 0 MAY be used." rfc6286 defines the = BGP > Identifier as always being non-zero. rfc8209 says that "if the same > certificate is issued to more than one router (and hence the private = key is > shared among these routers), the choice of the router ID used in this = name is > at the discretion of the Issuer." It seems to me that it doesn't = matter which > ID is used...it just can't be 0. The simple fix is to just remove the = sentence. Agreed. > (4) =C2=A78: "Enabling the router-to-CA connectivity MAY require = connections to > external networks (i.e., through firewalls, NATs, etc.)." That "MAY" = is out of > place because this sentence is just stating a fact. Can do r/MAY require/requires > (5) =C2=A78: "Note that the checks performed by the router in Section = 7...SHOULD be > performed." Besides confirming the checks from =C2=A77, I'm not sure = what this > sentence really contributes...but I do think that the "SHOULD" is out = of place > because the Normative language is already in =C2=A77. These are just consistency checks. > (6) Nits > s/used by the the/used by the > s/corresponds to the private used/corresponds to the private key used fixed Cheer, spt From nobody Tue Feb 12 18:25:53 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B28130F0F for ; Tue, 12 Feb 2019 18:25:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 o5mukQpDqphp for ; Tue, 12 Feb 2019 18:25:43 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90066130F1C for ; Tue, 12 Feb 2019 18:25:43 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id b8so914645qtr.9 for ; Tue, 12 Feb 2019 18:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3FBA0OEVoG+xb/5rwiXJUTl002lmng9vdS3hQ5Qv6og=; b=Hv2PT1nRTesze24jBEQw6tfPqHOTNXdZ6/WVmazh+bxMpHd/3gbfu8mKBnc0RrhB4L c8Xf52pYkGg+HzNK/M1oHovhuMYkJesbWLWyhpfkYJD1bFY4oNWTyMfecdYMS6z8s6A3 sftjWvktVYCJWIx4E3tFVcYFvpSkys0Jufsfw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3FBA0OEVoG+xb/5rwiXJUTl002lmng9vdS3hQ5Qv6og=; b=s12BTIi3zCfAvE72QCwo6SRmNfIG/iiZQTtMK8AyGA1F6maYYpbVGw/2oc8NGBc54h Xhtxh12asND5iUO6k+VjMkX7Q28AB97Vo869TEQssKdM5a5j1ahSNN6Oo1udfF+pKKoZ stbATXZPyedrmoi1z+r/udwaPFvDvKwfsT95Mmtwb7QIA0yZIGsRt3NtWYAa+kJosQ5h bawKo/ep6XTowTZLxy4yPSYu0mFsODAaCEu8JawvPmj/6x8b81W3OCYohl0mH6RSym3J PKrm7YtdbBaMOF9bqZoACvBI2sQApG2DTI6jkFBx55W/JugORFIZdaoOtM9aM3Spjyqn QreQ== X-Gm-Message-State: AHQUAub1ySiipXao6qdTrQnMQQGIED53TvmEKWuWKSE2fxqzHibNXMNl 9OeRH++l6RA/ghiKX9IoeSPIpg== X-Google-Smtp-Source: AHgI3IZGIEDTl5h6vEvEgRpTG+s69QYdwlWuresunsQH7+MSYNW0kQ3SI2uP/1nkYLPcFcB5a+bdfw== X-Received: by 2002:aed:39e8:: with SMTP id m95mr5242906qte.317.1550024742536; Tue, 12 Feb 2019 18:25:42 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.25.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:25:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:25:40 -0500 Cc: The IESG , Chris Morrow , SIDROps Chairs , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com> References: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> To: Benjamin Kaduk , draft-ietf-sidrops-rtr-keying@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:25:47 -0000 > On Jan 21, 2019, at 12:27, Benjamin Kaduk wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I know the intended status has been beaten to near death already, but = I > could see this as Informational as well as BCP. This horse has been flogged. I will do whatever I=E2=80=99m told :) > Section 1 >=20 > For example, when an operator > wants to support hot-swappable routers, the same private key needs = to > be installed in the soon-to-be online router that was used by the = the > soon-to-be offline router. This motivated the operator-driven > method >=20 > As the secdir review notes, there is no need to copy private keys to = hot-swap routers > (unless there is something special about the "hot-swap" case that = nullifies > the arguments he made?). >=20 > It rather seems that we should avoid framing this behavior as = justified by > a need for hot-swapping, but rather as something that people do to = work > around processes that do not admit the more secure workflow, as an > operational reality. Would something like the following work: The operator-driven model is motivated by ensuring the network = operates. In some deployments, the same private key needs to be installed in the soon-to-be online router that was used by the the soon-to-be offline router (i.e., operators need to support = hot-swappable routers. BTW - I am totally open to wording suggestions. > Section 2 >=20 > (see [RFC6470]), the protected the protected channel between the >=20 > nit: duplicate "the protected=E2=80=9D fixed > Section 5 >=20 > The PKCS#10 request SHOULD be saved to enable verifying that the > returned public key in the certificate corresponds to the private > used to generate the signature on the CSR. >=20 > I mostly assume this is done by the party that generates the CSR, = though > perhaps one could read it as being done on the router always. (I = guess > later on we do recommend both the operator and router to do this > verification.) This could be reworded, though, either to remove the = 2119 > language ("Retaining the CSR allows for verifying that [...]" or to = apply > to the actual verification as opposed to just the saving. I am all about dropping 2119-lang where we can so will reword as = suggested: Retaining the CSR allows for verifying that the returned public key in the certificate corresponds to the private used to generate the signature on the CSR. > Section 5.1 >=20 > NOTE: If a router were to communicate directly with a CA to have the > CA certify the PKCS#10 certification request, there would be no way > for the CA to authenticate the router. As the operator knows the > authenticity of the router, the operator mediates the communication > with the CA. >=20 > nit: I think that the thing we care about here is the CA's ability to = show > that the request is authorized. The operator is assumed to have an > account/relationship with the CA and a channel via which to authorize > cert-signing requests. Yes > In particular, "no way" is a rather strong > statement, and would seem to deny the possibility of a three-party = workflow > where the router sends the CSR to the CA but the operator logs in to = the CA > independently and is presented with a list of pending requests to = approve. > (It would also preclude the operator from delegating their = authorization at > the CA to the router, as described in Section 8.) Okay fair point. Maybe we reword it to say: NOTE: The CA needs to now that the router-generated CSR is authorized. The easiest way to accomplish this for the operator to mediate the communication with the CA. Other workflows are possible, e.g., where the router sends the CSR to the CA but the operator logs in to = the CA independently and is presented with a list of pending requests to = approve. Again, totally open to word smithing. > Section 5.2 ("Operator-Generated Keys") >=20 > Even if the operator cannot extract the private key from the router, > this signature still provides a linkage between a private key and a > router. That is, the operator can verify the proof of possession > (POP), as required by [RFC6484]. >=20 > This paragraph seems a bit of a non-sequitur -- if the operator just > generated the key, it sure isn't going to need to extract the private = key > from the router to sign something using it! Yeah if they just made it they certainly have access to it. The concern = was really more about router-driven models where there=E2=80=99s now way = to get the private out so this paragraph ought to move to s5.1. > Section 6 >=20 > In the operator-generated method, the operator SHOULD extract the > certificate from the PKCS#7 certs-only message, and verify that the > private key it holds corresponds to the returned public key. If the >=20 > nit: "private key it holds" is the one the operator holds, not the = PKCS#7 > certs-only message. It's probably worth disambiguating, here. I think you are suggesting the following: r/private key it holds corresponds to the returned public key/ private key the operator holds corresponds to the returned public key in = the PKCS#7 certs-only message. > Section 7 >=20 > NOTE: The signature on the PKCS#8 and Certificate need not be made = by > the same entity. Signing the PKCS#8 permits more advanced > configurations where the entity that generates the keys is not the > direct CA. >=20 > Why are we talking about PKCS#8 (asymmetric key transport) signatures = here > at all? This is the section about installing certificates! I guess I = am > not terribly familiar with the RPKI, but in the Web PKI at least it's = quite > uncommon for the CA to be generating the private keys, so mentioning = these > together is a non sequitur to me. In the WebPKI it=E2=80=99s really uncommon, but it is done in lots of = other places, e.g., little devices with no human interface. Some entity = creates the keys enmass, farms =E2=80=98em out when requested, and these = farmed keys are verified to make sure they come from the trusted key = generation source. But more to the point, the note is there because we do discuss PKCS#8 in = s5.2.1 and it seemed like a good place to say hey - don=E2=80=99t assume = the signatures are from the same place. In most cases they will be but = not necessarily. > Section 8 >=20 > More PKI-capable routers can take advantage of this increased > functionality and lighten the operator's burden. Typically, these >=20 > nit: most readers will not bind "this" to the right thing and will = instead > be left confused. I am thinking I could just strike the =E2=80=9Dthis=E2=80=9D. > Why do we not mention the need to get the manufacturer-installed key > material (or information thereof) to the operator? But, I thought that=E2=80=99s what the entire 1st paragraph is about? > When a router is so configured, the communication with the CA SHOULD > be automatically re-established by the router at future times to > renew or rekey the certificate automatically when necessary (See > Section 9). This further reduces the tasks required of the operator. >=20 > Mentioning renewing certificates is natural, as they have a stated end = time > to prepare for. Re-keying certificates is something of a different = matter, > and it would be nice to provide (a link to) some guidance on what > timescales at which to rekey, if we're mentioning rekeying here. > (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, = but I > did not see much concrete on this point.) We=E2=80=99d end up in a circular reference point then since they point = to our document. The thing here is that the lifetimes of the keys are = entirely dictated by the PKI CPs and there=E2=80=99s more than one place = to point. Not sure I have good fix for this one. Randy/Keyur? > Section 9.4 >=20 > Currently routers often generate private keys for uses such as SSH, > and the private keys may not be seen or off-loaded from the router. > While this is good security, it creates difficulties when a routing > engine or whole router must be replaced in the field and all = software > which accesses the router must be updated with the new keys. Also, >=20 > This seems to be talking about key management for keys other than > BGPsec-signing keys. Isn't that out of scope for this document? On the one hand yes, but on the other hand no. Because this section is = about overall router security we felt it ought to be included and I do = not think that it hurts to keep it. And, like people screw this up = regularly. > any network based initial contact with a new routing engine requires > trust in the public key presented on first contact. >=20 > To allow operators to quickly replace routers without requiring > update and distribution of the corresponding public keys in the = RPKI, > routers SHOULD allow the private BGPsec key to be inserted via a >=20 > Making this a SHOULD is perhaps an overstatement, since AFAICT this > functionality is not useful for the stated purpose unless the operator = has > access to private keys directly (whether by virtue of the operator = having > generated the keys or an extraction interface on the current routers). > This is an inherent tradeoff, as stated, between the delay in > update/distribution of public keys in the RPKI vs. reducing the risk = of > unauthorized key access. I'm not making this a Discuss point because = it's > not exactly my tradeoff to make, but I do want to be sure that this is > actually the tradeoff that SIDROPS wants to present to the community. It=E2=80=99s definitely been in the draft for a while now. I guess = folks can speak up if they think it=E2=80=99s wrong. Randy/Keyur? > protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This > lets the operator escrow the old private key via the mechanism used > for operator-generated keys, see Section 5.2, such that it can be = re- > inserted into a replacement router. The router MAY allow the private > key to be to be off-loaded via the protected channel, but this = SHOULD > be paired with functionality that sets the key into a permanent non- > exportable state to ensure that it is not off-loaded at a future = time > by unauthorized operations. >=20 > This last sentence is a somewhat different topic and could probably = stand > alone as its own paragraph. This would also provde the opportunity to > clarify that this offload interface is intended for use in conjunction = with > key generation, and the permanent non-exportable state to be applied > thereafter. How about: The router MAY allow the private key to be to be off-loaded via the protected channel after key generation, but this SHOULD be paired with functionality that sets the newly generated key into a permanent = non- exportable state to ensure that it is not off-loaded at a future time by unauthorized operations. > Appendix A >=20 > I agree with Mirja about the duplication of content and thus non-need = for > normative language. Agreed. I removed the 2119-language from Appendix A. spt= From nobody Tue Feb 12 18:26:10 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5F130EE7 for ; Tue, 12 Feb 2019 18:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 kYo_9joiOrKy for ; Tue, 12 Feb 2019 18:25:57 -0800 (PST) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE40130F00 for ; Tue, 12 Feb 2019 18:25:54 -0800 (PST) Received: by mail-qt1-f170.google.com with SMTP id p25so659603qtb.3 for ; Tue, 12 Feb 2019 18:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZN2UK7freEl7awJgLpWrsqpY0rRji0NcehE0VWiwtAc=; b=YhKOZop2hEbSR6U5QPQhAcpwUNmSXRPc/cPvcXCcS9CkfHdqCB5eCIejaoq5YCEn4O 8NmDpb6ThlRdzNeNuMfdyDu2OFuyMxQVhRnU9SuAWvDYEw3sAd4KhEgtQeaj7ybFpkjJ UVd6Y/xFjgjScPbC2aM4DzXGs1Oa0E3feaCBM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZN2UK7freEl7awJgLpWrsqpY0rRji0NcehE0VWiwtAc=; b=e+xusgrn7fO+OsiZ84173EkL9xg301KJQ5dSebhAECiJfpxCly7k6UTys8XmsrnAq6 Ug6yZlNmtf0CwX/cdf9cxFl9tnP4R1+/u7Ufr+heVQ6aLiBhN/3kbtXQGJBmydHE2mWc MgrY4zcO2qplxX6rJaMIiCUzGEM8dxzpryNcM+rA9Bga2ApXqEFlHubCrHbTaAH+Xum7 fjmEi2GmbBZr3sN627vWEsx3sPX/e9p+rzeJOs0I6v1iZbtheGRR4zRDAJc3sedU6iQp BetWe3Xoe2xfMzx+D0rztxh35Rzd8l6rSr7vKCN0IV8tjDl+F9r7kyYngmRmYWLsNyxl wo0Q== X-Gm-Message-State: AHQUAuZ2j2+iiuZgM5Bg/Y6tVat8OfRlTpsKONi5s4rZaAehIkAx1ML3 u3maupgtBIDmPW1BVs6X/s8Db3iMI3Y= X-Google-Smtp-Source: AHgI3IYqQkSjj/TDQIIh0HN6Yr0+eBpqBajGstyeKW2lA18KL3pSTw5HpJ6eSC6JlqnVwCl2Imn2bg== X-Received: by 2002:a0c:92ec:: with SMTP id c41mr5174617qvc.158.1550024752983; Tue, 12 Feb 2019 18:25:52 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.25.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:25:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154827316130.7453.12140820828793016275.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:25:51 -0500 Cc: The IESG , draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9AAC1676-E54A-4049-8AC7-BFC257E4A692@sn3rd.com> References: <154827316130.7453.12140820828793016275.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Alissa Cooper's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:25:59 -0000 > On Jan 23, 2019, at 14:52, Alissa Cooper wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > As this is a BCP, I don't understand why transport encryption of the = private > key is not normatively required. Could you explain? I guess there are a couple of issues here: 1. deployment - I think there are two cases we need to consider: a) = router is plugged into rack and managed over the LAN via the networked = administration interface (i.e., RJ45), but there are also times when the = operator sits down with box that=E2=80=99s not network connected and = jacks into the router via the =E2=80=9Ccraft port=E2=80=9D. The former = case sure, you=E2=80=99d want to mandate it, but in the later is it a = MUST? 2. Object level security (which I think BenC also commented on): I would = love to have object security, but the key needed to decrypt the = encrypted needs to get onto the router before the encrypted key does. = We could do something PBE-based maybe or rely on the manufacturers = having burned some key into the box that we can use. Unfortunately, = this bootstrapping problem isn=E2=80=99t new and not solved well - we = didn=E2=80=99t attempt to do it here. 2. Transport encryption (which I think ekr also commented on as being = underspecified): The draft does include the following: Operators are free to use either the router-driven or operator-driven method as supported by the platform. Regardless of the method chosen, operators first establish a protected channel between the management system and the router. How this protected channel is established is router-specific and is beyond scope of this document. Though other configuration mechanisms might be used, e.g. NetConf (see [RFC6470]), the protected channel between the management platform and the router is assumed to be an SSH-protected CLI. See Appendix A for security considerations for this protected channel. So transport security is required unless you got a really good reason = not to do it - like maybe you=E2=80=99re plugged directly into the = router and the router=E2=80=99s just being brought to life. Since both = you and ekr had the same kind of DISCUSS I will try to address it in = that thread. Maybe it=E2=80=99s as easy as explaining the two cases and = providing requirements for the networked protocol. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Given that this document is ostensibly specifying a "best" current = practice, I > would have expected a clearer expression of preference for the = router-driven > method over the operator-driven method, e.g., something like = BGPsec-speaking > routers MUST implement the router-driven method and MAY implement the > operator-driven method. Or if there is some exception case that makes = that MUST > problematic, it would at least be good to emphasize which one of these = is > actually "best" from a security perspective, even though the other one = is being > specified and we know will be used. The way I was looking at =E2=80=9Cbest" is that there are a set of = routers that do what they do; some do operator-driven and some do = router-driven (and some support advanced deployment scenarios). = Further, these routers are probably already out in the field and getting = BGPsec bolted on so what operations the router supports it supports. = And, it wasn't clear to me that picking one over the really made sense. > Nit in Section 1: >=20 > s/gritty details/details of the BGPsec protocol/ fixed spt From nobody Tue Feb 12 18:26:17 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632F8130E2E for ; Tue, 12 Feb 2019 18:26:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 HwNQ1EtHK8qD for ; Tue, 12 Feb 2019 18:26:01 -0800 (PST) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721A6130EFE for ; Tue, 12 Feb 2019 18:25:59 -0800 (PST) Received: by mail-qt1-x843.google.com with SMTP id a48so951574qtb.4 for ; Tue, 12 Feb 2019 18:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F7EsiWAvWy/ofPbD2fhdmyB7s4jdNRIIFjLffWagz6o=; b=AUNwAAnQxlY5ru6T0ilaQw4t++UKO3g/2FydIKmOYv0ypy9YZDFOEufKS7/9GBm5m4 v7sa//GzQZMdVO5ORQEJfCT0GwvZC+ILkHamY4wSVT/arq8V89++0cU31yB4zI8XCP27 EEVmCC8uWdp+oYNKPGGFfBLIWGXBWXeHRPxTo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F7EsiWAvWy/ofPbD2fhdmyB7s4jdNRIIFjLffWagz6o=; b=OxRBdBT/GOecHz70Vzab2NCf6/AUCmFMHZ8ePOUc3GKGRqsY76iTikar7PwvYieNiZ FOmlflEUeQqe4SPCZ56WhlRuBNZ5cl70sIJAnp42Z1cswGt+hyUWeqnYJ6q+ZvOdiWn3 OPtZmYTmHbDwyur/bRDP49fV35doY6+GNBv5X9pJmFDhQ+wPvo++A/5jlomLbiD2d8O0 jo6dksQX/sx5nHOR4OodbCHWf/ryi6FOuHtNC3db03MtltUht4Ff0MSOjCNgyROMdXYY aamhA94E4iu7iiz730UFSVWKTf16xIuWo7t9TqStjLLyVuWc4BH3ipErvl+p6+uNQrKV ZW9Q== X-Gm-Message-State: AHQUAuYaksELjKQcwmAnan9GoL82fBOA4aEZyCnUUJhH83zu+IFqEFih GzEmVfH5Je+hXi9u4il9wSiedg== X-Google-Smtp-Source: AHgI3Iad7DXsM0rwMFd1P7ShPH5HwXTe4UqhTIFX1bZd5Z8FUDCuLj+MOuXU/RvOqv9FsxVSpulDVw== X-Received: by 2002:ac8:1c5d:: with SMTP id j29mr5225484qtk.113.1550024758420; Tue, 12 Feb 2019 18:25:58 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.25.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:25:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154821398252.13239.9780042427198357683.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:25:56 -0500 Cc: The IESG , draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154821398252.13239.9780042427198357683.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Ben Campbell's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:26:03 -0000 > On Jan 22, 2019, at 22:26, Ben Campbell wrote: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > - General: The document says it's intended as BCP, but the data = tracker says > "Proposed Standard". Was this last called with the correct status? (I = agree > with BCP, by the way.) Yep - I changed the intended status as a result of a lot of comments, = but I guess the buttons didn't get pressed to change it in the = datatracker. > - I share Benjamin's concern about the idea of moving private keys = between > routers as a "need" vs "something people do=E2=80=9D. See the response to BenK. > =C2=A75.2.1: "The router should inform the operator > whether or not the signature validates to a trust anchor; this > notification mechanism is out of scope." >=20 > Should that be normative? I suspect it should be :| > =C2=A79.3: The second paragraph is a single convoluted sentence. Can = it be broken > into simpler sentences? I suspect it can be but I am hoping the RFC editor can do it=E2=80=99s = thing and give me really options. > =C2=A710: >=20 > - "This document defines no protocols. So, in some sense, it = introduces > no new security considerations." >=20 > I think practices can absolutely come with security considerations. = For > example, the practice of moving private keys between routers. Fair enough, but that=E2=80=99s why there=E2=80=99s more in the SecCon = than just that one sentence :) > - "Private key protection in transit": Is there no expectations that > transmitted private keys would have object-level encryption? >=20 > =C2=A7A: I'm curious why this is not part of the main-body security = considerations? See my response to Alissa=E2=80=99s DISCUSS. spt= From nobody Tue Feb 12 18:26:40 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B877130E2E for ; Tue, 12 Feb 2019 18:26:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 JnTNToZUAUeu for ; Tue, 12 Feb 2019 18:26:07 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735FC130EE1 for ; Tue, 12 Feb 2019 18:26:04 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id m9so498101qkl.4 for ; Tue, 12 Feb 2019 18:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dl7yb0gpGA/pgQiz+GiO2xlLtYF1WaGJV4xpKP+s5Gw=; b=Pgx/PS9LGwEWskesPOFNZL8WSaeuDcfCv+XQt0RadhLrEyaJe9fEy2oDSWnA8QMtAE Y3peF4qV1zcp+PiUxLmglPImCK5FoQ39byX5XduXB7YyMZkSNT8kdzs9iQvBu8Ovf8Gk avjJ4rQO5kNfNldv46qSX5QziPG/OyEzlOpWA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dl7yb0gpGA/pgQiz+GiO2xlLtYF1WaGJV4xpKP+s5Gw=; b=UCP1C0MtRvQmCxkad6sHMPxqTD9nBHByjq66ZczUhtfbPoZkCyBMpgwXATehvk2MVu uYsdML6W2jXS81zpUW+a2nAhIeF/YaQFqWYNqeYP5V0yewc/PlApU8y5528aZQLCGTWl yFtxa88hhh46NLvk6g+f0uHzKw2xSb7bbOfjdvD8DOFdqYnV1C06nMKcXtiQ3e3P6HtR gh/nrOnHCF5zP4NGKJxbCwH6Tg0f5dzKwAbZ34Q8BqqKecUdAkFbEDLYPt30svtl+JZQ HtmYqWCVBTA4qGTu0St6OseGoFCdcPdFHjd0dESN3AqFq+bhIizCzOmC4go5A8bIkQJS PH+g== X-Gm-Message-State: AHQUAua4BpQbwG+9utzI8k2mMr2V9ruTYxix/MmLwWcfwvv0ugdIdUZy zDX3YNx4eni3wiO4SIx5t+UMDg== X-Google-Smtp-Source: AHgI3IZc7O/Tm7KAWTJG9Kik+wQlrAeYkIFFN/xbDgSiCrP6eGnsXYPsOY5cOuq7ohlOwIZRHQRMXQ== X-Received: by 2002:a37:cf56:: with SMTP id e83mr1690510qkj.101.1550024763451; Tue, 12 Feb 2019 18:26:03 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.26.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:26:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154833578539.25088.8998015406968018020.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:26:02 -0500 Cc: The IESG , draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <69FC2470-F679-4911-A8DB-6A0518FE87B0@sn3rd.com> References: <154833578539.25088.8998015406968018020.idtracker@ietfa.amsl.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Martin Vigoureux's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:26:15 -0000 > On Jan 24, 2019, at 08:16, Martin Vigoureux = wrote: >=20 > Martin Vigoureux has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hello, >=20 > thank you for this Document. > I only have a couple of questions: >=20 > In the operator-generated method, the operator SHOULD extract the > certificate from the PKCS#7 certs-only message, and verify that the > private key it holds corresponds to the returned public key. >=20 > The router SHOULD extract the certificate from the PKCS#7 certs-only > message and verify that the public key corresponds to the stored > private key. >=20 > I believe SHOULD applies to extract and to verify, correct? > But I wonder why isn't that a MUST, or asked differently, what could = happen > wrong if that verification was not done? >=20 > Thank you Yes. This is kind of a sanctity check before the router starts signing = things. If the CA/operator somehow blows it and returns the wrong = certificate the router will catch this mistake. If CA/operator somehow = blows it and returns the wrong certificate (and never actually posts the = right one) and the router doesn=E2=80=99t do this check then relying = parties will not be able to verify the BGPsec messages. It=E2=80=99s = kind of like be good to neighbors ;). It=E2=80=99s really why it=E2=80=99s= a SHOULD and not a MUST. spt From nobody Tue Feb 12 18:26:45 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E88130F01 for ; Tue, 12 Feb 2019 18:26:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 5jUiU22MOkkL for ; Tue, 12 Feb 2019 18:26:12 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4EAF130F2B for ; Tue, 12 Feb 2019 18:26:08 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id 2so946349qtb.5 for ; Tue, 12 Feb 2019 18:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VmpeKt/drgnLKLifKl63kcI2mIyB7zpvhTCmHwI9rjQ=; b=lOHqM+h89myBjODFLxKBmP477e4SlF3kTfxhx0N/4ZzmwbM1azbeF9W0/LQS1x9eRy tTsellHbYj2ZbuAtGtg2WT+W4dROsJYLuBu4b8RjmAswhWKqRS+KPjpbTTkHa26skqLp 058kq1lmH7A9UzB1Yjv5vNZwcQ4VB3okUxP+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VmpeKt/drgnLKLifKl63kcI2mIyB7zpvhTCmHwI9rjQ=; b=pl/yfti4iJ5zZtVKLQH6cL+43aV3xA7z1sFrg6LitieB+DpAvorvgczFSfRqo5nnkg RtEzkS5jZcFLvqIDlnORvXu9O2ugFdmuEs2U+GST69rYMr3N6c6tzExqEYAHMOU6Ymhn C3YQ5QKjEqODBecZrk6KSvyfg8lU5ySdhyDG1VQOWUlGFSVyzgp11ZeD/OS+jzqLGUNA tMw6BPFmFA+2iMPzgdWkAeqe1N1TOsxLpbhnF/LDu9OfpDsmuExQaSLEC3sxofDs6Y7J 0r/h4cscduHgcCMua8loSXeaMfEn/X3T4p+VQdrjmDDFf3hz7hh2nBi8ZyAMg+Es2sDs eriA== X-Gm-Message-State: AHQUAubk9hCU9tNLaz6ThYL6DIRuZy3sj+fMSsu41dcRe5q3TuhMuAob Pz6hiP9xiHhNB47y8ldooSI4kA== X-Google-Smtp-Source: AHgI3IYrEMqCvKq9+JYEgP3cnVBbYRev2PVUa7sWDTwGr+iMrKRw2rGgSkOU7IUsEwlGv13WCarzCA== X-Received: by 2002:aed:3c33:: with SMTP id t48mr5251354qte.308.1550024767832; Tue, 12 Feb 2019 18:26:07 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.26.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:26:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154821657076.13328.13662061490601279410.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2019 21:26:06 -0500 Cc: The IESG , draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <28D5CC32-3E09-44C6-9A44-56FF3FA16918@sn3rd.com> References: <154821657076.13328.13662061490601279410.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Adam Roach's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:26:18 -0000 > On Jan 22, 2019, at 23:09, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-sidrops-rtr-keying-03: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks to the authors for a well-written and clear document. I have = one > substantive comment, and a minor editorial nit. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A73: >=20 >> - Using FTP or HTTP per [RFC2585], and >=20 > It's not clear from a casual examination whether use of unencrypted = and > non-integrity-protected channels for these operations are safe. I = would expect > to see a discussion of this in this section and/or section 10. The = closest I > could find is the SHOULD-strength (!) recommendation for = transport-level > security for private key transport. >=20 > Without a more thorough analysis, I suspect we should more strongly = deprecate > the use of unencrypted/non-integrity-protected transports. This = document is, > after all, supposed to be calling out best practice; and, in 2019, = that really > does entail transport security except under the most exceptional = circumstances. My initial reaction: For items that are already integrity protected, certificate and CRLs, = it=E2=80=99s not as bad as all that. See the security considerations in = RFC 2585. But, after a glass of wine on a plane: Maybe we put something it that says something like: Despite the fact that Certificates are integrity-protected and do not = necessarily need additional protection, transports that also provide = integrity protection are RECOMMENDED. > = --------------------------------------------------------------------------= - >=20 > =C2=A72: >=20 >> Though other configuration mechanisms might be used, e.g. NetConf >> (see [RFC6470]), the protected the protected channel between the >=20 > Nit: duplicate "...the protected=E2=80=A6" Fixed! spt From nobody Tue Feb 12 19:41:18 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C54130F8A; Tue, 12 Feb 2019 19:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Wui1KUGNwnwE; Tue, 12 Feb 2019 19:41:08 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831CC130F80; Tue, 12 Feb 2019 19:41:08 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gtlPu-0000jr-Dz; Wed, 13 Feb 2019 03:40:58 +0000 Date: Tue, 12 Feb 2019 19:40:57 -0800 Message-ID: From: Randy Bush To: Sean Turner Cc: Benjamin Kaduk , draft-ietf-sidrops-rtr-keying@ietf.org, The IESG , Chris Morrow , SIDROps Chairs , SIDR Operations WG In-Reply-To: <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com> References: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 03:41:10 -0000 > Would something like the following work: >=20 > The operator-driven model is motivated by ensuring the network > operates. In some deployments, the same private key needs to be > installed in the soon-to-be online router that was used by the the > soon-to-be offline router (i.e., operators need to support > hot-swappable routers. would add something about possuble O(day) RPKI propagation, thanks geoff >> When a router is so configured, the communication with the CA SHOULD >> be automatically re-established by the router at future times to >> renew or rekey the certificate automatically when necessary (See >> Section 9). This further reduces the tasks required of the operator. >>=20 >> Mentioning renewing certificates is natural, as they have a stated end t= ime >> to prepare for. Re-keying certificates is something of a different matt= er, >> and it would be nice to provide (a link to) some guidance on what >> timescales at which to rekey, if we're mentioning rekeying here. >> (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I >> did not see much concrete on this point.) >=20 > We=A2d end up in a circular reference point then since they point to our > document. The thing here is that the lifetimes of the keys are > entirely dictated by the PKI CPs and there=A2s more than one place to > point. Not sure I have good fix for this one. >=20 > Randy/Keyur? i do not see router private keys changing frequently. a paranoid op might re-key yearly. others never. >> To allow operators to quickly replace routers without requiring >> update and distribution of the corresponding public keys in the RPKI, >> routers SHOULD allow the private BGPsec key to be inserted via a >>=20 >> Making this a SHOULD is perhaps an overstatement, since AFAICT this >> functionality is not useful for the stated purpose unless the operator h= as >> access to private keys directly (whether by virtue of the operator having >> generated the keys or an extraction interface on the current routers). >> This is an inherent tradeoff, as stated, between the delay in >> update/distribution of public keys in the RPKI vs. reducing the risk of >> unauthorized key access. I'm not making this a Discuss point because it= 's >> not exactly my tradeoff to make, but I do want to be sure that this is >> actually the tradeoff that SIDROPS wants to present to the community. >=20 > It=A2s definitely been in the draft for a while now. I guess folks can > speak up if they think it=A2s wrong. >=20 > Randy/Keyur? we are going over the same issue from another angle. maybe in 2050, when bgpsec is deployed, the rpki will be sufficiently responsive to change that a vendor could sell a router that only did the key export thing. not today. to repeat my message to ben from 22 jan it's 2am. the bleeping device melted. a new key generated by a replacement device will take a good while to get into the rpki and then many more hours to get into everybody's bgpsec validation key caches around the planet [ask geoff why he insisted he did not have to publish more frequently than once a day]. and by 3am, people with shiny shoes will be giving the op snake eyes that customers in tiblisi can't give them money online right now. when the op tells them it will be tomorrow afternoon, it is usually referred to as a resume generating event. randy From nobody Wed Feb 13 10:56:07 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1962128B33; Wed, 13 Feb 2019 10:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 g7DN7xPqyrXD; Wed, 13 Feb 2019 10:55:55 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56B81292F1; Wed, 13 Feb 2019 10:55:54 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id n71so6070805ota.10; Wed, 13 Feb 2019 10:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=BNInO07TmnQiYs8O+ukf1gCCDK6huTSO9OKHHqyre3U=; b=tLIXJSLq5dHsI7kWva7Oq+gnUGgciLStq3oeL9arzeDlpJ4rmK8y2rRI47mzwz4l/X d5Ez24dgD93t+zUMxS0FasFMfEgpJ/4ttz8wwOV09KWMvINaHzbI5EY06SdyAxcXtDcn gMkYgJVkIQgIjki2YnMiDT5gPEFuuNOxkK0gWhyLXAtrpOHykGeM6R1DANbF/KA0GIv2 ph9mttJht0nN0r/4IMAqpH1PgCkjFK8JwRvbi8PkCGmMTT8J/cbP9EQ4uZLYNz+hldsG n/N3nVg+ojUalO9tsAXPGhisf+ZUn3dFnUM7XRT+00/KmcT0lL8rzTAo+MdOaaIDZcYp Wkbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=BNInO07TmnQiYs8O+ukf1gCCDK6huTSO9OKHHqyre3U=; b=I5Es80weAbCe3qjmeOXXf+4odQ/DCVLhaJgm92RWNL/xA77DWjO8/5P1dlrZQ84xfu jaRHYB/0UhB9ou3oDYz/EJD44xQe6OAUHsmcP5hCjE4rOE/osNbczPHZJF/eZZPItiQu To1iBh93OXD303JDSRgQyGsAAZN/7PQMRW+pJQxuBQ0lymru5L1eODimXjmwMkFPTcYm rznZn46vvNVp4x+mtB8XOa92QgxxPiKMV7iyJc1bxZCw9rEWTNQC53tIh6IDlTMfu1Hu 7/MXpi9+NfTvGFBXhAvuUCnr+83ha8jfRQ+UFYdpqhktr7GD5QY1ULtsHDhxdLgXAcPP EO3Q== X-Gm-Message-State: AHQUAuZ4bQQncDVMB3Z5GO9t4A/sosimRJWjilh8c5E/OrEIUuerOjXS FkNPGNuE0grzJv0PFIVRxXVvWrDx29a2qBK+p0o= X-Google-Smtp-Source: AHgI3IbDkUzAjtv/dTucTvOfuACBnTMQg+ZVb9aVfy7Xjj1clrVQ6ww6TS1XCfh3OXh9FPgDoBfxIpZs/Be+PdkELfQ= X-Received: by 2002:a9d:282:: with SMTP id 2mr1174490otl.287.1550084153368; Wed, 13 Feb 2019 10:55:53 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Feb 2019 13:55:52 -0500 From: Alvaro Retana In-Reply-To: <6A4B0CAF-004F-4FB8-8A0A-A2F155308DF0@sn3rd.com> References: <154826560230.7563.12584828485918011085.idtracker@ietfa.amsl.com> <6A4B0CAF-004F-4FB8-8A0A-A2F155308DF0@sn3rd.com> MIME-Version: 1.0 Date: Wed, 13 Feb 2019 13:55:52 -0500 Message-ID: To: Sean Turner Cc: SIDROps Chairs , Chris Morrow , SIDR Operations WG , The IESG , draft-ietf-sidrops-rtr-keying@ietf.org Content-Type: multipart/alternative; boundary="000000000000556bc40581cb17b4" Archived-At: Subject: Re: [Sidrops] Alvaro Retana's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 18:55:58 -0000 --000000000000556bc40581cb17b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On February 12, 2019 at 9:25:33 PM, Sean Turner (sean@sn3rd.com) wrote: Sean: Hi! > On Jan 23, 2019, at 12:46 , Alvaro Retana wrote: > ... > (1) I don't really have a strong objection for this document being a BCP. > However, while documenting two different methods, there is no clear indication > of "what is believed to be the best" [rfc2026], or even better, which method > should be used in what situations. I understand that operators have different > preferences/needs and that prescribing one method as the default in not the > right thing to do. > > I would really like to see some text (maybe a "Deployment Considerations" > section) that talks about when one or the other might be preferred/considered. Right so I am hoping that Randy=E2=80=99s answer helped here. The only thin= g I will add is that it really depends on what gear you buy so in some sense I am kind of wobbly on whether we should pick one. I=E2=80=99m not sure which of Randy=E2=80=99s messages you=E2=80=99re refer= ring to, but I would this related reply (to the RtgDir review): "we do not tell operators how to run their networks. for example many will choose operator driven because it allows them to quickly swap new gear for a failed device without backflow into the rpki. " I=E2=80=99m not asking you to pick one=E2=80=A6or to declare one to be the = default/best.. I=E2=80=99m hoping that you can provide some guidance on the pros/cons of u= sing one method or another in different scenarios. Maybe you say that if the right hw is present then one method might be better=E2=80=A6or you might say (as = above) that one method is better for some operational cases=E2=80=A6. In any case, just a non-blocking comment. :-) Thanks! Alvaro. --000000000000556bc40581cb17b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On February 12, 2019 at 9:25:33 PM, Sean Turner = (sean@sn3rd.com) wrote:

Sean:

Hi!


>=C2=A0On Jan 23, 2019,= at 12:46, Alvaro Retana <aretana.ietf@gmail.com> wrote:=C2= =A0
>=C2=A0

...

> (1) I don't really have a strong objection for this document = being a BCP.=C2=A0
&= gt; However, while documenting two different methods, there is no clear ind= ication=C2=A0
> = of "what is believed to be the best" [rfc2026], or even better, w= hich method=C2=A0
&g= t; should be used in what situations. I understand that operators have diff= erent=C2=A0
> pre= ferences/needs and that prescribing one method as the default in not the=C2=A0
> right thing= to do.=C2=A0
><= span class=3D"Apple-converted-space">=C2=A0
> I would r= eally like to see some text (maybe a "Deployment Considerations"<= span class=3D"Apple-converted-space">=C2=A0
> section) = that talks about when one or the other might be preferred/considered.=C2=A0

Right so I am hoping that Randy=E2=80=99s answer help= ed here. The only thing I will add is that it really depends on what gear y= ou buy so in some sense I am kind of wobbly on whether we should pick one.<= span class=3D"Apple-converted-space">=C2=A0

I=E2=80=99m not sure which of Randy=E2=80=99s messages you= =E2=80=99re referring to, but I would this related reply (to the RtgDir rev= iew): "we do not tell operators how to run their networks. for example= many will choose operator driven because it allows them to quickly swap ne= w gear for a failed device without backflow into the rpki. "

<= br>

I=E2=80=99m not asking you to pick one=E2=80=A6or to declare on= e to be the default/best..

I=E2=80=99m hoping that you can provide so= me guidance on the pros/cons of using one method or another in different sc= enarios.=C2=A0 Maybe you say that if the right hw is present then one metho= d might be better=E2=80=A6or you might say (as above) that one method is be= tter for some operational cases=E2=80=A6.=C2=A0

In any case, just a n= on-blocking comment. :-)

Thanks!

Alvaro.



--000000000000556bc40581cb17b4-- From nobody Wed Feb 13 17:11:05 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE29129AA0; Wed, 13 Feb 2019 17:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 nq7Dz3A9QLZf; Wed, 13 Feb 2019 17:10:38 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780104.outbound.protection.outlook.com [40.107.78.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2654A130DE3; Wed, 13 Feb 2019 17:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FzSg08X+GwThpmO6r16Utf/nNiJ+uhGCMzOBpnkfuNk=; b=FAWglT24+Fhpqnqp6jmOJzLWR4DuWq8gpT+xm7VEnXprQNEOBiHCJ1KNsz14ahgEBxLh45O+lt5GUgLMGtD8RMxDtDen0sqCA/qYY5jcssniCU/rqx+b/sDL2/uvWWmrmtncm3w5PgcJIaeF+T7TbUfwrB5a0q+1OxBasfVCqfY= Received: from BYAPR01CA0020.prod.exchangelabs.com (2603:10b6:a02:80::33) by SN6PR01MB3757.prod.exchangelabs.com (2603:10b6:805:17::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Thu, 14 Feb 2019 01:10:36 +0000 Received: from CO1NAM03FT012.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::207) by BYAPR01CA0020.outlook.office365.com (2603:10b6:a02:80::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Thu, 14 Feb 2019 01:10:35 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT012.mail.protection.outlook.com (10.152.80.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Thu, 14 Feb 2019 01:10:35 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1E1ATUq020717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Feb 2019 20:10:31 -0500 Date: Wed, 13 Feb 2019 19:10:29 -0600 From: Benjamin Kaduk To: Sean Turner CC: , The IESG , Chris Morrow , SIDROps Chairs , SIDR Operations WG Message-ID: <20190214011028.GF56447@kduck.mit.edu> References: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(136003)(2980300002)(51444003)(199004)(189003)(478600001)(305945005)(55016002)(76176011)(229853002)(8676002)(246002)(104016004)(8936002)(86362001)(26826003)(316002)(58126008)(36906005)(786003)(106002)(54906003)(75432002)(23676004)(2486003)(7696005)(26005)(2870700001)(186003)(106466001)(336012)(6916009)(14444005)(126002)(50466002)(426003)(11346002)(2906002)(446003)(53416004)(6246003)(476003)(30864003)(956004)(4326008)(486006)(66574012)(53546011)(1076003)(561944003)(47776003)(356004)(33656002)(88552002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB3757; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT012; 1:u00Mwp0MQoX/LM7/qENl487umlVWT3u+kE9Qnrch00zSD1ZkQ6fYeNDC1JACpjyjtvCCZ3G1wvCVa3G8O22awirjFfDVdua+6qzRXfGMwZUTH0bFRlPOQwg4AvygcaoVMudRqTxENDqOUD2SU+W8I6rJ90rlkeiw0xZhVBQlDxU= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c899ae8a-9a5c-4fe7-e0d8-08d692193988 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4608076)(4709027)(2017052603328)(7153060); SRVR:SN6PR01MB3757; X-MS-TrafficTypeDiagnostic: SN6PR01MB3757: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3757; 20:Kardiz5ylOkAZT/BC2x0KUg7AZhCD01CrIc4Th7WwTZV6BYEg3h0DUUpOoFDi71vpGo/QyS2xHEZr+hlfGPwcXnrChpQTFm3yilE99cKHZm180vkwal26lQYqiiq5UhnFcoQ7zBee7BHOLoUJ/DXnvh6cFNPnmwPqsEdvgLoaQU1Zz8fa1NsOyMfEbCc5Z1FUyJlmd+SlAKjEPIvs3Yqg9cIgPAeit4AIhDHS6vCEUbjqSdW5kaySxnE9qBRyCxjM9Qavgvm6Axb1HJ3OfTp/7OVONyzIC8KJJhWzrqq7UhqBVMLhLqBnoAoutY4cASXGIcDm8XBVlvxFkJmhEzHQBd7yjUlojCCw1QLUi/Kyw+n55EPBqTI6h/0oJSYSnuPTBZbling5sUSxf7lZHcif8ut7nFZs1QuKTsJI8tFrnZp4wOhomWAK4CAxUWq1/GIppA0Ir5dqpdsn6MWTF0dt3XrJjhXP9LfAHIr1M5C/ckO/+EG5+NwqvAFaoXSBdxcl077taMMmgak3qtZlDX0VPMkw2IxCsOSCYhba+x2za4J2dGjtXrJ7BG2utnbj6bEca3kBJphOAQRRYr18hBpfV0gIX4dY1+1gr0uiHOCj2Y= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09480768F8 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjZQUjAxTUIzNzU3OzIzOnFCQ0U5d0N1NVlTYnF2ZjZNR1RteXl2dWtr?= =?utf-8?B?b085Um0xOW01TFF1U2k3THpIcys3eXdrTk10NGVpdUlpVXAyekJzRjhCb2lv?= =?utf-8?B?dytVdmlzaGtQL05GV1JJQUFKOXRNZ3kvazAzTkkwZHpRYzlVYTlBTnVqQnhR?= =?utf-8?B?VWkzV3FaSnNTZ0d4SmtXbVFzNjNMUHlaRzNvY3FTNzcraVUvT3pTZzJVcmNB?= =?utf-8?B?ejRkRWg2bEJ2a0FlOVFzNTlRYnZ1bGorQzBITmlCRTZjLy8wWTh6V05XSkk5?= =?utf-8?B?UDYvM0F6ODg0V1ZmYUVVTHh3NEp5OG9rVWhUWmhhdGtGTVkxVlhSbmt2djBn?= =?utf-8?B?eityVEhxejdTMFEwQXAvYzgxaGY0WW9hTXFodk0xOStqU0szLzROM3o5NmJ2?= =?utf-8?B?em1LMWQrazN6cUMrSHFkWEpVMEtDbzRFUTNTR0RaU0hneE5hRkphT1pXOER5?= =?utf-8?B?WEMwWEZiMXVSZlUyckFCc2JWazZ6Ti9UN0UzUzJrSCtldzFvRjk5SUE2ejVa?= =?utf-8?B?M3o3WDJFeVhmRk5oM1gyRmRpdjh1UC9MMzdpS1RsOUJIaE9jZVhURXd0ZVpv?= =?utf-8?B?NHpubGNhQUF0S1FXTW0yY3B5dXo2eTJkY2VxZHRJU3pyUTVsU0MrbVFRUHRY?= =?utf-8?B?SmpOcnJrU3RJdGpzSEJ3ZGN2MndvT2phSWROR0pVVmhhQ2QyQmJ5M2cxZWNx?= =?utf-8?B?dTI0eDE2aE1LaGtPUC9DcTdkR2ppajhRSnpFR2FqNWcyd0tSckhkVGk3a0ha?= =?utf-8?B?aUprbUp1YmJpTmltVTVQeDRxSFlvWlZWL2tBQlFBNVJsaTdhWGJsTHN5M2hU?= =?utf-8?B?MEZwbVZhd1FTcW1KWiszdlZsTEdYL0twcjFkV2VZRWxJblZmZmVhMjhaODE0?= =?utf-8?B?aXg5Tzd6NWxaWnQ2TC9UNk1lNXVpUlBrUTBRazFNOHJmQlBvcVdWaWl1S3gw?= =?utf-8?B?OWM2alVGanlsTnhQbEd6bkY3TEU0REpJV21VRXlhb2I4bXNkTGMzWXNUK0Mz?= =?utf-8?B?WU9sbnFKNnNvVEdkZFJ2L1dBZVdyaEN0Mm14S1hjYU1zL3FGZDBZbWU0cmR5?= =?utf-8?B?M0VhbUVHVmZ3NzU2NjV0VHpkK256cjNNOFlHWDN1RDZCRzh1cGtVOEVWQ3pU?= =?utf-8?B?aE4veGRrcFJzaTlZRUlXQ08yaWQ5SEVwaTl1OHRUZnJmaTRDcXMrYnF2bmMx?= =?utf-8?B?TFZtMCs4MUtLUUNmVTBoVnhyT3gvQkZlK0pVeTVnRG52eC9KSUdmNWtjZ2lH?= =?utf-8?B?WUxqVkNzakR5L1Brbncvb0QzQlpUeU5RMWlnVW1HQmJKSFppQmhGWUYxcG5l?= =?utf-8?B?bGJDZ1AzeHQyQmMyZ2Zvc0JaV1dtTEo4bTN4RHpCc3FWMDR4akZOaHUwM2xt?= =?utf-8?B?MDhiYUlKV2oxTW9zNTQ3U2pFaHpLR2VxMmpTOUNkUmFFNmFjUDVpQ0J1SWtV?= =?utf-8?B?NEZQZnY2a2FtV0E1V28rM0s4ZXc5NW56bUFPeklkejZTVWFKTXdPWERrZERU?= =?utf-8?B?cTRGS1NMdkVINTB6T0ZLc1ZYcDFpc2hyNnlaWkE0M1NWRmhPMm8wM3BQQ3F2?= =?utf-8?B?QWNua2lqUU1nQlpNc1NTYVRkZGsxdmh2RG9OWlhPSXZXckVPcnh4YVU5ZGRt?= =?utf-8?B?UStxR1pRZkpCaUNXV3diQ3pkdmlXRGQvZmpHR1BTSEZxeFE2ZFlvaEdLRGV6?= =?utf-8?B?eFlwRGZnMXhCb2VGSFNsaDVvUEhnWTlPTERDU0VheDlOVDk3bVFTNndsbG9h?= =?utf-8?B?NS9ZWU9ZdGFpU1RzaEVGZz09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: C8E8NhWhcspumSbZ2UtMxA8g/PPzEuhCTHMUUDwWZKCZ0VDm8+BQ+LRstWeUpsKTsPKDy3OPIlNK8CTCm7mimaj7V7Kou1K5vlcsak4d35qOptVkkweIk18+Qr6hz0GaGcbPaaYDFslpisxyPhvMZdp9o4lTyfXUbJXAUUH0EOc1Rm2HsLYrYIj/l0I7JJ57QMopNCK2OuLjBNWiC5s1KtJa7rW0I7QTlY0KaHV49jhhBdvXFD5U82b7Cw+yksybLYByGA8QrQy4qtvLSJKOQvxnx6C53M2LdMKCrg5fbo57z49VEXoiP7kB79PPsI1vrqMahMdORA/4BLBvZa0gwzrrP+5soRqTWdcqB8c5kpxF1TNVldxVahtfly/MXFVr129pvqd39otsAVQFV8HLYeR+TROAFA8TaoB0C04qmH8= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2019 01:10:35.1511 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c899ae8a-9a5c-4fe7-e0d8-08d692193988 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB3757 Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 01:10:51 -0000 On Tue, Feb 12, 2019 at 09:25:40PM -0500, Sean Turner wrote: > > > > On Jan 21, 2019, at 12:27, Benjamin Kaduk wrote: > > > > Section 1 > > > > For example, when an operator > > wants to support hot-swappable routers, the same private key needs to > > be installed in the soon-to-be online router that was used by the the > > soon-to-be offline router. This motivated the operator-driven > > method > > > > As the secdir review notes, there is no need to copy private keys to hot-swap routers > > (unless there is something special about the "hot-swap" case that nullifies > > the arguments he made?). > > > > It rather seems that we should avoid framing this behavior as justified by > > a need for hot-swapping, but rather as something that people do to work > > around processes that do not admit the more secure workflow, as an > > operational reality. > > Would something like the following work: > > The operator-driven model is motivated by ensuring the network operates. "motivated by the extreme importance placed on ensuring the continued operation of the network"? > In some deployments, the same private key needs to > be installed in the soon-to-be online router that was used by the the > soon-to-be offline router (i.e., operators need to support hot-swappable > routers. Per Randy's suggestion, I might drop the parenthetical and go with "soon-to-be-offline router, since this "hot-swapping" behavior can result in minimal downtime, especially compared with the normal RPKI procedures to propagate a new key, which can take a day or longer to converge". > > BTW - I am totally open to wording suggestions. > > > > Section 2 > > > > (see [RFC6470]), the protected the protected channel between the > > > > nit: duplicate "the protected” > > fixed > > > Section 5 > > > > The PKCS#10 request SHOULD be saved to enable verifying that the > > returned public key in the certificate corresponds to the private > > used to generate the signature on the CSR. > > > > I mostly assume this is done by the party that generates the CSR, though > > perhaps one could read it as being done on the router always. (I guess > > later on we do recommend both the operator and router to do this > > verification.) This could be reworded, though, either to remove the 2119 > > language ("Retaining the CSR allows for verifying that [...]" or to apply > > to the actual verification as opposed to just the saving. > > I am all about dropping 2119-lang where we can so will reword as suggested: > > Retaining the CSR allows for verifying that the > returned public key in the certificate corresponds to the private > used to generate the signature on the CSR. SGTM > > Section 5.1 > > > > NOTE: If a router were to communicate directly with a CA to have the > > CA certify the PKCS#10 certification request, there would be no way > > for the CA to authenticate the router. As the operator knows the > > authenticity of the router, the operator mediates the communication > > with the CA. > > > > nit: I think that the thing we care about here is the CA's ability to show > > that the request is authorized. The operator is assumed to have an > > account/relationship with the CA and a channel via which to authorize > > cert-signing requests. > > Yes > > > In particular, "no way" is a rather strong > > statement, and would seem to deny the possibility of a three-party workflow > > where the router sends the CSR to the CA but the operator logs in to the CA > > independently and is presented with a list of pending requests to approve. > > (It would also preclude the operator from delegating their authorization at > > the CA to the router, as described in Section 8.) > > Okay fair point. Maybe we reword it to say: > > NOTE: The CA needs to now that the router-generated CSR is authorized. > The easiest way to accomplish this for the operator to mediate the > communication with the CA. Other workflows are possible, e.g., > where the router sends the CSR to the CA but the operator logs in to the CA > independently and is presented with a list of pending requests to approve. > > Again, totally open to word smithing. No changes to your proposal are immediately jumping out at me, though I do wonder if a xref to section 8 is worth attempting. (AFAICT it would require additional wordsmithing, though, which we may lack motivation to pursue.) > > Section 5.2 ("Operator-Generated Keys") > > > > Even if the operator cannot extract the private key from the router, > > this signature still provides a linkage between a private key and a > > router. That is, the operator can verify the proof of possession > > (POP), as required by [RFC6484]. > > > > This paragraph seems a bit of a non-sequitur -- if the operator just > > generated the key, it sure isn't going to need to extract the private key > > from the router to sign something using it! > > Yeah if they just made it they certainly have access to it. The concern was really more about router-driven models where there’s now way to get the private out so this paragraph ought to move to s5.1. > > > Section 6 > > > > In the operator-generated method, the operator SHOULD extract the > > certificate from the PKCS#7 certs-only message, and verify that the > > private key it holds corresponds to the returned public key. If the > > > > nit: "private key it holds" is the one the operator holds, not the PKCS#7 > > certs-only message. It's probably worth disambiguating, here. > > I think you are suggesting the following: > r/private key it holds corresponds to the returned public key/ > private key the operator holds corresponds to the returned public key in the PKCS#7 certs-only message. I think so, too :) > > Section 7 > > > > NOTE: The signature on the PKCS#8 and Certificate need not be made by > > the same entity. Signing the PKCS#8 permits more advanced > > configurations where the entity that generates the keys is not the > > direct CA. > > > > Why are we talking about PKCS#8 (asymmetric key transport) signatures here > > at all? This is the section about installing certificates! I guess I am > > not terribly familiar with the RPKI, but in the Web PKI at least it's quite > > uncommon for the CA to be generating the private keys, so mentioning these > > together is a non sequitur to me. > > In the WebPKI it’s really uncommon, but it is done in lots of other places, e.g., little devices with no human interface. Some entity creates the keys enmass, farms ‘em out when requested, and these farmed keys are verified to make sure they come from the trusted key generation source. > > But more to the point, the note is there because we do discuss PKCS#8 in s5.2.1 and it seemed like a good place to say hey - don’t assume the signatures are from the same place. In most cases they will be but not necessarily. Okay. > > Section 8 > > > > More PKI-capable routers can take advantage of this increased > > functionality and lighten the operator's burden. Typically, these > > > > nit: most readers will not bind "this" to the right thing and will instead > > be left confused. > > I am thinking I could just strike the ”this”. > > > Why do we not mention the need to get the manufacturer-installed key > > material (or information thereof) to the operator? > > But, I thought that’s what the entire 1st paragraph is about? Looking back, this comment is pretty opaque and even I myself am only 90% sure I figured out what I was trying to say. Sorry about that! I think I wanted to have another enumerated item as the "operator's burden", for ensuring the cryptographic chain of custody from manufacturer to operator (for the pre-installed key material, or handles thereto). > > When a router is so configured, the communication with the CA SHOULD > > be automatically re-established by the router at future times to > > renew or rekey the certificate automatically when necessary (See > > Section 9). This further reduces the tasks required of the operator. > > > > Mentioning renewing certificates is natural, as they have a stated end time > > to prepare for. Re-keying certificates is something of a different matter, > > and it would be nice to provide (a link to) some guidance on what > > timescales at which to rekey, if we're mentioning rekeying here. > > (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I > > did not see much concrete on this point.) > > We’d end up in a circular reference point then since they point to our document. The thing here is that the lifetimes of the keys are entirely dictated by the PKI CPs and there’s more than one place to point. Not sure I have good fix for this one. > > Randy/Keyur? Given Randy's comment, maybe we could just remove the mention of "or rekey"? I'm not sure. > > Section 9.4 > > > > Currently routers often generate private keys for uses such as SSH, > > and the private keys may not be seen or off-loaded from the router. > > While this is good security, it creates difficulties when a routing > > engine or whole router must be replaced in the field and all software > > which accesses the router must be updated with the new keys. Also, > > > > This seems to be talking about key management for keys other than > > BGPsec-signing keys. Isn't that out of scope for this document? > > On the one hand yes, but on the other hand no. Because this section is about overall router security we felt it ought to be included and I do not think that it hurts to keep it. And, like people screw this up regularly. > > > any network based initial contact with a new routing engine requires > > trust in the public key presented on first contact. > > > > To allow operators to quickly replace routers without requiring > > update and distribution of the corresponding public keys in the RPKI, > > routers SHOULD allow the private BGPsec key to be inserted via a > > > > Making this a SHOULD is perhaps an overstatement, since AFAICT this > > functionality is not useful for the stated purpose unless the operator has > > access to private keys directly (whether by virtue of the operator having > > generated the keys or an extraction interface on the current routers). > > This is an inherent tradeoff, as stated, between the delay in > > update/distribution of public keys in the RPKI vs. reducing the risk of > > unauthorized key access. I'm not making this a Discuss point because it's > > not exactly my tradeoff to make, but I do want to be sure that this is > > actually the tradeoff that SIDROPS wants to present to the community. > > It’s definitely been in the draft for a while now. I guess folks can speak up if they think it’s wrong. > > Randy/Keyur? > > > protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This > > lets the operator escrow the old private key via the mechanism used > > for operator-generated keys, see Section 5.2, such that it can be re- > > inserted into a replacement router. The router MAY allow the private > > key to be to be off-loaded via the protected channel, but this SHOULD > > be paired with functionality that sets the key into a permanent non- > > exportable state to ensure that it is not off-loaded at a future time > > by unauthorized operations. > > > > This last sentence is a somewhat different topic and could probably stand > > alone as its own paragraph. This would also provde the opportunity to > > clarify that this offload interface is intended for use in conjunction with > > key generation, and the permanent non-exportable state to be applied > > thereafter. > > How about: > > The router MAY allow the private key to be to be off-loaded via the > protected channel after key generation, but this SHOULD be paired > with functionality that sets the newly generated key into a permanent non- > exportable state to ensure that it is not off-loaded at a future time > by unauthorized operations. That's an improvement, thanks. -Benjamin > > Appendix A > > > > I agree with Mirja about the duplication of content and thus non-need for > > normative language. > > Agreed. I removed the 2119-language from Appendix A. > > spt From nobody Thu Feb 14 10:50:40 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B392129441; Thu, 14 Feb 2019 10:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 CIU9r-einn0B; Thu, 14 Feb 2019 10:50:37 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9A91289FA; Thu, 14 Feb 2019 10:50:33 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 36E1D3FD5C; Thu, 14 Feb 2019 18:50:32 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 03B5B2CC256EE; Thu, 14 Feb 2019 18:50:32 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Thu, 14 Feb 2019 18:50:31 +0000 Message-ID: <87bm3euruw.wl%morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:50:39 -0000 Hi Folks, The authors have requested SIDROPS working group adoption call of https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. Please send your comments to the list. This adoption call will conclude on Feb 28 2019. Regards, Chris & Keyur From nobody Thu Feb 14 12:56:02 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA0312D4F2; Thu, 14 Feb 2019 12:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 5wWDQdbfjeFJ; Thu, 14 Feb 2019 12:55:58 -0800 (PST) Received: from limes.NIC.DTAG.DE (limes.nic.dtag.de [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id 07573129532; Thu, 14 Feb 2019 12:55:56 -0800 (PST) Received: from x59.NIC.DTAG.DE (x59.nic.dtag.de [194.25.1.154]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id VAA04335; Thu, 14 Feb 2019 21:55:51 +0100 (MET) To: Chris Morrow cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org From: Ruediger Volk In-Reply-To: Your message of "Thu, 14 Feb 2019 18:50:31 GMT." <87bm3euruw.wl%morrowc@ops-netman.net> Date: Thu, 14 Feb 2019 21:55:51 +0100 Message-ID: <3864.1550177751@x59.NIC.DTAG.DE> Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:56:01 -0000 > The authors have requested SIDROPS working group adoption call of > > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 > > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. > > > > Please send your comments to the list. This adoption call will > conclude on Feb 28 2019. I support adoption of draft-azimov-sidrops-aspa-verification This is good/helpfull stuff; conceptually clean security upgrade. ... worth being progressed quickly. ... and seems to need fairly little work for getting finished. Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv@NIC.DTAG.DE From nobody Fri Feb 15 00:32:30 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18207130F28; Fri, 15 Feb 2019 00:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DzOGa_Fj8zhH; Fri, 15 Feb 2019 00:32:25 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774D7130E7E; Fri, 15 Feb 2019 00:32:25 -0800 (PST) Received: from [193.0.23.13] (helo=bufobufo.ripe.net) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1guYuy-0002mn-C5; Fri, 15 Feb 2019 09:32:20 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::176]) by bufobufo.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1guYue-000879-FE; Fri, 15 Feb 2019 09:32:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Oleg Muravskiy In-Reply-To: <87bm3euruw.wl%morrowc@ops-netman.net> Date: Fri, 15 Feb 2019 09:32:00 +0100 Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6481FF53-402C-4B5F-BAC9-199EDA0BF76D@ripe.net> References: <87bm3euruw.wl%morrowc@ops-netman.net> To: Chris Morrow X-Mailer: Apple Mail (2.3445.102.3) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b7437d9b90796265e57ee963d76ae5f07c1 Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 08:32:27 -0000 > On 14 Feb 2019, at 19:50, Chris Morrow wrote: >=20 >=20 > Hi Folks, >=20 >=20 >=20 > The authors have requested SIDROPS working group adoption call of=20 >=20 > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 >=20 > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. >=20 >=20 >=20 > Please send your comments to the list. This adoption call will = conclude on Feb 28 2019. Support. This is very useful. =E2=80=94=20 Oleg From nobody Fri Feb 15 00:47:45 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D0E130F28; Fri, 15 Feb 2019 00:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 ub5_Cy6VTRqB; Fri, 15 Feb 2019 00:47:43 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1966A129A87; Fri, 15 Feb 2019 00:47:43 -0800 (PST) Received: from [IPv6:2a04:b900::1:e94f:fdca:e5d:a674] (unknown [IPv6:2a04:b900:0:1:e94f:fdca:e5d:a674]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A7B381BB8D; Fri, 15 Feb 2019 09:47:40 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1550220460; bh=RYf7Qr6POtf5u4uCuRGYGVaKc53pXoxZiu0WB67VlJA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JDB2Wsbry2DMST83lvpSRQqKBYfJMi4+CudqjITbVyYMVH1wjBdeRp162Cq+yuwZv MWS32duB0qP/DOpeYw50B3KKYiMeuwz+GUVVJGUqmwZswuwiINoZV+H/Iz050sqH+F 3X5RuasMbpQvBGd1G9RlR2/nbHjJdPiG3hMsxYiw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: <87bm3euruw.wl%morrowc@ops-netman.net> Date: Fri, 15 Feb 2019 09:47:40 +0100 Cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87bm3euruw.wl%morrowc@ops-netman.net> To: Chris Morrow X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 08:47:45 -0000 To repeat my message from 7 december last year, I support adopting this = work. Tim > On 14 Feb 2019, at 19:50, Chris Morrow wrote: >=20 >=20 > Hi Folks, >=20 >=20 >=20 > The authors have requested SIDROPS working group adoption call of=20 >=20 > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 >=20 > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. >=20 >=20 >=20 > Please send your comments to the list. This adoption call will = conclude on Feb 28 2019. >=20 >=20 >=20 > Regards, >=20 > Chris & Keyur >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Fri Feb 15 08:50:45 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039E8130FC1 for ; Fri, 15 Feb 2019 08:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 vx7L6SZ11NfT for ; Fri, 15 Feb 2019 08:50:41 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FDE130D7A for ; Fri, 15 Feb 2019 08:50:41 -0800 (PST) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x1FGoZNv051569 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2019 16:50:36 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Chris Morrow Cc: sidrops@ietf.org References: <87bm3euruw.wl%morrowc@ops-netman.net> From: Nick Hilliard Message-ID: <7c716be8-1858-0c71-a839-e23ed74285f7@foobar.org> Date: Fri, 15 Feb 2019 16:50:34 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.10 MIME-Version: 1.0 In-Reply-To: <87bm3euruw.wl%morrowc@ops-netman.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 16:50:43 -0000 Chris Morrow wrote on 14/02/2019 18:50: > Hi Folks, > > The authors have requested SIDROPS working group adoption call of > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. > > Please send your comments to the list. This adoption call will conclude on Feb 28 2019. this is not completely stupid. We should adopt and subject it to review-by-committee. Nick From nobody Fri Feb 15 09:38:46 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940C7130FFF for ; Fri, 15 Feb 2019 09:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Jvhw5bFHwfyV for ; Fri, 15 Feb 2019 09:38:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD091128BCC for ; Fri, 15 Feb 2019 09:38:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1guhRa-0001tU-Pe; Fri, 15 Feb 2019 17:38:34 +0000 Date: Fri, 15 Feb 2019 09:38:34 -0800 Message-ID: From: Randy Bush To: Nick Hilliard Cc: Chris Morrow , sidrops@ietf.org In-Reply-To: <7c716be8-1858-0c71-a839-e23ed74285f7@foobar.org> References: <87bm3euruw.wl%morrowc@ops-netman.net> <7c716be8-1858-0c71-a839-e23ed74285f7@foobar.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 17:38:42 -0000 >> The authors have requested SIDROPS working group adoption call of >> https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 >> https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. >> >> Please send your comments to the list. This adoption call will >> conclude on Feb 28 2019. > > this is not completely stupid. We should adopt and subject it to > review-by-committee. nah, we just need reviewer #2 From nobody Mon Feb 18 18:00:17 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C75412E04D for ; Mon, 18 Feb 2019 18:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 j7o-OBTYpmEs for ; Mon, 18 Feb 2019 18:00:14 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59B9130D7A for ; Mon, 18 Feb 2019 18:00:11 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id y140so11147395qkb.9 for ; Mon, 18 Feb 2019 18:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MyzUAd3NkDr6foikNbtpxwOX5U3SioEYI3uIEMeT5fc=; b=PELEjF3TclhI9phcKjyYjPziLg2qkQH0+45RA/yIjm9m57geKSp2XOwOzRRDplakmz rf70hkscVigZguNU885p1Qubiscv1Eoa1/sIOtJBPwi/0lc3Hmigd1iQek9NBHuLs74m JUImY+AeJMagLFhFsGiYrbdztHjdFzYAYwEMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MyzUAd3NkDr6foikNbtpxwOX5U3SioEYI3uIEMeT5fc=; b=GFAxPjWWoEH6xjoeS7XmiCwtCA77GOhs+RuWSBMSxHorQ85/MkVeiEuG6Ey/m6oVkB gg4eN4344fxhrTpxxe5Gg7+PAsyv3XKStMwRysMsrxmDxvT1nvb/QU1mUH0gZ7/lGTYz YZPafn/wV+qya10uvivOUzwFSwfpCiOnM/lIXxrbrOTxGuDwE9L39682JExAglqQ+dFX U3viGqgjRXouBH/Os0+VI78UzRf9mAXBu5xynHoXX7Ay95AgpAH/wZcnjRHAgkYdt+XA XsMvs2FAAdOzP99HRLnNNfxepXYziKtKx1UXPUnicOJYRbs/ZjveMnn/yCg8vqVILPdt 4ybw== X-Gm-Message-State: AHQUAubPAHh2lFFEqDpEjzpJIBuZZPA/tMrtG9XhAXLVZfLhqWI6rGsf c/W3+PA+gP7wvSsb5+w9gtRIvA== X-Google-Smtp-Source: AHgI3IYQA15tpSxWp+ohZi7TuUB2jDvfVnHviCgQ/b3XERzKJTbUoQEaD8VAhgn2SP/aDc7NfcnQEA== X-Received: by 2002:a37:b146:: with SMTP id a67mr18569202qkf.240.1550541610696; Mon, 18 Feb 2019 18:00:10 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id o42sm9373042qtc.90.2019.02.18.18.00.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 18:00:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <20190214011028.GF56447@kduck.mit.edu> Date: Mon, 18 Feb 2019 21:00:07 -0500 Cc: draft-ietf-sidrops-rtr-keying@ietf.org, The IESG , Chris Morrow , SIDROps Chairs , SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <154809167315.8136.10582122386859681488.idtracker@ietfa.amsl.com> <9790FD28-6AF0-4C0B-B7E6-8B42FE1E3724@sn3rd.com> <20190214011028.GF56447@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 02:00:16 -0000 > On Feb 13, 2019, at 20:10, Benjamin Kaduk wrote: >=20 > On Tue, Feb 12, 2019 at 09:25:40PM -0500, Sean Turner wrote: >>=20 >>=20 >>> On Jan 21, 2019, at 12:27, Benjamin Kaduk wrote: >>>=20 >>> Section 1 >>>=20 >>> For example, when an operator >>> wants to support hot-swappable routers, the same private key needs = to >>> be installed in the soon-to-be online router that was used by the = the >>> soon-to-be offline router. This motivated the operator-driven >>> method >>>=20 >>> As the secdir review notes, there is no need to copy private keys to = hot-swap routers >>> (unless there is something special about the "hot-swap" case that = nullifies >>> the arguments he made?). >>>=20 >>> It rather seems that we should avoid framing this behavior as = justified by >>> a need for hot-swapping, but rather as something that people do to = work >>> around processes that do not admit the more secure workflow, as an >>> operational reality. >>=20 >> Would something like the following work: >>=20 >> The operator-driven model is motivated by ensuring the network = operates. >=20 > "motivated by the extreme importance placed on ensuring the continued > operation of the network"? >=20 >> In some deployments, the same private key needs to >> be installed in the soon-to-be online router that was used by the = the >> soon-to-be offline router (i.e., operators need to support = hot-swappable >> routers. >=20 > Per Randy's suggestion, I might drop the parenthetical and go with > "soon-to-be-offline router, since this "hot-swapping" behavior can = result > in minimal downtime, especially compared with the normal RPKI = procedures to > propagate a new key, which can take a day or longer to converge". >=20 >>=20 >> BTW - I am totally open to wording suggestions. Thanks for the suggestions. I=E2=80=99ll incorporate in the next = version. >>> Section 2 >>>=20 >>> (see [RFC6470]), the protected the protected channel between the >>>=20 >>> nit: duplicate "the protected=E2=80=9D >>=20 >> fixed >>=20 >>> Section 5 >>>=20 >>> The PKCS#10 request SHOULD be saved to enable verifying that the >>> returned public key in the certificate corresponds to the private >>> used to generate the signature on the CSR. >>>=20 >>> I mostly assume this is done by the party that generates the CSR, = though >>> perhaps one could read it as being done on the router always. (I = guess >>> later on we do recommend both the operator and router to do this >>> verification.) This could be reworded, though, either to remove the = 2119 >>> language ("Retaining the CSR allows for verifying that [...]" or to = apply >>> to the actual verification as opposed to just the saving. >>=20 >> I am all about dropping 2119-lang where we can so will reword as = suggested: >>=20 >> Retaining the CSR allows for verifying that the >> returned public key in the certificate corresponds to the private >> used to generate the signature on the CSR. >=20 > SGTM >=20 >>> Section 5.1 >>>=20 >>> NOTE: If a router were to communicate directly with a CA to have = the >>> CA certify the PKCS#10 certification request, there would be no way >>> for the CA to authenticate the router. As the operator knows the >>> authenticity of the router, the operator mediates the communication >>> with the CA. >>>=20 >>> nit: I think that the thing we care about here is the CA's ability = to show >>> that the request is authorized. The operator is assumed to have an >>> account/relationship with the CA and a channel via which to = authorize >>> cert-signing requests. >>=20 >> Yes >>=20 >>> In particular, "no way" is a rather strong >>> statement, and would seem to deny the possibility of a three-party = workflow >>> where the router sends the CSR to the CA but the operator logs in to = the CA >>> independently and is presented with a list of pending requests to = approve. >>> (It would also preclude the operator from delegating their = authorization at >>> the CA to the router, as described in Section 8.) >>=20 >> Okay fair point. Maybe we reword it to say: >>=20 >> NOTE: The CA needs to now that the router-generated CSR is = authorized. >> The easiest way to accomplish this for the operator to mediate the >> communication with the CA. Other workflows are possible, e.g., >> where the router sends the CSR to the CA but the operator logs in to = the CA >> independently and is presented with a list of pending requests to = approve. >>=20 >> Again, totally open to word smithing. >=20 > No changes to your proposal are immediately jumping out at me, though = I do > wonder if a xref to section 8 is worth attempting. (AFAICT it would > require additional wordsmithing, though, which we may lack motivation = to > pursue.) If it=E2=80=99s just missing a pointer to s8, maybe this would work: See Section 8 for an additional workflow. >>> Section 8 >>>=20 >>> More PKI-capable routers can take advantage of this increased >>> functionality and lighten the operator's burden. Typically, these >>>=20 >>> nit: most readers will not bind "this" to the right thing and will = instead >>> be left confused. >>=20 >> I am thinking I could just strike the =E2=80=9Dthis=E2=80=9D. >>=20 >>> Why do we not mention the need to get the manufacturer-installed key >>> material (or information thereof) to the operator? >>=20 >> But, I thought that=E2=80=99s what the entire 1st paragraph is about? >=20 > Looking back, this comment is pretty opaque and even I myself am only = 90% > sure I figured out what I was trying to say. Sorry about that! >=20 > I think I wanted to have another enumerated item as the "operator's > burden", for ensuring the cryptographic chain of custody from = manufacturer > to operator (for the pre-installed key material, or handles thereto). That I can get behind. How about: - Ensuring the cryptographic chain of custody from the manufacturer to = operator. For the pre-installed key material, the operator needs = guarantees that either no one has access the private key or an = authenticated log of those who have accessed it has been provided to the = operator. >>> When a router is so configured, the communication with the CA = SHOULD >>> be automatically re-established by the router at future times to >>> renew or rekey the certificate automatically when necessary (See >>> Section 9). This further reduces the tasks required of the = operator. >>>=20 >>> Mentioning renewing certificates is natural, as they have a stated = end time >>> to prepare for. Re-keying certificates is something of a different = matter, >>> and it would be nice to provide (a link to) some guidance on what >>> timescales at which to rekey, if we're mentioning rekeying here. >>> (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, = but I >>> did not see much concrete on this point.) >>=20 >> We=E2=80=99d end up in a circular reference point then since they = point to our document. The thing here is that the lifetimes of the keys = are entirely dictated by the PKI CPs and there=E2=80=99s more than one = place to point. Not sure I have good fix for this one. >>=20 >> Randy/Keyur? >=20 > Given Randy's comment, maybe we could just remove the mention of "or > rekey"? I'm not sure. Yep let=E2=80=99s remove it. spt= From nobody Tue Feb 19 07:25:41 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45616130E0A; Tue, 19 Feb 2019 07:25:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4aELHc_OsEHJ; Tue, 19 Feb 2019 07:25:38 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6103112870E; Tue, 19 Feb 2019 07:25:38 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id h11so7931351pgl.0; Tue, 19 Feb 2019 07:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=WCYklrygf5oSSKjKUELCCgi+xr9WdZ8h4kUioxHTW6o=; b=XwG7kddGOBBftY6u0G0+Jd3l2ve+Dz/iEskS+DqdzfxPbGq8QWp8e1G/JHS3zIuGhQ tb6MznJYFfuRcDcsldiQfnafzJOBDjQ+0LsQDdwtrx+vuEaXuRdr3a3RjdOHynA2cz8k r25unG8as93+OBYD2ezYnvo3ZZM61mQzlwZ+s5fQiNWFfmYYFKmim4RcPwZgmzD1Xnvv xiezifuCJRfdivwUhHlzdTjvwC0PPw5cdfkfGrPKHA8Yk9PETrg/R4V1vUGgCPJHpm72 q+beOb2MJmkoUI8HJf5YfYP7f3YdvXAuHBosVP5a/KAxi4t3V1LGTYAcfMqwFj4JrS8S 4hIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=WCYklrygf5oSSKjKUELCCgi+xr9WdZ8h4kUioxHTW6o=; b=qb+hVawQuVMX4KGhw8R+uq0YukInk7+247ZBCb47Aqb2uPhlNbRZYqH76EVKmaWAiy jV9+LJCGVVjQfv4aalvfGRDSVWJzpyK7BkJx0dIJGqum25oFeF8IIRUcwi8u7MgRHUCo KPVOR0UgVK7BEurGizz+3rh+WXLilY/vwNl7g1eAehO8gYSQUp+ELeLo9YhKxdQqAQqb Up8qQBbEU5u/Ygr7eNzaZcaFyR9YKOg39u1dBvmsW4sWV+NdYJKnvZOhxCF/W/Mg7+vr 5NtTa+C/SKHFM/Q27GHHGhI24CffhpVhkkwHqvcpocRS6LFeTDOdaBZ8RGQ2eQcaL99H gwtQ== X-Gm-Message-State: AHQUAuYd9SmBxGNLnAAXThHbZZjASX7Kl5tEuutmhlC7iwf9/p9XgccY gXJhvXPmXgsM/h59H7x7ris= X-Google-Smtp-Source: AHgI3IZ3sbuvyfiC+a+1l8Og8Ilq/krNbJRa10NJxYJ5h7kvK/oDrTmmmKWwOnj6FMGnc/sRB35WQQ== X-Received: by 2002:a62:1d0c:: with SMTP id d12mr30044497pfd.126.1550589937787; Tue, 19 Feb 2019 07:25:37 -0800 (PST) Received: from admins-MacBook-Pro-176.local ([12.197.85.240]) by smtp.googlemail.com with ESMTPSA id v15sm17990789pfa.75.2019.02.19.07.25.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 07:25:37 -0800 (PST) To: Chris Morrow , sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org References: <87bm3euruw.wl%morrowc@ops-netman.net> From: Andrei Robachevsky Openpgp: preference=signencrypt Autocrypt: addr=andrei.robachevsky@gmail.com; prefer-encrypt=mutual; keydata= mQGiBD8L4TQRBACI+LX/GwEK23h5OXLU7iPeZc8FJ0ywH1vVqY/gT8VCs7YzbG4GNV6omEqa 0sDBF/eYKzLC5PfaKkHeAJ51eVIcDqYDhqYNlaxr5XPWWYjOIGvVRDmp4RKxhhDgXgKMmisW RrMCCP1njNQEWYtuB64UUNit1VXbQXn2FBpEXisqxwCg6hZK7Seg5md07iu9lYQx5rng+C0D /2TkPt4t80x3Iw8WV7TSLKdEQMRG42FMIFbaZIKbiEwvfaZYNrOckxdTr8l8LvwxNxHePsVi 1sqjBR8iwtogvLhSudqXxXsj2BiYfGSpTJoiVRPKdlEzo3i1mFPV/dNTSjovzWz5c21nW9kK fUIY43sLD5aynB9WITl9O6iawOrxA/0cOwOOVrpwHdLg+Uxb9y8C/1mx3o307hZDbn84Zare aiQNOn+ETI45ucON72OoMnuaBs3fJOoreXoaOSIxuM5gSQDY/SyDqncPhZmQX8yA52fuc3Ol 8qBjEomymafFymRUFvphEr/KD9BpyBZqM41zrT5VEu2tk/ga5T+bC79W77QxQW5kcmVpIFJv YmFjaGV2c2t5IDxhbmRyZWkucm9iYWNoZXZza3lAZ21haWwuY29tPoh5BBMRCgA5AhsjBgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBGtZeFNYETVQoSYbeZY8+bWZrYo/BQJadGb/AAoJ EJY8+bWZrYo/pGgAoNlUk0Nu3km8dAtzOlrN5bveacodAJ4jwG65QN2EhvnTgHGQEybn9IjN 0LkBDQQ/C+E1EAQAvRN7YTDiGXS9OPLX5yDKBtvjQaR38t5zpi0ltuC5JITDKZdM6/9PCfJq QnMy+ngrI3VQdhxbduFrC5fBszo1vVMTwKrTD6D7BEsEgC3wNE5NzfzE/fjl0LkQMEf5Vxns jvbtYw2jfoyJFig2gdW4ojmBCge16RZwx7vK7Pn0z6MAAwYEAJ7zZZCCU2DZ/gPdfB3xPZVm 7XSMpG6GBz4mFGgJW/QeC2quqoKBeAEgf0icEM8ykEAPmpy8f6j0Fwe/qz/SgxOXfTlvH8O7 md6rx2t2D+1PM2PlYzwO37U5fqnPuzp5KMXlPPryuTWZmObgZMHHsko9BbpIcqNHqUNXzNwk +gjkiEYEGBECAAYFAj8L4TUACgkQljz5tZmtij/lFQCdGIvMimtJEiYiPIZYSvXI6hx8WOQA oMj/ni+WopJxWu947/5RyWR6AUpH Message-ID: <74a8c64a-f0bd-0659-972e-2b79993986e2@gmail.com> Date: Tue, 19 Feb 2019 16:25:14 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <87bm3euruw.wl%morrowc@ops-netman.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TXcQ7kk6gnn2p1UZipjUL7yBGdNLoWmad" Archived-At: Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 15:25:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TXcQ7kk6gnn2p1UZipjUL7yBGdNLoWmad Content-Type: multipart/mixed; boundary="vU4jOtOKxBmIJu5jdRwy1CQnZ4f4kjHEC"; protected-headers="v1" From: Andrei Robachevsky To: Chris Morrow , sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Message-ID: <74a8c64a-f0bd-0659-972e-2b79993986e2@gmail.com> Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification References: <87bm3euruw.wl%morrowc@ops-netman.net> In-Reply-To: <87bm3euruw.wl%morrowc@ops-netman.net> --vU4jOtOKxBmIJu5jdRwy1CQnZ4f4kjHEC Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Chris Morrow wrote on 14/02/2019 19:50: >=20 > Hi Folks, >=20 > =20 >=20 > The authors have requested SIDROPS working group adoption call of=20 >=20 > https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01 >=20 > https://datatracker.ietf.org/doc/draft-azimov-sidrops-aspa-profile/. >=20 > =20 >=20 > Please send your comments to the list. This adoption call will conclude= on Feb 28 2019. I support adoption of the draft. Promise a review. Regards, Andrei >=20 > =20 >=20 > Regards, >=20 > Chris & Keyur >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 --vU4jOtOKxBmIJu5jdRwy1CQnZ4f4kjHEC-- --TXcQ7kk6gnn2p1UZipjUL7yBGdNLoWmad Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iF0EARECAB0WIQRrWXhTWBE1UKEmG3mWPPm1ma2KPwUCXGwf2wAKCRCWPPm1ma2K P+QaAJ92ydv4VbsrCgFaVuOYkJQ6HXeshgCdEDEyVCxHkxIUYj8R4EFeVdB26A4= =nlbl -----END PGP SIGNATURE----- --TXcQ7kk6gnn2p1UZipjUL7yBGdNLoWmad-- From nobody Thu Feb 21 02:31:33 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093361276D0 for ; Thu, 21 Feb 2019 02:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ymlGzPwmBOzC for ; Thu, 21 Feb 2019 02:31:29 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58FA0130DC2 for ; Thu, 21 Feb 2019 02:31:29 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for sidrops@ietf.org with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gwldX-000iAR-Db>; Thu, 21 Feb 2019 11:31:27 +0100 Received: from x4e37b68a.dyn.telefonica.de ([78.55.182.138] helo=mw-x1.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) for sidrops@ietf.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gwldX-001ewH-5a>; Thu, 21 Feb 2019 11:31:27 +0100 Date: Thu, 21 Feb 2019 11:31:25 +0100 From: Matthias Waehlisch To: sidrops@ietf.org Message-ID: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 78.55.182.138 Archived-At: Subject: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 10:31:31 -0000 Hi, I read the (expired) draft draft-sidrops-rpkimaxlen. The problem analysis in the draft is misleading. The problem is not the usage of the max length field. Even without a max length field, a "forged-origin subprefix hijack" may occur easily. For example, a minimal, more specific ROA has been created, and the prefix is currently not announced by the origin AS configured in the ROA. The draft implicitly suggests: "Only create ROAs for prefixes that are currently announced." I'm not sure whether the WG has consensus about that. The draft is expired. I suggest to leave it expired because it leads to incorrect conclusions, see for example https://github.com/DECIX/RPKI/wiki/RPKI-deployment-options Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Thu Feb 21 02:59:00 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AD3130F19 for ; Thu, 21 Feb 2019 02:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 g_MCd2lZqVQt for ; Thu, 21 Feb 2019 02:58:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5721276D0 for ; Thu, 21 Feb 2019 02:58:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gwm46-0000Eg-AL; Thu, 21 Feb 2019 10:58:54 +0000 Date: Thu, 21 Feb 2019 19:58:51 +0900 Message-ID: From: Randy Bush To: Matthias Waehlisch Cc: sidrops@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 10:58:59 -0000 > The problem analysis in the draft is misleading. you are too polite > The problem is not the usage of the max length field. Even without a > max length field, a "forged-origin subprefix hijack" may occur easily. > For example, a minimal, more specific ROA has been created, and the > prefix is currently not announced by the origin AS configured in the > ROA. yep > The draft implicitly suggests: "Only create ROAs for prefixes that are > currently announced." I'm not sure whether the WG has consensus about > that. that'll be great for all the make before break scenarios: ddos mitigation, provider switching, ... > The draft is expired. I suggest to leave it expired because it leads > to incorrect conclusions yep randy From nobody Fri Feb 22 08:21:16 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F90130F73; Fri, 22 Feb 2019 08:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=gkcKQGJ3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=8BkWjFrE 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 aiuLtr2SU_wS; Fri, 22 Feb 2019 08:21:09 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AA3130F06; Fri, 22 Feb 2019 08:21:09 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 62D0023A30; Fri, 22 Feb 2019 11:21:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 22 Feb 2019 11:21:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=e Wf9Hk9oMUDKr/vFRjGdvzY164CpJ1AnOHFJ2tpvqkA=; b=gkcKQGJ3+yn6zWkZg hoPepB4UJQRSViQq0GYeYks7ezN8X42TlUtapTYK5Er3SkiI5PQhvHdAcwuE8scF wN4mdsClMqXzPBquteU0Ffu3LVwk5ae+bRssUKNBm9wsAbsuvNu/Yq0Dg2ZAgb5C X27TPvc+fA67Z/rghkM63iA3+p7w2wtExr87z2eFpo40e+QlmMDFLyyDECjSFSor tgiTsHKI3BzCIVuhX9/YHl8qIJBcKC4kaCTm77Rx+b38+MnCGKVeuFB3Qd51nrKa AK/cB7xyUELFvL8Y4V8UKs6dzs60PwGldc3Ik5MHlWF5KLU89Vs5sHzoOfxz2lnp Zc/sQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=eWf9Hk9oMUDKr/vFRjGdvzY164CpJ1AnOHFJ2tpvq kA=; b=8BkWjFrEdJ5Ta8F0YaprPd5zCTCdsDtpSEIw+z+VZobZQ1lBWxhr5xibk kQNfQL4VHr2J4DcDKdqKrNhZSb6HIphURtXHNKDXUmKOANyeL8EmxxOr7v0ytzIC 5eNwJPl2ucyu+O+/6Hv+D+W837g46Ef+diVrN09wvzKfHNLx1UCUBXPlbiMb8byD luM6tmM41fmkWegN6ON6crsLC2Kt9hFv0pGZ8/clPg214mSWpYKjrzzV3GMvZq6a ojt6azlldfFWH/sLKBSl4TiqLrWf23TFKMPIz1JTFEpUindiJtUX/+BjPNmemvAY x1p393fuGc94a5q+1hfUrOVQGPQlA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddruddtgdekleculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrieejnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.67]) by mail.messagingengine.com (Postfix) with ESMTPA id D3A83E4210; Fri, 22 Feb 2019 11:21:06 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <9AAC1676-E54A-4049-8AC7-BFC257E4A692@sn3rd.com> Date: Fri, 22 Feb 2019 11:21:05 -0500 Cc: The IESG , draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <15766BFC-B054-4748-B4D8-45C6EC15F521@cooperw.in> References: <154827316130.7453.12140820828793016275.idtracker@ietfa.amsl.com> <9AAC1676-E54A-4049-8AC7-BFC257E4A692@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] Alissa Cooper's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 16:21:14 -0000 Hi Sean, > On Feb 12, 2019, at 9:25 PM, Sean Turner wrote: >=20 >=20 >=20 >> On Jan 23, 2019, at 14:52, Alissa Cooper wrote: >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-sidrops-rtr-keying-03: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> As this is a BCP, I don't understand why transport encryption of the = private >> key is not normatively required. Could you explain? >=20 > I guess there are a couple of issues here: >=20 > 1. deployment - I think there are two cases we need to consider: a) = router is plugged into rack and managed over the LAN via the networked = administration interface (i.e., RJ45), but there are also times when the = operator sits down with box that=E2=80=99s not network connected and = jacks into the router via the =E2=80=9Ccraft port=E2=80=9D. The former = case sure, you=E2=80=99d want to mandate it, but in the later is it a = MUST? >=20 > 2. Object level security (which I think BenC also commented on): I = would love to have object security, but the key needed to decrypt the = encrypted needs to get onto the router before the encrypted key does. = We could do something PBE-based maybe or rely on the manufacturers = having burned some key into the box that we can use. Unfortunately, = this bootstrapping problem isn=E2=80=99t new and not solved well - we = didn=E2=80=99t attempt to do it here. >=20 > 2. Transport encryption (which I think ekr also commented on as being = underspecified): The draft does include the following: >=20 > Operators are free to use either the router-driven or operator-driven > method as supported by the platform. Regardless of the method > chosen, operators first establish a protected channel between the > management system and the router. How this protected channel is > established is router-specific and is beyond scope of this document. > Though other configuration mechanisms might be used, e.g. NetConf > (see [RFC6470]), the protected channel between the > management platform and the router is assumed to be an SSH-protected > CLI. See Appendix A for security considerations for this protected > channel. >=20 > So transport security is required unless you got a really good reason = not to do it - like maybe you=E2=80=99re plugged directly into the = router and the router=E2=80=99s just being brought to life. Since both = you and ekr had the same kind of DISCUSS I will try to address it in = that thread. Maybe it=E2=80=99s as easy as explaining the two cases and = providing requirements for the networked protocol. I think such an explanation would suffice for me. My naive reading of = this assumed that =E2=80=9Ctransit=E2=80=9D and =E2=80=9Ctransport=E2=80=9D= imply a connection between two nodes that aren=E2=80=99t necessarily = under the control of the same human at the time of the transfer, and a = network-connected router. Thanks, Alissa >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Given that this document is ostensibly specifying a "best" current = practice, I >> would have expected a clearer expression of preference for the = router-driven >> method over the operator-driven method, e.g., something like = BGPsec-speaking >> routers MUST implement the router-driven method and MAY implement the >> operator-driven method. Or if there is some exception case that makes = that MUST >> problematic, it would at least be good to emphasize which one of = these is >> actually "best" from a security perspective, even though the other = one is being >> specified and we know will be used. >=20 > The way I was looking at =E2=80=9Cbest" is that there are a set of = routers that do what they do; some do operator-driven and some do = router-driven (and some support advanced deployment scenarios). = Further, these routers are probably already out in the field and getting = BGPsec bolted on so what operations the router supports it supports. = And, it wasn't clear to me that picking one over the really made sense. >=20 >> Nit in Section 1: >>=20 >> s/gritty details/details of the BGPsec protocol/ >=20 > fixed >=20 > spt >=20 From nobody Fri Feb 22 23:28:23 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9748131055; Fri, 22 Feb 2019 23:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QPkV0HXka8nW; Fri, 22 Feb 2019 23:28:18 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F93131050; Fri, 22 Feb 2019 23:28:18 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id v72so6666956itc.0; Fri, 22 Feb 2019 23:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gvKybK2Zi2dK0D3hUwD4go/xeHckJ7m47EFM2+cAorU=; b=BJWiyBxs9A4V2TgIGA+fA1N2tENTB8VeiSpFKiYYwtLZd1UekPtPpdkuMLdzgEpY7m HD4pD28nQD5DNrLWfSkJddlZE5jFfmaXWX2s6NvY4Y6llASNxpXrd/L9jWduwUUCWmmp Hg7WR0QBJoojSqas2SprKxB8H7kc4T/GSIjHQ6hVfNasufZuRYoUiYv3VX6fXNeWOSGK ne83alTFcYaGfOpOiB7JOcdsHQ66pC7gaNoARzNFX1VZMYwnoL4nYxnKFnHsAS61NYoZ QcrPyhzCqoDjR4tLSY/di5gVkmurIAkqpcWH0DUbvJcqoc8RnIzmbeqWVLrDX7gEQ8D2 B9mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gvKybK2Zi2dK0D3hUwD4go/xeHckJ7m47EFM2+cAorU=; b=uJdcpw3mfJ9r2/8kiUKkKtqpYgwr84DrXhJFOshrPvJ8x5WX20lqT88v6wnRwpF1Mx aMlMIxiBTgJ8w3P2mc+MkVWLXzqXsnb5dY/UrdXYwHzT7V0MkwnbsB7veC+T22WQqwFi OYZWl4Cxd22glZhPZ3666e/VRznM4iCHt8aJIbff3TvqgOVQJBaCpa6BHOVC49xfSkuv WBOg1p1wXhIIGKvxGwvh3fYVq12BDuaQWmQtedRs4uO82a9E1w+IQJoicfheTcubBbhm 0f23H7TnVdhFAuWnolTNQaRf7yhMUgsnhFNn2zegSRPS1OZwEHN8XYJCNOe4ePT5hkoW /AkA== X-Gm-Message-State: AHQUAubXrQcneLnu8LDKdj/39/2VnEQ1UtCdE72L16IX3BsRD06AGzh2 rNsg5gpgi7fADvO/Bvi+xCCxr1heTmHyBaFKcaI= X-Google-Smtp-Source: AHgI3IZBZblmkbqrYhxU5fl3EX7eairFHrlLikbZrqPqgDhvOQ5u4lNKnHKaFoDpYKbyeohu+g/Brxb/fQuvExPYJUo= X-Received: by 2002:a24:7f81:: with SMTP id r123mr4410367itc.89.1550906897253; Fri, 22 Feb 2019 23:28:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Morrow Date: Sat, 23 Feb 2019 02:28:04 -0500 Message-ID: To: "Sriram, Kotikalapudi (Fed)" Cc: "sidrops@ietf.org" , "sidrops-chairs@ietf.org" , "Borchert, Oliver (Fed)" , Sean Turner Content-Type: multipart/alternative; boundary="000000000000b0cc7005828aa680" Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends 20-Aug-2018 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 07:28:21 -0000 --000000000000b0cc7005828aa680 Content-Type: text/plain; charset="UTF-8" Howdy. 'better late then... ' Anyway. I'm going to forward this off to the iesg for review/etc. On Tue, Aug 21, 2018 at 7:30 PM Sriram, Kotikalapudi (Fed) < kotikalapudi.sriram@nist.gov> wrote: > I support the publication of this draft. > > I have reread the draft carefully. It is well written. > Makes important and essential additions and corrections to RFC 8208. > I found a few typos and minor edits which I have communicated to the > authors. > > Sriram > > > ------------------------------------------------------------------------------------------------------------ > From: Sidrops on behalf of Christopher > Morrow > Date: Monday, August 6, 2018 at 8:59 PM > To: , , ietf.org> > Subject: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends > 20-Aug-2018 > > Howdy WG Folken! > Let's discuss the document: > > https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ > > which has an abstract saying: > "This document specifies the algorithms, algorithm parameters, > asymmetric key formats, asymmetric key sizes, and signature formats > used in BGPsec (Border Gateway Protocol Security). This document > updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature > Formats") by adding Special-Use Algorithm IDs and correcting the > range of unassigned algorithms IDs to fill the complete range. > > This document also includes example BGPsec UPDATE messages as well as > the private keys used to generate the messages and the certificates > necessary to validate those signatures." > > Let's see if there are any items still to address here, and if not move > this forward to publication. > > Last Call ends 20-aug-2018! > > thanks! > > -chris > > co-chair#2 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000b0cc7005828aa680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy.
'better late then... ' Anyway.
I'm going to forward this off to the iesg for review/etc.

On= Tue, Aug 21, 2018 at 7:30 PM Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> wrot= e:
I support the= publication of this draft.

I have reread the draft carefully. It is well written.
Makes important and essential additions and corrections to RFC 8208.
I found a few typos and minor edits which I have communicated to the author= s.

Sriram

---------------------------------------------------------------------------= ---------------------------------
From: Sidrops <sidrops-bounces at ietf.org> on behalf of Christopher Morrow= <christopher.morrow at gmail.com>
Date: Monday, August 6, 2018 at 8:59 PM
To: <sidrops at ietf.org>, <sidrops-chairs at ietf.org>, <sidrops-ads at= ietf.org<= /a>>
Subject: [Sidrops] WGLC: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis - ends = 20-Aug-2018

Howdy WG Folken!
Let's discuss the document:
=C2=A0 https://datatrack= er.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/

which has an abstract saying:
=C2=A0 "This document specifies the algorithms, algorithm parameters,<= br> =C2=A0 =C2=A0asymmetric key formats, asymmetric key sizes, and signature fo= rmats
=C2=A0 =C2=A0used in BGPsec (Border Gateway Protocol Security).=C2=A0 This = document
=C2=A0 =C2=A0updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Si= gnature
=C2=A0 =C2=A0Formats") by adding Special-Use Algorithm IDs and correct= ing the
=C2=A0 =C2=A0range of unassigned algorithms IDs to fill the complete range.=

=C2=A0 =C2=A0This document also includes example BGPsec UPDATE messages as = well as
=C2=A0 =C2=A0the private keys used to generate the messages and the certifi= cates
=C2=A0 =C2=A0necessary to validate those signatures."

Let's see if there are any items still to address here, and if not move= this forward to publication.

Last Call ends 20-aug-2018!

thanks!

-chris

co-chair#2
_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--000000000000b0cc7005828aa680-- From nobody Sat Feb 23 14:04:19 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15A4130DDA; Sat, 23 Feb 2019 14:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 b0YLHXu9gpBA; Sat, 23 Feb 2019 14:04:14 -0800 (PST) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840102.outbound.protection.outlook.com [40.107.84.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8A0130F7B; Sat, 23 Feb 2019 14:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=emwGyazwhSmkLBoj6Y/VtdPRbzTuvXNxloOJZ3/0MOU=; b=Qt6UnMjKUMaGGOCnPT8HPtcL8TY4TZ94QyOMEcCg0yidJlUNkq/3AZVPst+hUwDpq75co+xoUnaFMucbzQn3rL4X0vlf6sX5NFLnG+PSnK6WVlTytVl9XQoN924f/16dDHti1dUwJx9/Jc4h2j43lL7wm0TpQTGIsCulPZ6olTU= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2368.namprd09.prod.outlook.com (52.132.116.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Sat, 23 Feb 2019 22:04:07 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1643.016; Sat, 23 Feb 2019 22:04:07 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Matthias Waehlisch CC: "sidrops@ietf.org" , "draft-ietf-sidrops-rpkimaxlen@ietf.org" Thread-Topic: [Sidrops] draft-sidrops-rpkimaxlen Thread-Index: AQHUy8AmUSoU77RRv0K+rD/l/1dVIg== Date: Sat, 23 Feb 2019 22:04:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c1bd40d5-541d-4469-54a2-08d699dad528 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2368; x-ms-traffictypediagnostic: SN6PR0901MB2368: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; SN6PR0901MB2368; 23:MSCPnjwSW7F+DaFJY/N1OFXDHS3OitE0RzD6c?= =?iso-8859-1?Q?vwFCYEqat3z5fnGr0tfdXy/OL8dRPF1CTPVm4QfhDjk7H0O1xrhnNAf8ui?= =?iso-8859-1?Q?skDBZR1J7u87/wvVI2GB/hocHY+LnikUyT+DpSfdDC15NJcb3ZLceK7i07?= =?iso-8859-1?Q?+KHVW8B1jJPG6904rkty+MCVKw43uKoexukFF9EdoRTsiZZVqfKcmPCWgF?= =?iso-8859-1?Q?4Eh5bqb5DRXDmfn8cQLd1PFOiE8JeWMZ6HpFOTisJK/3eYyMfeKtYCfFzo?= =?iso-8859-1?Q?aEA80fA59brBK5q2b1gGMN+7HMMvYULMPDQQppSXJX2Ow56vGQb4CP9UgK?= =?iso-8859-1?Q?hRv5M98xumAZMKU7t1lVn82n99uhBtaDAc8jYqts3tOt6O43NFi4xZPKtY?= =?iso-8859-1?Q?7L8qLE8aROO0hfdK+zza09XizbFRHdyn7kfj93/6dwYngKg4ubRMjNClot?= =?iso-8859-1?Q?FmSuK4Rlm7ad8I62fB7YwdLWOUjssHvJJ3m4rpcioDyW+Gqs0NGB5dHbmP?= =?iso-8859-1?Q?V4ke4LpaP4OPR+zZpvh3OeM+wnhfBKPbHdgprEmHz0qvLkimJ1HATxZfKJ?= =?iso-8859-1?Q?JHF7NkLJ4awDK6rAc7aggGEqXjTiWBRbAQ3WHOj0az83dw0kvC2KZLnl4Y?= =?iso-8859-1?Q?mJzZXLSZSqdSjcxHnTONAyhKfHZ4yh0lkrp63LS/Og9xIVbJ4/IUedJBDB?= =?iso-8859-1?Q?hPypr85WDEPDpbJGbF/C9Ne0iy7fOD7DF+a5SIlA3Ac9CTQRi8vBA3pIDK?= =?iso-8859-1?Q?jxdvfoeTsavG4KKJkHIu2ycNnqKUt9MuHnnxrtd1qMlhTGvio2FfcIh+ox?= =?iso-8859-1?Q?1Fx7XDl0YgG1wY/Ahp6bR8N1sW25HG2pVZ6OiJiZ0AIcR3SeQHRazM0A10?= =?iso-8859-1?Q?TUS2hsYlc/aXhQDVQwRNw1hIIIB/s+gmujXJhixo3foew98Mh3sKRrl6bM?= =?iso-8859-1?Q?lcXyBd1vAWV+th823YbrUSoWPnltfW38C6ctQT/YSqn0Q2HYzBTd5pzmdX?= =?iso-8859-1?Q?X2jUSZLXhy9GnA/YMLAmayHQrdRVw8jftDCxCr0Atr2k+c1itKBXQg+R7M?= =?iso-8859-1?Q?TUriV8tvQV/fcTmAqsQ2kLtELcn/K4OIDjdOTKGEGVsBb29H4NIvjMPPSw?= =?iso-8859-1?Q?oZA1YCwjwTn03KeAIJGR004jYXqL/yyuSZWmTmlUu5lTbKbuOgLnxN9pQD?= =?iso-8859-1?Q?jCs+lv2Wrm9NYCzGV4Cuqb1cziqEmCATbBBGUHBR+2p9MTCiTkNRuN7WwL?= =?iso-8859-1?Q?Lh+5tXSw/9Lce8dYye0sL/dcXqemLTt1JBJ8UWsOw=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0957AD37A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(376002)(346002)(39850400004)(43544003)(189003)(199004)(476003)(54906003)(81156014)(86362001)(55016002)(6436002)(68736007)(8676002)(6116002)(106356001)(486006)(8936002)(186003)(7736002)(105586002)(3846002)(966005)(478600001)(5660300002)(81166006)(26005)(14454004)(305945005)(4326008)(7696005)(74316002)(256004)(14444005)(97736004)(25786009)(33656002)(52536013)(99286004)(316002)(6916009)(2906002)(71200400001)(71190400001)(6506007)(9686003)(66066001)(102836004)(6246003)(53936002)(229853002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2368; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uUZ9YLPzh5MMFRU0e0M5Kx4YnDc17xMIogqR4hl2ITyy5hy87z/4KcJ5qX65iapAsXjkjfkr7SaQW9vNB4nGGh/MRev+wtDJw3yFo/O+/1s3UDGhJlQwIrY0zUhkZCczZGu6nPfyTC47+NA/WL+dFT77fQP3FiDY/rfXCzBVGSRiB3atuMyznbyDxmnfaUyxgZ7Q0sa2AApOlQHqo1mi5k7dAvDHxvEWeq9SH1ICKq/9i1H5GUTHqdZWrKPBZkovoJRUDxgs+LSvobAI7EWtgvls8qBqCMW7eeDBBM3pfrfVy1ns8wLVznG9pkBAb0DGVv4stKPl1NaOz9SmCbL7RAVzp1T87698i8Q/pZFtmBtomjqHPk49QwKuNpHossBkFjH2xGZagRjJ75PHEwZzv4EHmbWsH/MOZCBnygleeZU= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: c1bd40d5-541d-4469-54a2-08d699dad528 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2019 22:04:07.6783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2368 Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 22:04:18 -0000 Hi Matthias, >I read the (expired) draft draft-sidrops-rpkimaxlen. It appears that a fork in the draft stream occurred inadvertently=20 sometime ago when Job tried to upload a new version.=20 You were looking at the "expired" branch.=20 The draft is active: https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-01 =20 >The problem analysis in the draft is misleading. >The problem is not the usage of the max length field. Even without a >max length field, a "forged-origin subprefix hijack" may occur easily.=20 >For example, a minimal, more specific ROA has been created, and the=20 >prefix is currently not announced by the origin AS configured in the ROA. IMO, the spirit and intention of the document is in complete alignment=20 with what you are trying to covey. It is the *misuse* of maxlength that=20 the draft cautions about. Adding the following wording (with some=20 further refinement) in the document will help clarify: A minimal ROA is one which includes prefixes that are currently=20 announced or are intended to be announced. Use of maxlength=20 can be avoided or it should be used judiciously so that=20 more specific prefixes that are not intended to be announced=20 are not covered by the ROA. The idea is to minimize the attack surface corresponding to forged-origin subprefix hijacking. =20 >The draft implicitly suggests: "Only create ROAs for prefixes that are=20 >currently announced." I'm not sure whether the WG has consensus about=20 >that. This was not the intent in the draft. A better definition of minimal ROA as outlined above will take care of the misunderstanding.=20 The draft did recognize that the IP prefixes planned to be announced=20 in the future or intermittently (when needed) may be included in the ROA. Please see the following paragraph from Section 5.1: =20 "In this case, the ROA SHOULD include (1) the set of IP prefixes that are always originated in BGP, and (2) the set IP prefixes that are sometimes, but not always, originated in BGP. The ROA SHOULD NOT include any IP prefixes that the operator knows will not be originated in BGP." There is a use case described after that involving DDoS mitigation. >The draft is expired. I suggest to leave it expired because it leads=20 >to incorrect conclusions, see for example=20 >https://github.com/DECIX/RPKI/wiki/RPKI-deployment-options=20 I carefully went through the link you've provided. Nice work! I do not see any inconsistency between your approach with ROAs=20 and what is in the draft, especially with the better definition of ROA as stated above (IMO). Please let us know if you still see it differently. In fact, there is a similarity between your Blackhole use case and the DDoS mitigation use case in the draft (except that=20 the latter doesn't involve prefixes more specific than /24 IPv4 or /48 IPv= 6). DDoS mitigation providers' needs are discussed in Section 5.1=20 and network operators seem to have found that discussion and=20 related recommendations quite useful. Please see this thread:=20 https://lists.arin.net/pipermail/arin-tech-discuss/2018-August/000723.html = =20 It should be noted that the document is aimed to be a BCP, not standards tr= ack. Thanks for your inputs. Regards, Sriram =20 From nobody Sat Feb 23 16:46:15 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9399128D0B; Sat, 23 Feb 2019 16:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dXaC2icSEz0L; Sat, 23 Feb 2019 16:46:12 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CF1128701; Sat, 23 Feb 2019 16:46:12 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gxhvl-0042v5-9b>; Sun, 24 Feb 2019 01:46:09 +0100 Received: from x4dbf3522.dyn.telefonica.de ([77.191.53.34] helo=mw-x1.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gxhvk-000mNN-VS>; Sun, 24 Feb 2019 01:46:09 +0100 Date: Sun, 24 Feb 2019 01:46:07 +0100 From: Matthias Waehlisch To: "Sriram, Kotikalapudi (Fed)" cc: "sidrops@ietf.org" , "draft-ietf-sidrops-rpkimaxlen@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 77.191.53.34 Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 00:46:15 -0000 Hi Sriram, On Sat, 23 Feb 2019, Sriram, Kotikalapudi (Fed) wrote: > >I read the (expired) draft draft-sidrops-rpkimaxlen. > > It appears that a fork in the draft stream occurred inadvertently > sometime ago when Job tried to upload a new version. > You were looking at the "expired" branch. > The draft is active: > https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-01 > hmm, strange. Anyhow, the diff between the 00 and the 01 version relates only to the version number and date. My previous email is still valid, except that the draft is unfortunately not expired. > >The problem analysis in the draft is misleading. The problem is not > >the usage of the max length field. Even without a max length field, a > >"forged-origin subprefix hijack" may occur easily. For example, a > >minimal, more specific ROA has been created, and the prefix is > >currently not announced by the origin AS configured in the ROA. > > IMO, the spirit and intention of the document is in complete alignment > with what you are trying to covey. It is the *misuse* of maxlength > that the draft cautions about. Adding the following wording (with some > further refinement) in the document will help clarify: > > A minimal ROA is one which includes prefixes that are currently > announced or are intended to be announced. Use of maxlength can be > avoided or it should be used judiciously so that more specific > prefixes that are not intended to be announced are not covered by the > ROA. The idea is to minimize the attack surface corresponding to > forged-origin subprefix hijacking. > I got this, see below. > >The draft implicitly suggests: "Only create ROAs for prefixes that are > >currently announced." I'm not sure whether the WG has consensus about > >that. > > This was not the intent in the draft. > It was, as you wrote: "A minimal ROA is one which includes prefixes that are currently announced or are intended to be announced." > A better definition of minimal ROA as outlined above will take care of > the misunderstanding. The draft did recognize that the IP prefixes > planned to be announced in the future or intermittently (when needed) > may be included in the ROA. Please see the following paragraph from > Section 5.1: > This is not very helpful. "when needed" is fuzzy. Needed in six month? Do you know when a DDoS occurs? The draft supposes that needed is very short-term. > "In this case, the ROA SHOULD include (1) the set of IP prefixes that > are always originated in BGP, and (2) the set IP prefixes that are > sometimes, but not always, originated in BGP. The ROA SHOULD NOT > include any IP prefixes that the operator knows will not be > originated in BGP." > > There is a use case described after that involving DDoS mitigation. > > >The draft is expired. I suggest to leave it expired because it leads > >to incorrect conclusions, see for example > >https://github.com/DECIX/RPKI/wiki/RPKI-deployment-options > > I carefully went through the link you've provided. Nice work! I do not > see any inconsistency between your approach with ROAs and what is in > the draft, especially with the better definition of ROA as stated > above (IMO). > Just to be clear: I was neither writing nor giving input to the wiki page. What I tried to say is that the authors of the wiki page draw incorrect conclusions, probably based on misleading insights from the draft. > Please let us know if you still see it differently. In fact, there is > a similarity between your Blackhole use case and the DDoS mitigation > use case in the draft (except that the latter doesn't involve prefixes > more specific than /24 IPv4 or /48 IPv6). > > DDoS mitigation providers' needs are discussed in Section 5.1 > and network operators seem to have found that discussion and > related recommendations quite useful. Please see this thread: > > https://lists.arin.net/pipermail/arin-tech-discuss/2018-August/000723.html > "It's also worth noting that pre-publishing many ROAs for not-normally-announced prefixes in the way Andrew was asking about creates the same exposure as would be caused by [mis]using max length." -- I agree on this. > It should be noted that the document is aimed to be a BCP, not standards track. > Yes, but again, the draft articulates a wrong perspective. The problem is not about the max length field. The discussion about the max length field is a _corollary_ of the discussion that you suggest to not create ROAs for prefixes that are not announced or will not be announced in the very near future. ... max length is syntax. So, if you want to continue with this topic, I suggest to write a more general draft. I'm not sure whether it is helpful, though, because there are use cases where we cannot say when the announcement will be active. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Sat Feb 23 19:43:22 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9D512D4E9; Sat, 23 Feb 2019 19:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 IKVflCydy0xD; Sat, 23 Feb 2019 19:43:18 -0800 (PST) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840104.outbound.protection.outlook.com [40.107.84.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0E41293B1; Sat, 23 Feb 2019 19:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cUYuDKQIBiK6oXDq7ijsUO9wE5a3h3eOsEbvQwbKnts=; b=AHjEJfUQZ68yNpjMwha+AxV/ylJrO7Q9Fjq4mKjGnOnlDw//hOEFVVaU7DpHG6Eoff6e9nFJWRDdIyOqYwIMWoxU23LTaWVkdyl8NPf3wfReksUY2uzMqUJ77ZT8GBwnW+1W/7QvzM6TFBW1407y3pm3FIhUSJSudF/bitBBP2s= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2365.namprd09.prod.outlook.com (52.132.115.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Sun, 24 Feb 2019 03:43:16 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1643.016; Sun, 24 Feb 2019 03:43:16 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Matthias Waehlisch CC: "sidrops@ietf.org" , "draft-ietf-sidrops-rpkimaxlen@ietf.org" Thread-Topic: [Sidrops] draft-sidrops-rpkimaxlen Thread-Index: AQHUy8AmUSoU77RRv0K+rD/l/1dVIqXuHSeAgAAdhqo= Date: Sun, 24 Feb 2019 03:43:16 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45ed0002-63ff-4b56-9f41-08d69a0a3601 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2365; x-ms-traffictypediagnostic: SN6PR0901MB2365: x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; SN6PR0901MB2365; 23:WnAoJHL4v/gPiddkwjXAp9AKDvii0LCmUX/IN?= =?iso-8859-1?Q?PxNKWL1abQE0PComkSEvDBSoJ/MCcUHdDdqnVLC2xvYcTWhkM+6Akyf68C?= =?iso-8859-1?Q?Xi9g388fo43ytmPyRsTRzQMPdu+te3DzZ4QWL/RWrDZNNrXVAtrbx6U4kG?= =?iso-8859-1?Q?J7bwuzANe/6jti3vQobCXVbM8kOhkSZLDzJCZT0QXxI7knp4ipwGSAAgQo?= =?iso-8859-1?Q?LTSKZOOUz/we4AerpMaqdLXjeEF8J3On4rQgUjimChBoEijCP38arsny8i?= =?iso-8859-1?Q?hEf0bx13Rb1wv5jxvVWx57gfiavwQLX5u++MJO0EedjqwUlv8rROnhanzR?= =?iso-8859-1?Q?G7Zij11nMNfzVy+MA1xj3DRFLB/gu+cJKw/2HDp9v5luzhytrpwp3i8duL?= =?iso-8859-1?Q?Xelu4hTNvoB4NFqofTEhxaXsDmlsSvjexhZDqcCxR4jcOPVIo3SexSv8qG?= =?iso-8859-1?Q?hIb92t8gvhXyDtR5zvuJhRs2v28nsQXF6Tc2KtyNtoDEc7ktSvPAkCebwU?= =?iso-8859-1?Q?vbHmSD+8SLB4TXrfWtTisd1eAnL7L+MWcrnsC2zahx+SJSk3Yitokh8p6w?= =?iso-8859-1?Q?BPEsq+stX62kVQhmizX+BdVnwdLj7mTtqViJ1G24Yksfnd68pcRDib6mi6?= =?iso-8859-1?Q?3vPkf1wrbAQUFnd/WjjaCb9xWYM1Kn8aV3iY42TvtRgSqO/wZzrdf5Pgxj?= =?iso-8859-1?Q?d6UMk/tX80P4BDDmUeF4cpCPFg0HbZnx8EBKH73hk84zQdt6RGrG6+FhxF?= =?iso-8859-1?Q?NwLAThRWzI/xza1NeIUHSuLWf0GU1YARZXFFKra1ZB9QQQ0aadxEQrQXiK?= =?iso-8859-1?Q?No+qSSNN5Kn5ppgtUYvSTgC90XLQlU7EaUE/lpIdbPxkg+L6eAy9kGnuYI?= =?iso-8859-1?Q?URdDHyPlxPZ09t+KBOqhRTpGmPlA9jf2vGarYB53W1gh1+Q+aTv8B+rKfD?= =?iso-8859-1?Q?2ElvaPdoeMRSkyZGcSWuFvETjJN5bsMXTmah8MXOrFkgP/XvdnAZEmXqby?= =?iso-8859-1?Q?ypsfFhz+5EhqLKGfysOdl1ie4qJCwtMhoMlXUdyrOUTd/HaENptzlQtTLV?= =?iso-8859-1?Q?jWjXrZWdxVEHrs/Oe6gCoYhCfumQdIOZoCv27t09ooVGFwJD+dKlBSx+S0?= =?iso-8859-1?Q?HQM/jXEyUZBDC6182w64ZAcB0OF8UM/5ckIKsagC/HHkZtx/vieF3F+qO8?= =?iso-8859-1?Q?f71YBQuhqcJK1chbafmU05nX3cgEEL8jxMLvU6WymbvBHMw6dXZtVfM0dg?= =?iso-8859-1?Q?NByhDTHlCqZgDfW6YAmraTLj+wQIDh1BAPSF1l18w=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09583628E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(346002)(396003)(376002)(39850400004)(199004)(43544003)(189003)(186003)(66066001)(256004)(33656002)(106356001)(54906003)(105586002)(316002)(9686003)(2906002)(68736007)(8936002)(3846002)(53936002)(76176011)(52536013)(6916009)(478600001)(6116002)(86362001)(99286004)(55016002)(7696005)(26005)(25786009)(14454004)(4326008)(7736002)(6506007)(305945005)(81156014)(81166006)(6246003)(446003)(71200400001)(71190400001)(6436002)(229853002)(74316002)(97736004)(8676002)(486006)(476003)(102836004)(5660300002)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2365; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PSd4/4U0ZWybhI9/HR4hac8vmM+XWtfuIN885zFMUeWIucqtFp5JMmWhIFSVXDM0+pEKhJscLbp7vJLwm2pcaQdlP5gtuGlhHAMEWKl+qGvmW2UNtdpGMMs0QlGeAZ7hjo4Q+SKA3JDCnpx1MQ1lL5xDo1nROJ2D00MMzbCAe61HEi/o8cApcq7SWWF1reENeiZdU26VrC0sJP/aEGXN42HQFQxvyQ9Rg95uWfUaT5iSZROOoZhn/W+H7v6+NDp6iR9YgGzZsOO00nM/xN0Lc4uUkiXM/JmCpZdoH/9u8OL0iDf3RPNy96anpwe9odHvH4MMZYKlt38lSfDYTko6C99qti37UMhXR+bexDrrUlun2tLspNJZrLtYknJwSF5oxCJLf0cDD091Gen/8JEMe1VTc32YYPaJNEtGZCHGJ7o= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 45ed0002-63ff-4b56-9f41-08d69a0a3601 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2019 03:43:16.4789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2365 Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 03:43:21 -0000 Hi Matthias, >> A minimal ROA is one which includes prefixes that are currently >> announced or are intended to be announced. Use of maxlength can be >> avoided or it should be used judiciously so that more specific >> prefixes that are not intended to be announced are not covered by the >> ROA. The idea is to minimize the attack surface corresponding to >> forged-origin subprefix hijacking. >> > I got this, see below. OK. Good. --- snip ---- >> A better definition of minimal ROA as outlined above will take care of >> the misunderstanding. The draft did recognize that the IP prefixes >> planned to be announced in the future or intermittently (when needed) >> may be included in the ROA. Please see the following paragraph from >> Section 5.1: >> > This is not very helpful. "when needed" is fuzzy. Needed in six month? >Do you know when a DDoS occurs? The draft supposes that needed is very >short-term. The draft does not presuppose when the prefixes may need to be announced. The time frame is up to the prefix owner. Once the prefix owner decides what prefixes (currently announced or intended to be announced) should be covered by the ROA (or ROAs), the draft merely offers recommendations for minimizing the attack surface.= =20 The example in Section 5.1 illustrates this for the DDoS case. (One more example can be added there to further drive home the point.) The example is agnostic about if/when the DDoS mitigation prefixes=20 may need to be announced. =20 --- snip ---- > What I tried to say is that the authors of the wiki page draw >incorrect conclusions, probably based on misleading insights from the >draft. I read the DECIX wiki page. It is not clear to me what you mean by=20 incorrect conclusions on that page with regard to ROA/maxlength .=20 I would appreciate if you can clarify or cite some examples. Thanks. =20 Sriram From nobody Sun Feb 24 05:50:31 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5621B130E72; Sun, 24 Feb 2019 05:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 D5lGXbqRcbDl; Sun, 24 Feb 2019 05:50:25 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A811129532; Sun, 24 Feb 2019 05:50:25 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gxuAh-002706-6E>; Sun, 24 Feb 2019 14:50:23 +0100 Received: from x4dbf1952.dyn.telefonica.de ([77.191.25.82] helo=mw-x1.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gxuAg-002zNa-Uf>; Sun, 24 Feb 2019 14:50:23 +0100 Date: Sun, 24 Feb 2019 14:50:21 +0100 From: Matthias Waehlisch To: "Sriram, Kotikalapudi (Fed)" cc: "sidrops@ietf.org" , "draft-ietf-sidrops-rpkimaxlen@ietf.org" In-Reply-To: Message-ID: References: , User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 77.191.25.82 Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 13:50:30 -0000 Hi Sriram, On Sun, 24 Feb 2019, Sriram, Kotikalapudi (Fed) wrote: > >> A better definition of minimal ROA as outlined above will take care of > >> the misunderstanding. The draft did recognize that the IP prefixes > >> planned to be announced in the future or intermittently (when needed) > >> may be included in the ROA. Please see the following paragraph from > >> Section 5.1: > >> > > This is not very helpful. "when needed" is fuzzy. Needed in six month? > >Do you know when a DDoS occurs? The draft supposes that needed is very > >short-term. > > The draft does not presuppose when the prefixes may need to be > announced. The time frame is up to the prefix owner. Once the prefix > owner decides what prefixes (currently announced or intended to be > announced) should be covered by the ROA (or ROAs), the draft merely > offers recommendations for minimizing the attack surface. The example > in Section 5.1 illustrates this for the DDoS case. (One more example > can be added there to further drive home the point.) The example is > agnostic about if/when the DDoS mitigation prefixes may need to be > announced. > sorry but I really don't see how this limits the attack surface, in case where the configured more specific prefix is announced very occasionally. > > What I tried to say is that the authors of the wiki page draw > >incorrect conclusions, probably based on misleading insights from the > >draft. > > I read the DECIX wiki page. It is not clear to me what you mean by > incorrect conclusions on that page with regard to ROA/maxlength . I > would appreciate if you can clarify or cite some examples. > To give one example: Your draft suggests to not use the max length field, which means "ROA generation software MUST use the prefix length as the max length if the user does not specify a max length." [RFC 7115] Option 3 in the wiki page, they will set the max length to the max length of the IP version (e.g., /32 for v4). This is different to your proposal. Based on what you wrote, each member that intends to send a blackholing announcement would need to create a corresponding ROA. Option 3, actually, tries to solve the problem when members forget to do this. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Sun Feb 24 19:10:20 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBDB129619; Sun, 24 Feb 2019 19:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 psOZP3K_eCJl; Sun, 24 Feb 2019 19:10:15 -0800 (PST) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830109.outbound.protection.outlook.com [40.107.83.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23FE129508; Sun, 24 Feb 2019 19:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tOQEB4OaIS7S0vBS6KI5do9168HeVyWzQWopO3f2pU4=; b=fX9xBPdQcAC3/9JIN11/quYT/hO04zjkUCcgNPBGmpWYka0x3/bo1gB1F5SEGTDyLNt2Thncz+aVEs/3vHkgw5Q0HCEhMA+QQhk5LMFCYZ3lvAexryWwy+x5rmu4PZAI26jJwBkku6A2sbt+96PTfN0wnOGwUh3JP0nuvIolTMw= Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Mon, 25 Feb 2019 03:10:13 +0000 Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1643.019; Mon, 25 Feb 2019 03:10:13 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Matthias Waehlisch CC: "sidrops@ietf.org" , "draft-ietf-sidrops-rpkimaxlen@ietf.org" Thread-Topic: [Sidrops] draft-sidrops-rpkimaxlen Thread-Index: AQHUy8AmUSoU77RRv0K+rD/l/1dVIqXuHSeAgAAdhqqAAL2XgIAA2cTA Date: Mon, 25 Feb 2019 03:10:12 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.222.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec219b2d-f4c6-4d44-630b-08d69acec229 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2366; x-ms-traffictypediagnostic: SN6PR0901MB2366: x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; SN6PR0901MB2366; 23:7KPRUYI0QjHF4VQmkOT5Ktxv9tgQxwl9Mi7?= =?Windows-1252?Q?b6OOL6cML+uaTgCRFaKAQR9AFU7H1jX5Pj+cOIeaPyl27ZiH9VPNW6H4?= =?Windows-1252?Q?M+fVScFLmlrCxjOdi3KXZsQ9/eyJJoend7oVh7UroQshgVNzuWOIU+vw?= =?Windows-1252?Q?eQ24rU/Wbyt57ZOMWgIfyg+hPBLplfopU+BDaEhT37E1zwDGV5Pz8vOS?= =?Windows-1252?Q?1WYa4zOEtQA0a5c9aS0rXeWH2bG5q2izIvuZA8OQZAoSmAq1yFJZE1ki?= =?Windows-1252?Q?4//rbW4Oep9gdeMEraYNBoiRMjrDempzxuPoW9gy3xu2az9t9DNurNAb?= =?Windows-1252?Q?u5HhuAjvv+udP6FWO1cA1WkKVLU+vvkNkE0dqAwqPG4fwsnVKZrHuh47?= =?Windows-1252?Q?d/vsoN3ubT8UivigBw8iuaEdkPlRqKluVKKdc5hDGsDXQrP6otb5+bmT?= =?Windows-1252?Q?RbgKnOgT74zf/LDM95KbdP1sgKfmSn1rp2IsejCEvpQUcQ+nO7PMd46I?= =?Windows-1252?Q?PPph0Zn1QiWjKL8NKHGb445hq7GumXKMHhAsShH7fCxZUeE0D4DiXGvr?= =?Windows-1252?Q?apH7c9uPM7mQEIqavegOi0p1D5RICDZjED+WH0HQRqolto9fuhMFB+dR?= =?Windows-1252?Q?/jrO+xX/cgVgFaG7JdwdRegXZoCojY8PAVpYvgV8/ncT3uqsturu+UU5?= =?Windows-1252?Q?t7iZ3cIoABAXMe8jYG/Gt4FU2YXEwXmwgTuSDIf7aI1NnHlwVvYxLHdj?= =?Windows-1252?Q?lMwRniXBOIHFH43s4Mk9+dS+epe0/CMhQTMlezussAovY1io3x0dbr2C?= =?Windows-1252?Q?lPCU+aMKRbze7ARkb27EEY/3eVWc3G8IaYwFIDg39oZ4oKwfq4yxa9va?= =?Windows-1252?Q?n+Wbr+xRgFJA9iJr7kD6FFAgW5gzxLto9AG3lLlW+iiIcdZrX4mF9XDP?= =?Windows-1252?Q?uaTs1XATepc3/OonuQW5jGL9g+Ep50m/NZv8lw2sHP1UiiCT40HBp9xI?= =?Windows-1252?Q?lAa83a8wy5tw7iwadcm4gky5Be2khxjGlf4tlqdgSqXGJ+XxKQwHfFq7?= =?Windows-1252?Q?ZFdDC+Se89KRMNRZCIfic9X/J9Hdw4KP1vo08naJj/zDnJzf5iwdMaP6?= =?Windows-1252?Q?JukyWUjSvvaaxLKVhqEpMufPOuJXOKTtnvp/uzNQHe3t9e5lvnTeVF8w?= =?Windows-1252?Q?gv/sLQR7Z0Ghw5IuMmd8k7WsCF1wDwspDXQLT2ws6LUl1NpdR7BDiAtx?= =?Windows-1252?Q?SaUW9Y0l4heOAgrGnhvdd+h2f+PNpCyyfZC8Tc9GRiNjRScM8SFS/04J?= =?Windows-1252?Q?NV/rg0I8yIz/YVc3cAONgA7lRueKL//252HMZT4TPY0HNUgkXMCaXzgN?= =?Windows-1252?Q?BSChTZ8B+lOxE?= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(366004)(396003)(39850400004)(189003)(199004)(33656002)(7736002)(68736007)(102836004)(8676002)(2906002)(81156014)(81166006)(256004)(561944003)(6506007)(76176011)(229853002)(86362001)(11346002)(316002)(446003)(486006)(66066001)(476003)(54906003)(305945005)(52536013)(5660300002)(6436002)(74316002)(93886005)(6246003)(55016002)(14444005)(9686003)(71200400001)(71190400001)(7696005)(99286004)(6116002)(3846002)(26005)(186003)(14454004)(478600001)(106356001)(4326008)(53936002)(8936002)(105586002)(25786009)(6916009)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2366; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YJfzbm2lctvnc86o5yndt80WM30l9FHQgK7248OSGhcu7eB7Wb+iCR4j9MHB0hp3zqcGQ2CqeJKto6J2cdz/8mvLezMgGZSX9jXtxPl0GjnKAnxhmriHdFicSUmvOH62uEw35+O6823UwhfS/PGviN7fKZoH5fg6RiQMU8c0aGV38cKYTgv6gMgH3B4BhuGRU0AwywEnOmO9bF57cF9VJv3Kh0sfhHBg9/tIiBBYbuhjYB6fkCmJq2dgLEvftvcI+K146tzwn1qtRAkiaXiXNe9kd4DRH5pNQtgXLrdjsLyeX2JKrYUXMkDOuCWoIpV6UsS8K9jEv4+eV+W9JbNfGXyYshEeFB+JDaPhjIzVKz0v2d/nYmDWzlKOB0H5osQ7atD/w1M6H2YLG1LVg5gw0368Ew870UVnIWJY9hlbQM8= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: ec219b2d-f4c6-4d44-630b-08d69acec229 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 03:10:12.9205 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2366 Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 03:10:19 -0000 Hi Matthias, -- snip -- >> The draft does not presuppose when the prefixes may need to be=20 >> announced. The time frame is up to the prefix owner. Once the prefix=20 >> owner decides what prefixes (currently announced or intended to be=20 >> announced) should be covered by the ROA (or ROAs), the draft merely=20 >> offers recommendations for minimizing the attack surface. The example=20 >> in Section 5.1 illustrates this for the DDoS case. (One more example=20 >> can be added there to further drive home the point.) The example is=20 >> agnostic about if/when the DDoS mitigation prefixes may need to be=20 >> announced. >>=20 > sorry but I really don't see how this limits the attack surface, in=20 >case where the configured more specific prefix is announced very=20 >occasionally. We know that with fully deployed BGPsec (if ever), there is no concern abou= t=20 forged-origin attacks and no concern for ROAs created for DDoS mitigation. But in the absence of BGPsec, there are two options as follow: 1. Pre-create ROAs for the DDoS mitigation service and=20 minimize the attack surface per draft.=20 For example, customer announces 168.122.0.0/16 and associated /17s, also announces 168.122.32.0/24 (for TE), and =20 and contracted DDoS mitigation service for 168.122.5.0/24. Their servers are located in 168.122.5.0/24.=20 The draft recommends the customer should create ROAs as follows: ROA: {168.122.0.0/16, maxlength =3D 17}, 168.122.32.0/24, AS 64496 ROA: 168.122.5.0/24, AS 64500 =20 Note: AS 64500 is the DDoS mitigation SP For this example, the draft warns against creating these kinds of ROAs=20 which would have unnecessarily large attack surface: ROA: 168.122.0.0/16, maxlength =3D 24, AS 64496 ROA: 168.122.0.0/16, maxlength =3D 24, AS 64500=20 =20 2. Create ROAs for DDoS mitigation on demand. Then, the risk is that there= =20 may be long RPKI/ROA propagation delays and the DDoS mitigation=20 response time suffers. (May be the RIRs and ISPs can be persuaded to=20 invest to cut this delay down.) There are trade-offs associated with the two methods. If you have other suggestions, we would like to hear.=20 -- snip -- =20 >> I read the DECIX wiki page. It is not clear to me what you mean by=20 >> incorrect conclusions on that page with regard to ROA/maxlength . I=20 >> would appreciate if you can clarify or cite some examples. >>=20 > To give one example: Your draft suggests to not use the max length=20 >field, which means "ROA generation software MUST use the prefix length=20 >as the max length if the user does not specify a max length." [RFC 7115] No, the draft that does not intend to suggest =93never use maxlength=94. I have clarified this before, and you replied, =93I got this=94. Also, see the example above which includes judicious use of maxlength.=20 =20 > Option 3 in the wiki page, they will set the max length to the max=20 >length of the IP version (e.g., /32 for v4). This is different to your=20 >proposal. Yep, this is not relevant to the draft. The DECIX effort is about how=20 the IXP can validate Blackhole messages from customers. > > Based on what you wrote, each member that intends to send a=20 >blackholing announcement would need to create a corresponding ROA.=20 >Option 3, actually, tries to solve the problem when members forget to do=20 >this. This again has really nothing to do with the draft=92s recommendations.=20 The draft doesn=92t even mention ROAs with > /24 IPv4 and > /48 IPv6. In general, I would say, IXP/ISP should not require ROAs for the=20 more specific Blackhole prefixes. They can be loosely validated without requiring ROAs (for those more specific prefixes)=20 as DECIX seems to be doing (option 3).=20 We can chat about all this some more in Prague. I will speak with my co-authors about making the draft a bit more general per your suggestion. Thanks. Regards, Sriram From nobody Mon Feb 25 02:15:29 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D212D4E6; Mon, 25 Feb 2019 02:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zkmzUuUcZHHK; Mon, 25 Feb 2019 02:15:25 -0800 (PST) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB56128D52; Mon, 25 Feb 2019 02:15:25 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gyDIB-002Q0c-CK>; Mon, 25 Feb 2019 11:15:23 +0100 Received: from ze304.pia.fu-berlin.de ([87.77.227.4] helo=mw-x1.zedat.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gyDIB-00298S-47>; Mon, 25 Feb 2019 11:15:23 +0100 Date: Mon, 25 Feb 2019 11:15:22 +0100 From: Matthias Waehlisch To: "Sriram, Kotikalapudi (Fed)" cc: "sidrops@ietf.org" , "draft-ietf-sidrops-rpkimaxlen@ietf.org" In-Reply-To: Message-ID: References: , , User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="336053415-24579-1551084771=:4012" Content-ID: X-Originating-IP: 87.77.227.4 Archived-At: Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 10:15:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --336053415-24579-1551084771=:4012 Content-Type: TEXT/PLAIN; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: Hi Sriram, On Mon, 25 Feb 2019, Sriram, Kotikalapudi (Fed) wrote: > -- snip -- > >> The draft does not presuppose when the prefixes may need to be > >> announced. The time frame is up to the prefix owner. Once the prefix > >> owner decides what prefixes (currently announced or intended to be > >> announced) should be covered by the ROA (or ROAs), the draft merely > >> offers recommendations for minimizing the attack surface. The example > >> in Section 5.1 illustrates this for the DDoS case. (One more example > >> can be added there to further drive home the point.) The example is > >> agnostic about if/when the DDoS mitigation prefixes may need to be > >> announced. > >> > > sorry but I really don't see how this limits the attack surface, in > >case where the configured more specific prefix is announced very > >occasionally. > > We know that with fully deployed BGPsec (if ever), there is no concern about > forged-origin attacks and no concern for ROAs created for DDoS mitigation. > ;). > But in the absence of BGPsec, there are two options as follow: > > 1. Pre-create ROAs for the DDoS mitigation service and > minimize the attack surface per draft. > > For example, customer announces 168.122.0.0/16 and associated /17s, > also announces 168.122.32.0/24 (for TE), and > and contracted DDoS mitigation service for 168.122.5.0/24. > Their servers are located in 168.122.5.0/24. > The draft recommends the customer should create ROAs as follows: > ROA: {168.122.0.0/16, maxlength = 17}, 168.122.32.0/24, AS 64496 > ROA: 168.122.5.0/24, AS 64500 > Note: AS 64500 is the DDoS mitigation SP > I'm not sure whether this "minimizes" the attack surface. Minimizing probably means that you create the ROAs on demand. > For this example, the draft warns against creating these kinds of ROAs > which would have unnecessarily large attack surface: ROA: > 168.122.0.0/16, maxlength = 24, AS 64496 ROA: 168.122.0.0/16, > maxlength = 24, AS 64500 > Btw, this warning is already noted in RFC 7115. > 2. Create ROAs for DDoS mitigation on demand. Then, the risk is that there > may be long RPKI/ROA propagation delays and the DDoS mitigation > response time suffers. (May be the RIRs and ISPs can be persuaded to > invest to cut this delay down.) > > There are trade-offs associated with the two methods. > If you have other suggestions, we would like to hear. > No other suggestions. My original point was that the draft is misleading because the draft highlights the max length field. > -- snip -- > >> I read the DECIX wiki page. It is not clear to me what you mean by > >> incorrect conclusions on that page with regard to ROA/maxlength . I > >> would appreciate if you can clarify or cite some examples. > >> > > To give one example: Your draft suggests to not use the max length > >field, which means "ROA generation software MUST use the prefix length > >as the max length if the user does not specify a max length." [RFC 7115] > > No, the draft that does not intend to suggest “never use maxlength”. > I have clarified this before, and you replied, “I got this”. > I was not writing "never" ;). Sorry that the text gave the impression. > We can chat about all this some more in Prague. > Will be there. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl --336053415-24579-1551084771=:4012-- From nobody Mon Feb 25 21:32:48 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA74112D4F0; Mon, 25 Feb 2019 21:32:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow To: X-Test-IDTracker: no X-IETF-IDTracker: 6.92.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, iesg-secretary@ietf.org, Chris Morrow Message-ID: <155115916669.10703.13546580238687807530.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2019 21:32:46 -0800 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 05:32:47 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 as Internet Standard on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ From nobody Mon Feb 25 21:45:18 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEBD12D4F0; Mon, 25 Feb 2019 21:45:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 japg9gbTMPTW; Mon, 25 Feb 2019 21:45:14 -0800 (PST) Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D516E12D4E7; Mon, 25 Feb 2019 21:45:13 -0800 (PST) Received: by mail-it1-x12e.google.com with SMTP id l66so2341608itg.3; Mon, 25 Feb 2019 21:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rfF7x7IXxvBdlP8tFMZzNmbgu4LtiEiGZuZDiNSjEtQ=; b=YeJeHKC/Ovd0h/kp0qhru4+5Qylg7EITrvgO2SlEGJuk4Kp5vLsic9VcgvG9uLt48Z XODC6HINOvwbSUgo1iUDDCuVuq2aK4ssrPMUs++iz2K5HF6eT3bv9vds2MUzyGg2SJ7u G8JLS7O9Fi9G0RiIyQTbdZHGgCysRy8TUN0HHt96+nbiZ59YlQLt33zYtRSZWT+TRk+K Gr1zGqWIc/Eb/nvt/jWE4x3fahU7Q58z/iCPKVXMVypNUxBimlv/4Y0ymorJZ+BhvdYh dDAHZPSvQ33vLtL1izEZli2/KhFlU1vdrXNz44HxSNxs76RVcOKh90YwBmsJLdk/sV8K 237Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rfF7x7IXxvBdlP8tFMZzNmbgu4LtiEiGZuZDiNSjEtQ=; b=RiqykqdoHoVsEVsegWKnGSNHJrnp+Fn+TWQ/SdY2BoiX6z6YUwv5uhzP0ZnRuxfP7b Gwhq0xZbCLwtO/Bx+Q67nIu6Z1PcV9Zml9grNrZE8oQA30IkU9EG4HCZoQIfBz8G2qSD 39GnSeFn0IlOQOu292ddxSNUuvbPWPSqRH3kDkQnxqzs1W/HPtFKUTv9BXQDf9TRplUL jzSV0IBjtyVFbPDYwG0uowvQTkfEPMMCHAxSBamWNXBg0FtdtC6tKb0/gqUAweuTKJRt oNFSy5G6u5HPWJ0tvWF+IrEH4fdx/6HMqTF2Q5UvP7ELMoa/UseIsTZuRzt4fbZr3H5R 4V7g== X-Gm-Message-State: AHQUAuYB74RfL7+bvOj1W7N1IRIb5oDRCFA9K38jVDHq86JhH/ZRUJhX yL4q3IW/QSpvnVS064Qd1IQ3HqO5+DCpJQOnGRZyJvkP X-Google-Smtp-Source: AHgI3IYNaYaP79n5UNyoXryYZmuRXD5qKZN1GFS/52+8G/fXqwznHdMOx5lGGFBRhRn507JUACd1amEbvcU4gv5Qd/I= X-Received: by 2002:a24:6cc8:: with SMTP id w191mr1430620itb.139.1551159912766; Mon, 25 Feb 2019 21:45:12 -0800 (PST) MIME-Version: 1.0 From: Christopher Morrow Date: Tue, 26 Feb 2019 00:45:01 -0500 Message-ID: To: sidrops@ietf.org, SIDROps Chairs , sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="0000000000009722de0582c58fce" Archived-At: Subject: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 05:45:16 -0000 --0000000000009722de0582c58fce Content-Type: text/plain; charset="UTF-8" Howdy WG folks! At the Bangkok meeting Oliver asked that we push forward: https://tools.ietf.org/html/draft-borchert-sidrops-rpki-state-unverified-01 for WG Adoption, the abstract is: "In case operators decide not to evaluate BGP route prefixes according to RPKI route origin validation (ROV), none of the available states as specified in RFC 6811 do properly represent this decision. This document introduces "Unverified" as well-defined validation state which allows to properly identify route prefixes as not evaluated according to RPKI route origin validation." and some brief 2wk period of discussion and such should now ensue! Thanks! -chris co-chair. --0000000000009722de0582c58fce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy W= G folks!
At the Bangkok meeting Oliver asked that we push forward:
= =C2=A0https://tools.ietf.org/html/draft-borchert-sidrops-rpki-= state-unverified-01

for WG Adoption, the abstr= act is:

=C2=A0 "In case operators decide not to evaluate BGP ro= ute prefixes according
=C2=A0 =C2=A0to RPKI route origin validati= on (ROV), none of the available states
=C2=A0 =C2=A0as specified = in RFC 6811 do properly represent this decision. This
=C2=A0 =C2= =A0document introduces "Unverified" as well-defined validation st= ate
=C2=A0 =C2=A0which allows to properly identify route prefixes= as not evaluated
=C2=A0 =C2=A0according to RPKI route origin val= idation."

and some brief 2wk period of discus= sion and such should now ensue!

Thanks!
= -chris
co-chair.
--0000000000009722de0582c58fce-- From nobody Mon Feb 25 21:46:49 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47328130E76; Mon, 25 Feb 2019 21:46:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 f5pSbpqrPHl7; Mon, 25 Feb 2019 21:46:45 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BDE12D4E7; Mon, 25 Feb 2019 21:46:45 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id v83so2363806itf.1; Mon, 25 Feb 2019 21:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RoqXcRIrsMh7ai8YfIgqkjMUD13xeJphHqhNia3PHBk=; b=Nwfp2/dUfUvFSoWBx52+y9fR9PSwngLv2XG329SrXJbdXLQd/ujzYS+cmLUYre24pQ lYKcAocmUX+gY4d+cvktg6YATwIQHDKL46WYOjzFL84oG/1WLY6P25cu2VKHAbB7jaCB OUe3SJoiF7MlwSXBx+7ieaO7GKzHbEGZfS2Zc51Kg3Bp/iHq/ECZKW9CUB9U9zcWI3El c8/znSHw6AwqkFv7TlRIDYv1xlccPqNvvLPtysY51xCWeMJQNjtE82ROREv0J8KfN5q/ rBnYz4PFbUptom1OYXtwxYBvv1R37/py3ZOFcuPm9hIMM1rxHnMwLFXZ3MwLf5HzuV5Z mDjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RoqXcRIrsMh7ai8YfIgqkjMUD13xeJphHqhNia3PHBk=; b=HKmNyp5rVcM0TRwJGZ4VwzTjfO4MKm1cMCMFgjiUIKtUPHvxt4bjpM4s9Rvi3b1Ia6 CEWqMpXoSbI2DQz7OMsQnza2bqxNXDmRsYdNSIvZvrgCBQvkObeSSyCYdLGhb4llisMx WX2NxwJKRm1Fm4uBp7gzkGev4HHlBZWL0TYiqqaYzU+UgmFsT/EJlffI44N34UIm6Rsm gzB/ze4DGaz4jmYYgXQTG2B0Y94HuiqXrO4lQ8mDSujJohfg3B7zdUhgI747/Epqj/cJ lJwWe7dBL9+35rUW+V6eWj7vtoTyYfYvGysSOYVAIAcmB4kEW5AbF28bNqRjRuQUnhvG pXiA== X-Gm-Message-State: AHQUAuaAARo4QirwT3DLtMz/y6+MLNc+r+d3g117oYQAmYVxQRC3fzsk 5Vuzu/Jj6Tq9ZUNsvjGjSM0naHsEAKX8ljVpl5mmDJXd X-Google-Smtp-Source: APXvYqyo+WKxTUEIorB2O+Mz/zKJVyDgkoL6QRBM/7RQyexmLnvK6BKfFpTnVScydQ/ICDmZa8lZmbE4H2o8XGND+js= X-Received: by 2002:a24:7f81:: with SMTP id r123mr1461852itc.89.1551160004175; Mon, 25 Feb 2019 21:46:44 -0800 (PST) MIME-Version: 1.0 From: Christopher Morrow Date: Tue, 26 Feb 2019 00:46:33 -0500 Message-ID: To: sidrops@ietf.org, SIDROps Chairs , sidrops-ads@ietf.org Content-Type: multipart/alternative; boundary="00000000000009edef0582c595fc" Archived-At: Subject: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-bgpsec-state-unverified-00 - ENDS: 03/12/2019 (Mar 12) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 05:46:48 -0000 --00000000000009edef0582c595fc Content-Type: text/plain; charset="UTF-8" Howdy WG Folks! At the Bangkok meeting Oliver asked that we adopt the following draft: https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-state-unverified-00 The abstract of which is: "In case operators decide to delay BGPsec path validation, none of the available states do properly represent this decision. This document introduces "Unverified" as a well-defined validation state which allows to properly identify a non-evaluated BGPsec routes as not verified." A brief 2wk period of chat, read, discuss, comment should now ensue! -chris co-chair --00000000000009edef0582c595fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy WG Folks!
At t= he Bangkok meeting Oliver asked that we adopt the following draft:
=C2= =A0=C2=A0https://tools.ietf.org/html/draft-borchert-sidrops-= bgpsec-state-unverified-00

The abstract of whi= ch is:
=C2=A0 "In case operators decide to delay BGPsec path valida= tion, none of the
=C2=A0 =C2=A0available states do properly repre= sent this decision. This document
=C2=A0 =C2=A0introduces "U= nverified" as a well-defined validation state which
=C2=A0 = =C2=A0allows to properly identify a non-evaluated BGPsec routes as not
=C2=A0 =C2=A0verified."

A brief 2wk= period of chat, read, discuss, comment should now ensue!

-chris
co-chair
--00000000000009edef0582c595fc-- From nobody Mon Feb 25 21:59:10 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B84126F72; Mon, 25 Feb 2019 21:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 4a4MGhz8uJfZ; Mon, 25 Feb 2019 21:59:07 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B494A12D4E7; Mon, 25 Feb 2019 21:59:06 -0800 (PST) Received: from 69.144.dhcp.conference.apricot.net (69.144.dhcp.conference.apricot.net [220.247.144.69]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 3E842D549; Tue, 26 Feb 2019 06:59:00 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1551160742; bh=AJhCZkeihV+JN7IWaKgUPALbwMkreM+GXtfmUPw3WvM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SUWRx8WJ0tRMNJbSOSQ2DxQIDFWdNobze9MvHf4uMN5BF/HIDfXrSVLaAXWi2LTuj ZWcWbAUI+21hsIpSfRoQwElbtjdeG6m+n2T1hNRterJP7nP/W3Elwmx+zJsznm5iOS 25RoikPUq+zbRkA+xyJr3oN7CcDrOGPthJd4XuFc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: <0502BBB4-06E0-49B5-8A16-82FADABB7F35@nlnetlabs.nl> Date: Tue, 26 Feb 2019 14:58:56 +0900 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <0B80B695-2739-490E-8F2C-D715C2A70118@nlnetlabs.nl> References: <154823467586.7485.17416366729552218933@ietfa.amsl.com> <4350CE4E-5E77-4101-932E-E164652F4425@nlnetlabs.nl> <0502BBB4-06E0-49B5-8A16-82FADABB7F35@nlnetlabs.nl> To: sidrops-chairs@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 05:59:09 -0000 Dear co-chairs, Repeat. Can we please have an official last-call? Or some other verdict = you deem fit. Tim > On 6 Feb 2019, at 18:20, Tim Bruijnzeels wrote: >=20 > Dear co-chairs, >=20 > I have waited a while but saw no further comments. >=20 > Can you please initiate a last-call for this version? >=20 > Kind regards >=20 > Tim Bruijnzeels >=20 >=20 >=20 >> On 23 Jan 2019, at 10:16, Tim Bruijnzeels wrote: >>=20 >> Dear WG, >>=20 >> This version address the comments made after the unclosed last call = for -05. >>=20 >> * There is now no blank line between the comments and the URIs. >> * Relying Parties MUST now do TLS verification (from SHOULD) and text = that was there arguing that unsafe transport is not a huge issue when = there is object security has been removed. >> * Job Snijders is acknowledged for suggesting the comments section. >>=20 >> Please have a look and speak up if you see any remaining issues. This = should have been a simple change, but we're talking about this for = almost a year now. If I get no comments by the end of next week, then I = will try asking for last call once again, but I hope to avoid having to = make a version -07. >>=20 >> Thanks >> Tim >>=20 >>=20 >>> On 23 Jan 2019, at 10:11, 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 SIDR Operations WG of the IETF. >>>=20 >>> Title : Resource Public Key Infrastructure (RPKI) = Trust Anchor Locator >>> Authors : Geoff Huston >>> Samuel Weiler >>> George Michaelson >>> Stephen Kent >>> Tim Bruijnzeels >>> Filename : draft-ietf-sidrops-https-tal-06.txt >>> Pages : 10 >>> Date : 2019-01-23 >>>=20 >>> Abstract: >>> This document defines a Trust Anchor Locator (TAL) for the Resource >>> Public Key Infrastructure (RPKI). TALs allow Relying Parties in the >>> RPKI to download the current Trust Anchor (TA) CA certificate from >>> one or more locations, and verify that the key of this self-signed >>> certificate matches the key on the TAL. Thus, Relying Parties can = be >>> configured with TA keys, but allow these TAs to change the content = of >>> their CA certificate. In particular it allows TAs to change the set >>> of Internet Number Resources included in the RFC3779 extension of >>> their certificate. >>>=20 >>> This document obsoletes the previous definition of Trust Anchor >>> Locators in RFC 7730 by adding support for HTTPS URIs. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-06 >>> = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-06 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-https-tal-06 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >=20 From nobody Mon Feb 25 22:26:48 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FBD130E77 for ; Mon, 25 Feb 2019 22:26:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dJp6WSl_rG8n for ; Mon, 25 Feb 2019 22:26:44 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A751295EC for ; Mon, 25 Feb 2019 22:26:44 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id v83so2477086itf.1 for ; Mon, 25 Feb 2019 22:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IplKy9AEj6sHkLYtfKdPshESTYUJPWVDLo3od+fZl6k=; b=fRwoKPmgElx7vcN8CXCYiSzvMSdppEOM0u7U/M6lp77oOC8LdnMwobLn9RJPvo6aA6 0Rt8lFDdU/TCxyWhqHezjC9s40slgpr6Qoiq0v9owjzzXLYRGeHLRfDB8DSkGs0GkBmX qJHpe8oHA/CTGHlx3WOlsXn7ynOBp8bPpoGYrPP1649Hnh9D2I8nykv3nP2YpDeLt0BV HFx1YMbOlE9I4JyNidOoiCaD+TYz6fF2+SKp+yit9jfCJL6vAzg8PsKvEg545Klf2kYQ X4lfELC5LNHyTTHklc0xy+RL4r+DSaHwWh9nxY22NhEN8SJUfHCZP7yytiMx6A2sBfBv HVkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IplKy9AEj6sHkLYtfKdPshESTYUJPWVDLo3od+fZl6k=; b=ZtLfyQoLt/N5pv25FpkSEVnNaT8DC/diJfV5ktiwMtYyoH8Gf6K8YB1DeOffShF0bh qz+TNFrVQqz5XazYKLG/guFL/EqiYqpCJNLN2I6y9rk8GSL2vo19cxdp0uARWRKZ+vpG eYJuc/SONegwFN+NbxUs2lruiePs8fARqmVB/06iyijsgwyjHDesW4RYtmnpwmOgD2/u xIX6++plEqQeSWh2t7gram7XgCdZkUd5Iue80dX3e5d0hP91Sib6USE1hzX1F0INgimx +2EgZLvjOmor+fhHkCYM6vgRWCa+JmGQCYqu4MdzURNHpGNDC/LqVeQQytsmmueKvS7E WTXw== X-Gm-Message-State: AHQUAuYaiKP86Uqni10hA+iauMXUiHyIJlgT+IQ7LLa31m0P4xo/5fOx olvSR/porNvmDePYWEscUaQozcl9RdRdh3XjMOle/g== X-Google-Smtp-Source: AHgI3IbGHdi06jVCrwrqDVjJ3ryO5ailFXLnCfcimyNUYWUG3OpUogUe7Ts+xgN5II9jE4DaTMKL0Z37eQDF5BJk+/U= X-Received: by 2002:a02:745:: with SMTP id f66mr12426999jaf.137.1551162402990; Mon, 25 Feb 2019 22:26:42 -0800 (PST) MIME-Version: 1.0 References: <0403D83D-7886-4E49-873A-78181A8BCFA4@nlnetlabs.nl> <0FD77962-7633-4B34-BBFE-42A668498E2B@nlnetlabs.nl> <20181220160248.204fa146@glaurung.nlnetlabs.nl> <3D9C4CAD-5D82-4E6C-A28F-C2444E6DCC7A@foobar.org> In-Reply-To: <3D9C4CAD-5D82-4E6C-A28F-C2444E6DCC7A@foobar.org> From: Christopher Morrow Date: Tue, 26 Feb 2019 01:26:31 -0500 Message-ID: To: Nick Hilliard Cc: Tim Bruijnzeels , SIDR Operations WG Content-Type: multipart/alternative; boundary="00000000000004f4320582c62413" Archived-At: Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-https-tal - ENDS Nov 26 2018 (11/26/2018) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 06:26:47 -0000 --00000000000004f4320582c62413 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy! Time went by, it's not november but it seems like people support and don't not-support this. I've questions for the authors and then we can push this up the hill to the IESG folks. thanks! -chris On Fri, Jan 4, 2019 at 10:17 AM Nick Hilliard wrote: > No objection. > > Nick > > Sent from my iWotsit. > > > On 4 Jan 2019, at 15:08, Tim Bruijnzeels wrote: > > > > Hi all, > > > > Any objections to me making the following changes? > > * remove the blank line after the comments > > * no longer allow data to be used when TLS verification fails (MUST > NOT..) > > > > I would really appreciate some voices pro / con, and then spin a > hopefully final version asap that I can ask last call on, again. > > > > Tim > > > > > >> On 20 Dec 2018, at 16:02, Martin Hoffmann > wrote: > >> > >> Tim Bruijnzeels wrote: > >>>> On 17 Dec 2018, at 17:14, Job Snijders wrote: > >>>> > >>>> Section 2.1 "ASCII" should probably be UTF-8, this is 2018 and we > >>>> are the IETF > >>> > >>> So, the machines will most likely ignore this anyway. I guess that > >>> UTF-8 should be okay, provided we restrict the allowed line breaks to > >>> or for these lines as well. So maybe rephrase: > >>> > >>> Current: > >>> > >>> 1. an optional comment section consisting of one or more lines > >>> starting with the '#' character, containing human readable > >>> informational ASCII text, followed by an empty line using a > >>> "" or "" line break only. > >>> > >>> New: > >>> > >>> 1. an optional comment section consisting of one or more lines > >>> starting with the '#' character, containing human readable > >>> informational UTF-8 text, and ending with a "" or > >>> "" line break. Followed by an empty line using a > >>> "" or "" line break only. > >> > >> I don=E2=80=99t quite see why the empty line after the comment is nece= ssary at > >> all. Since all the comment lines start with a hash, the end of the > >> comment section can be identified by the first line not starting with = a > >> hash. > >> > >> Kind regards, > >> Martin > >> > >> _______________________________________________ > >> Sidrops mailing list > >> Sidrops@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidrops > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --00000000000004f4320582c62413 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy! Time went by, it's not november but it seems li= ke people support and don't not-support this.
I've questions fo= r the authors and then we can push this up the hill to the IESG folks.

thanks!
-chris

On Fri, Jan 4, 2019 at 1= 0:17 AM Nick Hilliard <nick@foobar.or= g> wrote:
No objection.

Nick

Sent from my iWotsit.

> On 4 Jan 2019, at 15:08, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
>
> Hi all,
>
> Any objections to me making the following changes?
> * remove the blank line after the comments
> * no longer allow data to be used when TLS verification fails (MUST NO= T..)
>
> I would really appreciate some voices pro / con, and then spin a hopef= ully final version asap that I can ask last call on, again.
>
> Tim
>
>
>> On 20 Dec 2018, at 16:02, Martin Hoffmann <martin@opennetlabs.com> wrot= e:
>>
>> Tim Bruijnzeels wrote:
>>>> On 17 Dec 2018, at 17:14, Job Snijders <job@ntt.net> wrote:
>>>>
>>>> Section 2.1 "ASCII" should probably be UTF-8, th= is is 2018 and we
>>>> are the IETF=C2=A0
>>>
>>> So, the machines will most likely ignore this anyway. I guess = that
>>> UTF-8 should be okay, provided we restrict the allowed line br= eaks to
>>> <CRLF> or <LF> for these lines as well. So maybe r= ephrase:
>>>
>>> Current:
>>>
>>>=C2=A0 1.=C2=A0 an optional comment section consisting of one o= r more lines
>>>=C2=A0 =C2=A0 =C2=A0 starting with the '#' character, c= ontaining human readable
>>>=C2=A0 =C2=A0 =C2=A0 informational ASCII text, followed by an e= mpty line using a
>>>=C2=A0 =C2=A0 =C2=A0 "<CRLF>" or "<LF&g= t;" line break only.
>>>
>>> New:
>>>
>>>=C2=A0 1.=C2=A0 an optional comment section consisting of one o= r more lines
>>>=C2=A0 =C2=A0 =C2=A0 starting with the '#' character, c= ontaining human readable
>>>=C2=A0 =C2=A0 =C2=A0 informational UTF-8 text, and ending with = a "<CRLF>" or
>>>=C2=A0 =C2=A0 =C2=A0 "<LF>" line break. Followe= d by an empty line using a
>>>=C2=A0 =C2=A0 =C2=A0 "<CRLF>" or "<LF&g= t;" line break only.
>>
>> I don=E2=80=99t quite see why the empty line after the comment is = necessary at
>> all. Since all the comment lines start with a hash, the end of the=
>> comment section can be identified by the first line not starting w= ith a
>> hash.
>>
>> Kind regards,
>> Martin
>>
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf= .org
>> https://www.ietf.org/mailman/listinfo/sidrops<= /a>
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org=
> https://www.ietf.org/mailman/listinfo/sidrops<= br> >

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--00000000000004f4320582c62413-- From nobody Mon Feb 25 22:33:24 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA99A130E79; Mon, 25 Feb 2019 22:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 hx3lRQd5KBGJ; Mon, 25 Feb 2019 22:33:20 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644CC129619; Mon, 25 Feb 2019 22:33:20 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 5E51A3FDDE; Tue, 26 Feb 2019 06:33:19 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [IPv6:2606:700:e:30:fa59:71ff:febc:c58c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 2F0A82FD4175F; Tue, 26 Feb 2019 06:33:19 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Tue, 26 Feb 2019 01:33:18 -0500 Message-ID: From: Chris Morrow To: Tim Bruijnzeels Cc: sidrops-chairs@ietf.org, SIDR Operations WG In-Reply-To: <0B80B695-2739-490E-8F2C-D715C2A70118@nlnetlabs.nl> References: <154823467586.7485.17416366729552218933@ietfa.amsl.com> <4350CE4E-5E77-4101-932E-E164652F4425@nlnetlabs.nl> <0502BBB4-06E0-49B5-8A16-82FADABB7F35@nlnetlabs.nl> <0B80B695-2739-490E-8F2C-D715C2A70118@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 06:33:22 -0000 Questions sent to authors for IPR things. thanks for the reminder. On Tue, 26 Feb 2019 00:58:56 -0500, Tim Bruijnzeels wrote: > > Dear co-chairs, > > Repeat. Can we please have an official last-call? Or some other verdict you deem fit. > > Tim > > > On 6 Feb 2019, at 18:20, Tim Bruijnzeels wrote: > > > > Dear co-chairs, > > > > I have waited a while but saw no further comments. > > > > Can you please initiate a last-call for this version? > > > > Kind regards > > > > Tim Bruijnzeels > > > > > > > >> On 23 Jan 2019, at 10:16, Tim Bruijnzeels wrote: > >> > >> Dear WG, > >> > >> This version address the comments made after the unclosed last call for -05. > >> > >> * There is now no blank line between the comments and the URIs. > >> * Relying Parties MUST now do TLS verification (from SHOULD) and text that was there arguing that unsafe transport is not a huge issue when there is object security has been removed. > >> * Job Snijders is acknowledged for suggesting the comments section. > >> > >> Please have a look and speak up if you see any remaining issues. This should have been a simple change, but we're talking about this for almost a year now. If I get no comments by the end of next week, then I will try asking for last call once again, but I hope to avoid having to make a version -07. > >> > >> Thanks > >> Tim > >> > >> > >>> On 23 Jan 2019, at 10:11, internet-drafts@ietf.org wrote: > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. > >>> This draft is a work item of the SIDR Operations WG of the IETF. > >>> > >>> Title : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator > >>> Authors : Geoff Huston > >>> Samuel Weiler > >>> George Michaelson > >>> Stephen Kent > >>> Tim Bruijnzeels > >>> Filename : draft-ietf-sidrops-https-tal-06.txt > >>> Pages : 10 > >>> Date : 2019-01-23 > >>> > >>> Abstract: > >>> This document defines a Trust Anchor Locator (TAL) for the Resource > >>> Public Key Infrastructure (RPKI). TALs allow Relying Parties in the > >>> RPKI to download the current Trust Anchor (TA) CA certificate from > >>> one or more locations, and verify that the key of this self-signed > >>> certificate matches the key on the TAL. Thus, Relying Parties can be > >>> configured with TA keys, but allow these TAs to change the content of > >>> their CA certificate. In particular it allows TAs to change the set > >>> of Internet Number Resources included in the RFC3779 extension of > >>> their certificate. > >>> > >>> This document obsoletes the previous definition of Trust Anchor > >>> Locators in RFC 7730 by adding support for HTTPS URIs. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-06 > >>> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-06 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-https-tal-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/ > >>> > >>> _______________________________________________ > >>> Sidrops mailing list > >>> Sidrops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sidrops > >> > > From nobody Mon Feb 25 22:46:14 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C50130E7D; Mon, 25 Feb 2019 22:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 B2EvsuycCHWa; Mon, 25 Feb 2019 22:46:10 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F6B130E7E; Mon, 25 Feb 2019 22:46:09 -0800 (PST) Received: from 69.144.dhcp.conference.apricot.net (69.144.dhcp.conference.apricot.net [220.247.144.69]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D2162D752; Tue, 26 Feb 2019 07:46:04 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1551163566; bh=L+IU0Df2Dsig7fW9ntQiYr4sBuxGLSV82hA20683N9g=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=qDFRbpdVJXimx9J2Jmh6zFHk9yYWth53ZQy7GZEpNO57hdbQHJgYUGqkhHojn2p8r Aqm5P+UrDFDc37Yg3jFAfsncJrVmGb0byDS3tBRqnDMtnH7SEYm1Mf74Cf/MD6/H4R lz+A079mU4Mj5tBMQEEqolSDDLyYbHY0n/INcvJQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 26 Feb 2019 15:46:01 +0900 Cc: sidrops-chairs@ietf.org, SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <6E9126B5-FE2E-428F-9E90-DD89A0BD205A@nlnetlabs.nl> References: <154823467586.7485.17416366729552218933@ietfa.amsl.com> <4350CE4E-5E77-4101-932E-E164652F4425@nlnetlabs.nl> <0502BBB4-06E0-49B5-8A16-82FADABB7F35@nlnetlabs.nl> <0B80B695-2739-490E-8F2C-D715C2A70118@nlnetlabs.nl> To: Chris Morrow X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 06:46:13 -0000 Hi Chris, Thank you for moving this forward. However, the version -06 differs from the -05 version for which the last = call was done in November. Based on feedback on the list after last-call = the following changed: >>>> * There is now no blank line between the comments and the URIs. >>>> * Relying Parties MUST now do TLS verification (from SHOULD) and = text that was there arguing that unsafe transport is not a huge issue = when there is object security has been removed. >>>> * Job Snijders is acknowledged for suggesting the comments section. I am happy to see this progress, but I leave it to your judgement = whether last-call should be re-assessed for version -06 with these = changes. Tim > On 26 Feb 2019, at 15:33, Chris Morrow wrote: >=20 >=20 > Questions sent to authors for IPR things. > thanks for the reminder. >=20 > On Tue, 26 Feb 2019 00:58:56 -0500, > Tim Bruijnzeels wrote: >>=20 >> Dear co-chairs, >>=20 >> Repeat. Can we please have an official last-call? Or some other = verdict you deem fit. >>=20 >> Tim >>=20 >>> On 6 Feb 2019, at 18:20, Tim Bruijnzeels wrote: >>>=20 >>> Dear co-chairs, >>>=20 >>> I have waited a while but saw no further comments. >>>=20 >>> Can you please initiate a last-call for this version? >>>=20 >>> Kind regards >>>=20 >>> Tim Bruijnzeels >>>=20 >>>=20 >>>=20 >>>> On 23 Jan 2019, at 10:16, Tim Bruijnzeels wrote: >>>>=20 >>>> Dear WG, >>>>=20 >>>> This version address the comments made after the unclosed last call = for -05. >>>>=20 >>>> * There is now no blank line between the comments and the URIs. >>>> * Relying Parties MUST now do TLS verification (from SHOULD) and = text that was there arguing that unsafe transport is not a huge issue = when there is object security has been removed. >>>> * Job Snijders is acknowledged for suggesting the comments section. >>>>=20 >>>> Please have a look and speak up if you see any remaining issues. = This should have been a simple change, but we're talking about this for = almost a year now. If I get no comments by the end of next week, then I = will try asking for last call once again, but I hope to avoid having to = make a version -07. >>>>=20 >>>> Thanks >>>> Tim >>>>=20 >>>>=20 >>>>> On 23 Jan 2019, at 10:11, 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 SIDR Operations WG of the IETF. >>>>>=20 >>>>> Title : Resource Public Key Infrastructure (RPKI) = Trust Anchor Locator >>>>> Authors : Geoff Huston >>>>> Samuel Weiler >>>>> George Michaelson >>>>> Stephen Kent >>>>> Tim Bruijnzeels >>>>> Filename : draft-ietf-sidrops-https-tal-06.txt >>>>> Pages : 10 >>>>> Date : 2019-01-23 >>>>>=20 >>>>> Abstract: >>>>> This document defines a Trust Anchor Locator (TAL) for the = Resource >>>>> Public Key Infrastructure (RPKI). TALs allow Relying Parties in = the >>>>> RPKI to download the current Trust Anchor (TA) CA certificate from >>>>> one or more locations, and verify that the key of this self-signed >>>>> certificate matches the key on the TAL. Thus, Relying Parties can = be >>>>> configured with TA keys, but allow these TAs to change the content = of >>>>> their CA certificate. In particular it allows TAs to change the = set >>>>> of Internet Number Resources included in the RFC3779 extension of >>>>> their certificate. >>>>>=20 >>>>> This document obsoletes the previous definition of Trust Anchor >>>>> Locators in RFC 7730 by adding support for HTTPS URIs. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-06 >>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-06 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-https-tal-06 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> Sidrops mailing list >>>>> Sidrops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidrops >>>>=20 >>>=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Feb 26 11:26:52 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5BD1277CC; Tue, 26 Feb 2019 11:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001] autolearn=no autolearn_force=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 LDsILKTcf2Ud; Tue, 26 Feb 2019 11:26:47 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC77D1228B7; Tue, 26 Feb 2019 11:26:47 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id DA0F33FE40; Tue, 26 Feb 2019 19:26:45 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id BD91E30055D39; Tue, 26 Feb 2019 19:26:45 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Tue, 26 Feb 2019 19:26:45 +0000 Message-ID: <87h8cqtkp6.wl%morrowc@ops-netman.net> From: Chris Morrow To: Tim Bruijnzeels Cc: Chris Morrow , sidrops-chairs@ietf.org, SIDR Operations WG In-Reply-To: <6E9126B5-FE2E-428F-9E90-DD89A0BD205A@nlnetlabs.nl> References: <154823467586.7485.17416366729552218933@ietfa.amsl.com> <4350CE4E-5E77-4101-932E-E164652F4425@nlnetlabs.nl> <0502BBB4-06E0-49B5-8A16-82FADABB7F35@nlnetlabs.nl> <0B80B695-2739-490E-8F2C-D715C2A70118@nlnetlabs.nl> <6E9126B5-FE2E-428F-9E90-DD89A0BD205A@nlnetlabs.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-https-tal-06.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 19:26:50 -0000 At Tue, 26 Feb 2019 15:46:01 +0900, Tim Bruijnzeels wrote: > > Hi Chris, > > Thank you for moving this forward. > > However, the version -06 differs from the -05 version for which the last call was done in November. Based on feedback on the list after last-call the following changed: > >>>> * There is now no blank line between the comments and the URIs. > >>>> * Relying Parties MUST now do TLS verification (from SHOULD) and text that was there arguing that unsafe transport is not a huge issue when there is object security has been removed. > >>>> * Job Snijders is acknowledged for suggesting the comments section. > > I am happy to see this progress, but I leave it to your judgement whether last-call should be re-assessed for version -06 with these changes. > I didn't think the changes were significant enough to constitute a need for a second wglc round. > > Tim > > > > On 26 Feb 2019, at 15:33, Chris Morrow wrote: > > > > > > Questions sent to authors for IPR things. > > thanks for the reminder. > > > > On Tue, 26 Feb 2019 00:58:56 -0500, > > Tim Bruijnzeels wrote: > >> > >> Dear co-chairs, > >> > >> Repeat. Can we please have an official last-call? Or some other verdict you deem fit. > >> > >> Tim > >> > >>> On 6 Feb 2019, at 18:20, Tim Bruijnzeels wrote: > >>> > >>> Dear co-chairs, > >>> > >>> I have waited a while but saw no further comments. > >>> > >>> Can you please initiate a last-call for this version? > >>> > >>> Kind regards > >>> > >>> Tim Bruijnzeels > >>> > >>> > >>> > >>>> On 23 Jan 2019, at 10:16, Tim Bruijnzeels wrote: > >>>> > >>>> Dear WG, > >>>> > >>>> This version address the comments made after the unclosed last call for -05. > >>>> > >>>> * There is now no blank line between the comments and the URIs. > >>>> * Relying Parties MUST now do TLS verification (from SHOULD) and text that was there arguing that unsafe transport is not a huge issue when there is object security has been removed. > >>>> * Job Snijders is acknowledged for suggesting the comments section. > >>>> > >>>> Please have a look and speak up if you see any remaining issues. This should have been a simple change, but we're talking about this for almost a year now. If I get no comments by the end of next week, then I will try asking for last call once again, but I hope to avoid having to make a version -07. > >>>> > >>>> Thanks > >>>> Tim > >>>> > >>>> > >>>>> On 23 Jan 2019, at 10:11, internet-drafts@ietf.org wrote: > >>>>> > >>>>> > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. > >>>>> This draft is a work item of the SIDR Operations WG of the IETF. > >>>>> > >>>>> Title : Resource Public Key Infrastructure (RPKI) Trust Anchor Locator > >>>>> Authors : Geoff Huston > >>>>> Samuel Weiler > >>>>> George Michaelson > >>>>> Stephen Kent > >>>>> Tim Bruijnzeels > >>>>> Filename : draft-ietf-sidrops-https-tal-06.txt > >>>>> Pages : 10 > >>>>> Date : 2019-01-23 > >>>>> > >>>>> Abstract: > >>>>> This document defines a Trust Anchor Locator (TAL) for the Resource > >>>>> Public Key Infrastructure (RPKI). TALs allow Relying Parties in the > >>>>> RPKI to download the current Trust Anchor (TA) CA certificate from > >>>>> one or more locations, and verify that the key of this self-signed > >>>>> certificate matches the key on the TAL. Thus, Relying Parties can be > >>>>> configured with TA keys, but allow these TAs to change the content of > >>>>> their CA certificate. In particular it allows TAs to change the set > >>>>> of Internet Number Resources included in the RFC3779 extension of > >>>>> their certificate. > >>>>> > >>>>> This document obsoletes the previous definition of Trust Anchor > >>>>> Locators in RFC 7730 by adding support for HTTPS URIs. > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ > >>>>> > >>>>> There are also htmlized versions available at: > >>>>> https://tools.ietf.org/html/draft-ietf-sidrops-https-tal-06 > >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-https-tal-06 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-https-tal-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/ > >>>>> > >>>>> _______________________________________________ > >>>>> Sidrops mailing list > >>>>> Sidrops@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sidrops > >>>> > >>> > > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Feb 26 21:49:08 2019 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E78EB130E6A; Tue, 26 Feb 2019 21:49:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Chris Morrow To: X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, iesg-secretary@ietf.org, Chris Morrow Message-ID: <155124654594.840.14768314883770121851.idtracker@ietfa.amsl.com> Date: Tue, 26 Feb 2019 21:49:05 -0800 Archived-At: Subject: [Sidrops] Publication has been requested for draft-ietf-sidrops-https-tal-06 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 05:49:06 -0000 Chris Morrow has requested publication of draft-ietf-sidrops-https-tal-06 as Internet Standard on behalf of the SIDROPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-https-tal/ From nobody Wed Feb 27 08:18:02 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE12130E82 for ; Wed, 27 Feb 2019 08:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3WegHP1zDreB for ; Wed, 27 Feb 2019 08:17:58 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F37B1200B3 for ; Wed, 27 Feb 2019 08:17:58 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gz1u8-0004xX-0C; Wed, 27 Feb 2019 16:17:56 +0000 Date: Wed, 27 Feb 2019 08:17:55 -0800 Message-ID: From: Randy Bush To: Christopher Morrow Cc: sidrops@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 16:18:00 -0000 i do not understand this draft from an operational/security perspective. it seems to want to document why the announcement was not marked valid or invalid. from an opsec perspective, i really do not care. as there are a number of reasons the match might not have been made: peer not configured for validation, prefix in execption list, AS in excption list, ... will we next enumerate them all? e.g. for debugging, i might like to know which of my policies caused the prefix not to be evaluated. i am NOT suggesting we go down this rabbit hole. bottom line: i care if it is valid. i care if it is invalid. i do not care why it could not be marked one or t'other. randy From nobody Wed Feb 27 08:28:35 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C682E130FFB for ; Wed, 27 Feb 2019 08:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZTlvD3w_zjjK for ; Wed, 27 Feb 2019 08:28:32 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989AD130FF0 for ; Wed, 27 Feb 2019 08:28:32 -0800 (PST) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x1RGSSt1035408 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Feb 2019 16:28:29 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Randy Bush Cc: Christopher Morrow , sidrops@ietf.org References: From: Nick Hilliard Message-ID: Date: Wed, 27 Feb 2019 16:28:27 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.10 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 16:28:35 -0000 Randy Bush wrote on 27/02/2019 16:17: > bottom line: i care if it is valid. i care if it is invalid. i do not > care why it could not be marked one or t'other. Maybe the authors could describe use cases? I can't see any situation where this flag might be useful, but hey, other people have different requirements on their networks. nit: it would be better to use the term "unchecked" or "unevaluated" instead of "unverified". Verification implies assignment of a value of truthfulness, which is not what this draft is about. Nick From nobody Wed Feb 27 09:04:03 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB6130EED; Wed, 27 Feb 2019 09:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 c9azhKBrf9ig; Wed, 27 Feb 2019 09:03:59 -0800 (PST) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840107.outbound.protection.outlook.com [40.107.84.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738EC13101B; Wed, 27 Feb 2019 09:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yTynLYzH8Qk/Vcwy0JTlcWhpCdBi8Dr6D8gWYWGZeY8=; b=TQ/9STUsDDfZqC2PIXYSYic/JNF1QiMYPUqzd1BV/0hr8f4pYiFYoWPDGqpWyVpInVlTOGHzuwB0JgvLCAewPTx+HFX4qgqC791L69qEQOSJcojYnzTt3GzVwja3h7LCbnIBGQZ4wg1Q/SUgPVuLeapRqhFc4IqwVnRgZTNgWFw= Received: from BN8PR09MB3346.namprd09.prod.outlook.com (20.179.72.209) by BN8PR09MB3348.namprd09.prod.outlook.com (20.179.72.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Wed, 27 Feb 2019 17:03:57 +0000 Received: from BN8PR09MB3346.namprd09.prod.outlook.com ([fe80::743f:1ce7:c9a9:6ff7]) by BN8PR09MB3346.namprd09.prod.outlook.com ([fe80::743f:1ce7:c9a9:6ff7%2]) with mapi id 15.20.1643.019; Wed, 27 Feb 2019 17:03:57 +0000 From: "Borchert, Oliver (Fed)" To: "sidrops@ietf.org" , sidrops-chairs Thread-Topic: Preliminary Agenda and SIDR-OPS? Thread-Index: AQHUzr5tEduBPRx280e4v14uuyGVdw== Date: Wed, 27 Feb 2019 17:03:57 +0000 Message-ID: <34DB82B0-CB13-400F-88CA-10F18F2C3EA8@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-originating-ip: [2610:20:6222:140:45e3:f9e0:7d24:873b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0483902d-7d11-419d-c694-08d69cd58fb6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN8PR09MB3348; x-ms-traffictypediagnostic: BN8PR09MB3348: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjhQUjA5TUIzMzQ4OzIzOjhkamNNZ0xhWFp1b3Nwb2gxSWhiRmY5aG5h?= =?utf-8?B?MnVhK3JKK2lrT0g4NXpGQ2RudysxSjlUWUZ2WmxhWjVldWRzN2ViNmRjY3U2?= =?utf-8?B?YWtHOGZuNmpNelB5enN1OVR1L1NVSGZWYkxpaytlYUJaK1Rzck5yanFRT0k3?= =?utf-8?B?ZVVwbmtUOUF2dGFSNDFXWXFPZ1VEcHBRQWlpa201ejNVN0lISU9TMGExd3gy?= =?utf-8?B?YmJVZGNTTWJTYzZ1VUs1V29vUGpleFdvbjVVS3Yvb0RiV1ZVYlNENWxRQlJt?= =?utf-8?B?VkU5RXFHanJtRStBeTM5eTNqUmlwaUNYRUowZ2dGSUt6MnRQcmlYT05TeTVH?= =?utf-8?B?VHVOUWRvaWJzVU5qZ2F6TmpnUGFEVHhYUWlSS2lrYjhHUjhGMXNndFBJS2dG?= =?utf-8?B?WDUxSDRhQmtBMkpuc2tzMlFleE1HRnI1OTBrOGpXcU9YY09hOVZ2U2NiNTlV?= =?utf-8?B?d2F0UjlXUEFxR0ZOeE43Z3h0VGRscTFVN04xOXkzOVMrN3R2dXZmV1MwdmV1?= =?utf-8?B?Y1JPd0VISmxqYStrcSttSGthb3M0RWpBVHVsWm1HSnhZN01PZG5udzFlMEdH?= =?utf-8?B?bURRSDdiQ09YZ1hFSVZRVTJDOEZiUlBVK3RwOVNxUXJPK1d2U0s2cW9BRGJD?= =?utf-8?B?UDRwRTB5WWdRYkJhMEV2K3FqYy9iRnBRT256T3RwOUpEcHJiajlnN3M3SUxt?= =?utf-8?B?a25rYTRqaGxXYTdwdTBPVkorWGhuVzFpZEhVRkV3dHNhbzIvZmVHeklOWVJH?= =?utf-8?B?ZWNHNE9rT0VpSXZVM0U0dTk1Y0NCNWV0SEUzSm1XQzA4b1FKSTR3ck91WTA3?= =?utf-8?B?cWZsdGx5RXRFVUpiM090YjB3WHFCUGVDbGQra1QzUncyTXloTWw5Nkh0QjNo?= =?utf-8?B?UmJnVWhDNG9HSXZmcUpUNFZUVVliMkEzbHpVREVuMmVTV3RFbFFwYVh3cm93?= =?utf-8?B?VG5xcVg4V2FLVnBkL1RxUXE4SWQ1Nm14NnJ4T1BudlhkTG5EUnpsTjNUMGlE?= =?utf-8?B?NUxXNTBhTlpmMyttMi9VTU9VQk9kWHhUK3R4cys0OFVPT2J6VjhnUjQ5aC9m?= =?utf-8?B?NjUwUXlmWnhpQWcrekYrNWx2Z1YvUVpHS3dLTksrNmx1TXpvc0ZURVB4T1JE?= =?utf-8?B?Y1FpMjR4aXY5Y2JRMktucDBoNUljVTFkUldXNHFxZEJjK0hZNVhRZ3V6SVlB?= =?utf-8?B?UE94alg0OGN6amxrRFhNakcwVnVUY2dQOHV1dDJ1aTM3OWZqM1Y4aGZSYUdw?= =?utf-8?B?RkdKZkJvU2Q2WkY4Qytvci9FcDJtQ3BWek5QcWxlWnpGTkdySDlkTWhhLzRZ?= =?utf-8?B?bXl5MVpXRFlRVmNTS28xOTNGL3BqT2luT2syTm9zZXlMcmZISmlQaEk3NHdH?= =?utf-8?B?WEdtODlGNlFGYUdFeHpQR3hoLzdRUWg5b1FHTFI5aDF3b29WQ0RpdTVRYitT?= =?utf-8?B?SU5ndEJKZHRHcHprQVVCeGp1aEE3SHFqVmFQaDliYkpPWXFBQjNpS1d5WlVT?= =?utf-8?Q?ca8ebymOgZl+IWif/SPHRRO5KMI/FZd4o8uTlNIXVSXeFG?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(346002)(366004)(396003)(376002)(189003)(199004)(53936002)(110136005)(7736002)(256004)(6486002)(68736007)(450100002)(105586002)(2906002)(6436002)(14454004)(71190400001)(71200400001)(25786009)(97736004)(33656002)(58126008)(316002)(478600001)(8936002)(83716004)(6116002)(5660300002)(86362001)(476003)(486006)(305945005)(8676002)(46003)(6512007)(99286004)(81166006)(2616005)(81156014)(558084003)(102836004)(82746002)(106356001)(6506007)(36756003)(2501003)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR09MB3348; H:BN8PR09MB3346.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +CnJ+dG3dZmpK5X0ONJTLTDIKaHhTNcFZOivF4SN0bCdgOSz5nRaa+8GlmX9g3NPlSKqYBdMjAaXh52tQp1nrsyteBSAQ3eptMxYbF+bvliiIndy/PftxzCaw5XU1j3xktP9bh7VhRI3vlB10CXY0oUCCdoqY1g3qNuMhSSO/5NQoxCn8QzamX4ghm/+kcbVykhmp9GF0ft99VXgFfe7+3CXPAUVHYqOj5yCPTogC6H/jx61JkufpxgeU3Ip09nxMIvkg7YDvG2ol/h4ia71Ydn4bFoy7ICi1c2z1RfxV9Cjo79f4ivt2tVL7Lcd57SIyKBxnv+9nBURocNhbQsRFTh58OpetmJLXEjsKmKKpgeFrMGZLpfIdx4vKLDInKaHgQR63hNLW85xYAE9Ugjeaw+qMKPPLXndtfF5RvBpEwU= Content-Type: text/plain; charset="utf-8" Content-ID: <367286FC334A7D4588328FAF512091F4@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 0483902d-7d11-419d-c694-08d69cd58fb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 17:03:57.1390 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR09MB3348 Archived-At: Subject: [Sidrops] Preliminary Agenda and SIDR-OPS? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 17:04:02 -0000 V2hpbGUgcGxhbm5pbmcgZm9yIElFVEYxMDQsIEkgYW0gbG9va2luZyBvdmVyIHRoZSBwcmVsaW1p bmFyeSBhZ2VuZGEgYW5kIEkgYW0gd29uZGVyaW5nLCANCmlzIFNJRFItT1BTIG5vdCBtZWV0aW5n IHRoaXMgdGltZSBpbiBQcmFndWU/DQoNCk9saXZlcg0KDQo= From nobody Wed Feb 27 09:18:05 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0271B130EE1; Wed, 27 Feb 2019 09:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 MYtihI9dj3WA; Wed, 27 Feb 2019 09:18:01 -0800 (PST) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830132.outbound.protection.outlook.com [40.107.83.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAA8131029; Wed, 27 Feb 2019 09:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yTynLYzH8Qk/Vcwy0JTlcWhpCdBi8Dr6D8gWYWGZeY8=; b=PZDiBlNzBvisgKx702Msqs+6xFpWDW3ym4nzVVUUukinH4gZZViH6E/VJ8OeHJ7e/gVkZmagwjxXh32rg69KiqwZ2ha43J8K9AqI5WrL6wl9QKyIVICavZ16UEYPNchcGtMC7PMvPj45ZsDd1yLvsdqC3C2/1Orzhk+DzJNyxxY= Received: from BN8PR09MB3346.namprd09.prod.outlook.com (20.179.72.209) by BN8PR09MB3347.namprd09.prod.outlook.com (20.179.72.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Wed, 27 Feb 2019 17:17:58 +0000 Received: from BN8PR09MB3346.namprd09.prod.outlook.com ([fe80::743f:1ce7:c9a9:6ff7]) by BN8PR09MB3346.namprd09.prod.outlook.com ([fe80::743f:1ce7:c9a9:6ff7%2]) with mapi id 15.20.1643.019; Wed, 27 Feb 2019 17:17:58 +0000 From: "Borchert, Oliver (Fed)" To: "sidrops@ietf.org" , sidrops-chairs Thread-Topic: Preliminary Agenda and SIDR-OPS? Thread-Index: AQHUzsBiI6i8XIOaV02z38RSkDVK2g== Date: Wed, 27 Feb 2019 17:17:58 +0000 Message-ID: <34DB82B0-CB13-400F-88CA-10F18F2C3EA8@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov; x-originating-ip: [2610:20:6222:140:45e3:f9e0:7d24:873b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1a0c810-483e-470d-5bc7-08d69cd78506 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN8PR09MB3347; x-ms-traffictypediagnostic: BN8PR09MB3347: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjhQUjA5TUIzMzQ3OzIzOmdPUkhEdmxpZUJNMzZmN25WMndqRGdwVUVj?= =?utf-8?B?TjdyRjZDMkllenJjQ1Jab3NjQVk1a1NTajMyUEkrOTJCS2xINGxKTlMrdE9a?= =?utf-8?B?WEhETEVodndIb0tVUWV1ZlplNStDamlpejB4SHRCenVGRmg3R2Vra2RMSWlU?= =?utf-8?B?U0R4a3M0MUYwemZmL2IzbzNZZmVZTjdIcDJrdkxCOUR1c2UwUmZNOG56S2pi?= =?utf-8?B?aTM3dmduU3NZMSt6dExiMUZ2MnVEOVoyTG1TcjJVY0lFRGhpNWx0V0xOajhn?= =?utf-8?B?MTFFUVZubUpJTTYzZ2h5OUVjNUpka1huQzBRN1hxY3ZqUDl1cnpWLzZCUjV2?= =?utf-8?B?ejhWZ3J1QzNYOC82VDZpQmlEQkJZaW95c2s1Z3hJb21kU1dpODdORi95QjVK?= =?utf-8?B?R1JISXMrdnQ0Ly90eUZOdmVTc0owMTRFd0dVdDRibDFDbEVpeW5CMDE3MDV1?= =?utf-8?B?b3FZc1NaQW5udVlMMmxhVDNyTk5mTDlMY3VNWGVjelo3NVdweGNHOVBZWHho?= =?utf-8?B?NnU4NklYbFkrWXJjSWVHTmppcWJsVmp3THBoOUZRdG4zQnR3Um1sYWF1MXlP?= =?utf-8?B?dXArSWloam82QWF2KzdnZmE4Vkt0NjZLRm9vV3JhSHRlUk8venF1R0JCQ01X?= =?utf-8?B?VTBGZUE2SmcvbVhGakFSMWxvc1Q5MlhuemVMSWtoeVNUdy9MMVVrekZJUHFI?= =?utf-8?B?Mml3WGQ5M01tRzh6dVhEUE9QRDFmWWU1MERpekpSSkM4dmxpWGx1SVUwMGQx?= =?utf-8?B?NTc2S0RVMFJLL0VrWDVOUWUrUmN2eHhpNEQwUjJTdk1XYlVjTmo0S1hVazBm?= =?utf-8?B?UmxoejRQQkY3YUNkRTlmVzI5OUVuT2ROSmtKYy9kV1RZTTJnWEVxSCtQQ1BS?= =?utf-8?B?Zlpja1VpOHdrQitpVXpjNUVyNE1vWTdkNmJXdWRHdFNYMjFWcGNEL3pYWUdp?= =?utf-8?B?OUw5THIvTUkvNGVoQ0JocmNKZXExK2w2aEdNQ3EwamU0TjJqbnQvOHRkeTNV?= =?utf-8?B?WGNVSzRJVUV4WDVhZzFmbWk3UVNTOUxEcjhmZGl2VC9WV2YwRlI0ZUhDSnF1?= =?utf-8?B?cTd3UTVwNWxFK1RPakFlRVhFUGdFcDhWdHp2U01ia3dVZTNlMFhuQWVFTGJq?= =?utf-8?B?UkpERW0yRWJ3WUhCUDFGWmc0Tk1HVndYVURtQ3Y0N2xFWGo5K0NucDU3MC9n?= =?utf-8?B?VUk1aVFGVFhoczZPbXF5SDRkYlRJRWpxaGY2QkxQTjRUalFBS210UE50Y0JE?= =?utf-8?B?WGZLRmtoYVRtSFJjOHJxbkxlN3E4TW9EN3REdDZFaEhtL0JVSW1MeHpoU2gz?= =?utf-8?B?Y1c2WDNJeWlsK0VZUEFKNlVMdndRSUt6d3Yxa1BEWXpJcWVjNTlnRGhPaHZL?= =?utf-8?B?WE1FVEpTcW05UFY3OVM2cUEzZ0FlVzJpUWRaUHhhUC9nVEJxMFpCam5YMFQz?= =?utf-8?B?Zk15YXprRzM1RlNzVGttY1lhZTVlRkJ3SWNSLzhPTTdvbW1DeHpIbjJMQUpW?= =?utf-8?Q?DTdO71cO5UcQM8vUxgqvuFaTHL6SpL+AagHglkI8ftXa4f?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(376002)(366004)(396003)(39860400002)(199004)(189003)(450100002)(8676002)(86362001)(36756003)(81156014)(33656002)(68736007)(82746002)(305945005)(6116002)(25786009)(97736004)(81166006)(7736002)(8936002)(105586002)(99286004)(46003)(6512007)(316002)(558084003)(106356001)(6486002)(6506007)(256004)(6436002)(110136005)(102836004)(14454004)(478600001)(58126008)(2616005)(2906002)(53936002)(83716004)(71200400001)(71190400001)(186003)(2501003)(476003)(5660300002)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR09MB3347; H:BN8PR09MB3346.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0DFzHfftsUg97/jg+5hZxiwah2pV8GPKcpaW18Hno529hQuhzJOXEdV/TxzwmAQOxfDj6lW7UwFU9Frm7JbXviL6YeDY5HkrjBCgpploPBh+kpR3Y3MTpmrfAGyROFtAIE4BVFc+qHCdWIJnVORk+5E1OpoW3Q+firEE0mfZDylo0lZ2coMEtxLSQX2obOooIRUlOABwoMmnVJ4Ts2QWtj8rs3/Hesly1Z4MADXK3xhOX4nzclM2ylbOIYPcN7gt0yZBYuV0blUB8lITD+Yhb9ZqJVsbrkQekXRwuES/MqBmyG1+MC8q2HdbLJgWS88ZMJW6zxUjZ3wZhHSRMsWw71kp2pSSvTSsZvn4sOi4ldtEm/2k38ebW5LHBZzR7JBCZrL5sIUhwpK3Vh/cUTsZnmwHKYCXBWS+dNJ5f0FfHas= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: e1a0c810-483e-470d-5bc7-08d69cd78506 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 17:17:58.2241 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR09MB3347 Archived-At: Subject: [Sidrops] Preliminary Agenda and SIDR-OPS? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 17:18:03 -0000 V2hpbGUgcGxhbm5pbmcgZm9yIElFVEYxMDQsIEkgYW0gbG9va2luZyBvdmVyIHRoZSBwcmVsaW1p bmFyeSBhZ2VuZGEgYW5kIEkgYW0gd29uZGVyaW5nLCANCmlzIFNJRFItT1BTIG5vdCBtZWV0aW5n IHRoaXMgdGltZSBpbiBQcmFndWU/DQoNCk9saXZlcg0KDQo= From nobody Wed Feb 27 10:30:02 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478FC1310B4; Wed, 27 Feb 2019 10:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 y48wFrEYE7Dc; Wed, 27 Feb 2019 10:30:00 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B401310BC; Wed, 27 Feb 2019 10:30:00 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id B8CD83FDE3; Wed, 27 Feb 2019 18:29:58 +0000 (UTC) Received: from morrowc-glaptop2.ops-netman.net (unknown [IPv6:2620:15c:3:10:a69f:4935:d470:2a6a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 73753304D597D; Wed, 27 Feb 2019 18:29:58 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Wed, 27 Feb 2019 13:29:56 -0500 Message-ID: From: Chris Morrow To: "Borchert, Oliver (Fed)" Cc: "sidrops@ietf.org" , sidrops-chairs In-Reply-To: <34DB82B0-CB13-400F-88CA-10F18F2C3EA8@nist.gov> References: <34DB82B0-CB13-400F-88CA-10F18F2C3EA8@nist.gov> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.1 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] Preliminary Agenda and SIDR-OPS? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 18:30:01 -0000 On Wed, 27 Feb 2019 12:03:57 -0500, "Borchert, Oliver (Fed)" wrote: > > While planning for IETF104, I am looking over the preliminary agenda and I am wondering, > is SIDR-OPS not meeting this time in Prague? yes... :( We forgot (I forgot) to make a request for a meeting, I actuallyhad thought the date to do this was still coming, because I thought the meeting was in april sometime :( We're in discussion with the secretariat to see if we can still sneak in, but I'm unsure if that'll end successfully. -chris From nobody Wed Feb 27 10:53:40 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A87130FE2 for ; Wed, 27 Feb 2019 10:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_PASS=-0.001] autolearn=no autolearn_force=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 UkZGs8A0CJRQ for ; Wed, 27 Feb 2019 10:53:37 -0800 (PST) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3507912D4F2 for ; Wed, 27 Feb 2019 10:53:37 -0800 (PST) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 8C3FF3FDE3 for ; Wed, 27 Feb 2019 18:53:34 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 27256304E5D2D for ; Wed, 27 Feb 2019 18:53:34 +0000 (UTC) Authentication-Results: mail.ops-netman.net; dkim=none reason="no signature"; dkim-adsp=fail (unprotected policy); dkim-atps=neutral Date: Wed, 27 Feb 2019 18:53:33 +0000 Message-ID: <87bm2xt64y.wl%morrowc@ops-netman.net> From: Chris Morrow To: sidrops@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [Sidrops] So, about that meeting... X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 18:53:38 -0000 Howdy SIDROPS folks, Likely you are dilligently reading the agenda published by the secretariat, and wondering: "Where is my fav group meeting this time?" I'm sad to say that as of right now we don't have a meeting slot, this is my oversight :( I had 'april meeting time' in my plan, and ... missed that the meeting is in march, whoops. I've asked the secretariat if there's still a 1hr slot somewhere we can slide in SIDROPS, but that's probably less likely to happen. So, for now no sidrops, hopefully an update of use in ~24hrs time. -chris From nobody Wed Feb 27 11:27:53 2019 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6B7130E69 for ; Wed, 27 Feb 2019 11:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3FGV12mtLmBD for ; Wed, 27 Feb 2019 11:27:49 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D25B12D4EB for ; Wed, 27 Feb 2019 11:27:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D8A8E3004AA for ; Wed, 27 Feb 2019 14:09:31 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rBnPXl_u4og8 for ; Wed, 27 Feb 2019 14:09:30 -0500 (EST) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 81435300460 for ; Wed, 27 Feb 2019 14:09:30 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_7D9BD9D0-B69A-427C-96EF-4A766C6A0A2F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 27 Feb 2019 14:27:46 -0500 References: To: sidrops@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 19:27:52 -0000 --Apple-Mail=_7D9BD9D0-B69A-427C-96EF-4A766C6A0A2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This seems to be a proposal for documenting why the marking is something = other that valid or invalid. I can see why a researcher might care = about those differences, but I cannot see how an operator would make use = of it. I do not think we should add complexity. Russ > Howdy WG folks! > At the Bangkok meeting Oliver asked that we push forward: > = https://tools.ietf.org/html/draft-borchert-sidrops-rpki-state-unverified-0= 1 = >=20 > for WG Adoption, the abstract is: >=20 > "In case operators decide not to evaluate BGP route prefixes = according > to RPKI route origin validation (ROV), none of the available states > as specified in RFC 6811 do properly represent this decision. This > document introduces "Unverified" as well-defined validation state > which allows to properly identify route prefixes as not evaluated > according to RPKI route origin validation." >=20 > and some brief 2wk period of discussion and such should now ensue! >=20 > Thanks! > -chris > co-chair. --Apple-Mail=_7D9BD9D0-B69A-427C-96EF-4A766C6A0A2F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 
This seems to be a proposal for documenting why the marking is something other that valid or invalid.  I can see why a researcher might care about those differences, but I cannot see how an operator would make use of it.  I do not think we should add complexity.

Russ

Howdy WG folks!
At the Bangkok meeting Oliver asked that we push forward:
 https://tools.ietf.org/html/draft-borchert-sidrops-rpki-state-unverified-01

for WG Adoption, the abstract is:

  "In case operators decide not to evaluate BGP route prefixes according
   to RPKI route origin validation (ROV), none of the available states
   as specified in RFC 6811 do properly represent this decision. This
   document introduces "Unverified" as well-defined validation state
   which allows to properly identify route prefixes as not evaluated
   according to RPKI route origin validation."

and some brief 2wk period of discussion and such should now ensue!

Thanks!
-chris
co-chair.


--Apple-Mail=_7D9BD9D0-B69A-427C-96EF-4A766C6A0A2F--


From nobody Wed Feb 27 13:52:39 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761111292F1 for ; Wed, 27 Feb 2019 13:52:37 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Hs2BkfaKWYPj for ; Wed, 27 Feb 2019 13:52:36 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 436B81288BD for ; Wed, 27 Feb 2019 13:52:36 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 2DD581E2D8; Wed, 27 Feb 2019 16:51:43 -0500 (EST)
Date: Wed, 27 Feb 2019 16:51:42 -0500
From: Jeffrey Haas 
To: Russ Housley 
Cc: sidrops@ietf.org
Message-ID: <20190227215142.GB21642@pfrc.org>
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2019 21:52:38 -0000

On Wed, Feb 27, 2019 at 02:27:46PM -0500, Russ Housley wrote:
> This seems to be a proposal for documenting why the marking is something other that valid or invalid.  I can see why a researcher might care about those differences, but I cannot see how an operator would make use of it.  I do not think we should add complexity.

I likely should write more text, but very simply some operators want easy
ways to mark that a system that should be expected to do validation has not
done so.  The existing tri-state (valid, invalid, not-found) doesn't cover
this.


-- Jeff


From nobody Wed Feb 27 14:09:20 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1491292F1 for ; Wed, 27 Feb 2019 14:09:19 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 ngxENJJZifNY for ; Wed, 27 Feb 2019 14:09:17 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B99C1288BD for ; Wed, 27 Feb 2019 14:09:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 67F47300A42 for ; Wed, 27 Feb 2019 16:50:59 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iD7teWQXXnzU for ; Wed, 27 Feb 2019 16:50:58 -0500 (EST)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 85F71300460; Wed, 27 Feb 2019 16:50:58 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Russ Housley 
In-Reply-To: <20190227215142.GB21642@pfrc.org>
Date: Wed, 27 Feb 2019 17:09:14 -0500
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com>
References:   <20190227215142.GB21642@pfrc.org>
To: Jeffrey Haas 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2019 22:09:19 -0000

Jeff:

>> This seems to be a proposal for documenting why the marking is =
something other that valid or invalid.  I can see why a researcher might =
care about those differences, but I cannot see how an operator would =
make use of it.  I do not think we should add complexity.
>=20
> I likely should write more text, but very simply some operators want =
easy
> ways to mark that a system that should be expected to do validation =
has not
> done so.  The existing tri-state (valid, invalid, not-found) doesn't =
cover
> this.

Please write a little bit more.  What action would be taken in the =
unverified state that is different from the action taken in the =
not-found state?

Russ


From nobody Wed Feb 27 14:18:30 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897DF13116F for ; Wed, 27 Feb 2019 14:18:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 ZvPPWGNfg8jP for ; Wed, 27 Feb 2019 14:18:27 -0800 (PST)
Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd00::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27DC1288BD for ; Wed, 27 Feb 2019 14:18:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=il6xaOrOwJ28SGQ8JVaYO1TDVBFb6UyADDRfhOh9UO0=; b=Bvd6QPpxglnpHkV1s5tfJ+/R1c+cWNe3k0Uy7B9Wcu/4wbO7nBmeszNP43k5gdoB5wyod5P372/5yPWCmm2rkZABMNXhbIkh8MmC7tWxeLj0b+ddg259Ii67fzd7UPOIgKC+X2EUHpbrRCY1bKgciAQX07ndKEEX36pRaBBEi/4=
Received: from DM6PR09MB3244.namprd09.prod.outlook.com (20.178.3.144) by DM6PR09MB3243.namprd09.prod.outlook.com (20.178.3.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Wed, 27 Feb 2019 22:18:25 +0000
Received: from DM6PR09MB3244.namprd09.prod.outlook.com ([fe80::7804:8385:141:8a49]) by DM6PR09MB3244.namprd09.prod.outlook.com ([fe80::7804:8385:141:8a49%4]) with mapi id 15.20.1665.015; Wed, 27 Feb 2019 22:18:25 +0000
From: "Montgomery, Douglas (Fed)" 
To: Russ Housley , Jeffrey Haas 
CC: "sidrops@ietf.org" 
Thread-Topic: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
Thread-Index: AQHUztKTbd7Dl9/bdEmNmyGXwzeBcaX0L5oAgAAE5gD//66+AA==
Date: Wed, 27 Feb 2019 22:18:24 +0000
Message-ID: <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com>
In-Reply-To: <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.17.0.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; 
x-originating-ip: [2610:20:6222:140:b400:fba1:5f8d:f236]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f6229e1c-0f9c-4d5c-0545-08d69d017dd6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR09MB3243; 
x-ms-traffictypediagnostic: DM6PR09MB3243:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjA5TUIzMjQzOzIzOlh0akpMckpseWpTY0ZJTHFrT0krdHBpZ2VS?= =?utf-8?B?cDNaZ2MySDRHOG11S0gyMFpCTGUyZmdNUitFSWVzemlxZXljYnoyZy9VTFZU?= =?utf-8?B?YnEzbEEyZWY4NGlaVUhQY3RKbGJpUzRGQlBtWFQxc2VJYmcyTkRtYmxqdkNw?= =?utf-8?B?NndkRVVzSVVERHdndHZGTW5RVVBGRTB6bUtGY1k2L1hvT3ExbEFvSU4xUW93?= =?utf-8?B?RUdva0lyWWZoSDk5T3VWbVRKVmthbzM0bGxlT1UxcGZEMmlBa3NuTzhmZllO?= =?utf-8?B?am56MWpRZ3FHMGlWQnpGRjUvNW1zd3dMVTh6T3p1OHZyOFJ5KzFUUk1XT3VI?= =?utf-8?B?MVpnSndEMHB0QTFTYVlrUk5QRysySzRLMHczMlpSNDdyL0xWREZMWjk4S1o4?= =?utf-8?B?YVVOSmcwRnptOVRNczM3U0FBOTB4Mjc0SUhKK1pYOUxDcXQ2YnhFZVNoajVy?= =?utf-8?B?ZkhCZUFHT0ZPZkVORytTN1lUNnlqdGhDUDAyMTltdTFIWnBzZDJKVkx4bTUv?= =?utf-8?B?VEtDb3VlNm14RW43b09aMDJYWExVWG02b3p6ODZiSVpHQmFSYlNEQm5LbkdJ?= =?utf-8?B?TEtXdmpaQ3BWZGNwdUpJb3ArMFFsTzhqT0p6bi9FSTBaNlprMjVIOWhlS1RO?= =?utf-8?B?VUtIcTlDbHZVbWZjNGp2bHpGV1J2a3FOcjUrMWJZZ1ZJSUJVaUdrSXUyMHBP?= =?utf-8?B?WjlQRERCU3pMUGtGbFg1ellEK3QwdnljRTQwdlRmNHlnNHlrNERTaks2eDMv?= =?utf-8?B?Z3Z2ekpORVdBVFNveHd6Z0YxbEppS0JmZDQydTY2ZzZHS25DWDhMdWpIYUp5?= =?utf-8?B?Z3pBaG5rbGFlblJ2YWR5TFFFTE90TWg0WkFiZ240NDF5ZTRaUnVjbFp0T05I?= =?utf-8?B?d1NRc3JqQms4Ym41YzNJT1FWOERkcWNEV0VzNnc3Nm5oaFc5anhRN08zOHky?= =?utf-8?B?SzRGUEtLMGMzT09qN0J6ZjVTNFRoZUNPVENYVytIblkrVzlxS3c4V1BLSW1R?= =?utf-8?B?T2J5M1d1SWhXQ3pRSnhmU3Y0Z0NSWDFGNUVZM01SQi94Z1dOMllLa1pYamxL?= =?utf-8?B?LytjUitLOHlQVHZuODBRY2RPZGV4NlRBMWJLU0N4MUZhNjR1cTdBdG9DTFNU?= =?utf-8?B?WU94Rjg1R1NVTlhYbmp5cElKc25OZWRGWi83TDFDbTRQeDl1OW1KNUdpejlU?= =?utf-8?B?dTBUeHl6RisySmFiTGlUSzR4VDVRdHAvYmpoWWVIbHBISThBYjVoWmI5Y0Ny?= =?utf-8?B?ckhrUkVTN3I4KzNNQzFkSUZTQ2VFR1ZtMWlDS1BVci9KdXhHaEgwYUJ1T3B2?= =?utf-8?B?a1NVc3RQcEZRTExkMGZBUEhrWDY5L3Q4MU81ZjBJNmxOeXNmSTdKRlcrYTYy?= =?utf-8?B?b0ZtOXhBbUFraE8xRGxoTkxCanVORU8yeVRhWFc5RnRJWjVkMFh4ZUFhSWkr?= =?utf-8?B?Rmp2dkpWUk9YT256aXBIREVXZjZ4NU5TVW5QRHlOclg4ajJmWS9EbldzUUFj?= =?utf-8?B?clUvRjh6Z0hoL05MRWQ5YmR5K3h5bkVGOFpFa0JWK2tkQkFKSGVDcFhpa1BE?= =?utf-8?B?TnArNy80dCtzUU1JbnF0T3EwTHozbHRJOHhRYmJUYXM5L1VtYWdWbHFJRDBq?= =?utf-8?B?eERkb25WNGMwbTRFLzQ0MEpoQS9Pb3JGYnhGMHovZGlFWGlGQjRRQlpSSk81?= =?utf-8?B?cUpraVZJVW85K2JYSmNDRzhpU2QzR2E5MTBISWdIUGh2akFwQXFoR0o5S0tx?= =?utf-8?B?WklCVXRvRUptVTY3OEczRkxubEZzUUpjalVpSGpSV3U0U1NaMDNHd1JnV1dT?= =?utf-8?Q?N8uu15ui+Tq28?=
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0961DF5286
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(346002)(366004)(39860400002)(199004)(189003)(46003)(33656002)(186003)(6506007)(6306002)(102836004)(93886005)(446003)(71200400001)(561944003)(305945005)(7736002)(71190400001)(83716004)(81166006)(99286004)(316002)(486006)(2616005)(6486002)(11346002)(66574012)(476003)(14454004)(81156014)(8676002)(8936002)(5660300002)(6512007)(14444005)(6436002)(4326008)(966005)(256004)(76176011)(86362001)(110136005)(58126008)(97736004)(45080400002)(6116002)(82746002)(229853002)(36756003)(105586002)(53936002)(6246003)(25786009)(478600001)(106356001)(68736007)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3243; H:DM6PR09MB3244.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: PCEU4GUTZaipe8qwPNEtkVzMyWGujqodgzbO6BxzXWQHyJmmXJBlIJX6St2rA3ieByevrREuVbVCzGPywmOf70rYSzY85SRnXhjn0qrP0QijbEotxownk983ffVCwU+Ls/x048t02qM6CouKTfbHGrLbDJweTL2zwNhDIxw1iDtdTbWYDvDa/LtOMiDRbvWXsTWQCrAn4iwORDFVRdfQ89OespaIYMqyWIio2U8wq21uPkYb7o1DKWeasdir5t76Wy4UiuzSmXfP2j4fHe8K+LiyNFJIHskVUh7x0GrEV08qm0HcPRYh/H0+oTnLnmH+bg7ADk0VACLNtnLV5Scd29RPVjnBHEiKpJQOilPp8EK+uCzOQ+rvUdXFFJQcdcvH6ZSGJDvb11a/lK564p4P0t+rddPaD9xFh6W8EIezrUg=
Content-Type: text/plain; charset="utf-8"
Content-ID: <440111DE76D26445992DCAED708E3861@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: f6229e1c-0f9c-4d5c-0545-08d69d017dd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 22:18:24.9889 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3243
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2019 22:18:29 -0000

RXhhbWluZSB0aGUgaUJHUCBwZWVyIHRoYXQgeW91IHRob3VnaHQgeW91IGNvbmZpZ3VyZWQgdG8g
ZG8gb3JpZ2luIHZhbGlkYXRpb24gYW5kIGRldGVybWluZSB3aHkgaXQgaXMgdW5hYmxlIHRvLg0K
DQpXZSBlbnZpc2lvbmVkIHRoaXMgYmVpbmcgdXNlZnVsIGluIHNjZW5hcmlvcyBzdWNoIGFzOiB5
b3UgaGF2ZSBlbmFibGVkIEJHUCBPcmlnaW4gVmFsaWRhdGlvbiBvbiBhIHJvdXRlciB0aGF0IGhh
cyBsb3N0IGFsbCBjb25uZWN0aW9ucyB0byBpdHMgdmFsaWRhdGluZyBjYWNoZXMuICBBdCB0aGUg
bW9tZW50IHdlIGNhbid0IHRlbGwgYWRtaW5pc3RyYXRpdmVseSBkaXNhYmxlZCBmcm9tIGVuYWJs
ZWQsIGJ1dCBmYWlsZWQgaW4gc29tZSBtYW5uZXIuICAgV2Ugc2VlIHNvbWUgdmFsdWUgaW4gYmVp
bmcgYWJsZSB0byBkaWFnbm9zZSB0aGF0Lg0KDQpLZWVwIGluIG1pbmQsIG1vc3Qgb2YgdGhlIEZV
RCBpbiB0aGlzIHNwYWNlIGNvbWVzIGZyb20gdGhlIGZlYXIgdGhhdCBvcGVyYXRvcnMgd2lsbCBu
b3QgYmUgYWJsZSB0byBkaWFnbm9zZSB3aHkgcm91dGVzIGFyZS9hcmUgbm90IGJlaW5nIGZpbHRl
cmVkLiAgVGhpcyB0aGVtZSBjYW1lIHVwIGEgbG90IGluIHRoZSBtZWV0aW5nIGJlZm9yZSBOQU5P
Ry4NCg0KTm90IHRoZSBzdWJqZWN0IG9mIHRoaXMgZHJhZnQsIGJ1dCB0aGUgY29uY2VwdCBvZiBi
ZWluZyBhYmxlIHRvIHRlbGwgaWYgeW91ciBpQkdQIHBlZXIgYWN0dWFsbHkgcGVyZm9ybWVkIHZh
bGlkYXRpb24gd2lsbCBiZSBldmVuIG1vcmUgdXNlZnVsIGluIEJHUFNlYywgYnV0IHRoYXQgaXMg
Zm9yIGFub3RoZXIgZHJhZnQuDQoNCmRvdWdtDQotLSANCkRvdWdNIGF0IE5JU1QNCiANCg0K77u/
T24gMi8yNy8xOSwgNTowOSBQTSwgIlNpZHJvcHMgb24gYmVoYWxmIG9mIFJ1c3MgSG91c2xleSIg
PHNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaG91c2xleUB2aWdpbHNlYy5j
b20+IHdyb3RlOg0KDQogICAgSmVmZjoNCiAgICANCiAgICA+PiBUaGlzIHNlZW1zIHRvIGJlIGEg
cHJvcG9zYWwgZm9yIGRvY3VtZW50aW5nIHdoeSB0aGUgbWFya2luZyBpcyBzb21ldGhpbmcgb3Ro
ZXIgdGhhdCB2YWxpZCBvciBpbnZhbGlkLiAgSSBjYW4gc2VlIHdoeSBhIHJlc2VhcmNoZXIgbWln
aHQgY2FyZSBhYm91dCB0aG9zZSBkaWZmZXJlbmNlcywgYnV0IEkgY2Fubm90IHNlZSBob3cgYW4g
b3BlcmF0b3Igd291bGQgbWFrZSB1c2Ugb2YgaXQuICBJIGRvIG5vdCB0aGluayB3ZSBzaG91bGQg
YWRkIGNvbXBsZXhpdHkuDQogICAgPiANCiAgICA+IEkgbGlrZWx5IHNob3VsZCB3cml0ZSBtb3Jl
IHRleHQsIGJ1dCB2ZXJ5IHNpbXBseSBzb21lIG9wZXJhdG9ycyB3YW50IGVhc3kNCiAgICA+IHdh
eXMgdG8gbWFyayB0aGF0IGEgc3lzdGVtIHRoYXQgc2hvdWxkIGJlIGV4cGVjdGVkIHRvIGRvIHZh
bGlkYXRpb24gaGFzIG5vdA0KICAgID4gZG9uZSBzby4gIFRoZSBleGlzdGluZyB0cmktc3RhdGUg
KHZhbGlkLCBpbnZhbGlkLCBub3QtZm91bmQpIGRvZXNuJ3QgY292ZXINCiAgICA+IHRoaXMuDQog
ICAgDQogICAgUGxlYXNlIHdyaXRlIGEgbGl0dGxlIGJpdCBtb3JlLiAgV2hhdCBhY3Rpb24gd291
bGQgYmUgdGFrZW4gaW4gdGhlIHVudmVyaWZpZWQgc3RhdGUgdGhhdCBpcyBkaWZmZXJlbnQgZnJv
bSB0aGUgYWN0aW9uIHRha2VuIGluIHRoZSBub3QtZm91bmQgc3RhdGU/DQogICAgDQogICAgUnVz
cw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQogICAgU2lkcm9wcyBtYWlsaW5nIGxpc3QNCiAgICBTaWRyb3BzQGlldGYub3JnDQogICAg
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl
M0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzaWRyb3BzJmFtcDtk
YXRhPTAyJTdDMDElN0Nkb3VnbSU0MG5pc3QuZ292JTdDMzVhM2QxNDQ4M2I3NGY0MmZmN2UwOGQ2
OWQwMDQzYjUlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MwJTdDNjM2
ODY5MDIxODAwOTkwNTQ1JmFtcDtzZGF0YT1aNENNaHpBJTJCUmVPMjFnRlloWFpxTVF3TDRueGRq
elRSOVZwWWNBY21yUGclM0QmYW1wO3Jlc2VydmVkPTANCiAgICANCg0K


From nobody Wed Feb 27 14:29:23 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72C131197 for ; Wed, 27 Feb 2019 14:29:21 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 j7AdrIhH_FTI for ; Wed, 27 Feb 2019 14:29:19 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6D189131180 for ; Wed, 27 Feb 2019 14:29:19 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id C63C41E2D8; Wed, 27 Feb 2019 17:28:26 -0500 (EST)
Date: Wed, 27 Feb 2019 17:28:26 -0500
From: Jeffrey Haas 
To: Russ Housley 
Cc: sidrops@ietf.org
Message-ID: <20190227222826.GA26668@pfrc.org>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2019 22:29:22 -0000

On Wed, Feb 27, 2019 at 05:09:14PM -0500, Russ Housley wrote:
> >> This seems to be a proposal for documenting why the marking is something other that valid or invalid.  I can see why a researcher might care about those differences, but I cannot see how an operator would make use of it.  I do not think we should add complexity.
> > 
> > I likely should write more text, but very simply some operators want easy
> > ways to mark that a system that should be expected to do validation has not
> > done so.  The existing tri-state (valid, invalid, not-found) doesn't cover
> > this.
> 
> Please write a little bit more.  What action would be taken in the unverified state that is different from the action taken in the not-found state?

Among other things, not draconically drop things if that's your policy.

not-found says the prefix isn't in the db.
unverified means that the db might be outright down.

How you feel about such things will wildly vary depending on your network
and how much you wear a security hat for your day job.

-- Jeff


From nobody Wed Feb 27 15:48:35 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407071311E1 for ; Wed, 27 Feb 2019 15:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 F73WEJTqzxpD for ; Wed, 27 Feb 2019 15:48:32 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A111311D7 for ; Wed, 27 Feb 2019 15:48:32 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gz8w7-0004SJ-O7; Wed, 27 Feb 2019 23:48:27 +0000
Date: Wed, 27 Feb 2019 15:48:26 -0800
Message-ID: 
From: Randy Bush 
To: "Montgomery, Douglas (Fed)" 
Cc: Russ Housley , Jeffrey Haas , "sidrops@ietf.org" 
In-Reply-To: <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Feb 2019 23:48:34 -0000

> Examine the iBGP peer that you thought you configured to do origin
> validation and determine why it is unable to.

the path of debugging hooks runs far deeper into the mud.  to repeat;
you are stepping off a cliff here.

there are a number of reasons the match might not have been made: peer
not configured for validation, prefix in execption list, AS in exception
list, ...  will we next enumerate them all?  e.g. for debugging, i might
like to know which of my policies, or combination thereof, caused the
prefix not to be evaluated.  i am NOT suggesting we go down this rabbit
hole.

> We envisioned this being useful in scenarios such as: you have enabled
> BGP Origin Validation on a router that has lost all connections to its
> validating caches.

% show bgp rpki servers

> At the moment we can't tell administratively disabled from enabled,
> but failed in some manner.  We see some value in being able to
> diagnose that.

that is why we have cli-based (and yang etc) debugging tools.  you want
to know where in all your complex policy some decision was made, you
need to go through the policy, don't try to encode the cross-product of
all the posibilities in a result.

> Keep in mind, most of the FUD in this space comes from the fear that
> operators will not be able to diagnose why routes are/are not being
> filtered.  This theme came up a lot in the meeting before NANOG.

the game is over.  at&t has deployed and the multitude are hurrying to
join him.  and the flag-wavers are rushing to get in front and curry
publicity.

> Not the subject of this draft, but the concept of being able to tell
> if your iBGP peer actually performed validation will be even more
> useful in BGPSec, but that is for another draft.

and another century

randy


From nobody Wed Feb 27 16:09:27 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B79130EA7 for ; Wed, 27 Feb 2019 16:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 sUrwzDh8wZtb for ; Wed, 27 Feb 2019 16:09:23 -0800 (PST)
Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830119.outbound.protection.outlook.com [40.107.83.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5EA1279E6 for ; Wed, 27 Feb 2019 16:09:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iy7SWv8B2jia2lzkqGPnkowK0hbS9YhfzU0/Umw+rIA=; b=PVnej5eu4AmrSj46tdr9rFCRD/FZRUCIuHuClyVAOc35s6wDOuiQgTaeDUPWKbnGrZUWW5QgsdsGWPl+sThMQRoLDlrbPLEdIYvpIAfBdmyl2qzVc0q9tQhF5ltZgw6AhwqX0WEvNSnMDmd1YQ3wdedwJWt9+lh5w7e//sTnUZQ=
Received: from DM6PR09MB3244.namprd09.prod.outlook.com (20.178.3.144) by DM6PR09MB3241.namprd09.prod.outlook.com (20.178.3.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Thu, 28 Feb 2019 00:09:19 +0000
Received: from DM6PR09MB3244.namprd09.prod.outlook.com ([fe80::7804:8385:141:8a49]) by DM6PR09MB3244.namprd09.prod.outlook.com ([fe80::7804:8385:141:8a49%4]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 00:09:19 +0000
From: "Montgomery, Douglas (Fed)" 
To: Randy Bush 
CC: Russ Housley , Jeffrey Haas , "sidrops@ietf.org" 
Thread-Topic: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
Thread-Index: AQHUztKTbd7Dl9/bdEmNmyGXwzeBcaX0L5oAgAAE5gD//66+AIAAbPkA//+yAwA=
Date: Thu, 28 Feb 2019 00:09:18 +0000
Message-ID: <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.17.0.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; 
x-originating-ip: [2610:20:6222:140:71a8:a290:585c:23ac]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f69458f2-afc7-4af4-51e5-08d69d10fbdd
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR09MB3241; 
x-ms-traffictypediagnostic: DM6PR09MB3241:
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjA5TUIzMjQxOzIzOjltdDJ5cDkydUFycWpkTTBPVmZUaXhoeGN0?= =?utf-8?B?SDJMY2lDeHRGazBxZ0NuQnNlZXhUMmhxMG1pamVpdWJZbWhkOEovRjBydi9a?= =?utf-8?B?WVpyY3BiZ3F0bDZCSURkdzFMVitXaUVGN2MxZEhnRWpES040a3BRZXAwV0tw?= =?utf-8?B?Ty9rUlFRbHN5WVI4eXh3SjhuYnZBVXNIeUNvM1ZkVDhDSzl4dzUzM0R3ZjNj?= =?utf-8?B?cm1OaURBM3V5Skx5TDdXd09xbmRQdEx3Ri84MDJNT01HbGt0dXNmcFpvZGw0?= =?utf-8?B?M3Qzc1I0RG5VeEY1eUlyZXVVbVZJeUtWR2c3RVRMUnkyMmo1U3k1RWgrT0ho?= =?utf-8?B?UW1vcENpWEdlUXgwRTFyNWRseWZNRVNhVmNPb1hON1BVRno5a1lyaXhBeW51?= =?utf-8?B?enhqeWNvMWRMNGY4SGFoSlU2N0l6eVpmVjRENUxBUXZiZEVIUm1vblhoclRi?= =?utf-8?B?VFFBeEdWVktUS0R4cGFLMTB5Q3lmdVhuRVJGNzMrNHM1eExKS3B5M0dLT1lF?= =?utf-8?B?Rkp5Qy9EUkltT0pQNzFSTER4Mm5zTTQ5NzZkZHpYTnEydUZJb3BhcGsweUxW?= =?utf-8?B?ZjJUelI5N3pBUmhGRjhmY0I0NVVqT3R0dlJRVW5teDFLLzJNS0VucWE0dUpJ?= =?utf-8?B?cE9RRk50U3BybXpUWnFvSCt5YmEveWFXMzhVNVV1Mjg1K0U0enBOcmFJczRW?= =?utf-8?B?bitBdnB1bjYzbTFoRjBMTkdjNDYrKzJnS1V4MGRIWFZBRU9hL0F3bTNEaVYz?= =?utf-8?B?RW1JMkVQcE5RbTVSMzNwU2hrMjZkN2xkbFlsS2VXZG1PVUxtWXJkVzdDOWht?= =?utf-8?B?TWplZmtNZUVBUVlWYkx3NWVPanprSUg3cVdtRUtndE1tZjZiU3JZNjlGSzEr?= =?utf-8?B?eWhqMHhWL25PZ1BaNFVXamtXbTIySHREelBhRWM1RTk4bmJBTm9TOG1JeUdm?= =?utf-8?B?ZWp2ZHRWWEhtQW96S01VdkxkL3BtWGkvank3TnZiMWxKMTF5aldpUGJGRmNi?= =?utf-8?B?SW1zUXhNWnBkZnlQVUFoSFBWQXNqSDhJeFJpNytlcTNDR0Zmc2ltamxzdkgy?= =?utf-8?B?c2ZBNjVaSk1ldzczTWZ5THZXSm92SzdKQXpsK0pFQit3Q2xvZ3Y2dEhvSFpv?= =?utf-8?B?VkU1UVdtOEF0KzdXRERGb2oyL2d2ZW0ycDBJUU14ZXlIb1M3N3k3R0dJVnVF?= =?utf-8?B?SXJGUG1PV1Ztc2EralUwR1V1emg4bTRoa1A1ZW45SkxVeEtUQ3Q4QXg5Uk4r?= =?utf-8?B?NGlZZ3ZwRHJ0SGNIRkp4bTUvaG9xWHM2WWlWSHdrNHdqR0xmK0gzenA4TUQ4?= =?utf-8?B?cTdqMHlCZVlGQXZVSVBhMnJkMGxuZEtkQWJyUkhlOURlaER1S2RYQTdod1ZT?= =?utf-8?B?T1BVeE1jakZxUEJ0L2EybXFLM1pEUUZ5Nlk0WFgwNHNUdjFvVER2S2RidTFH?= =?utf-8?B?YzJqS3plYVdhNWhzOVRabFR2RC8vNy9wUDVXRUZTUXFQMDlvdTY1Z2N2Y21X?= =?utf-8?B?L2RZdStmSTlFaExzZFBUWjl3VlNBdGhwL2dMdSttS05RMXNQY3F2U0J4TnlX?= =?utf-8?B?VTFETytrT1R2cGxudEczZjJVOEVTbjRuMUVFODd2a3dBZVR5MkpwVmErV2xa?= =?utf-8?B?eldJejBFWjR3SUROb2ZHYVpyeDBCOUdjNk00UHRNejNjVmdEWjdCSExwbTlq?= =?utf-8?Q?SR8zO73UlvaRohikvQqRDJryBmWyFiyrlf/azWb?=
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0962D394D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(136003)(396003)(366004)(189003)(199004)(93886005)(97736004)(82746002)(36756003)(68736007)(33656002)(14444005)(256004)(81166006)(6916009)(102836004)(99286004)(6506007)(71200400001)(71190400001)(305945005)(81156014)(229853002)(7736002)(76176011)(83716004)(8676002)(6486002)(6436002)(6512007)(8936002)(53936002)(25786009)(46003)(86362001)(5660300002)(106356001)(14454004)(105586002)(54906003)(66574012)(478600001)(6116002)(4326008)(2906002)(6246003)(2616005)(11346002)(446003)(486006)(186003)(58126008)(316002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3241; H:DM6PR09MB3244.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sP1x1M4IU90WBND2QbVr/ckuHfzpG6GuxTclY+lxDm27kMDwuZWAqbqC/wkQTmQ8wwfwf8WkCcD9XnyS7Ku+V7VCwg9bUZEcTPplPHh993An00+i/qgIMkI2Ms9jFwQk0MY2IUSagT+LcYSYOw4KzyRRcJX1ll+yB82maAftMR5/TYBhO5wuXw1Xvelc9EG4a0BEep1Z/gP/6eBl2GteiS1f0gRxzVgoH3H1ZsSsEENc5kNM9MdsqeTYsIQ+0++nv92MqKP3Y4n+wGGjOL3ecZZAhoKi5JASYdcuLoqXcA+KeS0cnnUIadSkToLgV7LkQfpDU8qlv9nC07o9ZBR45m8wfLsTsWyWLVKkGewG/HB0L9/NA09lM4vKWwBpvy38JMKb7UTMpHLXzee3/yLBBU/JtjxoR8e9oDQXYYxKCOo=
Content-Type: text/plain; charset="utf-8"
Content-ID: <1B652A6744777743BA0C667DEC48DAC4@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: f69458f2-afc7-4af4-51e5-08d69d10fbdd
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 00:09:18.8535 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3241
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 00:09:26 -0000

V2hpY2ggb2YgeW91ciBOIGh1bmRyZWQgcm91dGVycyB3aWxsIHlvdSBsb2dpbiB0bywgdG8gZG8g
dGhlICJzaG93IGJncCBycGtpIHNlcnZlcnMiPw0KDQpXZSB0aG91Z2h0IHRoZSBvbmUgc2VuZGlu
ZyB5b3UgInVudmVyaWZpZWQiIHN0YXRlIHdvdWxkIGJlIGEgZ29vZCBjbHVlLg0KDQpObyBvbmUg
d2FzIGFza2luZyBmb3IgdGhlIGNyb3NzIHByb2R1Y3Qgb2YgYW55IG90aGVyIGluZm8gLi4uIHNv
IEkgZG9uJ3QgcmVhbGx5IGJ1eSB0aGUgc2xpcHBlcnkgc2xvcGUgbG9naWMuDQoNCkkgaG9wZSB5
b3UgYXJlIHJpZ2h0IGFib3V0IGV2ZXJ5b25lIHJ1c2hpbmcgdG8gam9pbiB0aGUgcGFyYWRlLiAg
DQoNCkkgc3RpbGwgc2VlIGFzIG1hbnkgZm9sa3MgZXhwcmVzcyBjb25jZXJucyBhYm91dCBkZWJ1
Z2dpbmcgYXMgd2F2ZSBmbGFncy4NCg0KZG91Z20NCi0tIA0KRG91Z00gYXQgTklTVA0KIA0KDQrv
u79PbiAyLzI3LzE5LCA2OjQ4IFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3Rl
Og0KDQogICAgPiBFeGFtaW5lIHRoZSBpQkdQIHBlZXIgdGhhdCB5b3UgdGhvdWdodCB5b3UgY29u
ZmlndXJlZCB0byBkbyBvcmlnaW4NCiAgICA+IHZhbGlkYXRpb24gYW5kIGRldGVybWluZSB3aHkg
aXQgaXMgdW5hYmxlIHRvLg0KICAgIA0KICAgIHRoZSBwYXRoIG9mIGRlYnVnZ2luZyBob29rcyBy
dW5zIGZhciBkZWVwZXIgaW50byB0aGUgbXVkLiAgdG8gcmVwZWF0Ow0KICAgIHlvdSBhcmUgc3Rl
cHBpbmcgb2ZmIGEgY2xpZmYgaGVyZS4NCiAgICANCiAgICB0aGVyZSBhcmUgYSBudW1iZXIgb2Yg
cmVhc29ucyB0aGUgbWF0Y2ggbWlnaHQgbm90IGhhdmUgYmVlbiBtYWRlOiBwZWVyDQogICAgbm90
IGNvbmZpZ3VyZWQgZm9yIHZhbGlkYXRpb24sIHByZWZpeCBpbiBleGVjcHRpb24gbGlzdCwgQVMg
aW4gZXhjZXB0aW9uDQogICAgbGlzdCwgLi4uICB3aWxsIHdlIG5leHQgZW51bWVyYXRlIHRoZW0g
YWxsPyAgZS5nLiBmb3IgZGVidWdnaW5nLCBpIG1pZ2h0DQogICAgbGlrZSB0byBrbm93IHdoaWNo
IG9mIG15IHBvbGljaWVzLCBvciBjb21iaW5hdGlvbiB0aGVyZW9mLCBjYXVzZWQgdGhlDQogICAg
cHJlZml4IG5vdCB0byBiZSBldmFsdWF0ZWQuICBpIGFtIE5PVCBzdWdnZXN0aW5nIHdlIGdvIGRv
d24gdGhpcyByYWJiaXQNCiAgICBob2xlLg0KICAgIA0KICAgID4gV2UgZW52aXNpb25lZCB0aGlz
IGJlaW5nIHVzZWZ1bCBpbiBzY2VuYXJpb3Mgc3VjaCBhczogeW91IGhhdmUgZW5hYmxlZA0KICAg
ID4gQkdQIE9yaWdpbiBWYWxpZGF0aW9uIG9uIGEgcm91dGVyIHRoYXQgaGFzIGxvc3QgYWxsIGNv
bm5lY3Rpb25zIHRvIGl0cw0KICAgID4gdmFsaWRhdGluZyBjYWNoZXMuDQogICAgDQogICAgJSBz
aG93IGJncCBycGtpIHNlcnZlcnMNCiAgICANCiAgICA+IEF0IHRoZSBtb21lbnQgd2UgY2FuJ3Qg
dGVsbCBhZG1pbmlzdHJhdGl2ZWx5IGRpc2FibGVkIGZyb20gZW5hYmxlZCwNCiAgICA+IGJ1dCBm
YWlsZWQgaW4gc29tZSBtYW5uZXIuICBXZSBzZWUgc29tZSB2YWx1ZSBpbiBiZWluZyBhYmxlIHRv
DQogICAgPiBkaWFnbm9zZSB0aGF0Lg0KICAgIA0KICAgIHRoYXQgaXMgd2h5IHdlIGhhdmUgY2xp
LWJhc2VkIChhbmQgeWFuZyBldGMpIGRlYnVnZ2luZyB0b29scy4gIHlvdSB3YW50DQogICAgdG8g
a25vdyB3aGVyZSBpbiBhbGwgeW91ciBjb21wbGV4IHBvbGljeSBzb21lIGRlY2lzaW9uIHdhcyBt
YWRlLCB5b3UNCiAgICBuZWVkIHRvIGdvIHRocm91Z2ggdGhlIHBvbGljeSwgZG9uJ3QgdHJ5IHRv
IGVuY29kZSB0aGUgY3Jvc3MtcHJvZHVjdCBvZg0KICAgIGFsbCB0aGUgcG9zaWJpbGl0aWVzIGlu
IGEgcmVzdWx0Lg0KICAgIA0KICAgID4gS2VlcCBpbiBtaW5kLCBtb3N0IG9mIHRoZSBGVUQgaW4g
dGhpcyBzcGFjZSBjb21lcyBmcm9tIHRoZSBmZWFyIHRoYXQNCiAgICA+IG9wZXJhdG9ycyB3aWxs
IG5vdCBiZSBhYmxlIHRvIGRpYWdub3NlIHdoeSByb3V0ZXMgYXJlL2FyZSBub3QgYmVpbmcNCiAg
ICA+IGZpbHRlcmVkLiAgVGhpcyB0aGVtZSBjYW1lIHVwIGEgbG90IGluIHRoZSBtZWV0aW5nIGJl
Zm9yZSBOQU5PRy4NCiAgICANCiAgICB0aGUgZ2FtZSBpcyBvdmVyLiAgYXQmdCBoYXMgZGVwbG95
ZWQgYW5kIHRoZSBtdWx0aXR1ZGUgYXJlIGh1cnJ5aW5nIHRvDQogICAgam9pbiBoaW0uICBhbmQg
dGhlIGZsYWctd2F2ZXJzIGFyZSBydXNoaW5nIHRvIGdldCBpbiBmcm9udCBhbmQgY3VycnkNCiAg
ICBwdWJsaWNpdHkuDQogICAgDQogICAgPiBOb3QgdGhlIHN1YmplY3Qgb2YgdGhpcyBkcmFmdCwg
YnV0IHRoZSBjb25jZXB0IG9mIGJlaW5nIGFibGUgdG8gdGVsbA0KICAgID4gaWYgeW91ciBpQkdQ
IHBlZXIgYWN0dWFsbHkgcGVyZm9ybWVkIHZhbGlkYXRpb24gd2lsbCBiZSBldmVuIG1vcmUNCiAg
ICA+IHVzZWZ1bCBpbiBCR1BTZWMsIGJ1dCB0aGF0IGlzIGZvciBhbm90aGVyIGRyYWZ0Lg0KICAg
IA0KICAgIGFuZCBhbm90aGVyIGNlbnR1cnkNCiAgICANCiAgICByYW5keQ0KICAgIA0KDQo=


From nobody Wed Feb 27 16:11:13 2019
Return-Path: 
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F37471286E7; Wed, 27 Feb 2019 16:11:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: sidrops-chairs@ietf.org, lflynn@amsl.com, sidrops@ietf.org, warren@kumari.net
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155131267199.14152.9776071622971703130.idtracker@ietfa.amsl.com>
Date: Wed, 27 Feb 2019 16:11:11 -0800
Archived-At: 
Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 104
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 00:11:12 -0000

A new meeting session request has just been submitted by Liz Flynn, on behalf of the sidrops working group.


---------------------------------------------------------
Working Group Name: SIDR Operations
Area Name: Operations and Management Area
Session Requester: Liz Flynn

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 80
Conflicts to Avoid: 
 First Priority: idr grow
 Second Priority: opsarea opsec
 Third Priority: opsawg


People who must be present:
  Keyur Patel
  Alvaro Retana
  Chris Morrow
  Warren "Ace" Kumari

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Wed Feb 27 16:43:13 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192A5131204 for ; Wed, 27 Feb 2019 16:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DFG1_buE7ZKH for ; Wed, 27 Feb 2019 16:43:09 -0800 (PST)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9551311FF for ; Wed, 27 Feb 2019 16:43:09 -0800 (PST)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gz9mv-003GtV-1N>; Thu, 28 Feb 2019 01:43:01 +0100
Received: from x4db7b587.dyn.telefonica.de ([77.183.181.135] helo=mw-x1.fritz.box) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1gz9mu-000jmF-QN>; Thu, 28 Feb 2019 01:43:00 +0100
Date: Thu, 28 Feb 2019 01:42:58 +0100
From: Matthias Waehlisch 
To: "Montgomery, Douglas (Fed)" 
cc: Randy Bush , Jeffrey Haas ,  "sidrops@ietf.org" , Russ Housley 
In-Reply-To: <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>
Message-ID: 
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>  <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
X-X-Sender: waehl@mail.zedat.fu-berlin.de
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Originating-IP: 77.183.181.135
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 00:43:12 -0000

The main problem of this discussion is the past: Sidr(ops) has history 
on discussing this topic (sorry that I'm too lazy to give reference to 
the mailing list pointers).

Personally, I have the impression that we run in circles. I don't see a 
clear and crisp reflection on what has been discussed that gives 
striking conclusion on continuing this topic.


Cheers
  matthias


On Thu, 28 Feb 2019, Montgomery, Douglas (Fed) wrote:

> Which of your N hundred routers will you login to, to do the "show bgp rpki servers"?
> 
> We thought the one sending you "unverified" state would be a good clue.
> 
> No one was asking for the cross product of any other info ... so I don't really buy the slippery slope logic.
> 
> I hope you are right about everyone rushing to join the parade.  
> 
> I still see as many folks express concerns about debugging as wave flags.
> 
> dougm
> 


-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl


From nobody Wed Feb 27 17:48:06 2019
Return-Path: 
X-Original-To: sidrops@ietf.org
Delivered-To: sidrops@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A461277D2; Wed, 27 Feb 2019 17:47:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sidrops@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: sidrops@ietf.org
Message-ID: <155131847773.13970.13636266071128872194@ietfa.amsl.com>
Date: Wed, 27 Feb 2019 17:47:57 -0800
Archived-At: 
Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-04.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 01:47:58 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIDR Operations WG of the IETF.

        Title           : Router Keying for BGPsec
        Authors         : Randy Bush
                          Sean Turner
                          Keyur Patel
	Filename        : draft-ietf-sidrops-rtr-keying-04.txt
	Pages           : 19
	Date            : 2019-02-27

Abstract:
   BGPsec-speaking routers are provisioned with private keys in order to
   sign BGPsec announcements.  The corresponding public keys are
   published in the global Resource Public Key Infrastructure, enabling
   verification of BGPsec messages.  This document describes two methods
   of generating the public-private key-pairs: router-driven and
   operator-driven.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-04
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rtr-keying-04


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 Feb 27 17:51:01 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769FE130ECE for ; Wed, 27 Feb 2019 17:50:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 mwIto8Y4rOkD for ; Wed, 27 Feb 2019 17:50:17 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A350A1277D2 for ; Wed, 27 Feb 2019 17:50:17 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id p25so21782594qtb.3 for ; Wed, 27 Feb 2019 17:50:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:date:references:cc:to:message-id; bh=HJg0CjGl3gYiIFtOpYHATfdW8oOAjBE5S1lZIWo53hc=; b=mh2ExW4JoyudItGhB2UMDVc8ZEQJsN9ScLI/aOCJASAwlzWxxpSm01fUCsn3yR9s6p 7TXjKGYoqpZSDStHYYjqzYGCm55/R8N9JVF3gAGtDz4elS49rHEkdBry0jXghc+jnGLz mXAlUri/uFLJIHkom3rfKm1aSSrWkjsEgeRf4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=HJg0CjGl3gYiIFtOpYHATfdW8oOAjBE5S1lZIWo53hc=; b=qowRQvhZB1Rnh1+qrfhR4eiW8zZGmzH9WVLcAz1rKcg0dGlgCz746qD7mRAq0znXjY kZT0g7wSd55XVrvL4QnuFMHBgmnVl/+NrvZEUxjy+JTWSreC5gU+SmwKLs76xeT2gNXW we+MxrRUVQT6MdIHpabqEYXVJ3xyTTFvo/m9ymKpgGOqz7WvY/8W+TQB2ZcR3CZfcbzE 7ctCw/e9e3Id1mAiVPv4N9M0mTGd54bdUt3B8WFJuqNRsjRN6BjC8Mlqi59yYgZ8w4To Cx83VCqJHSIlzwMsuJBX8T/72So7YjVO2C7VF+0JSkv2eWSvfR2mG0gXVm4DNG3kamBA tY6w==
X-Gm-Message-State: APjAAAVGojPzvJvhaQWzPApBaWTsuQjDSeXLsToiex7cQkQyGIOxx4df JjvrrfligQuFSsPz2k3c+voY9WZlMU/NVQ==
X-Google-Smtp-Source: APXvYqxI0bfLVMYbouJMqfpR2tik2H2o3ysudxEvlWmQigGAgNqs5WHCaSdLtkJdJlhZMXc19OBqww==
X-Received: by 2002:a0c:ad67:: with SMTP id v36mr4466684qvc.5.1551318616763; Wed, 27 Feb 2019 17:50:16 -0800 (PST)
Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id u31sm12438690qth.15.2019.02.27.17.50.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 17:50:15 -0800 (PST)
From: Sean Turner 
Content-Type: multipart/alternative; boundary="Apple-Mail=_80C89661-FC11-44DC-9B1B-501DF7B96992"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 27 Feb 2019 20:50:15 -0500
References: <155131847773.13970.13636266071128872194@ietfa.amsl.com>
Cc: draft-ietf-sidrops-rtr-keying.all@ietf.org, SIDR Operations WG 
To: The IESG 
Message-Id: <429B802D-C8A3-4F42-98C3-388C4C478B81@sn3rd.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: [Sidrops] Fwd:  I-D Action: draft-ietf-sidrops-rtr-keying-04.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 01:50:20 -0000

--Apple-Mail=_80C89661-FC11-44DC-9B1B-501DF7B96992
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I really hope this version addresses the concerns raised during IESG =
evaluation.

spt

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-04.txt
> Date: February 27, 2019 at 20:47:57 EST
> To: 
> Cc: sidrops@ietf.org
> Reply-To: sidrops@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the SIDR Operations WG of the IETF.
>=20
>        Title           : Router Keying for BGPsec
>        Authors         : Randy Bush
>                          Sean Turner
>                          Keyur Patel
> 	Filename        : draft-ietf-sidrops-rtr-keying-04.txt
> 	Pages           : 19
> 	Date            : 2019-02-27
>=20
> Abstract:
>   BGPsec-speaking routers are provisioned with private keys in order =
to
>   sign BGPsec announcements.  The corresponding public keys are
>   published in the global Resource Public Key Infrastructure, enabling
>   verification of BGPsec messages.  This document describes two =
methods
>   of generating the public-private key-pairs: router-driven and
>   operator-driven.
>=20
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-04
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-04
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rtr-keying-04
>=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
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops


--Apple-Mail=_80C89661-FC11-44DC-9B1B-501DF7B96992
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I =
really hope this version addresses the concerns raised during IESG =
evaluation.

spt

Begin forwarded message:

From: =
internet-drafts@ietf.org
Subject: =
[Sidrops] I-D =
Action: draft-ietf-sidrops-rtr-keying-04.txt
Date: =
February 27, 2019 at 20:47:57 =
EST
To: =
<i-d-announce@ietf.org>
Cc: sidrops@ietf.org
Reply-To: =
sidrops@ietf.org

A New Internet-Draft is available from the on-line =
Internet-Drafts directories.
This draft is a work item of =
the SIDR Operations WG of the IETF.

 =
       Title =
          : Router =
Keying for BGPsec
 =
       Authors =
        : Randy Bush
 =
            &n=
bsp;           &nbs=
p;Sean Turner
 =
            &n=
bsp;           &nbs=
p;Keyur Patel
	Filename =
       : =
draft-ietf-sidrops-rtr-keying-04.txt
	Pages =
          : 19
	=
Date =
           : =
2019-02-27

Abstract:
 =
  BGPsec-speaking routers are provisioned with private keys in =
order to
   sign BGPsec announcements.  The =
corresponding public keys are
   published in =
the global Resource Public Key Infrastructure, enabling
 =
  verification of BGPsec messages.  This document =
describes two methods
   of generating the =
public-private key-pairs: router-driven and
 =
  operator-driven.



The IETF datatracker status page for this =
draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/=


There are also htmlized versions =
available at:
https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-04https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-ke=
ying-04

A diff from the previous version is =
available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rtr-keyi=
ng-04


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/

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

=

--Apple-Mail=_80C89661-FC11-44DC-9B1B-501DF7B96992--


From nobody Wed Feb 27 19:51:12 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F252130DC4 for ; Wed, 27 Feb 2019 19:51:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MyMlEUyL4bXs for ; Wed, 27 Feb 2019 19:51:08 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AF812EB11 for ; Wed, 27 Feb 2019 19:51:08 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gzCiv-0005pY-2v; Thu, 28 Feb 2019 03:51:05 +0000
Date: Wed, 27 Feb 2019 19:51:01 -0800
Message-ID: 
From: Randy Bush 
To: "Montgomery, Douglas (Fed)" 
Cc: Jeffrey Haas , "sidrops@ietf.org" , Russ Housley 
In-Reply-To: <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>  <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 03:51:11 -0000

> Which of your N hundred routers will you login to, to do the "show bgp
> rpki servers"?
> 
> We thought the one sending you "unverified" state would be a good clue.

except routers do not send each other the ROV markings.  and the n
hundred routers probably differ in policy, caches, ...

[ i objected to rfc 8097 in the wg and in ietf lc ]

randy


From nobody Wed Feb 27 19:58:48 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5834612EB11 for ; Wed, 27 Feb 2019 19:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cIjGuzmGH6VZ for ; Wed, 27 Feb 2019 19:58:44 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5870A1274D0 for ; Wed, 27 Feb 2019 19:58:44 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id e1so15558014iok.1 for ; Wed, 27 Feb 2019 19:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wo/xcYyj1EoUlOSL3JqUegijrLzGM7jxOB8XbabdEpQ=; b=O5zCR/8Dv/OAVC6rOO3nWi/PfAr3QXwrFyAIFA0pv22DIt1FkbykoBNe8bVJTLYMCv oilBWO16JTaOw5/uzw+A63K7PPe2apayY0V1vmT3qphxXMqBg3SGj1lRHCDcvqPgqwXF 392SoDqBn7cV05dIoaEgDwPCuJzXYsyzSwWOLZHkmnAYTOR1mAsIvX4933xM8bJVcKyc uC/9mtTOcET62ka1iVAq/16XLeCkBbCYzBtedG1/S3/7VXJIpXkBF6FqHTsY9ZbL85Kg Sjc6ISpsoXPbbNvVjBt6i/Px08Gr4kEy8X5H1mUiT/YWdzjJFKrja37CPjAGCLBZLWYi HUUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wo/xcYyj1EoUlOSL3JqUegijrLzGM7jxOB8XbabdEpQ=; b=dfk0IESuUSjIMA+ZxOhDVQewJug+RH58qiV3CfRR+efPJlHCiJlyYp5xjc0cZPStMT mlEqQGiGX/gcl82d94AUsgBN6MPA22rqcVMdkPBtgCtlitUI8etZ1sxvhWCkQ8MHqBhQ X1TuycrqnksL+MBj/9UHB/ttkuQ/80kJ2k/53v+t1RkPw7r7MYLkGkya2U6tAW3dDmMd wTUjMxkIXaVHfn6kI7NLhoJtguP5OJP1Hi1LP+EXNcI5Y6UbpcnfzkVQU/54cHHTQqS1 3pMBTaXGh7V//eNWtQtNjmOr6ANEIC5uF8iYz6/VdM7KX5rgWS+jCpriTrvPRpuwORcT PnuA==
X-Gm-Message-State: APjAAAXSN0Hk9wFOcTnvAqS9YZyDX0K9u2RfzvH9X9bgtiZq1EfMZRod z9TLpFM80pP565BGmmOdwz9sXezzOeGSWzEepLw=
X-Google-Smtp-Source: APXvYqy+J2UjPraUsfe8/QFuSq0J7HKQFuVykbze5WGvvyEqLjzppBO/1cTIYDT5SDB00nToN5EPSSKZhwtI+aLC7pc=
X-Received: by 2002:a6b:e514:: with SMTP id y20mr3690696ioc.235.1551326323056;  Wed, 27 Feb 2019 19:58:43 -0800 (PST)
MIME-Version: 1.0
References: <87bm2xt64y.wl%morrowc@ops-netman.net>
In-Reply-To: <87bm2xt64y.wl%morrowc@ops-netman.net>
From: Christopher Morrow 
Date: Wed, 27 Feb 2019 22:58:31 -0500
Message-ID: 
To: Chris Morrow 
Cc: SIDR Operations WG 
Content-Type: multipart/alternative; boundary="0000000000006aa9040582ec4eed"
Archived-At: 
Subject: Re: [Sidrops] So, about that meeting...
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 03:58:46 -0000

--0000000000006aa9040582ec4eed
Content-Type: text/plain; charset="UTF-8"

Hey! the secretariat came through for us :)
There's a 1hr slot, please send agenda items.

On Wed, Feb 27, 2019 at 1:53 PM Chris Morrow  wrote:

>
> Howdy SIDROPS folks,
>
> Likely you are dilligently reading the agenda published by the
> secretariat, and wondering: "Where is my fav group meeting this time?"
>
> I'm sad to say that as of right now we don't have a meeting slot, this is
> my oversight :( I had 'april meeting time' in my plan, and ... missed
> that the meeting is in march, whoops. I've asked the secretariat if
> there's still a 1hr slot somewhere we can slide in SIDROPS, but that's
> probably less likely to happen.
>
> So, for now no sidrops, hopefully an update of use in ~24hrs time.
>
> -chris
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>

--0000000000006aa9040582ec4eed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey! the secretariat came through for us :)
There'=
s a 1hr slot, please send agenda items.

On Wed, Feb 27, 2019 at 1:53 P=
M Chris Morrow <morrowc@ops-ne=
tman.net> wrote:


Howdy SIDROPS folks,



Likely you are dilligently reading the agenda published by the

secretariat, and wondering: "Where is my fav group meeting this time?&=
quot;



I'm sad to say that as of right now we don't have a meeting slot, t=
his is 

my oversight :( I had 'april meeting time' in my plan, and ... miss=
ed

that the meeting is in march, whoops. I've asked the secretariat if

there's still a 1hr slot somewhere we can slide in SIDROPS, but that=
9;s

probably less likely to happen.



So, for now no sidrops, hopefully an update of use in ~24hrs time.



-chris



_______________________________________________

Sidrops mailing list

Sidrops@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/sidrops




--0000000000006aa9040582ec4eed--


From nobody Thu Feb 28 08:15:12 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68482130EF1 for ; Thu, 28 Feb 2019 08:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 Oicbk5ViDQKb for ; Thu, 28 Feb 2019 08:15:09 -0800 (PST)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840127.outbound.protection.outlook.com [40.107.84.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDC2130ED8 for ; Thu, 28 Feb 2019 08:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hp+txydYDTNOzX+5+x289KlO86CwjMKKKMQIvcdZXnQ=; b=G98JyXbtTQA1C4KRWZVr/FvqqhSLGIVcqdaUppDX0GIU3BvXT57ZPztdeEp8uR8mAcYS6V9MDW6oq0AhFzJfS8xuQO2bWECT2kHL/ZIQCxH2y40pGg9ZGfLzwkpPVSgkciatgQp4jQA+Df7m0fKvo4yyZH2VdH6rwlGXfaPLr1A=
Received: from DM6PR09MB3244.namprd09.prod.outlook.com (20.178.3.144) by DM6PR09MB3242.namprd09.prod.outlook.com (20.178.3.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Thu, 28 Feb 2019 16:15:05 +0000
Received: from DM6PR09MB3244.namprd09.prod.outlook.com ([fe80::7804:8385:141:8a49]) by DM6PR09MB3244.namprd09.prod.outlook.com ([fe80::7804:8385:141:8a49%4]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 16:15:05 +0000
From: "Montgomery, Douglas (Fed)" 
To: Randy Bush 
CC: Jeffrey Haas , "sidrops@ietf.org" , Russ Housley 
Thread-Topic: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
Thread-Index: AQHUztKTbd7Dl9/bdEmNmyGXwzeBcaX0L5oAgAAE5gD//66+AIAAbPkA//+yAwCAAJHEgIAAfBEA
Date: Thu, 28 Feb 2019 16:15:04 +0000
Message-ID: <0319BBE5-1991-4513-8E20-7AD72E991074@nist.gov>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>  <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.17.0.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov; 
x-originating-ip: [108.31.110.38]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1c112148-6cf4-4da8-025d-08d69d97e661
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR09MB3242; 
x-ms-traffictypediagnostic: DM6PR09MB3242:
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtETTZQUjA5TUIzMjQyOzIzOklBcERDWE5KdUQ3T2JQVmRIOWFTbW9aajhs?= =?utf-8?B?bnNTYWdIb1g0ZUFLYVp0VTJxRCs4VnhMT1pRUisxdTdkVDRmdzJnSVIzTzVB?= =?utf-8?B?bWVXVTFGYUplSkxxOVpTT2pTU2Y0V0daL1Vjb0ErcTZMOEx2a1Fkd3NlWHdR?= =?utf-8?B?VUZVUWdWaW9TUUlZbk1oSmd1NVhYV3hSbXdtZ1J5QzZUcWoySkpKY292RDVW?= =?utf-8?B?RDY1dnBPMWxTOStnY3NScWlrclRxUk9oN2ZVL1NIbWVyeE9uZUs4UDVtenlk?= =?utf-8?B?am5hR1pNY0gyYkpYTWU4V0hIdS9IWFFVRkM1MURWd3JVNnN0eGpwOHpIWDBy?= =?utf-8?B?SzRxcGZuc0p1NGZwRzdLY1I0UXY2eXllQktwRW5KY1JMOVBkazB3UXdQdmlj?= =?utf-8?B?TlZnSWx6OVBGOEoyUExzbWR3TnAzektjV3NvK3FBNEVOS0gzVVdNRmJhN1lQ?= =?utf-8?B?RE9YcGQ0T0tERC82SkNFcDNKcEZaV251MGgvNmFCVVhhY1FmanVnR3Q5VmI1?= =?utf-8?B?K3ZCbWhwbFhFRi85eUY0d1dRZVdSN0lQTnNmL2NKMGV3NEYyMDc5VmphbE5x?= =?utf-8?B?RElGWXliZHI3Z2VqaFpxQy84M1NyOHFnMGRlYm84amJsbDMzTVFCV0ducU02?= =?utf-8?B?Qm5RTGJINFZNN3ZUSml6VjYxQmU4NGtnVHJVbFBZVWREVVpsbHJYem9idjBS?= =?utf-8?B?YkdIMWo0Zlo3TXBoaUdCVmxId3hPL3VmTkE5TDlpUFhUSmREZjA1NlVQZlVY?= =?utf-8?B?MTNidUVsMzNuRlFFcFJBeWJaQnNhUkFFZ056enhHVTdtWWZvaC9DNWJFVy9J?= =?utf-8?B?RzJDT3dXemN0STUwSDBDU1B6aDYyT1N5WG1BeDdLUXBldE5SdFROOHdqcVI0?= =?utf-8?B?cEJrcXBUdUdWdjQybGpCVVJmNzVlRHN4OEU1WVdHZTFQbFE3SHQ4QnlJR25m?= =?utf-8?B?UExYd29qNERvS2hMVnRiSzdnTWhxZjJUMjZoMDBPUUNwMno1aG1FQ0dvcGxB?= =?utf-8?B?Wkg3WkNXaDBmNkpoY203WkxWMW8weTF5RnJ4RnpRRDJVQ0M3SGI2THE5OGVP?= =?utf-8?B?d3l6OUx4azJNTVVNN2x5bXZZam05LzRmeElGUHV1Wktoa0tLT3Z5aVZwV3BE?= =?utf-8?B?aFhFWWRyanZOY1Q3RFBqRGhCTE52NjZVUVRGQk5IVnhtN2laZThEMjRQM3pL?= =?utf-8?B?cDFzU3FtMURMVzBSVUNhQWtYOTJta0F4UlRaQ1NXQVBwWFJqaW5zaGkrcllF?= =?utf-8?B?RkFSSnc1YXJnb0VGRStYMkVSdVliT20wZEpHRWtsMnJPTmRmSUxZK0dXRXVG?= =?utf-8?B?YmdkRExEYlorNlFiRWxWc2NVejhQK1ZCQ2tNQlFFTEhnd1hkOEJuVzU4VWgv?= =?utf-8?B?YlgyTmJ0ZHdWMjhlWXdpdktMMEk1OHh5RzE5L0NZV3VubzgxYUZETDdZdUdq?= =?utf-8?B?Y1NyUHczaGxOMmFmMUdpaEhhUGZwTFBreE1ndkVrUUdmdWZJTG9BRnQ0Um1F?= =?utf-8?B?Z2VJVFdDVGlCVjNpNmpRUmNzQkZ2OVBhOVllMXBaQWdoUWJoaEhCNVNScWVE?= =?utf-8?B?c0pXdDQwLy9JMmcyTUNqWi9nUWo4K0hzNExJNVdqNy9PQzJ4Y3drTlpvOUwr?= =?utf-8?B?Y3lnMlJsYlJKYlpRN2gxZW1tSFZtRFRJY1M4eTNVdFZiQ1JoUGlvdXZiZnl4?= =?utf-8?B?YnEzMzR5dHIzZGU5SXFQT0gvcE9MSnBVLzVEeW8zeGpmOGtROWNxeFJ3eHFF?= =?utf-8?B?UGRLbS9qeTBZL0t0aXpqdz09?=
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0962D394D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(136003)(396003)(376002)(199004)(189003)(66066001)(4744005)(5660300002)(305945005)(8936002)(71200400001)(83716004)(6916009)(71190400001)(7736002)(25786009)(86362001)(36756003)(82746002)(97736004)(68736007)(58126008)(486006)(6246003)(54906003)(316002)(99286004)(93886005)(3846002)(81166006)(81156014)(2616005)(6116002)(476003)(229853002)(6486002)(8676002)(11346002)(14454004)(446003)(106356001)(6512007)(53936002)(4326008)(33656002)(478600001)(102836004)(186003)(6506007)(26005)(6436002)(2906002)(105586002)(256004)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3242; H:DM6PR09MB3244.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: S9NQ+nh8kGJ8NsUcv3VJUll+e0VQM0A2hS+wdUoomoIpWw1pnvbeN8kO/Y/pjnKP/85k8vFZXG1gT/t/gOo1uLj9u3eKzM0sT52Tbvq20/ifPlojXr4oNEQb+OM2WYRuwB45S5pozLA56V+Jfc0XLA0z7NEHNXjQQtndYkDc4CAZ1vuK5Z3Vz7Cvj5Y59Ub0eDXr7sEBIIZjp92bWmKmaUL54KicYHISbjvod6WnO1BZQHnY2VuBg7ukZ8mOnuD912PkwIO4vsFeiZHfXD/glu1Js56wFx8Evwwd7ph3830dC5tESbEi7UV6b574ufFco8OpzjA+x9bZuX7lkIvj90pndNvD9x9u/APGrla0ca9yK8OECJgPQNbZMiT16WuBkYQVvCNaatG+9BiBmCZetLqoAV/J5O1B0IFwsr819f0=
Content-Type: text/plain; charset="utf-8"
Content-ID: <68F971101BB84049B75E5E945313563A@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c112148-6cf4-4da8-025d-08d69d97e661
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 16:15:04.8902 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3242
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 16:15:11 -0000

QXJlIHlvdSBzYXlpbmcgbm8gb25lIHVzZXMgdGhlIFJGQzgwOTcgZXh0ZW5kZWQgY29tbXVuaXR5
IGluIGlCR1A/DQoNCkNlcnRhaW5seSBpdCBpcyBub3Rld29ydGh5IHdoZW4gYW4gYXV0aG9yIG9i
amVjdHMgdG8gaGlzIG93biBzcGVjIGluIExDIC4uLiBhbHRob3VnaCBpdCBjYW4gYmUgYSBjb25m
dXNpbmcgc2lnbmFsLg0KDQpkb3VnbQ0KLS0gDQpEb3VnTSBhdCBOSVNUDQogDQoNCu+7v09uIDIv
MjcvMTksIDEwOjUxIFBNLCAiUmFuZHkgQnVzaCIgPHJhbmR5QHBzZy5jb20+IHdyb3RlOg0KDQog
ICAgPiBXaGljaCBvZiB5b3VyIE4gaHVuZHJlZCByb3V0ZXJzIHdpbGwgeW91IGxvZ2luIHRvLCB0
byBkbyB0aGUgInNob3cgYmdwDQogICAgPiBycGtpIHNlcnZlcnMiPw0KICAgID4gDQogICAgPiBX
ZSB0aG91Z2h0IHRoZSBvbmUgc2VuZGluZyB5b3UgInVudmVyaWZpZWQiIHN0YXRlIHdvdWxkIGJl
IGEgZ29vZCBjbHVlLg0KICAgIA0KICAgIGV4Y2VwdCByb3V0ZXJzIGRvIG5vdCBzZW5kIGVhY2gg
b3RoZXIgdGhlIFJPViBtYXJraW5ncy4gIGFuZCB0aGUgbg0KICAgIGh1bmRyZWQgcm91dGVycyBw
cm9iYWJseSBkaWZmZXIgaW4gcG9saWN5LCBjYWNoZXMsIC4uLg0KICAgIA0KICAgIFsgaSBvYmpl
Y3RlZCB0byByZmMgODA5NyBpbiB0aGUgd2cgYW5kIGluIGlldGYgbGMgXQ0KICAgIA0KICAgIHJh
bmR5DQogICAgDQoNCg==


From nobody Thu Feb 28 08:16:15 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49057130EF1; Thu, 28 Feb 2019 08:16:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 GiaCS3JrLM0u; Thu, 28 Feb 2019 08:16:08 -0800 (PST)
Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on072a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd00::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E70130EB4; Thu, 28 Feb 2019 08:16:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1;  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PUd+mD5t266JUR0flSzXjDAWTLJbFkcXvY75nLZhoqo=; b=y+BL4S6FW6ogFTzbcsew3dSEErPSz3T0KPwV61sA43PRXkNiQDw3153bNxCqV2lI3x0KEEpIgztZaDlFQVhgfS3QQje/2oyT9KQsZtxM+OK0TgRWnbqhNPvlcdX1oXaaWfikowbsPMGEX1V2q7/AQpds1I2hKxreuWJs+f4U3EU=
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2367.namprd09.prod.outlook.com (52.132.115.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Thu, 28 Feb 2019 16:16:06 +0000
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1643.019; Thu, 28 Feb 2019 16:16:06 +0000
From: "Sriram, Kotikalapudi (Fed)" 
To: Alexander Azimov 
CC: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" 
Thread-Topic: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification
Thread-Index: AdTPfU3OunYiYNKQQ16BjWmmsPxDng==
Date: Thu, 28 Feb 2019 16:16:06 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; 
x-originating-ip: [129.6.252.155]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 403f11a4-a7f0-40ae-5208-08d69d980ae4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2367; 
x-ms-traffictypediagnostic: SN6PR0901MB2367:
x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; SN6PR0901MB2367; 23:5qan8O+Czl/V5UBL7Vb1WTG8uNlYnx5skk7wVHX?= =?us-ascii?Q?Iv1qscXQBmbtLa8w1BthZ62IW9ZBppLlcdru17WwUw2Fth2H0sW1CtFAoASZ?= =?us-ascii?Q?vZchvMkT2FouxXDN5GYyydWk5rfc2nW8kdS0r/bviXuP8mkKun9dB4TN7kju?= =?us-ascii?Q?V75Uy/O8prtZbH8z/Xfc0wm+QFEj59Upb2VLkQhai/fD9dsMI/inX/uPX6bJ?= =?us-ascii?Q?5EqRPBwa1IUA74kpYmZfnNk1rwoWCJlRMQGlHNj50glJF2stvCxvQMld1fOC?= =?us-ascii?Q?ipZLoDm0DNFTjnbWi1oK5b6WYNwTVr8z/cqgZ4aO8qNF79Ryr6lvzKQc5txv?= =?us-ascii?Q?eAOXKAj4NjHY8AJT6EG6PVzEtyNRC/vXW8VPUfNi6bbTmUa5lvfW4cbV2Eup?= =?us-ascii?Q?X5KPJsIUB5mlzWKOrEmPtQAa3PcAvyHdo1m8y67mgmH4gZO9mgPQB0uCOJpA?= =?us-ascii?Q?rvy9cGqQghEOsp7uEsd1P2NhLFyUIapOXTrvXnMui0lV/RbsdL8OxUb7QhMx?= =?us-ascii?Q?K05Q6fHtbUppAjieZqchPbEKg5YwKtxxQDWxWPOav6rFaKA7KS+9HmrMbhTU?= =?us-ascii?Q?sdQJC7MddVCeUJ8noYM0nQAwVrT4HSw8XPnFWG3JKYx/70k10CCL8ELMDCWR?= =?us-ascii?Q?gjjJNmT29MI4UynqmVg6Eelmn1SDzsfcMT8Jkpg7Ti986r9wzFJhpVSVjqCr?= =?us-ascii?Q?ZIHuz3Co0IuOAbFeWLYO3FEUONQdon4h1KbkKa0OnzgWvnj8WCxj513pQ+Q0?= =?us-ascii?Q?Qx3n9KrXWjK12nFl48E02vWIJGyuKG5GP11XA6lh5BlUQqrZZiQBCCTn4eVQ?= =?us-ascii?Q?93EboULtl64cF9zqfd4tnaDHTwMG+fLH5h2RZRk5wToCJSyn8c63JSeJdtZi?= =?us-ascii?Q?MPLFOHE0Wm30gRMiQaeeWGo1VGoZxL5xblsaIFSwmkABV7ImcSxaybEXLBFf?= =?us-ascii?Q?F7FKxUpouDatmVFROwmkgOHub33373V2KcJvXv7vvje22TQHHadea6MxALkC?= =?us-ascii?Q?kDK3rWdGMamzCIOy2tIk0LbKrDfWC6wUwEx3+urh7EwpbYA0ntdScKpin+xn?= =?us-ascii?Q?0ckPovHtkgXKO12ERgm5ZGTP/1/AkIfBLjGMtFMLCgdJzzN63EfdDW3jktVE?= =?us-ascii?Q?ZNu31eIU3T4yRfqj7OdARhB9dHy6SmOifQj4dlZcVaTvWC8q2z636k1wmn88?= =?us-ascii?Q?CUjVDoTWuVdHIH4SEVuRn3MfHj8u4kwKjrCBv/A2O8ZPpfXKFTcqQbZPQrHE?= =?us-ascii?Q?pY+hf3HWT1IMo31RDQin4meIh1VvcipN6ZHGlsZxklYJP5y42nGGEWn7KdTV?= =?us-ascii?Q?TxfZ7hQ8o9FdWZUYbnmo+Z9f6GCl4eyi6jHhBgxMVVNjaSsGEHwFfi5558Zp?= =?us-ascii?Q?lckmtgxR/ac/YdcAfegFQDbcGaed+eEF2fRzXB0EATydUBS71?=
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0962D394D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(136003)(346002)(43544003)(199004)(189003)(53936002)(74316002)(7736002)(102836004)(5660300002)(15650500001)(8676002)(9326002)(6116002)(68736007)(476003)(81156014)(81166006)(486006)(26005)(8936002)(186003)(6916009)(97736004)(10710500007)(2906002)(66066001)(4326008)(71190400001)(71200400001)(25786009)(6506007)(86362001)(316002)(105586002)(229853002)(55016002)(14444005)(54906003)(2420400007)(256004)(106356001)(966005)(6436002)(6306002)(52536013)(478600001)(99286004)(6246003)(7696005)(33656002)(54896002)(9686003)(561944003)(790700001)(3846002)(14454004)(49910200004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2367; H:SN6PR0901MB2366.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: p98YTDRLJIG3la+SNb36Ss77QKOv1lU8xKRXk4UVTxekLPVL8dgRK7mdMrq+cI7iHJg4J3GP/QVPf6TGMrKK2TKcOx1oYVphyKFK7ZiUEqQ95mBSIQ52wTRPq+RuWyLewOJUPYmWbkNFaDXuf6S2Y9x8Am3VNUmOeHzxgx9bANJ3lpd12oqUXh0kA5OwFytvTRFEotpYcLckDfBdiu9Nh2MbewUrJZP4Qu3ZJwenouOr0VBwXxjrCSawc0qd6kUcfLTEFXRuYKZZDUR+DUnGleLR7sFYCr4BM9tBBZe1qhGofxlcfvTdZ1BpHlLVCqNLGeKzddFEH2ME1HMZd6wxiqt5aSVKfIfsrKanJSVOrSyPLZ2GTJZHON3zaplCKSPz+SAt8FyHWHyWcKl+hu+jdFvg+X+gAiHpb8zTuplE0aE=
Content-Type: multipart/alternative; boundary="_000_SN6PR0901MB236620AD0F6209170C9BD9A384750SN6PR0901MB2366_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 403f11a4-a7f0-40ae-5208-08d69d980ae4
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 16:16:06.1958 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR0901MB2367
Archived-At: 
Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 16:16:13 -0000

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

Hi Alex,
I'll be happy to support but can you please take care of comment #1
prior to completion of the adoption call.
And while you are at it, comment #6 would be also easy to incorporate.
They should take no more than 10 minutes in all.
My other comments are important as well, but they only need discussion for =
now.

Comment #1:
I would strongly suggest deletion of the last two sentences of
the second paragraph in the Intro section.
You talk about downgrade attacks with BGPsec there.
The two sentences in question are inconsistent with how
incremental deployment of BGPsec really works.
Please read RFC 8205 Section 7.9 -- the idea of contiguous BGPsec ASes.
Regarding your attacker downgrading BGPsec comments,
John Scudder also suggested to you in IETF 102,
"It is not necessary to make that extreme claim for your proposal,
if I were you, I wouldn't."  See video at ~48 minute mark:
https://www.youtube.com/watch?v=3DLnXLB_MlpAs

Comment #2: Improvement of the algorithm for detection
Consider this topology example:

         AS3              AS5
         /       \        /
    AS2         AS4
   /
AS1

The peering relations are C2P going up and P2C going down (in the pic).
AS1, AS2 and AS4 have created ASPAs. AS3 has not created ASPA.
Let us say AS4 accidentally leaks to AS5 the route received from AS3.
The route's AS_PATH is AS4 AS3 AS2 AS1.
I think your algorithm (section 5) would fail to detect the leak.
But I would suggest a modified algorithm which is as follows:
At AS5, when it sees that AS3 does not have ASPA, it then considers
the ASPA of the next more recent AS in the path which is AS4 here.
>From AS4's ASPA, AS5 determines that AS3 is a provider of AS4,
and hence successfully detects that the update is a route leak.
So, I think the algorithm in section 5 needs to be modified per suggestion =
above.

Comment #3:
In the figure below, AS1 originates p1 and AS2 originates p2.
AS1 is a provider of AS2 for p1 and AS1 is a customer of AS2 for p2.
AS1 announces p1 to AS2 as P2C. AS2 announces p2 to AS1 as P2C.
AS3 is provider of AS2.

                   ---------P2C------->
                           p1 AS1 --->                                     =
 -----p1 AS2 AS1--->
AS1------------------(hybrid/complex)----------AS2---------- C2P ----------=
->AS3
                         <--- p2 AS2
                   <---------P2C-------
AS1 creates an ASPA: {AS1, AS2, IPv4}
AS2 creates an ASPA: {AS2, AS1, IPv4}

Now consider AS2 leaks route for p1 to AS3. Then AS3 is unable to detect th=
e leak.
AS3 looks at the ASPA: {AS1, AS2, IPv4} and determines that AS1 is a custom=
er of AS2,
and hence determines incorrectly that the Update: p1 AS2 AS1 is not a leak.
The ASPA scheme fails to work in this case for leak detection.
This is a limitation of the ASPA scheme because ASPAs are per AFI and not p=
er prefix.

Comment #4: Not all malicious leaks / hijacks are detected
In the topology below, AS2 leaks the path it learned from its peer AS4 to
its provider AS3 with path modification to avoid route leak detection,
or one may think of it as a hijack with feasible path insertion.
In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is
illegitimate but defies detection despite all ASes participating in ASPA.

         AS3                                                             AS=
5
              \  p1 AS2 AS1                                     /
                \ p2 AS2 AS1                                 /
                   \                                                 /
                     \         <----p2 AS4 AS1--    /
                       AS2 -------p2p----------AS4
                          \                             /
                             \ p1 AS1          /p2 AS1
                                 \               /
                                     AS1
                                   (p1, p2)

Comment #5: Path verification vs. path feasibility
Based on the above examples, in the draft, perhaps it is better to say
that the path is assessed feasible rather than say that the path is verifie=
d.

Comment #6:
In paragraph #1 in the Intro section, [I-D.ymbk-idr-bgp-eotr-policy] is ref=
erenced.
Based on WG consensus, we merged [I-D.ymbk-idr-bgp-eotr-policy] and
[I-D.idr-route-leak-detection-mitigation] and the latter is the WG document
that we are working on together since April 2018.
So, [I-D.idr-route-leak-detection-mitigation] is the more appropriate
document to cite for the ongoing WG effort.

Thanks.
Sriram

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











Hi Alex,


I’ll be happy to support but can you please ta=
ke care of comment #1



prior to completion of the adoption call. 


And while you are at it, comment #6 would be also ea=
sy to incorporate.


They should take no more than 10 minutes in all. 


My other comments are important as well, but they on=
ly need discussion for now.


 


Comment #1: 


I would strongly suggest deletion of the last two se=
ntences of



the second paragraph in the Intro section.


You talk about downgrade attacks with BGPsec there.<=
o:p>


The two sentences in question are inconsistent with =
how 



incremental deployment of BGPsec really works.<=
/o:p>


Please read RFC 8205 Section 7.9 -- the idea of cont=
iguous BGPsec ASes.


Regarding your attacker downgrading BGPsec comments,=
 


John Scudder also suggested to you in IETF 102, 


“It is not necessary to make that extreme clai=
m for your proposal,



if I were you, I wouldn’t.”  See vi=
deo at ~48 minute mark:


https://www.youtube.com/watch?v=3DLnXLB_MlpAs


 


Comment #2: Improvement of the algorithm for detecti=
on 



Consider this topology example:


 


         AS3=
            &nb=
sp; AS5


         /&n=
bsp;      \      &nb=
sp; /


    AS2     =
    AS4 


   /


AS1  


 


The peering relations are C2P going up and P2C going=
 down (in the pic).


AS1, AS2 and AS4 have created ASPAs. AS3 has not cre=
ated ASPA.


Let us say AS4 accidentally leaks to AS5 the route r=
eceived from AS3.


The route’s AS_PATH is AS4 AS3 AS2 AS1.


I think your algorithm (section 5) would fail to det=
ect the leak.


But I would suggest a modified algorithm which is as=
 follows:


At AS5, when it sees that AS3 does not have ASPA, it=
 then considers



the ASPA of the next more recent AS in the path whic=
h is AS4 here.



From AS4’s ASPA, AS5 determines that AS3 is a =
provider of AS4,


and hence successfully detects that the update is a =
route leak.


So, I think the algorithm in section 5 needs to be m=
odified per suggestion above.


 


Comment #3:


In the figure below, AS1 originates p1 and AS2 origi=
nates p2.


AS1 is a provider of AS2 for p1 and AS1 is a custome=
r of AS2 for p2.


AS1 announces p1 to AS2 as P2C. AS2 announces p2 to =
AS1 as P2C.


AS3 is provider of AS2.


 


        &nbs=
p;          ---------P2C------=
->


        &nbs=
p;             =
     p1 AS1 --->     &=
nbsp;           &nbs=
p;            &=
nbsp;       -----p1 AS2 AS1--->  =
;            



AS1------------------(hybrid/complex)----------AS2--=
-------- C2P ----------->AS3


        &nbs=
p;            &=
nbsp;   <--- p2 AS2


        &nbs=
p;          <---------P2C--=
-----


AS1 creates an ASPA: {AS1, AS2, IPv4}


AS2 creates an ASPA: {AS2, AS1, IPv4}


 


Now consider AS2 leaks route for p1 to AS3. Then AS3=
 is unable to detect the leak.


AS3 looks at the ASPA: {AS1, AS2, IPv4} and determin=
es that AS1 is a customer of AS2,


and hence determines incorrectly that the Update: p1=
 AS2 AS1 is not a leak.


The ASPA scheme fails to work in this case for leak =
detection.



This is a limitation of the ASPA scheme because ASPA=
s are per AFI and not per prefix.


 


Comment #4: Not all malicious leaks / hijacks are de=
tected


In the topology below, AS2 leaks the path it learned=
 from its peer AS4 to



its provider AS3 with path modification to avoid rou=
te leak detection,


or one may think of it as a hijack with feasible pat=
h insertion.  



In either case, the Update: p2 AS2 AS1 from AS2 to A=
S3 is 



illegitimate but defies detection despite all ASes p=
articipating in ASPA.   



 


         AS3=
            &nb=
sp;            =
            &nb=
sp;            =
           AS5=



        &nbs=
p;     \  p1 AS2 AS1     =
            &nb=
sp;            =
       /


         &nb=
sp;      \ p2 AS2 AS1    =
            &nb=
sp;            =
    /


        &nbs=
p;          \   =
;            &n=
bsp;            =
;            &n=
bsp;        /


        &nbs=
p;            \ =
;        <----p2 AS4 AS1--  =
;  /


        &nbs=
p;            &=
nbsp; AS2 -------p2p----------AS4 


        &nbs=
p;            &=
nbsp;    \       &nb=
sp;            =
         /


        &nbs=
p;            &=
nbsp;       \ p1 AS1    &=
nbsp;     /p2 AS1


        &nbs=
p;            &=
nbsp;           \ &n=
bsp;            =
; /


        &nbs=
p;            &=
nbsp;           &nbs=
p;   AS1


        &nbs=
p;            &=
nbsp;           &nbs=
p; (p1, p2)  


 


Comment #5: Path verification vs. path feasibility


Based on the above examples, in the draft, perhaps i=
t is better to say



that the path is assessed feasible rather than say t=
hat the path is verified.



 


Comment #6: 


In paragraph #1 in the Intro section, [I-D.ymbk-idr-=
bgp-eotr-policy] is referenced.


Based on WG consensus, we merged [I-D.ymbk-idr-bgp-e=
otr-policy] and



[I-D.idr-route-leak-detection-mitigation] and the la=
tter is the WG document


that we are working on together since April 2018.


So, [I-D.idr-route-leak-detection-mitigation] is the=
 more appropriate



document to cite for the ongoing WG effort.


 


Thanks.


Sriram   






--_000_SN6PR0901MB236620AD0F6209170C9BD9A384750SN6PR0901MB2366_--


From nobody Thu Feb 28 08:55:50 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73F4130E71 for ; Thu, 28 Feb 2019 08:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2ngrO6DKt_wt for ; Thu, 28 Feb 2019 08:55:46 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F71D1200B3 for ; Thu, 28 Feb 2019 08:55:46 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gzOyE-00021b-W8; Thu, 28 Feb 2019 16:55:43 +0000
Date: Thu, 28 Feb 2019 08:55:42 -0800
Message-ID: 
From: Randy Bush 
To: "Montgomery, Douglas (Fed)" 
Cc: sidrops@ietf.org
In-Reply-To: <0319BBE5-1991-4513-8E20-7AD72E991074@nist.gov>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>  <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>  <0319BBE5-1991-4513-8E20-7AD72E991074@nist.gov>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 16:55:48 -0000

> Are you saying no one uses the RFC8097 extended community in iBGP?

not to my knowledge.  see rfc 8481

i am proposing to use that extended community, or something analogous in
draft-ymbk-sidrops-ov-signal-02.txt.  but finer granularity of NotFound
is not desired there either.

> Certainly it is noteworthy when an author objects to his own spec in
> LC ... although it can be a confusing signal.

i have done it twice.  friends begged me to sign it; so i did.  did not
mean i liked it.

randy


From nobody Thu Feb 28 09:53:24 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1015C130F5B; Thu, 28 Feb 2019 09:53:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CGHPed6rI9hM; Thu, 28 Feb 2019 09:53:20 -0800 (PST)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEDA130E9F; Thu, 28 Feb 2019 09:53:20 -0800 (PST)
Received: by mail-oi1-x22e.google.com with SMTP id s16so17192383oih.9; Thu, 28 Feb 2019 09:53:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eMeSzkVDaIXTEaQgsbmFd1YXxjzTEvNgcVLZobFk30U=; b=IaIu1EZMgw8JzxeOk2isYrhToAh8dhhFYgM4QELFxovTSsvnw1sqRUnnLdN7p+P+SG 2HUqwcQm3JWJ5pwAb48/T7k57daxOYgC+ZLNraOInKzuJDlPFAnzPrSXVME9qeBsilYK 8EKoc0WWrwp2kH55iavOU7EgsPF+1dRmPXewYV9ZtJCrN2Ej0X1wwNaNFdQYtouqXJF6 ED3aR1m4gfJhQFxOhSFUkoMGbI96brq27Exq1WUY6DRdmSQ3+y2zlmvQDTbXOgUL0gkS EQdWaI6kTDzo4TqV3uRJsUSzZRXxWycQC1gBzXwLUwSrBe2DJEr16afVzeKSt5DlFpJB AzmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eMeSzkVDaIXTEaQgsbmFd1YXxjzTEvNgcVLZobFk30U=; b=kz4oYBPa7/Uxovq/gDXUAzvRzxUIG+T07U9hvvQVYQ8OpzeLFys/0pjsQImJupeNz+ UFa8DtVIEohnqZlmLSXE9qD4qpUxhRPZuPdfViCv4o0zhIX3NIEwTJOWyKeloEvRyIfg P+/bFrCbgOqgPABQBLFPGrzY4CKSgN57mF9xJ41/IygCbr5pmWx4yNKOSZHVyd/DMgbf 3G8c59CbT18ldGJl/pwc91SBsLouVN9WVDk80jC0ROCa27Uxn02dofKxZOn3G8zV0Vyq 9kZEJ1Uo02/K+GAv3reauAM0cjp/872LVl6lLS9MqmRxvUD00mxDE+tCcCdfQjWC2rky jMjA==
X-Gm-Message-State: APjAAAX/LgSa1KKGMDVVziOkRTzYd9ZoxY6U2ADBIATMC0Fi+9KqEqDw yBH/PTnLIW7UI1MNatm+Ykpp24Brk9bC7sfGpg9WTnbt
X-Google-Smtp-Source: APXvYqwGGUvofUqWZjRAsORXLxLLGcDtZgMPeK8tIqC/D4FkW8G5lemLv3+8fWD4fh9ppmReh9yg9IfZ9eASBN4Iih4=
X-Received: by 2002:aca:c38a:: with SMTP id t132mr595984oif.139.1551376399379;  Thu, 28 Feb 2019 09:53:19 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Alexander Azimov 
Date: Thu, 28 Feb 2019 20:53:07 +0300
Message-ID: 
To: "Sriram, Kotikalapudi (Fed)" 
Cc: "sidrops-chairs@ietf.org" , "sidrops@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000032b2530582f7f7c2"
Archived-At: 
Subject: Re: [Sidrops] WG Adoption call draft-azimov-sidrops-aspa-verification
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 17:53:23 -0000

--00000000000032b2530582f7f7c2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sriram,

I'm glad to see your comments! Please see my answers below.

Comment #1:
>
> I would strongly suggest deletion of the last two sentences of
>
> the second paragraph in the Intro section.
>
> You talk about downgrade attacks with BGPsec there.
>
> The two sentences in question are inconsistent with how
>
> incremental deployment of BGPsec really works.
>
> Please read RFC 8205 Section 7.9 -- the idea of contiguous BGPsec ASes.
>
> Regarding your attacker downgrading BGPsec comments,
>
> John Scudder also suggested to you in IETF 102,
>
> =E2=80=9CIt is not necessary to make that extreme claim for your proposal=
,
>
> if I were you, I wouldn=E2=80=99t.=E2=80=9D  See video at ~48 minute mark=
:
>
> https://www.youtube.com/watch?v=3DLnXLB_MlpAs
>
Can you please clarify to me next scenario with three ISPs:

   - Victim advertises /23 to Upstream, does use BGPSec, has ROA record
   with maxlength 24
   - Upstream, does use BGPSec
   - Attacker, advertises /24 that belongs to Upstream, adds its ASN in the
   beginning of ASPath, doesn't use BGPSec

Will Upsream, according to RFC8205, accept hijacked route from Attacker?
Anyway, I'm open for discussion about proper wording here.


> Comment #2: Improvement of the algorithm for detection
>
> Consider this topology example:
>
>
>
>          AS3              AS5
>
>          /       \        /
>
>     AS2         AS4
>
>    /
>
> AS1
>
>
>
> The peering relations are C2P going up and P2C going down (in the pic).
>
> AS1, AS2 and AS4 have created ASPAs. AS3 has not created ASPA.
>
> Let us say AS4 accidentally leaks to AS5 the route received from AS3.
>
> The route=E2=80=99s AS_PATH is AS4 AS3 AS2 AS1.
>
> I think your algorithm (section 5) would fail to detect the leak.
>
> But I would suggest a modified algorithm which is as follows:
>
> At AS5, when it sees that AS3 does not have ASPA, it then considers
>
> the ASPA of the next more recent AS in the path which is AS4 here.
>
> From AS4=E2=80=99s ASPA, AS5 determines that AS3 is a provider of AS4,
>
> and hence successfully detects that the update is a route leak.
>
> So, I think the algorithm in section 5 needs to be modified per suggestio=
n
> above.
>
This suggestion sounds great but it has an issue. Imagine that AS3 and AS4
have what is commonly named 'complex' relation. So they are both
customer-provider to one another. And in your scenario, where only AS4
creates ASPA it may result in rejection of valid routes, which will make
AS4 quite unhappy...


> Comment #3:
>
> In the figure below, AS1 originates p1 and AS2 originates p2.
>
> AS1 is a provider of AS2 for p1 and AS1 is a customer of AS2 for p2.
>
> AS1 announces p1 to AS2 as P2C. AS2 announces p2 to AS1 as P2C.
>
> AS3 is provider of AS2.
>
>
>
>                    ---------P2C------->
>
>                            p1 AS1
> --->                                      -----p1 AS2 AS1--->
>
> AS1------------------(hybrid/complex)----------AS2---------- C2P
> ----------->AS3
>
>                          <--- p2 AS2
>
>                    <---------P2C-------
>
> AS1 creates an ASPA: {AS1, AS2, IPv4}
>
> AS2 creates an ASPA: {AS2, AS1, IPv4}
>
>
>
> Now consider AS2 leaks route for p1 to AS3. Then AS3 is unable to detect
> the leak.
>
> AS3 looks at the ASPA: {AS1, AS2, IPv4} and determines that AS1 is a
> customer of AS2,
>
> and hence determines incorrectly that the Update: p1 AS2 AS1 is not a lea=
k.
>
> The ASPA scheme fails to work in this case for leak detection.
>
> This is a limitation of the ASPA scheme because ASPAs are per AFI and not
> per prefix.
>
Fully agreed. Simplicity comes with its own cost.
And that's why we still need community-based leak detection that can work
per-prefix. And it's our duty as-coauthors (and my debt, which I need to
admit) to finally push it forward.
I'm going to add an explicit statement in the next version of the draft.


> Comment #4: Not all malicious leaks / hijacks are detected
>
> In the topology below, AS2 leaks the path it learned from its peer AS4 to
>
> its provider AS3 with path modification to avoid route leak detection,
>
> or one may think of it as a hijack with feasible path insertion.
>
> In either case, the Update: p2 AS2 AS1 from AS2 to AS3 is
>
> illegitimate but defies detection despite all ASes participating in
> ASPA.
>
>
>
>          AS3
> AS5
>
>               \  p1 AS2 AS1                                     /
>
>                 \ p2 AS2 AS1                                 /
>
>                    \                                                 /
>
>                      \         <----p2 AS4 AS1--    /
>
>                        AS2 -------p2p----------AS4
>
>                           \                             /
>
>                              \ p1 AS1          /p2 AS1
>
>                                  \               /
>
>                                      AS1
>
>                                    (p1, p2)
>
>
>
Thinking about it as hijack adds simplicity to the picture. Customers may
still be hijacked by its direct or indirect providers. While it
significantly limits the attacker vector and highly unlikely to happen in
the real world, it must be clearly stated in the draft. Pushed to stack.

>
> Comment #5: Path verification vs. path feasibility
>
> Based on the above examples, in the draft, perhaps it is better to say
>
> that the path is assessed feasible rather than say that the path is
> verified.
>
I'm not a native speaker but for me 'feasibility' sounds a bit odd. I would
be glad to learn other opinions from the wg members. Anyway, this question
should not become a showstopper.

Comment #6:
>
> In paragraph #1 in the Intro section, [I-D.ymbk-idr-bgp-eotr-policy] is
> referenced.
>
> Based on WG consensus, we merged [I-D.ymbk-idr-bgp-eotr-policy] and
>
> [I-D.idr-route-leak-detection-mitigation] and the latter is the WG docume=
nt
>
> that we are working on together since April 2018.
>
> So, [I-D.idr-route-leak-detection-mitigation] is the more appropriate
>
> document to cite for the ongoing WG effort.
>
I don't think there was a need in such a detailed history of the question.
:)
Valid point. I'll change the link with the next update.


--=20
Best regards,
Alexander Azimov

--00000000000032b2530582f7f7c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sriram,

I'm glad to see your comments! Please see my an=
swers below.

Comment #1: 


I would strongly suggest deletion of the last two se=
ntences of



the second paragraph in the Intro section.


You talk about downgrade attacks with BGPsec there.<=
/p>

The two sentences in question are inconsistent with =
how=20



incremental deployment of BGPsec really works.


Please read RFC 8205 Section 7.9 -- the idea of cont=
iguous BGPsec ASes.


Regarding your attacker downgrading BGPsec comments,=
 


John Scudder also suggested to you in IETF 102, 


=E2=80=9CIt is not necessary to make that extreme cl=
aim for your proposal,



if I were you, I wouldn=E2=80=99t.=E2=80=9D=C2=A0 Se=
e video at ~48 minute mark:


https://www.youtube.com/watch?v=3DLnXLB_MlpAs
Can you please clarify to me next scenario =
with three ISPs: 
  • Victim advertises /23 to Upstream, =
does use BGPSec, has ROA record with maxlength 24
  • Upstream, doe=
s use BGPSec
  • Attacker, advertises /24 that belongs to Upstream, add=
s its ASN in the beginning of ASPath, doesn't use BGPSec
=
Will Upsream, according to RFC8205, accept hijacked route from Attacker?
Anyway, I'm open for discussion about proper wording here.
<=
/div>=C2=A0

Comment #2: Improvement of the algorithm fo=
r detection=20



Consider this topology example:


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AS3=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 AS5


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 /


=C2=A0=C2=A0=C2=A0 AS2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 AS4 


=C2=A0=C2=A0=C2=A0/


AS1=C2=A0 


=C2=A0


The peering relations are C2P going up and P2C going=
 down (in the pic).


AS1, AS2 and AS4 have created ASPAs. AS3 has not cre=
ated ASPA.


Let us say AS4 accidentally leaks to AS5 the route r=
eceived from AS3.


The route=E2=80=99s AS_PATH is AS4 AS3 AS2 AS1.


I think your algorithm (section 5) would fail to det=
ect the leak.


But I would suggest a modified algorithm which is as=
 follows:


At AS5, when it sees that AS3 does not have ASPA, it=
 then considers



the ASPA of the next more recent AS in the path whic=
h is AS4 here.



From AS4=E2=80=99s ASPA, AS5 determines that AS3 is =
a provider of AS4,


and hence successfully detects that the update is a =
route leak.


So, I think the algorithm in section 5 needs to be m=
odified per suggestion above.
This suggestion s=
ounds great but it has an issue. Imagine that AS3 and AS4 have what is comm=
only named 'complex' relation. So they are both customer-provider t=
o one another. And in your scenario, where only AS4 creates ASPA it may res=
ult in rejection of valid routes, which will make AS4 quite unhappy...
=
=C2=A0=C2=A0

Comment #3:


In the figure below, AS1 originates p1 and AS2 origi=
nates p2.


AS1 is a provider of AS2 for p1 and AS1 is a custome=
r of AS2 for p2.


AS1 announces p1 to AS2 as P2C. AS2 announces p2 to =
AS1 as P2C.


AS3 is provider of AS2.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ---------P2C-----=
-->


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0p1 AS1 --->=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -----p1 AS2 AS1--->=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0



AS1------------------(hybrid/complex)----------AS2--=
-------- C2P ----------->AS3


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 <--- p2 AS2


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <---------P2C-=
------


AS1 creates an ASPA: {AS1, AS2, IPv4}


AS2 creates an ASPA: {AS2, AS1, IPv4}


=C2=A0


Now consider AS2 leaks route for p1 to AS3. Then AS3=
 is unable to detect the leak.


AS3 looks at the ASPA: {AS1, AS2, IPv4} and determin=
es that AS1 is a customer of AS2,


and hence determines incorrectly that the Update: p1=
 AS2 AS1 is not a leak.


The ASPA scheme fails to work in this case for leak =
detection.



This is a limitation of the ASPA scheme because ASPA=
s are per AFI and not per prefix.
Fully agreed.=
 Simplicity comes with its own cost.
And that's why we still need co=
mmunity-based leak detection that can work per-prefix. And it's our dut=
y as-coauthors (and my debt, which I need to admit) to finally push it forw=
ard.
I'm going to add an explicit statement in the next version of=
 the draft.
=C2=A0

Comment #4: Not all ma=
licious leaks / hijacks are detected


In the topology below, AS2 leaks the path it learned=
 from its peer AS4 to



its provider AS3 with path modification to avoid rou=
te leak detection,


or one may think of it as a hijack with feasible pat=
h insertion.=C2=A0=C2=A0



In either case, the Update: p2 AS2 AS1 from AS2 to A=
S3 is=20



illegitimate but defies detection despite all ASes p=
articipating in ASPA.=C2=A0=C2=A0=C2=A0



=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AS3=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AS5


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0 p1 AS2 AS1=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /


=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0\ p2 AS2 AS1=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 /


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <----p2 AS4 AS1--=C2=A0=C2=
=A0=C2=A0 /


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 AS2 -------p2p----------AS4 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0\=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \ p1 AS1=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /p2 AS1


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 /


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 AS1


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 (p1, p2)=C2=A0 


=C2=A0
Thinking about it=
 as hijack adds simplicity to the picture. Customers may still be hijacked =
by its direct or indirect providers. While it significantly limits the atta=
cker vector and highly unlikely to happen in the real world, it must be cle=
arly stated in the draft. Pushed to stack.
=C2=A0


Comment #5: Path verification vs. path feasibility

Based on the above examples, in the draft, perhaps i=
t is better to say



that the path is assessed feasible rather than say t=
hat the path is verified.

I'm not a native speaker but for me 'f=
easibility' sounds a bit odd. I would be glad to learn other opinions f=
rom the wg members. Anyway, this question should not become a showstopper.<=
/div>
 



Comment #6: 


In paragraph #1 in the Intro section, [I-D.ymbk-idr-=
bgp-eotr-policy] is referenced.


Based on WG consensus, we merged [I-D.ymbk-idr-bgp-e=
otr-policy] and



[I-D.idr-route-leak-detection-mitigation] and the la=
tter is the WG document


that we are working on together since April 2018.=



So, [I-D.idr-route-leak-detection-mitigation] is the=
 more appropriate



document to cite for the ongoing WG effort.
I don't think there was a need in such a detailed h=
istory of the question. :)
Valid point. I'll change the link with th=
e next update.
=C2=A0

-- 
Bes=
t regards,
Alexander Azimov


--00000000000032b2530582f7f7c2--


From nobody Thu Feb 28 09:56:27 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE8B130EE9 for ; Thu, 28 Feb 2019 09:56:25 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qoHl8bAXoGFH for ; Thu, 28 Feb 2019 09:56:23 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D526D12F1AB for ; Thu, 28 Feb 2019 09:56:23 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id BC4731E2D8; Thu, 28 Feb 2019 12:55:31 -0500 (EST)
Date: Thu, 28 Feb 2019 12:55:31 -0500
From: Jeffrey Haas 
To: Randy Bush 
Cc: "Montgomery, Douglas (Fed)" , sidrops@ietf.org
Message-ID: <20190228175531.GB20319@pfrc.org>
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>  <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>  <0319BBE5-1991-4513-8E20-7AD72E991074@nist.gov> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 17:56:25 -0000

On Thu, Feb 28, 2019 at 08:55:42AM -0800, Randy Bush wrote:
> > Are you saying no one uses the RFC8097 extended community in iBGP?
> 
> not to my knowledge.  see rfc 8481

As I commented during the cloudflare RPKI event before NANOG: I tend to
notice something is getting attention and use because bugs are filed.

So, I have at least some contrary data points to your knowledge.

-- Jeff


From nobody Thu Feb 28 10:04:32 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10EC130EE9 for ; Thu, 28 Feb 2019 10:04:30 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 U6j3WvASGVdQ for ; Thu, 28 Feb 2019 10:04:29 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B5DC112F1AB for ; Thu, 28 Feb 2019 10:04:29 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id DDCCB1E2D8; Thu, 28 Feb 2019 13:03:37 -0500 (EST)
Date: Thu, 28 Feb 2019 13:03:37 -0500
From: Jeffrey Haas 
To: Nick Hilliard 
Cc: Randy Bush , Christopher Morrow , sidrops@ietf.org
Message-ID: <20190228180337.GC20319@pfrc.org>
References:   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 18:04:31 -0000

On Wed, Feb 27, 2019 at 04:28:27PM +0000, Nick Hilliard wrote:
> Maybe the authors could describe use cases?  I can't see any
> situation where this flag might be useful, but hey, other people
> have different requirements on their networks.

I'm not an author.  I had some opinions on the original extended community
that weren't exactly popular among the purists in SIDR.  A terse form of
those opinions follows:

Like all BGP features, OV will be incrementally deployed.
RPKI can tell you the useful bit of tri-state that is in the current RFC:
valid, invalid, unknown.
Carrying that state from a spot in your network that supports OV to parts
that don't may be useful, depending on your policy.
For some fault states (validator down, e.g.) carrying that state into the
network may similarly be useful.
Similarly, carrying state that OV has arrived at one state but you're taking
different action may be interesting.  This one overlaps things like more
specific routes carried between consenting providers that are not in the
global RPKI as valid.  Other mechanisms can address the issue as well.

End of the day, the tri-state is helpful, but provides the bare minimum of
operational coverage for carrying this stuff into your network.

At some point, OV can be pervasivel deployed such that these are less of an
issue.

-- Jeff


From nobody Thu Feb 28 10:09:03 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F55130F2D for ; Thu, 28 Feb 2019 10:09:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qHtCVA0mCfGY for ; Thu, 28 Feb 2019 10:08:59 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295BC130F26 for ; Thu, 28 Feb 2019 10:08:59 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1gzQ78-000GfJ-1H (job@us.ntt.net) for sidrops@ietf.org; Thu, 28 Feb 2019 18:08:58 +0000
Received: by mail-ot1-f48.google.com with SMTP id c18so18464779otl.13 for ; Thu, 28 Feb 2019 10:08:57 -0800 (PST)
X-Gm-Message-State: APjAAAXFULo/1Gr8YkA0siAye6FxKBwev4wHY31ETYqGR3OzjaNoGpcx f6c48764O3S/87iswxfmnCdt1k9gRFUpjWpANBE+Gw==
X-Google-Smtp-Source: APXvYqxmWhVDijOZhIpxtYt5dpiidlvLHg/pCLppaDHBaAxLfEV3vn4IG3G5uuFIseaaBa4lWbT9uCay9QvHuXM+6/g=
X-Received: by 2002:a9d:70cc:: with SMTP id w12mr648317otj.101.1551377337383;  Thu, 28 Feb 2019 10:08:57 -0800 (PST)
MIME-Version: 1.0
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>  <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>  <0319BBE5-1991-4513-8E20-7AD72E991074@nist.gov> 
In-Reply-To: 
From: Job Snijders 
Date: Fri, 1 Mar 2019 03:08:46 +0900
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Randy Bush 
Cc: "Montgomery, Douglas (Fed)" , sidrops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001b95b90582f82fd6"
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 18:09:01 -0000

--0000000000001b95b90582f82fd6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 1, 2019 at 1:55 Randy Bush  wrote:

> > Are you saying no one uses the RFC8097 extended community in iBGP?
>
> not to my knowledge.


I don=E2=80=99t use 8097 in traditional IBGP context, but I use 8097 quite =
a bit.
For instance to carry information to a looking glass web frontend, or to a
traffic analyzer (like pmacct), or to mark routes to aid debugging [1]

Could=E2=80=99ve used locally defined communities, but by using something d=
efined
by IETF I have one less thing to document.

Just my two cents.

Kind regards,

Job

[1] For instance, BIRD allows the operator to (sort of) modify Adj-RIB-In
and add/remove communities on routes which didn=E2=80=99t make it to the Lo=
c-RIB.

>

--0000000000001b95b90582f82fd6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, Mar 1, 2019 at 1:55 Randy Bush <randy@psg.com> wrote:
> Are you saying no one uses the RFC8097=
 extended community in iBGP?



not to my knowledge.=C2=A0

I don=E2=80=99t use 8097 in traditional IBGP context, but I use 8=
097 quite a bit. For instance to carry information to a looking glass web f=
rontend, or to a traffic analyzer (like pmacct), or to mark routes to aid d=
ebugging [1]

Could=E2=80=
=99ve used locally defined communities, but by using something defined by I=
ETF I have one less thing to document.

Just my two cents.

Kind regards,

=
Job

[1] For instance, BI=
RD allows the operator to (sort of) modify Adj-RIB-In and add/remove commun=
ities on routes which didn=E2=80=99t make it to the Loc-RIB.


--0000000000001b95b90582f82fd6--


From nobody Thu Feb 28 13:19:56 2019
Return-Path: 
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2F130FD4 for ; Thu, 28 Feb 2019 13:19:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 uOJfMiPphSIf for ; Thu, 28 Feb 2019 13:19:53 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0040130FCE for ; Thu, 28 Feb 2019 13:19:53 -0800 (PST)
X-Envelope-To: sidrops@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id x1SLJl4m047794 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2019 21:19:48 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
To: "Montgomery, Douglas (Fed)" 
Cc: Randy Bush , Jeffrey Haas , "sidrops@ietf.org" , Russ Housley 
References:   <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>  <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>
From: Nick Hilliard 
Message-ID: <628d257e-ccd4-906b-5e44-e1bde55f7a8c@foobar.org>
Date: Thu, 28 Feb 2019 21:19:46 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.10
MIME-Version: 1.0
In-Reply-To: <0B6FBEFD-DF57-4613-9B66-ED4A9E8302A2@nist.gov>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Feb 2019 21:19:55 -0000

Montgomery, Douglas (Fed) wrote on 28/02/2019 00:09:
> Which of your N hundred routers will you login to, to do the "show bgp rpki servers"?

All of them:

> % salt -G roles:rpkirouters net.cli 'show bgp rpki server summary' | grep -B 1 NONE
Nick