From nobody Wed Jul 5 11:50:35 2017 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 25003131DC7 for ; Wed, 5 Jul 2017 11:50:25 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 MaXcEGspC08z for ; Wed, 5 Jul 2017 11:50:22 -0700 (PDT) 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 64781131DC3 for ; Wed, 5 Jul 2017 11:50:21 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dSpNT-0005Wj-DN for sidrops@ietf.org; Wed, 05 Jul 2017 20:50:20 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-247.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dSpNT-0001FF-4z; Wed, 05 Jul 2017 20:50:19 +0200 From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Jul 2017 20:50:17 +0200 Message-Id: To: sidrops@ietf.org X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071984e774a77731946ad7d15a2a842f8f7d Archived-At: Subject: [Sidrops] Tree validation document - or rather RIPE NCC RPKI Validator 2.23 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 18:50:25 -0000 Dear working group, I asked for some agenda time to talk about the tree validation document: https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-00 Despite the rather generic title, this document is really an = informational description of how the RIPE NCC RPKI Validator 2.23 is = implemented. And as such Oleg and I would really like to call this = document done. We would like to publish this as an IETF document if = possible - to provide transparency - but if the process is too heavy = weight, then we can also just publish it with our code directly. We = would like to reach a decision on this after discussing in Prague, but = of course feel free to speak your mind before then :) Kind regards Tim Bruijnzeels= From nobody Wed Jul 5 13:07:18 2017 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 99781131A36 for ; Wed, 5 Jul 2017 13:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 v3H144hbRo8C for ; Wed, 5 Jul 2017 13:07:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 5898C131D88 for ; Wed, 5 Jul 2017 13:07:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dSqZt-0007cy-Ps; Wed, 05 Jul 2017 20:07:13 +0000 Date: Wed, 05 Jul 2017 22:07:12 +0200 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: sidrops@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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] Tree validation document - or rather RIPE NCC RPKI Validator 2.23 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 20:07:17 -0000 > Despite the rather generic title, this document is really an > informational description of how the RIPE NCC RPKI Validator 2.23 is > implemented. there is a long history of pubishing rfcs of the form how implements this is just another. so the wg chairs would just wglc it. if folk know you did not really implement it that way, then the document will need to be fixed. if folk think you should have implemented it differently, then you politely say thanks and we move along. ship this sucker. though, as you point out, the title could be more explicit. randy From nobody Mon Jul 10 05:28:41 2017 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 D2BA9131726 for ; Mon, 10 Jul 2017 05:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=zdns.cn 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 aD3CxpcAHiFN for ; Mon, 10 Jul 2017 05:28:37 -0700 (PDT) Received: from mail.zdns.cn (mail.knet.cn [202.173.10.13]) (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 A367E129ADA for ; Mon, 10 Jul 2017 05:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zdns.cn; s=dkim; x=1500294516; i=madi@zdns.cn; h=From:Content-Type: Mime-Version:Subject:Message-Id:References:To:Date; bh=gyATqzlj/ LnhG6Rm2aI4fYOUaXuGuFORmXwacDREhFA=; b=OsXURC3+M3MEg5hQSjNyHR6/u CeaU7yCTnh7LV7eCf3ByrWtSL5SfagYUlGs4ZY4oL1Pd8plmQMIqRsLeNb/yiIAp ll76SXyWOyUTkFzO40LPxTVjaRA/PXjemSsCTffQOADWwthDtBliHR1zkitVtE6+ iaWIXbsL+UvlBZ3CkA= X-TM-DID: 755f352abb0b02153bf05e6f6546140e From: Di Ma Content-Type: multipart/alternative; boundary="Apple-Mail=_A553A267-5EF0-439B-9A4F-AAA018934737" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <2D2D7E46-7CCF-4082-9FFD-4B7694CC9954@zdns.cn> References: <149857205931.15060.13252536700859949379.idtracker@ietfa.amsl.com> To: "sidrops@ietf.org" Date: Mon, 10 Jul 2017 20:28:31 +0800 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Sidrops] Fwd: New Version Notification for draft-madi-sidrops-rp-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 12:28:40 -0000 --Apple-Mail=_A553A267-5EF0-439B-9A4F-AAA018934737 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb2312 Hi, folks, Dr. Stephen Kent and I updated the draft about the requirements for RPKI = RP two weeks ago, expecting discussions in this WG. And I will be briefing this document in the coming SIDROPS meeting in = Prague. We would appreciate your comments. Thanks very much indeed. Di > =CF=C2=C3=E6=CA=C7=B1=BB=D7=AA=B7=A2=B5=C4=D3=CA=BC=FE=A3=BA >=20 > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org > =D6=F7=CC=E2: New Version Notification for = draft-madi-sidrops-rp-00.txt > =C8=D5=C6=DA: 2017=C4=EA6=D4=C227=C8=D5 GMT+8 22:00:59 > =CA=D5=BC=FE=C8=CB: "Di Ma" , "Stephen Kent" = >=20 >=20 > A new version of I-D, draft-madi-sidrops-rp-00.txt > has been successfully submitted by Di Ma and posted to the > IETF repository. >=20 > Name: draft-madi-sidrops-rp > Revision: 00 > Title: Requirements for Resource Public Key = Infrastructure (RPKI) Relying Parties > Document date: 2017-06-26 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-madi-sidrops-rp-00.txt > Status: = https://datatracker.ietf.org/doc/draft-madi-sidrops-rp/ > Htmlized: https://tools.ietf.org/html/draft-madi-sidrops-rp-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rp-00 >=20 >=20 > Abstract: > This document provides a single reference point for requirements for > Relying Party (RP) software for use in the Resource Public Key > Infrastructure (RPKI). It cites requirements that appear in several > RPKI RFCs, making it easier for implementers to become aware of = these > requirements that are segmented with orthogonal functionalities. >=20 >=20 >=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 > The IETF Secretariat >=20 --Apple-Mail=_A553A267-5EF0-439B-9A4F-AAA018934737 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb2312
Hi, folks,

Dr. Stephen Kent and I updated the draft about the = requirements for RPKI RP two weeks ago, expecting discussions in this = WG.

And I will = be briefing this document in the coming SIDROPS meeting in = Prague.

We = would appreciate your comments.

Thanks very much indeed.

Di


=CF=C2=C3=E6=CA=C7=B1=BB=D7=AA=B7=A2=B5=C4=D3=CA=BC=FE=A3=BA
=B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org
=D6=F7=CC=E2: = New Version = Notification for draft-madi-sidrops-rp-00.txt
=C8=D5=C6=DA= : 2017=C4=EA6=D4=C227=C8=D5 GMT+8 = 22:00:59
=CA=D5=BC=FE= =C8=CB: "Di Ma" <madi@zdns.cn>, "Stephen = Kent" <kent@alum.mit.edu>


A new version = of I-D, draft-madi-sidrops-rp-00.txt
has been successfully = submitted by Di Ma and posted to the
IETF repository.

Name: draft-madi-sidrops-rp
Revision: 00
Title: = Requirements for Resource Public Key Infrastructure (RPKI) = Relying Parties
Document date: 2017-06-26
Group:= = Individual Submission
Pages: 11
URL: =            https://www.ietf.org/internet-drafts/draft-madi-sidrops-rp-00.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-madi-sidrops-rp/
Htmlized:       https://tools.ietf.org/html/draft-madi-sidrops-rp-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rp-00<= /a>


Abstract:
=   This document provides a single reference point for = requirements for
  Relying Party (RP) software = for use in the Resource Public Key
=   Infrastructure (RPKI).  It cites requirements that = appear in several
  RPKI RFCs, making it easier = for implementers to become aware of these
=   requirements that are segmented with orthogonal = functionalities.




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.

The IETF = Secretariat


= --Apple-Mail=_A553A267-5EF0-439B-9A4F-AAA018934737-- From nobody Fri Jul 14 09:16:56 2017 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 249BE1287A0; Fri, 14 Jul 2017 09:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 PsMJBYu3mCSq; Fri, 14 Jul 2017 09:16:53 -0700 (PDT) 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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616801201F2; Fri, 14 Jul 2017 09:16:49 -0700 (PDT) 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 9854A3FEE3; Fri, 14 Jul 2017 16:16:48 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (pool-100-36-48-227.washdc.fios.verizon.net [100.36.48.227]) (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 812D5C39C137; Fri, 14 Jul 2017 16:16:48 +0000 (UTC) Date: Fri, 14 Jul 2017 12:16:47 -0400 Message-ID: From: Chris Morrow To: sidrops@ietf.org, sidrops-chairs@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] Meeting Materials X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 14 Jul 2017 16:16:55 -0000 Howdy SIDROps folks, if you are presenting (agenda -> https://tools.ietf.org/wg/sidrops/agenda) and the chairs don't have your slides by 9pm local (prague time) sunday (July 16) you may miss out on being able to present. Please email slides in PDF form (or you risk my conversion tooling!) to: sidrops-chairs@ietf.org thanks! -chris (co-chair) From nobody Sun Jul 16 12:44:50 2017 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 47275129AD1 for ; Sun, 16 Jul 2017 12:44:49 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 SrkM4yWUYL8Z for ; Sun, 16 Jul 2017 12:44:47 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 4F6E8127978 for ; Sun, 16 Jul 2017 12:44:47 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1dWpT9-000CIG-Ak; Sun, 16 Jul 2017 21:44:44 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-134.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1dWpT8-00075g-3k; Sun, 16 Jul 2017 21:44:42 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4FDCC3D-58F5-47A2-ADA3-91C18B155559" From: Oleg Muravskiy In-Reply-To: <2D2D7E46-7CCF-4082-9FFD-4B7694CC9954@zdns.cn> Date: Sun, 16 Jul 2017 21:44:41 +0200 Cc: "sidrops@ietf.org" Message-Id: References: <149857205931.15060.13252536700859949379.idtracker@ietfa.amsl.com> <2D2D7E46-7CCF-4082-9FFD-4B7694CC9954@zdns.cn> To: Di Ma X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b7437bf007a6e81329b254e35c062987a1b Archived-At: Subject: Re: [Sidrops] New Version Notification for draft-madi-sidrops-rp-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 19:44:49 -0000 --Apple-Mail=_C4FDCC3D-58F5-47A2-ADA3-91C18B155559 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Di and Stephen, > On 10 Jul 2017, at 14:28, Di Ma wrote: >=20 > Hi, folks, >=20 > Dr. Stephen Kent and I updated the draft about the requirements for = RPKI RP two weeks ago, expecting discussions in this WG. >=20 > And I will be briefing this document in the coming SIDROPS meeting in = Prague. >=20 > We would appreciate your comments. You may want to look at my comments on the previous version of this = document. Many of them have not been addressed in this version. Regards, Oleg > Thanks very much indeed. >=20 > Di >=20 >=20 >> =E4=B8=8B=E9=9D=A2=E6=98=AF=E8=A2=AB=E8=BD=AC=E5=8F=91=E7=9A=84=E9=82=AE= =E4=BB=B6=EF=BC=9A >>=20 >> =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = >> =E4=B8=BB=E9=A2=98: New Version Notification for = draft-madi-sidrops-rp-00.txt >> =E6=97=A5=E6=9C=9F: 2017=E5=B9=B46=E6=9C=8827=E6=97=A5 GMT+8 22:00:59 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: "Di Ma" >, "Stephen Kent" > >>=20 >>=20 >> A new version of I-D, draft-madi-sidrops-rp-00.txt >> has been successfully submitted by Di Ma and posted to the >> IETF repository. >>=20 >> Name: draft-madi-sidrops-rp >> Revision: 00 >> Title: Requirements for Resource Public Key = Infrastructure (RPKI) Relying Parties >> Document date: 2017-06-26 >> Group: Individual Submission >> Pages: 11 >> URL: = https://www.ietf.org/internet-drafts/draft-madi-sidrops-rp-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-madi-sidrops-rp/ = >> Htmlized: https://tools.ietf.org/html/draft-madi-sidrops-rp-00 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rp-00 = >>=20 >>=20 >> Abstract: >> This document provides a single reference point for requirements = for >> Relying Party (RP) software for use in the Resource Public Key >> Infrastructure (RPKI). It cites requirements that appear in = several >> RPKI RFCs, making it easier for implementers to become aware of = these >> requirements that are segmented with orthogonal functionalities. >>=20 >>=20 >>=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 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_C4FDCC3D-58F5-47A2-ADA3-91C18B155559 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Di and Stephen,

On = 10 Jul 2017, at 14:28, Di Ma <madi@zdns.cn> wrote:

Hi, folks,

Dr. Stephen Kent and I = updated the draft about the requirements for RPKI RP two weeks ago, = expecting discussions in this WG.

And I will be briefing this document in = the coming SIDROPS meeting in Prague.

We would appreciate your = comments.

You may want to look at my comments on the = previous version of this document.
Many of them have not been = addressed in this version.

Regards,
Oleg


Thanks very much = indeed.

Di

=

=E4=B8=8B=E9=9D=A2=E6=98=AF=E8=A2=AB=E8=BD=AC=E5=8F=91=E7=9A=84= =E9=82=AE=E4=BB=B6=EF=BC=9A

=E5=8F=91=E4=BB=B6=E4=BA=BA: = internet-drafts@ietf.org
=E4=B8=BB=E9=A2=98: New Version Notification for = draft-madi-sidrops-rp-00.txt
=E6=97=A5=E6=9C=9F: 2017=E5=B9=B46=E6=9C=8827=E6=97=A5 GMT+8 = 22:00:59
=E6=94=B6=E4=BB=B6=E4=BA=BA: = "Di Ma" <madi@zdns.cn>, "Stephen = Kent" <kent@alum.mit.edu>


A new version = of I-D, draft-madi-sidrops-rp-00.txt
has been successfully = submitted by Di Ma and posted to the
IETF repository.

Name: draft-madi-sidrops-rp
Revision: 00
Title: = Requirements for Resource Public Key Infrastructure (RPKI) = Relying Parties
Document date: 2017-06-26
Group:= = Individual Submission
Pages: 11
URL: =            https://www.ietf.org/internet-drafts/draft-madi-sidrops-rp-00.t= xt
Status: =         https://datatracker.ietf.org/doc/draft-madi-sidrops-rp/
Htmlized:       https://tools.ietf.org/html/draft-madi-sidrops-rp-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-madi-sidrops-rp-00<= /a>


Abstract:
=   This document provides a single reference point for = requirements for
  Relying Party (RP) software = for use in the Resource Public Key
=   Infrastructure (RPKI).  It cites requirements that = appear in several
  RPKI RFCs, making it easier = for implementers to become aware of these
=   requirements that are segmented with orthogonal = functionalities.




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.

The IETF = Secretariat


_____________________________________________= __
Sidrops mailing list
Sidrops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

= --Apple-Mail=_C4FDCC3D-58F5-47A2-ADA3-91C18B155559-- From nobody Sun Jul 16 14:43:23 2017 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 5C192126CB6; Sun, 16 Jul 2017 14:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 eRyUKp8EoTVM; Sun, 16 Jul 2017 14:43:13 -0700 (PDT) Received: from mr25p46im-ztdg02101301.me.com (mr25p46im-ztdg02101301.me.com [17.111.255.91]) (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 474AE126BF3; Sun, 16 Jul 2017 14:43:13 -0700 (PDT) Received: from process-dkim-sign-daemon.mr25p46im-ztdg02101301.me.com by mr25p46im-ztdg02101301.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OT700100DLF3L00@mr25p46im-ztdg02101301.me.com>; Sun, 16 Jul 2017 21:43:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1500241392; bh=MW5C8bUbbqtY5VWNqSQ6Bj2Tqyewpt9sg6PY1Zpbvtk=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=Sp4vtrfRLagvG6/r4meoh53DpNUhxuHXVM+H7/BHv4EmF+GlzqIXJtflsDDzVvl3y PBfgayMXGGXvoRXQboOk7lLTatw3ElOWQ7BA45lGOgqMZCVuNkqcbucVBS34rIlt6a d3ZSuFqEZUWtD4Er1sQVS4ai5+4n7yPxx+0Ran5qrNqXK0fG2VfQF8xW+9gI0smhCj dbFjgUqkG5deo94VEUG6CWUwuuo+Oca4B7jD/Q4hwHe/qqKHtqXWLoQQqAnl5eNqin T+A5gXN/EpeGIpwbqqDMdyMaKt3tlUKlhS71x6CT3lRSsJYJNBR3LZyfH/zjhTqlSv MygaS+ETbAy7g== Received: from icloud.com ([127.0.0.1]) by mr25p46im-ztdg02101301.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OT700O59DNVGY20@mr25p46im-ztdg02101301.me.com>; Sun, 16 Jul 2017 21:43:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-16_16:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1707160365 Content-type: text/plain; charset=gb2312 MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Di Ma In-reply-to: Date: Sun, 16 Jul 2017 23:43:06 +0200 Cc: IETF SIDR , sidrops@ietf.org, kent@alum.mit.edu, Declan Ma Content-transfer-encoding: quoted-printable Message-id: References: <20160412100344.32250.28492.idtracker@ietfa.amsl.com> To: Oleg Muravskiy X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Sidrops] [sidr] New Version Notification for draft-madi-sidr-rp-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 21:43:15 -0000 Oleg, Thanks very much for your comments. See my responses in lines.=20 > =D4=DA 2016=C4=EA7=D4=C213=C8=D5=A3=AC17:05=A3=ACOleg Muravskiy = =D0=B4=B5=C0=A3=BA >=20 > Hi Di, >=20 >> On 27 Apr 2016, at 03:46, Declan Ma wrote: >>=20 >> Hi, folks, >>=20 >> Steve Kent and I have generated this document to try to consolidate = RP requirements in one document, with pointers to all the relevant RFCs.=20= >=20 > I read the document, and I appreciate you putting it together, but I = can't say I support this effort. >=20 > As you state in Section 1: >=20 > The follow sections present requirements imposed on RPs as defined = in > the following RFCs: >=20 > RFC 6480 (RPKI Architecture) > RFC 6481 (Repository Structure) > RFC 6482 (ROA format) > RFC 6485 (Algorithms) > RFC 6486 (Manifests) > RFC 6487 (Certificate and CRL profile) > RFC 6488 (RPKI Signed Objects) > RFC 6489 (Key Rollover) > RFC 6810 (RPKI to Router Protocol) > RFC 6916 (Algorithm Agility) > RFC 7730 (Trust Anchor Locator) > RFC XXXX (Router Certificates) >=20 > This document will be update to reflect new or changed requirements > as these RFCs are updated, or new RFCs are written. >=20 > I agree that there are many documents that one has to consult on order = to make or verify an implementation of RPKI validation, but this = document will *add* to that number! >=20 > Once this document is out, someone will have to keep it up to date = (and not conflicting) with all those other documents. This could create = more problems than it could solve. >=20 > My following comments basically show why it is difficult to keep this = document in a state that would not create more problems. I understand your concerns but I do think this document deserves our = efforts.=20 It=A1=AFs not in state of art at present yet I hope it would be adopted = to move along with help from the WG.=20 >=20 >=20 >> As I mentioned in IETF 95 meeting, there is no standards language = (e.g., MUST, SHOULD, MAY, ...) in this doc, as it is just POINTING to = the docs that have the real requirements.=20 >=20 > Well, actually there is normative language: >=20 > 3.3. CRL Processing >=20 > The CRL processing requirements imposed on CAs and RP are described > in [RFC6487]. CRLs in the RPKI are tightly constrained; only the > AuthorityKeyIndetifier and CRLNumber extensions are allowed, and = they > MUST be present. No other CRL extensions are allowed, and no > ^^^^^^ > CRLEntry extensions are permitted. RPs are required to verify that > these constraints have been met. Each CRL in the RPI MUST be > ^^^^^^ > verified using the public key from the certificate of the CA that > issued the CRL. >=20 > And there are several other places where the normative language is not = used, but implied. Thanks for catching the typos.=20 We will change =A1=AEMUST=A1=AF into =A1=AEmust=A1=AF. As for the implication stuff, the text is just paraphrasing the = requirements from RFCs which I don=A1=AFt think is sort of = inappropriate.=20 >=20 >=20 >> This doc outlines the RP functions, summarizes them and then gives = reference to those precise sections or paragraphs, in order to make life = easier for implementers to make sure he/she has addressed all of these = requirements. >=20 > I have two comments for this paragraph. >=20 > First, it might seem appealing to create a document that will give a = "reference to those precise sections or paragraphs", so that the = implementer could skip reading those long RFCs in full. But I do not = think it is possible or advisable. Even in your draft you say: >=20 > An RP is required > to verify that a resource certificate adheres to the profile > established by [RFC6487]. This means that all extensions mandated = by > [RFC6487] must be present and value of each extension must be within > the range specified by this RFC. Moreover, any extension excluded = by > [RFC6487] must be omitted. >=20 > or >=20 > To determine whether a manifest is valid, the RP is required to > perform manifest-specific checks in addition to those specified in > [RFC6488]. >=20 > So very often it is more practical to refer to the whole RFCs, because = an implementer has to implement all of it, not just specific paragraphs. >=20 We are not suggesting that implementers skip reading those RFCs in full. This draft is born to be a guide to help implementers get the essentials = of RP functionalities scattered in different RFCs. Anyone who wants to = comprehend RPKI cannot be exempted from reading all the RPKI RFCs, let = alone the implementers. One might see the RP requirements document as a=A1=B0Manifest=A1=B1 for = all necessary RP functions.=20 >=20 > Second, what if, for whatever reason, this document will not list = *all* of the requirements? Will it be OK for the implementer to say "I = did everything specified there", or will (s)he be required to = double-check with other RFCs you refer to? Or even with those you do = not refer to? >=20 > I=A1=AFm not sure how to define the applicability of such document. This is document is intended to be Informational, which is going to help = implementers to find what they want. The tricky part is the your = concerns are of different granularity! This document tell readers an RP system is supposed to contain these = categories: --Fetching and Caching RPKI Repository Objects -- Processing Certificate and CRL --Processing RPKI Repository Signed Objects --Delivering Validated Cache Data to BGP Speakers But for whether an implementer did everything specified =A1=B0there=A1=B1,= they should double check =A1=B0there=A1=B1 which is specific paragraph = in the referenced RFCs.=20 Once again, we are not suggesting that implementers skip reading those = RFCs in full. IF they want to do double-check, they are encouraged to know the = breakdown of every categories in terms RP requirements.=20 >=20 >=20 >> Any comments and feedbacks are appreciated. >=20 > Here are my comments for some specific sections: >=20 > 3.1. Verifying Resource Certificate and Syntax >=20 > Certificates in the RPKI are called resource certificates, and they > are required to conform to the profile [RFC6487]. An RP is required > to verify that a resource certificate adheres to the profile > established by [RFC6487]. This means that all extensions mandated = by > [RFC6487] must be present and value of each extension must be within > the range specified by this RFC. Moreover, any extension excluded = by > [RFC6487] must be omitted. >=20 > I think you should not repeat the text of other RFCs, otherwise you = risk of being incomplete or going out of sync with referenced RFC. Good suggestion.=20 We authors will see how to address issues. And I would appreciate your help.=20 >=20 >=20 > 3.2. Certificate Path Validation >=20 > In the RPKI, issuer can only assign and/or allocate public INRs > belong to it, ... >=20 > I don=A1=AFt think assignment or allocation of INR happens in RPKI. Agreed. It should have been expressed like: In the RPKI, issuer can only = authorize the custodianship of public INR belonging to it, =A1=AD >=20 >=20 > 3.3. CRL Processing >=20 > The CRL processing requirements imposed on CAs and RP are described > in [RFC6487]. CRLs in the RPKI are tightly constrained; only the > AuthorityKeyIndetifier and CRLNumber extensions are allowed, and = they > MUST be present. No other CRL extensions are allowed, and no > CRLEntry extensions are permitted. RPs are required to verify that > these constraints have been met. Each CRL in the RPI MUST be > verified using the public key from the certificate of the CA that > issued the CRL. >=20 >=20 > Apart from using normative language mentioned above, you seem to = repeat the text of other RFC. > Is it the only bit of RFC6487 that is applicable to CRL processing in = RPKI validation? > Aren=A1=AFt any CRL validation (not only in RPKI) requires that CRL = must be verified using the public key of it's issuer? We will be considering adding text in terms of generalized CRL = specification. >=20 >=20 > 4.2.1. Manifest >=20 > To determine whether a manifest is valid, the RP is required to > perform manifest-specific checks in addition to those specified in > [RFC6488]. >=20 > Specific checks for a Manifest are described in section 4 of > [RFC6486]. If any of these checks fails, indicating that the > manifest is invalid, then the manifest will be discarded and treated > as though no manifest were present. >=20 > This description is quite incomplete. Perhaps you should merge the = content of section "4.3. How to Make Use of Manifest Data=A1=B1 in = here, but even there I do not see a reference to section 6 (Relying = Party Use of Manifests) of RFC6486, which is quite a big omission. Manifest has been a tricky part.=20 Manifest processing has proven to be significantly more complicated that = initially anticipated.=20 I hope SIDROPS WG to take the chance to give an operational advice along = with this draft.=20 >=20 >=20 > 4.2.2. ROA >=20 > To validate a ROA, the RP is required perform all the checks > specified in [RFC6488] as well as the additional ROA-specific > validation steps. The IP address delegation extension [RFC3779] > present in the end-entity (EE) certificate (contained within the > ROA), must encompass each of the IP address prefix(es) in the ROA. > More details for ROA validation are specified in section 2 of > [RFC6482]. >=20 > The second sentence is almost a 1-to-1 copy of Section 4 of 6482. = What=A1=AFs the point of copying it instead of referencing? For smooth reading, in some cases, the text of this draft paraphrases = the requirements, and in other cases it may merely restate them. >=20 > Section 2 of RFC6482 defines the ROA content-type, not the validation. >=20 >=20 > 4.2.3. Ghostbusters >=20 > The Ghostbusters Record is optional; a publication point in the RPKI > can have zero or more associated Ghostbuster Records. =20 >=20 > This is true for all objects except manifest and CRL. >=20 > If a CA has at > least one Ghostbuster Record, RP is required to verify that this > Ghostbusters Record conforms to the syntax of signed object defined > in [RFC6488]. >=20 > And this is also true for any signed object. >=20 > The payload of this signed object is a (severely) profiled vCard. = An > RP is required to verify that the payload of Ghostbusters conforms = to > format as profiled in [RFC6493]. >=20 > I'm mentioning it here, but it applies to many places in this = document: the validation section of RFC6493 already references RFC6488. = So why duplicate it here? >=20 They are not duplicate. RFC6488 is for generalized validity check in terms of syntax yet RFC6493 = is for syntax check especial for Ghostbusters.=20 >=20 > 4.3. How to Make Use of Manifest Data >=20 > For a given publication point, the RP ought to perform tests to > determine the state of the Manifest at the publication point. A > Manifest can be classified as either valid or invalid, and a valid > Manifest is either current and stale. An RP decides how to make use > of a Manifest based on its state, according to local (RP) policy. >=20 > If there are valid objects in a publication point that are not > present on a Manifest, [RFC6486] does not mandate specific RP > behavior with respect to such objects. However, most RP software > ignores such objects and this document recommends that this behavior > be adopted uniformly. >=20 > Instead of =A1=B0recommending" it in this document, maybe we should = review and change 6486? >=20 > In the absence of a Manifest, an RP is expected to accept all valid > signed objects present in the publication point. =20 >=20 > Actually, 6486 says that all such objects "SHOULD be viewed as = suspect, but MAY be used by the RP, as per local policy", which has = subtle difference. >=20 As I mentioned above, Manifest has been a tricky part. Manifest = processing has proven to be significantly more complicated that = initially anticipated.=20 We might as well considering to update RFC 6486.=20 >=20 >=20 > I think this confirms that keeping such document up to date and = consistent with other documents is not an easy task, and having this = document will not relieve the implementer from studying deeply all the = documents it refers. As far I responded to you above, I think this document is worth efforts = as a WG item though it is not in state of art at present.=20 I would appreciate help and contributions from the WG, especially guys = in charge of RP software.=20 Di From nobody Mon Jul 17 07:37:06 2017 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 9662B131C30 for ; Mon, 17 Jul 2017 07:37:04 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 i_VZZK245o92 for ; Mon, 17 Jul 2017 07:37:02 -0700 (PDT) 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 9A4F1131C2D for ; Mon, 17 Jul 2017 07:36:58 -0700 (PDT) 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:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1dX78r-000xVV-4Q>; Mon, 17 Jul 2017 16:36:57 +0200 Received: from dhcp-80a7.meeting.ietf.org ([31.133.128.167] helo=mw-x1.meeting.ietf.org) 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 <1dX78q-00328B-S6>; Mon, 17 Jul 2017 16:36:57 +0200 Date: Mon, 17 Jul 2017 16:36:55 +0200 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: 31.133.128.167 Archived-At: Subject: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 14:37:05 -0000 two comments via the list because we run out of time: (1) I'm wondering about the statement that the quality of ROAs decreases over time. My impression is that the quality improved because of excellent training by RIRs and others. Slide 4 shows absolute values, which is not helpful in this context. (2) Regarding ROV measurements: "Similar results apparently from measurements by Randy Bush and others (didn't yet see details)" Details are available, easy to find using Google: * "Towards a Rigorous Methodology for Measuring Adoption of RPKI Route Validation and Filtering", https://arxiv.org/abs/1706.04263. Some of this work was also presented at the last RIPE meeting: https://ripe74.ripe.net/archives/video/46/ Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Mon Jul 17 08:14:24 2017 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 35F32126D73; Mon, 17 Jul 2017 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 j57cToaoB9k6; Mon, 17 Jul 2017 08:14:17 -0700 (PDT) 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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF927131C55; Mon, 17 Jul 2017 08:14:08 -0700 (PDT) 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 F2C3A3FF98; Mon, 17 Jul 2017 15:14:06 +0000 (UTC) Received: from morrowc.roam.corp.google.com.ops-netman.net (dhcp-8d3b.meeting.ietf.org [31.133.141.59]) (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 B1D8ACA899E5; Mon, 17 Jul 2017 15:14:05 +0000 (UTC) Date: Mon, 17 Jul 2017 11:14:00 -0400 Message-ID: From: Chris Morrow To: sidrops@ietf.org,sidrops-chairs@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] Discussion && WGLC call for: draft-ietf-sidrops-rpki-tree-validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 15:14:19 -0000 Working group folks: The Authors of draft: draft-ietf-sidrops-rpki-tree-validation With Abstract: "This document describes the approach to validate the content of the RPKI certificate tree, as used by the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol, and repositories that use a mix of both." Would like to move their documentation about their process forward. This document does not describe protocol bits nor global operational work, it describes how the RIPE systems operate, and has links to their code and such for future followup/replication/etc. This seems like a reasonable goal, met by the document, so moving forward to WGLC seems appropriate at this time. Let's give the document a read, and ack/nack forward motion in the next 3 weeks time (giving 1wk extra for ietf meeting work to happen). This means, decisions should arrive on/about: 8/8/2017 -chris co-chair-sidrops From nobody Mon Jul 17 08:22:27 2017 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 5B555131B39 for ; Mon, 17 Jul 2017 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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=juniper.net 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 XWURd2ZNhc5Q for ; Mon, 17 Jul 2017 08:22:08 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.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 5B49A131C55 for ; Mon, 17 Jul 2017 08:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LptA6RSdv+B9toebP+Ef9rcZfZiQh4/oIP9OoImadcU=; b=U2GXsRATUd7mXGUTv+JRbDN5RMnVmHlkcSHCoAIGT67DAcIZmJ8kqhTVJUu4U0MYO+8663D8JXT6hJKvWMoBeAk7W+cEZLKZMfVpP+qAz/cLvMNgpAqVptbgvkLhciG99mbSCKSeejgj/FnzcmBml5FSBoOKSgeYcXXp/RKJ/PU= Received: from CY1PR05MB2507.namprd05.prod.outlook.com (10.167.10.134) by CY1PR05MB2347.namprd05.prod.outlook.com (10.166.193.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 15:22:07 +0000 Received: from CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) by CY1PR05MB2507.namprd05.prod.outlook.com ([10.167.10.134]) with mapi id 15.01.1282.008; Mon, 17 Jul 2017 15:22:07 +0000 From: John Scudder To: "sidrops@ietf.org" Thread-Topic: Enforcement mechanisms Thread-Index: AQHS/xBzqHU/jR6ztkORt5aDx3NgMQ== Date: Mon, 17 Jul 2017 15:22:07 +0000 Message-ID: <081F8800-6734-4AB0-BB6C-19FB6C9A100B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:128:1cb0:d75e:405c:ee35] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR05MB2347; 7:PD8V9hN9YPMjA4uGowR2FG94x/qwrYSuDUOzWeHHzm9/fxP939mt90ltb2r/MieSUSyRtAmajzibMVl4B4gAg1v33rlW0bVmOWetgzpqjYmn4cnJOx3LRNVK4J4EqwXdcCZzDHOwk1b+J1jNpC6q5kwbRbfwrGJYpue9onxHbn9Snu1Rtj6QBrtOSU5zxziP6vaj4vJHTr1TUkVnbOThOeJTg5ebJS/smioKDPfC88pP6fsn9UJXS5TejaUftH/pAGB+Q3iklqyzpTRWadKwbqfRJ75AHvMrgq0/lRPkQE41ShRKxbtH+V8sq/yUfCY2oa5wX6xpFqoaFj0wziKcxekRTHrNMMaSsWAdKIAQ3+K60I+36q0RrXcO2qLHCSx3OtJExHWY17Z/GFHFfGMYnOCNV3fRt1sw2g/XXH59gOGWw+jNJQbap6OmWEeTHKIDYoXMDkXi34R97Nszt9rMlyETcTBZtq1OEUo0/17IE3oZ0sy6mR0Osf9k/KXEkWt4p90s6n723C5Ap1cxexIS1TimU/88jvPxtPbN9ZliyYAVdmaRFwbDwYx02GjpBf4MHn7nu5POd4eogMmLocei2AnbtTBVzyouLZfEEBrNP8l/LksrqoSVAWsB6MlMw7EqNjAMB4pQBY7ChCLf3/L6yKOV7SoDltUsbIQ5y7GyCm517Kh6PYJKxQ3cyJuHr7pfDc6C+MtCODsR2fWdAT7zAWEEKz1Zbx56e4PB0lnYpMCD05QT8NJhqai5LyVFYOrh+lPXs2osiXyvJnWIoGFV5ulNwfKWzTe6hN5s67qO/D0= x-ms-office365-filtering-correlation-id: 5005cba0-96ee-45c1-07d5-08d4cd279636 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB2347; x-ms-traffictypediagnostic: CY1PR05MB2347: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(50300203121483)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB2347; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB2347; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39450400003)(39400400002)(39860400002)(39850400002)(38730400002)(53936002)(2501003)(6506006)(2351001)(14454004)(6486002)(5640700003)(189998001)(77096006)(6436002)(86362001)(6512007)(6916009)(478600001)(3480700004)(33656002)(236005)(99286003)(110136004)(50986999)(54896002)(6306002)(54356999)(83716003)(966005)(82746002)(36756003)(2906002)(6116002)(2900100001)(102836003)(3280700002)(3660700001)(5660300001)(81166006)(25786009)(1730700003)(8676002)(7736002)(221733001)(8936002)(606006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2347; H:CY1PR05MB2507.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_081F880067344AB0BB6C19FB6C9A100Bjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 15:22:07.1749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2347 Archived-At: Subject: [Sidrops] Enforcement mechanisms X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 15:22:12 -0000 --_000_081F880067344AB0BB6C19FB6C9A100Bjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIEFtaXIgSGVyemJlcmcncyAiY29sbGF0ZXJhbCBkYW1hZ2UiLCBzbGlkZSA5IG9m IGhpcyBwcmVzZW50YXRpb246DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk5 L3NsaWRlcy9zbGlkZXMtOTktc2lkcm9wcy1ycGtpLWRlcGxveW1lbnQtc3RhdHVzLWNoYWxsZW5n ZXMtYW5kLXRoZS1sZWFybmluZy12YWxpZGF0b3ItMDEucGRmDQoNCkl0IG9jY3VycyB0byBtZSB0 aGUgZGVzY3JpYmVkIGRhbWFnZSBvbmx5IG9jY3VycyBpZiBBUyAzIHVzZXMgImRyb3AgdGhlIHJv dXRlIiBhcyBpdHMgZW5mb3JjZW1lbnQgbWVjaGFuaXNtLiBBbm90aGVyIG9wdGlvbiB3b3VsZCBi ZSB0byBibGFja2hvbGUgdHJhZmZpYyB0byB0aGUgImJhZCIgcHJlZml4ICAoMS4xLjEvMjQgb24g dGhlIHNsaWRlKSBpZiBhbmQgb25seSBpZiBubyBnb29kIGFsdGVybmF0ZSByb3V0ZSB0byB0aGUg cHJlZml4IGlzIGF2YWlsYWJsZSAoYXMgaXMgdGhlIGNhc2UgaW4gdGhlIGV4YW1wbGUgb24gc2xp ZGUgOSkuDQoNClRoaXMgd291bGQgc3RpbGwgcmVwcmVzZW50IGEgc3VjY2Vzc2Z1bCBhdHRhY2sg YnV0IGEgZGlmZmVyZW50IG9uZSAtLSBkZW5pYWwgb2Ygc2VydmljZSB0byB0aGUgdmljdGltIGlu c3RlYWQgb2YgZGF0YSBzdGVhbGluZy4gTm90ZSB0aGF0IGluIHRoZSBleGFtcGxlIG9uIHNsaWRl IDksIHNpbmNlIEFTIDIgZG9lc24ndCBjYXJlIGFib3V0IFJPQXMgYXQgYWxsLCB3ZSBvbmx5IGhh dmUgdGhlIG9wdGlvbnMgb2YgZGV2aWwgb3IgZGVlcCBibHVlIHNlYSBpbiBhbnkgY2FzZS4NCg0K VGhlIG1haW4gbGlhYmlsaXR5IG9mIHRoaXMgYXBwcm9hY2ggdGhhdCBJIHNlZSBpcyBpZiBpdCdz IG5vdCBhIHJlYWwgYXR0YWNrIGJ1dCByYXRoZXIgYSAid3JvbmciIFJPQSwgd2l0aCB0aGUgdXN1 YWwgImRyb3AgdGhlIHJvdXRlIiBhcHByb2FjaCB0aGVyZSBvZnRlbiB3aWxsIGJlIG5vIChvciBu b3Qgc2V2ZXJlKSBuZWdhdGl2ZSBjb25zZXF1ZW5jZXMgdG8gdGhlIGFmZmVjdGVkIHBhcnR5LCBp ZiB0aGV5J3JlIGNvdmVyZWQgYnkgYSBwcm9wZXJseSBST0EnZCBzdXBlcm5ldCwgc28geW91IGNh biBzdGlsbCBnZXQgeW91ciB5b2d1cnQsIGFsYmVpdCBtYXliZSB0aHJvdWdoIGEgc3Vib3B0aW1h bCBwYXRoLiBPVE9IIHdpdGggdGhlIGFwcHJvYWNoIEkgZGVzY3JpYmUsIHRoZXkncmUgc3VyZSB0 byBsb3NlIGNvbm5lY3Rpdml0eSwgbm8geW9ndXJ0LiBCdXQgSSB0aGluayB0aGlzIGlzIHJlYWxs eSBhbiBhcmd1bWVudCBmb3IgZ2V0dGluZyByaWQgb2YgIndyb25nIiBST0FzLCBub3QgZm9yIHVz aW5nIHdlYWsgZW5mb3JjZW1lbnQuIChJZiB5b3UncmUgdXNpbmcgd2VhayBlbmZvcmNlbWVudCBi ZWNhdXNlIHlvdSdyZSBhZnJhaWQgb2YgdGhlIGNvbnNlcXVlbmNlcyBvZiBzdHJvbmcgZW5mb3Jj ZW1lbnQsIHlvdSBtaWdodCBhcyB3ZWxsIGFkbWl0IHlvdSBkb24ndCB3YW50IHRvIGRvIGVuZm9y Y2VtZW50IGF0IGFsbC4pDQoNCllvdSBjYW4gZGVjaWRlIGZvciB5b3Vyc2VsZiBpZiB0aGUgY3Vy ZSBpcyB3b3JzZSB0aGFuIHRoZSBkaXNlYXNlLiBCdXQgSSBiZWxpZXZlIGl0J3MgcG9zc2libGUg dG8gY29uZmlndXJlIHlvdXIgcm91dGVyIHRvIGRvIHRoaXMgdG9kYXksIGlmIHlvdSBmZWVsIGxp a2UgaXQuDQoNCi0tSm9obg0KDQpQLiBTLiBUaGlzIHByb2JhYmx5IGNhbiBiZSByZWxhdGVkIGJh Y2sgdG8gdGhlIHByZWhpc3Rvcnkgb2YgQ0lEUiwgZm9yIHRob3NlIHdobyByZW1lbWJlciB0aGF0 LiBJcyB0aGlzIHRoZSBmaXJzdCB0aW1lIENJRFIgaGFzIGNvbWUgdXAgaW4gU0lEUj8NCg== --_000_081F880067344AB0BB6C19FB6C9A100Bjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <771651ABDD31134DB75680D0D224A812@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Vi a2l0LWxldHRlcnByZXNzOyI+UmVnYXJkaW5nIEFtaXIgSGVyemJlcmcncyAmcXVvdDtjb2xsYXRl cmFsIGRhbWFnZSZxdW90Oywgc2xpZGUgOSZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Via2l0LWxldHRlcnByZXNzOyI+ b2YgaGlzIHByZXNlbnRhdGlvbjo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDY5LCA2 OSwgNjkpOyB0ZXh0LWRlY29yYXRpb246IC13ZWJraXQtbGV0dGVycHJlc3M7Ij48YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjog LXdlYmtpdC1sZXR0ZXJwcmVzczsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzk5L3NsaWRlcy9zbGlkZXMtOTktc2lkcm9wcy1ycGtpLWRlcGxveW1lbnQtc3RhdHVz LWNoYWxsZW5nZXMtYW5kLXRoZS1sZWFybmluZy12YWxpZGF0b3ItMDEucGRmIj5odHRwczovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OS9zbGlkZXMvc2xpZGVzLTk5LXNpZHJvcHMtcnBraS1k ZXBsb3ltZW50LXN0YXR1cy1jaGFsbGVuZ2VzLWFuZC10aGUtbGVhcm5pbmctdmFsaWRhdG9yLTAx LnBkZjwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IHRleHQt ZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVzczsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Via2l0LWxldHRl cnByZXNzOyI+SXQgb2NjdXJzIHRvIG1lIHRoZSBkZXNjcmliZWQgZGFtYWdlIG9ubHkgb2NjdXJz IGlmIEFTIDMgdXNlcyAmcXVvdDtkcm9wIHRoZSByb3V0ZSZxdW90OyBhcyBpdHMgZW5mb3JjZW1l bnQgbWVjaGFuaXNtLiBBbm90aGVyIG9wdGlvbiB3b3VsZCBiZSB0byBibGFja2hvbGUgdHJhZmZp YyB0byB0aGUgJnF1b3Q7YmFkJnF1b3Q7IHByZWZpeCAmbmJzcDsoMS4xLjEvMjQNCiBvbiB0aGUg c2xpZGUpIGlmIGFuZCBvbmx5IGlmIG5vIGdvb2QgYWx0ZXJuYXRlIHJvdXRlIHRvIHRoZSBwcmVm aXggaXMgYXZhaWxhYmxlIChhcyBpcyB0aGUgY2FzZSBpbiB0aGUgZXhhbXBsZSBvbiBzbGlkZSA5 KS4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IHRleHQt ZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVzczsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Via2l0LWxldHRl cnByZXNzOyI+VGhpcyB3b3VsZCBzdGlsbCByZXByZXNlbnQgYSBzdWNjZXNzZnVsIGF0dGFjayBi dXQgYSBkaWZmZXJlbnQgb25lIC0tIGRlbmlhbCBvZiBzZXJ2aWNlIHRvIHRoZSB2aWN0aW0gaW5z dGVhZCBvZiBkYXRhIHN0ZWFsaW5nLiBOb3RlIHRoYXQgaW4gdGhlIGV4YW1wbGUgb24gc2xpZGUg OSwgc2luY2UgQVMgMiBkb2Vzbid0DQogY2FyZSBhYm91dCBST0FzIGF0IGFsbCwgd2Ugb25seSBo YXZlIHRoZSBvcHRpb25zIG9mIGRldmlsIG9yIGRlZXAgYmx1ZSBzZWEgaW4gYW55IGNhc2UuJm5i c3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyB0ZXh0LWRlY29y YXRpb246IC13ZWJraXQtbGV0dGVycHJlc3M7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVz czsiPlRoZSBtYWluIGxpYWJpbGl0eSBvZiB0aGlzIGFwcHJvYWNoIHRoYXQgSSBzZWUgaXMgaWYg aXQncyBub3QgYSByZWFsIGF0dGFjayBidXQgcmF0aGVyIGEgJnF1b3Q7d3JvbmcmcXVvdDsgUk9B LCB3aXRoIHRoZSB1c3VhbCAmcXVvdDtkcm9wIHRoZSByb3V0ZSZxdW90OyBhcHByb2FjaCB0aGVy ZSBvZnRlbiB3aWxsIGJlIG5vIChvciBub3Qgc2V2ZXJlKQ0KIG5lZ2F0aXZlIGNvbnNlcXVlbmNl cyB0byB0aGUgYWZmZWN0ZWQgcGFydHksIGlmIHRoZXkncmUgY292ZXJlZCBieSBhIHByb3Blcmx5 IFJPQSdkIHN1cGVybmV0LCBzbyB5b3UgY2FuIHN0aWxsIGdldCB5b3VyIHlvZ3VydCwgYWxiZWl0 IG1heWJlIHRocm91Z2ggYSBzdWJvcHRpbWFsIHBhdGguIE9UT0ggd2l0aCB0aGUgYXBwcm9hY2gg SSBkZXNjcmliZSwgdGhleSdyZSBzdXJlIHRvIGxvc2UgY29ubmVjdGl2aXR5LCBubyB5b2d1cnQu IEJ1dCBJIHRoaW5rDQogdGhpcyBpcyByZWFsbHkgYW4gYXJndW1lbnQgZm9yIGdldHRpbmcgcmlk IG9mICZxdW90O3dyb25nJnF1b3Q7IFJPQXMsIG5vdCBmb3IgdXNpbmcgd2VhayBlbmZvcmNlbWVu dC4gKElmIHlvdSdyZSB1c2luZyB3ZWFrIGVuZm9yY2VtZW50IGJlY2F1c2UgeW91J3JlIGFmcmFp ZCBvZiB0aGUgY29uc2VxdWVuY2VzIG9mIHN0cm9uZyBlbmZvcmNlbWVudCwgeW91IG1pZ2h0IGFz IHdlbGwgYWRtaXQgeW91IGRvbid0IHdhbnQgdG8gZG8gZW5mb3JjZW1lbnQgYXQgYWxsLik8L2Rp dj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjog LXdlYmtpdC1sZXR0ZXJwcmVzczsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn Yig2OSwgNjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Via2l0LWxldHRlcnByZXNzOyI+WW91 IGNhbiBkZWNpZGUgZm9yIHlvdXJzZWxmIGlmIHRoZSBjdXJlIGlzIHdvcnNlIHRoYW4gdGhlIGRp c2Vhc2UuIEJ1dCBJIGJlbGlldmUgaXQncyBwb3NzaWJsZSB0byBjb25maWd1cmUgeW91ciByb3V0 ZXIgdG8gZG8gdGhpcyB0b2RheSwgaWYgeW91IGZlZWwgbGlrZSBpdC4mbmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjogLXdlYmtp dC1sZXR0ZXJwcmVzczsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYig2OSwg NjksIDY5KTsgdGV4dC1kZWNvcmF0aW9uOiAtd2Via2l0LWxldHRlcnByZXNzOyI+LS1Kb2huPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDY5LCA2OSwgNjkpOyB0ZXh0LWRlY29yYXRpb246 IC13ZWJraXQtbGV0dGVycHJlc3M7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoNjksIDY5LCA2OSk7IHRleHQtZGVjb3JhdGlvbjogLXdlYmtpdC1sZXR0ZXJwcmVzczsiPlAu IFMuIFRoaXMgcHJvYmFibHkgY2FuIGJlIHJlbGF0ZWQgYmFjayB0byB0aGUgcHJlaGlzdG9yeSBv ZiBDSURSLCBmb3IgdGhvc2Ugd2hvIHJlbWVtYmVyIHRoYXQuIElzIHRoaXMgdGhlIGZpcnN0IHRp bWUgQ0lEUiBoYXMgY29tZSB1cCBpbiBTSURSPzwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_081F880067344AB0BB6C19FB6C9A100Bjunipernet_-- From nobody Mon Jul 17 09:16:00 2017 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 575EE131C71 for ; Mon, 17 Jul 2017 09:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=nistgov.onmicrosoft.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 vCNNova8zBHQ for ; Mon, 17 Jul 2017 09:15:56 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0096.outbound.protection.outlook.com [23.103.201.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E747912EC01 for ; Mon, 17 Jul 2017 09:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jp3n2WC13MZ92OpukMDvhrH/FTKdZ+1UTWIIOvH2QVo=; b=JmcUvCHHMUDDgEEPpwOrI+dMP7Dgs0t3kSz6YU+0kR+bDvB7mlxy+Nvajmwk2JwH8DF8056Bt1ES5d0I5O9jKGlYU7RcVoDDowG8iPO70Y42g1K4QQaYWCRkRTwvHORkI8wn5kQ+GZlHXG5g5yLZtjeWe3nKmoaiC7tmWsfBZsY= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 16:15:54 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58]) by DM2PR09MB0446.namprd09.prod.outlook.com ([fe80::1c34:a069:468b:fa58%13]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 16:15:54 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Brian Weis (bew)" CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] WGLC for draft-ietf-sidrops-bgpsec-rollover-00 - ENDS: 04/21/2017 (April 21 2017) Thread-Index: AQHSu+CYdM3RbugUgkmZcx58NwhSiaJY52QA///NRIA= Date: Mon, 17 Jul 2017 16:15:53 +0000 Message-ID: References: , <17A30666-950F-4712-8FF1-64F61A5AF5F9@cisco.com> In-Reply-To: <17A30666-950F-4712-8FF1-64F61A5AF5F9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.133] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:0wPOONH3yjOlfdSaITjYFKVllgsava2uBq1yw6LMTiwRJtSgHWbeyhpluCZAVBssCC4EvyiXkbDrLxM42jwPYD8mLAfuIKiUNFwT4Wc2BpYd4r0bqNTPBWsq5SHP6vnV8VJS2YjY1fMSLfp+HUKnmbexrdhqrto60UwzyXbJp3YuiujC8AFOP7J8QnnH2DhN9OiM7rVGtURyNO0bfMh9nJMR+dnJoyL1AM2ob8RqPD6bh0pwB81zcJMTnQybZ35vUf49+3mggjBMQy48YoF2RO0Vg5vWxAmg3OrcYEUe4wBeMvdREV52AJIMGwuNfAn5lC/CM0tHs9K2Q820n3qC29OW8AedNxXKhuW7iXFduDs8pWseZ/l4QX0S83zb6AWUT0ywtkUG7hILDC+oOtzQn3z2aHECTHtNHhvLZIy9bxSY9eRFCzpTyBZu2jfRuD3iasjx5BW8CDeKgB/OyozEJTmQ27pxrO4pcFmrbOpt9G/aTCeBBXLQELzZ+8rCD1HtfcEEiLV4mdUsx7yE6LqpQ9nt2qputci9PFYz3DDMmd32nCLuToI8atWgkd2wD0QoiLo6UUKV+BJSDAzahF9Av+TFPscbxV98ErWprmRo0Dh2jbY/J/UcuCHLXELo6gBROAhYE2N4q3pskYBeF7WMCxCjOUo1+ZmlX4XRrdnUocVZy3ce2yrEBvGHrPehJqLhFX6nos0NZ6Sd1Q2/DtSMMrqn6US3iij6s10rLhJ/c7dNw4w6CHPWkJLZnDYKXae6Gc1sb7znCuYc5gTf+cjydhs7vHJ0V+6Vvb0w1qRu+NQ= x-ms-office365-filtering-correlation-id: 74386271-2253-40cd-34f5-08d4cd2f198d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR09MB0448; x-ms-traffictypediagnostic: DM2PR09MB0448: x-exchange-antispam-report-test: UriScan:(125551606395959)(278178393323532)(65766998875637)(236129657087228)(192374486261705)(48057245064654)(148574349560750)(167848164394848)(209349559609743)(95692535739014); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR09MB0448; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39840400002)(39450400003)(39400400002)(39850400002)(66654002)(69224002)(5423002)(252514010)(24454002)(377454003)(76176999)(2950100002)(4326008)(50986999)(7696004)(229853002)(53936002)(6506006)(53546010)(33656002)(966005)(14454004)(54356999)(74316002)(110136004)(25786009)(38730400002)(6246003)(81166006)(8936002)(478600001)(6916009)(8676002)(7736002)(305945005)(5660300001)(3846002)(66066001)(6436002)(2906002)(3280700002)(5890100001)(3660700001)(6116002)(102836003)(86362001)(189998001)(99286003)(55016002)(9686003)(6306002)(5250100002)(230783001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 16:15:53.8651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-bgpsec-rollover-00 - ENDS: 04/21/2017 (April 21 2017) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 16:15:58 -0000 Brian, Thanks for letting me know.=20 There was also a marked-up MS word file attachment in the same sidrops post= -- I hope you've noted that. https://www.ietf.org/mail-archive/web/sidrops/current/msg00115.html=20 Sriram ________________________________________ From: Brian Weis (bew) Sent: Monday, July 17, 2017 11:04 AM To: Sriram, Kotikalapudi (Fed) Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-bgpsec-rollover-00 - END= S: 04/21/2017 (April 21 2017) Hi Sriram, Found your comments =85 somehow I missed them earlier. I=92ll address them = ASAP. > On Apr 23, 2017, at 6:53 AM, Sriram, Kotikalapudi (Fed) wrote: > > Hi Brian, Keyur, Roque: > > Thanks for all your efforts in authoring this document. > I have carefully read the draft and have comments. > Some of my comments are listed here and I have also comments in the attac= hed document > (marked in the MS word file using track changes). > My comments are aimed to help get the document into a good shape before a= dvancing it to IESG review. > The technical accuracy of the method described in not in question but > still I feel that the draft needs a careful revision. > > First, it needs to clear some English issues (grammatical errors, some di= fficult to parse sentence structures). > Some of these are pointed out below here, and the rest in the attached wo= rd file. Good. I tried in the last version to address many of these (which originate= d from an author where English was not the first language), but no doubt mi= ssed some > > Second, the document needs to eliminate errors in terms of technical term= s or phrases used. Precision is good =97 thanks. Many thanks, Brian > For example: > s/BGPsec certificate/router certificate/g > (Note: It is the router that has a certificate, not the BGPsec protocol) > s/BGPsec rollover/router key rollover/g > s/BGPsec emergency rollover/Emergency key rollover/g > Generally, "BGPsec_Path attributes" needs replaced with "BGPsec updates" > throughout the document. > For example: > s/...BGPsec_Path attributes signed with a new private key.../...BGPsec up= dates signed with a new private key.../ > (Note: The current AS=92s signature covers the prefix, previous BGPsec_Pa= th attribute including all previous signatures, > the current Secure_Path segment, and the Target AS. > So it is not correct to say =93BGPsec_Path attribute is signed=94; instea= d simply say =93BGPsec update is singed=94.) > > The following comments pertain only to the Abstract and the Introduction = section. > (Please see the attached MS word document for my comments on the other se= ctions.) > Abstract: minor problem with phrasing > > OLD> > This memo provides general recommendations for > that process, as well as describing reasons why the rollover of > BGPsec EE certificates might be necessary. > > NEW> > This document provides general recommendations for > the rollover process, while describing reasons why the rollover of > BGPsec-router EE certificates might be necessary. > > Section 2 (Introduction): > > OLD> > When a router receives or creates a new key pair (using a key > provisioning mechanism), this key pair will be used to sign new > BGPsec_Path attributes =85 > > NEW> > When a router receives or creates a new key pair (using a key > provisioning mechanism), this key pair will be used to sign new > BGPsec updates =85 > > s/to include a signature using the new key (replacing the replaced key)./ > include a signature using the new key (replacing the old key). > > Note: =93replacing the replaced key=94 sounds like a bad phrase > > s/ the old BGPsec certificate (and its key) will not longer be valid,/ > the old BGPsec certificate (and its key) will no longer be valid,/ > > s/ and thus any BGPsec Update that includes a BGPsec_Path attribute with = a signature performed by/ > and thus any BGPsec Update that includes a signature performed by/ > > OLD> > Consequently, if the router does not > refresh its outbound BGPsec Update messages, routing information may > be treated as unauthenticated =85 > NEW> > Consequently, if the router does not > refresh its outbound BGPsec Update messages, previously sent routing in= formation may be treated as unauthenticated =85 > > OLD> > It is therefore extremely important that the BGPsec router key > rollover be performed in such a way that the probability of new > router EE certificates have been distributed throughout the RPKI > before the router begin signing BGPsec_Path attributes with a new > private key. > (Note: sentence is structurally cumbersome) > > NEW> > It is therefore extremely important that NEW > router EE certificates should have been distributed throughout the RPKI= system > before the router begins signing BGPsec updates with the NEW private ke= y. > > Please see comments on other sections in the attached MS word document. > Thank you. > Sriram > > > > > -- Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Mon Jul 17 10:09:20 2017 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 639AA131BD9; Mon, 17 Jul 2017 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 RRMbBl9WmyES; Mon, 17 Jul 2017 10:09:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 76FD2131B3E; Mon, 17 Jul 2017 10:09:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dX9WF-00020k-L0; Mon, 17 Jul 2017 17:09:15 +0000 Date: Mon, 17 Jul 2017 19:09:14 +0200 Message-ID: From: Randy Bush To: Chris Morrow Cc: sidrops@ietf.org, sidrops-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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] Discussion && WGLC call for: draft-ietf-sidrops-rpki-tree-validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 17:09:18 -0000 have read. ship it already. randy From nobody Tue Jul 18 01:21:27 2017 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 486381317AD for ; Tue, 18 Jul 2017 01:21:22 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=zdns.cn 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 MJBtv1zZnqb6 for ; Tue, 18 Jul 2017 01:21:20 -0700 (PDT) Received: from mail.zdns.cn (mail.zdns.cn [202.173.10.13]) (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 313CF131A50 for ; Tue, 18 Jul 2017 01:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zdns.cn; s=dkim; x=1500970878; i=madi@zdns.cn; h=From:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date: Cc:To; bh=rMAnhQf8hEfN2mcwW3YtDssEe/PJIErL9h/twcWvkgY=; b=ma2Tlt TAxdKrRskFys0KBkCEBwp2/3YhE2coaLxL/fnhVC1ZbwZJOMrPW0QpZk0g3FoRNF LvivQH1CVe2Io6gie010qDKri2xFEpxJYySwPFcXGbVr7k+3z9QWnvaFRR8gOXaj BBmZpZrqITrxaUUHcw6Rdw8zHE5KTye9k6OiY= X-TM-DID: 0e6c0e80312adf8b6989fbe7fc72405b From: Di Ma Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 18 Jul 2017 10:21:10 +0200 Cc: Chris Morrow , Keyur Patel To: sidrops@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Sidrops] draft-madi-sidrops-rp adoption X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 08:21:22 -0000 Hi all, As I mentioned in SIDROPS meeting yesterday, we authors think the = informational draft Requirements for RPKI Relying Parties = (draft-madi-sidrops-rp-00) is in alignment with the charter of this WG = in terms of RP.=20 This document provides a single reference point for requirements for RP = software for use in the RPKI and it outlines the RP functions, = summarizes them and then gives reference to those precise sections or = paragraphs. =20 Chairs, please consider this a formal request to put out an adoption = call. Thanks.=20 Di From nobody Tue Jul 18 05:29:50 2017 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 6F779131B42; Tue, 18 Jul 2017 05:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Fo-KdhlR-3Qp; Tue, 18 Jul 2017 05:29:47 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC427131B54; Tue, 18 Jul 2017 05:29:46 -0700 (PDT) Received: from minas-ithil.hactrn.net (dhcp-8048.meeting.ietf.org [31.133.128.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 5D9AD5C43; Tue, 18 Jul 2017 12:29:46 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 1F44BA030AE; Tue, 18 Jul 2017 14:29:34 +0200 (CEST) Date: Tue, 18 Jul 2017 14:29:34 +0200 From: Rob Austein To: sidrops@ietf.org, sidrops-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170718122935.1F44BA030AE@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] Discussion && WGLC call for: draft-ietf-sidrops-rpki-tree-validation X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 12:29:48 -0000 Read it. Portions of it were helpful to me when rewriting my own implementation to add support for RRDP. Useful. Does not need to become more general, just describing what RIPE did is fine. Ship it. From nobody Wed Jul 19 01:59:51 2017 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 53C4D131C43 for ; Wed, 19 Jul 2017 01:59:50 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 YFA8yEERIaCT for ; Wed, 19 Jul 2017 01:59:46 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 9B85A131C42 for ; Wed, 19 Jul 2017 01:59:46 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1dXkpc-000BgL-CS for sidrops@ietf.org; Wed, 19 Jul 2017 10:59:45 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-199.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dXkpc-0003f1-7H; Wed, 19 Jul 2017 10:59:44 +0200 From: Tim Bruijnzeels Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 19 Jul 2017 10:59:42 +0200 Message-Id: To: sidrops@ietf.org X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071963967054f3189060db20d6ea281d0ffd Archived-At: Subject: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 08:59:50 -0000 Dear WG, As presented I want to propose a change to RFC7730 to move to HTTPS = URIs, rather than RSYNC. The reasons why I want this change are: - As a TA operator I feel more confident assuring the availability of a = TA certificate over HTTPS compared to RSYNC - As an RP implementer I want to reduce the dependency on rsync in the = validator. Especially if RRDP is also used, this would mean we don=E2=80=99= t need to call rsync at all anymore. Conventional wisdom would be to first allow HTTPS in addition to RSYNC = (and make it preferred if available), then mandate it, and then = deprecate RSYNC. However, I feel that in this case it would be perfectly safe, and much = simpler to go for the end-stage immediately for the following reasons: - step 1 of allowing HTTPS already forces RP software to support HTTPS - nothing stops us from having a mix of RFC7730 style TALs and = =E2=80=98HTTPS=E2=80=99 TALs for a while: =E2=80=94 TAs can create new TALs when they are ready to publish their = certificate using an HTTPS URI =E2=80=94 TAs can continue to have their certificate available under = RSYNC for those RPs unaware of the updated TAL =E2=80=94 We can pursue parallel efforts (other thread) to have a way = for TAs to pro-actively communicate an updated TAL to RPs - and, of course, updating/replacing 7730 in one step rather than 3 is a = lot less work So, updating 7730 to use HTTPS this way is almost as simple as = 's/rsync/https/g=E2=80=99, and updating the references. In addition I would advocate an HTTPS consideration section, similar to: = https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4.3 Essentially, TLS certificate or host name validation issues found are = worth logging about, but since the RP can verify that the retrieved TA = certificate matches the =E2=80=9CsubjectPublicKeyInfo=E2=80=9D in the = TAL, and is newer than previously obtained certificate, it should be = safe to process. We should probably also advocate that in cases where = multiple HTTPS URIs are present, and TLS certificate or host name = validation issues are found, other URIs are also followed to see if = there is no newer TA certificate. This may be left to local policy, but = I believe this will help against replay attacks where RPs are presented = an outdated TA certificate. So, questions to the WG: =3D Can we adopt this work? =3D What is the best path? Are the 7730 authors willing to update? = Should I start work on a -bis? Thanks Tim= From nobody Wed Jul 19 11:14:33 2017 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 E3673131AAF for ; Wed, 19 Jul 2017 11:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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=apnic.onmicrosoft.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 PwDts1SSJ7-m for ; Wed, 19 Jul 2017 11:14:28 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0050.outbound.protection.outlook.com [104.47.93.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275B812EC18 for ; Wed, 19 Jul 2017 11:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T24gmqnW7r6ViSsmsAstw1N85EWOn/JpaEKGNta9CW4=; b=ZQt2tFsHQD5aOwlBFyrkabmkrd1AIO9/hE++2fJ9I4u1jLRos71Clj3gzyfEqevbyzofyi6u/F6uLlnN2w/qEhoWHUWbRM+KdqGBnZotfHNCmMdh/GtkjNk4fDxkhv4mdcg53zf76WN7w2PSBeHwd5zOHtn+YwCQ2p2JTWdJBeg= Authentication-Results: ripe.net; dkim=none (message not signed) header.d=none;ripe.net; dmarc=none action=none header.from=apnic.net; Received: from [IPv6:2001:67c:370:128:38e7:168d:b987:9b13] (2001:67c:370:128:38e7:168d:b987:9b13) by TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Wed, 19 Jul 2017 18:14:22 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Geoff Huston In-Reply-To: Date: Wed, 19 Jul 2017 20:14:00 +0200 CC: Content-Transfer-Encoding: quoted-printable Message-ID: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> References: To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3273) X-Originating-IP: [2001:67c:370:128:38e7:168d:b987:9b13] X-ClientProxiedBy: VI1P193CA0011.EURP193.PROD.OUTLOOK.COM (10.175.177.149) To TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6e0022ff-8e0c-44e5-f49e-08d4ced1fc18 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 3:3IR2K7Q98laSTYhcLzVjB8J8cUlrHkPnCKGVHgByOee/KSVpQoF2poiDigrGbOKvh5AYNY9mrFmbjAs9OTezgEKLV3XkPdUGMHenek7+m+UivrjQPu95C+hBbINkKRKhS7VBRdQl9OWSfpg+3rSCOeW4wvY6zVMjAX/CQZAlPld0VKTG3xVpbYdJg7CLkd9aehMtgXGA9XwQVR8Kry2RdeRw6k9OlESOUmx0Oy/UmTfGhHeg5R6qq0tgrfuia/lBvQhLcfHIqGBnH+Zd+EYq8aLKB0BtwWC0Wgzz8MAZc8fzGRnS5MtvGxstH5mn/AVbfVfQTeU+xgTF/ciEz4Bu12pu+0HYWB8h8qcppNJgyWvuXvkaMNAii2H7EFyJXPp/CbPJ3uW6UUdZOTxmcSqx7cToiXnrH//2jfOfn48zZqXSdDwnEs7p7L+pxuLdTRIJunKXHKDnZV5UlxOf2CKhNNdbdiFZ1WauwCMsk68oD0FdBXzjLpQryGuBDT/6+I6CLTeJuPiTILyKeCbeQmXzLPoSUp/UCcisejvIEK2McifF2dRPo0zz7BBubtgLp/kE0jxDVnRuh16hdSrxwSE4nhI38QtzoH8PKUUz/RElkSR/3Ed0D720rdaduyZASnjb54OavxClWftRqI/tsb9udfit0fvSg1nGKb4yMTACOurOloQmFKFj0XH4TNcnHtfRnLlafjSGTNl+RY4193ZSamED5GDuE+dekI24Ez03WW4= X-MS-TrafficTypeDiagnostic: TY1PR04MB0703: X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 25:2n1xDnYdtGEV8GTk7vjS4wa1U7fKaydIDOotH/1XZaqAka4LpRNYX8+qdberzJT7Ox8lV2n9DrA+C26EVT8WGzbHo6fx6EqlRUwll0Jcza1dNOs7RTxUKWsURqPpGbnmCG+y5hvAIUkv6lF6+VjaSbX+9Xqf8HlujsWNGZ1SyBHYY8mPTooLUUqZL90fDL/LQVY7HTWYhRc09RBPw8QoituEKVYnCwGNeg0qJ/B1uyZz+8ZzC4Rgu0vA1UlRJZGXTl3enFtie4TGvT4UMwDNlshRGYat1erDQXgoLdxwWR8ugG/ptnpEYM0g785tpvUJ1mYwQyh4+5xHaNNVOWM5nebiGp8tEcztpY/qQCVOJB3fIb5D2NVKd8TzJh2WeV6oB42upeJOAv93TWg2HOSvx40lRTcW3R0d7q8qA7hDrMGFq+VaJNfLg/yhyUfMPdiY93G2fyXXTJInxIl6Bj/ZZmlxjFN6x6lAZxzxNcYOuo/ykz6x/bWM8XySQOcAObrg08j7ExJFZDn11VXF73pKYgnq7BJJt/TrjLF9QPEEK9b6IJ5vEJOPiC9d/BKqcPBZRhBTcb8R4E53GKVjYm2lNmbBaixH4aNodbt+bKr3lbmtN2++R/nG3Gzr//jgRCuBfv/aXXeCcQcUfai+BJXQWDkqDJy0KsZxdgzkHA2hTLc89z7UpAPgMVUc9A6R9z2W4VFNyDxBPeVxsz2aBGztfeVvke+bzhSK46s121FezQw4F/OZ5FQWzvHAK7R3BaTj9XBnFLGpEd5OCLvzl8HZjl1bxNPgIbIp1DQK1b+5eGfGcbITSmVD0It08DNpEEj9gyD2LOmLLsjXk3jsMjetup1I0CVBx+x8JZcpexEPU6DVVigWUn1m/joPR9EZMlFKhtyuUuVtxdRmvf7NWiiSxttzqlQKYLPhnlxM6lBOADc= X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 31:uyeHHLtRmLryx0F8jQylNHlmP8tzfTR4HMKnTs9gsXSIO4EQS+C7GH/IJkPyWf8BbqxfHs4A4qmU/1yBISAV3NznuIOtNlks14N2Va/dayBsPPSj7LvoMjyb40ropuP9w8eIKdNSY1mR3zzI17j1NErgEZ5OofnXpluzb/ZSQTAgkAychsp0Helphv+9PMuJURT1wCzJ2BZIq7qPK29bfN/GPrM8La4RlEjNQsoPtxEq5H8OvY5Cm5/HALT/wgYp3E6HUv2muqTJssWUD6BxJAcqaLUBJTJCiWsbHjnACokrpa2/at9KphS0bPuz24DiuEfsgGy/dpKpYyrykh7WmjamiHLcweclgp019bdVSFMZglD10+2C/pkqNExs1e+bLNkXRQv25HiyOtCYAH15UnxsgcQVPKDq1vjufibg/49IS3+entUJO89PcmfowV3LffEhTPBKgiHw4YH5hFFN5ayGevW9DYx8Ph+Gj2Xtf1qv9fVVI5wCZMIbY/w7PPI+3/nLBRgpPKIP6cR4b3BEkIeS3o7BY1WuLOk4sol6u+7neo+wKrSJqJc8JYQPFDz/wfmg/56LpVUiO3dem7i5mgyEjLQ3QPSw+Sms+d6EZBRNdJAge7H7SMknBF6s+ko2l/zm2HYxmIFP+G/c55IQndW66jCmq6TygcHiwlPFHvrAokPYj/riMj1SV3si0/N2juaxeB3tfq4i6PlGHbXdgQ== X-Exchange-Antispam-Report-Test: UriScan:(133145235818549)(236129657087228)(100405760836317)(148574349560750)(92977632026198)(167848164394848)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:TY1PR04MB0703; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjA0TUIwNzAzOzQ6N3dXblVmOUJFa1pFOVI3VHEzMnMxZE15VDVI?= =?utf-8?B?WXhITEVOK08wRTNVeGhQU2g4N2w5SjIrQkJuVkRNYlBZb0RKNCt5Ym9COFBQ?= =?utf-8?B?L0YvdjlLd3BpYjZoZjBMOEhqNHF5L0lpMnJYRzArTVprYWNyNzUyUDU1QVpo?= =?utf-8?B?VzdoZnBNYVBWRmV5VDU3REFaNm16QW9HVW5haUlCT01zTGtVZGFvZ2xsT2xx?= =?utf-8?B?clZOcTlmK1JqTk9BQTN0a1poZVRMa1owWTdySTFMano4QVZYcXZTQ25WUS9u?= =?utf-8?B?S01DdUN0aE5IUGsvalFyRm5XalJlaTFHZEl2RngvbWE0VE5DWkdpZUUwdG1N?= =?utf-8?B?bDUrSEdyQ29nMDVpYVhIcGFWMENYSkRHN3U1d2hVOVJtMXE2TG9BZTAwWFgr?= =?utf-8?B?SWtpOHFPbXB2b20vbXF6cnF6cGQ0Y2g3WVQ5TFZGQlNtL2xVUWI1MUxhYlNT?= =?utf-8?B?dXd5WkVyN3V0UThOYWdySHoyNm9QWFpaVmNCN2t0ZVlqMzlkRE9YTVVTTU83?= =?utf-8?B?NW8vd0tPT0NFSUxvaU9MSFhEQWRYQWloa3ZpeGdJc0Q0LzZTVzVnNDBDVGtj?= =?utf-8?B?MUlXU2xpZm9jQWZjTzFWd0JXb0x3c1RHMFA1aEorZjI0VXRyV3FwZDFibUNW?= =?utf-8?B?cnpKRllhbmJicThOM3NOSVJrelNSOGhaTVJRUkJkd3poT2w0NWVORGhvRVhU?= =?utf-8?B?cjFuMW9aUTlCQ2JjQkg2aEFFUGI4SHE5enNlTVNDQXMvdFZSSWY0ZmZMQzRr?= =?utf-8?B?YWRRVjVwWnVLeWJSUGlVbUJ2OFdPZWQ1L1U5RE90MmVTekpHc29rUVd3VENJ?= =?utf-8?B?NjdhTS9jWk1STENSQU5UcjNqU3MybmF4N0tzUVY5U3d4VWttNm8xQ3dYSXRs?= =?utf-8?B?am9LUThLdzJvWlVVKzFCZjV3aENFUGcvWS9NQ0JPRTRrQ1U2YWRxS3BKMEVn?= =?utf-8?B?ak9jOC8rejFXYktjeUowb01SeWFxTTFPeXk0bUdsZEQzUUJtRnFCUTA1UEEr?= =?utf-8?B?RDVreGRIY25veFVYOEFUeHVwejF1aGZCMUNnNWd0bWZVRnVGU2E2NHl1aHg2?= =?utf-8?B?TlhwSnRkek5Wb0xyL1hpM1RuQk16Y1VMcWJ2blBPV1BSdUgrSVk0NE9MM2FD?= =?utf-8?B?UU9JRzNiam5iSEMrVVF6YUx5SWFOTVVnTzllNGYyd1NSTXpUZ0cwTmthYm0x?= =?utf-8?B?cUpZcnFubG93RWl5Szl4WHdmMUpRcnZPUmRSckhQWGRyanJJVXdQOGQ3T2Nt?= =?utf-8?B?SEJlZUhnOUZlZW4zTnBweGRVRkEwZFQyZDBlaUdEWVpqbnJzdE9adUlha254?= =?utf-8?B?dG16bkNpR1k1WjFManNGOTEzZWxWeFJvR1VKWW5jdmdjZGc3M2hnWlVvNW9H?= =?utf-8?B?Q2pMdkR4R1B1cDUzWlVMck9SclFySkxZbStrTDNiK2srVkpRSXpPQVNRcFla?= =?utf-8?B?QW5ENVNJTjNGclBGQVNPRVU4VWgxYjdtN09uUEQrc2l1aVV4aFlYMGh5OXF6?= =?utf-8?B?WXFVMlBDZVp2Y0d2UkJTQ2kvSlhuZ21YNHpQUlVPNllRbStGajU1Y0pucDlZ?= =?utf-8?B?VjlvWk9iMEl6MGRvV2IwZmFyVGIxKzdHSTJhd01Ic25XVXVMWUEzdDgyODNj?= =?utf-8?B?SFlLN3VRTjBVcS9PcDEwUjhEV3RpbitPWG5XK1hMVnZUTmgybnJZcHF6di9L?= =?utf-8?B?Vm1hUkdaZ2JoSG1LSkJSTXRXTU9pZ1ZZTksvS0FjNktYNExubmh2RU9pK1hQ?= =?utf-8?B?VURWNDZpRFAvODNxVzYxcnFGRkRNL040NlJLYlFrV2tWK1BmTVNxVjF4cnRK?= =?utf-8?B?eGRIc2RVejkrcDJFWForYkdYLzI3L2VLREhtZFJ0RmlZMk5iMldPVTUwYnFJ?= =?utf-8?B?VWRMS2dZZjBlMmYreDhXNWpUZjRuU3B1bEZHZGhqL285bCtUZzVVUnZNYzd4?= =?utf-8?Q?W1tP5Ip4h5dQ1vRJIn+BKdZV9fbJQ=3D?= X-Forefront-PRVS: 0373D94D15 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7370300001)(4630300001)(6009001)(39410400002)(39450400003)(39400400002)(39830400002)(377454003)(24454002)(53936002)(42186005)(50466002)(189998001)(38730400002)(110136004)(47776003)(478600001)(6246003)(53546010)(57306001)(50986999)(86362001)(76176999)(6306002)(966005)(6116002)(36756003)(305945005)(4326008)(6916009)(6666003)(25786009)(7736002)(2950100002)(8746002)(2906002)(8676002)(7350300001)(81166006)(33656002)(6486002)(50226002)(23676002)(83716003)(82746002)(229853002)(5660300001)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR04MB0703; H:[IPv6:2001:67c:370:128:38e7:168d:b987:9b13]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjA0TUIwNzAzOzIzOnNxbko3SFZZU2Y0b2tmdXhDQlJzUTBWTndN?= =?utf-8?B?VCs3OFNEY3d6MnYraG14QlM3dnJVY2w1ckwwYitKU0hncmdDOC83OEpTMmpH?= =?utf-8?B?LzJHZHc5VE9nRU9IK09aUEhMWWZSSEtjRVM1bGwrY2NZQnh5QkphbWF4d1dK?= =?utf-8?B?c25vMEpjM0lkdFlXcWVUblk5WkpHaXg0bEJlaExsMXVGRUUyMHpIQjBPcVJk?= =?utf-8?B?QURvMUNacnpkSHk3RjFudjFYRkNoWXJwcmJ6cVVBck10aXpuTXh0MnIwTUNO?= =?utf-8?B?R1BvNzlEcjltQUZIbXBjRjJQSTk5c2lacmdnMldrRkhSZDVWNFJHRm51Wkkz?= =?utf-8?B?Q3A2VHQzOWJVbzFTTGFyQzdoMUZaL2VHMm5LU3EvZnpFNExFRTN4ZnBXWEp2?= =?utf-8?B?bGRmMEQ5d0RUVllYQjIwbTczRksvYjczaFJFUEpDUnVMRFBrY0dhY1Rvazg0?= =?utf-8?B?NzF0NElNVzBuQ1llYmtiQlZJSDFZamREUW4wSDFOUWw3U044RFdnUkRzVG14?= =?utf-8?B?bmZCMGR1SkNBL2NrWlpKS1NJM1FxcHMrbUZRd1ZxQXVhTHRmc0tmTHFVVTgv?= =?utf-8?B?a0VEYVZ4TW12YjhSYXFTNnhCaC9uR2FtUmRJNEw3TWdqNHZmZE9nWmo0bHBH?= =?utf-8?B?SWc1SkNDVWVjQk1lRGJ2aTZEZWtkNGtQSEFqdk80aUVpSERIYkdzaC84Z3FV?= =?utf-8?B?YWFRUjZ5eGpaUDNWUmpLem9GdFBScGNJTG1GT1ZWUzNtVDZBdTFSMkNjSkRo?= =?utf-8?B?anN1UENoUzkvZUQ1NTgrbzE1MzJpRnd6OWk3YmIxT2Y3bi9zTkJpU2s2dkQr?= =?utf-8?B?bHRTS0ZXTDM3L0lXVS9ZTGZPbWxKOFlYTW5id1lMNFFVQmJRZWE0c1N5TjA0?= =?utf-8?B?WjlWaFBxQytBZlV1UGo4RWNtRVBPWnc2a3p5TXJBRFMzNmR0T2RlMk1PbDZU?= =?utf-8?B?b0N0SThjMzVSdjdxUGZuSmFKTCtUT2VXdFdvUXQycTZXcFdILy9ZN3lIRnVI?= =?utf-8?B?ZHF6NEdZOEJBeFJJUDNISURXUTEyZUtUZVdZUkN6OFN1RUE2OEg3ZFlyeVNE?= =?utf-8?B?UU5hVnI4UGRZeTFkbHNkUGR2NXVZeW1pU0dWRlRZSThmOFJmU0pOcnAweENr?= =?utf-8?B?Unovb0R2Tnd3V3hjY29EVmc3TmZHeXpDZkhsSkpDQzhDWEtZNmQ5c09XTUpj?= =?utf-8?B?UzZiM3NMUFkzNFRTMVYzNmluTi9pcGhTU0xTR2lra2VEWWRGUFA1WFMyMHV2?= =?utf-8?B?UFhUaFEwOWN6dnRCb04veEYyZWxpV0VrTU9jSzNPOHlDaTdGc2h4RmJuMlla?= =?utf-8?B?cEYzZzM4UHhzalpZYnJ5elR3clJuTWQ2ODVsbVVEVEdBY3VFSmJmYXdxTy9n?= =?utf-8?B?aFNPYmxFYzIxRnNacEhVQWFwbmMydVVUTkdBQ0p3VVArY25Ud3FDVDg3a1FH?= =?utf-8?B?WGtyWnRIQS9iZDlOVjlaY3hrRE9vOUprUDF2S3p5VUdzYzZtSmRJRzNPV2Rs?= =?utf-8?B?UGltZ1JSa05lYlVYUS92THhlOGJMdFRaaGVScHZ5bzBBLzBwTGoyV3VSSVZr?= =?utf-8?Q?xNMnH825Mf1Z8TwSI17HGr6q9ZLp5BISww159W5XPhVk=3D?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjA0TUIwNzAzOzY6cmN5bnhvRnE2TDUycWtWREg0c0pVRDQ5Zmky?= =?utf-8?B?WTJva1h6d3ZCTFdYNkNiRGhXS3hVMTNNdUZacjEyQTRrMStsQnFSMnp4cktC?= =?utf-8?B?Q2grc0FsS1ROQ3h2d3hRQVZEbDB0OHpEc3Vibkk4VkcvZmJBL3dXQkVwOGlm?= =?utf-8?B?YXI5VGMyUml5azNKLzZUdFFNN1JZdTIvd2dtVmdvVXJia3ZlRktOWXNmQ2xG?= =?utf-8?B?S042WURmU2NlUGpra0xRU21wa1BpTG12d2xOeXY0dGUydVZiZ04rcGN3aHNw?= =?utf-8?B?a1ZhWmRvdnZlZ3BkRURjeGJVcllEL2wyczg1Lzl4MURpaWFnRUttRGZWSjkv?= =?utf-8?B?TSt5WGQ3U1JQQ3RhTnFrYWdtdnRidWdrdWFsdjZxSXJOaU5Rb2dTc1hSalBx?= =?utf-8?B?WEpuMlh1cTJsUjhHL3hGZ0tFcUdwYURNTVdkdk9iVnlTL2htVUNUQ0s0T0Z5?= =?utf-8?B?MVE1RHp2QThUUjNZZC9aaUhmYnU0VzJkTWNPTzlDaEFxZ2JyMkpGTnAxeVdD?= =?utf-8?B?SHpSR0FNdDJINVVWeVJyV0JvbEJLVC9CZjMrWFRwUk8vNmh3WDRVSi82NmV4?= =?utf-8?B?SmNHR1R3S1BUekJmSXE4VWtJbU85aGVqaGZNM1FHb0wwTWZHNFRidmlZaUZm?= =?utf-8?B?K2hZM05RdEVtU1dQQThmQVBrS0ZHeHM2dTRyZlZHMGtyQTlvVGJUejlCd1Rt?= =?utf-8?B?eGtybiszSUE0dmhnYlZhekRrU1I2OEVleVpWeGdUTW5aUWZPS2hsMU5LQmdJ?= =?utf-8?B?QnBIT1lZbUxDOFRwT3hNWDdhdUkwNkJDYWduMUJIU1ExVjBzWkdpOWEzdUtE?= =?utf-8?B?ZkdKbVJQRXc3WVhiZUh4SGtVRDBqMVlpVDVqSDlxRENsc1poNzdVTnJaUWs5?= =?utf-8?B?cDJHeENGb3E3UHQrUjM2Tk9NVy9haW9zUlBIWlhNOGlzRVB3MEhMdURsMDAw?= =?utf-8?B?UnNtY2E1MUpMbTRabkt6a1hUYW5EYlEva2dEL1NCNXhjTTVEb3dtbnRqOExQ?= =?utf-8?B?ZlNpTXVGWFg0L2FuTDZ2TUhlNkg0RTVHdzdycnMzZm5Kc09QTUgvMmdIT2tk?= =?utf-8?B?Mis4QW9lWlR3OS9rUSt1dWFGajJlUm5Ua2pRTG9qT0d5c0FDeTZkbkNBeDZ2?= =?utf-8?B?SUpyeThxYm9ZemM3bnVycFkzbmVkQ3pyZ2NJc2U0TjdKWEV4TjNrTGtHdWNj?= =?utf-8?B?YlNYQ2dsQUxyNmxmcnpXSnQ4VDV1Z3dxeERMNmx3bUoyVW1Ib3M2c216WXFV?= =?utf-8?B?WXBZS2xnUysvVXFMMEk4d0pibWpDaldXTDFleDc5a2JaQkVxdnhwRU8wQ0Js?= =?utf-8?Q?Rt2Z4mxSRGVe2gbqKY2gdW/Tw7BObbE=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 5:9NCt8JYX2Yf9uXMSZemA4xmAl3zdcI4HyOdOHPx6BnrEDuSVQ9b/ZgHNJNbr41DwAhD/FX1SsJ9J/8neSa9y4k67iT789pe+TSaWpppsKZ0m457ADrN1ZV/rIAUpZx7ijcXWAlB6K1xWkhdah4XmhnmCGC6+TbhS4vG1zd+hWir495nk5kGmPK3BVwBVUiwXKPO+/R3+6vmxpEGWbwHRCAgm+9OmgRgynLEm1C3uw2LHexJLVgwhmFkwhXtr7tezmXCfWgIww+O6y6rvZ+w2RR9tj/zYSIiaYVq7+QS2Nrdle+lxa/oJ5eDkn07Hyyoni9tqVeM3+26hKtxD2AsFk10l6HHp4G9hlyxStZCf+z2p6FE8CRTL+zLoftqnfNlpSgQaTOntHfAVUncYnMDwvOwCb8wxUQthJh1WuVTMmkQvCQOkGbr9M1OGhJ5StCm4vP/dKjnR+25Jli3ijJ+oP+8bml9ZlBVJ/GtcUamweSsilFv1C6XNuq3isd4CD0n7; 24:FBtjg0sW92Qj7QbFGliE4u81Xy1mk9P140jpfY1m+yh4fihfSLYdAuP5buuAGsfb55ceUAbk0hqAx1v/iawRJ2PgnpMx7G9pLwe1moX58nY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 7:L4bcIQyCGjuupcYylGE456JgJ59tZ+gRQ7wOekrVMQlTbOR+FNs9p0jC1Jy2PJ4Dr7umsW1YjXBErTSyGNy5+aOw9xDEiKQOz0KQtQpfvylbcFOHX2j9nvGzIEkcHD0+6Ko4cLq0e/GFNMcLm/DQBCXI6Ai4c9toGHNF7ejRBFd2Jvc4ziQPvsPcKMGz5555y90muzEtCSU2jIZ8K63Yk69jK0jgxKW0fDWhR1yqzIRlkGgtqjmuNSZOJY6fUVQXgy+IJBxttGtzWka+IJ3fyaR74M4t8GVfND8+KXxd67SEiU9b/WyaPm7m+KLURB/lKOserJNXJ3MT+XQa5iazo8eq+H0+udPcQDBsit7vNU45emxF6H2Hcnp0Snz1AW0baa+EkbHkzuWwvWYoWYY+JQERYeRkV23CjIsYs01dSje3Lt41suddss5iUKfwITSYXkhwCjHABSQ8WG3lTiooYPqnmvCpo/rKNnV4Myf2i3McjlyMI5DR+UB37EEXONsRYqoz6mChiQWYQ7pmYUivu0J64Gw7195EP6V4j/gyEC7DEZy4i9tFPzOOSGFRDVNt64CInnEXm3XVgJ/NQXEoRIjF3qsAY2qis7/nX12fpm5Jgwm+JpiqJjjxqwAwcKTZzLwiOBj0/xsAjg+d4FVLk3bHGG4jAIgPXvzrivGUjjpcWwiFVxZTMMNSxRc+WvntsG9OiogFgs7PvJN8djkxNWS3YWbBR4WD9GXPdBXoe2I9YW6F+PoAv0xGI0i7Og27niL+fcfbkqU5tEd3a+TQqo9wTAi+ZJD+yKYNCFrAueM= X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2017 18:14:22.8594 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR04MB0703 Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 18:14:32 -0000 This particular author of RFC7730 is more than happy to apply = s/rsync/https/g on RFC7730, but will only do so if the chairs can gather = the consensus of the WG to proceed in this direction, of course regards, Geoff > On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels wrote: >=20 > Dear WG, >=20 > As presented I want to propose a change to RFC7730 to move to HTTPS = URIs, rather than RSYNC. >=20 > The reasons why I want this change are: > - As a TA operator I feel more confident assuring the availability of = a TA certificate over HTTPS compared to RSYNC > - As an RP implementer I want to reduce the dependency on rsync in the = validator. Especially if RRDP is also used, this would mean we don=E2=80=99= t need to call rsync at all anymore. >=20 > Conventional wisdom would be to first allow HTTPS in addition to RSYNC = (and make it preferred if available), then mandate it, and then = deprecate RSYNC. >=20 > However, I feel that in this case it would be perfectly safe, and much = simpler to go for the end-stage immediately for the following reasons: > - step 1 of allowing HTTPS already forces RP software to support HTTPS > - nothing stops us from having a mix of RFC7730 style TALs and = =E2=80=98HTTPS=E2=80=99 TALs for a while: > =E2=80=94 TAs can create new TALs when they are ready to publish their = certificate using an HTTPS URI > =E2=80=94 TAs can continue to have their certificate available under = RSYNC for those RPs unaware of the updated TAL > =E2=80=94 We can pursue parallel efforts (other thread) to have a way = for TAs to pro-actively communicate an updated TAL to RPs > - and, of course, updating/replacing 7730 in one step rather than 3 is = a lot less work >=20 > So, updating 7730 to use HTTPS this way is almost as simple as = 's/rsync/https/g=E2=80=99, and updating the references. >=20 > In addition I would advocate an HTTPS consideration section, similar = to: > = https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4.3 >=20 > Essentially, TLS certificate or host name validation issues found are = worth logging about, but since the RP can verify that the retrieved TA = certificate matches the =E2=80=9CsubjectPublicKeyInfo=E2=80=9D in the = TAL, and is newer than previously obtained certificate, it should be = safe to process. We should probably also advocate that in cases where = multiple HTTPS URIs are present, and TLS certificate or host name = validation issues are found, other URIs are also followed to see if = there is no newer TA certificate. This may be left to local policy, but = I believe this will help against replay attacks where RPs are presented = an outdated TA certificate. >=20 > So, questions to the WG: > =3D Can we adopt this work? > =3D What is the best path? Are the 7730 authors willing to update? = Should I start work on a -bis? >=20 >=20 > Thanks >=20 > Tim > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Jul 19 11:30:23 2017 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 1EFD1131AAF for ; Wed, 19 Jul 2017 11:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 7-ET3_XTn63c for ; Wed, 19 Jul 2017 11:30:19 -0700 (PDT) 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 312EA131B48 for ; Wed, 19 Jul 2017 11:30:19 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dXtjl-0003LD-Fk (job@us.ntt.net) for sidrops@ietf.org; Wed, 19 Jul 2017 18:30:18 +0000 Received: by mail-wr0-f172.google.com with SMTP id 12so62038746wrb.1 for ; Wed, 19 Jul 2017 11:30:17 -0700 (PDT) X-Gm-Message-State: AIVw11277PTYowJb4z/VlpwwiA8J+9h86786E/a/1SvhNyuJdNn5Umhl nvXEWU96ApIhRT1eb+3FcqUgvYBUdFW8 X-Received: by 10.223.130.102 with SMTP id 93mr1042962wrb.253.1500489016364; Wed, 19 Jul 2017 11:30:16 -0700 (PDT) MIME-Version: 1.0 References: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> In-Reply-To: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> From: Job Snijders Date: Wed, 19 Jul 2017 18:30:05 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Geoff Huston , Tim Bruijnzeels Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="001a114b3c44cf9e5e0554afd2c1" Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 18:30:22 -0000 --001a114b3c44cf9e5e0554afd2c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I'd like to encourage the working group to consider modernizing the file format a bit. I'd like to see JSON or XML on anything that is structured, and a version field somewhere. Kind regards, Job On Wed, 19 Jul 2017 at 20:14, Geoff Huston wrote: > This particular author of RFC7730 is more than happy to apply > s/rsync/https/g on RFC7730, but will only do so if the chairs can gather > the consensus of the WG to proceed in this direction, of course > > regards, > > Geoff > > > > On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels wrote: > > > > Dear WG, > > > > As presented I want to propose a change to RFC7730 to move to HTTPS > URIs, rather than RSYNC. > > > > The reasons why I want this change are: > > - As a TA operator I feel more confident assuring the availability of a > TA certificate over HTTPS compared to RSYNC > > - As an RP implementer I want to reduce the dependency on rsync in the > validator. Especially if RRDP is also used, this would mean we don=E2=80= =99t need > to call rsync at all anymore. > > > > Conventional wisdom would be to first allow HTTPS in addition to RSYNC > (and make it preferred if available), then mandate it, and then deprecate > RSYNC. > > > > However, I feel that in this case it would be perfectly safe, and much > simpler to go for the end-stage immediately for the following reasons: > > - step 1 of allowing HTTPS already forces RP software to support HTTPS > > - nothing stops us from having a mix of RFC7730 style TALs and =E2=80= =98HTTPS=E2=80=99 > TALs for a while: > > =E2=80=94 TAs can create new TALs when they are ready to publish their > certificate using an HTTPS URI > > =E2=80=94 TAs can continue to have their certificate available under RS= YNC for > those RPs unaware of the updated TAL > > =E2=80=94 We can pursue parallel efforts (other thread) to have a way f= or TAs to > pro-actively communicate an updated TAL to RPs > > - and, of course, updating/replacing 7730 in one step rather than 3 is = a > lot less work > > > > So, updating 7730 to use HTTPS this way is almost as simple as > 's/rsync/https/g=E2=80=99, and updating the references. > > > > In addition I would advocate an HTTPS consideration section, similar to= : > > > https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4.3 > > > > Essentially, TLS certificate or host name validation issues found are > worth logging about, but since the RP can verify that the retrieved TA > certificate matches the =E2=80=9CsubjectPublicKeyInfo=E2=80=9D in the TAL= , and is newer > than previously obtained certificate, it should be safe to process. We > should probably also advocate that in cases where multiple HTTPS URIs are > present, and TLS certificate or host name validation issues are found, > other URIs are also followed to see if there is no newer TA certificate. > This may be left to local policy, but I believe this will help against > replay attacks where RPs are presented an outdated TA certificate. > > > > So, questions to the WG: > > =3D Can we adopt this work? > > =3D What is the best path? Are the 7730 authors willing to update? Shou= ld > I start work on a -bis? > > > > > > Thanks > > > > Tim > > _______________________________________________ > > 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 > --001a114b3c44cf9e5e0554afd2c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I'd like to encourage the working group to consider modernizing = the file format a bit. I'd like to see JSON or XML on anything that is = structured, and a version field somewhere.=C2=A0
Kind regards,

Job

On Wed, 19 Jul = 2017 at 20:14, Geoff Huston <gih@apnic.= net> wrote:
This particular = author of RFC7730 is more than happy to apply s/rsync/https/g on RFC7730, b= ut will only do so if the chairs can gather the consensus of the WG to proc= eed in this direction, of course

regards,

=C2=A0 Geoff


> On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels <tim@ripe.net> wrote:
>
> Dear WG,
>
> As presented I want to propose a change to RFC7730 to move to HTTPS UR= Is, rather than RSYNC.
>
> The reasons why I want this change are:
> - As a TA operator I feel more confident assuring the availability of = a TA certificate over HTTPS compared to RSYNC
> - As an RP implementer I want to reduce the dependency on rsync in the= validator. Especially if RRDP is also used, this would mean we don=E2=80= =99t need to call rsync at all anymore.
>
> Conventional wisdom would be to first allow HTTPS in addition to RSYNC= (and make it preferred if available), then mandate it, and then deprecate = RSYNC.
>
> However, I feel that in this case it would be perfectly safe, and much= simpler to go for the end-stage immediately for the following reasons:
> - step 1 of allowing HTTPS already forces RP software to support HTTPS=
> - nothing stops us from having a mix of RFC7730 style TALs and =E2=80= =98HTTPS=E2=80=99 TALs for a while:
> =E2=80=94 TAs can create new TALs when they are ready to publish their= certificate using an HTTPS URI
> =E2=80=94 TAs can continue to have their certificate available under R= SYNC for those RPs unaware of the updated TAL
> =E2=80=94 We can pursue parallel efforts (other thread) to have a way = for TAs to pro-actively communicate an updated TAL to RPs
> - and, of course, updating/replacing 7730 in one step rather than 3 is= a lot less work
>
> So, updating 7730 to use HTTPS this way is almost as simple as 's/= rsync/https/g=E2=80=99, and updating the references.
>
> In addition I would advocate an HTTPS consideration section, similar t= o:
> https://tools.ietf.org= /html/draft-ietf-sidr-delta-protocol-08#section-4.3
>
> Essentially, TLS certificate or host name validation issues found are = worth logging about, but since the RP can verify that the retrieved TA cert= ificate matches the =E2=80=9CsubjectPublicKeyInfo=E2=80=9D in the TAL, and = is newer than previously obtained certificate, it should be safe to process= . We should probably also advocate that in cases where multiple HTTPS URIs = are present, and TLS certificate or host name validation issues are found, = other URIs are also followed to see if there is no newer TA certificate. Th= is may be left to local policy, but I believe this will help against replay= attacks where RPs are presented an outdated TA certificate.
>
> So, questions to the WG:
> =3D Can we adopt this work?
> =3D What is the best path? Are the 7730 authors willing to update? Sho= uld I start work on a -bis?
>
>
> Thanks
>
> Tim
> _______________________________________________
> 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
--001a114b3c44cf9e5e0554afd2c1-- From nobody Wed Jul 19 12:08:09 2017 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 874B5131B3B for ; Wed, 19 Jul 2017 12:08:07 -0700 (PDT) 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 ZDDxZYvZKVvv for ; Wed, 19 Jul 2017 12:08:05 -0700 (PDT) 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 0B506128CFF for ; Wed, 19 Jul 2017 12:08:04 -0700 (PDT) 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 v6JJ7u9x040764 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jul 2017 20:07:56 +0100 (IST) (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 Message-ID: <596FAE0B.2010405@foobar.org> Date: Wed, 19 Jul 2017 20:07:55 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.15 (Macintosh/20170609) MIME-Version: 1.0 To: Geoff Huston CC: sidrops@ietf.org References: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> In-Reply-To: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 19:08:07 -0000 Looks good to me. Nick Geoff Huston wrote: > This particular author of RFC7730 is more than happy to apply s/rsync/https/g on RFC7730, but will only do so if the chairs can gather the consensus of the WG to proceed in this direction, of course > > regards, > > Geoff > > >> On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels wrote: >> >> Dear WG, >> >> As presented I want to propose a change to RFC7730 to move to HTTPS URIs, rather than RSYNC. >> >> The reasons why I want this change are: >> - As a TA operator I feel more confident assuring the availability of a TA certificate over HTTPS compared to RSYNC >> - As an RP implementer I want to reduce the dependency on rsync in the validator. Especially if RRDP is also used, this would mean we don’t need to call rsync at all anymore. >> >> Conventional wisdom would be to first allow HTTPS in addition to RSYNC (and make it preferred if available), then mandate it, and then deprecate RSYNC. >> >> However, I feel that in this case it would be perfectly safe, and much simpler to go for the end-stage immediately for the following reasons: >> - step 1 of allowing HTTPS already forces RP software to support HTTPS >> - nothing stops us from having a mix of RFC7730 style TALs and ‘HTTPS’ TALs for a while: >> — TAs can create new TALs when they are ready to publish their certificate using an HTTPS URI >> — TAs can continue to have their certificate available under RSYNC for those RPs unaware of the updated TAL >> — We can pursue parallel efforts (other thread) to have a way for TAs to pro-actively communicate an updated TAL to RPs >> - and, of course, updating/replacing 7730 in one step rather than 3 is a lot less work >> >> So, updating 7730 to use HTTPS this way is almost as simple as 's/rsync/https/g’, and updating the references. >> >> In addition I would advocate an HTTPS consideration section, similar to: >> https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4.3 >> >> Essentially, TLS certificate or host name validation issues found are worth logging about, but since the RP can verify that the retrieved TA certificate matches the “subjectPublicKeyInfo” in the TAL, and is newer than previously obtained certificate, it should be safe to process. We should probably also advocate that in cases where multiple HTTPS URIs are present, and TLS certificate or host name validation issues are found, other URIs are also followed to see if there is no newer TA certificate. This may be left to local policy, but I believe this will help against replay attacks where RPs are presented an outdated TA certificate. >> >> So, questions to the WG: >> = Can we adopt this work? >> = What is the best path? Are the 7730 authors willing to update? Should I start work on a -bis? >> >> >> Thanks >> >> Tim >> _______________________________________________ >> 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 Wed Jul 19 12:50:25 2017 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 D34EE12EC06 for ; Wed, 19 Jul 2017 12:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 CQBoNyPVSKos for ; Wed, 19 Jul 2017 12:50:22 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 5E9B11200FC for ; Wed, 19 Jul 2017 12:50:22 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so7637308uax.3 for ; Wed, 19 Jul 2017 12:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=pfFsLOkQRfPn4Eq2h3bdS/eDy1+btwWyMBeFU4c2OSQ=; b=X7lucNDcZV7ofCuHvvh2D/tqVCmybkVn7bpdkioqSyfPgKxMAEsA4ZQhd9dQPSRZVz tulYNckHmjMgYgxkWBRLmd3oa8U/+HxREsWTrqNdBonvfVxOfuspTbOYmivZHz3Eio/a Cjgu38ZXDQZ8PTyznRf4Ocwyz6kotDQCMoe3QQEBFdEp8aSphDx4uXn6+qUPubBGgqKx PTRK3SYhWtIhT5BMONFemYatetGO4r/xkos8u++3KEztBj0hBrVkqI/laT51dgPy2KB+ 4kyMpzK4Vg3ifHkWpheI55qS7bLaolWxFd+7wptFc+jcewKHD0V1AGapzMYRqqR2xbot 2Sug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=pfFsLOkQRfPn4Eq2h3bdS/eDy1+btwWyMBeFU4c2OSQ=; b=g3NzoZbngB/A534wogRVMStBBuQ+nUSF0lZORqyLF8lgnRKbTxPHQPx6B+WkMV1XlG 82SKE7Mny3n6NnR3k9eN9QrlwEE0I1gmGtC+35n9SKmKmSV4pivRwrEQ6WrMFVU4vXuB cAEPQa1htN2mViBHOP+CoabkknLFyMCXQaE4vOZHdHWcDY+ivmaBXa7WBxMxDpFMStRT FMdvvI5oOLSm/R/3DgYQyBv44QN5ZrI2xO10EVHurdLGTWSnWp/XICVfsIvw+c1tuedf qFeNopK3/tW9ExHiiCuWi0As/qEWFEHtpvHd8BbzXIxrtbSXJ4xjP12B8G6oJWPSqcz0 Rnsw== X-Gm-Message-State: AIVw1107LsPiNMB9Uy3X8MXL6Fu3t0g/Vrd071EhmeaWDsVEdNiow6+S rCRoXy0pELxVdn7Oq9t+qU3UioUd4q1Uf5A= X-Received: by 10.176.23.3 with SMTP id j3mr842862uaf.128.1500493821135; Wed, 19 Jul 2017 12:50:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Wed, 19 Jul 2017 12:50:20 -0700 (PDT) X-Originating-IP: [2001:67c:1232:144:f504:8046:2221:2b54] In-Reply-To: <596FAE0B.2010405@foobar.org> References: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> <596FAE0B.2010405@foobar.org> From: George Michaelson Date: Wed, 19 Jul 2017 21:50:20 +0200 Message-ID: To: sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 19:50:25 -0000 I think a simple revspin is a no brainer. I think we should go there. -G On Wed, Jul 19, 2017 at 9:07 PM, Nick Hilliard wrote: > Looks good to me. > > Nick > > Geoff Huston wrote: >> This particular author of RFC7730 is more than happy to apply s/rsync/ht= tps/g on RFC7730, but will only do so if the chairs can gather the consensu= s of the WG to proceed in this direction, of course >> >> regards, >> >> Geoff >> >> >>> On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels wrote: >>> >>> Dear WG, >>> >>> As presented I want to propose a change to RFC7730 to move to HTTPS URI= s, rather than RSYNC. >>> >>> The reasons why I want this change are: >>> - As a TA operator I feel more confident assuring the availability of a= TA certificate over HTTPS compared to RSYNC >>> - As an RP implementer I want to reduce the dependency on rsync in the = validator. Especially if RRDP is also used, this would mean we don=E2=80=99= t need to call rsync at all anymore. >>> >>> Conventional wisdom would be to first allow HTTPS in addition to RSYNC = (and make it preferred if available), then mandate it, and then deprecate R= SYNC. >>> >>> However, I feel that in this case it would be perfectly safe, and much = simpler to go for the end-stage immediately for the following reasons: >>> - step 1 of allowing HTTPS already forces RP software to support HTTPS >>> - nothing stops us from having a mix of RFC7730 style TALs and =E2=80= =98HTTPS=E2=80=99 TALs for a while: >>> =E2=80=94 TAs can create new TALs when they are ready to publish their = certificate using an HTTPS URI >>> =E2=80=94 TAs can continue to have their certificate available under RS= YNC for those RPs unaware of the updated TAL >>> =E2=80=94 We can pursue parallel efforts (other thread) to have a way f= or TAs to pro-actively communicate an updated TAL to RPs >>> - and, of course, updating/replacing 7730 in one step rather than 3 is = a lot less work >>> >>> So, updating 7730 to use HTTPS this way is almost as simple as 's/rsync= /https/g=E2=80=99, and updating the references. >>> >>> In addition I would advocate an HTTPS consideration section, similar to= : >>> https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4= .3 >>> >>> Essentially, TLS certificate or host name validation issues found are w= orth logging about, but since the RP can verify that the retrieved TA certi= ficate matches the =E2=80=9CsubjectPublicKeyInfo=E2=80=9D in the TAL, and i= s newer than previously obtained certificate, it should be safe to process.= We should probably also advocate that in cases where multiple HTTPS URIs a= re present, and TLS certificate or host name validation issues are found, o= ther URIs are also followed to see if there is no newer TA certificate. Thi= s may be left to local policy, but I believe this will help against replay = attacks where RPs are presented an outdated TA certificate. >>> >>> So, questions to the WG: >>> =3D Can we adopt this work? >>> =3D What is the best path? Are the 7730 authors willing to update? Shou= ld I start work on a -bis? >>> >>> >>> Thanks >>> >>> Tim >>> _______________________________________________ >>> 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 From nobody Wed Jul 19 18:44:25 2017 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 8F7ED126DEE for ; Wed, 19 Jul 2017 18:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 qZ-so1EsTeRb for ; Wed, 19 Jul 2017 18:44:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49701205F0 for ; Wed, 19 Jul 2017 18:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5080; q=dns/txt; s=iport; t=1500515061; x=1501724661; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7q1/KFRvNsohF7odCxRgrx7+6PFxsGXKR2o1Dx0Hdgo=; b=D/JM19b6lx7xEgfeYRwAdn8nLpMMo33l9J/s+WBFUghF133ayGQGQhQ3 YSAgNHXs6zCyYWb17VtUH7BDh5m9UiIhGue/IIVwdF8HrPoLdfPH79/8r Bvf0guaGlKOPvb0snyzckPRJin+23KNpojaYVHzJ83aAgs1LQyMetTXDV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAABeCXBZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgSRRSKWBIIRIQ2BXoJsTwIag0k/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBASEROgYFEAIBCA4KAgImAgICJQsVEAIEAQ0FiicIELBIgiaLI?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuCHYNNgWErC4JuhGoXgnwwgjEFkFe?= =?us-ascii?q?GbYd1AodJjE6CDJAkiUeMFAEfOD9LdRVJEgGHA3YBhmIrgQWBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,382,1496102400"; d="scan'208";a="275792137" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2017 01:44:20 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6K1iKcU005831 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 01:44:20 GMT Received: from xch-rtp-011.cisco.com (64.101.220.151) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Jul 2017 21:44:19 -0400 Received: from xch-rtp-011.cisco.com ([64.101.220.151]) by XCH-RTP-011.cisco.com ([64.101.220.151]) with mapi id 15.00.1210.000; Wed, 19 Jul 2017 21:44:19 -0400 From: "Roque Gagliano (rogaglia)" To: Geoff Huston , Tim Bruijnzeels CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] HTTPS in TALs Thread-Index: AQHTAG1lrB0Cc7OHEk6SatvBMuYqAKJbt8oAgAA1fgA= Date: Thu, 20 Jul 2017 01:44:19 +0000 Message-ID: <0133E7BC-5845-4478-917A-62BE3CBA5696@cisco.com> References: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> In-Reply-To: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.0.170702 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.75.84] Content-Type: text/plain; charset="utf-8" Content-ID: <32FA5C454BC85740B0B43B7BA95E393C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 01:44:23 -0000 SGksDQoNCkFncmVlIHRvIG1vdmUgZm9yd2FyZC4NCg0KT25lIG9ic2VydmF0aW9uIGlzIHRoYXQg d2Ugc2hvdWxkIGV4cGxpY2l0bHkgaW5jbHVkZSBhIHNlY3Rpb24gb24gdGhlIHRyYW5zaXRpb24g ZnJvbSBSRkM3NzMwIHRvIDc3MzBiaXMgd2hlcmUgVEEgb3BlcmF0b3JzIGhhdmUsIGZvciBhIHJl YXNvbmFibGUgYW1vdW50IG9mIHRpbWUsIGJvdGggSFRUUFMgYW5kIFJTWU5DIFVSSXMgYXZhaWxh YmxlIChldmVuIHRob3VnaCBvbmx5IEhUVFBTIHdpbGwgYmUgbWFuZGF0b3J5IGdvaW5nIGZvcndh cmQuKQ0KDQpSZWdhcmRzLA0KUm9xdWUNCg0KDQoNCk9uIDE5LzA3LzE3IDE1OjE0LCAiU2lkcm9w cyBvbiBiZWhhbGYgb2YgR2VvZmYgSHVzdG9uIiA8c2lkcm9wcy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBnaWhAYXBuaWMubmV0PiB3cm90ZToNCg0KICAgIFRoaXMgcGFydGljdWxhciBh dXRob3Igb2YgUkZDNzczMCBpcyBtb3JlIHRoYW4gaGFwcHkgdG8gYXBwbHkgcy9yc3luYy9odHRw cy9nIG9uIFJGQzc3MzAsIGJ1dCB3aWxsIG9ubHkgZG8gc28gaWYgdGhlIGNoYWlycyBjYW4gZ2F0 aGVyIHRoZSBjb25zZW5zdXMgb2YgdGhlIFdHIHRvIHByb2NlZWQgaW4gdGhpcyBkaXJlY3Rpb24s IG9mIGNvdXJzZQ0KICAgIA0KICAgIHJlZ2FyZHMsDQogICAgDQogICAgICBHZW9mZg0KICAgIA0K ICAgIA0KICAgID4gT24gMTkgSnVsIDIwMTcsIGF0IDEwOjU5IGFtLCBUaW0gQnJ1aWpuemVlbHMg PHRpbUByaXBlLm5ldD4gd3JvdGU6DQogICAgPiANCiAgICA+IERlYXIgV0csDQogICAgPiANCiAg ICA+IEFzIHByZXNlbnRlZCBJIHdhbnQgdG8gcHJvcG9zZSBhIGNoYW5nZSB0byBSRkM3NzMwIHRv IG1vdmUgdG8gSFRUUFMgVVJJcywgcmF0aGVyIHRoYW4gUlNZTkMuDQogICAgPiANCiAgICA+IFRo ZSByZWFzb25zIHdoeSBJIHdhbnQgdGhpcyBjaGFuZ2UgYXJlOg0KICAgID4gLSBBcyBhIFRBIG9w ZXJhdG9yIEkgZmVlbCBtb3JlIGNvbmZpZGVudCBhc3N1cmluZyB0aGUgYXZhaWxhYmlsaXR5IG9m IGEgVEEgY2VydGlmaWNhdGUgb3ZlciBIVFRQUyBjb21wYXJlZCB0byBSU1lOQw0KICAgID4gLSBB cyBhbiBSUCBpbXBsZW1lbnRlciBJIHdhbnQgdG8gcmVkdWNlIHRoZSBkZXBlbmRlbmN5IG9uIHJz eW5jIGluIHRoZSB2YWxpZGF0b3IuIEVzcGVjaWFsbHkgaWYgUlJEUCBpcyBhbHNvIHVzZWQsIHRo aXMgd291bGQgbWVhbiB3ZSBkb27igJl0IG5lZWQgdG8gY2FsbCByc3luYyBhdCBhbGwgYW55bW9y ZS4NCiAgICA+IA0KICAgID4gQ29udmVudGlvbmFsIHdpc2RvbSB3b3VsZCBiZSB0byBmaXJzdCBh bGxvdyBIVFRQUyBpbiBhZGRpdGlvbiB0byBSU1lOQyAoYW5kIG1ha2UgaXQgcHJlZmVycmVkIGlm IGF2YWlsYWJsZSksIHRoZW4gbWFuZGF0ZSBpdCwgYW5kIHRoZW4gZGVwcmVjYXRlIFJTWU5DLg0K ICAgID4gDQogICAgPiBIb3dldmVyLCBJIGZlZWwgdGhhdCBpbiB0aGlzIGNhc2UgaXQgd291bGQg YmUgcGVyZmVjdGx5IHNhZmUsIGFuZCBtdWNoIHNpbXBsZXIgdG8gZ28gZm9yIHRoZSBlbmQtc3Rh Z2UgaW1tZWRpYXRlbHkgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCiAgICA+IC0gc3RlcCAx IG9mIGFsbG93aW5nIEhUVFBTIGFscmVhZHkgZm9yY2VzIFJQIHNvZnR3YXJlIHRvIHN1cHBvcnQg SFRUUFMNCiAgICA+IC0gbm90aGluZyBzdG9wcyB1cyBmcm9tIGhhdmluZyBhIG1peCBvZiBSRkM3 NzMwIHN0eWxlIFRBTHMgYW5kIOKAmEhUVFBT4oCZIFRBTHMgZm9yIGEgd2hpbGU6DQogICAgPiDi gJQgVEFzIGNhbiBjcmVhdGUgbmV3IFRBTHMgd2hlbiB0aGV5IGFyZSByZWFkeSB0byBwdWJsaXNo IHRoZWlyIGNlcnRpZmljYXRlIHVzaW5nIGFuIEhUVFBTIFVSSQ0KICAgID4g4oCUIFRBcyBjYW4g Y29udGludWUgdG8gaGF2ZSB0aGVpciBjZXJ0aWZpY2F0ZSBhdmFpbGFibGUgdW5kZXIgUlNZTkMg Zm9yIHRob3NlIFJQcyB1bmF3YXJlIG9mIHRoZSB1cGRhdGVkIFRBTA0KICAgID4g4oCUIFdlIGNh biBwdXJzdWUgcGFyYWxsZWwgZWZmb3J0cyAob3RoZXIgdGhyZWFkKSB0byBoYXZlIGEgd2F5IGZv ciBUQXMgdG8gcHJvLWFjdGl2ZWx5IGNvbW11bmljYXRlIGFuIHVwZGF0ZWQgVEFMIHRvIFJQcw0K ICAgID4gLSBhbmQsIG9mIGNvdXJzZSwgdXBkYXRpbmcvcmVwbGFjaW5nIDc3MzAgaW4gb25lIHN0 ZXAgcmF0aGVyIHRoYW4gMyBpcyBhIGxvdCBsZXNzIHdvcmsNCiAgICA+IA0KICAgID4gU28sIHVw ZGF0aW5nIDc3MzAgdG8gdXNlIEhUVFBTIHRoaXMgd2F5IGlzIGFsbW9zdCBhcyBzaW1wbGUgYXMg J3MvcnN5bmMvaHR0cHMvZ+KAmSwgYW5kIHVwZGF0aW5nIHRoZSByZWZlcmVuY2VzLg0KICAgID4g DQogICAgPiBJbiBhZGRpdGlvbiBJIHdvdWxkIGFkdm9jYXRlIGFuIEhUVFBTIGNvbnNpZGVyYXRp b24gc2VjdGlvbiwgc2ltaWxhciB0bzoNCiAgICA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXNpZHItZGVsdGEtcHJvdG9jb2wtMDgjc2VjdGlvbi00LjMNCiAgICA+IA0K ICAgID4gRXNzZW50aWFsbHksIFRMUyBjZXJ0aWZpY2F0ZSBvciBob3N0IG5hbWUgdmFsaWRhdGlv biBpc3N1ZXMgZm91bmQgYXJlIHdvcnRoIGxvZ2dpbmcgYWJvdXQsIGJ1dCBzaW5jZSB0aGUgUlAg Y2FuIHZlcmlmeSB0aGF0IHRoZSByZXRyaWV2ZWQgVEEgY2VydGlmaWNhdGUgbWF0Y2hlcyB0aGUg 4oCcc3ViamVjdFB1YmxpY0tleUluZm/igJ0gaW4gdGhlIFRBTCwgYW5kIGlzIG5ld2VyIHRoYW4g cHJldmlvdXNseSBvYnRhaW5lZCBjZXJ0aWZpY2F0ZSwgaXQgc2hvdWxkIGJlIHNhZmUgdG8gcHJv Y2Vzcy4gV2Ugc2hvdWxkIHByb2JhYmx5IGFsc28gYWR2b2NhdGUgdGhhdCBpbiBjYXNlcyB3aGVy ZSBtdWx0aXBsZSBIVFRQUyBVUklzIGFyZSBwcmVzZW50LCBhbmQgVExTIGNlcnRpZmljYXRlIG9y IGhvc3QgbmFtZSB2YWxpZGF0aW9uIGlzc3VlcyBhcmUgZm91bmQsIG90aGVyIFVSSXMgYXJlIGFs c28gZm9sbG93ZWQgdG8gc2VlIGlmIHRoZXJlIGlzIG5vIG5ld2VyIFRBIGNlcnRpZmljYXRlLiBU aGlzIG1heSBiZSBsZWZ0IHRvIGxvY2FsIHBvbGljeSwgYnV0IEkgYmVsaWV2ZSB0aGlzIHdpbGwg aGVscCBhZ2FpbnN0IHJlcGxheSBhdHRhY2tzIHdoZXJlIFJQcyBhcmUgcHJlc2VudGVkIGFuIG91 dGRhdGVkIFRBIGNlcnRpZmljYXRlLg0KICAgID4gDQogICAgPiBTbywgcXVlc3Rpb25zIHRvIHRo ZSBXRzoNCiAgICA+ID0gQ2FuIHdlIGFkb3B0IHRoaXMgd29yaz8NCiAgICA+ID0gV2hhdCBpcyB0 aGUgYmVzdCBwYXRoPyBBcmUgdGhlIDc3MzAgYXV0aG9ycyB3aWxsaW5nIHRvIHVwZGF0ZT8gU2hv dWxkIEkgc3RhcnQgd29yayBvbiBhIC1iaXM/DQogICAgPiANCiAgICA+IA0KICAgID4gVGhhbmtz DQogICAgPiANCiAgICA+IFRpbQ0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICA+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQogICAgPiBTaWRy b3BzQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpZHJvcHMNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIFNpZHJvcHMgbWFpbGluZyBsaXN0DQogICAgU2lkcm9wc0BpZXRmLm9y Zw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wcw0KICAg IA0KDQo= From nobody Wed Jul 19 22:29:27 2017 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 433AB131B90; Mon, 17 Jul 2017 06:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 JNAZumTY0yUu; Mon, 17 Jul 2017 06:28:35 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix-1.ams-ix.net [185.55.136.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1431131B8A; Mon, 17 Jul 2017 06:28:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from dhcp-970f.meeting.ietf.org (dhcp-970f.meeting.ietf.org [31.133.151.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aristidis) by deliverix.ams-ix.net (Postfix) with ESMTPSA id E55DD4151B; Mon, 17 Jul 2017 15:28:29 +0200 (CEST) From: Aris Lambrianidis Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DDC931A8-7C58-4A18-8FD9-3A46C449650E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 15:28:28 +0200 In-Reply-To: <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> Cc: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" , draft-ietf-sidrops-route-server-rpki-light@ietf.org To: "sidrops@ietf.org" References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-Mailman-Approved-At: Wed, 19 Jul 2017 22:29:26 -0700 Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 13:28:37 -0000 --Apple-Mail=_DDC931A8-7C58-4A18-8FD9-3A46C449650E Content-Type: multipart/alternative; boundary="Apple-Mail=_6A216768-80C6-4D4D-9654-C707D8925ADE" --Apple-Mail=_6A216768-80C6-4D4D-9654-C707D8925ADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all, As a quick note, Daniel and I are in Prague, at IETF99. Daniel will be = here until Tuesday afternoon and I=E2=80=99ll be here for the entire week, should you have any concerns, comments, or = questions. We=E2=80=99re looking into moving things forward (read: go for WG Last Call), so we=E2=80=99d appreciate any feedback, in = person or by email. --Aris > On 11 Apr 2017, at 18:15, Thomas King wrote: >=20 > Hi all, >=20 > we have worked on the feedback we received through many channels (e.g. = this mailing list): > - Clarification of the =E2=80=9CSecurity Considerations=E2=80=9D = section. Please let us know if you think a security issue is not = tackled. > - The feedback told us that different modes of operation for how = =E2=80=9Cinvalid=E2=80=9D and =E2=80=9Cnot found=E2=80=9D routes should = be handled needs to be addressed. For this, section =E2=80=9CBGP Prefix = Origin Validation State Utilized at Route-Servers=E2=80=9D was added. > - House-Keeping (e.g. update references, fix typos) >=20 > Best regards, > Thomas >=20 >=20 > On 11/04/2017, 18:14, "Sidrops on behalf of 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 of the IETF. >=20 > Title : Signaling Prefix Origin Validation = Results from a Route Server to Peers > Authors : Thomas King > Daniel Kopp > Aristidis Lambrianidis > Arnaud Fenioux > Filename : = draft-ietf-sidrops-route-server-rpki-light-02.txt > Pages : 7 > Date : 2017-04-11 >=20 > Abstract: > This document defines the usage of the BGP Prefix Origin = Validation > State Extended Community [RFC8097] to signal prefix origin = validation > results from a route server to its peers. Upon reception of = prefix > origin validation results peers can use this information in = their > local routing decision process. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-ligh= t/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-02 > = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-route-server-rpki= -light-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-route-server-rpki-l= ight-02 >=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 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_6A216768-80C6-4D4D-9654-C707D8925ADE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello all,

As a quick note, Daniel and I are in Prague, at IETF99. = Daniel will be here until Tuesday afternoon and I=E2=80=99ll be = here
for the entire week, should you have any = concerns, comments, or questions. We=E2=80=99re looking into moving = things forward
(read: go for WG Last Call), so = we=E2=80=99d appreciate any feedback, in person or by = email. 

--Aris


On 11 Apr 2017, at 18:15, Thomas King <thomas.king@de-cix.net> wrote:

Hi = all,

we have worked on the feedback we = received through many channels (e.g. this mailing list):
- = Clarification of the =E2=80=9CSecurity Considerations=E2=80=9D section. = Please let us know if you think a security issue is not tackled.
- The feedback told us that different modes of operation for = how =E2=80=9Cinvalid=E2=80=9D and =E2=80=9Cnot found=E2=80=9D routes = should be handled needs to be addressed. For this, section =E2=80=9CBGP = Prefix Origin Validation State Utilized at Route-Servers=E2=80=9D was = added.
- House-Keeping (e.g. update references, fix = typos)

Best regards,
Thomas


On 11/04/2017, 18:14, "Sidrops = on behalf of internet-drafts@ietf.org" <sidrops-bounces@ietf.org on behalf of 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 of = the IETF.

=            Title =           : Signaling = Prefix Origin Validation Results from a Route Server to Peers
=            Authors =         : Thomas King
=             &n= bsp;           &nbs= p;    Daniel Kopp
=             &n= bsp;           &nbs= p;    Aristidis Lambrianidis
=             &n= bsp;           &nbs= p;    Arnaud Fenioux
=     Filename =        : = draft-ietf-sidrops-route-server-rpki-light-02.txt
=     Pages =           : 7
    Date =            : = 2017-04-11

   Abstract:
      This document defines = the usage of the BGP Prefix Origin Validation
=       State Extended Community [RFC8097] = to signal prefix origin validation
=       results from a route server to its = peers.  Upon reception of prefix
=       origin validation results peers can = use this information in their
=       local routing decision process.



=    The IETF datatracker status page for this draft is:
   https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-serve= r-rpki-light/

   There = are also htmlized versions available at:
=    https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpk= i-light-02
   https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-route-= server-rpki-light-02

=    A diff from the previous version is available at:
   https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-route-se= rver-rpki-light-02


=    Please note that it may take a couple of minutes from = the time of submission
   until the = htmlized version and diff are available at tools.ietf.org.

   Internet-Drafts are also = available by anonymous FTP at:
   ftp://ftp.ietf.org/internet-drafts/

=    _______________________________________________
   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

= --Apple-Mail=_6A216768-80C6-4D4D-9654-C707D8925ADE-- --Apple-Mail=_DDC931A8-7C58-4A18-8FD9-3A46C449650E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZbLt8AAoJEA9B3v9ltRqsV/8QAMyHnSsD8G2ZYpmUddfCZ/ds EFRRL3tm+sW0Twb6IZ26GnG4CIZg5dajm1qo0fROA7HuaOfu9aFVsrSai8bQwuED k12wYHz+fNy0vVQJa33ICMdV79ZN6ZStHrHudW5wtfywpPjk3Uc6LrZgy00qLtTH xIQVu7JsgmmgYe3/sqhhKzZD1TS6RcGuUWUi2ERNelseLanNSdQe1JNcAi7P7+V8 K60YgBn6qsGPtv8EPQRXKL/9NA0JeMBPXimvVrPAIsqJ+eZofjmySfgR8siGR4d4 RrUf16xQ8wAVuhnwr3ivuyuLub3lxhMTInQJz8hDme5r60I2dlxS6WcqEegGfDNM PPBN1SbpaIGP6/35lMktkgDqENkQ/iJ1e+pUhb4JJwdV7G98z6kK4nzmuomQ1rwZ Sgsqb8t2wvgG2+yQ6SpczueZxHu5p64y1A2v03De8uqAB72VO69CicDRTOO1Zfiz EgDmFK+Jl1MENSYoo0y0nEdodvxHguXoFds1cN8s/s8XKnkGlWS+5VO/BX457k1A pXabUzil4g2cN69feVmla7CyS9mpFTPK+FN+lVylQQc5oq70MfmiV3HoxX/d0vxo twMWigl8ICb79QmeOPaUZX1uMr/COQ8BmEL/OaA9TPsNQpX7Cpb4giuSSsB1uwx6 CMyXrgSH2FmbeLrrdA5E =l6Yl -----END PGP SIGNATURE----- --Apple-Mail=_DDC931A8-7C58-4A18-8FD9-3A46C449650E-- From nobody Thu Jul 20 02:05:45 2017 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 0406A12ECCB for ; Thu, 20 Jul 2017 02:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 vMNq8jB2Y152 for ; Thu, 20 Jul 2017 02:05:42 -0700 (PDT) Received: from mr25p46im-ztdg02101301.me.com (mr25p46im-ztdg02101301.me.com [17.111.255.91]) (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 990FB127735 for ; Thu, 20 Jul 2017 02:05:42 -0700 (PDT) Received: from process-dkim-sign-daemon.mr25p46im-ztdg02101301.me.com by mr25p46im-ztdg02101301.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OTD00900SX2ER00@mr25p46im-ztdg02101301.me.com> for sidrops@ietf.org; Thu, 20 Jul 2017 09:05:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1500541542; bh=Uh5ZEi4fIiXniFNbRSwx06ZvivQMCDRVTD0KrM98njc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=fNQdJlW/dILIdiF21Oy7LgpTnb726vuIFDmu0UIjaIFSLRnHJEiEET7ZOZwwaeu2K /zBqSE4LOvNvHx4Cwnz6NxIu/Lav1zuEv/7nJr2SxDvDnZMJso7evQYOPD9xvhLltg Y9bxXjMmvqAmNuiPMvLSMqDU6fsbW2KsVZQXV/HhyTRkVPFv1sbheoi0qeUQ0uZTsi cbMplNnwhf/G0GfjUGAJZFYX6wIigcEujBJUAgKseWXn9LiMQ7aJRFOYuobddxTvJX WkdRZwB80bzOUPjKm7VNTjXPbCH0bg+So/PMroUV09C+Ht4+2tOLn7hfUm0izjvPjS e0ufCa2XEFZsw== Received: from icloud.com ([127.0.0.1]) by mr25p46im-ztdg02101301.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OTD007JKT9FZ820@mr25p46im-ztdg02101301.me.com>; Thu, 20 Jul 2017 09:05:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-20_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1707200148 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Di Ma In-reply-to: <0133E7BC-5845-4478-917A-62BE3CBA5696@cisco.com> Date: Thu, 20 Jul 2017 11:05:38 +0200 Cc: Geoff Huston , Tim Bruijnzeels , "sidrops@ietf.org" Content-transfer-encoding: quoted-printable Message-id: References: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> <0133E7BC-5845-4478-917A-62BE3CBA5696@cisco.com> To: "Roque Gagliano (rogaglia)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 09:05:44 -0000 I am in favor of this work. And I, as an RP software implementer, agree with Roque on the way to = move forward, which is to leave a reasonable amount of time, both HTTPS = and RSYNC URIs available. Di > =E5=9C=A8 2017=E5=B9=B47=E6=9C=8820=E6=97=A5=EF=BC=8C03:44=EF=BC=8CRoque= Gagliano (rogaglia) =E5=86=99=E9=81=93=EF=BC=9A >=20 > Hi, >=20 > Agree to move forward. >=20 > One observation is that we should explicitly include a section on the = transition from RFC7730 to 7730bis where TA operators have, for a = reasonable amount of time, both HTTPS and RSYNC URIs available (even = though only HTTPS will be mandatory going forward.) >=20 > Regards, > Roque >=20 >=20 >=20 > On 19/07/17 15:14, "Sidrops on behalf of Geoff Huston" = wrote: >=20 > This particular author of RFC7730 is more than happy to apply = s/rsync/https/g on RFC7730, but will only do so if the chairs can gather = the consensus of the WG to proceed in this direction, of course >=20 > regards, >=20 > Geoff >=20 >=20 >> On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels wrote: >>=20 >> Dear WG, >>=20 >> As presented I want to propose a change to RFC7730 to move to HTTPS = URIs, rather than RSYNC. >>=20 >> The reasons why I want this change are: >> - As a TA operator I feel more confident assuring the availability of = a TA certificate over HTTPS compared to RSYNC >> - As an RP implementer I want to reduce the dependency on rsync in = the validator. Especially if RRDP is also used, this would mean we = don=E2=80=99t need to call rsync at all anymore. >>=20 >> Conventional wisdom would be to first allow HTTPS in addition to = RSYNC (and make it preferred if available), then mandate it, and then = deprecate RSYNC. >>=20 >> However, I feel that in this case it would be perfectly safe, and = much simpler to go for the end-stage immediately for the following = reasons: >> - step 1 of allowing HTTPS already forces RP software to support = HTTPS >> - nothing stops us from having a mix of RFC7730 style TALs and = =E2=80=98HTTPS=E2=80=99 TALs for a while: >> =E2=80=94 TAs can create new TALs when they are ready to publish = their certificate using an HTTPS URI >> =E2=80=94 TAs can continue to have their certificate available under = RSYNC for those RPs unaware of the updated TAL >> =E2=80=94 We can pursue parallel efforts (other thread) to have a way = for TAs to pro-actively communicate an updated TAL to RPs >> - and, of course, updating/replacing 7730 in one step rather than 3 = is a lot less work >>=20 >> So, updating 7730 to use HTTPS this way is almost as simple as = 's/rsync/https/g=E2=80=99, and updating the references. >>=20 >> In addition I would advocate an HTTPS consideration section, similar = to: >> = https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4.3 >>=20 >> Essentially, TLS certificate or host name validation issues found are = worth logging about, but since the RP can verify that the retrieved TA = certificate matches the =E2=80=9CsubjectPublicKeyInfo=E2=80=9D in the = TAL, and is newer than previously obtained certificate, it should be = safe to process. We should probably also advocate that in cases where = multiple HTTPS URIs are present, and TLS certificate or host name = validation issues are found, other URIs are also followed to see if = there is no newer TA certificate. This may be left to local policy, but = I believe this will help against replay attacks where RPs are presented = an outdated TA certificate. >>=20 >> So, questions to the WG: >> =3D Can we adopt this work? >> =3D What is the best path? Are the 7730 authors willing to update? = Should I start work on a -bis? >>=20 >>=20 >> Thanks >>=20 >> Tim >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jul 20 02:18:02 2017 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 629E5131892 for ; Thu, 20 Jul 2017 02:17:58 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 aqamQf2SPfMC for ; Thu, 20 Jul 2017 02:17:54 -0700 (PDT) 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 6030A131B05 for ; Thu, 20 Jul 2017 02:17:54 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dY7ag-000Cai-MH; Thu, 20 Jul 2017 11:17:52 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-206.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dY7ag-0004Dv-HP; Thu, 20 Jul 2017 11:17:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 20 Jul 2017 11:17:49 +0200 Cc: "Roque Gagliano (rogaglia)" , "sidrops@ietf.org" , Geoff Huston Content-Transfer-Encoding: quoted-printable Message-Id: References: <0428C22A-4D93-4961-92FA-968B4E177BC5@apnic.net> <0133E7BC-5845-4478-917A-62BE3CBA5696@cisco.com> To: Di Ma X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197fcb8d340979ab2ebfc9385407d16033 Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 09:17:58 -0000 Hi Di, all, > On 20 Jul 2017, at 11:05, Di Ma wrote: >=20 > I am in favor of this work. >=20 > And I, as an RP software implementer, agree with Roque on the way to = move forward, which is to leave a reasonable amount of time, both HTTPS = and RSYNC URIs available. I believe this can be achieved by allowing a reasonable amount of time = where both current RFC7730 style RSYNC only TALs and 7730-bis HTTPS only = TALs are available. RPs that do not support HTTPS (yet) can then use the current RFC7730 = style TALs without surprising HTTPS URIs occurring RPs that are upgraded to support HTTPS in TALs can just as easily use = (multiple) HTTPS only, without the need for RSYNC fallback. So, I believe that there is no strong operational need for having both = URI types in one TAL, while it would complicate the document update = cycle. Tim >=20 > Di >=20 >=20 >> =E5=9C=A8 2017=E5=B9=B47=E6=9C=8820=E6=97=A5=EF=BC=8C03:44=EF=BC=8CRoqu= e Gagliano (rogaglia) =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> Hi, >>=20 >> Agree to move forward. >>=20 >> One observation is that we should explicitly include a section on the = transition from RFC7730 to 7730bis where TA operators have, for a = reasonable amount of time, both HTTPS and RSYNC URIs available (even = though only HTTPS will be mandatory going forward.) >>=20 >> Regards, >> Roque >>=20 >>=20 >>=20 >> On 19/07/17 15:14, "Sidrops on behalf of Geoff Huston" = wrote: >>=20 >> This particular author of RFC7730 is more than happy to apply = s/rsync/https/g on RFC7730, but will only do so if the chairs can gather = the consensus of the WG to proceed in this direction, of course >>=20 >> regards, >>=20 >> Geoff >>=20 >>=20 >>> On 19 Jul 2017, at 10:59 am, Tim Bruijnzeels wrote: >>>=20 >>> Dear WG, >>>=20 >>> As presented I want to propose a change to RFC7730 to move to HTTPS = URIs, rather than RSYNC. >>>=20 >>> The reasons why I want this change are: >>> - As a TA operator I feel more confident assuring the availability = of a TA certificate over HTTPS compared to RSYNC >>> - As an RP implementer I want to reduce the dependency on rsync in = the validator. Especially if RRDP is also used, this would mean we = don=E2=80=99t need to call rsync at all anymore. >>>=20 >>> Conventional wisdom would be to first allow HTTPS in addition to = RSYNC (and make it preferred if available), then mandate it, and then = deprecate RSYNC. >>>=20 >>> However, I feel that in this case it would be perfectly safe, and = much simpler to go for the end-stage immediately for the following = reasons: >>> - step 1 of allowing HTTPS already forces RP software to support = HTTPS >>> - nothing stops us from having a mix of RFC7730 style TALs and = =E2=80=98HTTPS=E2=80=99 TALs for a while: >>> =E2=80=94 TAs can create new TALs when they are ready to publish = their certificate using an HTTPS URI >>> =E2=80=94 TAs can continue to have their certificate available under = RSYNC for those RPs unaware of the updated TAL >>> =E2=80=94 We can pursue parallel efforts (other thread) to have a = way for TAs to pro-actively communicate an updated TAL to RPs >>> - and, of course, updating/replacing 7730 in one step rather than 3 = is a lot less work >>>=20 >>> So, updating 7730 to use HTTPS this way is almost as simple as = 's/rsync/https/g=E2=80=99, and updating the references. >>>=20 >>> In addition I would advocate an HTTPS consideration section, similar = to: >>> = https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08#section-4.3 >>>=20 >>> Essentially, TLS certificate or host name validation issues found = are worth logging about, but since the RP can verify that the retrieved = TA certificate matches the =E2=80=9CsubjectPublicKeyInfo=E2=80=9D in the = TAL, and is newer than previously obtained certificate, it should be = safe to process. We should probably also advocate that in cases where = multiple HTTPS URIs are present, and TLS certificate or host name = validation issues are found, other URIs are also followed to see if = there is no newer TA certificate. This may be left to local policy, but = I believe this will help against replay attacks where RPs are presented = an outdated TA certificate. >>>=20 >>> So, questions to the WG: >>> =3D Can we adopt this work? >>> =3D What is the best path? Are the 7730 authors willing to update? = Should I start work on a -bis? >>>=20 >>>=20 >>> Thanks >>>=20 >>> Tim >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jul 20 02:23:35 2017 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 5EDEF131BFF; Thu, 20 Jul 2017 02:23:15 -0700 (PDT) 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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150054259523.24133.3464732718430229924@ietfa.amsl.com> Date: Thu, 20 Jul 2017 02:23:15 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-tree-validation-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 09:23:16 -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 : RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator Authors : Oleg Muravskiy Tim Bruijnzeels Filename : draft-ietf-sidrops-rpki-tree-validation-01.txt Pages : 15 Date : 2017-07-20 Abstract: This document describes the approach to validate the content of the RPKI certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol, and repositories that use a mix of both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-01 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-tree-validation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-tree-validation-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 20 02:34:07 2017 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 F34D412FB9C for ; Thu, 20 Jul 2017 02:34:05 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 NSN7REjJRZ_J for ; Thu, 20 Jul 2017 02:34:04 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 ADD9B12ECCB for ; Thu, 20 Jul 2017 02:34:04 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.88) (envelope-from ) id 1dY7qM-000B7L-CZ for sidrops@ietf.org; Thu, 20 Jul 2017 11:34:03 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-49.ripe.net) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1dY7qL-0006pH-5u; Thu, 20 Jul 2017 11:34:01 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Oleg Muravskiy In-Reply-To: <150054259523.24133.3464732718430229924@ietfa.amsl.com> Date: Thu, 20 Jul 2017 11:34:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F15EA94-597A-46F0-AF5E-D909EF471A4E@ripe.net> References: <150054259523.24133.3464732718430229924@ietfa.amsl.com> To: sidrops@ietf.org X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b744cd0bc51c0d0bdc05c4061dcf4ba8a7e Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-tree-validation-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 09:34:06 -0000 Dear Working Group, This is an update to the description of our implementation of RPKI Tree = Validation. In this version we've added clarification of our use of the algorithm = described in the "validation-reconsidered" draft. And, as discussed during WG meeting on Monday, we would like to go for = WGLC with this document. Thanks, Oleg > On 20 Jul 2017, at 11:23, 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 : RPKI Certificate Tree Validation by the RIPE = NCC RPKI Validator > Authors : Oleg Muravskiy > Tim Bruijnzeels > Filename : draft-ietf-sidrops-rpki-tree-validation-01.txt > Pages : 15 > Date : 2017-07-20 >=20 > Abstract: > This document describes the approach to validate the content of the > RPKI certificate tree, as it is implemented in the RIPE NCC RPKI > Validator. This approach is independent of a particular object > retrieval mechanism. This allows it to be used with repositories > available over the rsync protocol, the RPKI Repository Delta > Protocol, and repositories that use a mix of both. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-tree-validat= ion-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rpki-tree-validatio= n-01 >=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 Thu Jul 20 08:41:31 2017 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 0E6521252BA for ; Thu, 20 Jul 2017 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 LzJ8s87QIkb1 for ; Thu, 20 Jul 2017 08:41:28 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 C513312EC46 for ; Thu, 20 Jul 2017 08:41:27 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id g127so30651087wmd.0 for ; Thu, 20 Jul 2017 08:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=kFqwKlmUG8sHrTo3k9Zy2jkqNJxnQQAoEiZslLNAqZc=; b=QCHZqxFKOdLc/hECcXO7YT6E6HO2ZFdFH0GrTPp5eprvw9BF+9A4vxtLY2mjowYB1s iwnTxxgdsBLl5qwT2gwDuLHMUdvvfqtPaMPbIM0hS8LmNOuyEESPJxormCgcXkAquKMH cEFC7DnvAAb0DNTA/Ouo29P+wSSs1EBD4687cioP7sl8RlK6w9uNDNOtwXTHI8RbkyKL +vc6hU1JZB630C+YcmL4+b4+z0xDYPKzC+ScRH6HHfIsRYN0LlxFA/+/elFOU5JzuuXq v25bnwqO1/5+kq3RljXFFUmFNUOd1B4YsaPcjBNVW0WFgpz4I/5XX2YCyZvh/y3oYxJL 41eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=kFqwKlmUG8sHrTo3k9Zy2jkqNJxnQQAoEiZslLNAqZc=; b=KCEchaHm3BLsQzFsgMJ8OxPVMCCMfCB/K9ZDape+u57oElSw/AcsMvKHsGBwVohx3m gDv5eGkdAq9PryZvcXCzHe0eT9h177LYjkcqw2DJm61DGblA7a5sSMjL1wNEjCnGWXKX RdXMPE28d35W6S7SLyozHq8JJorJK+rPieMEwQ+xe8k1CCKaA+B5+vPuoYusdNLgaKPO 5o4XXqzfTeiLJrqKpWStDp8sTvdSPA26CaHP4Rv5P3EYmtmIcsSu04Kmxgy3ViQHUZs/ Bhs+KE0cDpw9aVDDMHRmZNNazeGd6wr5vipxZb9A5mbq20xAmuz181aUtb6ljT8mi7Z9 uzNA== X-Gm-Message-State: AIVw113fVlpwWEIrBS9ioCTC3HFk4oeSLGAcP9HjNWHfFDTTQ7+6ZeZD 18jHcUhwpIUXQTpf/cE= X-Received: by 10.28.12.195 with SMTP id 186mr2640712wmm.5.1500565286172; Thu, 20 Jul 2017 08:41:26 -0700 (PDT) Received: from [31.133.150.35] ([2001:67c:1232:144:c921:6563:e075:70bb]) by smtp.gmail.com with ESMTPSA id 2sm5921886wrn.24.2017.07.20.08.41.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 08:41:24 -0700 (PDT) From: "Carlos M. Martinez" To: "Matthias Waehlisch" Cc: sidrops@ietf.org Date: Thu, 20 Jul 2017 17:41:24 +0200 Message-ID: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_11533BFC-E6B9-4BC5-9F25-DE1595AD5317_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5383) Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 15:41:30 -0000 --=_MailMate_11533BFC-E6B9-4BC5-9F25-DE1595AD5317_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I was about to ask a question on the mic but was late to the line. Maybe it’s worth sharing it here: - How we define a ROA to be “wrong” ? One that invalidates routes or one that causes legitimate traffic to be dropped ? Why? because we’ve seen in many cases ROAs that create lots of invalids but validate a less-specific route that covers those invalids In a way, this even a positive side-effect, sort of vacuum-cleaning your routing tables. I believe analyzing what ROAs are wrong is quite important, but i’d believe this particular case should not count as wrong. thanks! /Carlos On 17 Jul 2017, at 16:36, Matthias Waehlisch wrote: > two comments via the list because we run out of time: > > (1) I'm wondering about the statement that the quality of ROAs > decreases > over time. My impression is that the quality improved because of > excellent training by RIRs and others. > > Slide 4 shows absolute values, which is not helpful in this context. > > > (2) Regarding ROV measurements: "Similar results apparently from > measurements by Randy Bush and others (didn't yet see details)" > > Details are available, easy to find using Google: > > * "Towards a Rigorous Methodology for Measuring Adoption of RPKI Route > Validation and Filtering", https://arxiv.org/abs/1706.04263. Some of > this work was also presented at the last RIPE meeting: > https://ripe74.ripe.net/archives/video/46/ > > > > > Cheers > matthias > > -- > Matthias Waehlisch > . Freie Universitaet Berlin, Computer Science > .. http://www.cs.fu-berlin.de/~waehl > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --=_MailMate_11533BFC-E6B9-4BC5-9F25-DE1595AD5317_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I was about to ask a question on the mic but was late to = the line. Maybe it=E2=80=99s worth sharing it here:

  • How we define a ROA to be =E2=80=9Cwrong=E2=80=9D ? One that invalida= tes routes or one that causes legitimate traffic to be dropped ?

Why? because we=E2=80=99ve seen in many cases ROAs that c= reate lots of invalids but validate a less-specific route that covers tho= se invalids

In a way, this even a positive side-effect, sort of vacuu= m-cleaning your routing tables.

I believe analyzing what ROAs are wrong is quite importan= t, but i=E2=80=99d believe this particular case should not count as wrong= =2E

thanks!

/Carlos

On 17 Jul 2017, at 16:36, Matthias Waehlisch wrote:

two comments via the= list because we run out of time:

(1) I'm wondering about the statement that the quality of ROAs decrea= ses
over time. My impression is that the quality improved because of
excellent training by RIRs and others.

Slide 4 shows absolute values, which is not helpful in this context.


(2) Regarding ROV measurements: "Similar results apparently from
= measurements by Randy Bush and others (didn't yet see details)"<= br>
Details are available, easy to find using Google:

* "Towards a Rigorous Methodology for Measuring Adoption of RPKI Rou= te
Validation and Filtering", https://arxiv.org/abs/1706.04263. Some of
this work was also presented at the last RIPE meeting:
https://ripe74.rip= e.net/archives/video/46/




Cheers
matthias

--
Matthias Waehlisch
=2E Freie Universitaet Berlin, Computer Science
=2E. http://www.cs.fu-berli= n.de/~waehl

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

--=_MailMate_11533BFC-E6B9-4BC5-9F25-DE1595AD5317_=-- From nobody Thu Jul 20 10:01:38 2017 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 2A952131945 for ; Thu, 20 Jul 2017 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 gc3I3xBRrFsO for ; Thu, 20 Jul 2017 10:01:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1F8127B60 for ; Thu, 20 Jul 2017 10:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17544; q=dns/txt; s=iport; t=1500570094; x=1501779694; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=prxq5kb4AoyToQgr0LkuXXwVOWSlXAArClj6KNlGi88=; b=AGZeY8PlaG6z7qtNaYVvmv8qZ3HXzordaGsOEn/5jhi8jHlZAin76liT Ti1UExcRvbaMs9jEHx5s9mYxhjeEEYTm14AXTOx4FlD2wxDgeFELN77ad 6pQdsZWRQNDX7jU5hBGBGQtyzD8wS/jtnaRzg+GICCSqI9ssZgYJkw3wC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAAB64XBZ/4oNJK1cFgQBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJva2SBFAeOBJFnkFmFLIIRIQEKhExPAhqDWz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDAQEhCkABCxACAQgRBAEBKAMCAgIlCxQJCAIEAQ0FCBSJL2QQsiSCJ?= =?us-ascii?q?haLDAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKINNgWGDJIUggl2CYQWXSId2Aod?= =?us-ascii?q?JjEaSPY0BiFwBHzhMPnUVSYVIgU52AYc7K4EFgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,384,1496102400"; d="scan'208,217";a="276101058" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2017 17:01:33 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6KH1XEu019263 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 17:01:33 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 12:01:33 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 12:01:33 -0500 From: "Jakob Heitz (jheitz)" To: "Carlos M. Martinez" , Matthias Waehlisch CC: "sidrops@ietf.org" Thread-Topic: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator Thread-Index: AQHS/wosXCvss6U2wEyq5n16HYmqTqJdMwYA///B1+A= Date: Thu, 20 Jul 2017 17:01:32 +0000 Message-ID: <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> In-Reply-To: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.63] Content-Type: multipart/alternative; boundary="_000_177afbdbb5424f26992196dae0219ff1XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 17:01:37 -0000 --_000_177afbdbb5424f26992196dae0219ff1XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgaXQgY2F1c2VzIGxlZ2l0aW1hdGUgdHJhZmZpYyB0byBmYWlsLCB0aGVuIGl0J3Mgd3Jvbmcu DQoNClRoYW5rcywNCkpha29iLg0KDQpGcm9tOiBTaWRyb3BzIFttYWlsdG86c2lkcm9wcy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2FybG9zIE0uIE1hcnRpbmV6DQpTZW50OiBUaHVy c2RheSwgSnVseSAyMCwgMjAxNyA4OjQxIEFNDQpUbzogTWF0dGhpYXMgV2FlaGxpc2NoIDxtLndh ZWhsaXNjaEBmdS1iZXJsaW4uZGU+DQpDYzogc2lkcm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtTaWRyb3BzXSBUYWxrOiBSUEtJIERlcGxveW1lbnQ6IFN0YXR1cywgQ2hhbGxlbmdlcyBhbmQg dGhlIExlYXJuaW5nLVZhbGlkYXRvcg0KDQoNCkkgd2FzIGFib3V0IHRvIGFzayBhIHF1ZXN0aW9u IG9uIHRoZSBtaWMgYnV0IHdhcyBsYXRlIHRvIHRoZSBsaW5lLiBNYXliZSBpdOKAmXMgd29ydGgg c2hhcmluZyBpdCBoZXJlOg0KDQogICogICBIb3cgd2UgZGVmaW5lIGEgUk9BIHRvIGJlIOKAnHdy b25n4oCdID8gT25lIHRoYXQgaW52YWxpZGF0ZXMgcm91dGVzIG9yIG9uZSB0aGF0IGNhdXNlcyBs ZWdpdGltYXRlIHRyYWZmaWMgdG8gYmUgZHJvcHBlZCA/DQoNCldoeT8gYmVjYXVzZSB3ZeKAmXZl IHNlZW4gaW4gbWFueSBjYXNlcyBST0FzIHRoYXQgY3JlYXRlIGxvdHMgb2YgaW52YWxpZHMgYnV0 IHZhbGlkYXRlIGEgbGVzcy1zcGVjaWZpYyByb3V0ZSB0aGF0IGNvdmVycyB0aG9zZSBpbnZhbGlk cw0KDQpJbiBhIHdheSwgdGhpcyBldmVuIGEgcG9zaXRpdmUgc2lkZS1lZmZlY3QsIHNvcnQgb2Yg dmFjdXVtLWNsZWFuaW5nIHlvdXIgcm91dGluZyB0YWJsZXMuDQoNCkkgYmVsaWV2ZSBhbmFseXpp bmcgd2hhdCBST0FzIGFyZSB3cm9uZyBpcyBxdWl0ZSBpbXBvcnRhbnQsIGJ1dCBp4oCZZCBiZWxp ZXZlIHRoaXMgcGFydGljdWxhciBjYXNlIHNob3VsZCBub3QgY291bnQgYXMgd3JvbmcuDQoNCnRo YW5rcyENCg0KL0Nhcmxvcw0KDQpPbiAxNyBKdWwgMjAxNywgYXQgMTY6MzYsIE1hdHRoaWFzIFdh ZWhsaXNjaCB3cm90ZToNCg0KdHdvIGNvbW1lbnRzIHZpYSB0aGUgbGlzdCBiZWNhdXNlIHdlIHJ1 biBvdXQgb2YgdGltZToNCg0KKDEpIEknbSB3b25kZXJpbmcgYWJvdXQgdGhlIHN0YXRlbWVudCB0 aGF0IHRoZSBxdWFsaXR5IG9mIFJPQXMgZGVjcmVhc2VzDQpvdmVyIHRpbWUuIE15IGltcHJlc3Np b24gaXMgdGhhdCB0aGUgcXVhbGl0eSBpbXByb3ZlZCBiZWNhdXNlIG9mDQpleGNlbGxlbnQgdHJh aW5pbmcgYnkgUklScyBhbmQgb3RoZXJzLg0KDQpTbGlkZSA0IHNob3dzIGFic29sdXRlIHZhbHVl cywgd2hpY2ggaXMgbm90IGhlbHBmdWwgaW4gdGhpcyBjb250ZXh0Lg0KDQoNCigyKSBSZWdhcmRp bmcgUk9WIG1lYXN1cmVtZW50czogIlNpbWlsYXIgcmVzdWx0cyBhcHBhcmVudGx5IGZyb20NCm1l YXN1cmVtZW50cyBieSBSYW5keSBCdXNoIGFuZCBvdGhlcnMgKGRpZG4ndCB5ZXQgc2VlIGRldGFp bHMpIg0KDQpEZXRhaWxzIGFyZSBhdmFpbGFibGUsIGVhc3kgdG8gZmluZCB1c2luZyBHb29nbGU6 DQoNCiogIlRvd2FyZHMgYSBSaWdvcm91cyBNZXRob2RvbG9neSBmb3IgTWVhc3VyaW5nIEFkb3B0 aW9uIG9mIFJQS0kgUm91dGUNClZhbGlkYXRpb24gYW5kIEZpbHRlcmluZyIsIGh0dHBzOi8vYXJ4 aXYub3JnL2Ficy8xNzA2LjA0MjYzLiBTb21lIG9mDQp0aGlzIHdvcmsgd2FzIGFsc28gcHJlc2Vu dGVkIGF0IHRoZSBsYXN0IFJJUEUgbWVldGluZzoNCmh0dHBzOi8vcmlwZTc0LnJpcGUubmV0L2Fy Y2hpdmVzL3ZpZGVvLzQ2Lw0KDQoNCg0KDQpDaGVlcnMNCm1hdHRoaWFzDQoNCi0tDQpNYXR0aGlh cyBXYWVobGlzY2gNCi4gRnJlaWUgVW5pdmVyc2l0YWV0IEJlcmxpbiwgQ29tcHV0ZXIgU2NpZW5j ZQ0KLi4gaHR0cDovL3d3dy5jcy5mdS1iZXJsaW4uZGUvfndhZWhsDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaWRyb3BzIG1haWxpbmcgbGlzdA0K U2lkcm9wc0BpZXRmLm9yZzxtYWlsdG86U2lkcm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wcw0K --_000_177afbdbb5424f26992196dae0219ff1XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ikx1Y2lkYSBDb25zb2xlIjsNCglwYW5vc2UtMToyIDExIDYgOSA0IDUgNCAyIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFk aW5nIDEgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjE3LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCglm b250LXdlaWdodDpib2xkO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHls ZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjE0LjVwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjsNCglmb250LXdlaWdodDpib2xkO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEzLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjsNCglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMzOTgzQzQ7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMzOTgzQzQ7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSGVhZGluZzFDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkg TGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzJFNzRCNTt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExp Z2h0IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMyRTc0QjU7fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdo dCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0RDc4O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjojNzAzMEEwOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5v cm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg4OTYxMjc1OTsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTgwNzg5NTkxNjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMzOTgzQzQiIHZsaW5rPSIjMzk4M0M0Ij4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNzAzMEEwIj5JZiBpdCBjYXVzZXMgbGVnaXRpbWF0ZSB0cmFmZmljIHRvIGZhaWws IHRoZW4gaXQncyB3cm9uZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZxdW90Oztjb2xvcjojNzAzMEEwIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtMdWNpZGEgQ29uc29sZSZx dW90Oztjb2xvcjojNzAzMEEwIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gU2lkcm9wcyBbbWFpbHRvOnNp ZHJvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2FybG9zIE0uIE1h cnRpbmV6PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3IDg6NDEgQU08 YnI+DQo8Yj5Ubzo8L2I+IE1hdHRoaWFzIFdhZWhsaXNjaCAmbHQ7bS53YWVobGlzY2hAZnUtYmVy bGluLmRlJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2lkcm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1NpZHJvcHNdIFRhbGs6IFJQS0kgRGVwbG95bWVudDogU3RhdHVzLCBDaGFs bGVuZ2VzIGFuZCB0aGUgTGVhcm5pbmctVmFsaWRhdG9yPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5JIHdhcyBhYm91dCB0byBhc2sgYSBxdWVzdGlvbiBvbiB0aGUgbWljIGJ1dCB3 YXMgbGF0ZSB0byB0aGUgbGluZS4gTWF5YmUgaXTigJlzIHdvcnRoIHNoYXJpbmcgaXQgaGVyZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Ib3cgd2UgZGVmaW5lIGEgUk9BIHRvIGJl IOKAnHdyb25n4oCdID8gT25lIHRoYXQgaW52YWxpZGF0ZXMgcm91dGVzIG9yIG9uZSB0aGF0IGNh dXNlcyBsZWdpdGltYXRlIHRyYWZmaWMgdG8gYmUgZHJvcHBlZCA/PG86cD48L286cD48L3NwYW4+ PC9saT48L3VsPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPldoeT8gYmVjYXVzZSB3ZeKAmXZlIHNlZW4gaW4gbWFueSBjYXNlcyBST0Fz IHRoYXQgY3JlYXRlIGxvdHMgb2YgaW52YWxpZHMgYnV0IHZhbGlkYXRlIGEgbGVzcy1zcGVjaWZp YyByb3V0ZSB0aGF0IGNvdmVycyB0aG9zZSBpbnZhbGlkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5JbiBhIHdheSwgdGhpcyBldmVuIGEgcG9zaXRpdmUgc2lkZS1lZmZlY3QsIHNvcnQgb2YgdmFj dXVtLWNsZWFuaW5nIHlvdXIgcm91dGluZyB0YWJsZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PkkgYmVsaWV2ZSBhbmFseXppbmcgd2hhdCBST0FzIGFyZSB3cm9uZyBpcyBxdWl0ZSBpbXBvcnRh bnQsIGJ1dCBp4oCZZCBiZWxpZXZlIHRoaXMgcGFydGljdWxhciBjYXNlIHNob3VsZCBub3QgY291 bnQgYXMgd3JvbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnRoYW5rcyE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+L0NhcmxvczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5PbiAxNyBKdWwgMjAx NywgYXQgMTY6MzYsIE1hdHRoaWFzIFdhZWhsaXNjaCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdp bi1sZWZ0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxwPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3NzciPnR3byBjb21tZW50cyB2aWEgdGhlIGxpc3QgYmVjYXVzZSB3ZSBydW4gb3V0IG9m IHRpbWU6PGJyPg0KPGJyPg0KKDEpIEknbSB3b25kZXJpbmcgYWJvdXQgdGhlIHN0YXRlbWVudCB0 aGF0IHRoZSBxdWFsaXR5IG9mIFJPQXMgZGVjcmVhc2VzPGJyPg0Kb3ZlciB0aW1lLiBNeSBpbXBy ZXNzaW9uIGlzIHRoYXQgdGhlIHF1YWxpdHkgaW1wcm92ZWQgYmVjYXVzZSBvZjxicj4NCmV4Y2Vs bGVudCB0cmFpbmluZyBieSBSSVJzIGFuZCBvdGhlcnMuPGJyPg0KPGJyPg0KU2xpZGUgNCBzaG93 cyBhYnNvbHV0ZSB2YWx1ZXMsIHdoaWNoIGlzIG5vdCBoZWxwZnVsIGluIHRoaXMgY29udGV4dC48 YnI+DQo8YnI+DQo8YnI+DQooMikgUmVnYXJkaW5nIFJPViBtZWFzdXJlbWVudHM6ICZxdW90O1Np bWlsYXIgcmVzdWx0cyBhcHBhcmVudGx5IGZyb208YnI+DQptZWFzdXJlbWVudHMgYnkgUmFuZHkg QnVzaCBhbmQgb3RoZXJzIChkaWRuJ3QgeWV0IHNlZSBkZXRhaWxzKSZxdW90Ozxicj4NCjxicj4N CkRldGFpbHMgYXJlIGF2YWlsYWJsZSwgZWFzeSB0byBmaW5kIHVzaW5nIEdvb2dsZTo8YnI+DQo8 YnI+DQoqICZxdW90O1Rvd2FyZHMgYSBSaWdvcm91cyBNZXRob2RvbG9neSBmb3IgTWVhc3VyaW5n IEFkb3B0aW9uIG9mIFJQS0kgUm91dGU8YnI+DQpWYWxpZGF0aW9uIGFuZCBGaWx0ZXJpbmcmcXVv dDssIDxhIGhyZWY9Imh0dHBzOi8vYXJ4aXYub3JnL2Ficy8xNzA2LjA0MjYzIj48c3BhbiBzdHls ZT0iY29sb3I6Izc3Nzc3NyI+aHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE3MDYuMDQyNjM8L3NwYW4+ PC9hPi4gU29tZSBvZjxicj4NCnRoaXMgd29yayB3YXMgYWxzbyBwcmVzZW50ZWQgYXQgdGhlIGxh c3QgUklQRSBtZWV0aW5nOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vcmlwZTc0LnJpcGUubmV0L2Fy Y2hpdmVzL3ZpZGVvLzQ2LyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPmh0dHBzOi8vcmlw ZTc0LnJpcGUubmV0L2FyY2hpdmVzL3ZpZGVvLzQ2Lzwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KQ2hlZXJzPGJyPg0KbWF0dGhpYXM8YnI+DQo8YnI+DQotLSA8YnI+DQpN YXR0aGlhcyBXYWVobGlzY2g8YnI+DQouIEZyZWllIFVuaXZlcnNpdGFldCBCZXJsaW4sIENvbXB1 dGVyIFNjaWVuY2U8YnI+DQouLiA8YSBocmVmPSJodHRwOi8vd3d3LmNzLmZ1LWJlcmxpbi5kZS9+ d2FlaGwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5odHRwOi8vd3d3LmNzLmZ1LWJlcmxp bi5kZS9+d2FlaGw8L3NwYW4+PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KU2lkcm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86U2lkcm9wc0BpZXRmLm9yZyI+U2lkcm9wc0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHJvcHMi PjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpZHJvcHM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_177afbdbb5424f26992196dae0219ff1XCHALN014ciscocom_-- From nobody Thu Jul 20 10:22:51 2017 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 5A4F612700F for ; Thu, 20 Jul 2017 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.onmicrosoft.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 3DrHeZG2pmi2 for ; Thu, 20 Jul 2017 10:22:45 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0099.outbound.protection.outlook.com [23.103.200.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AD6126B6D for ; Thu, 20 Jul 2017 10:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8DI00HEyk+iRPju/0ZTrNuUYuMOUPkxfNGL/H7f16jY=; b=s4GZXPl7MjlhGGUPkGTbuUJqxbvi+wZn8iY0rmVbENiDJ1wdyE2B8HDmfp+V1OGhuNdMFgA1ZfMIJGoQsFA6G1YVPaREY5yxUuWh6tRVEiA4pNTwsdbP0ugjbOwp/FekCLkdNz1UMSCGK9/kN8/ucoLALDqPuuTpQnhRbN8o7Ek= Received: from DM5PR09MB1436.namprd09.prod.outlook.com (10.173.171.14) by DM5PR09MB1436.namprd09.prod.outlook.com (10.173.171.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Thu, 20 Jul 2017 17:22:44 +0000 Received: from DM5PR09MB1436.namprd09.prod.outlook.com ([10.173.171.14]) by DM5PR09MB1436.namprd09.prod.outlook.com ([10.173.171.14]) with mapi id 15.01.1261.024; Thu, 20 Jul 2017 17:22:44 +0000 From: "Montgomery, Douglas (Fed)" To: "sidrops@ietf.org" Thread-Topic: NCCoE Secure Inter-Domain Routing Project - request for industry input. Thread-Index: AQHTAXzMvcyRtIFBz0m39T2+L3ft3g== Date: Thu, 20 Jul 2017 17:22:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.218.149] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1436; 7:1hVa7kC5RbbySkY7EMvNyZfZ2eNUQMTljX+WM49adbtWljLOtkrNf+ANQcmKeqIKl2uAkX8R6wPXlfenbcNzwjHuLLkzHDrI1x/GGoX8dU67BLgXXMpZfBBCBFe8mvnE+WMIyYfEcRMRuZABn0vXYipJIqoLnKPM2O8vROGQTXhe5O1UMc5tr+awmsGCGgOkatHV5IDLCz7N0MZy4kD6FxKsq4sG84XWG516/HX1rZNMGOtl4McNJj4EN/ljw0ArUCx5qDw5qcYNMRw4phaXZxD8XoNc4dVIaemvtRr6TvQ4oZbRqP87eOB6SO+6OIy06Mc4pnJF+TlTb9Fox31AWkeFQuQ7DgVryUCBGJ0p7+J1A5h/zm8/H1T4ZiuPHkLnYbnMUcs/KDWSex1ii58zToGXe7gHYl45ENiGMfWQn1wARIlFwGX5F72FgT1ZKoEVQUQo3BmQJU7d8CWSVIgqiicknVZhuR4Kes0uV8bELUZCiYGEiqBMvyrwCEzEv2xo6udYZfGT7s/CQJvckvKAlMolhdl8+NaPp8E1gvziqHQD543awmDYIA3O1I50UA+eN4s6cUnsFpH2trqQWZL8U5t074TqBLMPl69KV1ILiRCY7oF1P56hBbK1NlF6MJ5XUju9ySHC6QiBKMpC8U3L8YD+Zc6tOi2iG/hoDr3CiW1HhGTn9dwDhsVbbuJDBQONcpenluwkn9fh/vux69ttI7xK6n4a0m8KLZOGo8ONkb5rbqxB8Jk+qFnT5t/7XGcRYH+OnVbhwts6AOBCnoeJwxd6u+7bwOb1gNbYO4we5rI= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39860400002)(39840400002)(39400400002)(39850400002)(39450400003)(39410400002)(6116002)(5660300001)(6506006)(86362001)(3280700002)(7736002)(38730400002)(5640700003)(6916009)(2351001)(110136004)(3846002)(966005)(6512007)(102836003)(81166006)(8676002)(1730700003)(6436002)(6306002)(3660700001)(229853002)(6486002)(2906002)(77096006)(53936002)(99286003)(236005)(50986999)(4001350100001)(54356999)(14454004)(25786009)(54896002)(66066001)(478600001)(83506001)(2501003)(189998001)(8936002)(2473003)(606006)(36756003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1436; H:DM5PR09MB1436.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: e2cb463f-a9ad-44fc-b1e3-08d4cf93eeee x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR09MB1436; x-ms-traffictypediagnostic: DM5PR09MB1436: x-exchange-antispam-report-test: UriScan:(125551606395959)(65766998875637)(72170088055959)(236129657087228)(192374486261705)(5213294742642); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1436; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1436; x-forefront-prvs: 0374433C81 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D5965C8F5601Cdougmnistgov_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 17:22:44.0373 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1436 Archived-At: Subject: [Sidrops] FW: NCCoE Secure Inter-Domain Routing Project - request for industry input. X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 17:22:49 -0000 --_000_D5965C8F5601Cdougmnistgov_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgd2FzbuKAmXQgdGltZSBvbiB0aGUgYWdlbmRhIHRvIGRpc2N1c3MgdGhpcyBpbiBzaWRy b3BzIHRoaXMgd2VlaywNCmJ1dCBJIHdhbnRlZCB0byBzaGFyZSB0aGUgbm90ZSBiZWxvdyBoZXJl IChwcmV2aW91c2x5IHNlbnQgdG8gdGhlDQpuYW5vZyBsaXN0KS4NCg0KV2hpbGUgdGhlIHBhZ2Ug YmVsb3cgd2lsbCBzYXkgdGhhdCB0aGUgcHVibGljIGNvbW1lbnQgcGVyaW9kIG9uIHRoZQ0KcHJv cG9zZWQgcHJvamVjdCBoYXMgcGFzc2VkLCB3ZSBzdGlsbCBzZWVrIGlucHV0IGZyb20gdGhlIGlu ZHVzdHJ5LA0KbWFpbmx5IGluIHRoZSBmb3JtIG9mIGtleSBzcGVjaWZpYyB0ZWNobmljYWwgcXVl c3Rpb25zIG9yIGlzc3Vlcw0KKGRlcGxveW1lbnQgc2NlbmFyaW9zLCByb2J1c3RuZXNzLCByZXNw b25zaXZlbmVzcywgaW50ZXJvcGVyYWJpbGl0eSkNCnRoYXQgc2hvdWxkIGJlIGludmVzdGlnYXRl ZCAvIGRlbW9uc3RyYXRlZC4NCg0KSSBoYXZlIHNwb2tlIHRvIHNvbWUgb2YgeW91IGluZGl2aWR1 YWxseSBhYm91dCB0aGlzLCBidXQgd2Ugc29saWNpdA0KaW5wdXQgZnJvbSBldmVyeW9uZS4NCg0K Q29tbWVudHMgY2FuIGJlIHNlbnQgdG8gc2lkci1uY2NvZUBuaXN0LmdvdjxtYWlsdG86c2lkci1u Y2NvZUBuaXN0Lmdvdj4gb3IgbWUgYW5kIEkgd2lsbCByZWxheS4NCg0KVGhhbmtzDQpkb3VnbQ0K PT09PT09PT09PT09PT09PT09PT09PQ0KDQpUaGUgTmF0aW9uYWwgQ3liZXJzZWN1cml0eSBDZW50 ZXIgb2YgRXhjZWxsZW5jZSAoTkNDb0UpIHJlcXVlc3RzIGNvbW11bml0eQ0KaW5wdXQgb24gYSBw cm9wb3NlZCBwcm9qZWN0IGVudGl0bGVkOiBTZWN1cmUgSW50ZXItRG9tYWluIFJvdXRpbmcsIFBh cnQgMToNClJvdXRlLUhpamFja3MuDQoNCmh0dHBzOi8vbmNjb2UubmlzdC5nb3YvcHJvamVjdHMv YnVpbGRpbmctYmxvY2tzL3NlY3VyZS1pbnRlci1kb21haW4tcm91dGluZw0KDQpUaGUgb2JqZWN0 aXZlIG9mIHRoZSBwcm9qZWN0IGlzIHRvIGV4YW1pbmUgYW5kIGRlbW9uc3RyYXRlIHRoZSBzdGF0 ZSBvZg0KdGhlIFJQS0kgYW5kIEJHUCBPcmlnaW4gVmFsaWRhdGlvbiB0ZWNobm9sb2dpZXMgaW4g cmVhbGlzdGljIHNjZW5hcmlvcyBhbmQNCnRvIGFkZHJlc3MgaWRlbnRpZmllZCBjb25jZXJucyB3 aXRoIHRoZWlyIGRlcGxveW1lbnQgYW5kIHVzZSAoZS5nLiwNCnNlY3VyaXR5LCByb2J1c3RuZXNz LCByZXNwb25zaXZlbmVzcywgbWFuYWdlbWVudCAvIG1vbml0b3JpbmcsIG11bHRpLXZlbmRvcg0K aW50ZXItb3BlcmF0aW9uKS4NCg0KVGhpcyByZXF1ZXN0IGlzIGZvciBpbmR1c3RyeSBpbnB1dCBv biB0aGUgdGhlIHByb3Bvc2VkIHByb2plY3QgcGxhbi4gIEluDQpwYXJ0aWN1bGFyIHdlIHNlZWsg aW5wdXQgZnJvbSBib3RoIG5ldHdvcmsgb3BlcmF0b3JzIGFuZCBlbnRlcnByaXNlcyBvbg0KcHJh Y3RpY2FsIHF1ZXN0aW9ucywgaXNzdWVzIGFuZCBiYXJyaWVycyB0byBhZG9wdGlvbiBhbmQgc3Vn Z2VzdGlvbnMgZm9yDQpob3cgdGhlc2UgY291bGQgYmUgYWRkcmVzc2VkIGluIHRoZSBwcm9qZWN0 Lg0KDQpQbGVhc2Ugc2VlIHRoZSBsaW5rIGFib3ZlIGZvciBlbWFpbCBhZGRyZXNzIGZvciBzdWJt aXR0aW5nIGNvbW1lbnRzIGFuZA0KaG93IHlvdSBjYW4gam9pbiBhIGNvbW11bml0eSBvZiBpbnRl cmVzdCBmb3IgdGhlIHByb2plY3QuDQoNCipUaGUgaW50ZW50aW9uIGlzIG5vdCB0byBoYXZlIHRo ZSBkaXNjdXNzaW9uIGhlcmUgb24gdGhlIGFpcmRyb3BzIGxpc3QuKg0KDQpUaGFua3MNCmRvdWdt DQotLQ0KRG91ZyBNb250Z29tZXJ5LCBNZ3IgSW50ZXJuZXQgJiBTY2FsYWJsZSBTeXN0ZW1zIFJl c2VhcmNoIGF0IE5JU1QvSVRML0FOVEQNCg0K --_000_D5965C8F5601Cdougmnistgov_ Content-Type: text/html; charset="utf-8" Content-ID: <220F409E2B8150418FD05E40A1EDF3CD@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQ291cmllciwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+VGhlcmUgd2FzbuKAmXQgdGltZSBv biB0aGUgYWdlbmRhIHRvIGRpc2N1c3MgdGhpcyBpbiBzaWRyb3BzIHRoaXMgd2Vlayw8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+YnV0IEkgd2FudGVk IHRvIHNoYXJlIHRoZSBub3RlIGJlbG93IGhlcmUgKHByZXZpb3VzbHkgc2VudCB0byB0aGUmbmJz cDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+bmFu b2cgbGlzdCkuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFy ZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRh cmQ7Ij5XaGlsZSB0aGUgcGFnZSBiZWxvdyB3aWxsIHNheSB0aGF0IHRoZSBwdWJsaWMgY29tbWVu dCBwZXJpb2Qgb24gdGhlPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1z dGFuZGFyZDsiPnByb3Bvc2VkIHByb2plY3QgaGFzIHBhc3NlZCwgd2Ugc3RpbGwgc2VlayBpbnB1 dCBmcm9tIHRoZSBpbmR1c3RyeSw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN0YW5kYXJkOyI+bWFpbmx5IGluIHRoZSBmb3JtIG9mIGtleSBzcGVjaWZpYyB0ZWNobmlj YWwgcXVlc3Rpb25zIG9yIGlzc3VlczwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3RhbmRhcmQ7Ij4oZGVwbG95bWVudCBzY2VuYXJpb3MsIHJvYnVzdG5lc3MsIHJlc3Bv bnNpdmVuZXNzLCBpbnRlcm9wZXJhYmlsaXR5KSZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij50aGF0IHNob3VsZCBiZSBpbnZlc3RpZ2F0ZWQg LyBkZW1vbnN0cmF0ZWQuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1z dGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQt c3RhbmRhcmQ7Ij5JIGhhdmUgc3Bva2UgdG8gc29tZSBvZiB5b3UgaW5kaXZpZHVhbGx5IGFib3V0 IHRoaXMsIGJ1dCB3ZSBzb2xpY2l0PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPmlucHV0IGZyb20gZXZlcnlvbmUuPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5Db21tZW50cyBjYW4gYmUgc2VudCB0byZu YnNwOzxhIGhyZWY9Im1haWx0bzpzaWRyLW5jY29lQG5pc3QuZ292IiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsiPnNpZHItbmNjb2VAbmlzdC5nb3Y8L2E+Jm5ic3A7b3IgbWUgYW5kIEkgd2lsbCByZWxh eS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPlRo YW5rczwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5k b3VnbTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij49 PT09PT09PT09PT09PT09PT09PT09PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3RhbmRhcmQ7Ij5UaGUgTmF0aW9uYWwgQ3liZXJzZWN1cml0eSBDZW50ZXIgb2YgRXhj ZWxsZW5jZSAoTkNDb0UpIHJlcXVlc3RzIGNvbW11bml0eTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5pbnB1dCBvbiBhIHByb3Bvc2VkIHByb2plY3Qg ZW50aXRsZWQ6IFNlY3VyZSBJbnRlci1Eb21haW4gUm91dGluZywgUGFydCAxOjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5Sb3V0ZS1IaWphY2tzLjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGEgaHJl Zj0iaHR0cHM6Ly9uY2NvZS5uaXN0Lmdvdi9wcm9qZWN0cy9idWlsZGluZy1ibG9ja3Mvc2VjdXJl LWludGVyLWRvbWFpbi1yb3V0aW5nIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiPmh0dHBzOi8vbmNj b2UubmlzdC5nb3YvcHJvamVjdHMvYnVpbGRpbmctYmxvY2tzL3NlY3VyZS1pbnRlci1kb21haW4t cm91dGluZzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5k YXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFu ZGFyZDsiPlRoZSBvYmplY3RpdmUgb2YgdGhlIHByb2plY3QgaXMgdG8gZXhhbWluZSBhbmQgZGVt b25zdHJhdGUgdGhlIHN0YXRlIG9mPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPnRoZSBSUEtJIGFuZCBCR1AgT3JpZ2luIFZhbGlkYXRpb24gdGVjaG5v bG9naWVzIGluIHJlYWxpc3RpYyBzY2VuYXJpb3MgYW5kPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPnRvIGFkZHJlc3MgaWRlbnRpZmllZCBjb25jZXJu cyB3aXRoIHRoZWlyIGRlcGxveW1lbnQgYW5kIHVzZSAoZS5nLiw8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+c2VjdXJpdHksIHJvYnVzdG5lc3MsIHJl c3BvbnNpdmVuZXNzLCBtYW5hZ2VtZW50IC8gbW9uaXRvcmluZywgbXVsdGktdmVuZG9yPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPmludGVyLW9wZXJh dGlvbikuJm5ic3A7Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtp dC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJr aXQtc3RhbmRhcmQ7Ij5UaGlzIHJlcXVlc3QgaXMgZm9yIGluZHVzdHJ5IGlucHV0IG9uIHRoZSB0 aGUgcHJvcG9zZWQgcHJvamVjdCBwbGFuLiZuYnNwOyZuYnNwO0luPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPnBhcnRpY3VsYXIgd2Ugc2VlayBpbnB1 dCBmcm9tIGJvdGggbmV0d29yayBvcGVyYXRvcnMgYW5kIGVudGVycHJpc2VzIG9uPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPnByYWN0aWNhbCBxdWVz dGlvbnMsIGlzc3VlcyBhbmQgYmFycmllcnMgdG8gYWRvcHRpb24gYW5kIHN1Z2dlc3Rpb25zIGZv ciZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7 Ij5ob3cgdGhlc2UgY291bGQgYmUgYWRkcmVzc2VkIGluIHRoZSBwcm9qZWN0LjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+UGxlYXNlIHNlZSB0aGUg bGluayBhYm92ZSBmb3IgZW1haWwgYWRkcmVzcyBmb3Igc3VibWl0dGluZyBjb21tZW50cyBhbmQ8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+aG93IHlv dSBjYW4gam9pbiBhIGNvbW11bml0eSBvZiBpbnRlcmVzdCBmb3IgdGhlIHByb2plY3QuPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij4qVGhlIGludGVu dGlvbiBpcyBub3QgdG8gaGF2ZSB0aGUgZGlzY3Vzc2lvbiBoZXJlIG9uIHRoZSBhaXJkcm9wcyBs aXN0Lio8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+ PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsi PlRoYW5rczwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7 Ij5kb3VnbTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7 Ij4tLTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5E b3VnIE1vbnRnb21lcnksIE1nciBJbnRlcm5ldCAmYW1wOyBTY2FsYWJsZSBTeXN0ZW1zIFJlc2Vh cmNoIGF0IE5JU1QvSVRML0FOVEQ8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_D5965C8F5601Cdougmnistgov_-- From nobody Fri Jul 21 00:42:55 2017 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 C7FA1124217 for ; Fri, 21 Jul 2017 00:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 lGk_t-w5ZVpa for ; Fri, 21 Jul 2017 00:42:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 B3689131748 for ; Fri, 21 Jul 2017 00:42:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dYSaH-0007pz-Qb; Fri, 21 Jul 2017 07:42:50 +0000 Date: Fri, 21 Jul 2017 09:42:49 +0200 Message-ID: From: Randy Bush To: "Carlos M. Martinez" Cc: sidrops@ietf.org In-Reply-To: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 07:42:54 -0000 < pedantry > > - How we define a ROA to be $B!H(Bwrong$B!I(B ? One that invalidates routes or > one that causes legitimate traffic to be dropped ? neither. a roa is 'wrong' when it does not validate up to the iana TA or the political TA kludge of the season. a roa may cover but not validate a particular bgp announcement; though that announcement may be validated by a different roa. a roa may not validate a particular announcement which it covers for which there are no other roas. the roa is neither right nor wrong; it merely disagrees with the current bgp announcements. which needs to be changed is not obviously determinable. of course there was the work in new mexico a dozen years ago to create roas to match the bgp table with a bit of delay. we all laughed. randy From nobody Fri Jul 21 00:43:33 2017 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 2AB8912783A for ; Fri, 21 Jul 2017 00:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 O854l8aIbVTQ for ; Fri, 21 Jul 2017 00:43:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 52179124217 for ; Fri, 21 Jul 2017 00:43:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dYSau-0007qR-Sq; Fri, 21 Jul 2017 07:43:29 +0000 Date: Fri, 21 Jul 2017 09:43:28 +0200 Message-ID: From: Randy Bush To: "Jakob Heitz (jheitz)" Cc: sidrops@ietf.org In-Reply-To: <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 07:43:31 -0000 > If it causes legitimate traffic to fail, then it's wrong. that's the traffic with the evil bit off, right? randy From nobody Fri Jul 21 06:15:51 2017 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 35DF0131D1C; Fri, 21 Jul 2017 06:15:49 -0700 (PDT) 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 SdVaDNv2HBWD; Fri, 21 Jul 2017 06:15:47 -0700 (PDT) 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 1339F131471; Fri, 21 Jul 2017 06:15:46 -0700 (PDT) X-Envelope-To: draft-ietf-sidrops-route-server-rpki-light@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 v6LDFd3f048084 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2017 14:15:39 +0100 (IST) (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 Message-ID: <5971FE7B.6060607@foobar.org> Date: Fri, 21 Jul 2017 14:15:39 +0100 From: Nick Hilliard User-Agent: Postbox 5.0.16 (Macintosh/20170718) MIME-Version: 1.0 To: Aris Lambrianidis CC: "sidrops@ietf.org" , draft-ietf-sidrops-route-server-rpki-light@ietf.org References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 13:15:49 -0000 Aris, the concerns I brought up about this draft on jan 13 / jan 14 have not been addressed in -01 or -02. The concerns were basically: this is not how to solve the problem of making things easier for route server clients + the reasons why. Nick Aris Lambrianidis wrote: > Hello all, > > As a quick note, Daniel and I are in Prague, at IETF99. Daniel will be > here until Tuesday afternoon and I’ll be here > for the entire week, should you have any concerns, comments, or > questions. We’re looking into moving things forward > (read: go for WG Last Call), so we’d appreciate any feedback, in person > or by email. > > --Aris > > >> On 11 Apr 2017, at 18:15, Thomas King > > wrote: >> >> Hi all, >> >> we have worked on the feedback we received through many channels (e.g. >> this mailing list): >> - Clarification of the “Security Considerations” section. Please let >> us know if you think a security issue is not tackled. >> - The feedback told us that different modes of operation for how >> “invalid” and “not found” routes should be handled needs to be >> addressed. For this, section “BGP Prefix Origin Validation State >> Utilized at Route-Servers” was added. >> - House-Keeping (e.g. update references, fix typos) >> >> Best regards, >> Thomas >> >> >> On 11/04/2017, 18:14, "Sidrops on behalf of internet-drafts@ietf.org >> " > on behalf of >> 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 of the IETF. >> >> Title : Signaling Prefix Origin Validation >> Results from a Route Server to Peers >> Authors : Thomas King >> Daniel Kopp >> Aristidis Lambrianidis >> Arnaud Fenioux >> Filename : draft-ietf-sidrops-route-server-rpki-light-02.txt >> Pages : 7 >> Date : 2017-04-11 >> >> Abstract: >> This document defines the usage of the BGP Prefix Origin Validation >> State Extended Community [RFC8097] to signal prefix origin >> validation >> results from a route server to its peers. Upon reception of prefix >> origin validation results peers can use this information in their >> local routing decision process. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-light/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-route-server-rpki-light-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-route-server-rpki-light-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 From nobody Sun Jul 23 11:06:53 2017 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 6886413146E for ; Sun, 23 Jul 2017 11:06:51 -0700 (PDT) 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 g_mStWszdOQY for ; Sun, 23 Jul 2017 11:06:50 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 6DFBD129B61 for ; Sun, 23 Jul 2017 11:06:50 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 21so60575961qtx.3 for ; Sun, 23 Jul 2017 11:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N8rzFYIea/3i+9ZkvWMzzp1ITZdHqOUEvXiIx1d1xtE=; b=ffj0vV6Ud9A60OXS1IolKAtolGMWSPBP/+aC2D/GD8JO5KoaerKu0yZ0i+oAdEW3DK M9uT5fmzPfGIPlJZNHQ1Fmux/3bJ2/gYTcg0FI/lD+9hxvwOO5fCz5QdMKuC2FC7Dl9o XLUkFcPkP/bfzZOFGVmmkWL3ToR8kXixfFC4SLrwhT4AgbPFqmMDOYPt/hhBlHjo3nUC Mv9kEbo/PR2EZ0GWLV3ctDrPE7zKjt6OuPpLuMTU4hHcTEnSM6kq5Yp2tslS4PWPvR17 ozEDEcZO1WCtC+a7mDerFboyHpYVNC8RFjpldndYQzNeHwy/h1pIHKVJhLPs7LOcwLRZ R/2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N8rzFYIea/3i+9ZkvWMzzp1ITZdHqOUEvXiIx1d1xtE=; b=OHz6ftnkSgfOnVGq7ZDrrtuPKf51Tp7MHo2eIkRXTaGl9J6iHsA81uV6ZR4fRfKZjm 0CN8GvKSxQbPPBO1wMcY9JSCf+B7H7PLeT+Oo6dkjw1mXUKkPzwcvxTmHuVhy9LhM5AU oyZaR/EdppTb3ZlJwMc90T2K9BHWdeIlhykl5KVac/wl6BF7+OwV96F5b4ZHkYeYup4O 5nRBR+h6rU2vN7U+mCxo1IXBclhIgnaU5HuKp64kk2B1pYP0xVk46NzkgjnNcizacLzW jkxnaUits22td5gJhOL+0fPoT8Rp1QVH2mAszgD1ZLqaELWR5wlE9u2FBEyOsfak+mfD n5Yw== X-Gm-Message-State: AIVw1104JcOmjTWV+QeSi993d1ziL5xAis/ZCguojdLzCuyjGxlEj9qI TyIizAeFcyPdY8I9YgqpKLaiNfJ62w== X-Received: by 10.200.38.70 with SMTP id v6mr19323237qtv.267.1500833209546; Sun, 23 Jul 2017 11:06:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.39 with HTTP; Sun, 23 Jul 2017 11:06:49 -0700 (PDT) In-Reply-To: References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> From: Christopher Morrow Date: Sun, 23 Jul 2017 20:06:49 +0200 Message-ID: To: Randy Bush Cc: "Carlos M. Martinez" , sidrops@ietf.org Content-Type: multipart/alternative; boundary="001a114036c0527c8b0554fff6c3" Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jul 2017 18:06:51 -0000 --001a114036c0527c8b0554fff6c3 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 21, 2017 at 9:42 AM, Randy Bush wrote: > > of course there was the work in new mexico a dozen years ago to create > roas to match the bgp table with a bit of delay. we all laughed. > I took from the preso here that there was work going on to make the NM tooling (or similar) more operationally useful.. that along with some reporting / alerting anyway. --001a114036c0527c8b0554fff6c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 21, 2017 at 9:42 AM, Randy Bush <randy@psg.com> = wrote:

of course there was the work in new mexico a dozen years ago to create
roas to match the bgp table with a bit of delay.=C2=A0 we all laughed.
<= /blockquote>

I took from the preso here that there was w= ork going on to make the NM tooling (or similar) more operationally useful.= . that along with some reporting / alerting anyway.=C2=A0
=
--001a114036c0527c8b0554fff6c3-- From nobody Sun Jul 23 11:47:34 2017 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 92C5013178D for ; Sun, 23 Jul 2017 11:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 UnYJAV3OialC for ; Sun, 23 Jul 2017 11:47:31 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BA913178B for ; Sun, 23 Jul 2017 11:47:30 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 85F665C3F for ; Sun, 23 Jul 2017 18:47:30 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 6F85CA32091 for ; Sun, 23 Jul 2017 14:47:19 -0400 (EDT) Date: Sun, 23 Jul 2017 14:47:19 -0400 From: Rob Austein To: sidrops@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20170723184719.6F85CA32091@minas-ithil.hactrn.net> Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 23 Jul 2017 18:47:32 -0000 I think we should move from rsync to HTTPS for fetching TALs, yes, so I think the WG should be doing something of this general nature. How many stages...I think at this point I would be most comfortable with making HTTPS mandatory and rsync optional. My own RP implementation has supported both schemes for years (albeit only on a development branch until about a year ago). I don't know the status of the other RP implementations, but the authors of those can speak for themselves. Regarding Job's request that we change format to JSON or XML or ..., I must respectfully disagree. The current format was deliberately chosen to be as simple as possible, no presentation-layer-du-jour parsing library required. ASN.1 is enough fun for somebody who has to implement an RP in an embedded environment, but that is required, because all of the objects being validated are ASN.1. Let's please not add a requirement for another whole parser just for TALs when the trivial line-oriented thing we have now will suffice. From nobody Sun Jul 23 17:22:33 2017 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 6CA8412F28B for ; Sun, 23 Jul 2017 17:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 mLTgXIggdzrS for ; Sun, 23 Jul 2017 17:22:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3421912ECC1 for ; Sun, 23 Jul 2017 17:22:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dZR8n-00020v-5B; Mon, 24 Jul 2017 00:22:29 +0000 Date: Mon, 24 Jul 2017 09:22:27 +0900 Message-ID: From: Randy Bush To: Christopher Morrow Cc: "Carlos M. Martinez" , sidrops@ietf.org In-Reply-To: References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 00:22:32 -0000 >> of course there was the work in new mexico a dozen years ago to create >> roas to match the bgp table with a bit of delay. we all laughed. > > I took from the preso here that there was work going on to make the NM > tooling (or similar) more operationally useful.. that along with some > reporting / alerting anyway. in which it was shown that the length of time spammers/attackers mis-announce space turns out to have a long and fat tail. randy From nobody Mon Jul 24 03:39:34 2017 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 0D92F131C83 for ; Mon, 24 Jul 2017 03:39:33 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 4Id3TUTIihNV for ; Mon, 24 Jul 2017 03:39:31 -0700 (PDT) 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 80753131C81 for ; Mon, 24 Jul 2017 03:39:31 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dZalq-00020V-Jy; Mon, 24 Jul 2017 12:39:27 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-212.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dZalq-0004L5-Fq; Mon, 24 Jul 2017 12:39:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <20170723184719.6F85CA32091@minas-ithil.hactrn.net> Date: Mon, 24 Jul 2017 12:39:25 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170723184719.6F85CA32091@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07199ba95d8bee254c255bffafa1b4a9d135 Archived-At: Subject: Re: [Sidrops] HTTPS in TALs X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 10:39:33 -0000 > On 23 Jul 2017, at 20:47, Rob Austein wrote: >=20 > I think we should move from rsync to HTTPS for fetching TALs, yes, so > I think the WG should be doing something of this general nature. At this point agreeing on the direction is the most important point to = me. > How many stages...I think at this point I would be most comfortable > with making HTTPS mandatory and rsync optional. That said, I can=E2=80=99t help myself ;) Why? If HTTPS is mandatory to implement for both CAs and RPs, what = operational concern is addressed by allowing optional rsync in the same = TAL in addition? Again, I sympathise that CAs and RPs (including ours) need to time to = move, but to me it=E2=80=99s much simpler to address that by having = RFC7730 and 7730-bis (HTTPS only) TALs defined, and agreeing on a = strategy to allow the use of -bis by CAs, support them in RPs, and once = the 5 RIR TAs and 3 RPs have moved, discontinuing 7730 (rsync only). = Guiding this process in subsequent RFC updates seems like unnecessary = overhead to me. Still, I would rather have that, and progress, if I am = alone in this.. To me the end goal is what counts here. > My own RP implementation has supported both schemes for years (albeit > only on a development branch until about a year ago). I don't know > the status of the other RP implementations, but the authors of those > can speak for themselves. We don=E2=80=99t yet support in production I believe, but I think we had = code on a development branch when working on RRDP - in any case this = will be trivial to add for us. (And beneficial even because it will make automated scenario testing = easier of our CA code publishing with our Publication Server, and RP = validating and expecting specific results - without the need for rsync) > Regarding Job's request that we change format to JSON or XML or ..., > I must respectfully disagree. The current format was deliberately > chosen to be as simple as possible, no presentation-layer-du-jour > parsing library required. ASN.1 is enough fun for somebody who has to > implement an RP in an embedded environment, but that is required, > because all of the objects being validated are ASN.1. Let's please > not add a requirement for another whole parser just for TALs when the > trivial line-oriented thing we have now will suffice. While I would have been happier with JSON or XML in the first place I = don=E2=80=99t see a need to change the general format now. We already know how to parse the current TALs - the only change is in = the scheme used in URIs - leaving the format as-is will be least = intrusive for existing deployment at this point. >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 From nobody Tue Jul 25 06:49:37 2017 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 C7557127869 for ; Tue, 25 Jul 2017 06:49:34 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 HS4Zi5n559Zv for ; Tue, 25 Jul 2017 06:49:32 -0700 (PDT) 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 6FC8E129A96 for ; Tue, 25 Jul 2017 06:49:32 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1da0DJ-0001r6-6k; Tue, 25 Jul 2017 15:49:30 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-196.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1da0DJ-0006F2-2X; Tue, 25 Jul 2017 15:49:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> Date: Tue, 25 Jul 2017 15:49:28 +0200 Cc: "Carlos M. Martinez" , Matthias Waehlisch , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <78F49BAC-F0F2-4712-862A-BCFA1A9DC35D@ripe.net> References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07198d73f28c16dfee394677c38a82454f31 Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 13:49:35 -0000 Hi, Jakob, not picking on you - but your statement gave me a good angle for = what I wanted to say on this. > On 20 Jul 2017, at 19:01, Jakob Heitz (jheitz) = wrote: >=20 > If it causes legitimate traffic to fail, then it's wrong. Sure, but knowing what constitutes legitimate is the trick then. If an = announcement has status =E2=80=9Cinvalid=E2=80=9D, then this means that = the holder of the prefix made one or more authorisation(s) for other = announcement(s) for this space, but not for *this* announcement. Whether this is: a) a bug, because the holder wants the announcement but neglected to = authorise; or b) a feature, because the holder does not want this announcement That is impossible to tell based only on the observation that there is a = disagreement. And I fear that any smart heuristics, e.g. based on = announcement history, are in the end only estimated guesswork. It may be = smart and it may be right more often than wrong, but it=E2=80=99s still = guesswork. Now, I see value in exposing such differences and helping operators = anywhere to understand and debug them and take action, but I have to say = that I disagree quite fundamentally on automating decisions on the = validator side. I believe that it will inevitably result in = announcements that are supposed to be =E2=80=9Cinvalid=E2=80=9D (by = choice of the holder) to become authorised. This will degrade the = benefit of using RPKI Origin Validation for networks that do maintain = their ROAs properly. Secondly I believe that =E2=80=98fixing=E2=80=99 = this on the RP side will remove the incentive for networks to fix their = ROAs so that they match their intended announcements. If it hurts, = people will fix it. This has been happening in Europe for decades w.r.t. = route objects. Let me provide a further datapoint. We have 4880 organisations that = activated their hosted RPKI service. Some organisations only switched on = the system, but a total of 2874 organisations actively maintain ROAs. We = provide an opt-in service whereby organisations can receive alerts in = case we see announcements that are inconsistent with their ROAs. = Although this is not mandatory, the majority of organisations (2020) = have opted in to this service. The alerts will inform the organisation = of any =E2=80=9Cinvalid=E2=80=9D or =E2=80=9Cunknown=E2=80=9D = announcements. On receiving this organisations can choose to authorise = these announcements - but ONLY if they are supposed to be correct (their = choice). If they do not authorise the announcement, and it keeps = happening, they will receive an email every day. For this reason users = can also choose to suppress the warnings on announcements they do not = wish to authorise. We have 219 organisations that have at lease one = announcement suppressed. So, in short: I believe that this in itself proves that a lot of our = users are actively managing their ROAs, and that quite a few of the = =E2=80=9Cinvalids=E2=80=9D out there are really supposed to be = considered just that: =E2=80=9Cinvalid=E2=80=9D Thanks Tim > =20 > Thanks, > Jakob. > =20 > From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Carlos M. = Martinez > Sent: Thursday, July 20, 2017 8:41 AM > To: Matthias Waehlisch > Cc: sidrops@ietf.org > Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and = the Learning-Validator > =20 > I was about to ask a question on the mic but was late to the line. = Maybe it=E2=80=99s worth sharing it here: >=20 > =E2=80=A2 How we define a ROA to be =E2=80=9Cwrong=E2=80=9D ? = One that invalidates routes or one that causes legitimate traffic to be = dropped ? > Why? because we=E2=80=99ve seen in many cases ROAs that create lots of = invalids but validate a less-specific route that covers those invalids >=20 > In a way, this even a positive side-effect, sort of vacuum-cleaning = your routing tables. >=20 > I believe analyzing what ROAs are wrong is quite important, but i=E2=80=99= d believe this particular case should not count as wrong. >=20 > thanks! >=20 > /Carlos >=20 > On 17 Jul 2017, at 16:36, Matthias Waehlisch wrote: >=20 > two comments via the list because we run out of time: >=20 > (1) I'm wondering about the statement that the quality of ROAs = decreases > over time. My impression is that the quality improved because of > excellent training by RIRs and others. >=20 > Slide 4 shows absolute values, which is not helpful in this context. >=20 >=20 > (2) Regarding ROV measurements: "Similar results apparently from > measurements by Randy Bush and others (didn't yet see details)" >=20 > Details are available, easy to find using Google: >=20 > * "Towards a Rigorous Methodology for Measuring Adoption of RPKI Route > Validation and Filtering", https://arxiv.org/abs/1706.04263. Some of > this work was also presented at the last RIPE meeting: > https://ripe74.ripe.net/archives/video/46/ >=20 >=20 >=20 >=20 > Cheers > matthias >=20 > --=20 > Matthias Waehlisch > . Freie Universitaet Berlin, Computer Science > .. http://www.cs.fu-berlin.de/~waehl >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Tue Jul 25 07:38:53 2017 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 54879131CE1; Tue, 25 Jul 2017 07:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 SXbrT7paXn7w; Tue, 25 Jul 2017 07:38:41 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix.ams-ix.net [IPv6:2001:67c:1a8:a101::70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CC0131CE2; Tue, 25 Jul 2017 07:38:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from [IPv6:2001:67c:1a8:102:10e2:b570:73cc:c076] (unknown [IPv6:2001:67c:1a8:102:10e2:b570:73cc:c076]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aristidis) by deliverix.ams-ix.net (Postfix) with ESMTPSA id 4942540F9A; Tue, 25 Jul 2017 16:38:39 +0200 (CEST) From: Aris Lambrianidis Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3EE466D9-3F60-41AD-8EF3-3F0DB6128F09"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Jul 2017 16:38:38 +0200 In-Reply-To: <5971FE7B.6060607@foobar.org> Cc: "sidrops@ietf.org" , draft-ietf-sidrops-route-server-rpki-light@ietf.org, Job Snijders To: Nick Hilliard References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 14:38:51 -0000 --Apple-Mail=_3EE466D9-3F60-41AD-8EF3-3F0DB6128F09 Content-Type: multipart/alternative; boundary="Apple-Mail=_A052A481-D794-4019-A69E-FA4FDFBCB874" --Apple-Mail=_A052A481-D794-4019-A69E-FA4FDFBCB874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nick, We=E2=80=99re working on an updated draft to elaborate further on the valid path hiding concerns you raised, as well as describing a new transitive extended BGP community attribute, (instead of reusing the one described in RFC8097), based on Job Snijders=E2=80=99 offline comments. --Aris > On 21 Jul 2017, at 15:15, Nick Hilliard wrote: >=20 > Aris, >=20 > the concerns I brought up about this draft on jan 13 / jan 14 have not > been addressed in -01 or -02. The concerns were basically: this is = not > how to solve the problem of making things easier for route server > clients + the reasons why. >=20 > Nick >=20 > Aris Lambrianidis wrote: >> Hello all, >>=20 >> As a quick note, Daniel and I are in Prague, at IETF99. Daniel will = be >> here until Tuesday afternoon and I=E2=80=99ll be here >> for the entire week, should you have any concerns, comments, or >> questions. We=E2=80=99re looking into moving things forward >> (read: go for WG Last Call), so we=E2=80=99d appreciate any feedback, = in person >> or by email. >>=20 >> --Aris >>=20 >>=20 >>> On 11 Apr 2017, at 18:15, Thomas King >> > wrote: >>>=20 >>> Hi all, >>>=20 >>> we have worked on the feedback we received through many channels = (e.g. >>> this mailing list): >>> - Clarification of the =E2=80=9CSecurity Considerations=E2=80=9D = section. Please let >>> us know if you think a security issue is not tackled. >>> - The feedback told us that different modes of operation for how >>> =E2=80=9Cinvalid=E2=80=9D and =E2=80=9Cnot found=E2=80=9D routes = should be handled needs to be >>> addressed. For this, section =E2=80=9CBGP Prefix Origin Validation = State >>> Utilized at Route-Servers=E2=80=9D was added. >>> - House-Keeping (e.g. update references, fix typos) >>>=20 >>> Best regards, >>> Thomas >>>=20 >>>=20 >>> On 11/04/2017, 18:14, "Sidrops on behalf of internet-drafts@ietf.org >>> " >> on behalf of >>> 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 of the IETF. >>>=20 >>> Title : Signaling Prefix Origin Validation >>> Results from a Route Server to Peers >>> Authors : Thomas King >>> Daniel Kopp >>> Aristidis Lambrianidis >>> Arnaud Fenioux >>> Filename : = draft-ietf-sidrops-route-server-rpki-light-02.txt >>> Pages : 7 >>> Date : 2017-04-11 >>>=20 >>> Abstract: >>> This document defines the usage of the BGP Prefix Origin = Validation >>> State Extended Community [RFC8097] to signal prefix origin >>> validation >>> results from a route server to its peers. Upon reception of = prefix >>> origin validation results peers can use this information in = their >>> local routing decision process. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-server-rpki-ligh= t/ >>>=20 >>> There are also htmlized versions available at: >>> = https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpki-light-02 >>> = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-route-server-rpki= -light-02 >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-route-server-rpki-l= ight-02 >>>=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 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_A052A481-D794-4019-A69E-FA4FDFBCB874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Nick,

We=E2=80=99re working on an updated draft to elaborate = further
on the valid path hiding concerns you = raised, as well 
as describing a new = transitive extended BGP community attribute,
(instead= of reusing the one described in RFC8097),
based on = Job Snijders=E2=80=99 offline comments.

--Aris


On 21 Jul 2017, at 15:15, Nick Hilliard <nick@foobar.org> = wrote:

Aris,

the concerns I brought up = about this draft on jan 13 / jan 14 have not
been = addressed in -01 or -02.  The concerns were basically: this is = not
how to solve the problem of making things easier for = route server
clients + the reasons why.

Nick

Aris Lambrianidis wrote:
Hello all,

As a quick note, Daniel and I are in Prague, = at IETF99. Daniel will be
here until Tuesday afternoon and = I=E2=80=99ll be here
for the entire week, should you have = any concerns, comments, or
questions. We=E2=80=99re = looking into moving things forward
(read: go for WG Last = Call), so we=E2=80=99d appreciate any feedback, in person
or= by email.

--Aris


On 11 Apr = 2017, at 18:15, Thomas King <thomas.king@de-cix.net
<mailto:thomas.king@de-cix.net>> wrote:

Hi all,

we have = worked on the feedback we received through many channels (e.g.
this mailing list):
- Clarification of the = =E2=80=9CSecurity Considerations=E2=80=9D section. Please let
us know if you think a security issue is not tackled.
- The feedback told us that different modes of operation for = how
=E2=80=9Cinvalid=E2=80=9D and =E2=80=9Cnot found=E2=80=9D= routes should be handled needs to be
addressed. For this, = section =E2=80=9CBGP Prefix Origin Validation State
Utilized= at Route-Servers=E2=80=9D was added.
- House-Keeping = (e.g. update references, fix typos)

Best = regards,
Thomas


On 11/04/2017, 18:14, "Sidrops on behalf of internet-drafts@ietf.org
<mailto:internet-drafts@ietf.org>" <sidrops-bounces@ietf.org
<mailto:sidrops-bounces@ietf.org> on behalf of
internet-drafts@ietf.org <mailto: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 of the IETF.

=           Title =           : Signaling = Prefix Origin Validation
Results from a Route Server to = Peers
=           Authors =         : Thomas King
=             &n= bsp;           &nbs= p;   Daniel Kopp
=             &n= bsp;           &nbs= p;   Aristidis Lambrianidis
=             &n= bsp;           &nbs= p;   Arnaud Fenioux
  Filename =        : = draft-ietf-sidrops-route-server-rpki-light-02.txt
=   Pages =           : 7
  Date =            : = 2017-04-11

  Abstract:
     This document defines the = usage of the BGP Prefix Origin Validation
=      State Extended Community [RFC8097] to = signal prefix origin
validation
=      results from a route server to its peers. =  Upon reception of prefix
=      origin validation results peers can use = this information in their
=      local routing decision process.



  The = IETF datatracker status page for this draft is:
=   https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-serve= r-rpki-light/

  There are = also htmlized versions available at:
  https://tools.ietf.org/html/draft-ietf-sidrops-route-server-rpk= i-light-02
  https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-route-= server-rpki-light-02

  A = diff from the previous version is available at:
=   https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-route-se= rver-rpki-light-02


=   Please note that it may take a couple of minutes from the = time of
submission
  until the = htmlized version and diff are available at tools.ietf.org
<http://tools.ietf.org>.

=   Internet-Drafts are also available by anonymous FTP at:
  ftp://ftp.ietf.org/internet-drafts/

=   _______________________________________________
=   Sidrops mailing list
  Sidrops@ietf.org <mailto:Sidrops@ietf.org>
  https://www.ietf.org/mailman/listinfo/sidrops


_______________________________________________
Sidrops mailing list
Sidrops@ietf.org <mailto: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

= --Apple-Mail=_A052A481-D794-4019-A69E-FA4FDFBCB874-- --Apple-Mail=_3EE466D9-3F60-41AD-8EF3-3F0DB6128F09 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZd1fuAAoJEA9B3v9ltRqs1+EQAJoGhjrb8UNvBKjMqYplIFSc 8Hk40PN/Na2mgZdrxPH5LqgW7v58kw+XBSwzV66kA+qjj5wHPNzInzz3OzCNPw+j 8nQ74XVBOFPmjOTz7uYr6gphB1Hg3YI/zBQdUkjouhY/quM54ck/1HbKkv18nSAv U+Zv9stGjED5V7ZvTISFrdyYMnq99YtwAOUYKbLOnFnIZhsp6Nv/rLvfY8m4KMLq 0tABaU3rdhBWIwxy/8lNNP44oKbzJNBpgsRzRH+DXz2DS4rrSU7N4xAJvJgdIdE9 IGEM6O0NcvVBLBvUCPCiYB8Ca9xuGBZopC6UpwL9yBxDT4msuXYYXw/Ei7ATB7ON h0zKrtzRJdvm5je3xieXMTkbTMQfpTYzYknUiNTwVgj/Xm3LhCMn+suqob7kkCSg vkarwk+y/XaQKhxz5qG6UsgqvMYLgjCbeJdv7f4DAGc8IKe4B19scrUJeHJkSqVU 69vODHu1SY2nGhsYtlNWQ3UC3xWq+h9jQHmNQ+Dp+etWTogUGpkOOm6oRXZbhDzw m722FAwyreIlCQa4E8AedycdzD1OBGQm57bWquqdgDJAlLfosLCcSDo1Tgi97kq4 VmSaV5/xvfojA3T/2lNYiiPMLjB7xQcvhEzRPdn+YK6UG9hMIAUOYXRV5IaQTxOu PtL12Rz2uzVPhO0DZ/NL =B7Iw -----END PGP SIGNATURE----- --Apple-Mail=_3EE466D9-3F60-41AD-8EF3-3F0DB6128F09-- From nobody Tue Jul 25 08:26:53 2017 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 129C2131CFB for ; Tue, 25 Jul 2017 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 bnog3fXmvUCp for ; Tue, 25 Jul 2017 08:26:44 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 490E0131D0F for ; Tue, 25 Jul 2017 08:26:44 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so45327830wma.1 for ; Tue, 25 Jul 2017 08:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=dlPWfgLOqzM023zZ6s2b4FBVT9nF97P+2o3jH7HMYlg=; b=MRxHhGOpqdoi6IU/C/nyZeh5jaquovQQoVSt4954Xo2i+hz+y7JFlMGs+P982OhWTB hPeOwJdR0ScfFuUDdPrxH6hSuarizroCqGiT+aT8SPHEzKshzPjWLJny5pJsVThPzWcF /BvyMLXB05O3O+NOQoVgm4RK3xGguSQrWLmUDlIVvPjVaqxI7WbDDfv2ozvEOQs4LnM/ AfMG/EBsHdI7aNHl4uNNJt9KFiRlsak2g4KyRk+3gx2qt4WjbFtUf56lsQiTjAp8uFn4 bmkQJRVJWQgzVTBG4SmUYaJW1EYGALcQtHh8pCIddnK4SSWbXMKO8TOSj8+LAhrkkZ9b LJSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=dlPWfgLOqzM023zZ6s2b4FBVT9nF97P+2o3jH7HMYlg=; b=RXamqmsKKAMigb8NaRI6BJdxjaEtBwNhfXCCt/EuuCILDJNq3xu6pfQG0aFqEUFPjG Zt5Hb0FF4EBSTzK2IA+S4f/09H1y/MwPCvCEP/R8Ae9Ow1JYnnpXcEs0St+Wge/xEQGl GMwmAldiQCQghKJULHLjKyP9STT/RTKpUWzm8KmlUXb80CtdOMXNwEY6M8Qn6dAd1BUU LHYXMY8EGxPJLpI+lL3AnQafaUoJdWLBj/ENLevXt7aYOEAEhpaQtxguvBUryY7euuu6 D1nOxroR+sEHOtxr0hQ81Ko2ZsriPMAiblPbmgmt2iffMi4eh5u2A/hSJJ2PvIet6des qyBQ== X-Gm-Message-State: AIVw111Il3su11aizBtVYwedrTuT6/OWqLzVTFP+RnPjnzb4ngORjkXy yrGFC7bEaOKsbzNg X-Received: by 10.28.111.218 with SMTP id c87mr7585601wmi.36.1500996402524; Tue, 25 Jul 2017 08:26:42 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:58db:f3bc:13c1:ac46]) by smtp.gmail.com with ESMTPSA id h1sm15606443wrb.25.2017.07.25.08.26.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 08:26:41 -0700 (PDT) Date: Tue, 25 Jul 2017 17:26:40 +0200 From: Job Snijders To: Aris Lambrianidis Cc: Nick Hilliard , "sidrops@ietf.org" , draft-ietf-sidrops-route-server-rpki-light@ietf.org Message-ID: <20170725152640.o2kqovryesai3ysh@hanna.meerval.net> References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 15:26:47 -0000 Hi, On Tue, Jul 25, 2017 at 04:38:38PM +0200, Aris Lambrianidis wrote: > We’re working on an updated draft to elaborate further on the valid > path hiding concerns you raised, as well as describing a new > transitive extended BGP community attribute, (instead of reusing the > one described in RFC8097), based on Job Snijders’ offline comments. I elaborated that using a non-transitive extended community to cross EBGP boundaries (in my opinion) is a mis-use of the community transivity type. I know of a number of BGP implementations which will not send or accept non-transitive extended communities across EBGP borders. I am not sure whether a transitive extended community is the way to go either. A transitive extended community will allow an adversary to tunnel through networks which don't recognize the semantics of the "BGP Prefix Origin Validation State Transitive Extended Community" and possibly negatively impact such networks. This is the trouble with communities: the granularity available to limit scope and distributino is very coarse. I'm not sure there is a good solution here. Any adversy will tag the malicious announcement as "this is perfectly valid" and hope the 'valid' community helps mitigate 'rpki light' barriers. Kind regards, Job From nobody Tue Jul 25 10:27:07 2017 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 E652B131E5E; Tue, 25 Jul 2017 10:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 K9O674pfqN43; Tue, 25 Jul 2017 10:27:04 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FDD131E64; Tue, 25 Jul 2017 10:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3100; q=dns/txt; s=iport; t=1501003623; x=1502213223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hiov2uHi7aQ3klJyNiDhgFluF4zsZdZElDeZs3EloaE=; b=e05ws8KVD+tqwcV2+d2rrKOqin3pCO/NHm31SsSotsZWTWDxZxK6F/Ez ImbHTy6fFhKSBzBDN4zSw03AVmlnYIvXL2muY5Xl7q+Bx7FM/ngqiZjGP fdlmVEXbMj05zlG+vdPC0BnFv53y5QlhoL0Ucb3UJY8eN0cDvLpm0WVTs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAABafndZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgWRaJYGghIhC4RMTwIagx0/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAwEBIRE6CwwEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQUIDAeKFBCxR?= =?us-ascii?q?4Imi0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELgh2DTYFhgySETRCDKYJhBZ9?= =?us-ascii?q?XApQUkkKVaAEfOIEKdxVJhxl2hnYBJAeBBYEOAQEB?= X-IronPort-AV: E=Sophos;i="5.40,411,1496102400"; d="scan'208";a="461034499" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2017 17:27:02 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v6PHR2Ip022445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2017 17:27:02 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 12:27:01 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 25 Jul 2017 12:27:01 -0500 From: "Jakob Heitz (jheitz)" To: Job Snijders , Aris Lambrianidis CC: "sidrops@ietf.org" , "draft-ietf-sidrops-route-server-rpki-light@ietf.org" , Nick Hilliard Thread-Topic: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt Thread-Index: AQHSst7I9CejtHqlcUC81n91Ri0w36HAq9eAgJhDYwCABkW+gIAGYIMAgAANbAD//8r1YA== Date: Tue, 25 Jul 2017 17:27:01 +0000 Message-ID: <1fb673f586c74af8992c9b5c6a19333d@XCH-ALN-014.cisco.com> References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> <20170725152640.o2kqovryesai3ysh@hanna.meerval.net> In-Reply-To: <20170725152640.o2kqovryesai3ysh@hanna.meerval.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.157] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 17:27:06 -0000 WW91IGFjY2VwdCB0aGUgY29tbXVuaXR5IG9ubHkgZnJvbSB0aG9zZSB5b3UgdHJ1c3QuIEludGVy bmFsIG9yIGV4dGVybmFsLg0KRnByIGV4YW1wbGUsIGlmIHlvdSBrbm93IHRoYXQgdGhlIG5laWdo Ym9yIGlzIHBlcmZvcm1pbmcgdmFsaWRhdGlvbiB0byB5b3VyIHN0YW5kYXJkLg0KVGhlcmUgaXMg YW4gYXBwcm94aW1hdGUgY29ycmVsYXRpb24gYmV0d2VlbiB0cnVzdCBib3VuZGFyeSBhbmQgQVMg Ym91bmRhcnkuDQpJZiB5b3UgdHJ1c3Qgc29tZW9uZSBpbiBhbm90aGVyIEFTLCB0aGVuIHRoZXkg c2hvdWxkIGJlIGFibGUgdG8gc2VuZCB5b3UgdGhlIGNvbW1tdW5pdHkuDQoNClRoYW5rcywNCkph a29iLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU2lkcm9wcyBb bWFpbHRvOnNpZHJvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvYiBTbmlqZGVy cw0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDI1LCAyMDE3IDg6MjcgQU0NCj4gVG86IEFyaXMgTGFt YnJpYW5pZGlzIDxhcmlzdGlkaXMubGFtYnJpYW5pZGlzQGFtcy1peC5uZXQ+DQo+IENjOiBzaWRy b3BzQGlldGYub3JnOyBkcmFmdC1pZXRmLXNpZHJvcHMtcm91dGUtc2VydmVyLXJwa2ktbGlnaHRA aWV0Zi5vcmc7IE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9yZz4NCj4gU3ViamVjdDogUmU6 IFtTaWRyb3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNpZHJvcHMtcm91dGUtc2VydmVyLXJw a2ktbGlnaHQtMDIudHh0DQo+IA0KPiBIaSwNCj4gDQo+IE9uIFR1ZSwgSnVsIDI1LCAyMDE3IGF0 IDA0OjM4OjM4UE0gKzAyMDAsIEFyaXMgTGFtYnJpYW5pZGlzIHdyb3RlOg0KPiA+IFdl4oCZcmUg d29ya2luZyBvbiBhbiB1cGRhdGVkIGRyYWZ0IHRvIGVsYWJvcmF0ZSBmdXJ0aGVyIG9uIHRoZSB2 YWxpZA0KPiA+IHBhdGggaGlkaW5nIGNvbmNlcm5zIHlvdSByYWlzZWQsIGFzIHdlbGwgYXMgZGVz Y3JpYmluZyBhIG5ldw0KPiA+IHRyYW5zaXRpdmUgZXh0ZW5kZWQgQkdQIGNvbW11bml0eSBhdHRy aWJ1dGUsIChpbnN0ZWFkIG9mIHJldXNpbmcgdGhlDQo+ID4gb25lIGRlc2NyaWJlZCBpbiBSRkM4 MDk3KSwgYmFzZWQgb24gSm9iIFNuaWpkZXJz4oCZIG9mZmxpbmUgY29tbWVudHMuDQo+IA0KPiBJ IGVsYWJvcmF0ZWQgdGhhdCB1c2luZyBhIG5vbi10cmFuc2l0aXZlIGV4dGVuZGVkIGNvbW11bml0 eSB0byBjcm9zcw0KPiBFQkdQIGJvdW5kYXJpZXMgKGluIG15IG9waW5pb24pIGlzIGEgbWlzLXVz ZSBvZiB0aGUgY29tbXVuaXR5IHRyYW5zaXZpdHkNCj4gdHlwZS4gSSBrbm93IG9mIGEgbnVtYmVy IG9mIEJHUCBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggd2lsbCBub3Qgc2VuZCBvcg0KPiBhY2NlcHQg bm9uLXRyYW5zaXRpdmUgZXh0ZW5kZWQgY29tbXVuaXRpZXMgYWNyb3NzIEVCR1AgYm9yZGVycy4N Cj4gDQo+IEkgYW0gbm90IHN1cmUgd2hldGhlciBhIHRyYW5zaXRpdmUgZXh0ZW5kZWQgY29tbXVu aXR5IGlzIHRoZSB3YXkgdG8gZ28NCj4gZWl0aGVyLiBBIHRyYW5zaXRpdmUgZXh0ZW5kZWQgY29t bXVuaXR5IHdpbGwgYWxsb3cgYW4gYWR2ZXJzYXJ5IHRvDQo+IHR1bm5lbCB0aHJvdWdoIG5ldHdv cmtzIHdoaWNoIGRvbid0IHJlY29nbml6ZSB0aGUgc2VtYW50aWNzIG9mIHRoZSAiQkdQDQo+IFBy ZWZpeCBPcmlnaW4gVmFsaWRhdGlvbiBTdGF0ZSBUcmFuc2l0aXZlIEV4dGVuZGVkIENvbW11bml0 eSIgYW5kDQo+IHBvc3NpYmx5IG5lZ2F0aXZlbHkgaW1wYWN0IHN1Y2ggbmV0d29ya3MuIFRoaXMg aXMgdGhlIHRyb3VibGUgd2l0aA0KPiBjb21tdW5pdGllczogdGhlIGdyYW51bGFyaXR5IGF2YWls YWJsZSB0byBsaW1pdCBzY29wZSBhbmQgZGlzdHJpYnV0aW5vDQo+IGlzIHZlcnkgY29hcnNlLg0K PiANCj4gSSdtIG5vdCBzdXJlIHRoZXJlIGlzIGEgZ29vZCBzb2x1dGlvbiBoZXJlLiBBbnkgYWR2 ZXJzeSB3aWxsIHRhZyB0aGUNCj4gbWFsaWNpb3VzIGFubm91bmNlbWVudCBhcyAidGhpcyBpcyBw ZXJmZWN0bHkgdmFsaWQiIGFuZCBob3BlIHRoZSAndmFsaWQnDQo+IGNvbW11bml0eSBoZWxwcyBt aXRpZ2F0ZSAncnBraSBsaWdodCcgYmFycmllcnMuDQo+IA0KPiBLaW5kIHJlZ2FyZHMsDQo+IA0K PiBKb2INCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IFNpZHJvcHMgbWFpbGluZyBsaXN0DQo+IFNpZHJvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQo= From nobody Tue Jul 25 10:35:29 2017 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 DB656131E75 for ; Tue, 25 Jul 2017 10:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 wLgBYvujmj0m for ; Tue, 25 Jul 2017 10:35:24 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 0A5F1131E73 for ; Tue, 25 Jul 2017 10:35:23 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id c184so58344964wmd.0 for ; Tue, 25 Jul 2017 10:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=56wDMJI7Cr0hDUG/CzUbbsMnZC1KqEHY2NY6DsyEqwI=; b=WvpxgqlVLg4m3ntL/Cujt5nASsegbWmF5U6Uf2Lssm0To/F36iHG5Ru1SikAWG+d06 +Z+/yRfuQAYj+BD3SywnxKGBVDknagjU95gwYQ06OJDViBz6+0bg1P66XzQM3f1QzFib ESqBHnqye6XLiHkaXqnbYy0ghOLd1UyKp4J3FDEj/IdVdqbVgxsP740eZL2wHvjxsJF/ oe+46wENNaz36e5gRaGjmVnMseiNgvk8PVo1JnEwuhbmQOH3cZblPRhLszbfxvhtNpjt ACZwTUAluQuS1krlW6TFtDp4lVDTfjRp3NDCw59aC4QJkoOHUOpnEoJYLvTL4k0VnN7C Gehw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=56wDMJI7Cr0hDUG/CzUbbsMnZC1KqEHY2NY6DsyEqwI=; b=APRKnnmrrbAEhCCS8RZN+KPVlDj8U02KmaNTA/gTVNL8CvZvrufjTVloc78sdMivdA n1yJ9Jm/NnkUqTodC6cMo00ZENxScgg7J/4ipbVjwKElZcoGolticeBNRAtrtaeaf7am ENXUe52Pw1kXsLg1U3Nrr+DAKMUiAkyKor+RhXtXqqX2IyVkO7XQ8nshn0Rpjskxlvgh PfOGt53f/TofhNTqsh6ubC5bW6EA3BaVbO2rQC4ScrZoSbVHn5hHOZxCIe9s43rMq48h qMkkCsDLxGZtu1NkMUKHXyFREl99sPz7ISQ+ug7zT9e2IUHd1/IXQEP8Lw6J5g3GBcj+ ZvAw== X-Gm-Message-State: AIVw111uLdC+4ph/4037q45M42epO72rS07lM6PhTDHcWFnyRkoiOhEZ HaSed4pqc4EIfzlC X-Received: by 10.28.185.210 with SMTP id j201mr8218698wmf.52.1501004122253; Tue, 25 Jul 2017 10:35:22 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:7065:5e1b:6a46:2fbb]) by smtp.gmail.com with ESMTPSA id q27sm14204337wrc.94.2017.07.25.10.35.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 10:35:21 -0700 (PDT) Date: Tue, 25 Jul 2017 19:35:16 +0200 From: Job Snijders To: "Jakob Heitz (jheitz)" Cc: Aris Lambrianidis , "sidrops@ietf.org" , "draft-ietf-sidrops-route-server-rpki-light@ietf.org" , Nick Hilliard Message-ID: <20170725173516.q5lyiybdikctvfyr@Vurt.local> References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> <20170725152640.o2kqovryesai3ysh@hanna.meerval.net> <1fb673f586c74af8992c9b5c6a19333d@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1fb673f586c74af8992c9b5c6a19333d@XCH-ALN-014.cisco.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 17:35:27 -0000 On Tue, Jul 25, 2017 at 05:27:01PM +0000, Jakob Heitz (jheitz) wrote: > You accept the community only from those you trust. Internal or external. A challenge with any new transitive (extended) well-known community is that until the thing is standardised, people don't know what to filter and chances are the thing can just pass through anything. There even are BGP implementations in which you cannot delete unknown extended communities, so you'd have to wait until you receive a software update before you can scrub those specific new types. I don't encourage blanket community scrubbing either. So we have to be careful when introducing new codepoints associated with specific semantics. Kind regards, Job From nobody Tue Jul 25 10:55:54 2017 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 62BAB126C0F for ; Tue, 25 Jul 2017 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 7r0fNypM44it for ; Tue, 25 Jul 2017 10:55:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC27A1241FC for ; Tue, 25 Jul 2017 10:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8364; q=dns/txt; s=iport; t=1501005349; x=1502214949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bs0lA9D5mnWO0b58tXHK/uVQJD5QyJ4oScgGdnq+ruI=; b=dHQ/InCk0UFVXsqNOmdeC8c2iyTOR21/N0BGGh0czw9VSDQ2ssQuM8hw pTtJsn8CgHpFfQR0Kc9no+XkDsx8cAFWyMI/ggfvDp7mCq7ewZixTQV6T DJxE0+mQESQQ1pTam5oQrF4c3PjZ5CfChHlViRoq3IXRlGC5I5EQYhajt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAADkhXdZ/49dJa1dFgMBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEUB44FkWiIMI1WDoIEIQuETE8CGoMdPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQMBASEROQELDAQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAgQOBQgUi?= =?us-ascii?q?XsDFRCxNoImFocjDYQDAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELgh2DTYFhgyS?= =?us-ascii?q?CV4FpARIBgzKCYQWfGzwCh02BDIZUhGeCFZAtjBR0iGABHzhMMwt3FUmFS4FOd?= =?us-ascii?q?gGGdg0XB4EFgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,411,1496102400"; d="scan'208";a="264035266" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2017 17:55:31 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6PHtVSr030078 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2017 17:55:31 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 12:55:30 -0500 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Tue, 25 Jul 2017 12:55:30 -0500 From: "Jakob Heitz (jheitz)" To: Tim Bruijnzeels CC: "Carlos M. Martinez" , Matthias Waehlisch , "sidrops@ietf.org" Thread-Topic: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator Thread-Index: AQHS/wosXCvss6U2wEyq5n16HYmqTqJdMwYA///B1+CAB/qLAP//6wTg Date: Tue, 25 Jul 2017 17:55:30 +0000 Message-ID: <96044ca1d98d4cb99fe2dd8e6d3ead08@XCH-ALN-014.cisco.com> References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> <78F49BAC-F0F2-4712-862A-BCFA1A9DC35D@ripe.net> In-Reply-To: <78F49BAC-F0F2-4712-862A-BCFA1A9DC35D@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.157] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 17:55:52 -0000 SSBjb3VsZCB1bmRlcnN0YW5kIGlmIHRoZXJlIGFyZSBwcm92aWRlcnMgdGhhdCB3b3VsZCByYXRo ZXIgYWNjZXB0DQp0aGUgIm1heWJlIGludmFsaWQiIHRoYW4gZHJvcCB0aGVtLiBEcm9wcGluZyBw cmVmaXhlcyBicmVha3MgY29ubmVjdGl2aXR5Lg0KSWYgdGhleSBjYW4ndCB0ZWxsIHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gIm1hdGNoZWQgd2l0aCB3cm9uZyBBUyINCmFuZCBjb3ZlcmVkLCB0aGVu IHRoZXknbGwganVzdCBhY2NlcHQgdGhlbSBhbGwuDQoNClRoYW5rcywNCkpha29iLg0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGltIEJydWlqbnplZWxzIFttYWls dG86dGltQHJpcGUubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDI1LCAyMDE3IDY6NDkgQU0N Cj4gVG86IEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPg0KPiBDYzogQ2Fy bG9zIE0uIE1hcnRpbmV6IDxjYXJsb3NtMzAxMUBnbWFpbC5jb20+OyBNYXR0aGlhcyBXYWVobGlz Y2ggPG0ud2FlaGxpc2NoQGZ1LWJlcmxpbi5kZT47IHNpZHJvcHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtTaWRyb3BzXSBUYWxrOiBSUEtJIERlcGxveW1lbnQ6IFN0YXR1cywgQ2hhbGxlbmdl cyBhbmQgdGhlIExlYXJuaW5nLVZhbGlkYXRvcg0KPiANCj4gSGksDQo+IA0KPiBKYWtvYiwgbm90 IHBpY2tpbmcgb24geW91IC0gYnV0IHlvdXIgc3RhdGVtZW50IGdhdmUgbWUgYSBnb29kIGFuZ2xl IGZvciB3aGF0IEkgd2FudGVkIHRvIHNheSBvbiB0aGlzLg0KPiANCj4gPiBPbiAyMCBKdWwgMjAx NywgYXQgMTk6MDEsIEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPiB3cm90 ZToNCj4gPg0KPiA+IElmIGl0IGNhdXNlcyBsZWdpdGltYXRlIHRyYWZmaWMgdG8gZmFpbCwgdGhl biBpdCdzIHdyb25nLg0KPiANCj4gU3VyZSwgYnV0IGtub3dpbmcgd2hhdCBjb25zdGl0dXRlcyBs ZWdpdGltYXRlIGlzIHRoZSB0cmljayB0aGVuLiBJZiBhbiBhbm5vdW5jZW1lbnQgaGFzIHN0YXR1 cyDigJxpbnZhbGlk4oCdLCB0aGVuIHRoaXMNCj4gbWVhbnMgdGhhdCB0aGUgaG9sZGVyIG9mIHRo ZSBwcmVmaXggbWFkZSBvbmUgb3IgbW9yZSBhdXRob3Jpc2F0aW9uKHMpIGZvciBvdGhlciBhbm5v dW5jZW1lbnQocykgZm9yIHRoaXMgc3BhY2UsIGJ1dA0KPiBub3QgZm9yICp0aGlzKiBhbm5vdW5j ZW1lbnQuDQo+IA0KPiBXaGV0aGVyIHRoaXMgaXM6DQo+ICBhKSBhIGJ1ZywgYmVjYXVzZSB0aGUg aG9sZGVyIHdhbnRzIHRoZSBhbm5vdW5jZW1lbnQgYnV0IG5lZ2xlY3RlZCB0byBhdXRob3Jpc2U7 IG9yDQo+ICBiKSBhIGZlYXR1cmUsIGJlY2F1c2UgdGhlIGhvbGRlciBkb2VzIG5vdCB3YW50IHRo aXMgYW5ub3VuY2VtZW50DQo+IA0KPiBUaGF0IGlzIGltcG9zc2libGUgdG8gdGVsbCBiYXNlZCBv bmx5IG9uIHRoZSBvYnNlcnZhdGlvbiB0aGF0IHRoZXJlIGlzIGEgZGlzYWdyZWVtZW50LiBBbmQg SSBmZWFyIHRoYXQgYW55IHNtYXJ0DQo+IGhldXJpc3RpY3MsIGUuZy4gYmFzZWQgb24gYW5ub3Vu Y2VtZW50IGhpc3RvcnksIGFyZSBpbiB0aGUgZW5kIG9ubHkgZXN0aW1hdGVkIGd1ZXNzd29yay4g SXQgbWF5IGJlIHNtYXJ0IGFuZCBpdCBtYXkNCj4gYmUgcmlnaHQgbW9yZSBvZnRlbiB0aGFuIHdy b25nLCBidXQgaXTigJlzIHN0aWxsIGd1ZXNzd29yay4NCj4gDQo+IE5vdywgSSBzZWUgdmFsdWUg aW4gZXhwb3Npbmcgc3VjaCBkaWZmZXJlbmNlcyBhbmQgaGVscGluZyBvcGVyYXRvcnMgYW55d2hl cmUgdG8gdW5kZXJzdGFuZCBhbmQgZGVidWcgdGhlbSBhbmQgdGFrZQ0KPiBhY3Rpb24sIGJ1dCBJ IGhhdmUgdG8gc2F5IHRoYXQgSSBkaXNhZ3JlZSBxdWl0ZSBmdW5kYW1lbnRhbGx5IG9uIGF1dG9t YXRpbmcgZGVjaXNpb25zIG9uIHRoZSB2YWxpZGF0b3Igc2lkZS4gSQ0KPiBiZWxpZXZlIHRoYXQg aXQgd2lsbCBpbmV2aXRhYmx5IHJlc3VsdCBpbiBhbm5vdW5jZW1lbnRzIHRoYXQgYXJlIHN1cHBv c2VkIHRvIGJlIOKAnGludmFsaWTigJ0gKGJ5IGNob2ljZSBvZiB0aGUgaG9sZGVyKQ0KPiB0byBi ZWNvbWUgYXV0aG9yaXNlZC4gVGhpcyB3aWxsIGRlZ3JhZGUgdGhlIGJlbmVmaXQgb2YgdXNpbmcg UlBLSSBPcmlnaW4gVmFsaWRhdGlvbiBmb3IgbmV0d29ya3MgdGhhdCBkbyBtYWludGFpbg0KPiB0 aGVpciBST0FzIHByb3Blcmx5LiBTZWNvbmRseSBJIGJlbGlldmUgdGhhdCDigJhmaXhpbmfigJkg dGhpcyBvbiB0aGUgUlAgc2lkZSB3aWxsIHJlbW92ZSB0aGUgaW5jZW50aXZlIGZvciBuZXR3b3Jr cyB0bw0KPiBmaXggdGhlaXIgUk9BcyBzbyB0aGF0IHRoZXkgbWF0Y2ggdGhlaXIgaW50ZW5kZWQg YW5ub3VuY2VtZW50cy4gSWYgaXQgaHVydHMsIHBlb3BsZSB3aWxsIGZpeCBpdC4gVGhpcyBoYXMg YmVlbg0KPiBoYXBwZW5pbmcgaW4gRXVyb3BlIGZvciBkZWNhZGVzIHcuci50LiByb3V0ZSBvYmpl Y3RzLg0KPiANCj4gTGV0IG1lIHByb3ZpZGUgYSBmdXJ0aGVyIGRhdGFwb2ludC4gV2UgaGF2ZSA0 ODgwIG9yZ2FuaXNhdGlvbnMgdGhhdCBhY3RpdmF0ZWQgdGhlaXIgaG9zdGVkIFJQS0kgc2Vydmlj ZS4gU29tZQ0KPiBvcmdhbmlzYXRpb25zIG9ubHkgc3dpdGNoZWQgb24gdGhlIHN5c3RlbSwgYnV0 IGEgdG90YWwgb2YgMjg3NCBvcmdhbmlzYXRpb25zIGFjdGl2ZWx5IG1haW50YWluIFJPQXMuIFdl IHByb3ZpZGUgYW4NCj4gb3B0LWluIHNlcnZpY2Ugd2hlcmVieSBvcmdhbmlzYXRpb25zIGNhbiBy ZWNlaXZlIGFsZXJ0cyBpbiBjYXNlIHdlIHNlZSBhbm5vdW5jZW1lbnRzIHRoYXQgYXJlIGluY29u c2lzdGVudCB3aXRoDQo+IHRoZWlyIFJPQXMuIEFsdGhvdWdoIHRoaXMgaXMgbm90IG1hbmRhdG9y eSwgdGhlIG1ham9yaXR5IG9mIG9yZ2FuaXNhdGlvbnMgKDIwMjApIGhhdmUgb3B0ZWQgaW4gdG8g dGhpcyBzZXJ2aWNlLiBUaGUNCj4gYWxlcnRzIHdpbGwgaW5mb3JtIHRoZSBvcmdhbmlzYXRpb24g b2YgYW55IOKAnGludmFsaWTigJ0gb3Ig4oCcdW5rbm93buKAnSBhbm5vdW5jZW1lbnRzLiBPbiBy ZWNlaXZpbmcgdGhpcyBvcmdhbmlzYXRpb25zIGNhbg0KPiBjaG9vc2UgdG8gYXV0aG9yaXNlIHRo ZXNlIGFubm91bmNlbWVudHMgLSBidXQgT05MWSBpZiB0aGV5IGFyZSBzdXBwb3NlZCB0byBiZSBj b3JyZWN0ICh0aGVpciBjaG9pY2UpLiBJZiB0aGV5IGRvIG5vdA0KPiBhdXRob3Jpc2UgdGhlIGFu bm91bmNlbWVudCwgYW5kIGl0IGtlZXBzIGhhcHBlbmluZywgdGhleSB3aWxsIHJlY2VpdmUgYW4g ZW1haWwgZXZlcnkgZGF5LiBGb3IgdGhpcyByZWFzb24gdXNlcnMgY2FuDQo+IGFsc28gY2hvb3Nl IHRvIHN1cHByZXNzIHRoZSB3YXJuaW5ncyBvbiBhbm5vdW5jZW1lbnRzIHRoZXkgZG8gbm90IHdp c2ggdG8gYXV0aG9yaXNlLiBXZSBoYXZlIDIxOSBvcmdhbmlzYXRpb25zIHRoYXQNCj4gaGF2ZSBh dCBsZWFzZSBvbmUgYW5ub3VuY2VtZW50IHN1cHByZXNzZWQuDQo+IA0KPiBTbywgaW4gc2hvcnQ6 IEkgYmVsaWV2ZSB0aGF0IHRoaXMgaW4gaXRzZWxmIHByb3ZlcyB0aGF0IGEgbG90IG9mIG91ciB1 c2VycyBhcmUgYWN0aXZlbHkgbWFuYWdpbmcgdGhlaXIgUk9BcywgYW5kDQo+IHRoYXQgcXVpdGUg YSBmZXcgb2YgdGhlIOKAnGludmFsaWRz4oCdIG91dCB0aGVyZSBhcmUgcmVhbGx5IHN1cHBvc2Vk IHRvIGJlIGNvbnNpZGVyZWQganVzdCB0aGF0OiDigJxpbnZhbGlk4oCdDQo+IA0KPiBUaGFua3MN Cj4gVGltDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBKYWtvYi4N Cj4gPg0KPiA+IEZyb206IFNpZHJvcHMgW21haWx0bzpzaWRyb3BzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDYXJsb3MgTS4gTWFydGluZXoNCj4gPiBTZW50OiBUaHVyc2RheSwgSnVs eSAyMCwgMjAxNyA4OjQxIEFNDQo+ID4gVG86IE1hdHRoaWFzIFdhZWhsaXNjaCA8bS53YWVobGlz Y2hAZnUtYmVybGluLmRlPg0KPiA+IENjOiBzaWRyb3BzQGlldGYub3JnDQo+ID4gU3ViamVjdDog UmU6IFtTaWRyb3BzXSBUYWxrOiBSUEtJIERlcGxveW1lbnQ6IFN0YXR1cywgQ2hhbGxlbmdlcyBh bmQgdGhlIExlYXJuaW5nLVZhbGlkYXRvcg0KPiA+DQo+ID4gSSB3YXMgYWJvdXQgdG8gYXNrIGEg cXVlc3Rpb24gb24gdGhlIG1pYyBidXQgd2FzIGxhdGUgdG8gdGhlIGxpbmUuIE1heWJlIGl04oCZ cyB3b3J0aCBzaGFyaW5nIGl0IGhlcmU6DQo+ID4NCj4gPiAJ4oCiIEhvdyB3ZSBkZWZpbmUgYSBS T0EgdG8gYmUg4oCcd3JvbmfigJ0gPyBPbmUgdGhhdCBpbnZhbGlkYXRlcyByb3V0ZXMgb3Igb25l IHRoYXQgY2F1c2VzIGxlZ2l0aW1hdGUgdHJhZmZpYyB0byBiZQ0KPiBkcm9wcGVkID8NCj4gPiBX aHk/IGJlY2F1c2Ugd2XigJl2ZSBzZWVuIGluIG1hbnkgY2FzZXMgUk9BcyB0aGF0IGNyZWF0ZSBs b3RzIG9mIGludmFsaWRzIGJ1dCB2YWxpZGF0ZSBhIGxlc3Mtc3BlY2lmaWMgcm91dGUgdGhhdA0K PiBjb3ZlcnMgdGhvc2UgaW52YWxpZHMNCj4gPg0KPiA+IEluIGEgd2F5LCB0aGlzIGV2ZW4gYSBw b3NpdGl2ZSBzaWRlLWVmZmVjdCwgc29ydCBvZiB2YWN1dW0tY2xlYW5pbmcgeW91ciByb3V0aW5n IHRhYmxlcy4NCj4gPg0KPiA+IEkgYmVsaWV2ZSBhbmFseXppbmcgd2hhdCBST0FzIGFyZSB3cm9u ZyBpcyBxdWl0ZSBpbXBvcnRhbnQsIGJ1dCBp4oCZZCBiZWxpZXZlIHRoaXMgcGFydGljdWxhciBj YXNlIHNob3VsZCBub3QgY291bnQNCj4gYXMgd3JvbmcuDQo+ID4NCj4gPiB0aGFua3MhDQo+ID4N Cj4gPiAvQ2FybG9zDQo+ID4NCj4gPiBPbiAxNyBKdWwgMjAxNywgYXQgMTY6MzYsIE1hdHRoaWFz IFdhZWhsaXNjaCB3cm90ZToNCj4gPg0KPiA+IHR3byBjb21tZW50cyB2aWEgdGhlIGxpc3QgYmVj YXVzZSB3ZSBydW4gb3V0IG9mIHRpbWU6DQo+ID4NCj4gPiAoMSkgSSdtIHdvbmRlcmluZyBhYm91 dCB0aGUgc3RhdGVtZW50IHRoYXQgdGhlIHF1YWxpdHkgb2YgUk9BcyBkZWNyZWFzZXMNCj4gPiBv dmVyIHRpbWUuIE15IGltcHJlc3Npb24gaXMgdGhhdCB0aGUgcXVhbGl0eSBpbXByb3ZlZCBiZWNh dXNlIG9mDQo+ID4gZXhjZWxsZW50IHRyYWluaW5nIGJ5IFJJUnMgYW5kIG90aGVycy4NCj4gPg0K PiA+IFNsaWRlIDQgc2hvd3MgYWJzb2x1dGUgdmFsdWVzLCB3aGljaCBpcyBub3QgaGVscGZ1bCBp biB0aGlzIGNvbnRleHQuDQo+ID4NCj4gPg0KPiA+ICgyKSBSZWdhcmRpbmcgUk9WIG1lYXN1cmVt ZW50czogIlNpbWlsYXIgcmVzdWx0cyBhcHBhcmVudGx5IGZyb20NCj4gPiBtZWFzdXJlbWVudHMg YnkgUmFuZHkgQnVzaCBhbmQgb3RoZXJzIChkaWRuJ3QgeWV0IHNlZSBkZXRhaWxzKSINCj4gPg0K PiA+IERldGFpbHMgYXJlIGF2YWlsYWJsZSwgZWFzeSB0byBmaW5kIHVzaW5nIEdvb2dsZToNCj4g Pg0KPiA+ICogIlRvd2FyZHMgYSBSaWdvcm91cyBNZXRob2RvbG9neSBmb3IgTWVhc3VyaW5nIEFk b3B0aW9uIG9mIFJQS0kgUm91dGUNCj4gPiBWYWxpZGF0aW9uIGFuZCBGaWx0ZXJpbmciLCBodHRw czovL2FyeGl2Lm9yZy9hYnMvMTcwNi4wNDI2My4gU29tZSBvZg0KPiA+IHRoaXMgd29yayB3YXMg YWxzbyBwcmVzZW50ZWQgYXQgdGhlIGxhc3QgUklQRSBtZWV0aW5nOg0KPiA+IGh0dHBzOi8vcmlw ZTc0LnJpcGUubmV0L2FyY2hpdmVzL3ZpZGVvLzQ2Lw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4g Q2hlZXJzDQo+ID4gbWF0dGhpYXMNCj4gPg0KPiA+IC0tDQo+ID4gTWF0dGhpYXMgV2FlaGxpc2No DQo+ID4gLiBGcmVpZSBVbml2ZXJzaXRhZXQgQmVybGluLCBDb21wdXRlciBTY2llbmNlDQo+ID4g Li4gaHR0cDovL3d3dy5jcy5mdS1iZXJsaW4uZGUvfndhZWhsDQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFNpZHJvcHMgbWFpbGlu ZyBsaXN0DQo+ID4gU2lkcm9wc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lkcm9wcw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBTaWRyb3BzIG1haWxpbmcgbGlzdA0KPiA+IFNp ZHJvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpZHJvcHMNCg0K From nobody Tue Jul 25 11:45:36 2017 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 83A26131EBD for ; Tue, 25 Jul 2017 11:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 oaMSXU1SOXTs for ; Tue, 25 Jul 2017 11:45:33 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 4903A131EBB for ; Tue, 25 Jul 2017 11:45:33 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id v105so92450808wrb.0 for ; Tue, 25 Jul 2017 11:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=eEfu8OJOMMwmQTCH0M/8iiCY69jgCwPRg8TTp0SI80g=; b=M6zSVdK94QFomABFxINcUXX1VM/Huhngotz9gacStaMAZhvrQFXm8iLCCqNUt6cJNW gBpLqIb93bOjKBieds4/lncuHSe3kPcVGaOOUMb3vjJRow9migLbg+nitjuvzBxvbIhJ ET24kv0v+KIaxYWWw8LYP04XkYoSGA3jflfncTDLpwtZccs5pnqns18zqzUJBtcCdaxR XLGeQVpOO5OG+q3kMXCfj76EznFm5eukrPTD9RakcvP4bZqUnrnBKnhkO6ozSsA/VCk7 W3YsNgYm0XfgHbh995UuUlbaD8/rD1JNqoch6gkP2aQv/e39fnTB+e+5cxupKBdfVSpH iLtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=eEfu8OJOMMwmQTCH0M/8iiCY69jgCwPRg8TTp0SI80g=; b=AB3LfI7ixoWWTXVqSyJ/CFqQj/jKCct6jYk6xZisSra0WgQSlrme2r4sREh7tkzX7n aYEPHEdZjTDqWMg/ceJ7psjtBWXFupfB4vEAYIIh9Zv85HNH/npiGqM5kHiUR7yoJz7/ O0HP2rfM0bDldO7v/ex0IuaMe6pvWS+WlJWSI0F/Eld4SbHS1HoTOATb2ZBoB9K3oCkU +SKIfHn3raYPAviQ8emph3bhn7LLxNC6zllj6aWfVLPNlnQBPaLRQsRHjDNq6lh/MPeq fGsDvI6lwFYbfjgnxXXP4tbS4/jUaBrNrNX67yU8n/9Drt5LfcuKwKCAukMGjEj9jSq/ dF6g== X-Gm-Message-State: AIVw110WDEw7+f5OGKaQF/yy3EYsjq/x9S4S8XGmzhUpguYV6Dbmrb/H j8zAGcKtjV8AR/Lj X-Received: by 10.223.168.70 with SMTP id l64mr21388157wrc.94.1501008331496; Tue, 25 Jul 2017 11:45:31 -0700 (PDT) Received: from localhost ([2001:67c:208c:10:7065:5e1b:6a46:2fbb]) by smtp.gmail.com with ESMTPSA id q2sm10638969wmg.3.2017.07.25.11.45.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jul 2017 11:45:30 -0700 (PDT) Date: Tue, 25 Jul 2017 20:45:28 +0200 From: Job Snijders To: Aris Lambrianidis Cc: Nick Hilliard , "sidrops@ietf.org" , draft-ietf-sidrops-route-server-rpki-light@ietf.org Message-ID: <20170725184527.qyd63ipba2mvyksl@Vurt.local> References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 18:45:35 -0000 Hi all, On Tue, Jul 25, 2017 at 04:38:38PM +0200, Aris Lambrianidis wrote: > We’re working on an updated draft to elaborate further on the valid > path hiding concerns you raised, as well as describing a new > transitive extended BGP community attribute, (instead of reusing the > one described in RFC8097), based on Job Snijders’ offline comments. I had some more dialogue with Aris off-list, and the following idea came up: With the current approach as outlined in sidrops-route-server-rpki-light-02 I find the anonymous attestation "this is a valid route" problematic. However if hints are provided which ASN made the claim, the idea of well-known communities to signal observed states is perhaps less problematic. What if a "Transitive Four-Octet AS-Specific Extended Community Sub-Type" is used and (route server) operators put their own ASN in the Global Administrator field, and an integer signifying the observed state in the Local Administrator field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02 | Sub-Type TBD | Global Administrator : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Global Administrator (cont.) | validationstate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (validationstate: 0 = "valid", 1 = "not found", 2 = "invalid") While i am still not entirely sold on the idea of "RPKI Light", this approach would alleviate some of my concerns: - As a transitive type, this community is allowed to cross EBGP boundaries without causing controversy; - by putting the attesting network's ASN in the Global Administrator field, any users of the community will need to explicitly configure their routing policy to match on those parameters, and we can then reasonably expect them to scrub in the appropiate places as well. This is a form of "opt-in". Furthermore I think the draft's intended status should be adjusted from "Standards track" to "Informational" (as is customary for most well-known communities). Half of the "Transitive Four-Octet AS-Specific Extended Community Sub-Types" space is FCFS anyway, so "Informational" is sufficient to obtain a codepoint. Thoughts? Kind regards, Job From nobody Tue Jul 25 12:16:00 2017 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 AF1C4131D06; Tue, 25 Jul 2017 12:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 EYcmeTg-omw2; Tue, 25 Jul 2017 12:15:56 -0700 (PDT) Received: from deliverix.ams-ix.net (deliverix.ams-ix.net [IPv6:2001:67c:1a8:a101::70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1C0127136; Tue, 25 Jul 2017 12:15:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at ams-ix.net Received: from [IPv6:2001:67c:1a8:102:10e2:b570:73cc:c076] (unknown [IPv6:2001:67c:1a8:102:10e2:b570:73cc:c076]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aristidis) by deliverix.ams-ix.net (Postfix) with ESMTPSA id 5A933416D5; Tue, 25 Jul 2017 21:15:54 +0200 (CEST) From: Aris Lambrianidis Message-Id: <23C61E35-DE89-42F8-A14B-4BA4AA68C993@ams-ix.net> Content-Type: multipart/signed; boundary="Apple-Mail=_13216EA6-C366-42CA-8006-352F70AD6224"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Jul 2017 21:15:53 +0200 In-Reply-To: <20170725184527.qyd63ipba2mvyksl@Vurt.local> Cc: draft-ietf-sidrops-route-server-rpki-light@ietf.org, Nick Hilliard To: Job Snijders , "sidrops@ietf.org" References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> <20170725184527.qyd63ipba2mvyksl@Vurt.local> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 19:15:59 -0000 --Apple-Mail=_13216EA6-C366-42CA-8006-352F70AD6224 Content-Type: multipart/alternative; boundary="Apple-Mail=_BD3717D1-2EDA-49B6-A968-538D3F4B45A1" --Apple-Mail=_BD3717D1-2EDA-49B6-A968-538D3F4B45A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Two comments: 1. Regarding transitivity of the extended community: This draft was never meant to replace RPKI. To state the obvious, it is impossible to do so, as cryptographic assurance does not exist for BGP communities. This basically means that any caveats applicable for known (and unknown) communities still apply. At its core, it's merely an informational tag. I would expect it should be up to the administrative authority to decide whether and how much they: a) Would trust such a tag (hopefully not at all if they are far removed from the AS conducting the validation, and marginally, if at all, if they are directly connected) b) Would scrub such communities or c) Would propagate them to its EBGP peers. As an example, I would certainly not consider it a general good practice to pass on such a tag to my upstreams, but I could see a use case in which I, as a single authority, administer multiple (non-confederated) Autonomous Systems and would like the = community be propagated across these. 2. Personally, I believe including the ASN conducting the Prefix Origin = Validation as a field within the encoding makes sense, for the reasons Job stated. I=E2=80=99ve already committed a version of the draft in our repository = to reflect this change, but I=E2=80=99ll wait for author consensus before we submit a = newer draft to the IETF repository. --Aris > On 25 Jul 2017, at 20:45, Job Snijders wrote: >=20 > Hi all, >=20 > On Tue, Jul 25, 2017 at 04:38:38PM +0200, Aris Lambrianidis wrote: >> We=E2=80=99re working on an updated draft to elaborate further on the = valid >> path hiding concerns you raised, as well as describing a new >> transitive extended BGP community attribute, (instead of reusing the >> one described in RFC8097), based on Job Snijders=E2=80=99 offline = comments. >=20 > I had some more dialogue with Aris off-list, and the following idea = came up: >=20 > With the current approach as outlined in = sidrops-route-server-rpki-light-02 > I find the anonymous attestation "this is a valid route" problematic. > However if hints are provided which ASN made the claim, the idea of > well-known communities to signal observed states is perhaps less > problematic. >=20 > What if a "Transitive Four-Octet AS-Specific Extended Community = Sub-Type" > is used and (route server) operators put their own ASN in the Global > Administrator field, and an integer signifying the observed state in = the > Local Administrator field. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0x02 | Sub-Type TBD | Global Administrator : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : Global Administrator (cont.) | validationstate | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > (validationstate: 0 =3D "valid", 1 =3D "not found", 2 =3D = "invalid") >=20 > While i am still not entirely sold on the idea of "RPKI Light", this > approach would alleviate some of my concerns: >=20 > - As a transitive type, this community is allowed to cross EBGP > boundaries without causing controversy; >=20 > - by putting the attesting network's ASN in the Global = Administrator > field, any users of the community will need to explicitly > configure their routing policy to match on those parameters, and > we can then reasonably expect them to scrub in the appropiate > places as well. This is a form of "opt-in". >=20 > Furthermore I think the draft's intended status should be adjusted > from "Standards track" to "Informational" (as is customary for most > well-known communities). Half of the "Transitive Four-Octet = AS-Specific > Extended Community Sub-Types" space is FCFS anyway, so "Informational" > is sufficient to obtain a codepoint. >=20 > Thoughts? >=20 > Kind regards, >=20 > Job >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops --Apple-Mail=_BD3717D1-2EDA-49B6-A968-538D3F4B45A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Two = comments:

1. = Regarding transitivity of the extended community: This draft
was never meant to replace RPKI. To state the obvious, it = is 
impossible to do so, as =  cryptographic assurance does not 
exist = for BGP communities.

This basically means that any caveats applicable for = known
(and unknown) communities still apply. At its = core, it's merely an 
informational tag. I = would expect it should be up to the administrative
authority to decide whether and how much they:

a) Would trust such a = tag (hopefully not at all if they are far
removed = from the AS conducting the validation, and marginally,
if at all, if they are directly connected)

b) Would scrub such = communities or 

c) Would propagate them to its EBGP peers.

As an example, I would = certainly not consider it a general good practice 
to pass on such a tag to my upstreams, but I could = see
a use case in which I, as a single authority, = administer
multiple (non-confederated) Autonomous = Systems and would like the community 
be = propagated across these.

2. Personally, I believe including the ASN conducting the = Prefix Origin Validation
as a field within the = encoding makes sense, for the reasons Job stated. 

I=E2=80=99ve already = committed a version of the draft in our repository to reflect = this 
change, but I=E2=80=99ll wait for author = consensus before we submit a newer draft to
the = IETF repository.

 --Aris


On 25 Jul 2017, at 20:45, Job Snijders <job@instituut.net> = wrote:

Hi all,

On Tue, Jul 25, 2017 at = 04:38:38PM +0200, Aris Lambrianidis wrote:
We=E2=80=99re working on an updated draft to = elaborate further on the valid
path hiding concerns you = raised, as well as describing a new
transitive extended = BGP community attribute, (instead of reusing the
one = described in RFC8097), based on Job Snijders=E2=80=99 offline = comments.

I had some more = dialogue with Aris off-list, and the following idea came up:

With the current approach as outlined in = sidrops-route-server-rpki-light-02
I find the anonymous = attestation "this is a valid route" problematic.
However = if hints are provided which ASN made the claim, the idea of
well-known communities to signal observed states is perhaps = less
problematic.

What if a = "Transitive Four-Octet AS-Specific Extended Community Sub-Type"
is used and (route server) operators put their own ASN in the = Global
Administrator field, and an integer signifying the = observed state in the
Local Administrator field.

   0 =             &n= bsp;     1 =             &n= bsp;     2 =             &n= bsp;     3
   0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
= =   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  |      0x02 =     | Sub-Type TBD  | =      Global Administrator =     :
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
  : Global Administrator (cont.)  | =        validationstate =        |
=   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
(validationstate: 0 =3D "valid", = 1 =3D "not found", 2 =3D "invalid")

While i = am still not entirely sold on the idea of "RPKI Light", this
approach would alleviate some of my concerns:
   - As a transitive type, this community is = allowed to cross EBGP
=      boundaries without causing controversy;

   - by putting the attesting = network's ASN in the Global Administrator
=      field, any users of the community will = need to explicitly
=      configure their routing policy to match on = those parameters, and
     we = can then reasonably expect them to scrub in the appropiate
=      places as well. This is a form of = "opt-in".

Furthermore I think the draft's = intended status should be adjusted
from "Standards track" = to "Informational" (as is customary for most
well-known = communities). Half of the "Transitive Four-Octet AS-Specific
Extended Community Sub-Types" space is FCFS anyway, so = "Informational"
is sufficient to obtain a codepoint.

Thoughts?

Kind = regards,

Job

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

= --Apple-Mail=_BD3717D1-2EDA-49B6-A968-538D3F4B45A1-- --Apple-Mail=_13216EA6-C366-42CA-8006-352F70AD6224 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZd5jpAAoJEA9B3v9ltRqsM9YP/01HvrXJYsKBXmoxxhR8cU38 YbW/ot1gLaKWph5iU8c0gCBdzy9lQsl9DCPmqhG2WhLc1VXvD/pFYCF/pv4n32xq vIHKP+1+0hZDhO8f2zAjjGhOLdPU1BcwKaXrxdkpkZDtbRZ54dCXMzW4mCFUkRNM OETB0DHz1co5yp3ME2bxcbulLXvGQMj5MfgRlyPboVMDYzdnpSmYW708fUBtjRQT PIYfnoknSe8LeEp+ThqZYQ7UvnqDFZlrkXL6CaYvdmY7zNdtD3/7bwJyMnM796W/ HRDhydbak5qgBNcmG7DI2aMPuyyvjXER2hoKbxUD5ET3fo50FBOSdyDMtxnHN6jv 5HO6Rm+aHvLepwuZbvUrPAWROpr4ycxyWLUREhY0wzE5xqbdPvXh+A9/+XIyLoH5 QhGgYTxDVl0s3zmG+PjiCUnF43rb+xoH340FX3ZjSrrD+TwCTJfY9PhL+4TjBtSb SpCyySH00RZSbnrd8OwugJrvhb9t3ed/lSmY5uR1KVEwrWXPLdJy7ZGAVKsDk/Cl jGkBXpEDTEQ6CgDcPp/vIqqAVwse09+UUlHMcLbOWz12Aixo14s66eDEVtsu1JhS tZsd3n+bMi96aLonft+mlxVJmeHQuyQlj3+7oWVq+xWI4TKkqeUST5kC/ncvMlX2 9HuBzznvkhGii6mDBwxj =G7TC -----END PGP SIGNATURE----- --Apple-Mail=_13216EA6-C366-42CA-8006-352F70AD6224-- From nobody Tue Jul 25 12:38:34 2017 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 5B19C131563 for ; Tue, 25 Jul 2017 12:38:33 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 DY1uLt3bawdf for ; Tue, 25 Jul 2017 12:38:31 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 212A0129B61 for ; Tue, 25 Jul 2017 12:38:30 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id f21so66738379wrf.5 for ; Tue, 25 Jul 2017 12:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XomwAgrUjd3nZC1idVl344wzI9jk+XFo0vVYS6UcN/0=; b=RHX2I4GXxIJwQOiCOVVc0fhBTnuEqE13m8VSg2AUqB4ufrJSwJnhkldc8WAjcDZ9NA 4B+uyObFFi0eIco5fjLV483ok6cKTQnvoF4nhGCpYGTYPrpU4QZLkSgV+Zw3lJegGq1z S0nEr1o3qeWZH1X6wND8TF65s+pHO4/QktjZe43ZE4WrcLDnEHxZemnCnF8FVijmvF9a iOitu3wbqc8N55Vn20KHGz2JehXgt8z5hCYsJFjUONrm05S/4NX5jgwKwksehNcJsCj6 tSCnY6jI9H6ebRP45hw2IZWPOtu/Qj0WYICCQ8FTcvoxFaM88FVeyf24fFOjSFddK8Kp umeQ== 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=XomwAgrUjd3nZC1idVl344wzI9jk+XFo0vVYS6UcN/0=; b=NPEzvF1ja8K5GJva8H9P2ws96PqPdd47+6QHQP3kRcekrDGghL/cuyZznJHTbVlvg2 LVg/FCDqxQ34X95xU9cLhpM9JzejM1AO+o1RjaHzMt1toBe0Noq8F50Ab4xzpkI34d5E TKuJNV4Kxza98F3w3o9zd8FyNkhDqw/2IYK3JvjWE1Ayyxk2j8VGLqthkQw5HCPljaXp H+artlQBXCT+KX2EePzqaH+Fa9eExbnOrLLz7gjMKR190Vh9ID3PllHd8usWwaUMl3Om Js+uzPMgT7C33I4fu95QhyfhoH1x5GSzgA1umpUYC7djIEoe9KMIJ0o/VzwlTv4NAEVv /oFQ== X-Gm-Message-State: AIVw111vCFbYB3VRBMfDvMuWCwDAaZmm194awPTxseUvRKsrpPGNX1ms RjPjdodvQXXU8g2gXGgBPF9HZ9iKMbMi X-Received: by 10.223.171.200 with SMTP id s66mr20816403wrc.38.1501011509297; Tue, 25 Jul 2017 12:38:29 -0700 (PDT) MIME-Version: 1.0 References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> <20170725184527.qyd63ipba2mvyksl@Vurt.local> <23C61E35-DE89-42F8-A14B-4BA4AA68C993@ams-ix.net> In-Reply-To: <23C61E35-DE89-42F8-A14B-4BA4AA68C993@ams-ix.net> From: Job Snijders Date: Tue, 25 Jul 2017 19:38:17 +0000 Message-ID: To: Aris Lambrianidis , "sidrops@ietf.org" Cc: Nick Hilliard , draft-ietf-sidrops-route-server-rpki-light@ietf.org Content-Type: multipart/alternative; boundary="001a113c2eead291b505552979f8" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 19:38:33 -0000 --001a113c2eead291b505552979f8 Content-Type: text/plain; charset="UTF-8" On Tue, 25 Jul 2017 at 21:15, Aris Lambrianidis < aristidis.lambrianidis@ams-ix.net> wrote: > comments: > Perhaps the title of the document can be updated to reflect the recent changes. How about the following as title: "Signalling BGP Prefix Origin Validation States with Transitive Extended Communities". Kind regards, Job > --001a113c2eead291b505552979f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 25 Jul 2017 at 21:15, Aris Lambrianidis <aristidis.lambrianidis@ams-ix.net> wro= te:
comments:

Perhaps the title of the document can= be updated to reflect the recent changes. How about the following as title= : "Signalling BGP Prefix Origin Validation States with Transitive Exte= nded Communities".

= Kind regards,

Job
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--001a113c2eead291b505552979f8-- From nobody Tue Jul 25 18:23:51 2017 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 50301124B0A for ; Tue, 25 Jul 2017 18:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 vUWxFsnsZJur for ; Tue, 25 Jul 2017 18:23:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3870B1286B2 for ; Tue, 25 Jul 2017 18:23:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1daB3C-0002Jv-Dc; Wed, 26 Jul 2017 01:23:46 +0000 Date: Wed, 26 Jul 2017 10:23:44 +0900 Message-ID: From: Randy Bush To: Job Snijders Cc: sidrops@ietf.org In-Reply-To: References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <5971FE7B.6060607@foobar.org> <20170725184527.qyd63ipba2mvyksl@Vurt.local> <23C61E35-DE89-42F8-A14B-4BA4AA68C993@ams-ix.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 01:23:50 -0000 > Perhaps the title of the document can be updated to reflect the recent > changes. How about the following as title: "Signalling BGP Prefix Origin > Validation States with Transitive Extended Communities". how about "Outsourcing Security Using Transitive Extended Communities?" randy From nobody Wed Jul 26 01:25:21 2017 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 1116F131FC6 for ; Wed, 26 Jul 2017 01:25:20 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 ic7_D7Ltpi8B for ; Wed, 26 Jul 2017 01:25:18 -0700 (PDT) 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 0ABC7131FC4 for ; Wed, 26 Jul 2017 01:25:18 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1daHd4-0005rU-Ln; Wed, 26 Jul 2017 10:25:15 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-190.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1daHd4-0006HH-Hf; Wed, 26 Jul 2017 10:25:14 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <96044ca1d98d4cb99fe2dd8e6d3ead08@XCH-ALN-014.cisco.com> Date: Wed, 26 Jul 2017 10:25:14 +0200 Cc: "Carlos M. Martinez" , "sidrops@ietf.org" , Matthias Waehlisch Content-Transfer-Encoding: quoted-printable Message-Id: <1A84C9BF-68CD-45A2-A933-02A732603FC9@ripe.net> References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> <78F49BAC-F0F2-4712-862A-BCFA1A9DC35D@ripe.net> <96044ca1d98d4cb99fe2dd8e6d3ead08@XCH-ALN-014.cisco.com> To: "Jakob Heitz (jheitz)" X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07195ad6197ad15407002aba1f63f755a44b Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 08:25:20 -0000 > On 25 Jul 2017, at 19:55, Jakob Heitz (jheitz) = wrote: >=20 > I could understand if there are providers that would rather accept > the "maybe invalid" than drop them. Dropping prefixes breaks = connectivity. True, but they are really =E2=80=9Cinvalid=E2=80=9D in the validation = sense. You can choose to ignore this, or the holder can authorise them = so they will be valid - which would be the better solution. I believe a lot of this comes down to a burden of proof kind of concept = - if the connectivity breaks because the holder only partially = authorised their announcements - then they are to =E2=80=98blame=E2=80=99 = and they have the power to fix. > If they can't tell the difference between "matched with wrong AS" > and covered, then they'll just accept them all. I believe it would be better then to make this difference available to = operators, rather than artificially marking things as valid. Accepting more specific announcements leaves one vulnerable though to = more specific announcements done with a spoofed AS. Therefore, if the = path cannot be trusted, e.g. by use of BGPSec, doing blanket acceptance = policy to accept =E2=80=9Cinvalid length=E2=80=9D introduces a major = vulnerability. That said, if you as an operator have other ways of determining whether = you can trust the path, e.g. because it=E2=80=99s a leaf customer of = yours and its path length is 1, or because the path is short and you = know and trust all the ASNs on it, then I think there is something to be = said for a pragmatic policy of accepting more specifics here. It = doesn=E2=80=99t give the full RPKI+Origin Validation+BGPSec certainty, = but it=E2=80=99s probably a big step up from today without causing too = many issues. I am quite sure that talking about this will also generate quite some = discussion between more purist and more pragmatic world views on = security, but I think it=E2=80=99s probably a good discussion to have. >=20 > Thanks, > Jakob. >=20 >=20 >> -----Original Message----- >> From: Tim Bruijnzeels [mailto:tim@ripe.net] >> Sent: Tuesday, July 25, 2017 6:49 AM >> To: Jakob Heitz (jheitz) >> Cc: Carlos M. Martinez ; Matthias Waehlisch = ; sidrops@ietf.org >> Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and = the Learning-Validator >>=20 >> Hi, >>=20 >> Jakob, not picking on you - but your statement gave me a good angle = for what I wanted to say on this. >>=20 >>> On 20 Jul 2017, at 19:01, Jakob Heitz (jheitz) = wrote: >>>=20 >>> If it causes legitimate traffic to fail, then it's wrong. >>=20 >> Sure, but knowing what constitutes legitimate is the trick then. If = an announcement has status =E2=80=9Cinvalid=E2=80=9D, then this >> means that the holder of the prefix made one or more authorisation(s) = for other announcement(s) for this space, but >> not for *this* announcement. >>=20 >> Whether this is: >> a) a bug, because the holder wants the announcement but neglected to = authorise; or >> b) a feature, because the holder does not want this announcement >>=20 >> That is impossible to tell based only on the observation that there = is a disagreement. And I fear that any smart >> heuristics, e.g. based on announcement history, are in the end only = estimated guesswork. It may be smart and it may >> be right more often than wrong, but it=E2=80=99s still guesswork. >>=20 >> Now, I see value in exposing such differences and helping operators = anywhere to understand and debug them and take >> action, but I have to say that I disagree quite fundamentally on = automating decisions on the validator side. I >> believe that it will inevitably result in announcements that are = supposed to be =E2=80=9Cinvalid=E2=80=9D (by choice of the holder) >> to become authorised. This will degrade the benefit of using RPKI = Origin Validation for networks that do maintain >> their ROAs properly. Secondly I believe that =E2=80=98fixing=E2=80=99 = this on the RP side will remove the incentive for networks to >> fix their ROAs so that they match their intended announcements. If it = hurts, people will fix it. This has been >> happening in Europe for decades w.r.t. route objects. >>=20 >> Let me provide a further datapoint. We have 4880 organisations that = activated their hosted RPKI service. Some >> organisations only switched on the system, but a total of 2874 = organisations actively maintain ROAs. We provide an >> opt-in service whereby organisations can receive alerts in case we = see announcements that are inconsistent with >> their ROAs. Although this is not mandatory, the majority of = organisations (2020) have opted in to this service. The >> alerts will inform the organisation of any =E2=80=9Cinvalid=E2=80=9D = or =E2=80=9Cunknown=E2=80=9D announcements. On receiving this = organisations can >> choose to authorise these announcements - but ONLY if they are = supposed to be correct (their choice). If they do not >> authorise the announcement, and it keeps happening, they will receive = an email every day. For this reason users can >> also choose to suppress the warnings on announcements they do not = wish to authorise. We have 219 organisations that >> have at lease one announcement suppressed. >>=20 >> So, in short: I believe that this in itself proves that a lot of our = users are actively managing their ROAs, and >> that quite a few of the =E2=80=9Cinvalids=E2=80=9D out there are = really supposed to be considered just that: =E2=80=9Cinvalid=E2=80=9D >>=20 >> Thanks >> Tim >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Thanks, >>> Jakob. >>>=20 >>> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Carlos = M. Martinez >>> Sent: Thursday, July 20, 2017 8:41 AM >>> To: Matthias Waehlisch >>> Cc: sidrops@ietf.org >>> Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and = the Learning-Validator >>>=20 >>> I was about to ask a question on the mic but was late to the line. = Maybe it=E2=80=99s worth sharing it here: >>>=20 >>> =E2=80=A2 How we define a ROA to be =E2=80=9Cwrong=E2=80=9D ? = One that invalidates routes or one that causes legitimate traffic to be >> dropped ? >>> Why? because we=E2=80=99ve seen in many cases ROAs that create lots = of invalids but validate a less-specific route that >> covers those invalids >>>=20 >>> In a way, this even a positive side-effect, sort of vacuum-cleaning = your routing tables. >>>=20 >>> I believe analyzing what ROAs are wrong is quite important, but = i=E2=80=99d believe this particular case should not count >> as wrong. >>>=20 >>> thanks! >>>=20 >>> /Carlos >>>=20 >>> On 17 Jul 2017, at 16:36, Matthias Waehlisch wrote: >>>=20 >>> two comments via the list because we run out of time: >>>=20 >>> (1) I'm wondering about the statement that the quality of ROAs = decreases >>> over time. My impression is that the quality improved because of >>> excellent training by RIRs and others. >>>=20 >>> Slide 4 shows absolute values, which is not helpful in this context. >>>=20 >>>=20 >>> (2) Regarding ROV measurements: "Similar results apparently from >>> measurements by Randy Bush and others (didn't yet see details)" >>>=20 >>> Details are available, easy to find using Google: >>>=20 >>> * "Towards a Rigorous Methodology for Measuring Adoption of RPKI = Route >>> Validation and Filtering", https://arxiv.org/abs/1706.04263. Some of >>> this work was also presented at the last RIPE meeting: >>> https://ripe74.ripe.net/archives/video/46/ >>>=20 >>>=20 >>>=20 >>>=20 >>> Cheers >>> matthias >>>=20 >>> -- >>> Matthias Waehlisch >>> . Freie Universitaet Berlin, Computer Science >>> .. http://www.cs.fu-berlin.de/~waehl >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >>>=20 >>> _______________________________________________ >>> Sidrops mailing list >>> Sidrops@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Wed Jul 26 13:18:21 2017 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 649BF124234 for ; Wed, 26 Jul 2017 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 I2jGxIHreddn for ; Wed, 26 Jul 2017 13:18:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F423E12EB99 for ; Wed, 26 Jul 2017 13:18:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1daSl6-0001np-RI; Wed, 26 Jul 2017 20:18:17 +0000 Date: Thu, 27 Jul 2017 05:18:15 +0900 Message-ID: From: Randy Bush To: Tim Bruijnzeels Cc: sidrops@ietf.org In-Reply-To: <1A84C9BF-68CD-45A2-A933-02A732603FC9@ripe.net> References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> <78F49BAC-F0F2-4712-862A-BCFA1A9DC35D@ripe.net> <96044ca1d98d4cb99fe2dd8e6d3ead08@XCH-ALN-014.cisco.com> <1A84C9BF-68CD-45A2-A933-02A732603FC9@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 20:18:20 -0000 > Accepting more specific announcements leaves one vulnerable though to > more specific announcements done with a spoofed AS. one of the principle goals of the whole effort From nobody Wed Jul 26 15:49:04 2017 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 4A119131E88 for ; Wed, 26 Jul 2017 15:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 KlHo89Rgvmhe for ; Wed, 26 Jul 2017 15:49:00 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 4D1D9131D02 for ; Wed, 26 Jul 2017 15:49:00 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id w45so128038995uac.5 for ; Wed, 26 Jul 2017 15:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0mXwA7fwKiqdww9P4qka4kqIe2e14U4sdQL6s9CXmRQ=; b=UNLwfvNUkFcOjM0KVdnn1a3x0scDy+BQV+OVRq13EJXunNUmWbhs252ykGQ4imhzHE ubodmu/pDaI7uUKxrvP7AWxfc9WoUAapDYRxDEfmhtaJlaW/Zzs3P7KxueQ0i3xpZrgf HfrJpZT2EjH7tl6Vpr07sthB6nBbEsSK69BacBySVeFaTizdc6IwxPZJaWv7rndWvoSN nTPcO70cgjPc2sklVHE79TSVotRPtbD0aKmcLPDfh5H4FFuupk/QsRUgwQavqz49jVd5 gG0K6aok33GF/Q58ADHvYGiQhIClsBwxVZn1zoOoZGEv3i9fB4TRESfkw/F0Ua1QoPC8 0d0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0mXwA7fwKiqdww9P4qka4kqIe2e14U4sdQL6s9CXmRQ=; b=EiHE46/lXCjbl2W7SVL7OdDow2uCIouFP73RcQupiLDkFxmdhMBiyDMU21OnJJuJok /iI3pW2NfZhJ/FglwtyWKrlyfINYimoZxsYeVA1XGKeFvQ+s59bxGdA/FrzpuMmODYqS y8VJD2OI4g2i7wxQzkn1QtFqxDQjeychn47Cr8gGlfYXF3+aPHZe/OQbPEUcu0ZzCEb4 QQpHmIoHRgkl8qyFuEVyfeChZFCUbJ3oC8JGRxdKd/Gk5zPQ0sl29x0a3po38wgqqF7x Kdbh3AHfyZBSKowFbd/UMG4uuZ4Oxx7UQP5b7Cv6YXF86c/W4rIFUBtnnQOoWG5M1Oki dx4g== X-Gm-Message-State: AIVw112bErJc3/gIjsRo/71rWusjmCDIoNqMij3lpYqbtRqq8PORxrop eLOH4HaLLkjvCgov6SVF33f9MRi+lH3dI60= X-Received: by 10.31.50.137 with SMTP id y131mr1433758vky.181.1501109339273; Wed, 26 Jul 2017 15:48:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.87 with HTTP; Wed, 26 Jul 2017 15:48:58 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:8de4:97b6:117e:2210] In-Reply-To: References: <5ED572DF-AC77-4F54-92DC-F65C86F4E022@gmail.com> <177afbdbb5424f26992196dae0219ff1@XCH-ALN-014.cisco.com> <78F49BAC-F0F2-4712-862A-BCFA1A9DC35D@ripe.net> <96044ca1d98d4cb99fe2dd8e6d3ead08@XCH-ALN-014.cisco.com> <1A84C9BF-68CD-45A2-A933-02A732603FC9@ripe.net> From: George Michaelson Date: Thu, 27 Jul 2017 08:48:58 +1000 Message-ID: To: Randy Bush Cc: Tim Bruijnzeels , sidrops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Sidrops] Talk: RPKI Deployment: Status, Challenges and the Learning-Validator X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 22:49:03 -0000 I am probably being simplistic, but my memory of this conversation during happier more innocent days was that a covering prefix's use of a ROA signalled that RPKI applied to all origin-as assertions made below it, as more specific. Thats how I understood us to be discussing it. For this mail, I discount a ROA which fails cryptographic checks: its being spoofed or is otherwise mechanistically in error and cannot apply. The address holder is the sole signatory of a ROA. The address holder of the covering prefix has a delegation authority over the more specific. If they had transferred the resources, there would be an overt 'hole' in their addresses and it would have a different RFC3779 representation, so there is no 'prefix' as such to announce: if they continue to announce the aggregate covering prefix when there is an explicit transfer out of the more specific, that wasn't engineered for in the model. There can be no covering ROA which refers to it since the 3779 state is not legal under the signing (even under modified validation, the ROA which overclaims is going to be invalid) So excluding explicit transfer, I believe the 'reductionist' sense of a more specific is: either its authorized by an explicit ROA referring to itself, or its implied as legal in the values specified in a covering aggregate ROA, or its not actually permissable. I can't see any other state implied. I do not see this as a tri-state situation: if the aggregate over it is legal, then all more specifics of that aggregate require a ROA or implied consent from the aggregate to be true. (basically, the same AS and a length-permitting setting) Now, as to intent: if somebody *wants* the more specific to exist, there is a path out: make a ROA. If this is a timeliness situation, they haven't published one, thats a transitional fault. if it persists, its an operational failure. But its not in system to say "oh, they probably meant this" -Thats not how validation is meant to work. Do we really want to move to a world where crypto intent and declared validation semantics can be _interpreted_ ? Why do a ROA, for the covering aggregate, if you didn't intend applying ROA semantics to all addresses in the covering ROA? The semantics should be concrete. Not inferential. What am I missing here? What did I not understand? 'inferring' intent, belief, which is not backed by the literal meaning of the ROAs which exist, and their cryptographic checks, feels to me like a losing game. On Thu, Jul 27, 2017 at 6:18 AM, Randy Bush wrote: >> Accepting more specific announcements leaves one vulnerable though to >> more specific announcements done with a spoofed AS. > > one of the principle goals of the whole effort > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Sat Jul 29 17:59:51 2017 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 24937129AD1 for ; Sat, 29 Jul 2017 17:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 PcsGvXmTPjgO for ; Sat, 29 Jul 2017 17:59:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 83835131D14 for ; Sat, 29 Jul 2017 17:59:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1dbca9-0004mH-QJ for sidrops@ietf.org; Sun, 30 Jul 2017 00:59:46 +0000 Date: Sun, 30 Jul 2017 09:59:44 +0900 Message-ID: From: Randy Bush To: sidrops@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 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: [Sidrops] draft-ymbk-sidrops-ov-clarify-01.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jul 2017 00:59:49 -0000 the following has been posted From: internet-drafts@ietf.org Subject: New Version Notification for draft-ymbk-sidrops-ov-clarify-01.txt To: "Randy Bush" Date: Sat, 29 Jul 2017 17:56:22 -0700 A new version of I-D, draft-ymbk-sidrops-ov-clarify-01.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Name: draft-ymbk-sidrops-ov-clarify Revision: 01 Title: Origin Validation Clarifications Document date: 2017-07-30 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-ymbk-sidrops-ov-clarify-01.txt Status: https://datatracker.ietf.org/doc/draft-ymbk-sidrops-ov-clarify/ Htmlized: https://tools.ietf.org/html/draft-ymbk-sidrops-ov-clarify-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-ov-clarify-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-ymbk-sidrops-ov-clarify-01 Abstract: Deployment of RPKI-based BGP origin validation is hampered by, among other things, vendor mis-implementations in two critical areas, which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those mis-implementations. this version includes text to cover the AS specification hole noted by keyur, as follows: When redistributing into BGP from connected, static, IGP, iBGP, etc., there is no AS_PATH in the input to allow RPKI validation of the originating AS. In such cases, the router SHOULD use the AS of the router's BGP configuration. If that is ambiguous because of confederation, AS migration, or other multi-AS configuration, then the router configuration MUST provide a means of specifying the AS to be used on the redistribution, either per redistribution or globally. thanks keyur. can we please adopt this document and progress it? thanks. randy